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
| 09:30 | Guest14 joined #evergreen | |
| 09:52 | cbrown joined #evergreen | |
| 10:01 | mantis joined #evergreen | |
| 10:01 | mantis | running through the 3.11.6 ver install on a test server and I got a lot of these errors when building our Angular files |
| 10:01 | mantis | ex; Error: src/main.ts:1:32 - error TS2307: Cannot find module '@angular/core' or its corresponding type declarations. |
| 10:01 | mantis | not sure why this is a problem now |
| 10:03 | JBoyer | mantis, that looks like you're either running the "build from git" instructions when you don't need to or if you are installing from git maybe missed one of the pre-req install steps? |
| 10:03 | mantis | this is the command |
| 10:03 | mantis | ng build --configuration production |
| 10:04 | JBoyer | The npm install step is what I'm wondering about, that's what pulls down things like angular core and friends. |
| 10:04 | mantis | I know it's technically outdated |
| 10:05 | mantis | also run into this after running CHROME_BIN=/usr/bin/chromium-browser npm run test |
| 10:05 | mantis | 23 07 2024 09:59:20.061:ERROR [karma-server]: Error: Found 1 load error |
| 10:05 | mantis | at Server.<anonymous> (/home/opensrf/Evergreen-ILS-3.11.6-biblio/Open-ILS/src/eg2/node_modules/karma/lib/server.js:243:26) |
| 10:05 | mantis | at Object.onceWrapper (node:events:631:28) |
| 10:05 | mantis | at Server.emit (node:events:529:35) |
| 10:05 | mantis | at Server.emit (node:domain:489:12) |
| 10:05 | mantis | at emitListeningNT (node:net:1851:10) |
| 10:05 | ian1 joined #evergreen | |
| 10:06 | JBoyer | is there anything in /home/opensrf/Evergreen-ILS-3.11.6-biblio/Open-ILS/src/eg2/node_modules and was a different version of Evergreen installed previously? |
| 10:06 | mantis | I'll check |
| 10:18 | mantis | Yeah it had Evergreen 3.11.4 on here |
| 10:18 | mantis | though I am comparing angular/core directories and there are a couple of differences |
| 10:18 | Dyrcona | Well, that's not old enough to cause issues with different node versions. |
| 10:18 | mantis | esm2020 and testing folders are not in evgtest2 |
| 10:19 | mantis | Dyrcona++ |
| 10:19 | mantis | I'll try the reinstallation |
| 10:20 | Dyrcona | I wonder if something made it into 3.11.6 that should not have? I built it. It installed fine from the tarball, but I did not attempt an upgrade. |
| 10:20 | mantis | should I remove the node_modules before or after running the build commands? |
| 10:21 | Dyrcona | BTW, I am working on Lp2060734 again today. I've made a couple of releases with it, and I'm about to test the results of those releases on Debian Bookworm and Ubuntu 24.04, so I'm also in the middle of doing installations. |
| 10:21 | Dyrcona | Lp 2060734 |
| 10:21 | pinesol | Launchpad bug 2060734 in Evergreen "Various changes to the release process" [Undecided,Confirmed] https://launchpad.net/bugs/2060734 - Assigned to Jason Stephenson (jstephenson) |
| 10:23 | Dyrcona | I should build one from git, maybe. |
| 11:52 | Dyrcona | I think I have one hanging around maybe. It might have gone in. |
| 11:56 | Dyrcona | I can use Lp 1835953 |
| 11:57 | pinesol | Launchpad bug 1835953 in Evergreen "Circulation auto renewal remaining should not be nullable" [Medium,Confirmed] https://launchpad.net/bugs/1835953 |
| 11:57 | Dyrcona | Hm... something wrong with my configuration. The two tests that depend on apache failed. |
| 11:59 | Dyrcona | I'll look into it after lunch. |
| 12:03 | jihpringle joined #evergreen | |
| 12:19 | JBoyer | To this day I do not understand rooibos tea. (At least that one, I know there's more than one type.) |
| 12:40 | Dyrcona | Looks like my problem was nginx needed a restart. |
| 12:41 | * Dyrcona | has never had rooibos tea. |
| 12:42 | Dyrcona | Ok. gonna test my fake upgrade from 3.14.0 to 3.14.1, then I'll do 3.14.1 to 3.14.2.... :) |
| 12:46 | Dyrcona | Think I'll do somethin' unorthodox... I'll reinstall the 3.14.0 schema and data, then run the db upgrade, and then install 3.14.1. After that, I'll run the tests. |
| 13:01 | cbrown_isl joined #evergreen | |
| 13:03 | Dyrcona | So, that works... |
| 10:06 | mmorgan | mantis: Point releases are out! https://evergreen-ils.org/ |
| 10:08 | mantis | sweet thanks! |
| 10:17 | redavis joined #evergreen | |
| 10:27 | ian1 | It appears we may not have postgresql logs enabled for our test servers. I was able to get this log from `/openils/var/log/osrfsys.log`: |
| 10:27 | ian1 | [2024-07-22 09:59:55] /usr/sbin/apache2 [ACT:20655:Search.pm:480:17214480092065521] EGWeb: [bre search] item_lang:por filter_group_entry(4) depth(0) |
| 10:28 | ian1 | lol. It grabbed ':' 'p' and made an emoji, but let it be known that was not in the logs. |
| 11:03 | Dyrcona | ian1: Emojis depend on the client. I turned them off for this reason. |
| 11:07 | Dyrcona | ian1: PostgreSQL also doesn't log much by default, sometimes not even bad queries. In this case I think you have a long-running query. |
| 11:07 | Dyrcona | Oh, bummer. |
| 11:14 | ian1 joined #evergreen | |
| 11:16 | ian1 | Just walked away and I see I missed some chat in the logs. The query is definitely very long running. I don't know why that might be and I don't know why the results are empty. If I used the `item_lang` field in a traditional search in opac it returns results no problem. |
| 11:17 | Dyrcona | KPAC might not run the exact same query. It probably add audience filters. If you can get PostgreSQL to log the query, you can attempt to see what's wrong. |
| 11:18 | ian1 | I assumed that and added audience filters in my OPAC search in an attempt to simulate that. Let me check on enabling the logs and once again come back to you guys. Thank you as always. |
| 11:30 | ian1 | It looks like the postgreSQL log options for our test servers are outside my jurisdiction for now. I can try to test this locally for now and ping my server admin when hes back in office. I'm using the dev version of the evergreen-ils docker image. As far as I can tell, it doesnt have test data by default, but if I can load some up, I can definitely change the log settings there. Any suggestions? |
| 11:38 | Dyrcona | Test data is not the same as production data. My suspicion is you likely need to do a vacuum analyze or possibly a reindex in production. You might also be missing an index. |
| 11:40 | ian1 | Makes sense. This might have to wait until I have access to someone with the authority to do that here. Appreciate the discussion. |
| 11:42 | Dyrcona | It might be good to ask about getting a test environment with production data for situations like this. |
| 11:45 | mmorgan | ian1: As Dyrcona says, production data is the ultimate test, but testing on a limited dataset is valuable also to confirm the logic works. |
| 11:52 | ian1 | Heard. Thanks everyone. :-D |
| 12:00 | ian1 joined #evergreen | |
| 12:01 | jihpringle joined #evergreen |
| 08:33 | ian1 joined #evergreen | |
| 08:34 | cbrown-isl joined #evergreen | |
| 08:34 | mmorgan joined #evergreen | |
| 08:41 | ian1 | Good morning, everyone. I'm looking to get a local test environment up and running. Any recommendations? |
| 08:42 | kworstell-isl joined #evergreen | |
| 08:53 | stompro joined #evergreen | |
| 08:58 | ian1 joined #evergreen | |
| 09:23 | redavis joined #evergreen | |
| 09:27 | mmorgan | ian1: FWIW, I've used both VirtualBox and Docker and have found Docker to be the shallower learning curve to get an enviroment up and running. I like the persistence of the VirtualBox images, though. |
| 09:29 | mmorgan | Feel free to ask questions as you explore! |
| 09:39 | ian1 | I initially ran through the install instructions on virtual box running ubuntu jammy, but I like doing my development on Windows primarily. Docker is looking attractive. How long does it take to reset the server to test new changes? I'm coming from a lot of front-end web dev stuff. I miss hot reload. :'( |
| 09:47 | berick | mmorgan: building virtualbox images manually or w/ ansible? |
| 09:53 | mmorgan | berick: ansible! |
| 09:54 | berick | ok, good, just making sure you're not typing all that stuff :) |
| 09:41 | csharp_ | pinesol: yo |
| 09:41 | pinesol | csharp_: WORKSFORME WONTFIX |
| 09:42 | book` joined #evergreen | |
| 10:20 | Dyrcona | jeff: Thanks to something stompro said in an email (non-community list), I realize why the same tests were always failing when I used a remote PotsgreSQL database server with certain VMs. The local VM and the PostgreSQL server were set to different time zones. Some of our billing tests are time sensitive. |
| 10:20 | Dyrcona | stompro++ |
| 10:21 | JBoyer | stompro++ good catch |
| 10:25 | Dyrcona | Do the bots come back on their own, or do they need a little help? |
| 08:53 | Dyrcona joined #evergreen | |
| 08:53 | mantis joined #evergreen | |
| 09:32 | jvwoolf joined #evergreen | |
| 10:55 | Dyrcona | stompro: I'm going to have another look at Lp 2054842. I want to rebase the branches and run the tests again. Don't let that stop you from looking at them if you wish. |
| 10:55 | pinesol | Launchpad bug 2054842 in OpenSRF "Add Installation on Ubuntu 24.04" [Wishlist,In progress] https://launchpad.net/bugs/2054842 - Assigned to Jason Stephenson (jstephenson) |
| 11:00 | Dyrcona | I think the issue is that some test fail on a remote database, but they succeed if the test is local, and IIRC, I've seen that not just on Ubuntu 24.04, but other distros as well. |
| 11:01 | Dyrcona | Ugh. I mean if the database is on a remote server, some of the tests seem to fail, and if the database is local, they succeed. |
| 11:02 | pinesol | News from commits: LP2018014: Add release note <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=588da520d3def40fdf89f586b920d6e65502543a> |
| 11:04 | jeff | are the failing tests failing because they have pre-reqs that aren't in the database server pre-req Makefile target(s)? |
| 11:55 | ian1 joined #evergreen | |
| 12:32 | redavis joined #evergreen | |
| 12:41 | Christineb joined #evergreen | |
| 13:17 | Dyrcona | jeff: I don't think so. I pasted it here before. One of them doesn't find as many bills as it expects. |
| 13:20 | Dyrcona | Here's one place I mentioned the failing tests before and eliminated Pg 16 as the culprit: http://irc.evergreen-ils.org/evergreen/2024-06-24#i_555023 |
| 13:27 | Dyrcona | I was also considering the possibility that Lp 2060734 caused it. I had that one, Lp 2054842 and Lp 2037656 applied. I also tested wit an older release, IIRC, and got failures on a remote database with all the prerequisites installed. (I have a test db server with everything installed that I use all the time and it works for normal operations.) |
| 13:27 | pinesol | Launchpad bug 2060734 in Evergreen "Various changes to the release process" [Undecided,Confirmed] https://launchpad.net/bugs/2060734 - Assigned to Jason Stephenson (jstephenson) |
| 13:27 | pinesol | Launchpad bug 2054842 in OpenSRF "Add Installation on Ubuntu 24.04" [Wishlist,In progress] https://launchpad.net/bugs/2054842 - Assigned to Jason Stephenson (jstephenson) |
| 13:27 | pinesol | Launchpad bug 2037656 in Evergreen "Add Support for PostgreSQL 16" [Wishlist,Confirmed] https://launchpad.net/bugs/2037656 |
| 13:29 | kworstell_isl_ joined #evergreen | |
| 13:30 | kworstell_isl_ joined #evergreen | |
| 13:32 | kworstell_isl joined #evergreen | |
| 13:58 | Dyrcona | Testing on Ubuntu 24.04 with local Pg 16, make check and make livecheck pass. |
| 14:25 | Dyrcona | Sure is slow running the tests over the Internet. :) |
| 14:30 | Dyrcona | Up to 24-login-ap.t and it looks like they've all passed so far. I was getting failures before this in the past. Maybe it's just one of those things? Maybe jeff was right about something missing, but the failing tests didn't seem like ones where it would matter. |
| 14:32 | jvwoolf joined #evergreen | |
| 14:49 | Dyrcona | Hey! make livecheck passed this time. |
| 14:59 | kworstell-isl joined #evergreen |
| 13:57 | Dyrcona | jmurray-isl: What step can I put you down for : https://docs.google.com/spreadsheets/d/1gZayHfF7qK0zwLMEAXt-PbKBMiAM_F6EZguqzIYceBY/edit?gid=0#gid=0 |
| 14:51 | abneiman | in advance of point releases next week, there's one uncommitted High importance bug on 3.13 if anyone has eyes: https://bugs.launchpad.net/evergreen/+bug/2071372 |
| 14:51 | pinesol | Launchpad bug 2071372 in Evergreen "3.13 previous templates cloned will lose column connections" [High,Confirmed] |
| 15:01 | abneiman | (the aforementioned bug has a pullrequest, I will poke for a test plan) |
| 15:12 | pinesol | News from commits: Docs: adding 3.13 to site.yml <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=3a58d1c6ea1e89bb5914d768f36200a6195d7c2a> |
| 15:20 | cbrown-isl joined #evergreen | |
| 16:22 | mmorgan | For those that are using a true sms solution for text message, how have you dealt with hiding/removing the sms carrier option from the client and opac? |
| 16:20 | Dyrcona | canceling statement due to conflict with recovery |
| 16:20 | Dyrcona | replication... |
| 16:20 | Dyrcona | select * from metabib.real_full_rec where tag = '245' and subfield = 'h' and index_vector @@ to_tsquery('electronic & resource'); That thar be a slow query. |
| 16:22 | Dyrcona | Ooh. but I got results in production which is more than I can say for the test database. |
| 16:59 | mmorgan left #evergreen | |
| 17:00 | Dyrcona | And, other voices say we probably do want to send these records.... |
| 17:00 | Dyrcona | That's enough for today. |
| 10:20 | Dyrcona | ian1: Do you mind pasting the command line you used? |
| 10:21 | ian1 | perl Open-ILS/src/support-scripts/eg_db_config --update-config --service all --create-database --create-schema --create-offline --user evergreen --password ******* --hostname localhost --port 5432 --database everdb --admin-user evergreen --admin-pass ********* |
| 10:22 | Dyrcona | Two suggestions: 1. if there is no other database on here, name the database "evergreen" it will save you issues with psql. |
| 10:23 | Dyrcona | 2. Set the --admin-usr to "admin" and the --admin-pass to "demo123". This way, you can run the automated tests and they will just work. |
| 10:23 | ian1 | I can just run it again right? |
| 10:23 | Dyrcona | I guess a third suggestion: Add --load-all-sample to get some sample data in the database, unless you intend to build your data from scratch. |
| 10:24 | Dyrcona | You can, but I'd drop everdb, first : psql -U evergreen -h localhost -d postgres -c 'drop database everdb;' |
| 10:26 | ian1 | round x |
| 10:27 | Dyrcona | I don't remember how many times it took me to get a working test installation the first time. I still mess things up now and then when I build a new vm for testing. There are also scripts and docker images out there to make the setup easier. |
| 10:27 | Dyrcona | It's because we've all made the same mistakes that we're able to help. :) |
| 10:28 | Dyrcona | Also, if you can think of better ways to word the instructions, please do make suggestions/open bugs on Launchpad. |
| 10:29 | ian1 | I'm planning to attend DIG meetings at a minimum. May look for other ways to get involved as well. I love a clean well formatted document. So I ran the db config again. |
| 10:45 | Dyrcona | huh.... |
| 10:45 | Dyrcona | At this point, I'm stumped. |
| 10:45 | Dyrcona | I'd need to see the configuration files. |
| 10:46 | Dyrcona | Did you test OpenSRF before with the math add test from the OpenSRF README? |
| 10:46 | ian1 | I did that yesterday and at the time it worked fine |
| 10:46 | Dyrcona | So, you have /etc/ld.so.conf.d/opensrf.conf, then.... |
| 10:47 | Dyrcona | Is this Ubuntu 24.04? |
| 15:29 | sandbergja | I was hoping we could go back to the previous discussion, and pull out one or two bitesize items that we could make progress on *in this meeting* |
| 15:29 | abneiman | ok - did you have your eye on a couple items in particular? |
| 15:29 | redavis | fer sure. But I do like the idea of someone being able to checkout a virtual machine. Just used that in a class and it was delightful. |
| 15:29 | sandbergja | so not like move git hosting or setting up a VM checkout system, but... like more guidance on backporting. Or doing something proactive about existing pull requests without test plans |
| 15:30 | jeffdavis | Would a "needstestplan" tag be useful or is that just kicking the can down the road some more? |
| 15:30 | redavis | jeffdavis++ |
| 15:30 | sleary | was just thinking that, jeffdavis |
| 15:31 | abneiman | it's certainly a start |
| 15:31 | abneiman | jeffdavis++ |
| 15:31 | Dyrcona | For testing, we do have this old document: https://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa |
| 15:31 | Dyrcona | It basically says, you must include tests. |
| 15:32 | jeffdavis | I think " a plan for how to test if the fix works" is not necessarily the same as the automated tests contemplated there. |
| 15:32 | jeffdavis | Although automated tests are certainly ideal. |
| 15:32 | sleary | correct. |
| 15:32 | abneiman | yes, I was going to say - not everything is automatically-testable |
| 15:32 | redavis | I think there are both code tests and feature tests. |
| 15:33 | sleary | and I think that document is not entirely up to date with our current translation process. |
| 15:33 | abneiman | and in fact, we do have a "needstest" LP tag which indicates that an automated test is needed (and is often misapplied by people who think it means "please test this") |
| 15:34 | sandbergja | It seems to me that the automated test part of that document has been more or less ignored for 9 years... It is pretty unusual to see any code submitted _with_ automated tests. |
| 15:34 | kworstell-isl joined #evergreen | |
| 15:34 | Dyrcona | True. We have not been enforcing it. Commit messages explaining how to test have been acceptable, too. |
| 15:34 | redavis | there's a nuance differentiating needstest and needstestplan |
| 15:36 | Jaysal joined #evergreen | |
| 15:36 | Dyrcona | I'm not sure we were all that strict with the 2.8 and 2.9 releases mentioned in the document, but it's a start. |
| 15:36 | Jaysal joined #evergreen | |
| 15:36 | sandbergja | I'm hearing no strong objections to a needstestplan tag |
| 15:37 | redavis | +1 to needstestplan tag |
| 15:37 | sandbergja | And the page Dyrcona mentioned has a nice example of a test plan in a commit message |
| 15:37 | redavis | It seems that that page could also do with a nice update, but I can't volunteer for that. |
| 15:37 | abneiman | no, but I will point out that with one exception, the needstest tag is on bugs that haven't seen any action in 3+ years |
| 15:39 | * mmorgan | likes the idea of using Launchpad tags, but we need to make sure the tags are more like action items than reasons to kick the can down the road. |
| 15:39 | abneiman | this ^^^^ |
| 15:39 | redavis | abneiman, I can envision the needstestplan used on a consternating lp ticket during BSW where a tester might need more info to set up their test. "help me!" |
| 15:39 | abneiman | good point, redavis |
| 15:40 | jeffdavis | I will say I committed something today because abneiman asked for eyes on the 3.14 roadmap, and the fix had a test plan and no merge conflict. |
| 15:40 | abneiman | "The disambiguation of uses of Lauchpad tags: an Evergreen Conference Panel and / or drinking game" |
| 15:40 | redavis | lol! |
| 15:40 | abneiman | jeffdavis++ |
| 15:42 | mmorgan | +1 |
| 15:42 | smayo | sleary++ |
| 15:42 | abneiman | well, in that case, "needswork" and "needsrebase" should also be on that list |
| 15:42 | sandbergja | One etiquette question (which I think might be part of not kicking the can down the road): if a pullrequest gets a needstestplan applied, can anybody reply on launchpad with the test plan? Or would it have to tbe the original patch author. |
| 15:43 | mmorgan | I also like the idea of a bugs to look at list. |
| 15:43 | redavis | that's a cool idea. clarifying question - would needstestplan only go on pull requested tickets? |
| 15:43 | redavis | sandbergja++ |
| 15:43 | sleary | redavis I think so |
| 15:43 | redavis | sleary++ |
| 15:43 | shulabear | redavis++ |
| 15:44 | Dyrcona | sandbergja: In keeping the bazaar atmosphere, I think anyone could offer a test plan, though it would be better coming from the original patch author. |
| 15:44 | abneiman | yes, I was basically typing what Dyrcona just said re test plan |
| 15:44 | redavis | Dyrcona++ |
| 15:44 | mmorgan | I also think anyone could offer a test plan. |
| 15:44 | sandbergja | Dyrcona++ |
| 15:44 | shulabear | Dyrcona++ |
| 15:44 | abneiman | and +1 to the tag being only applicable to pr'd items |
| 15:45 | jeffdavis | IMO it should be an expectation that the author provides the test plan, but I agree anyone could do it. |
| 15:45 | abneiman | OK, so, I think we have a few items of agreement here: |
| 15:45 | redavis | And maybe worth noting that there might be people who excel at test plans but not other stuff and vice versaish. |
| 15:45 | shulabear | redavis++ |
| 15:45 | sandbergja | redavis: good point |
| 15:46 | sleary | I think we've occasionally gotten test plans from the first signoff person. |
| 15:46 | abneiman | 1) [someone] will create a needstestplan tag, which will be appplied to PR'd bugs if a test plan is lacking and needed; 2) we prefer if all PR'd bugs ALREADY have a test plan from the patch author, but if not, anyone can provide them; 3) mmorgan will update the LP stats monthly pull to include new uses of needswork, needsrebase, and needstestplan |
| 15:46 | mmorgan | Providing test plans could be a good fit for folks that use Evergreen and not so much write code. |
| 15:47 | abneiman | is that an accurate summary? does anyone want to take the first item as an action? |
| 15:47 | redavis | I do envision that this might be a nice entry point for community contribution as well. |
| 15:47 | sandbergja | I can make the tag right now |
| 15:48 | abneiman | sandbergja++ # the best kind of action items are the ones already done! |
| 15:48 | abneiman | ok, for the minutes: |
| 15:48 | redavis | sandbergja++ |
| 15:49 | abneiman | #info agreed upon the following: 1) sandbergja will create a needstestplan tag, which will be appplied to PR'd bugs if a test plan is lacking and needed; 2) we prefer if all PR'd bugs ALREADY have a test plan from the patch author, but if not, anyone can provide them; 3) mmorgan will update the LP stats monthly pull to include new uses of needswork, needsrebase, and needstestplan |
| 15:49 | terranm | It will need to be added to https://wiki.evergreen-ils.org/doku.php?id=dev:lp_tags as well - I can do that |
| 15:49 | abneiman | terranm++ |
| 15:49 | redavis | terranm++ |
| 15:49 | Dyrcona | I think there's actually and #agreed command for the bot. |
| 15:49 | abneiman | moving along, or any other discussion here? did we meet your goal of bitesize actionable items here, sandbergja? |
| 15:49 | Dyrcona | s/and/an/ |
| 15:49 | terranm | To make sure I'm right, needstestplan should be applied to tickets needing testing instructions, correct? (I had to step away, so trying to catch up)_ |
| 15:50 | sleary | yes |
| 15:50 | terranm | thx |
| 15:50 | sandbergja | I'm good! Thanks all! |
| 15:52 | abneiman | jeffdavis already took one of these on, so there are now TWO features committed for 3.14! |
| 15:52 | dluch | woot! |
| 15:52 | eeevil | side note, I'm happy that evergreen pi will be a spoooooky release right by Halloween :D |
| 15:52 | abneiman | and yes, I will give myself a related action |
| 15:52 | abneiman | #action abneiman will review existing EOLI PRs for test plans |
| 15:52 | phasefx_ | we could just keep versioning in the pattern of pi, but it wouldn't be rational |
| 15:52 | Dyrcona | eeevil: Should we do what tex does and increment 1 digit of pi for each future release? |
| 15:53 | Dyrcona | phasefx_++ |
| 15:54 | abneiman | (I'm just forging ahead, you nerds) there are 3 pullrequests and 2 signoffs on that 3.14 roadmap. Perhaps instead of a Last Minute Merge Melee, we can look at some of those earlier? |
| 15:54 | sleary | smayo we should put a ghost easter egg in there somewhere |
| 15:54 | eeevil | alliterative code names: pumpkin pi |
| 15:54 | redavis | There are couple of those that are still in or pre-testing. |
| 15:55 | abneiman | good point, redavis |
| 15:55 | sleary | yes, and a few not finished at all--although dark mode is getting pretty close! |
| 15:55 | redavis | Also, I'll go do a root around LP and see if there are some other things that should be added to the roadmap as well. |
| 15:56 | jeffdavis | I'm kind of scared to commit bug 2043142 because it's so big, even though folks here at Sitka have tested and signed off on it. Does a non-EOLI person need to commit it? |
| 15:56 | pinesol | Launchpad bug 2043142 in Evergreen "wishlist: Reports security improvements" [Wishlist,New] https://launchpad.net/bugs/2043142 |
| 15:56 | abneiman | AFAIK these are ready for review: |
| 15:56 | abneiman | Add PostgreSQL 16 support bug 2037656 – pullrequested & signedoff |
| 15:56 | pinesol | Launchpad bug 1902120 in Evergreen "Rename 'All parts' to 'Any part' in hold placement screen" [Wishlist,Confirmed] https://launchpad.net/bugs/1902120 |
| 15:56 | pinesol | Launchpad bug 2060734 in Evergreen "Various changes to the release process" [Undecided,Confirmed] https://launchpad.net/bugs/2060734 - Assigned to Jason Stephenson (jstephenson) |
| 15:56 | redavis | jeffdavis, that's preferable. |
| 15:57 | Dyrcona | Regarding Lp 2043142: Someone at CW MARS told me it likely would not affect us because we don't let library staff create templates. Otherwise, we would probably have tested it by now. |
| 15:57 | pinesol | Launchpad bug 2043142 in Evergreen "wishlist: Reports security improvements" [Wishlist,New] https://launchpad.net/bugs/2043142 |
| 15:57 | sandbergja | out of curiosity, does bug 2043142 have a test plan? |
| 15:58 | abneiman | sandbergja: there is a tech ref doc and an extensive commit message, but not necessarily a "do A and get B" test plan |
| 15:58 | Dyrcona | I have actually been looking at Lp 2060734, and I should go ever it again. I think I'd like to suggest/make some modifications. |
| 15:58 | pinesol | Launchpad bug 2060734 in Evergreen "Various changes to the release process" [Undecided,Confirmed] https://launchpad.net/bugs/2060734 - Assigned to Jason Stephenson (jstephenson) |
| 15:59 | abneiman | which, does point to a wrinkle that I of all people should've thought of, which is, what's the difference between a bugfix test plan and a feature test plan |
| 15:59 | Dyrcona | typos-- |
| 15:59 | sandbergja | Dyrcona++ # thanks for reviewing that |
| 15:59 | Dyrcona | sandbergja++ Thanks for taking it on. |
| 15:59 | sandbergja | abneiman: good question |
| 16:00 | Dyrcona | yeah, bug fix tests should be easier than new features, unless the feature is really simple. |
| 16:00 | abneiman | because with features, it's not as simple as "do A and get B" - which is why we (Equinox) try to include documentation and tech ref docs with new features, along with extensive commit messages |
| 16:01 | abneiman | but, if you all would rather us put out more formal test plans, I can work on that as well |
| 16:01 | rlefaive joined #evergreen | |
| 16:01 | abneiman | however, we are at the top of the hour so maybe "test plans for big features" could be a future topic |
| 16:02 | sandbergja | yeah, that might be where it gets trickier |
| 16:02 | dluch | +1 |
| 16:03 | redavis | also +1 |
| 16:03 | abneiman | #action discussion item for next meeting: test plans for big features |
| 16:03 | abneiman | that even might be a worthy hackaway topic |
| 16:03 | abneiman | anyway. |
| 16:04 | abneiman | anything else to discuss? Anything that I forgot? Any parting words of wisdom? |
| 16:04 | redavis | stay hydrated |
| 16:04 | eeevil | never start a land war in ... oh, nevermind |
| 16:04 | abneiman | #agree we're all gonna stay hydrated |
| 16:52 | Dyrcona | ugh.... timed events give different results depending on the time that one runs them, and expire_dates are not all at the same hour.... |
| 16:53 | Rogan | Quick note before I disappear for the weekend. Outreach is glad to share that all of the 2024 conference videos are now up on youtube https://www.youtube.com/watch?v=1CH8N2K_prQ&list=PLsktT5b82paVQ5JMpJG8hEuqxbX5wsnL2 |
| 16:53 | Dyrcona | Rogan++ |
| 16:56 | * Dyrcona | runs 'update actor.usr set expire_date = expire_date::date;' in the test database and decides to call it a week. |
| 17:01 | rlefaive joined #evergreen | |
| 17:28 | mmorgan left #evergreen | |
| 17:37 | rlefaive joined #evergreen |
| 09:01 | dguarrac joined #evergreen | |
| 09:02 | Dyrcona joined #evergreen | |
| 09:03 | mmorgan joined #evergreen | |
| 09:43 | Bmagic | Dyrcona: some tests mangle the database to a degree that makes subsequent runs fail |
| 09:59 | mantis joined #evergreen | |
| 10:18 | jvwoolf joined #evergreen | |
| 11:37 | Christineb joined #evergreen | |
| 11:52 | jihpringle joined #evergreen | |
| 11:54 | jvwoolf joined #evergreen | |
| 12:00 | jvwoolf joined #evergreen | |
| 13:15 | Dyrcona | Bmagic: I know that. I have been running eg_db_config to rebuild the database between each test run. |
| 13:17 | Dyrcona | The routine is: eg_db_config ...; osrf_control --start-all ; autogen.sh -u; make livecheck |
| 13:18 | Dyrcona | There's a --stop-all missing, but anyway. |
| 13:18 | Bmagic | sounds like it could be a PG compatibility thing |
| 13:19 | Dyrcona | Well, yeah, except that it is Pg 16 locally and remotely. Looks like when the Pg16 is remote 3 tests consistently fail. I could try with Pg 10 to see what happens. |
| 13:19 | Dyrcona | I'm looking at other stuff right now, though. |
| 13:21 | Dyrcona | I'll give it a run through on Pg 10...why not? |
| 13:24 | Bmagic | I like your atitude |
| 13:24 | Bmagic | the cut of your jib |
| 13:25 | Dyrcona | I also have not disabled jit. I'm going to see if that makes a difference on the remote Pg. |
| 13:45 | Dyrcona | Even more tests failed remotely on Pg 10. |
| 13:50 | Dyrcona | Yeahp. the same tests fail on Pg 16 when talking to a remote db server even with jit disabled. |
| 13:50 | Dyrcona | The same tests and more failed on Pg 10 when talking to a remote db server. |
| 14:00 | Dyrcona | Figured out why 18 kept failing: stuck lock file. |
| 14:02 | kworstell-isl joined #evergreen | |
| 14:18 | Dyrcona | So, it's looking like maybe it is an Ubuntu 24 thing. |
| 14:22 | Dyrcona | I know the first relies on autogen, which I ran.... |
| 15:04 | mantis joined #evergreen | |
| 15:20 | jvwoolf left #evergreen | |
| 15:42 | Dyrcona | I think I need to set up another vm with a different distro and just main on it to test the tests. The failures are inconsistent when I try to use one of my other vms to test. Pretty consistent with Ubuntu 24, so I suspect that's the issue, though it's weird it only happens when using a remotely hosted db. |
| 15:45 | Bmagic | that is pretty weird (and interesting) |
| 15:46 | Dyrcona | yeah. I've got an Ubuntu 22.04 vm that I've not finished setting up. I'm going to put the same branches on it and see what happens. |
| 15:53 | Dyrcona | Ugh! ejabberd on ubuntu 22..... |
| 16:55 | Dyrcona | Wow. It takes a long time to load the database over the Internet/VPN.... |
| 16:59 | mantis left #evergreen | |
| 17:07 | mmorgan left #evergreen | |
| 17:07 | pinesol | News from commits: LP2069098: get Angular tests compiling and passing again <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=6d99c8b8fba481f59fd24c3931b193d27e5a0a9a> |
| 17:07 | pinesol | News from commits: LP#2047442 Stamping upgrade script 1421 <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=133e67e839b2c4209ea962394d89043d97678b12> |
| 17:07 | pinesol | News from commits: LP2047442: Add URLs to copy tags export in SuperCat/unAPI <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=569cefb02987516049ada8dd22b0d9047da6e246> |
| 17:07 | pinesol | News from commits: LP2047442: Add Copy Tags to SuperCat/unAPI <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=3be9d3071a6108f67ef25dc447b7ccf27a5ad3dc> |
| 19:07 | pinesol | News from commits: LP#2026206: Treat empty or WS granularity as NULL <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=f0a419ca62950277439f2d5b65b432abc1ce3851> |
| 08:55 | Dyrcona joined #evergreen | |
| 10:03 | dguarrac joined #evergreen | |
| 10:45 | Christineb joined #evergreen | |
| 10:54 | Dyrcona | Yuck. Tests are failing... |
| 11:56 | jihpringle joined #evergreen | |
| 12:20 | collum joined #evergreen | |
| 14:22 | Dyrcona | The test failures are consistent. I guess I'll have to check on plain old master on a supported distro and Pg version.... I'm using Ubuntu 24 and Pg 16. |
| 15:15 | Dyrcona | So, another vm running Ubuntu 24.04 with the same code installed from git rather than a tarball, the live tests so far seem to be working. I wonder if the issue is the tarball or something peculiar to the vm... |
| 15:16 | Dyrcona | The other difference is the successful vm runs PG 16 itself, and the other talks to Pg 16 running on a separate server, but that should not matter. |
| 15:21 | Dyrcona | Yeah. all tests pass when it is installed from git. I guess I'll check the tarball for anomalies... |
| 15:27 | Dyrcona | ok. found an apache thing that might affect the cover uploader. |
| 15:37 | Dyrcona | Yeah. That fixed the cover uploader test, but live_t/03-overdue_circ.t, live_t/04-overdue_with_closed_dates.t, and live_t/05-pay_bills.t still fail. |
| 15:41 | Dyrcona | Looks like there's an insert error in the database. I'm clearing logs and rebuilding the db. |
| 15:56 | Dyrcona | Hm... diff -R ~/Evergreen ~/release/Evergreen-ILS-3.14.0/ doesn't show any significant differences... Nothing that I wouldn't expect. |
| 15:59 | Dyrcona | That should be a lowercase '-r', not '-R'. I should have copy/pasted. |
| 16:09 | Dyrcona | So, it is something in this VM's environment because the tests fail when installed from git, too. |
| 16:43 | Dyrcona | So... Install Pg 16 on the vm where the tests were failing and configure it to use that one instead of the db server, and the tests pass. That's it. That's all I changed. |
| 16:45 | Dyrcona | That *might* help explain some billing bugs, maybe.... If the tests consistently fail on a remote database. |
| 16:49 | Dyrcona | Except this one decided to fail: live_t/18-lp1592891_sip_standing_penalties.t. It was succeeding before. |
| 16:49 | * Dyrcona | calls it a day/week. |
| 10:51 | pinesol | News from commits: Forward-port 3.12.3-3.13.0 upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=735d3748a84b6d10e1a97bbdb292aeed739c12f9> |
| 12:03 | jihpringle joined #evergreen | |
| 12:10 | Dyrcona | Lp is flaky today. |
| 13:36 | Dyrcona | Oof! Figured out my opensrf problem. I forgot to update max_user_sessions in ejabberd.yml. I was setting up a different vm to test the code when I realized that was the problem. |
| 13:37 | redavis | Dyrcona++ |
| 13:56 | jvwoolf joined #evergreen | |
| 14:45 | jihpringle joined #evergreen |
| 15:06 | sandbergja | that's farther than we've gotten hahaha. Unsurprisingly, we have spent a lot of time on the ownership chapter |
| 15:07 | Dyrcona | yeah. if [ ! -f ../dojo.tgz ].... I just have to rename it. |
| 15:08 | Dyrcona | Yeah, the ownership seems tricky.. Just pass everything as a reference is my take away. :) |
| 15:08 | sandbergja | heh, seriously! |
| 15:09 | sandbergja | we did try an experiment this week in one of our rails apps, we rewrote a method in Rust, and then used ffi to let Ruby find the compiled dynamic library. All of our ruby tests still passed, it was pretty cool. Lots of glue code though :-( |
| 15:09 | berick | neat! |
| 15:10 | Dyrcona | Yeah. Sound neat. I was think of doing crazy stuff at some point like hooking up the LibreOffice API. |
| 15:10 | sandbergja | ooh, cool |
| 15:43 | Dyrcona | I suspect that this has more to do with using the latest main over anything sandbergja changed. |
| 15:43 | Dyrcona | Bleh: fatal: tag 'rel_3_14_0' already exists |
| 15:44 | Dyrcona | I'll have to start over and delete the tag. |
| 15:45 | sandbergja | Dyrcona: was that angular error from `ng build` or the tests? |
| 15:46 | Dyrcona | sandbergja: I'm not sure. Let me check the scroll back. |
| 15:46 | sandbergja | hmmmm... I wonder if it would be good to have a "clobber" option for the git tag, in case you have to re-run it |
| 15:46 | Dyrcona | The warnings and errors come after "Browser application bundle generation complete." |
| 15:47 | sandbergja | ah gotcha |
| 15:48 | Dyrcona | It doesn't say it is running tests, yet. I could try a manual build from git later to see what happens. |
| 15:48 | Dyrcona | I'm going to git clean -xfd to make sure. I think I did that earlier. |
| 15:48 | Bmagic | Dyrcona berick: I solved by downloading the file manually via web browser (theory is that the browser is more error tolerante compared to wget) - then put the resulting download file in ../release/dojo..... (exact path is mentinoed in the build bash script) - and if the file exists, then it doesn't waste time wgeting a fresh copy |
| 15:49 | Dyrcona | Bmagic: I just did more or less the same, but used rsync to pull both dojo.tgz from the server and compare them on my laptop before sending one to the vm where I'm playing around. |
| 15:12 | pinesol | Launchpad bug 1970791 in ejabberd (Ubuntu) "Starting ejabberd with systemctl "hangs" on Ubuntu 22.04 with apparmor profile" [Undecided,Confirmed] https://launchpad.net/bugs/1970791 |
| 15:15 | csharp_ | seems the trick to getting apparmor to care about disabling a profile is to create a symlink to the profile in /etc/apparmor.d/disabled, then do "aa-teardown; systemctl stop apparmor.service; systemctl start apparmor.service" |
| 15:16 | csharp_ | possible aa-teardown is not required, but a simple systemctl restart apparmor was ineffective for me |
| 15:19 | berick | related, i deployed the redis code to our testing cluster today. planning to continue apace. |
| 15:19 | berick | chicken, meet egg |
| 15:23 | csharp_ | berick++ |
| 15:53 | Dyrcona | csharp_: It's in the README how to disable apparmor of ejabberd on ubuntu. Only it does not work and is not needed on ubuntu 24.04. |
| 15:55 | Dyrcona | It's in the OpenSRF README: https://evergreen-ils.org/documentation/install/OpenSRF/README_3_3_0.html#_configure_the_ejabberd_server |
| 08:29 | mmorgan joined #evergreen | |
| 09:01 | dguarrac joined #evergreen | |
| 09:23 | Dyrcona joined #evergreen | |
| 09:24 | Dyrcona | Why is it that something tested in production over a week ago and worked, doesn't work when I actually want to use it? |
| 09:31 | Dyrcona | OK. It IS working. The first thing it tried to do ended up being invalid as far as the new process is concerned. |
| 09:31 | Dyrcona | The a/t event is not invalid, but it doesn't meet other criteria in the script. |
| 10:00 | kmlussier joined #evergreen | |
| 15:35 | Bmagic | with the understanding that we will have a follow-up LP to update the bits for ValKey when that's possible |
| 15:35 | berick | the bigger qestion for me is whether the functionality is complete for the various use cases |
| 15:36 | berick | which is to some extent aimed at the Equinox folks |
| 15:36 | Dyrcona | I've been using it since October on a test instance and haven't noticed anything that doesn't work. |
| 15:36 | Bmagic | We have it running on production, for a small library. Working just fine. Though, I'd feel more confident if it were on production for a larger library/consortium |
| 15:37 | berick | Bmagic: i'm deploying it as soon as it's merged to opensrf main |
| 15:37 | berick | (part of why i'm asking now, want to get going on it) |
| 15:43 | csharp_ | the thin ice we're skating on held! (this is fine dog) |
| 15:43 | * kmlussier | is hoping reddis isn't quite so painful. |
| 15:43 | Dyrcona | jeff csharp_: Yeah, that was my suggestion about the numbering. |
| 15:43 | Bmagic | We have a few systems adopting 3.13 over the next few months, I think we can give redis a whirl at the same time. I'd like to see it up and running in a larger environment as proof. I don't think any test environment can do what a production environment does |
| 15:44 | Dyrcona | kmlussier: I'm sorry, didn't mean to make light of it. All software is some kind of pain to use. |
| 15:44 | Dyrcona | berick has done a great job making the Redis integration just work. Very little configuration required. |
| 15:44 | Bmagic | agreed berick++ |
| 16:03 | Bmagic | terranm: looks good for me |
| 16:04 | redavis | terranm, perfect |
| 16:04 | sleary | terranm++ |
| 16:04 | terranm | Maybe we'll have the new circ/patron interfaces to test then? |
| 16:04 | LindaJansova | terranm++ |
| 16:04 | redavis | terranm++ |
| 16:04 | Bmagic | terranm++ |
| 10:31 | kworstell-isl joined #evergreen | |
| 10:41 | kworstell-isl joined #evergreen | |
| 11:25 | Christineb joined #evergreen | |
| 12:43 | mantis | When manually testing hold expiring soon notices, I have a test set up so that the hold that is captured has a shelf expiration two days from now, but when I run a script, nothing runs. Not sure if anyone has any ideas or tried testing this notice before. |
| 12:52 | berick | mantis: we use it w/ delay = '-2 days' and max_delay = '-1 day' |
| 12:53 | mantis | ah ok |
| 12:53 | mantis | I have a max delay of 2 days |
| 12:54 | Dyrcona | Negative for before, positive for after. |
| 12:54 | eeevil | mantis: think of delay and max_delay as the age of the timestamp in the field pointed at by delay_field (in fact, it's exactly that!) |
| 12:54 | eeevil | as in, the output of the age() function in the db |
| 12:55 | mantis | eevil: I also thought had to do something with the timestamp, but testing wasn't as fruitful |
| 12:55 | mantis | and when you edit the hold dates in the regular circ module, it doesn't give a timestamp option |
| 12:55 | mantis | berick: I gave that a shot and no dice |
| 12:56 | mantis | my shelf expire time is set to 6-12-2024 00:00:00-04 |
| 13:01 | Dyrcona | mantish: action_trigger.event_hook specifies a "core_type" for the event. This is the main IDL class used by the event. action_trigger.event_definition specifies a delay_field, delay, and max_delay. |
| 13:01 | Dyrcona | The delay and max_delay (if present) are added to the value of the delay_field of the object being processed to determine if an event should be generated for that object. |
| 13:03 | Dyrcona | To process things from the past, i.e. a 30-day overdue event, you would use positive values in delay and max_delay. For future things, like hold expires in 2 days, use negative values. So a delay of '-2 days' and a max_delay of '-1 days' would get everything between tomorrow and two days from now. |
| 13:11 | mantis | eevil++ |
| 13:11 | mantis | Dyrcona++ |
| 13:11 | Dyrcona | I'd check the action_trigger_filers.json in /openils/conf, or if you're using custom filters, make sure that file is there. |
| 13:11 | * Dyrcona | often forgets the filters when testing triggers. |
| 13:15 | Rogan | This is also sent out on the general dev lists but details for the 2024 Hack-A-Way are now available: https://wiki.evergreen-ils.org/doku.php?id=hack-a-way:hack-a-way-2024 |
| 13:48 | terranm joined #evergreen | |
| 13:54 | terranm | Claiming 1419 |
| 13:07 | Dyrcona | Well, I thought I'd have nothing to do today.... :) |
| 13:08 | redavis | The universe just trying to keep your mind active :D. |
| 13:08 | mantis joined #evergreen | |
| 13:08 | Dyrcona | At any rate, I did manage to the part I was testing to work, so I can recover some of the changed data from a table where I was backing up the data before the update. |
| 13:08 | Dyrcona | I've got 15 holds and 12 hold notifications to fix manually. So the damage isn't that bad. |
| 13:09 | redavis | Was this productive data? Oh, 15 hold and 12 notifications...that's a backstroke on a hot day in the shade. |
| 13:09 | redavis | lol, productive? |
| 12:03 | Christineb joined #evergreen | |
| 12:13 | Dyrcona | This is why I kept putting this off: there are a couple of places this could be fixed, and then there's the temptation to rip it up and implement something quite a bit different.... |
| 12:21 | Dyrcona | I suppose I could build a copy of the provider/account list and use grep to prevent duplicates. |
| 12:29 | Dyrcona | That works in my simple test. The list went from 180 to 29. |
| 12:47 | Dyrcona | heh. I typoed "Depulicate" as "Depuplicate" and my spell check suggested "Depopulate" with also works. :) |
| 12:48 | Dyrcona | OMG!!! "Deduplicate" not "Depulicate.".... |
| 12:48 | Dyrcona | @blame finger |
| 16:31 | Bmagic | completely deleting the value |
| 16:31 | abneiman | yes |
| 16:32 | berick | not really a shortcut, but an inability to move the curser to the character you want to edit |
| 16:32 | Bmagic | WTF, it didn't do that in a previous test |
| 16:32 | abneiman | anyway I think we have a fix |
| 16:32 | abneiman | stand by |
| 16:34 | sleary | I'm seeing the right arrow issue, but I have no problem saving an edited subfield. |
| 16:36 | berick | yeah, other fields save OK for me too |
| 16:36 | sleary | ... yeah, that's bad |
| 16:36 | berick | Bmagic: same :) |
| 16:37 | Bmagic | interesting. What a nuance. Thinking back to when I tested that branch, I edited marc records like crazy but I don't think I interacted with a larger subfield like that |
| 16:37 | abneiman | I'm not seeing it on our internal 3.13-rc, even in multi line fields |
| 16:37 | abneiman | weird |
| 16:37 | Bmagic | weird indeed. Imma install from git and see |
| 17:11 | jihpringle joined #evergreen | |
| 17:15 | berick | sleary: yes |
| 17:19 | * berick | sees the working branch |
| 17:20 | sleary | berick I think we have a fix, but eeevil just found a bunch of missing libraries on my dev server that are causing other problems |
| 17:20 | sleary | testing it on a different server now |
| 17:20 | eeevil | deploying to butternut for testing now... |
| 17:22 | berick | seems partly fixed. editing existing values is better. creating new ones is still having issues. |
| 17:24 | kworstell-isl joined #evergreen | |
| 17:24 | eeevil | berick: you mean the arrow key issue, or something else? |
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