| 10:29 |
Dyrcona |
What it's going to do now is to create the autorenew event and let the next --run-pending for that granularity pick it up. |
| 10:30 |
Dyrcona |
Since we have a batch kicking off right about now, I'll wait until about 45 minutes to try it on production. |
| 10:31 |
Dyrcona |
Looks like it's only 1 or 2 per day. |
| 10:32 |
Dyrcona |
On my test system where this has been running for a week, I don't have any since the new schedule started. |
| 10:32 |
Dyrcona |
Production has 2 that should have been picked up yesterday when this started, but it could be because of the weird due dates in the circulation. |
| 10:34 |
Dyrcona |
I wonder how run pending is going to cope with the constant flood of events being created on my other test vm? |
| 10:40 |
Dyrcona |
Looks like it's only working on those that were pending when I started it, which is what I expected. |
| 09:51 |
Dyrcona |
Perhaps I'll experiment with Rust again in the coming weeks. |
| 09:52 |
berick |
that reminds me I keep meaning to send a "any interest in rust working group" email to the dev list |
| 09:53 |
mantis |
kicking off our pingest; we'll see how long it takes :-X |
| 09:57 |
Dyrcona |
mantis: You can experiment with the --batch option sizes. In my test enviroment, I find going with 1000 runs pretty fast. |
| 09:57 |
mantis |
I have a batch of 10000 for now |
| 09:57 |
Bmagic |
mantis: if you use the linux command "time" you can let the computer tell you how long it takes. You would execute pingest.pl like you would normally, but put the word "time" in front. Like "time pingest.pl --switches....." |
| 10:07 |
mantis |
do you use a particular "max-child" flag? |
| 10:11 |
JBoyer |
If memory serves that's how many active simultaneous processes will be running, so the best value depends on your hardware. On a test system you could use the number of processors in the system to go as fast as possible, but should use a lower count for prod, depending on the use it sees. |
| 10:11 |
Dyrcona |
No, I usually go with 8, but it depends on how many cores your db server and/or utility machine have, assuming that they're separate. |
| 10:11 |
JBoyer |
(meaning the number of cpus on your database, not necessarily the machine running it.) |
| 10:15 |
Dyrcona |
Also, if you don't skip the browse ingest, there will be 1 child process doing the browse ingest on all of the records because the browse ingest can't be done in parallel. You eventually run into a deadlock(?) when two processes try to update the same record. (Mark Twain seems to be a common one for us.) |
| 10:45 |
Bmagic |
that's right |
| 10:45 |
|
Llewellyn joined #evergreen |
| 10:47 |
Dyrcona |
Do we actually send it plain text though? I thought it get MD5'd before it got to the server? I guess that's only after it arrives, huh. |
| 10:47 |
Llewellyn |
I did a test on it yesterday, I added a logger statement to Actor.pm and was able to capture incoming passwords. |
| 10:47 |
berick |
it's plain text via the API, salted+hashed in the db |
| 10:47 |
Bmagic |
I'll let Llewellyn take that one |
| 10:47 |
Dyrcona |
Llewellyn++ |
| 10:59 |
Dyrcona |
If you got a MITM, you got bigger problems. |
| 10:59 |
Bmagic |
Llewellyn: correct, but* the man in the middle can just use the MD5 version of the password (just like the client software did) and they'd login no problem |
| 10:59 |
Llewellyn |
hmmm |
| 10:59 |
sleary |
^^ SSO branch with a PR ready for people to test. |
| 10:59 |
Bmagic |
sleary++ |
| 11:01 |
Bmagic |
Llewellyn: in other words: the benefit is nill, with the exception being: if the patron uses the same password in other places, the attacker would be able to access their account in the other places now that they had the raw password. Whereas, the md5 version wouldn't work in other places |
| 11:01 |
Llewellyn |
better than nothing imo |
| 12:07 |
dguarrac |
Dyrcona: Would a STAFF_CHR penalty applied just at that org unit work? |
| 12:07 |
dguarrac |
I don't actually know how the H in the CHR works. |
| 12:08 |
Dyrcona |
dguarrac: Yeah, that probably will work. |
| 12:08 |
Dyrcona |
I can test it. |
| 12:08 |
* Dyrcona |
overlooks penalties sometimes. |
| 12:09 |
Dyrcona |
dguarrac++ That works. |
| 12:09 |
dguarrac |
woohoo! |
| 13:05 |
terranm |
If any seasoned developers are available for new devs today at 3pm eastern, I'd love some guidance on this bug - https://bugs.launchpad.net/evergreen/+bug/2107209 |
| 13:05 |
pinesol |
Launchpad bug 2107209 in Evergreen "Author links break in several places when MARC 100 subfields are present" [High,New] |
| 13:59 |
|
terranm joined #evergreen |
| 14:21 |
pinesol |
News from commits: LP2106780 Adjust karma.conf.js for concurrency, logging, timeouts <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fd5bdc1da02a345394a31c0946ed7336671d1b40> |
| 14:21 |
pinesol |
News from commits: LP2106780 IDL service, Item attr unit test fixes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b39e987eded3dce5921059d2c910fcdb1930d480> |
| 14:21 |
pinesol |
News from commits: LP2106780 Unit test updates for 3.15 <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=be56cbc0adc5e6ed799d0eecbafc0906fd23ab8a> |
| 14:54 |
|
collum joined #evergreen |
| 14:58 |
terranm |
NVM I just figured it out, and it requires the change of a single character, lol |
| 15:02 |
csharp_ |
terranm++ |
| 11:32 |
ianskelskey |
What do you mean? |
| 11:41 |
csharp_ |
ianskelskey: not sure what import method you're doing but there are match sets and merge profiles within vandelay that the UI import and some scripty tools use |
| 11:41 |
csharp_ |
may not be relevant in your case - just theorizing |
| 11:44 |
ianskelskey |
I'm just gathering any information I can before I start looking at code/custom solutions so I appreciate it. I'll run it by our cataloger and see what she says. |
| 11:51 |
ianskelskey |
It looks like the match set is Hoopla and the merge profile is full overlay if that means anything |
| 11:54 |
ianskelskey |
We've been running a test with 100 records and its been running for over 2 hours so far with about 65 complete. |
| 11:56 |
jihpringle |
ianskelskey: it might be worth looking at what your Hoopla match set is matching on compared to other match sets you have |
| 11:58 |
collum |
ianskelskey: ^ In the MARC Batch Import/Export screen there's a tab for Record Match Sets. You can find how Hoopla is defined through that interface. |
| 11:59 |
ianskelskey |
Is there something in particular I should look for there. I was in that screen recently poking around. |
| 11:48 |
sleary |
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sleary/LP2106666-color-mode-with-windows7-support-rebase |
| 11:48 |
Bmagic |
holy smokes that was fast |
| 11:49 |
sleary |
I know these stylesheets too well :( |
| 12:10 |
phasefx |
Bmagic: abneiman: I wrote something simpler and more targeted than pg_diff, and nothing is actually missing. Counts for rows in each table are off by 1 with the test data; going to double-check that |
| 12:13 |
Bmagic |
sleary: maybe I should've just pushed to the real branches rather than making signoff branches |
| 12:17 |
Bmagic |
ok, it's on main now |
| 12:17 |
sleary |
Bmagic++ |
| 12:17 |
sleary |
thanks for testing that |
| 12:20 |
Bmagic |
no problem, I'm doing 3.14 and 3.15 too, and I'll post on LP in a minute |
| 12:22 |
abneiman |
Bmagic++ sleary++ |
| 12:28 |
Dyrcona |
Windows 7, really? |
| 12:38 |
|
jihpringle joined #evergreen |
| 12:40 |
|
smayo joined #evergreen |
| 12:42 |
jeffdavis |
sleary++ |
| 12:45 |
phasefx |
Bmagic: abneiman: and my off-by-1 rows came from the database snapshot capturing some of my testing. I think we're good! |
| 12:45 |
abneiman |
@phasefx++ |
| 12:45 |
pinesol |
abneiman: git diff origin/hamster |
| 12:46 |
abneiman |
phasefx++ |
| 12:47 |
phasefx |
abneiman: Bmagic: I celebrated too soon. email.login.issuer and email.login.digits exist in an upgraded db but not a pristine one |
| 12:47 |
* abneiman |
has no such restraint |
| 12:47 |
abneiman |
phasefx: s'ok there's still time to work stuff out |
| 12:48 |
phasefx |
I'm going to redo the snapshot, make sure I rule out changes introduced from testing |
| 12:48 |
Bmagic |
what you're doing is pretty close to the logic that make_concerto_from_evergreen_db.pl does |
| 12:48 |
phasefx |
but there are definitely things off |
| 12:49 |
phasefx |
circ.void_overdue_on_longoverdue in a pristine db, but not in an upgraded one |
| 12:49 |
Bmagic |
do you run this type of test for each release? And this one is giving different results from previous releases? |
| 12:51 |
phasefx |
who me? no, I haven't been doing this previously, though I played with the idea a long time ago |
| 13:02 |
|
Dyrcona joined #evergreen |
| 13:05 |
csharp_ |
@dunno add user opensr does not exist |
| 14:01 |
pinesol |
Rogan knows too much about action triggers. |
| 14:39 |
abneiman |
probably true, tbh |
| 14:46 |
Dyrcona |
:) |
| 14:47 |
Dyrcona |
I know more about it than I did yesterday, mostly by trying things on a test system and seeing what happens. |
| 15:37 |
Dyrcona |
I picked the wrong day to test of a change in a script... |
| 15:37 |
Dyrcona |
19,756 events and rising. |
| 17:11 |
|
jvwoolf1 joined #evergreen |
| 17:11 |
|
mmorgan left #evergreen |
| 12:34 |
mantis |
Bmagic++ |
| 12:35 |
Bmagic |
let us know if you have any questions! |
| 12:37 |
|
jvwoolf joined #evergreen |
| 12:38 |
mantis |
Bmagic: definitely for sure |
| 12:39 |
mantis |
I would like to start these on test servers during off hours next week; do you have any best practice tips? We haven't been able to perform a successful parallel ingest before |
| 12:39 |
mantis |
I think we did try but there was issue with either storage or just having too many records and a timeout happens |
| 12:39 |
mantis |
not 100% sure on that but it definitely had something to do with the size of our collection |
| 12:40 |
Bmagic |
what's the total number of bibs? |
| 12:44 |
mantis |
we're somewhere in the 600k area - at least that's what I'm seeing when running counts on IDs |
| 12:45 |
Bmagic |
the main issue we've run into is running the reingest at the same time as a backup. That usually results in a full disk situation. So if your backups are running at night, you want your reingest to finish (or a portion thereof) before the backup starts |
| 12:49 |
mantis |
Bmagic++ |
| 12:49 |
Dyrcona |
mantis: I run it on 1.8 million bibs all the time. |
| 12:49 |
mantis |
Dyrcona: how often? |
| 12:50 |
Dyrcona |
At least monthly on my test systems. |
| 12:50 |
Dyrcona |
it is generally only necessary after database upgrades. |
| 12:51 |
Dyrcona |
Well, upgrades that affect search. |
| 12:52 |
mantis |
what's the difference between parallel and queued? parallel does it in concurrent batches? |
| 13:04 |
Dyrcona |
The purpose of ingest is to make sure that the search indexes are up to date with your records. This should be taken care of normally, but under some circumstances, they get out of whack. |
| 13:04 |
mantis |
why do you run ingests monthly? |
| 13:05 |
Dyrcona |
I copy a dump of production data to a local server. I load that dump into a database. I make a copy of that database which is updated to a more recent version of Evergreen. That gets dumped again, and reloaded as yet a third database. |
| 13:06 |
Dyrcona |
This third database is connected to a test vm running that release of Evergreen. I run a pingest on that database to make sure that search works. |
| 13:07 |
Dyrcona |
I find it is often more convenient to just do a pingest of the whole thing rather than do the SQL bits included in the DB upgrades' comments. |
| 13:08 |
Dyrcona |
In production, we pretty much never do an ingest, unless we added a new search index (rare) or just did a version upgrade (probably less rare). |
| 13:08 |
mantis |
ah I see |
| 13:08 |
mantis |
so it's just a preference |
| 13:09 |
Dyrcona |
it might fix your KPAC issues depending on the problem. I don't know enough about the particulars to really say. |
| 13:09 |
Bmagic |
mantis: he's reingesting on a test machine. Which can be done willy nilly without concern about uptime and production nightly backup interference. |
| 13:10 |
Bmagic |
It's a good idea to get familiar with the procedure on a test machine though! |
| 13:10 |
Bmagic |
You can use the expierence that you gain from running the procedure on a test machine to see how long it takes, which should translate roughly to the time it will take on production (if your test machine is close in size and shape) |
| 13:10 |
Dyrcona |
If the Evergreen upgrade affects search indexes, then doing some sort of ingest is pretty much mandatory, or search will not reflect the changes in the upgrade. That's why I do the ingest on the database that has been upgraded to a more recent version of Evergreen than the original data. |
| 13:12 |
Dyrcona |
Not knowing the history of your database and upgrades, I can't say if an ingest will solve your KPAC search issues or not. |
| 13:13 |
mantis |
I can always give it a try anyway! |
| 13:13 |
mantis |
thanks to you both |
| 13:13 |
Bmagic |
one way to know: copy your production database to a test machine, ensure that you're having the same issue on your test machine as you do on production. Then run your reingest on the test machine, and see if it makes a difference |
| 13:14 |
|
redavis joined #evergreen |
| 13:17 |
Dyrcona |
You should be able to do either type of ingest while users are using Evergreen. They won't notice for the most part. |
| 13:17 |
Dyrcona |
We used to kick a pingest off after the upgrade and start services so users could use Evergreen while the ingest was chugging away. |
| 10:21 |
abneiman |
(that's what MY brain feels like, anyway) |
| 10:22 |
abneiman |
just wanna nap in a tree all day and eat some plants |
| 10:22 |
redavis |
coked-up-squirrels and barbiturate-sloths are siblings. possibly twins. possibly identical twins. |
| 10:23 |
Dyrcona |
Anyway, I think I've had success in splitting up our daily courtesy/autorenewal process. I was able to test the filters Monday and they work! |
| 10:23 |
redavis |
Dyrcona++ |
| 10:24 |
Dyrcona |
redavis: I think the JEDI is just a JSON representation of the EDI. |
| 10:24 |
Dyrcona |
Same data in a different format. |
| 10:26 |
Dyrcona |
The JEDI was (is?) used internally by Evergreen and not sent to vendors. |
| 10:26 |
Dyrcona |
I don't remember if the new EDI process uses it or not. |
| 10:27 |
redavis |
++ |
| 10:27 |
Dyrcona |
Ha! We're supposed to do this Phishing security training/test for insurance purposes, and the invitation email ended up in my spam. Yay, Google! |
| 10:27 |
redavis |
berick, do you know? |
| 10:28 |
Dyrcona |
berick should know for sure. |
| 10:29 |
berick |
yeah JEDI is the internal representation of the EDI. it's mainly just a snapshot for debugging |
| 12:34 |
|
jihpringle joined #evergreen |
| 13:09 |
phasefx |
--load-concerto-enhanced in main (and 3.15-rc) gave me a duplicate key error on permission.grp_tree |
| 13:10 |
Bmagic |
ah! I got that too, the other day, probably needs regenerated now |
| 13:12 |
Bmagic |
for feedback fest, I got enhanced concerto loaded on the test machine, but encountered that issue and figured it was due to all of the patches I'd loaded onto the source code. But now that they've been merged, it's time to regenerate the enhanced concerto to bring it up to current |
| 13:13 |
phasefx |
@Bmagic++ |
| 13:13 |
pinesol |
phasefx: uh huh.. please tell me more about that |
| 13:13 |
phasefx |
urg, my IRC habits are fading away |
| 13:54 |
redavis |
But it's not happening throughout the entirety of the upgraded libraries? |
| 13:56 |
jihpringle25 |
no we've only had reports from 6 libraries and for some of them some computer are affected and others are normal |
| 13:57 |
jihpringle25 |
I'm thinking something browser related (Chrome) but so far we haven't been able to pinpoint anything |
| 13:58 |
redavis |
++. is their a possibility of having them test it using Firefox? |
| 13:58 |
mmorgan |
jihpringle25: Does sound browser related. Try a different browser on an affected computer? Try disabling extensions, Incognito mode? |
| 13:58 |
redavis |
or something else? |
| 14:00 |
jihpringle25 |
at least one library tried it in Edge and it looked normal |
| 15:12 |
shulabramble |
#topic Bmagic will look into transferring POeditor account ownership to a generic EG account |
| 15:12 |
Bmagic |
I did some poking around |
| 15:13 |
Bmagic |
defer for next time |
| 15:13 |
shulabramble |
#action Bmagic will look into transferring POeditor account ownership to a generic EG account |
| 15:13 |
shulabramble |
#topic sleary and sandbergja will report progress on test writing wiki pages next month |
| 15:13 |
sleary |
still in progress, actual progress being made, still not done |
| 15:13 |
shulabramble |
#action sleary and sandbergja will report progress on test writing wiki pages next month |
| 15:14 |
shulabramble |
#topic abneiman will discuss moving the developer's meeting with shulabramble and poll the community |
| 15:14 |
abneiman |
we discussed this! |
| 15:14 |
abneiman |
and we will table this till later since as of now, Shula is the dev meeting leader & without av computer things |
| 15:15 |
abneiman |
so, this can be struck for now |
| 15:16 |
abneiman |
shulabramble++ |
| 15:17 |
shulabramble |
#topic Dyrcona will look at https://bugs.launchpad.net/evergreen/+bug/2073561 |
| 15:17 |
pinesol |
Launchpad bug 2073561 in Evergreen 3.14 "Incorrect content in the config.coded_value_map after applying the upgrade script from 3.12.3 to 3.13.0" [High,Fix committed] |
| 15:17 |
shulabramble |
Okay, fix committed! |
| 15:17 |
shulabramble |
Dyrcona++ |
| 15:17 |
shulabramble |
#topic Updates |
| 15:18 |
shulabramble |
#topic Evergreen |
| 15:18 |
shulabramble |
#topic Thanks to Terran et al. for a very successful Feedback Fest! FBF stats |
| 15:19 |
shulabramble |
#topic 3.15-rc built this morning (thank you Galen!) and is being tested this afternoon, with release announcement & merge un-pause expected later today |
| 15:19 |
shulabramble |
#topic No merges to 3.15 branch unless they are critical bugfixes, lint fixes, or documentation |
| 15:19 |
terranm |
Yay Feedback Festers! |
| 15:19 |
terranm |
Festers doesn't sound nice |
| 15:19 |
shulabramble |
#topic 3.15.0 is slated for release next Wednesday 16th, as is 3.14.5 and 3.13.10 |
| 15:20 |
abneiman |
terranm++ feedback-festers++ |
| 15:20 |
shulabramble |
gmcharlt++ abneiman++ |
| 15:20 |
collum |
terranm++ |
| 15:20 |
terranm |
And Bmagic++ and JBoyer++ for building test servers! |
| 15:20 |
shulabramble |
bmagic++ jboyer++ |
| 15:20 |
abneiman |
do we want to talk about point releases next week? |
| 15:20 |
redavis |
Bmagic++ JBoyer++ |
| 08:45 |
|
mmorgan joined #evergreen |
| 09:02 |
|
Dyrcona joined #evergreen |
| 09:04 |
|
dguarrac joined #evergreen |
| 09:36 |
Dyrcona |
My custom a/t filters with a subquery to limit by patron home_ou for autorenewals/courtesy notices seems to work. I got only the libraries expected in my first test run. |
| 09:37 |
Dyrcona |
The a/t runner only ran for about 16 minutes (15m54s according to time). |
| 09:37 |
|
collum joined #evergreen |
| 09:37 |
Dyrcona |
This looks promising for a move to production soon. |
| 09:56 |
Dyrcona |
It should probably only work when a granularity is specified.... Not sure. |
| 10:08 |
Dyrcona |
Lp 2106399 |
| 10:09 |
pinesol |
Launchpad bug 2106399 in Evergreen "Allow override of delay and max_delay from action_trigger_runner.pl command line" [Wishlist,New] https://launchpad.net/bugs/2106399 - Assigned to Jason Stephenson (jstephenson) |
| 10:10 |
Dyrcona |
Wild: I ran the same test on Pg 10, and it took 35 minutes. The 16 minutes was on Pg 17. The Pg 10 database is optimized to use about 80% of the hardware whereas Pg 17 is using default optimization. |
| 10:13 |
Dyrcona |
Same data and same results. It really makes sense to upgrade PostgreSQL just for the better performance. |
| 10:14 |
* Dyrcona |
starts the next test on Pg 10 to see how long it takes. |
| 10:55 |
|
Christineb joined #evergreen |
| 11:11 |
|
jihpringle joined #evergreen |
| 11:28 |
|
redavis joined #evergreen |
| 11:02 |
redavis |
berick, does KCLS use Ingram as a vendor, and if so, have y'all implemented ASN receiving for it? |
| 11:37 |
jmurray-isl |
Speaking of geoblocking, does anyone know of any geoblocking services that allow free automated downloads of country IP lists? |
| 11:38 |
jmurray-isl |
Emphasis on free. ;) |
| 11:42 |
csharp_ |
jmurray-isl: I was able to create a personal account with MaxMind and that allows me free downloads |
| 11:43 |
csharp_ |
and we've automated that |
| 11:44 |
csharp_ |
# m h dom mon dow user command |
| 11:44 |
csharp_ |
47 6 * * 3 root test -x /usr/bin/geoipupdate && grep -q '^AccountID .*[^0]\+' /etc/GeoIP.conf && test ! -d /run/systemd/system && /usr/bin/geoipupdate |
| 11:44 |
jmurray-isl |
csharp_++ |
| 11:45 |
csharp_ |
we have geoip-bin, geoip-database and geoipupdate installed (and libgeoip1 which is probably an implied dependency) (on Ubuntu 22.04) |
| 11:46 |
csharp_ |
our iptables lines look like this: iptables -I INPUT -m geoip --src-cc OM -j DROP where "OM" is the country code |
| 13:59 |
Dyrcona |
If I can't get this filter to work, then my other option is granularities with multiple events owned by each library or system. |
| 14:00 |
Dyrcona |
That won't do exactly what I want, however, because that will group the notices by checkout library, and I want to group them by patron home library because the final product is grouped by patron. |
| 14:01 |
Dyrcona |
So, using granularities could lead to multiple notices per day per patron, and I'm trying to avoid that. If anything, I expect that filter to be slow. |
| 14:01 |
Dyrcona |
Now, I just have to write the code to test the filter. |
| 14:04 |
|
jvwoolf joined #evergreen |
| 14:09 |
jvwoolf |
terranm: Is the reporter running on terran-main? |
| 14:11 |
|
mmorgan1 joined #evergreen |
| 09:18 |
Bmagic |
csharp_++ # It’s not the destination that matters, it’s the journey. |
| 09:19 |
Bmagic |
mantis: it's usually 6 months for our libraries, but 1 week is fine too if that's what they want |
| 09:24 |
|
Dyrcona joined #evergreen |
| 09:25 |
mantis |
Bmagic: thank you I'm just doing it to test and wasn't sure if the values were valid for it to work |
| 09:25 |
mantis |
I don't see a week example so figure I ask |
| 09:25 |
mantis |
Bmagic++ |
| 09:26 |
|
sandbergja joined #evergreen |
| 09:29 |
Dyrcona |
mantis: https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-INTERVAL-INPUT |
| 09:29 |
Bmagic |
mantis: that value can be anything as far as testing goes. I don't think that 1 week will break Evergreen's logic |
| 09:29 |
mantis |
Dyrcona++ |
| 09:31 |
Dyrcona |
Any valid interval at all should work. Some make more sense than others. Anything less than a day would likely make no sense for age hold protection. |
| 09:33 |
Dyrcona |
Negative intervals are also a bad idea as it would have the opposite of the desired effect, unless the code does an abs() somewhere. |
| 11:21 |
csharp_ |
that's okay, we'll all live |
| 11:22 |
Dyrcona |
yeahp. There were a couple of times that I wished I could force push over some things. |
| 11:29 |
sleary |
sometimes working out in the open is a bit too out in the open, and that's okay |
| 11:30 |
csharp_ |
JBoyer: curious about bug 2097308 - I was planning to test on a VM later and then realized how very EOL buster is and I'm wondering if this should be a site-specific thing rather than an EG commit? |
| 11:31 |
pinesol |
Launchpad bug 2097308 in Evergreen "Fix Debian Buster Install" [Low,New] https://launchpad.net/bugs/2097308 |
| 11:31 |
csharp_ |
open to being persuaded if buster is in heavy use |
| 11:36 |
|
Christineb joined #evergreen |
| 13:06 |
sleary |
awesome! |
| 13:06 |
sleary |
I'm going to go through the IDL at some point, but I can't do that today |
| 13:07 |
Bmagic |
sleary++ |
| 13:14 |
csharp_ |
mantis++ |
| 13:14 |
csharp_ |
JBoyer: sounds sane - I'll test it and push if it passes muster |
| 13:14 |
JBoyer |
csharp_++ |
| 13:14 |
csharp_ |
(sure it does, but, you know) |
| 13:24 |
csharp_ |
it took me way too long to find https://cdimage.debian.org/cdimage/archive/10.13.0/amd64/iso-cd/debian-10.13.0-amd64-netinst.iso |
| 13:41 |
csharp_ |
bug confirmed, now for the fix |
| 13:53 |
csharp_ |
argh - clashing with bug 2097313 |
| 13:53 |
pinesol |
Launchpad bug 2097313 in Evergreen "Install pgdg signing key in preferred location" [Low,Fix committed] https://launchpad.net/bugs/2097313 |
| 13:54 |
csharp_ |
it's no biggie though, just means I need to re-test |
| 14:06 |
csharp_ |
ok, all good |
| 14:07 |
pinesol |
News from commits: LP2097308: Use PostgreSQL apt archive when necessary <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=19cee157080257422acc41dbe2bd78e438246ccd> |
| 14:18 |
abneiman |
hi all, has anyone gotten sandbergja 's files up on lupin (10:30am ET upthread)? If not I can poke someone over here |
| 14:36 |
Dyrcona |
abneiman: I don't think anyone has. I can do it in a minute, though. |
| 15:26 |
Bmagic |
sleary: that translation patch is up on https://bugsquash.mobiusconsortium.org/eg2/cs-CZ/staff/splash but I'm not so sure I have it setup correctly because all of the cards are still in English |
| 15:27 |
sleary |
Bmagic cards on the splash page are a whole separate problem; this is about grids in the admin pages. My wifi died just as I was about to point out that I added a second commit to that branch; did you catch it? |
| 15:27 |
sandbergja |
abneiman++ gmcharlt++ Dyrcona++ |
| 15:29 |
sleary |
Bmagic three URLs to test: https://bugsquash.mobiusconsortium.org/eg2/cs-CZ/staff/admin/server/authority/control_set https://bugsquash.mobiusconsortium.org/eg2/cs-CZ/staff/cat/vandelay/match_sets https://bugsquash.mobiusconsortium.org/eg2/cs-CZ/staff/admin/booking/resource |
| 15:30 |
sleary |
Controlling Authority Fields, Match Set ID, and Overbook, respectively |
| 15:37 |
pinesol |
News from commits: LP2106057 Do not show open_in_new icon on images <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=d945ab98027598b638b842df2ef9d01410c0a821> |
| 15:47 |
|
jihpringle joined #evergreen |
| 15:47 |
Bmagic |
sleary: those look translated to me |
| 15:48 |
sleary |
\o/ |
| 15:49 |
Bmagic |
(pach applied), I suppose other test servers don't have those words translated... butternut. Just tried, that server doesn't have the additional languages installed. |
| 15:49 |
Bmagic |
maybe if I reverted the patch, I wouldn't see czech language on those pages? |
| 15:51 |
|
jihpringle22 joined #evergreen |
| 15:57 |
sleary |
Bmagic probably. (Sorry I can't look; I'm on the thinnest of data connections atm) |
| 17:08 |
pinesol |
News from commits: LP2085844 Scroll focused combobox option into view <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=4592b8d034178759a81fcf26f5d2fabd513a4bfc> |
| 17:16 |
|
mmorgan left #evergreen |
| 18:04 |
|
jihpringle joined #evergreen |
| 19:08 |
pinesol |
News from commits: LP2074112 follow-up: fix two unit tests <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=38b073a3464b5cdee430dfb85d4eb80092c77ff2> |
| 19:43 |
|
sandbergja joined #evergreen |
| 21:07 |
sleary |
sandbergja++ #unit tests |
| 21:07 |
sleary |
sandbergja we will have IDL and dialog test fixes shortly |
| 21:10 |
sandbergja |
sleary++ |
| 09:55 |
jeff |
I'll take a look at that branch again. |
| 09:58 |
jeff |
guessing there will be more interest now. i think Stompro and I have been suggesting this for a while, but I know a lot of people opted to go with different solutions in recent years. |
| 10:00 |
jeff |
since Stompro and I are pretty much set with how we're doing things, I'd be interested in hearing if any others are interested in collaborating on something that will have wider applicability. It's always a challenge to design something that will work for others if others aren't interested in having those conversations yet. :-) |
| 10:23 |
csharp_ |
if there are ways to test without subscribing to things, that makes it easier, but that's a common situation with anything touching 3rd party stuff |
| 10:31 |
jeff |
agreed! and yes, for something like this testing can be accomplished a few different ways, either low cost/effort or no cost (relying on the existing test accounts of others). |
| 10:57 |
|
sandbergja joined #evergreen |
| 11:01 |
|
Christineb joined #evergreen |
| 11:36 |
|
jihpringle joined #evergreen |
| 16:27 |
Bmagic |
Maybe not applicable to this question exactly |
| 16:33 |
Dyrcona |
I suspect that the filter may be applied before the environment is fetched, so this may not work. It's hard to tell from the code sometimes. |
| 16:34 |
Dyrcona |
Yes, I'm pretty sure that the filter is applied before the environment is applied. |
| 16:36 |
Dyrcona |
Well, I'll try with a sample group tomorrow on a test system to see what happens, but I'm pretty sure it won't work. I'll be pleased to be proven wrong, though. |
| 16:37 |
Dyrcona |
Actually, I'm not even sure how I'd put it in the filter itself. It seemed obvious, but now that I think about it.... It's just a JSON query, though... bet I'd could join on usr and do it that way... |
| 16:38 |
Dyrcona |
This will be interesting to see if I can make it work. |
| 16:38 |
Dyrcona |
Probably need a subquery. |
| 10:24 |
Dyrcona |
Bmagjc: Subscribing via email works. I did it last week when switching to my cwmars email. |
| 10:25 |
Dyrcona |
<list>-request list.evergreen-ils.org with Subject: subscribe |
| 10:43 |
|
jihpringle joined #evergreen |
| 10:44 |
jeff |
Dyrcona: usually dev/test instances only, no current production instances. not for any specific reason, just not something we're currently doing. |
| 10:49 |
Dyrcona |
jeff: Thanks for the info. |
| 10:55 |
|
sandbergja joined #evergreen |
| 10:57 |
Dyrcona |
i wonder if I could AI to figure this out more quickly. I'm trying to split 194 locations up into 12 groups where the average number of notifications is around 1,150 per group, but the max should probably also not be over 3,220 or so. |
| 11:32 |
Bmagic |
Drycona++ # thanks for the subscribing stuff |
| 11:33 |
|
jihpringle joined #evergreen |
| 11:34 |
sandbergja |
sleary++ # thanks for linting! |
| 11:36 |
sleary |
sandbergja++ # thanks for staying on top of the tests. We will look at the IDL stuff, but it might be another day or two; phasefx and I are both committed elsewhere for most of today |
| 11:48 |
|
Christineb joined #evergreen |
| 11:55 |
sandbergja |
sleary++ |
| 11:55 |
sandbergja |
phasefx++ |
| 11:56 |
sandbergja |
I will take a look at the live tests, I have a sneaking suspicion that one of them is my fault. :-D |
| 13:04 |
Dyrcona |
My numbers don't add up. One spreadsheet says I should have an average 1,143 notices per group (12 groups). The other spreadsheet comes out closer to 1,200 notices per group. |
| 13:11 |
Dyrcona |
Average total number of notices per day and average per day by home ou don't add up. The former is 13,644 and the latter 14,402. |
| 13:11 |
Dyrcona |
Granted, the first data range includes an extra month or so of data. |
| 14:13 |
Dyrcona |
Although, it would make sense to run fewer notifications in the middle of the day and more at night/early morning... |
| 14:13 |
Dyrcona |
I can just reorder the groups and all is good. :) |
| 14:25 |
Dyrcona |
Not that simple, either. |
| 14:32 |
pinesol |
News from commits: LP2019430 follow-up: fix failing live test <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=1034f00474d5ae475c7a050949418ee01738c7c0> |
| 15:05 |
csharp_ |
@band add ABSOLUTE ORG UNIT |
| 15:05 |
pinesol |
csharp_: Band 'ABSOLUTE ORG UNIT' added to list |
| 15:06 |
csharp_ |
redavis: yeashhh |
| 09:22 |
pinesol |
csharp_: Band 'Otto Gin' added to list |
| 09:29 |
|
dguarrac joined #evergreen |
| 09:42 |
Dyrcona |
ottogin.ess-aitch |
| 09:46 |
csharp_ |
nice |
| 09:49 |
* csharp_ |
wonders if the IP redirector could use the JSON org tree to get its data and get rid of lib-ips.txt altogether |
| 09:49 |
csharp_ |
currently just thinking about storing org IP addresses in the DB and auto-generating the lib-ips.txt file |
| 09:50 |
csharp_ |
and getting smarter about parsing the IP ranges for the overlap test |
| 09:50 |
csharp_ |
currently ORG-SHORTNAME IP1 IP2 |
| 09:50 |
csharp_ |
but Net::IP supports pretty much any standard IP format |
| 09:51 |
csharp_ |
going down this rabbithole because I'm frustrated about having to update a chunk of lines in the IP redirector and having to translate /24 ranges to "start ip", "end ip" |
| 10:10 |
JBoyer |
At least they're /24s. Really unpleasant would be something like /23 or /11. :) |
| 10:10 |
csharp_ |
it's often those too |
| 10:11 |
csharp_ |
I end up using sites like https://www.subnet-calculator.com/ a lot |
| 11:27 |
pinesol |
Dyrcona: go with development |
| 11:27 |
Dyrcona |
I guess. |
| 11:35 |
berick |
Dyrcona++ |
| 12:06 |
sandbergja |
Hey everyone, I'm getting failures in the perl live tests and in the angular unit tests on main. Friendly reminder to devs and committers to run tests, and request that we don't push any more failing code until we address the current failures. |
| 12:09 |
sandbergja |
...also, if you don't like having to remember to run tests, we could make the computers do it for us (see bug 2089184 for example) |
| 12:09 |
pinesol |
Launchpad bug 2089184 in Evergreen "Run Perl unit tests automatically in Github Actions" [Undecided,New] https://launchpad.net/bugs/2089184 |
| 12:09 |
|
jihpringle joined #evergreen |
| 12:18 |
|
redavis joined #evergreen |
| 12:24 |
|
jihpringle joined #evergreen |
| 12:29 |
pinesol |
News from commits: LP2074112 follow-up: allow angular unit tests to compile <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=bb256ffaad6cebf02118389679a3b8491f4e7b83> |
| 13:19 |
|
jihpringle joined #evergreen |
| 13:44 |
jihpringle |
Bmagic: I'm getting "This site can't be reached" when I try https://bugsquash.mobiusconsortium.org/eg/staff |
| 13:44 |
Bmagic |
it's not ready yet |
| 13:44 |
Bmagic |
I'll update the spreadsheet with "ready to test" soon |
| 13:44 |
Bmagic |
almost done! |
| 13:45 |
jihpringle |
I totally missed that that column was empty :) |
| 13:46 |
csharp_ |
sandbergja++ |
| 13:46 |
csharp_ |
tests++ |
| 13:47 |
Dyrcona |
Bmagic++ |
| 13:47 |
Dyrcona |
sandbergja++ # just looked at the scrollback. |
| 14:00 |
Bmagic |
jihpringle: it's up now, however, I'm having an issue with the certificate. But you should be able to click through the browser warnings if you want to get started |
| 15:47 |
redavis |
Yep |
| 15:47 |
redavis |
It is. |
| 15:47 |
Dyrcona |
Ok. We're not on 3.10, yet. |
| 15:47 |
* redavis |
nods |
| 15:47 |
redavis |
I forgot |
| 15:48 |
redavis |
It's pretty cool, but I've got zero bits to test it to recreate screens for docs. |
| 15:48 |
redavis |
And there are zero docs |
| 15:49 |
redavis |
But some LP comments and release notes..ish..and a presentation from 2022. |
| 15:55 |
redavis |
And here's the statement from AFGE Local 3403 on the Status of the Institute of Museum and Library Services. "Earlier today, the [IMLS] notified the entire staff that they are being placed on administrative leave immediately. The notification followed a brief meeting with DOGE staff and IMLS leadership. Employees were required to turn in all government property prior to exiting the building, and email accounts are being disabled today. Museums and |
| 15:55 |
redavis |
libraries will no longer be able to contact IMLS staff for updates about the funding they rely upon. In the absence of staff, all work processing 2025 applications has ended. The status of previously awarded grants is unclear. Without staff to administer the programs, it is likely that most grants will be terminated." |
| 15:57 |
Bmagic |
wow wow wow |
| 15:58 |
csharp_ |
redavis: not that I know of (re: advance shipment stuff) - you might ask Tiffany |
| 15:58 |
redavis |
mmhmm |
| 16:59 |
pinesol |
News from commits: LP2080373 Expand grid row right-click area (Chrome) <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=4a92cf6d7523b0b2566451c16a232e6be2553505> |
| 17:00 |
|
mmorgan left #evergreen |
| 17:42 |
|
jihpringle joined #evergreen |
| 19:35 |
sandbergja |
I got 9 of the erroring angular unit tests passing and pushed that to main as a follow-up. There are 6 more failing angular unit tests on main -- all for the IDL service. I have not yet looked at the perl live test failures |
| 20:00 |
pinesol |
News from commits: LP2074112 follow-up: address NG0203: inject() must be called from an injection contex... <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8dbeb06ce59a6376fc239ddea0e8c44996e168ef> |
| 13:38 |
jeffdavis |
I don't really know what "select":{"bre":["id"]} is doing there though |
| 13:39 |
Dyrcona |
I don't know either, and all of that fleshing would be pulling in whole rows, so it seems unnecessary. Not saying that is why it's slow though. |
| 13:40 |
Dyrcona |
Since bre.wide_display is fleshed, the rest of bre should be there already. |
| 13:41 |
mmorgan |
jeffdavis: We had that exact issue on 2 test servers. |
| 13:42 |
Dyrcona |
acn.record gets the bre row.... |
| 13:42 |
mmorgan |
Bmagic++ changed a postgres setting which fixed it. |
| 13:42 |
mmorgan |
jit_above_cost to -1 |
| 13:46 |
berick |
"select":{"bre":["id"]} tells pcrud to avoi adding values to the other fields, useful for avoid unneeded bulky MARC blobs |
| 13:46 |
jeffdavis |
ah yeah, I see there's a comment in items_out.js to that effect |
| 13:48 |
Dyrcona |
Huh... I'm getting a "new file" when I try to open that. |
| 13:48 |
jeffdavis |
Really wish I could figure out why we still have JIT problems in this test environment. |
| 13:48 |
Dyrcona |
Stupid editor... extra space at the end of the paste. |
| 13:49 |
jeffdavis |
Maybe postgres needs a restart. |
| 13:50 |
Dyrcona |
berick: That apparently doesn't interfere with fleshing the wide_display_entry? |
| 10:14 |
|
mixo joined #evergreen |
| 10:14 |
mixo |
Hello |
| 10:17 |
redavis |
hello mixo |
| 10:17 |
mixo |
I have evergreen version 3.12.3. I configured smtp. Test mail from evergreen works, but when I click to place hold it does not send email. |
| 10:25 |
redavis |
I'm going to leave that for someone with more experience. I'd possibly look at whatever Action Triggers you have set up. |
| 10:29 |
|
redavis_reloaded joined #evergreen |
| 10:33 |
mixo |
"Email Notice: Hold Request Success" is enabled |
| 11:10 |
mixo |
csharp_ thank you. I didn't schedule it. I'll do it. |
| 11:15 |
redavis |
csharp_++ |
| 11:16 |
eeevil |
grabbing db id 1465 |
| 11:20 |
sleary |
I see a few console errors here and there. It looks like they came from our stuff, so I will clean those up along with the failing test from IANT. |
| 11:20 |
sleary |
and whatever lint we missed |
| 11:20 |
sandbergja |
sleary++ |
| 11:22 |
redavis |
sleary++ |
| 11:22 |
eeevil |
also grabbing 1466, there's 2 upgrade scripts here! |
| 10:57 |
abneiman |
Dyrcona++ # much appreciated! |
| 10:57 |
|
sandbergja joined #evergreen |
| 11:43 |
|
jihpringle joined #evergreen |
| 12:03 |
sandbergja |
I have the capacity to review things that have automated test coverage and/or are small in scope/unlikely to cause side effects. Any suggestions? |
| 12:24 |
sleary |
@later tell sandbergja the localStorage cache buster https://bugs.launchpad.net/evergreen/+bug/2084181 |
| 12:24 |
pinesol |
sleary: The operation succeeded. |
| 12:24 |
pinesol |
Launchpad bug 2084181 in Evergreen "Wishlist: Cache buster for Staff Client LocalStorage" [Wishlist,New] |
| 14:18 |
pinesol |
Launchpad bug 2091748 in Evergreen "Concurrent browse entry update/insert" [Wishlist,New] |
| 14:18 |
abneiman |
csharp_++ |
| 14:19 |
abneiman |
thank you so much! |
| 14:20 |
csharp_ |
I think we may have tested bug 2091748 during our upgrade testing - I'll verify |
| 14:20 |
pinesol |
Launchpad bug 2091748 in Evergreen "Concurrent browse entry update/insert" [Wishlist,New] https://launchpad.net/bugs/2091748 |
| 14:20 |
abneiman |
that would be awesome, thanks |
| 14:22 |
csharp_ |
hmm - yes, we did - we backed it out and I don't remember why... |
| 13:09 |
Dyrcona |
s/with/without/ |
| 13:10 |
redavis |
Dyrcona++ #it'd be nice for a day or so though. |
| 13:10 |
redavis |
Maybe even three days |
| 13:11 |
Dyrcona |
So.... I'm getting Redis errors on my test vm, but it looks like it's still configured to talk to Ejabberd. |
| 13:11 |
Dyrcona |
Apparently, both redis and ejabberd are running. |
| 13:20 |
Dyrcona |
Stopped ejabberd, reconfigured opensrf_core.xml and it still doesn't seem to work. |
| 13:20 |
Dyrcona |
Could not connect to Redis server at private.localhost:6379: Connection refused at /usr/local/share/perl/5.38.2/OpenSRF/Transport/Redis/BusConnection.pm line 83. |
| 13:29 |
Dyrcona |
OK. Got it. Just put everything on the 127.0.0.1 line in /etc/hosts. |
| 13:49 |
jmurray-isl |
It helps if the ipset match is the first entry in iptables input rather than the last... |
| 14:00 |
|
jihpringle joined #evergreen |
| 14:04 |
Dyrcona |
Are any of the tests known to be failing with recent main? |
| 14:05 |
|
jihpringle joined #evergreen |
| 14:18 |
|
kmlussier joined #evergreen |
| 14:39 |
|
kmlussier left #evergreen |
| 09:49 |
|
jmurray-isl joined #evergreen |
| 10:01 |
|
kworstell_isl joined #evergreen |
| 10:17 |
Dyrcona |
Apparently, we can add a commit template to the repository, but we cannot enforce it's use. |
| 10:17 |
Dyrcona |
Everyone will have to set it locally. I can't force it from gitolite, either. (I just tried with a test repository.) |
| 10:18 |
redavis |
Was the goal to enforce it or make it available for use and have it documented as an SOP? |
| 10:19 |
Dyrcona |
redavis: The goal is probably to make it available. Even if we could force it, it would still pretty much be optional because the lines are added as comments/suggestions. |
| 10:19 |
* redavis |
nods |
| 15:11 |
Dyrcona |
I think I'll add a signoff with a note that we should get this in before the next releases. |
| 15:11 |
redavis |
Dyrcona, possible for you to add the signoff and check back in a few days prior to feature freeze? |
| 15:11 |
redavis |
Dyrcona++ |
| 15:11 |
jeffdavis |
I'm confident about the excising-1416 part but I'm not gonna have time to test/signoff the fix script. |
| 15:11 |
Dyrcona |
I don't think feature freeze would hold this up. It's a bug fix and AFAICTL it doesn't affect strings either. |
| 15:13 |
Dyrcona |
Well, I had a question about leaving a mostly empty upgrade script in the repo, but it makes sense after I thought about it and the motivation for doing so. |
| 15:13 |
Dyrcona |
I'll push a signoff and if no one gets to it by next week, I'll push it for the freeze anyway. |
| 16:16 |
redavis |
They have an additional org unit level, so maybe that has something to do with it? I dunno. Just going to skip over that right now and work on something else. |
| 16:16 |
Dyrcona |
Yeah, I'd put it down to different datasets. |
| 16:17 |
Dyrcona |
I have a plan to get rid of our extra org unit level. |
| 16:17 |
redavis |
And I'm also working on a test server that might not get the same loving care as production. |
| 16:18 |
redavis |
Yeah. I'm pretty hopeful that the continued work on library groups might make an extra level obsolete at some point. |
| 16:21 |
Dyrcona |
Ours is a hangover from the previous commercial ILS. They (we) ran two server instances split into western and central regions. Because it could not handle the full load. Then (I think) there was some kind of ILL connector to enable loans between the two. |
| 16:22 |
redavis |
Back in the good ol' days. Also, my issue with this was a performance issue. I just needed to wait longer. (ugh) |
| 17:05 |
|
mmorgan left #evergreen |
| 12:21 |
csharp_ |
. |
| 12:28 |
Bmagic |
csharp_++ |
| 12:28 |
Bmagic |
MS Copilot integration in the OS is pushing me away too |
| 12:29 |
jeffdavis |
I might not be able to make the dev meeting today. Just want to say I think we should test and commit Blake's branch (which removes 1416 and provides a fix for folks who have already run it) and include it in the next point releases. |
| 12:29 |
Bmagic |
jeffdavis++ |
| 12:37 |
Dyrcona |
jeffdavis++ # I'll paste what you said and an #info when we get there if you're not able to attend. |
| 12:37 |
Dyrcona |
s/and/as/ |
| 15:14 |
mantis |
I was only able to do it once so far in the releases |
| 15:14 |
* mmorgan |
is a POeditor, what am I looking for? |
| 15:15 |
Dyrcona |
I don't know if we have git integration with POEditor. I haven't heard anything and haven't looked. |
| 15:16 |
shulabramble |
so what I think I'm hearing is we need testing to confirm the integration? |
| 15:17 |
redavis |
shulabramble, I guess so. |
| 15:17 |
abneiman |
sounds that way, I can ping gmcharlt again |
| 15:17 |
|
ianskelskey joined #evergreen |
| 15:22 |
shulabramble |
I was going to ask if that's a bottleneck we need to address |
| 15:23 |
Dyrcona |
Well, in the long run, yes. |
| 15:24 |
Bmagic |
I'll take the action item if you want |
| 15:24 |
shulabramble |
and transferring ownership would have to be discussed with gmcharlt |
| 15:24 |
shulabramble |
bmagic++ |
| 15:25 |
shulabramble |
#action Bmagic will look into transferring POeditor account ownership to a generic EG account |
| 15:25 |
shulabramble |
#topic sleary and sandbergja will report progress on test writing wiki pages next month |
| 15:26 |
sleary |
still in progress |
| 15:26 |
shulabramble |
sleary++ |
| 15:26 |
shulabramble |
#action sleary and sandbergja will report progress on test writing wiki pages next month |
| 15:26 |
shulabramble |
and the last item from last month... |
| 15:26 |
shulabramble |
#topic abneiman will discuss moving the developer's meeting with shulabramble and poll the community |
| 15:27 |
* abneiman |
waves hands |
| 15:27 |
abneiman |
nope nope |
| 15:27 |
shulabramble |
i know this hasn't happened but will one day! :) |
| 16:10 |
csharp_ |
would have planned it properly if I had done a tiny bit of research |
| 16:11 |
shulabramble |
no trouble at all, these things happen and there's been A Lot Going On |
| 16:11 |
Dyrcona |
What about switching to Debian? |
| 16:12 |
csharp_ |
Dyrcona: I looked at that - similar issues on currently-supported Debian stable releases |
| 16:12 |
csharp_ |
basically there are gaps between OS releases even having a Mailman package to install at all |
| 16:12 |
csharp_ |
24.04 is basically current sid, or maybe testing |
| 16:13 |
csharp_ |
so kind of a bad situation from top to bottom |
| 16:15 |
|
mantis left #evergreen |
| 16:15 |
shulabramble |
csharp_++ |
| 16:15 |
shulabramble |
anything else? |
| 15:03 |
csharp_ |
making me wonder 1) if we need to get certs from somewhere else and 2) if we need the Evergreen project to find us some web space to run these servers out from under ITS :-/ |
| 15:04 |
csharp_ |
@blame corporate IT |
| 15:04 |
pinesol |
csharp_: corporate IT was monkeying around too much on the prod servers! |
| 15:04 |
csharp_ |
pinesol: nope, that was me late yesterday truncating the production reporter.schedule table thinking I was on a test server |
| 15:04 |
pinesol |
csharp_: No, you're a puzzleheaded kraken! |
| 15:05 |
csharp_ |
apropos of nothing, our backups are effective! |
| 15:05 |
berick |
*phew* |
| 15:06 |
Dyrcona |
Backups *are* effective. It's also good to test your restore plan every now and then. |
| 15:07 |
JBoyer |
csharp_++ |
| 15:08 |
JBoyer |
FW issue that they don't want anything coming in on 80 I assume? |
| 15:08 |
JBoyer |
Well that would be pretty over the top now that I write it out |
| 15:08 |
csharp_ |
would've preferred a lower cortisol inducing approach to testing our restore plan, but you're right, Dyrcona |
| 15:09 |
csharp_ |
JBoyer: yeah :-/ |
| 15:09 |
csharp_ |
basically any firewall request involving access from parties outside the USG must get CIO-level approval with a form and all |
| 15:09 |
csharp_ |
TPS cover sheet probably not involved, but I don't know yet\ |
| 15:10 |
JBoyer |
yuk. |
| 15:10 |
csharp_ |
it was a forced marriage |
| 15:14 |
Bmagic |
please sir, may I have a port sir |
| 12:48 |
Bmagic |
ianskelskey: 15 |
| 12:49 |
berick |
going to 14 in a couple weeks |
| 12:50 |
JBoyer |
Yeah, I think as long as you disable jit 15+ is entirely fine. (and eventually we'll spend the time to find out why jit hates our queries, but that's currently the only face-rake in place on later versions.) |
| 12:50 |
Dyrcona |
We plan to go to 16 in April. I've been testing with 17 as well. |
| 12:50 |
JBoyer |
Oh, and the libc reindex-the-world thing in 14. |
| 12:50 |
ianskelskey |
Thank you. I was just going to ask if there were any specific considerations to be aware of. Anything else? |
| 12:51 |
Dyrcona |
ianskelskey: What Evergreen release are you on? |
| 12:56 |
ianskelskey |
Thank you. That was very helpful. |
| 12:58 |
berick |
Dyrcona++ |
| 12:58 |
berick |
had to re-read them to check |
| 12:58 |
Dyrcona |
For the logs: It is also safe to apply those patches if you're staying on PostgreSQL 10 for a bit. I've tested releases as old as 3.7.4 with those patches on all versions of Pg from 10 through 17. |
| 12:59 |
berick |
ianskelskey: btw just got that logitech mx mouse. very nice. |
| 13:01 |
ianskelskey |
Heck yea. I think they're great. |
| 13:30 |
csharp_ |
Dyrcona++ |
| 10:55 |
|
Christineb joined #evergreen |
| 10:56 |
mantis |
Bmagic: Pop OS wasn't fruitful? |
| 10:56 |
mantis |
or did you just want to change? |
| 10:59 |
Bmagic |
Pop!_OS was fruitful for the most part. It's a Debian derivative, same as Mint. I had trouble with a video game. It stuttered and crashed ransomly. I'm not sure I can blame Pop!_OS, but I used that as my first test when testing an OS install. And I got it to work flawlessly on Mint, so I proceeded to install more and more of my applications, and it kept working. So, I'm rolling with it for now |
| 10:59 |
Bmagic |
ransomly/randomly |
| 11:00 |
* berick |
wishes Bmagic safe passage |
| 11:03 |
Bmagic |
I will likely format (or swap HD) when Cosmic Desktop is out of Alpha release (Pop!_OS (System76) is working on), lots of buzz, and I'm excited for it. |
| 10:18 |
Dyrcona |
Cleaning up the lock file is gonna be trickier than I first thought, because I only want the main reporter process to remove it. |
| 10:24 |
Dyrcona |
clark-kent.pl is one of the files that we "mangle" during make install and not make. That should be changed. |
| 10:26 |
Dyrcona |
Hmm. My first try doesn't work because I'm setting the stored process id too soon. |
| 10:30 |
Dyrcona |
Yeahp. Works, now.... I should test it with reports running. |
| 10:34 |
|
sandbergja joined #evergreen |
| 10:36 |
* Dyrcona |
sings along with Dale Bozzio: "Do you hear me? Do you care?" |
| 10:37 |
* Dyrcona |
tries to figure out how to run a report. |
| 12:00 |
redavis |
Dyrcona++ |
| 12:00 |
Dyrcona |
It finished and the lock file is still there, so my patch works. |
| 12:01 |
redavis |
Excellent :D |
| 12:02 |
Dyrcona |
It's lunch time. I'll add code to put the lock file elsewhere after lunch, test that, then push it to working and update Lp 2098995. |
| 12:02 |
pinesol |
Launchpad bug 2098995 in Evergreen "Reporter should clean up after itself" [Undecided,New] https://launchpad.net/bugs/2098995 - Assigned to Jason Stephenson (jstephenson) |
| 12:06 |
|
b_bonner joined #evergreen |
| 12:16 |
|
jihpringle joined #evergreen |
| 14:12 |
csharp_ |
we are upgrading from 3.12 to 3.14 on Saturday |
| 14:12 |
csharp_ |
oh |
| 14:12 |
csharp_ |
hmm - maybe we can save ourselves the pain |
| 14:13 |
jeffdavis |
So simply omitting 1416 would in theory mean that an upgraded system is a match for a clean install. |
| 14:13 |
jeffdavis |
I haven't tested this yet *at all* so please don't rely on me being right about this :) |
| 14:13 |
jeffdavis |
(and good luck with the upgrade either way!) |
| 14:13 |
csharp_ |
thanks! |
| 14:14 |
Dyrcona |
I think you can skip it without danger. |
| 14:17 |
csharp_ |
Dyrcona++ # gonna skip it! |
| 14:25 |
Dyrcona |
Ugh. Half of a script just blew up because i did one of the steps early. |
| 14:27 |
Dyrcona |
Well, not quite half. |
| 14:28 |
Dyrcona |
I think I should be able to test OpenSRF now. |
| 14:30 |
Bmagic |
does the SIP 98/99 keepalive refresh the memcached authtoken? |
| 14:30 |
Dyrcona |
Bmagic: Not sure. |
| 14:50 |
jeffdavis |
Bmagic: Are you using SIPServer or SIP2Mediator? |
