| 11:53 |
|
redavis joined #evergreen |
| 12:01 |
|
jihpringle joined #evergreen |
| 14:02 |
|
redavis_ joined #evergreen |
| 14:07 |
jeffdavis |
I've got a test server where generating Did You Mean suggestions is adding 23 seconds to the runtime of a keyword search, because the call to search.symspell_lookup has to process 62,000 potential suggestions. |
| 14:08 |
jeffdavis |
This is a 3.11 server. |
| 14:11 |
|
redavis joined #evergreen |
| 14:13 |
jeffdavis |
symspell dictionary was generated using the sideload script with the default values for internal flags (symspell.prefix_length = 6, symspell.max_edit_distance = 3) |
| 14:23 |
|
Dhruv_Fumtiwala joined #evergreen |
| 14:23 |
Dhruv_Fumtiwala |
copy_vis_attr_cache |
| 14:23 |
Dhruv_Fumtiwala |
Can you please help me as to what this table has information about. |
| 15:43 |
jeff |
jeffdavis: possibly reading too much into your words, by "slow in 3.11" do you mean that there is a version of Evergreen prior to 3.11 where search suggestions did not result in very slow searches? |
| 15:45 |
|
kworstell-isl joined #evergreen |
| 15:45 |
Stompro |
In the angular catalog search, the opac hidden marc coded value maps that are not marked opac visible are showing. Is that a config option? |
| 15:45 |
jihpringle |
jeff: when I do a search on our 3.11 test server public catalogue it takes 52 seconds to give me any results, a search on PINES' catalogue takes seconds and they have DYM running in 3.10 |
| 15:50 |
jihpringle |
Strompo: it's a bug, we deleted the hidden ones off our server since we weren't using them anyways |
| 15:50 |
jihpringle |
Stompro ^^ |
| 15:51 |
jihpringle |
here's the original bug - https://bugs.launchpad.net/evergreen/+bug/1872867 |
| 15:51 |
pinesol |
Launchpad bug 1872867 in Evergreen "Angular Staff Catalog Format Drop Down List Not Using Search Labels or Observing OPAC Visible Value" [Undecided,Fix released] |
| 15:52 |
Stompro |
jihpringle++ thank you very much. |
| 15:52 |
jihpringle |
np :) |
| 09:33 |
Bmagic |
CONS is there |
| 09:34 |
Dyrcona |
Errors from Socket.pm are a bit surprising if that's the problem, but it could be that some service doesn't run. |
| 09:34 |
Dyrcona |
Last time I tried this, it was for the MVLC migration in 2012... |
| 09:38 |
Bmagic |
just about to test concerto. If I get the same error, then I'll chase a different problem |
| 09:44 |
Bmagic |
same prob |
| 09:44 |
Bmagic |
I'll figure it out. This should* work. I setup concerto machines all the time |
| 09:46 |
Dyrcona |
I'd osrf_control --diagnostic and check that ejabberd, memcached, etc., are running. |
| 09:56 |
berick |
Bmagic++ |
| 09:56 |
Bmagic |
at least at first :) |
| 09:56 |
Dyrcona |
Bmagic++ |
| 09:57 |
Dyrcona |
I've been using Pg 15 with test VMs for awhile. I've even got one with produciton data. It's faster at some things than Pg 10, even when Pg 15 isn't optimized. |
| 09:57 |
Dyrcona |
We should start looking at Pg 16. It was released already. |
| 09:57 |
Bmagic |
I figured this would be an opportunity to see if Evergreen (with nothing and no history) can setup and work on PG15. I'll be watching the PG logs like a hawk |
| 09:58 |
Dyrcona |
Bmagic: It should. |
| 09:58 |
Bmagic |
I'm sure it will look* like it's working |
| 09:58 |
Bmagic |
I'll be expecting to see some nasy stuff in the logs, but hey! maybe not |
| 09:58 |
Dyrcona |
I told you it will* work. What more do you need? |
| 09:59 |
Bmagic |
running through the migration of 500k bibs into an empty DB with PG15 should be a good test |
| 10:00 |
* Dyrcona |
loads dumps and has imported bibs into Pg 15 with production data. It should work. |
| 10:01 |
Bmagic |
wouldn't it be funny if PG15 was the issue with this socket error |
| 10:01 |
Dyrcona |
Did you set pg_hba.conf properly? |
| 10:24 |
Dyrcona |
yeah, I think it does. |
| 10:24 |
Dyrcona |
If it has the installation for Pg 15, then it should have all of the commits. |
| 10:25 |
* Dyrcona |
makes a Lp bug.... |
| 10:27 |
Bmagic |
I'm testing my theory that my socket issue was due to the Linux host being 22.04 and the container was 20.04 |
| 10:28 |
Dyrcona |
Maybe..... |
| 10:28 |
Dyrcona |
You can run Evergreen on 22.04. It works there, too. |
| 10:28 |
Bmagic |
yeah, I might target 22.04 for this. I can't remember why I shy away from that one. There was something about it but I can't remember |
| 10:28 |
Dyrcona |
I do most of my testing on Ubuntu 22.04. |
| 10:29 |
Dyrcona |
Lp 2037656 |
| 10:29 |
pinesol |
Launchpad bug 2037656 in Evergreen "Add Support for PostgreSQL 16" [Wishlist,New] https://launchpad.net/bugs/2037656 |
| 10:29 |
Bmagic |
Dyrcona++ |
| 11:58 |
Bmagic |
the Evergreen application is installed on the same machine with PG? |
| 11:58 |
Bmagic |
when you said 1 machine (out of 5) I assumed each one had a single-purpose dedicated OS |
| 12:01 |
Bmagic |
how about this: what if you setup a new brick from scratch. Does the problem occur there? |
| 12:01 |
jmurray-isl |
Yes, we have two non-prod bare metal machines that use a full copy of the prod database, one for migration testing, and the other for practice. I eventually plan to move practicing over to the migration testing server, but currently it helps to have them separate. The others would be training/testing VMs, which work fine. |
| 12:03 |
jmurray-isl |
At this point, it would probably save time just to rebuild the server in question, but I wasn't sure if there'd be a quicker solution. |
| 12:04 |
Bmagic |
if you can't find a difference between the working machine and the non-working machine. A difference in any of the meaningful Evergreen configs and Apache configs, then it's gotta be OS |
| 12:04 |
jmurray-isl |
One would think. The OS should be the same (both Ubuntu Focal). |
| 12:05 |
Dyrcona |
jmurray-isl: Does the too many redirects message prevent it from working, or does it go away and then things work? |
| 08:45 |
|
sandbergja joined #evergreen |
| 09:12 |
|
Dyrcona joined #evergreen |
| 09:21 |
|
collum joined #evergreen |
| 09:32 |
Dyrcona |
Today's test is going better than yesterday's. It is still chugging away at the events, and I apparently have not run out of drones. |
| 09:34 |
Dyrcona |
I'm using our production server's configuration for this test. |
| 09:35 |
Dyrcona |
Modulo the database connection parameters, etc., of course. |
| 09:36 |
Stompro |
Morning all, I'm looking into cleaning up our /openils/var/web/reporter data this morning. Every report generated since we migrated in 2015 exists in there. Is there an existing evergreen method for purging those? |
| 09:47 |
Stompro |
Bug 1835317 talks about adding a retention interval to report output. |
| 12:12 |
Dyrcona |
Is the editor always_xact? |
| 12:12 |
Dyrcona |
Oh, never mind. It is. |
| 12:12 |
Dyrcona |
:P |
| 12:13 |
Dyrcona |
I'm having one of those days. I have to rerun a test of marc_export because I overwrote one of the output files with the data that I wanted to compare it to. |
| 12:15 |
berick |
Bmagic: but also... working code wins, so don't let me mood derail everything ;) feeling ranty this a.m. |
| 12:16 |
berick |
also, apparently, talking like a pirate |
| 12:17 |
Bmagic |
berick: I think I agree that the API shouldn't crash |
| 12:31 |
berick |
Bmagic: that means those try/catch'es do nothing. that crash is happening in a whole different OS process |
| 12:32 |
berick |
(the api should also be fixed, of course, but on the topic of try/catching...) |
| 12:32 |
Bmagic |
we'll dig |
| 13:01 |
Dyrcona |
My other test turns out to have a bad template... |
| 13:07 |
Dyrcona |
Ah, found it. Though the error message didn't really help.... It complained about an unexpected token (END) when it looks like the problem was an extra %] higher up. |
| 13:57 |
|
jihpringle joined #evergreen |
| 14:29 |
Stompro |
Great... testing EDI is fun. Just sent in an order because "edi_pusher.pl --debug-only=1" is not the correct format for that flag, so it just runs like normal. |
| 14:30 |
jeffdavis |
:( |
| 14:35 |
Stompro |
I guess I'll get to see what happens when PO and line item id numbers get reused does to the B&T system and to our system if they send us a response message. |
| 14:37 |
Stompro |
The test seems to be showing that EDI generates the same message on 3.11.1, with Ruby 3.1 and the Ruby EDI translator on Debian 12 as it did on our old system. |
| 14:38 |
jeff |
later that same day, From: Baker & Taylor / Subject: Server Outage Impacting Systems |
| 14:44 |
Stompro |
Ha, but maybe it will fix the content cafe issue... if they have to restart their redis servers. Ever hopeful. |
| 14:52 |
|
jihpringle joined #evergreen |
| 08:28 |
|
kworstell-isl joined #evergreen |
| 08:33 |
|
mmorgan joined #evergreen |
| 09:10 |
|
Dyrcona joined #evergreen |
| 09:15 |
Dyrcona |
So, the action_trigger_runner blew up processing the modified autorenew events in my test last night. There were 55,706 of them. |
| 09:17 |
Dyrcona |
Most of the events last night (i.e. all of the events that run) are collected or collecting. Only a few event completed. There was nothing else going on in the database, only this one vm running this test, so it's easy to overwhelm action trigger. |
| 09:19 |
Dyrcona |
Time for some spelunking in the logs. |
| 09:21 |
Bmagic |
why is authority_control_fields.pl so expensive? |
| 09:21 |
Dyrcona |
The open-ils.trgger stderr log has a new one on me: Caught error from 'run' method: Unable to update event state at /usr/local/share/perl/5.34.0/OpenILS/Application/Trigger/Event.pm line 247. That might have something to do with a not connected to the network message a few errors higher up. Too bad the stderr log lacks timestamps. |
| 09:51 |
Dyrcona |
Yeah, but I've got 4 total certs for the chain file. |
| 09:56 |
Dyrcona |
I suppose I can figure it out by inspecting the certs. Our cert goes first, then I think they go in order from the one that sigend our cert down to the root. |
| 09:57 |
Dyrcona |
And, I can omit the self-signed root authority assuming that the recipient has it anyway. |
| 10:01 |
Dyrcona |
Right. Easy-peasy... Now to test it. |
| 10:06 |
jeff |
for intermediate certs, apache (starting with 2.4.8) is leaf-to-root, nginx needs the leaf to be first but may tolerate a different order on the others (but why complicate things -- leaf-to-root works here too). pound uses leaf to root followed by the private key in the same PEM file. in most cases (with the possible exclusion of some weird cross-signing), the self-signed actual root cert found in the |
| 10:06 |
jeff |
browser's trust store doesn't need to be included in the file or sent. |
| 10:07 |
jeff |
exim and dovecot and friends i usually look in the docs, or follow whatever my deployment scripts or existing files contain. :-) |
| 10:07 |
Dyrcona |
exim and dovecot work with whatever certbot does. I can say that. Oh, so does Apache 2.4. |
| 10:08 |
jeff |
happily, with intermediates being more or less a fact of life now, you rarely have to go digging in the source or rely on empirical test-and-hope techniques... since they're so common, they're much more well-documented now. :-) |
| 10:08 |
Dyrcona |
This one is just nginx an apache, and I'm getting a gateway timeout. |
| 10:08 |
jeff |
I am happy to keep certbot far, far away from as many systems as possible. |
| 10:08 |
Dyrcona |
Well, the RFC also specifies the order, and most software follows the RFC. |
| 10:48 |
Dyrcona |
s/(list)/\1en/ |
| 10:55 |
Dyrcona |
Y'know. I'm starting to suspect that the 500 Ineternal Sever Error was caused by the backlog. It wasn't just open-ils.trigger that was overloaded. |
| 10:56 |
Dyrcona |
Yeah. It's fine now that I've restarted services. |
| 10:57 |
Dyrcona |
So, my test failed successfully. I now know that I need to increase resources before trying this again. :) |
| 10:58 |
|
briank joined #evergreen |
| 11:35 |
sharpsie |
@dunno add SYSTEM CONTROL RESTART OPEN SURF |
| 11:35 |
pinesol |
sharpsie: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
| 10:28 |
* mmorgan1 |
*believes* the biblio.record_entry.email trigger is for both baskets and individual bib records. |
| 10:29 |
mantis1 |
mmorgan1: thinking the same at this point |
| 10:29 |
Bmagic |
that might be right. I've had to track this down before but I don't remember what the conclusion was |
| 10:30 |
mantis1 |
testing now |
| 10:32 |
mantis1 |
yup that was it |
| 10:32 |
mantis1 |
mmorgan1++ |
| 10:32 |
mantis1 |
Bmagic++ |
| 10:32 |
Bmagic |
matis++ mmorgan1++ |
| 10:32 |
mmorgan |
mantis1++ |
| 10:32 |
Bmagic |
mantis1++ even |
| 14:53 |
Stompro |
Does the vendor (B&T) know what attributes they want if I ask them? |
| 14:55 |
jihpringle |
Stompro: maybe email the acq list? based on the last time we talked about EDI Attributes in the acq interest group very few libraries/consortia have made the switch |
| 14:56 |
Dyrcona |
We've switched but I don't know the details about the attributes. That would be someone else here who doesn't hang out in IRC. |
| 14:57 |
Stompro |
Thanks, I think I have the Ruby translator installed on Debian 12, but I don't know how to test it out. So I was looking at the new generator also. |
| 14:58 |
Dyrcona |
We haven't used the Ruby code in a couple of years. |
| 14:59 |
mantis1 |
We had a problem with the loader before |
| 14:59 |
mantis1 |
turned out it was because we didn't upgrade Ruby |
| 15:03 |
Stompro |
I guess if I don't run the order pusher, and just the A/T I can see if the EDI message gets generated. |
| 15:06 |
|
jihpringle joined #evergreen |
| 15:10 |
Dyrcona |
We've had fun with that and new versions of Ruby in the past. I'll be glad to see it go. |
| 16:11 |
Dyrcona |
I'm going to start another test run of action triggers on a vm with 32GB of RAM and 16 cores. (It has double the number of cores over production.) Should I double the parallel values for action trigger from 3 to 6 for collectors and reactors? |
| 16:15 |
Dyrcona |
All right, I will double the values. We'll see how this goes tomorrow. |
| 16:55 |
pinesol |
News from commits: Docs: DIG Reports Docs Update Project <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=95c08fe464ce0b0686893ba19a87085758cfd5bf> |
| 17:02 |
|
mantis1 left #evergreen |
| 09:08 |
pinesol |
News from commits: LP2034969: Update docs to reference EDI cron jobs <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=d9ec9d3295389ca42b8b0c29b18b6ce40e28cdbd> |
| 09:08 |
pinesol |
News from commits: LP2034969: Add EDI Scripts to Example crontab <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8f3690d9580bad8d4c1fb9b324811b2287f6dd32> |
| 09:08 |
pinesol |
News from commits: LP2034969: Add EDI Scripts to Makefile.am <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=74d46c4f7b726d611cf0151f8b7ecba9fd7791ad> |
| 09:11 |
sandbergja |
Fun fact (and cause for celebration): we have exactly 100 angular client unit tests in main right now! |
| 09:12 |
sandbergja |
Our safety net is getting stronger! Maybe we can make it 200 before the next big angular or ng-bootstrap upgrade. :-) |
| 09:22 |
Dyrcona |
sandbergja++ |
| 09:39 |
|
kworstell-isl joined #evergreen |
| 09:43 |
berick |
sandbergja++ |
| 10:22 |
sharpsie |
lrwxrwxrwx 1 root root 4 Jul 18 2019 /bin/sh -> dash |
| 10:23 |
sharpsie |
that's on a 20.04 server here |
| 10:24 |
Dyrcona |
sharpsie: The crontabs both do SHELL = /bin/bash |
| 10:25 |
mantis1 |
JBoyer it may be I can give it a shot in our test server then get back to you |
| 10:27 |
sharpsie |
Dyrcona: ah |
| 10:27 |
Dyrcona |
Anyway, that's small potatoes at the moment. I tried replacing our 2-day courtesy notices with a combined template for autorenewals on the "bad" vm last night, and it choked on 62,321 notices.I'll have to dig into the logs, but the a/t runner isn't running and its stuck with 52000+ "collected" events. |
| 10:27 |
sharpsie |
is LYING=true set :-) |
| 10:48 |
sharpsie |
Dyrcona: ah - I've only played with Arch in VMs |
| 10:48 |
sharpsie |
jeff: makes sense |
| 10:49 |
sandbergja |
Dyrcona: I switched to Endeavour OS for my personal laptop recently -- really enjoying it so far. It's been fun to dip my toes into the arch world. |
| 10:49 |
Dyrcona |
sharpsie: It's actually easier to install it on hardware than on a vm, because of the UEFI setup. At least that was my experience. I did a test install on a VM before going "live." |
| 10:50 |
Dyrcona |
Right, so /var/log/syslog.1 looks like it was rotated 3 days ago, and it is also 17GB. Something's off on this vm. |
| 10:53 |
Bmagic |
mantis1: probably opac/parts/record/summary.tt2 |
| 10:54 |
Dyrcona |
sandbergja: I hadn't seen Endeavour OS before. It looks cool. |
| 10:55 |
Dyrcona |
Heh. Confusing ld for ls is kind of funny: ld:/var/log/syslog.1: file format not recognized; treating as linker script |
| 10:55 |
Dyrcona |
ld:/var/log/syslog.1:1: syntax error |
| 10:56 |
Bmagic |
mantis1: lol, just made it through the backlog, ignore me |
| 10:58 |
Dyrcona |
I'll make sure I have a backup of the crontab that I'm testing, and then wipe this vm and build a replacement. It's probably not worth figuring out the issues. |
| 11:01 |
|
briank joined #evergreen |
| 11:07 |
jeff |
semi offtopic, but also not: anyone with a library card vendor that they can recommend, I'd be interested. Our requirements are fairly typical, but also we supply a list of card numbers (not a range), so the vendor would need to be able to support that also. |
| 11:08 |
pinesol |
News from commits: LP#1840990: The Mark Damaged and Mark Missing dialogs are missing some <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=22a30e43f45a83dfd72b55be17baf5c1bdd0bdb2> |
| 14:11 |
Dyrcona |
mantis2: At the moment, no, but there's a Lp bug for that. |
| 14:12 |
Dyrcona |
Lp 1904737 |
| 14:12 |
pinesol |
Launchpad bug 1904737 in Evergreen "Flag/setting for Items with Specific Statuses to Display on Holds Pull List" [Wishlist,Confirmed] https://launchpad.net/bugs/1904737 |
| 14:13 |
Dyrcona |
Feel free to test it and signoff! |
| 14:16 |
mantis2 |
ooo excellent |
| 14:19 |
* jeff |
reviews the comments to see where the "why not use locations for that?" discussion went |
| 14:20 |
* Dyrcona |
doesn't want to get into it. That horse has been talked to death. |
| 14:26 |
Dyrcona |
All of that being said, I like the idea of the flag on the status to show up on holds. It eliminates the "magic" status of some statuses and makes it obvious. |
| 14:27 |
Dyrcona |
Very often good ideas get shot down or delayed because the discussion gets bogged down in unnecessary detail..... |
| 14:27 |
* Dyrcona |
trips off the soapbox he didn't intend to stand on. |
| 14:39 |
Dyrcona |
mantis2: If you're going to test that, it would be helpful if you could assign the bug to yourself in Launchpad. |
| 14:41 |
jeffdavis |
Upshot of the status vs location discussion seems to be "use status for items that should revert to Available on checkin, otherwise use locations"? |
| 14:52 |
mmorgan |
At the risk of tripping over Dyrcona's soapbox, it's the fluidity of the status that's appealing vs. the rigidity of the location. My observation, anyway. |
| 14:55 |
Dyrcona |
So, I figured out why one of my cron jobs was failing. It was trying to talk a database server that doesn't exist. Turns out I was also clever enough to implement the cron job so that if I set PGHOST and PGDATABASE in the crontab it should be fixed. |
| 11:18 |
|
dguarrac joined #evergreen |
| 11:18 |
Dyrcona |
Something is definitely wrong because right cron tries running this job, it says 'No MTA installed, discarding output.' So, cron has a problem before it gets to the job? Redirection to a file isn't working.... |
| 11:23 |
Dyrcona |
All right. We'll see if 'no configuration' works for this. |
| 11:29 |
Dyrcona |
Well, the message about no MTA did not appear in the logs, but still got no output and no mail was delivered to the user, so maybe it worked. There was nothing to do on that vm? I'll test the other with "Local only" mail configuraiton. |
| 11:32 |
Dyrcona |
Really? That's the problem.... |
| 11:39 |
Dyrcona |
And.... Still nothing. |
| 11:41 |
Dyrcona |
OK. eliminated the redirects and its running..... |
| 14:28 |
Dyrcona |
Ha! Never mind! |
| 14:32 |
jeffdavis |
Bmagic: if you are looking into Azure (or other Shibboleth-based SSO) and you are running EG on Ubuntu, you will probably need the changes to OpenSRF and Evergreen from bug 1999823 |
| 14:32 |
pinesol |
Launchpad bug 1999823 in OpenSRF "Name collision causes apache gateway modules to fail when mod_shib is installed" [Medium,Confirmed] https://launchpad.net/bugs/1999823 |
| 14:34 |
jeffdavis |
I'm happy to share the Shibboleth setup that has worked for us in testing as well |
| 14:35 |
Bmagic |
jeffdavis++ |
| 14:42 |
|
shulabear joined #evergreen |
| 14:47 |
Bmagic |
13 minte warning! Dev meeting |
| 15:32 |
Bmagic |
oh |
| 15:32 |
berick |
thanks rfrasur. there will be plenty yet to discuss |
| 15:32 |
Bmagic |
#link https://bugs.launchpad.net/opensrf/+bug/2032835 |
| 15:33 |
Bmagic |
#topic LP#1999823: concurrent changes to EG and OpenSRF required; testing requested |
| 15:33 |
jeffdavis |
I can speak to this |
| 15:33 |
Bmagic |
#link https://bugs.launchpad.net/opensrf/+bug/1999823 |
| 15:33 |
pinesol |
Launchpad bug 1999823 in OpenSRF "Name collision causes apache gateway modules to fail when mod_shib is installed" [Medium,Confirmed] |
| 15:33 |
JBoyer |
Yeah, so, see above about making changes across 2 different but related projects. :D |
| 15:34 |
jeffdavis |
basically some of the C functions in OpenSRF and EG need to be renamed to avoid collisions; it's currently an issue when using Shibboleth for SSO on Ubuntu but I think that's just one potential problem case |
| 15:34 |
jeffdavis |
there are branches for both OpenSRF and EG making the necessary changes, this is a request for some folks besides me and JBoyer to try running those branches and see if anything breaks |
| 15:35 |
Bmagic |
jeffdavis: we might be candidates for testing these branches in the coming months |
| 15:35 |
Dyrcona |
I can have a look without sso enabled. |
| 15:35 |
jeffdavis |
that would be great! and yeah, SSO is not needed to test the branches I think |
| 15:36 |
jeffdavis |
also, once the changes are committed to EG we'll need to update the minimum required version of OpenSRF |
| 15:36 |
JBoyer |
And note, if it helps, you don't necessarily have to setup a whole shibboleth setup to test them, testing them "plain" helps, as does just enabling the modules that shibboleth uses and testing then too. |
| 15:37 |
Dyrcona |
jeffdavis: Mind if I steal the bug from you? |
| 15:37 |
jeffdavis |
Please do! |
| 15:37 |
Bmagic |
jeffdavis: I was thinking that too, which means that the commits will need to take place on a major Evergreen release cycle (not bug fix cycle) |
| 15:39 |
jeffdavis |
FWIW we are hoping to go live with SSO for a few of our libraries this month, so we'll need to deploy the changes on 3.9 |
| 15:40 |
jeffdavis |
we can deal with backporting locally at Sitka but it's a bit of an added version if the changes aren't in EG until 3.12 |
| 15:40 |
jeffdavis |
*added burden |
| 15:40 |
Dyrcona |
Well, I can test with 3.10 as well as main. |
| 15:41 |
Bmagic |
our container setup makes it fairly trivial to stand up a test server with certain patches on OpenSRF/Evergreen. |
| 15:41 |
Dyrcona |
I don't think much has changed in the C code, so a backport should be trivial. |
| 15:41 |
sandbergja |
Would these be considered breaking changes to OpenSRF's C API? If so, should we cut a 4.0.0 of OpenSRF with these changes? |
| 15:42 |
JBoyer |
The Big Fix, that can't be broken by further OS updates, would be to modify our library build process to *only* export certain functions, rather than all of them. :/ |
| 17:08 |
|
mmorgan left #evergreen |
| 17:36 |
|
sandbergja left #evergreen |
| 18:25 |
|
sandbergja joined #evergreen |
| 18:26 |
sandbergja |
Requesting review on bug 2035287 (small PR related to the nightwatch tests). Especially for anybody who hasn't yet run the nightwatch tests and wants to give them a try. :-D |
| 18:26 |
pinesol |
Launchpad bug 2035287 in Evergreen "e2e tests are failing" [Undecided,New] https://launchpad.net/bugs/2035287 |
| 18:52 |
jeffdavis |
We should probably rationalize how we use various parameters for context org in the OPAC someday (locg, loc, search_ou, physical_loc, context_org, etc etc). It's pretty messy. |
| 19:06 |
pinesol |
News from commits: [docs] lp1841635 Adding macros for preferred name. <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=01f36734203007cc0a8f3255952aeecf96f5704d> |
| 19:06 |
pinesol |
News from commits: LP#2030821 - Fix for Acq: Alert Type Drop Down Duplicated <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=52e0db9a33c41f3a990b0dced007aaa3f44f9819> |
| 12:48 |
Dyrcona |
I wonder if systemd-resolvd can do that? I know it can resolv for the localhost. Will it accept outside connections? |
| 12:49 |
* Dyrcona |
decides to save that exercise for later. ;) |
| 12:51 |
* Dyrcona |
remembers having "fun" with dnsmasq back in the day at MVLC. |
| 12:55 |
Dyrcona |
So, the overnight events finally finished at 12:16 pm on the machine running without parallel settings, so that's being undone for the remaining tests. |
| 12:55 |
Dyrcona |
We're likely going to replace our autorenewal template with something similar to the one Stompro++ shared yesterday. Then drop the courtesy notices. |
| 12:56 |
Dyrcona |
I'm going to test with the filter to drop circs with autorenewal from the courtesy notices to compare the difference between the two vms. They have the same data, so it should be a fair comparison. |
| 12:57 |
* Dyrcona |
poofs out to get some lunch. |
| 13:39 |
|
kworstell_isl joined #evergreen |
| 14:36 |
|
jihpringle joined #evergreen |
| 10:17 |
Dyrcona |
I thought about setting them up to send email, then setting param, recipient_email on the events, and flooding my gmail inbox. :) |
| 10:18 |
Dyrcona |
I'm OK with no mail for now. |
| 10:18 |
sharpsie |
yeah, we have some of our servers send external mail for cron, and yes it's a flood |
| 10:19 |
Dyrcona |
yeah. I would also have to make sure that the action_tigger.params, email_recipient, or whatever, works with all of our templates. It's handy for testing. |
| 10:20 |
|
smayo joined #evergreen |
| 10:20 |
Dyrcona |
We generated well over 50,000 events on Tuesday that could have sent email. |
| 10:31 |
* Dyrcona |
tries to figure out a good way to turn 2,250 lines from a spreadsheet into a SQL upsert. Yes, it has to be SQL for ... reasons. I'm not gonna do the inserts via Perl, which makes more sense than writing a program to write SQL. :) |
| 10:51 |
Dyrcona |
Ugh. ON CONFLICT ... DO UPDATE is more complicated than it needs to be.... |
| 10:54 |
Dyrcona |
And, my test data is missing some users, but OK. The syntax is all right now. |
| 10:55 |
|
BrianK joined #evergreen |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:25 |
jeff |
fun hold quirk, probably nothing new (since ~1.2.0.4 I'm guessing): multiple outstanding holds on a title with no available copies, none have a "current copy". normal so far. check in an item, hold capture verification asks if you want to capture the item to fill a hold. say no, item is reshelving. still good/normal/expected... |
| 16:45 |
mmorgan |
Bmagic: maybe the group_application.user permission? |
| 16:46 |
Bmagic |
I'll try that |
| 16:46 |
Bmagic |
that permission is granted already at the consortium level (inherited from the "Staff" parent group) |
| 16:52 |
Bmagic |
I have a clue. I compared the osrfsys.log file when loading the web page as and admin compared to loading the page where it fails to load as my test user. And there is a small difference in the pcrud call: |
| 16:53 |
Bmagic |
CALL: open-ils.pcrud open-ils.pcrud.search.cust.atomic "REDACTED",{"-or":[{"name":["circ.holds_behind_desk","circ.collections.exempt","opac.hold_notify","opac.default_phone","opac.default_pickup_location","opac.default_sms_carrier","opac.default_sms_notify"]},{"name":["circ.send_email_checkout_receipts"]},{"opac_visible":"t"}]},{} |
| 16:53 |
Bmagic |
^^ This is when it works |
| 16:54 |
Bmagic |
the difference is the presence of "circ.send_email_checkout_receipts" in there |
| 16:55 |
Bmagic |
when using my test staff account, the pcrud call doesn't include the email_checkout_receipt call in the pcrud call. And that's what's missing, throwing the error "Empty IN list" |
| 16:56 |
mmorgan |
Bmagic: Just to clarify, are you trying to load a blank new registration page, or load an existing user? |
| 16:56 |
Bmagic |
blank registration |
| 17:01 |
* mmorgan |
just loaded the blank registration screen successfully, and doesn't see the email_checkout_receipt in the pcrud call. |
| 11:54 |
|
Stompro joined #evergreen |
| 12:31 |
|
collum joined #evergreen |
| 12:41 |
|
collum joined #evergreen |
| 12:49 |
Dyrcona |
I am testing my modified fix script on a VM with data from Sunday, so it has plenty of auto-renewals. |
| 12:51 |
Dyrcona |
Thousands of events have gone from "pending" to "collected" state, and the lock file is still there. I guess I can look at the run all pending events code to see when the first response comes back. |
| 12:52 |
Dyrcona |
My use of the same lock file does prevent my fix program from running: Script already running with lockfile /tmp/action-trigger-LOCK.daily at /usr/local/share/perl/5.30.0/OpenILS/Utils/Cronscript.pm line 151. |
| 13:12 |
|
pinesol joined #evergreen |
| 13:41 |
Dyrcona |
Hm.. maybe not "the first." It looks more like after all of the grouped events are 'found'. |
| 13:51 |
|
_collum joined #evergreen |
| 14:12 |
|
eby joined #evergreen |
| 14:16 |
Dyrcona |
I'm also testing that filter on 2-day pre-due courtesy notices that I mentioned last week. On the vm where I'm using it, it's processing about 15,000 fewer of those events than on the other. |
| 14:17 |
Dyrcona |
Guess I'll find something else to do and come back to that in an hour or so. :) |
| 14:52 |
|
berick joined #evergreen |
| 15:00 |
Bmagic |
chromeos impresses me |
| 09:23 |
|
kmlussier joined #evergreen |
| 09:42 |
|
kworstell_isl joined #evergreen |
| 09:55 |
Dyrcona |
Too many git branches.... |
| 09:58 |
Dyrcona |
Also, testing 2-day (pre-due) courtesy notices with month-old data is kind of pointless. There were 6 without the "auto_renewal_remaining: 0" filter and none with it. |
| 10:09 |
Dyrcona |
Guess that's a 100% reduction. :) |
| 10:43 |
|
BrianK joined #evergreen |
| 11:44 |
|
rfrasur joined #evergreen |
| 12:03 |
Dyrcona |
jeff: That's interesting what you point out. I would have expected an error that bar has no column 'id.' |
| 12:08 |
Dyrcona |
I suppose I could try and figure out what data from MARC is being used to build the wide_display_entry title and physical_description fields, or I could just take her word that she want the 300$n, and use 245$a for the title. :) |
| 12:09 |
Dyrcona |
My suspicion is this query will be faster if it drops the join on metabib.wide_display_entry and just grabs the data from MARC via XPath, since biblio.record_entry is already joined. |
| 12:09 |
Dyrcona |
The original is still running against my test database. |
| 12:10 |
jeff |
more detailed example that I just created: https://www.db-fiddle.com/f/9YseNbGnFVuqPkVJK85aew/0 |
| 12:16 |
jeff |
fun when "foo" is something like actor.usr or biblio.record_entry and "bar" is records_to_update or records_to_delete or the like. good reason to qualify your column references even when not forced to by ERROR: column reference "id" is ambiguous |
| 12:21 |
jeff |
I also had a recent fun one that I'll probably pick #postgresql about: I tend to favor WHERE NOT EXISTS (SELECT 1 FROM foo [...]) instead of LEFT JOIN foo ON [...] WHERE foo IS NULL for excluding things, especially if I'm not otherwise joining table foo in the query. I found at least one place where that was extremely detrimental fo my query's performance, ending up with a step where postgresql was |
| 14:09 |
|
kmlussier joined #evergreen |
| 14:13 |
|
kworstell-isl joined #evergreen |
| 15:30 |
|
mantis1 left #evergreen |
| 16:02 |
Dyrcona |
So, the unmodified version of that query has been going for over 3 hours and 12 minutes on a test database. |
| 16:21 |
Dyrcona |
Think I'll stop and try my version. |
| 16:25 |
pinesol |
News from commits: Docs: adding image for Standing Penalties docs <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=bbeeb8d42681f2d5a2419c6ed0683a34566dc832> |
| 16:27 |
|
jihpringle joined #evergreen |
| 12:26 |
|
Guest20 joined #evergreen |
| 12:43 |
|
_collum joined #evergreen |
| 12:50 |
|
jihpringle joined #evergreen |
| 13:41 |
* Dyrcona |
ponders spamming himself with 2-day courtesy notices to test the filter. |
| 13:43 |
Dyrcona |
I suppose that I can test the filter without sending email. |
| 13:47 |
Dyrcona |
Might as well wait until Tuesday, since my test database will be automatically refreshed on Sunday. |
| 14:14 |
|
jihpringle joined #evergreen |
| 14:50 |
Dyrcona |
Running a test of the filter today anyway. Set myself as recipient_email in event_params, just in case one of the vms can actually send email. |
| 15:58 |
|
Dyrcona left #evergreen |
| 15:59 |
|
Dyrcona joined #evergreen |
| 16:03 |
Dyrcona |
My date is so out of date that this test is pretty much meaningless, though the vm/database with the filter does show fewer events than the one without. Tuesday will be better because the data will be from midnight Sunday. |
| 16:03 |
Dyrcona |
My data is out of date, too. :) |
| 16:18 |
|
mantis1 left #evergreen |
| 16:50 |
|
jihpringle joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 09:08 |
|
Dyrcona joined #evergreen |
| 09:23 |
|
kworstell-isl joined #evergreen |
| 09:40 |
StomproJ |
I didn't realize bug 1862834 was a thing... we have 88 call number prefixes in use with 250 templates... lets go test that fix out. |
| 09:40 |
pinesol |
Launchpad bug 1862834 in Evergreen 3.11 "regex based url building that can match hostnames" [Medium,Confirmed] https://launchpad.net/bugs/1862834 |
| 09:41 |
StomproJ |
Ooops, bad paste buffer. I mean bug 1983156. |
| 09:41 |
pinesol |
Launchpad bug 1983156 in Evergreen "Allow Call Number attributes in Item Templates option gone" [High,Confirmed] https://launchpad.net/bugs/1983156 - Assigned to Michele Morgan (mmorgan) |
| 09:46 |
StomproJ |
So it needs the bits to save back into the template when updating the template? |
| 09:46 |
mmorgan |
StomproJ: Exactly! |
| 09:47 |
mmorgan |
Also, the standalone template editor under Local Admin DOES allow the call number attrs to get saved in the template - that interface hasn't been angularized yet. |
| 09:48 |
StomproJ |
That makes testing a bit harder, if someone cannot add that info to the prefix.... ah. |
| 09:49 |
* mmorgan |
can add some testing notes to the LP bug. |
| 09:49 |
StomproJ |
I'm seeing two actor.usr_setting types for storing templates, cat.copy.templates and staff_client.copy_editor.templates. |
| 09:49 |
StomproJ |
Is staff_client.copy_editor.templates the old XUL key? |
| 09:50 |
Dyrcona |
One of them is, and I don't remember which. |
| 09:52 |
Dyrcona |
"[T]he standalone template editor under Local Admin" this points to a problem without intending to. |
| 09:53 |
|
Rogan joined #evergreen |
| 09:57 |
StomproJ |
mmorgan, I'm in what I think is the standalong template editor, but there is no item section where the prefix can be set. |
| 10:00 |
mmorgan |
StomproJ: Just posted some testing notes: https://bugs.launchpad.net/evergreen/+bug/1983156/comments/9 |
| 10:00 |
pinesol |
Launchpad bug 1983156 in Evergreen "Allow Call Number attributes in Item Templates option gone" [High,Confirmed] - Assigned to Michele Morgan (mmorgan) |
| 10:00 |
mmorgan |
You need to set preferences in the holdings editor to get those to display. |
| 10:01 |
StomproJ |
Thanks |
| 10:22 |
mmorgan |
Hmm. Shouldn't be, unless I missed something - which is possible :) |
| 10:24 |
StomproJ |
AngularJS volcopy prefs seem to be in cat.copy.defaults - and the "Allow Call Number attributes" sets the ""show_vol_template_controls": true," json value |
| 10:25 |
StomproJ |
Angular seems to use "eg.cat.volcopy.defaults" and sets "show_vol_template_controls": true |
| 10:27 |
mmorgan |
Ok, that makes sense. So it sounds like you DO need to set the preference in the angularjs holdings editor to get the call number attributes to show in the standalone holdings editor. |
| 10:28 |
mmorgan |
Just so you can create a template to test. I can see how this is difficult to test. :-/ |
| 10:29 |
StomproJ |
Yes, but I'm making progress. I'm just adding some Call number suffix entries to make sure I try them also. |
| 10:31 |
mmorgan |
StomproJ++ |
| 10:34 |
pinesol |
News from commits: LP2028088 Fix info, primary, success button colors <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=5186c72cc0d5aa0ab142a8515697735bef6cd1b5> |
| 10:39 |
* mmorgan |
will need to take a look at that. |
| 10:41 |
StomproJ |
mmorgan, false alarm, had to log out and log in for the template change to get read. Could have been a side effect of me doing things in different tabs. |
| 10:42 |
StomproJ |
The Suffix does apply. |
| 10:42 |
mmorgan |
Ok, thanks! I have to admit, in my testing I was mostly focusing on Classification and Prefix, but thought I did try Suffix a few times :) |
| 10:43 |
StomproJ |
We don't use suffix at all either in production, but I don't want to hurt it's feelings by not testing it. |
| 10:44 |
mmorgan |
We have lots of libraries that use Prefix, many fewer that use Suffix, but it needs to work, too! |
| 10:46 |
Dyrcona |
If it is there, someone will use it. :) |
| 10:47 |
StomproJ |
I really hate that template save button being there. Gets me every time. |
| 10:42 |
Dyrcona |
s/Arc/Arch/ |
| 10:42 |
Dyrcona |
Also, busted packages lately on Ubuntu 20.04, but this is off topic. |
| 10:43 |
berick |
Arch is fun. but also, xubuntu++ |
| 10:44 |
Dyrcona |
Arch will test/improve your actual Linux chops. I've come to appreciate systemd. I still don't like, but I don't dislike it as much as I used to. :) |
| 10:58 |
Dyrcona |
I'm trying to install vanilla Gnome on Ubuntu 20.04, but package dependencies are out of sync. |
| 11:02 |
Dyrcona |
I like how apt says "you have held broken packages." But I have no held packages. Neither of the ways to check (aptmark, dpkg) say I have held packages. |
| 11:03 |
berick |
Dyrcona: maybe start w/ a server install so you don't have all that existing Gnome stuff? |
| 12:05 |
|
rfrasur joined #evergreen |
| 12:09 |
Bmagic_ |
StomproJ: I forgot about that! I'll get on it |
| 12:10 |
|
Bmagic joined #evergreen |
| 12:10 |
StomproJ |
Bmagic, it is ok, I have a test system setup now to test it. |
| 12:10 |
Bmagic |
don't need me to do anything? |
| 12:10 |
StomproJ |
Nope, but thank you. |
| 12:11 |
Bmagic |
sorry! I know I said I would do that |
| 13:38 |
kmlussier |
berick++ |
| 13:57 |
jeffdavis |
I'm trying out memcached StorageService for Shibboleth and it's not working. A shib session is being successfully created and there's a shibsession cookie in my browser that corresponds to the session ID stored in memcached, but I'm not actually logged into EG. Is there some extra mod_shib config required? I can't find much in the Shibboleth docs. |
| 14:27 |
JBoyer |
It logs you in as expected with the default backend but not memcached? |
| 14:27 |
jeffdavis |
yes, default backend works fine |
| 14:45 |
jeffdavis |
hmm, this is interesting: I click Login with SSO, enter credentials in the SSO login form, and get bounced back to the OPAC, and I am not logged in. But if I then click Login with SSO again, I *do* get logged in (without being redirected to the SSO login form). |
| 14:46 |
jeffdavis |
whereas with the default backend I'm logged in right away as soon as I'm redirected back to the OPAC |
| 14:53 |
jeffdavis |
this is on a single test server using the same local memcached that EG itself uses |
| 15:23 |
JBoyer |
That sounds vaguely familiar. Something about the target of the login link needing to be specifically /myopac rather than /login or something like that. |
| 15:25 |
|
mantis1 left #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 11:09 |
|
kmlussier joined #evergreen |
| 11:36 |
|
collum joined #evergreen |
| 11:52 |
|
Dyrcona joined #evergreen |
| 12:26 |
jeffdavis |
I'll test that EG branch for 1999823 today |
| 12:28 |
Dyrcona |
Lp 1999823 |
| 12:28 |
pinesol |
Launchpad bug 1999823 in OpenSRF "Name collision causes apache gateway modules to fail when mod_shib is installed" [Medium,Confirmed] https://launchpad.net/bugs/1999823 |
| 12:38 |
|
kworstell-isl joined #evergreen |
| 12:46 |
|
kworstell_isl joined #evergreen |
| 13:18 |
|
kworstell_isl_ joined #evergreen |
| 13:19 |
|
kworstell-isl joined #evergreen |
| 13:52 |
jeffdavis |
JBoyer++ # initial testing suggests that mod_idlchunk branch resolves the issue - need to test further before signoff but feeling pretty optimistic. Thanks! |
| 13:54 |
JBoyer |
jeffdavis++ glad to hear it. I'd like to see the rest of the files in both OpenSRF and Evergreen switch to those funcs since neither fix is committed, but at least you should have everything you need to get things going locally. |
| 13:55 |
jeffdavis |
Should I open a new bug about changing the function names everywhere, or do we want to do it as part of this bug? |
| 13:56 |
|
kworstell-isl joined #evergreen |
| 08:24 |
|
Stompro joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:58 |
|
Dyrcona joined #evergreen |
| 09:16 |
Stompro |
Since the Bug squashing week is coming up... would anyone be willing to name their test systems with the prefix eg to allow this bug #1862834 to be tested. |
| 09:16 |
mmorgan |
@coffee #evergreen |
| 09:16 |
pinesol |
Launchpad bug 1862834 in Evergreen 3.11 "regex based url building that can match hostnames" [Medium,Confirmed] https://launchpad.net/bugs/1862834 |
| 09:16 |
* pinesol |
brews and pours a cup of Hamma Cooperative Yirgacheffe, Fair-Trade Organic, and sends it sliding down the bar to #evergreen |
| 12:03 |
mmorgan |
The library that reported it says it started happening about 2 months ago. I see it in both Chrome and Firefox. |
| 12:04 |
Dyrcona |
I don't use the client or work directly with those who do. You might want to try one of the mailing lists. |
| 12:07 |
|
kworstell-isl joined #evergreen |
| 12:10 |
mmorgan |
Ok, I think I'll wait til Monday on that. I should be clear that it's happening in the angularjs pull list, I don't see the same problem in the Angular pull list. In my 3.9 and 3.11-ish tests, I entered the old url manually: https://<hostname>/eg/staff/circ/holds/pull |
| 12:28 |
|
jvwoolf joined #evergreen |
| 12:49 |
|
kmlussier joined #evergreen |
| 12:50 |
kmlussier |
Hello #evergreen and Happy Friday! |
| 13:09 |
|
jihpringle joined #evergreen |
| 13:29 |
|
bgillap joined #evergreen |
| 13:33 |
Dyrcona |
I always have to spend time in the code to (re)figure out how the hooks work.... |
| 13:39 |
* Dyrcona |
is trying to figure out why a test machine did not generate any of a certain kind of notice last night while production did with similar date. |
| 13:39 |
Dyrcona |
s/date/data/ |
| 13:41 |
Dyrcona |
Doh! It's as simple as that. The default filters were not copied/renamed. |
| 13:42 |
* Dyrcona |
tries an experiment. |
| 15:37 |
JonGeorg |
Thanks. So it's a known issue. I can at least let the libraries know that. |
| 15:39 |
Dyrcona |
JonGeorg: We removed Boost Mobile as an option for SMS in the CW MARS Evergreen installation because their gateway doesn't exist any more. |
| 15:42 |
Dyrcona |
If you're in the USA, this might help: https://en.wikipedia.org/wiki/List_of_United_States_mobile_virtual_network_operators |
| 15:43 |
Dyrcona |
You can sometimes figure out which actual provider to use for a patron's SMS by sending them test texts until one goes through. |
| 15:51 |
Dyrcona |
As for the "magic:" `cd Open-ILS/src; make ./support-scripts/marc_export` |
| 15:51 |
Dyrcona |
Then just cp it into place if you want. |
| 16:03 |
JonGeorg |
Thank you. I do have a few numbers that I keep getting bouncebacks for, but when I search for the number it comes up as not there. |
| 13:29 |
Bmagic |
I was thinking the threshold would tolerate a few log messages but not more than X number in the last hour |
| 13:30 |
Dyrcona |
Well, your filter is a program, so it can track whatever you want. Now that I think about it, it will run as the syslog user, so it would probably have to sudo or something to restart services. I've used this feature before, but not for restarting OpenSRF services. |
| 13:33 |
|
kworstell_isl joined #evergreen |
| 13:43 |
Dyrcona |
We've got some AngularJS grids, namely the holds pull list, where some fields are turning up "null" if you mouse over them or try to print the full grid. This just started after we installed the open-ils.fielder patch, however it doesn't seem to be related because it happens on a test system without the fielder patch. Does this ring a bell for anyone? |
| 13:44 |
Dyrcona |
I've also been told by a reliable source that it isn't Lp 1785260. |
| 13:44 |
pinesol |
Launchpad bug 1785260 in Evergreen "Web Client: Holds Pull List - fields blank when using "Print Full Grid" or "Download Full CSV"" [Undecided,Confirmed] https://launchpad.net/bugs/1785260 |
| 14:13 |
Dyrcona |
This is frustrating. |
