| 09:34 |
Dyrcona |
I'm running it manually now. |
| 09:36 |
Dyrcona |
Grr. Insert can have only 1 ON COnFLICT clause. I'd actually like to do something different depending on which constraint triggers. |
| 09:36 |
Dyrcona |
Totally unrelated to offline blocklist, of course. |
| 09:39 |
Dyrcona |
This mean that I can't really test this update in its entirety. I'm updating some information related to users and my test database doesn't have all of the users from production. |
| 09:40 |
Dyrcona |
i suppose I could do the insert/update with a select statement or add a where exists.... |
| 09:46 |
Dyrcona |
No? "and exists (select 1 from actor.usr where id = <user_id>) didn't help. |
| 09:46 |
Dyrcona |
Oh, duh.... |
| 09:47 |
|
redavis joined #evergreen |
| 09:47 |
Dyrcona |
Bmagic: Looks like offline-blocklist finished and the output is 18MB. |
| 09:49 |
Dyrcona |
Maybe the AND EXISTS will work if I remove the rule from the constraint... |
| 09:51 |
Dyrcona |
Nope. Do update requires inference specification or constraint name. Guess I can't really test the update, though it "worked" for the ones that existed, so it's good. Hopefully all of the users exist in production. |
| 10:01 |
berick |
hey, Ubuntu, how about I pay you *not* to advertise Ubuntu Pro at me? bleh. |
| 10:01 |
berick |
maybe time to mix up the ol' desktop OS |
| 10:02 |
Dyrcona |
berick: Have you considered Arch? I use it on my personal laptop. |
| 13:48 |
sandbergja |
+1 |
| 13:49 |
Dyrcona |
I suppose we can drop 1 of the frameworks, or at least 1 set of tests, when AngularJS is finally gone. |
| 13:49 |
sandbergja |
Oh, one test question that I've been meaning to ask forever. What is the distinction between pgtap regression tests and just regular pgtap tests? |
| 13:51 |
Dyrcona |
The regression tests are, I think, meant to check that certain database changes have not been undone. |
| 13:52 |
Dyrcona |
I added a regression test to my branch for Lp 1835953 to make sure that the columns have the not null constraint. |
| 13:52 |
pinesol |
Launchpad bug 1835953 in Evergreen "Circulation auto renewal remaining should not be nullable" [Medium,In progress] https://launchpad.net/bugs/1835953 |
| 13:53 |
sandbergja |
Dyrcona++ |
| 13:54 |
sandbergja |
I like that example! |
| 13:58 |
Dyrcona |
That branch makes a few updates to the pgtap tests and the sample data load. |
| 14:08 |
sandbergja |
3.12.1 tarball tested and it passed! |
| 14:09 |
sandbergja |
I've uploaded the release directory here: https://drive.google.com/drive/folders/1PVlPVhJ8UtUUH7Yu1JRSsJkr1TOo0Fgv?usp=drive_link -- gmcharlt: could you please upload it to lupin? |
| 14:21 |
sandbergja |
I pushed my working branch to tags/rel_3_12_1. I also added the upgrade script to the rel_3_12 and main branches. Does that seem as it should be? |
| 14:21 |
Dyrcona |
Yes, that sounds right. Let me have a look. |
| 14:22 |
sandbergja |
Dyrcona++ |
| 14:22 |
Dyrcona |
Looks good to me. I can copy the files to Lupin if gmcharlt hasn't gotten to it, yet. |
| 16:30 |
Dyrcona |
I'll have to see if I can test this tomorrow some time, but I've got stuff to do. |
| 16:34 |
Dyrcona |
I've put the release files here: https://drive.google.com/drive/folders/1Eys7BQV4TdDcgs8QtXy6XJ46QC8CMbyK?usp=sharing |
| 16:35 |
Dyrcona |
If anyone else wants to test. Also, let me know if you can't access that or the contents. It should be shared with anyone who has the link. |
| 16:35 |
sandbergja |
Dyrcona++ |
| 16:35 |
sandbergja |
I can run the automated tests on that tarball this afternoon |
| 16:36 |
Dyrcona |
sandbergja++ |
| 16:53 |
sandbergja |
It would be nice if we could make the perl live tests and nightwatch e2e tests faster too. I suspect that's a barrier to people running them regularly. |
| 17:06 |
|
jihpringle joined #evergreen |
| 15:15 |
berick |
mmorgan: i only meant we don't systematically apply pcrud perms to every pcrud-accessible class in the IDL, esp. if pcrud was not initially used to manage the class. |
| 15:46 |
|
adam_reid joined #evergreen |
| 15:55 |
adam_reid |
hey all! I've been looking at the actor.verify_passwd() function in the evergreen DB, am I understanding it correctly that I should be able to pass in (usr.id, type, password) and get a true false result? I'm playing with a little custom tool and want to require users to verfiy beforehand |
| 15:58 |
berick |
adam_reid: yes, but it's a little more complicated with 'main' passwords |
| 16:00 |
|
sandbergja joined #evergreen |
| 16:00 |
berick |
adam_reid: select * from actor.verify_passwd(1, 'main', md5((select salt from actor.passwd where usr = 1) || md5('demo123'))); |
| 16:01 |
berick |
that's my test system where admin has password demo123 |
| 16:01 |
adam_reid |
amazing, I had the feeling I was missing the use of md5, I'll try with you example. Thanks berick! |
| 16:06 |
adam_reid |
Fantastic, that worked berick! |
| 16:06 |
|
mantis1 left #evergreen |
| 09:10 |
|
kworstell-isl joined #evergreen |
| 09:42 |
|
dguarrac joined #evergreen |
| 09:50 |
|
kworstell-isl joined #evergreen |
| 10:30 |
csharp_ |
Bmagic: do y'all still have tools for LibraryIQ export that are shareable somewhere? the vendor has an outdated link to the mobius_evergreen repo... |
| 10:31 |
csharp_ |
we have a library interested in testing |
| 10:31 |
Bmagic |
yep! Let me get the link |
| 10:32 |
Bmagic |
csharp_: https://github.com/mcoia/evergreen-libraryiq-export |
| 10:38 |
csharp_ |
Bmagic++ # muchas gracias |
| 15:17 |
Bmagic |
I've decided (based on the strength of recent new installation of Evergreen 3.11.1 on PG15 for a new group of academics) that we upgrade to PG15 for anyone going to 3.11 and greater |
| 15:18 |
Dyrcona |
I wish more folks would actually look at new Pg versions. I'm playing with pg 16 and production data, now, but have no idea if it is really ready for prime time. |
| 15:19 |
Bmagic |
We have two production consortia on pg15. Been 6 weeks or so. So far it's just fine |
| 15:19 |
Dyrcona |
Also, i don't know that pg versions should really cause bad character issues in the data. We could check the release notes again. I know that we have had to adjust the creations of some indexes and update tests because of Pg changes with character set handling in the past. |
| 15:20 |
Bmagic |
the character issue may not be related. I was sort of guessing, because the PG version was something we changed between then and now. But records get added all the time too, so.... |
| 15:20 |
Dyrcona |
Those were mainly related to stripping accents in name search. |
| 15:22 |
Dyrcona |
We get wide character and other warnings during export all the time. The best is when some UTF-16 sneaks, usually copy and paste from a browser. It always seems to happen when someone copy/pastes a description from Amazon. |
| 11:48 |
jeff |
using Hatch? |
| 11:48 |
berick |
yeah |
| 11:49 |
* Dyrcona |
mumbles something about editors and indentation being adjusted automagically. |
| 11:50 |
jeff |
In the newly opened tab, before reloading the page, window.document.documentElement.getAttribute("hatch-is-open") returns null. |
| 11:51 |
jeff |
reloading the page causes it to return the expected value. |
| 11:51 |
jeff |
(and workstation fetching from Hatch works, as evidenced by the workstation appearing in the top nav) |
| 11:52 |
jeff |
might be something Windows-only. I've tested on 2+ machines running Windows 10 with Hatch 0.3.3 |
| 11:53 |
jeff |
Evergreen 3.10 and 3.12. I can reproduce on demo.evergreencatalog.com |
| 11:53 |
jeff |
Haven't tried to reproduce on Linux or macOS, mostly because we don't use Hatch on those anywhere currently. |
| 11:58 |
jeff |
interesting. it also happens when I right-click and "Open link in new window". That new window opens in the foreground, so that seems to rule out something related to background tabs or page visibility api. |
| 12:06 |
|
jihpringle joined #evergreen |
| 12:09 |
jeff |
no report in console of the new window/tab loading the Hatch relay content script. |
| 12:23 |
|
kworstell-isl joined #evergreen |
| 13:52 |
jeff |
(where "break it" is: no workstation name after the username in the top right corner; redirected to the register workstation page) |
| 13:53 |
|
dguarrac joined #evergreen |
| 13:55 |
Stompro |
jeff++ thanks for tracking this down |
| 13:58 |
jeff |
things that this seems to have had nothing to do with: background tabs, preloading/prefetch, memory/energy saving, angular routing, Chrome updates, and field tests. :-) |
| 14:12 |
berick |
jeff: hm, turns out I can reproduce in main, but not in KCLS-tweaked EG 3.9 |
| 14:12 |
* berick |
tries 3.11 |
| 14:15 |
jeff |
reproduced on Debian 11 with Chrome Stable against 3.12 (demo.evergreencatalog.com) just now. |
| 09:03 |
|
Dyrcona joined #evergreen |
| 09:13 |
|
dguarrac joined #evergreen |
| 09:28 |
|
mantis1 joined #evergreen |
| 09:38 |
* Dyrcona |
prepares to switch his main test database from pg 15 to pg 16. |
| 09:58 |
|
sleary joined #evergreen |
| 10:02 |
|
Rogan joined #evergreen |
| 10:05 |
|
jihpringle joined #evergreen |
| 15:03 |
abneiman |
#info abneiman = Andrea Buntz Neiman, Equinox |
| 15:03 |
mmorgan |
Dyrcona++ |
| 15:03 |
Bmagic |
#action mmorgan will explore moving LP stats to community site and automating same |
| 15:03 |
Bmagic |
#info sandbergja will see if gh actions can run the pgtap tests |
| 15:04 |
sandbergja |
no progress on pgtap in github actions |
| 15:04 |
|
collum joined #evergreen |
| 15:04 |
Bmagic |
#action sandbergja will see if gh actions can run the pgtap tests |
| 15:04 |
Bmagic |
#info Dyrcona will summarize release coordination discussion and followup on the development mailing list. |
| 15:04 |
Dyrcona |
#info Done! |
| 15:04 |
Bmagic |
suhweet |
| 15:08 |
pinesol |
Launchpad bug 2047707 in OpenSRF "track browser and tab for staff interface logging" [Wishlist,New] |
| 15:08 |
GalenCharlton |
upshot of that one: will help us deal with runaway pcrud explosions and general load monitoring |
| 15:09 |
Bmagic |
interesting! |
| 15:10 |
Bmagic |
I have a VM setup to test the redis branch(es), I really need to get back to that |
| 15:10 |
eeevil |
GalenCharlton: since the agenda is otherwise thin, I have a question about that! |
| 15:10 |
GalenCharlton |
eeevil: go for it |
| 15:11 |
eeevil |
do you imagine being able to make it a hard client requirement (think: soft API key) or just (for now) some extra info a client /should/ pass so we can know who's who? |
| 15:15 |
Bmagic |
There's a bug somewhere having to do with closing the tab, causing the pcrud wall-o-requests |
| 15:15 |
GalenCharlton |
ayup |
| 15:16 |
GalenCharlton |
and while I _also_ have some thoughts on ameliorating that from the Angular and AngularJS code, the ability to detect that a specific browser is spamming requests and doing a block (or even just a forced WS connection reset) would be very useful |
| 15:17 |
Bmagic |
coolio! Anyone here want to chime in on testing redis and/or adding comments on the tab-tracking proposal bug |
| 15:18 |
Bmagic |
I suppose we can move on now |
| 15:18 |
Bmagic |
#topic Documentation |
| 15:18 |
Bmagic |
dluch won't make it today. abneiman, any update? |
| 10:01 |
Dyrcona |
@blame 3a9279694aff88c4b7909fec00b50faea92212cd |
| 10:01 |
pinesol |
Dyrcona: 3a9279694aff88c4b7909fec00b50faea92212cd typed Google into Google; broke the Internet. |
| 10:02 |
Dyrcona |
So, if you encounter that configure error, it means you need to upgrade OpenSRF. |
| 10:03 |
* Dyrcona |
fires up a local vm to run pgtap tests on Pg 16. |
| 10:04 |
Dyrcona |
BTW, You can check the lib version with autotools. Not that we've been versioning libraries "correctly" either. |
| 10:07 |
Dyrcona |
Did I mention before that I find Github's new 2FA requirements to be annoying? Well, if I didn't, I do, and if I did, I still do. |
| 10:14 |
Dyrcona |
Hmm... Make a Pg 16 branch now, or test Pg 16 first? |
| 10:16 |
Dyrcona |
Upgrade an existing VM or wipe it out and start over? |
| 10:16 |
|
briank joined #evergreen |
| 10:20 |
|
sandbergja joined #evergreen |
| 11:11 |
Dyrcona |
my session was still logged in as far as I could tell. |
| 11:33 |
Dyrcona |
The Redis code has not been merged to OpenSRF main, yet? |
| 11:33 |
berick |
negatory |
| 11:34 |
Dyrcona |
If I want to test redis on a fresh install which branch should I use? |
| 11:34 |
berick |
collab/berick/lp2017941-opensrf-on-redis-v3 |
| 11:35 |
Stompro |
Bmagic, I like the look of that schemaspy.org project, the relationship diagrams are nice, and it would make schema comments visible. |
| 11:35 |
Dyrcona |
berick++ |
| 11:39 |
berick |
may be what you're thinking of |
| 11:40 |
Dyrcona |
OK. |
| 11:40 |
Dyrcona |
That is probably what I'm thinking of. I'll just the working branch. |
| 11:40 |
Dyrcona |
I plan to test Pg 16 and redis on this vm. I have redis installed elsewhere, too. |
| 11:42 |
Dyrcona |
I guess I have to time to build the base vm right now. |
| 11:42 |
|
redavis joined #evergreen |
| 11:52 |
csharp_ |
Dyrcona: re 2FA, I'm facing that issue with our local GitLab install after a recent version upgrade :-/ |
| 14:36 |
* pinesol |
grabs a bottle of Smirnoff Ice Passionfruit and sends it sliding down the bar to gmcharlt |
| 14:38 |
kmlussier |
That last one sounds promising. "... infused with a sweet tart flavor for total island vibes." Maybe gmcharlt will share. |
| 14:55 |
|
briank joined #evergreen |
| 15:08 |
Dyrcona |
OK. Here gotes the big test: eg_db_config on Pg 16. |
| 15:10 |
bshum |
Oooh cookies. Thanks kmlussier! |
| 15:12 |
Dyrcona |
bshum++ |
| 15:12 |
Dyrcona |
kmlussier++ |
| 15:13 |
Dyrcona |
And, it just works. |
| 15:15 |
Dyrcona |
pgtap tests succeed. |
| 15:21 |
kmlussier |
bshum: I knew you would like those! :) |
| 15:24 |
berick |
Dyrcona: arg, good catch |
| 15:24 |
berick |
re: hosts |
| 15:32 |
|
jihpringle joined #evergreen |
| 15:33 |
Dyrcona |
I bet I accidentally edited the .example file after copying. |
| 15:34 |
Dyrcona |
Yeah. That's what happened. The files are identical. |
| 15:34 |
Dyrcona |
Perl tests succeed, too. |
| 15:35 |
Dyrcona |
Think I'll switch from Pg 15 to Pg 16 as the main database on my test server. |
| 15:38 |
Dyrcona |
Maybe next week. I should read the release notes again for any gotchas. |
| 17:05 |
|
mmorgan left #evergreen |
| 17:15 |
|
kmlussier left #evergreen |
| 09:02 |
|
dguarrac joined #evergreen |
| 09:14 |
|
mantis1 joined #evergreen |
| 09:16 |
Dyrcona |
I've noticed that with psql 16, \df+ <function> no longer shows the function definition. |
| 09:22 |
Dyrcona |
I had to use \ef <function> to open it in a test editor, which gives you the SQL used to create the function. |
| 09:24 |
Dyrcona |
Interesting... psql 10 gives an error when doing \df+ on a pg 15 database. I wonder if \df+ from psql 16 works on a Pg 16 database. It probably does. |
| 09:25 |
* Dyrcona |
loads a dump into pg 16 to see what happens. |
| 09:26 |
Dyrcona |
Heh... "Talk Soup" by Weird Al just started playing.... :) |
| 09:26 |
mantis1 |
talksoup++ |
| 09:27 |
Dyrcona |
"Listen to me! Listen to me! Listen to me!" :P |
| 09:30 |
* Dyrcona |
updates a script for pg 16 on the test db server. |
| 09:32 |
Dyrcona |
Whee! Just copy, paste, and edit 3 lines. |
| 09:35 |
JBoyer |
Dyrcona, so long as you specify enough params to uniq-ify it, \sf should show you the function source |
| 09:35 |
JBoyer |
(similar to \df+ I mean) |
| 09:35 |
Dyrcona |
JBoyer: OK. I was going to check with psql 16 on a pg 16 database because I think its an issue client server mismatch and not a change in features. |
| 09:36 |
JBoyer |
Oh, I see what you mean. Yeah, the queries backing that feature may have changed / broken / been removed in psql 16. |
| 09:36 |
Dyrcona |
Now that I have used it, I think I prefer \ef, at least when I'm running psql locally and talking to a remote server. |
| 09:37 |
Dyrcona |
I also plan to finally get around to adding Pg 16 support for Evergreen, so this will be a good first test. |
| 09:43 |
Dyrcona |
I suppose it is a good sign that pg_restore has not produced any output to the screen. |
| 09:43 |
|
smayo joined #evergreen |
| 09:51 |
|
BDorsey_ joined #evergreen |
| 12:28 |
|
jvwoolf joined #evergreen |
| 12:55 |
|
sleary joined #evergreen |
| 13:28 |
|
smayo joined #evergreen |
| 13:38 |
csharp_ |
Dyrcona: I tested out all but one of the LP scripts you shared and with a couple of Python 3-ish changes, they appear to work |
| 13:39 |
csharp_ |
the release.py one is untested since it appears to make changes and I wanted to get my head around it first |
| 13:39 |
csharp_ |
smayo may do some work on things too - we're still in research mode to make sense of the release process |
| 13:47 |
|
jvwoolf joined #evergreen |
| 13:58 |
|
dguarrac_ joined #evergreen |
| 14:11 |
|
mdriscoll joined #evergreen |
| 14:20 |
|
mdriscoll joined #evergreen |
| 14:25 |
mdriscoll |
I want to copy some patrons from a production system to a test system and I need their password to work. I have the password hash but not sure how to do the insert so the password works and isn't set to literally 'd41d8cd98f00b...' Any ideas? |
| 14:31 |
|
mdriscoll joined #evergreen |
| 14:34 |
jeff |
mdriscoll: that looks like the start of the md5 hash of an empty string. you'll probably want to take a look at the actor.passwd table. |
| 14:36 |
jeff |
mdriscoll: if you copy a user's row from actor.usr and actor.passwd (and actor.usr_address, actor.card, etc), then the copied user on the test system should end up with the same password as on the source system. |
| 14:39 |
mdriscoll |
jeff: thanks. I think actor.passwd is the part I was missing. |
| 14:41 |
jeff |
mdriscoll: depending on how empty your test system db is, you may need to worry about conflicts, renumbering ids, etc. Even if you don't, consider that if you manually insert ID values, you'll want to either bump sequences or know that eventually you'll run into an error when some future insert gets that manually-inserted value from its default sequence. |
| 14:42 |
jeff |
(depending on what kind of a test system this is, and how long it will be around, and other things, you may not care) |
| 14:48 |
mdriscoll |
jeff: I'm altering a script I use for loading patrons where I usually set the password and let the database trigger crypt the plain text. I let the database create the new ids but duly noted about bumping sequences. |
| 15:01 |
|
mmorgan1 joined #evergreen |
| 15:10 |
|
smayo joined #evergreen |
| 11:01 |
Rogan |
btw, I'm not in that cage match - if your editor works for you then power to you :) |
| 11:01 |
Rogan |
heh |
| 11:02 |
berick |
by the same token, a couple of git checkout commands are gravy compared to the rest of the eg/osrf install docs. |
| 11:03 |
Rogan |
and I've made use of berick's ansible scripts to automate it when wanting to just throw something up quick(ish) for testing |
| 11:05 |
berick |
but tarballs have pre-compiled / pre-downloaded stuff, so it's more than just a checkout, of course. |
| 11:18 |
csharp_ |
mantis1: just a quick warning about virtualbox (or any VM running on a PC/laptop) - make sure the RAM is sufficient to run a VM that takes 4GB RAM minimum, and probably 2 CPUs |
| 11:20 |
csharp_ |
mantis1: at GPLS we used to repurpose older servers or even PCs to run as a dedicated VM host, but that might be a rabbit hole |
| 12:16 |
mantis1 |
but it's good now: https://docs.google.com/forms/d/e/1FAIpQLSfjPGS3IZYkJxNZslkYaUYfwX24QxXRktrDvALM6E1jQZfGhQ/viewform?usp=sf_link |
| 12:19 |
berick |
mantis1: thanks! |
| 12:22 |
csharp_ |
mantis1++ |
| 12:24 |
bshum |
mantis1: I'll be curious if 4 GB of RAM Is sufficient for a small test VM. I feel like I was bumping up on problems last time I sized something that small, and it worked better with 6-8 |
| 12:25 |
bshum |
Might just be my tricky memory. |
| 12:25 |
mantis1 |
berick++ |
| 12:25 |
mantis1 |
bshum: we did allocate more ram out I believe but I'll send an update on specs and how this goes |
| 12:25 |
csharp_ |
bshum: you're probably right, but I'm guessing the RAM on a typical laptop/PC is maybe 8GB? and Windows is a hog |
| 12:26 |
csharp_ |
(assuming we're talking about Windows 10/11 prolly?) |
| 12:26 |
bshum |
csharp_: Oh certainly. Windows :P |
| 12:26 |
Dyrcona |
With KVM on a Linux host 4GB is enough for basic testing. If you really want to do something with it, you'll need more RAM. |
| 12:26 |
bshum |
@karma Microsoft |
| 12:26 |
pinesol |
bshum: Microsoft has neutral karma. |
| 12:29 |
csharp_ |
given Microsoft's relatively recent tolerance and sometimes support of open source software, they don't get as much negative karma from me as they used to :-) |
| 15:11 |
|
mantis1 left #evergreen |
| 15:28 |
|
Stompro joined #evergreen |
| 15:35 |
JBoyer |
Looking forward to the forthcoming gaming soundtrack from Character Limit Break |
| 15:46 |
pinesol |
News from commits: LP#2044141 (follow-up) tweaks to OPAC tests GitHub action <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=631c7be752a7c9f5d5b91e26d24be949d0c7a4ea> |
| 15:46 |
pinesol |
News from commits: LP2044141: Run javascript unit tests in github actions <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=514ad0c2c1b845d501a820d0d28b4fe2caede1e7> |
| 16:16 |
pinesol |
News from commits: LP#2046970 Poorly Cropped Reports Icon <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=db508c9037a44cc08dcf0a9f1ef102a70fe3542d> |
| 17:15 |
|
jihpringle joined #evergreen |
| 17:16 |
|
mmorgan left #evergreen |
| 10:07 |
* mmorgan |
would love to see item templates moved to the database - maybe to that very table! |
| 10:08 |
Dyrcona |
I thought they were in user settings? That's bib templates, isn't it? |
| 10:26 |
Dyrcona |
Is there a standard for the miscellaneous.adoc file under RELEASE_NOTES_NEXT? |
| 10:32 |
Dyrcona |
Hmm.. I could add a PgTap regression test or something like that. Might as well. |
| 10:40 |
Dyrcona |
Apparently, one can only check if a column constraint exists and not its definition? |
| 10:42 |
mmorgan |
Dyrcona: Yes, item templates are in user settings in a big blob per user. Tough to manage. Bib templates moved to the db would be good also. That's bug 1131238. |
| 10:42 |
pinesol |
Launchpad bug 1131238 in Evergreen "Move MARC templates into the database" [Wishlist,Triaged] https://launchpad.net/bugs/1131238 |
| 10:43 |
Dyrcona |
mmorgan: I remember that bug. :) |
| 10:44 |
Dyrcona |
I guess I'll give up on a regression test since it won't be easy to do what I want. I'll just specify that one should check the table definition before and after applying the patch. |
| 10:59 |
|
smayo joined #evergreen |
| 11:08 |
Dyrcona |
We should take some time to go through the bugs to find those that are "lost." I'm just looking at the ones with patches right now, and I see a few that might need some attention. |
| 11:39 |
Dyrcona |
Some bugs have had folks assigned to them for a long time, and I wonder if the bugs are still being looked at. |
| 09:55 |
|
dguarrac_ joined #evergreen |
| 11:03 |
|
sandbergja joined #evergreen |
| 14:03 |
|
sandbergja joined #evergreen |
| 14:10 |
Dyrcona |
So, I think I found a bug in SuperCat while testing my changes. I don't think I wrote this bug, either. It looks like there is insufficient fleshing for stat cat entries. |
| 14:12 |
Dyrcona |
/opac/extras/supercat/retrieve/marcxml/acp/<copy_id> Gives an internal server error and the error message indicates that the stat cat entries are not fleshed: Can't locate object method "opac_visible" via package "3" (perhaps you forgot to load "3"?) |
| 14:12 |
Dyrcona |
And, yeahp. They aren't fleshed properly. |
| 14:23 |
Dyrcona |
Then, I sometimes wonder if I get the URI correct because some of these are producing 500 errors with nothing useful in the logs. |
| 14:49 |
|
Rogan joined #evergreen |
| 14:51 |
Dyrcona |
Yeah. Guess I'lll have to Lp that. Adding asce => [qw/stat_cat/] to the "flesh" list in two places fixes it. |
| 14:51 |
mmorgan |
Dyrcona++ |
| 14:55 |
Dyrcona |
It's hard to test your own changes when you encounter other bugs. :) |
| 14:56 |
Dyrcona |
This means my feature branch will likely need a rebase before it can be merged if the bug fix goes in first. |
| 15:18 |
Dyrcona |
Yeah, I made my local fix based on my feature branch and I get a conflict cherry-picking the change to a clean branch base on main. :) |
| 15:27 |
Dyrcona |
Well, that's interesting. The stat cats are empty even though it doesn't crash. Guess it needs more work. |
| 11:16 |
|
sleary_ joined #evergreen |
| 11:25 |
|
jihpringle joined #evergreen |
| 11:42 |
|
jvwoolf joined #evergreen |
| 12:05 |
Bmagic |
does it make sense to anyone that a text message would make it to the cell phone using the test feature in the my account opac for one account but not another account. Using the same phone number and carrier on both accounts? |
| 12:06 |
jvwoolf |
Same sending address for both? |
| 12:06 |
Bmagic |
yep, same server |
| 12:07 |
Bmagic |
I can see the process all the way through, and the mail logs in one case is "Sent" and the other is "Service Unavailable" |
| 12:27 |
kmlussier |
I am very much looking forward to the day when we no longer send our texts that way. NOBLE has been looking at other options for the past couple of months. |
| 12:27 |
jeff |
That answer doesn't help you solve the problem, but hopefully it helps confirm that there may be no clear reason other than you're hitting rate limits and spam filters and intentional brownouts/deegredations of the target service. |
| 12:31 |
jeff |
we spend on average a little over $0.01/message to not have to worry about it. |
| 12:38 |
Bmagic |
ok, it was a differenting sending address. haha. The two accounts were attached to two different org units, and the test template walks up the org tree to find an accosiated email address, and found one that isn't allowed to sen through our relay. Mystery solved |
| 12:38 |
Bmagic |
phew, I was losing my mind |
| 12:39 |
jeff |
phew. next time, keep the above in mind also. :-) |
| 12:40 |
jeff |
my understanding is that time of day can also influence carrier SMTP to SMS gateways. |
| 10:00 |
|
jvwoolf joined #evergreen |
| 10:00 |
|
sleary joined #evergreen |
| 10:12 |
|
sandbergja joined #evergreen |
| 10:16 |
csharp_ |
Bmagic> Dyrcona: Just testing my tarball, and I got this while building the old concerto set: psql:assets_concerto.sql:58: ERROR: update or delete on table "record_entry" violates foreign key constraint "browse_entry_def_map_source_fkey" on table "browse_entry_def_map" |
| 10:16 |
csharp_ |
terranm saw that same error yesterday - currently trying to reproduce it |
| 10:18 |
csharp_ |
and.... no, I can't reproduce it on 3.12.0 |
| 10:18 |
csharp_ |
(from git, not tarball, if that matters) |
| 10:21 |
Bmagic |
csharp_++ |
| 10:22 |
Bmagic |
I don't think the build process messes with the concerto set, but, of course, the base schema build is there in the rel_11 branch. I would think that if there was an issue with the schema, the enhanced concerto would have the problem too |
| 10:36 |
|
redavis_reboot joined #evergreen |
| 16:22 |
adam_reid |
ok, thats fair, so does Evergreen need to be aware of the page earlier in the process? |
| 16:22 |
jeff |
just the tt2 bits, or Evergreen variables/functions also? |
| 16:23 |
jeff |
do you have the tt2 source somewhere? that would answer some of the questions. it sounds like public data? |
| 16:23 |
adam_reid |
I'm not 100% the difference, I think just the tt2 bits |
| 16:24 |
adam_reid |
no source anywhere yet, to test the idea I basically just made a blank test page, I assumed it would resolve but didn't expect to be asked to login by default |
| 16:24 |
jeff |
which path did you put it at? |
| 16:25 |
adam_reid |
at the time /openils/var/templates_custom/opac/test.tt2 |
| 16:26 |
adam_reid |
I figured if the simple test worked I would start to see what was possible, the page was essentially blank, once logged in everything worked fine, pulled in a few carousels and they worked |
| 16:26 |
adam_reid |
just didn't want users to need to log in |
| 16:30 |
terranm |
I'm not 100% certain, but you may need to add it into EGCatLoader.pm to route |
| 16:31 |
terranm |
Example - https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=fc361eeb6759c7af074b14f8faa9b9c4d37bbb77 |
| 16:34 |
adam_reid |
interesting... right, seems that addition would've required a similar setup, looks like a great place to start looking, THANKS terranm |
| 16:39 |
jeff |
depending on your needs, you can drop a tt2 file in a place outside of the opac dir, like (using your example above) /openils/var/templates_custom/local/test.tt2 |
| 16:40 |
jeff |
(without needing to define a route, etc) |
| 16:41 |
terranm |
jeff++ |
| 16:44 |
* JBoyer |
Eg tarballs rebuilt, uploaded, and updated. |
| 16:44 |
adam_reid |
interesting, thanks jeff. I'll play around with that too! |
| 09:26 |
Dyrcona |
sandbergja++ |
| 09:28 |
* Dyrcona |
ponders how much the PHP Evergreen objects should resemble their Perl counterparts.... There are two ways I could implement property access, and one is similar to the Perl way, the other is more like public property access. I could do both. |
| 09:30 |
jmurray-isl |
For some reason, the concept of "PHP Evergreen objects" leaves a bad taste. |
| 09:32 |
Dyrcona |
jmurray-isl: I have reasons for implementing Evergreen client code with PHP, mainly to do with testing Aspen code changes. I'm going a bit farther than I might actually need to go and implementing actual classes for a client, fieldmapper, requests, objects, and probably another to represent class metadata. |
| 09:38 |
pinesol |
News from commits: Docs: release notes for 3.11.2 <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=82d206eebd22b89a9ea002cb58188adf1c84169d> |
| 09:39 |
jmurray-isl |
Dyrcona: I get it. It's mostly just the principle for me. |
| 09:41 |
Dyrcona |
jmurray-isl++ |
| 09:46 |
jmurray-isl |
Indeed. |
| 09:47 |
Dyrcona |
CLI programming in PHP is a different thing, and it's easier/better in some ways. |
| 09:48 |
jmurray-isl |
Agreed. My initial work with VuFind was pre-Zend. The cli harvest scripts were much easier to troubleshoot. |
| 09:51 |
Dyrcona |
I kind of like using the interactive mode (aka REPL) for testing code. The only problem is having to restart when I change a class definition. (In Lisp, I can just reload the file and it will replace the existing code definitions.) |
| 09:54 |
sandbergja |
Dyrcona: 3.10.4 release notes pushed |
| 09:56 |
Dyrcona |
sandbergja++ |
| 09:56 |
mmorgan |
sandbergja++ |
| 11:28 |
Dyrcona |
Looks like just --disabled-password. |
| 11:28 |
|
mantis1 joined #evergreen |
| 11:30 |
Dyrcona |
yeah, i know... I should script this with ansible. |
| 11:40 |
kmlussier |
Dyrcona: On the other hand, it's always good to have an opportunity to test the steps in the README. |
| 11:46 |
Dyrcona |
Oof. have to start over. I started installing prerequisites for the wrong branch. |
| 11:53 |
Dyrcona |
Maybe another burrito will help? |
| 11:58 |
|
jihpringle joined #evergreen |
| 14:08 |
pinesol |
News from commits: Docs: final updates to 3.12 release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=807fb5cf59f4ba65a4d668cfbf87627fbf36ebb9> |
| 14:10 |
|
jvwoolf joined #evergreen |
| 14:14 |
jmurray-isl |
win 2 |
| 14:16 |
Dyrcona |
Live tests are failing. Guess I'll need to figure out what I did wrong. |
| 14:18 |
Dyrcona |
heh. --load-all-sample might help. :) |
| 14:23 |
Dyrcona |
yeah, that's much better. |
| 14:33 |
|
jihpringle joined #evergreen |
| 16:09 |
pinesol |
News from commits: LP2046362 Button type for staff portal catalog search <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=533b9e5bcc11dc99bd5a0d1393bb8a46934c7d18> |
| 16:09 |
pinesol |
News from commits: Forward port 3.10.3 to 3.10.4 db upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b6d73efaac01e2604d6871d1bcf704b4fcb41f14> |
| 16:18 |
|
smayo joined #evergreen |
| 16:20 |
Bmagic |
Dyrcona: Just testing my tarball, and I got this while building the old concerto set: psql:assets_concerto.sql:58: ERROR: update or delete on table "record_entry" violates foreign key constraint "browse_entry_def_map_source_fkey" on table "browse_entry_def_map" |
| 16:21 |
Bmagic |
oops, Dyrcona's not here |
| 16:27 |
Bmagic |
enhanced concerto loaded ok though |
| 16:27 |
Bmagic |
not sure if that's "ok" but I've put the tarball on the web server (I think that the concerto issue isn't related to the tarball) |
| 15:10 |
mmorgan |
No updates this month due to release business, but I'm fine with keeping it as an action item. |
| 15:10 |
Dyrcona |
#action mmorgan will explore moving LP stats to community site and automating same |
| 15:10 |
Dyrcona |
OK. Carrying it forward. |
| 15:11 |
Dyrcona |
#info sandbergja will investigate getting more tests into gh actions |
| 15:11 |
sandbergja |
bug 2044141 adds the OPAC js tests to run in github actions |
| 15:11 |
pinesol |
Launchpad bug 2044141 in Evergreen "Run OPAC javascript unit tests in github actions" [Undecided,New] https://launchpad.net/bugs/2044141 |
| 15:11 |
Dyrcona |
Awesome sauce. |
| 15:11 |
sandbergja |
I'm interested in seeing if gh actions can run the pgtap tests next |
| 15:12 |
Dyrcona |
#info bug 2044141 adds the OPAC js tests to run in github actions |
| 15:12 |
sandbergja |
I'm okay keeping this item assigned to me |
| 15:12 |
Dyrcona |
I was just about to ask. |
| 15:12 |
Dyrcona |
#action sandbergja will see if gh actions can run the pgtap tests |
| 15:13 |
Dyrcona |
Ok. Unless anyone has anything else to say about previous action items, I'll move on to |
| 15:13 |
Dyrcona |
#topic OpenSRF Releases |
| 15:13 |
Dyrcona |
#info OpenSRF 3.2.4 and 3.3.0-beta released 2023-12-05 |
| 15:13 |
|
smayo joined #evergreen |
| 15:14 |
Dyrcona |
I would post a link to the email, but I think that got trickier recently. |
| 15:14 |
JBoyer |
I'm planning to take a look at the beta for some testing soon |
| 15:15 |
Dyrcona |
I've been using the main branch on most of my test systems so far, so I guess I'm using the beta now... I'll check and make sure. |
| 15:16 |
Dyrcona |
i added to the next topic before the meeting, so if you haven't yet, you might want to reload the agenda in your browser. |
| 15:16 |
Dyrcona |
#topic Evergreen Releases |
| 15:16 |
Dyrcona |
#info Evergreen 3.12 release candidate available 2023-12-06 |
| 16:08 |
Dyrcona |
Two would be all of them, woudn't it? |
| 16:08 |
JBoyer |
I'm not sure voting will do much unless a "yes" vote is taken as volunteering to take part |
| 16:09 |
JBoyer |
and yes, it's just 3.10.4 and 3.11.2 tomorrow |
| 16:09 |
Dyrcona |
jeff: That's possible already. I've done it for test releases. |
| 16:09 |
JBoyer |
(or whenever) |
| 16:09 |
jeff |
Dyrcona: good! it's possible that no "ensuring" is needed. |
| 16:09 |
Dyrcona |
I'll volunteer to build and upload 3.10.whatever, if we can get other roles fileld. |
| 08:58 |
|
kmlussier1 joined #evergreen |
| 09:08 |
* Dyrcona |
should implement a Fieldmapper that doesn't depend on OpenSRF being installed. |
| 09:16 |
Dyrcona |
Guess I'll just copy the Aspen PHP code today because I want to play with enhancements to the Aspen Evergreen driver. |
| 09:17 |
Dyrcona |
And.... I don't want to install Aspen to test things before submitting pull requests. |
| 09:24 |
Dyrcona |
Oh, nifty.... Aspen looks up each class from the IDL as it needs it, but caches the results in memcached. I was gonna just grab the whole IDL at the start of a program and parse it. |
| 09:27 |
Bmagic |
Dyrcona++ |
| 09:41 |
|
dguarrac joined #evergreen |
| 12:41 |
Dyrcona |
Yeah, search and replace was faster to do. |
| 12:42 |
|
smayo joined #evergreen |
| 12:59 |
|
smayo joined #evergreen |
| 13:01 |
* Dyrcona |
caused a deadlock on a test database. yay..... whatever.... |
| 13:42 |
|
jihpringle joined #evergreen |
| 13:43 |
Dyrcona |
There are two URLs where one can get the IDL aren't there? |
| 13:46 |
Dyrcona |
Oh, right. |
| 15:26 |
|
mantis1 left #evergreen |
| 15:30 |
Dyrcona |
"They say these days are made of rust..." Or should that be Rust? Eh, berick? |
| 15:33 |
Stompro |
I'm looking at how Aspen categorizes things as fiction/non-fiction... and it categorizes poetry as Fiction by default? Which seems wrong for how Libraries usually categorize things. |
| 15:33 |
Dyrcona |
Command line programming with PHP: I don't recommend it if you don't need to for some crazy reason... like oh, testing the Aspen Evergreen driver without installing Aspen. |
| 15:35 |
Dyrcona |
Stompro: Most of that comes from the MARC, I wager. Not sure if poetry can also say "fiction" in the coded values/wherever that lives, but I've seen lots of crazy stuff in MARC records over the years...decades. |
| 15:36 |
Dyrcona |
Come to think of it, I don't recommend web programming with PHP, either. |
| 15:36 |
Dyrcona |
:) |
| 08:16 |
|
BDorsey joined #evergreen |
| 08:32 |
|
Dyrcona joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:54 |
Dyrcona |
Do the Angular and AngularJS tests work with Firefox and Chromium snaps? |
| 08:58 |
Dyrcona |
Apparently not: Firefox have not captured in 60000 ms, killing. |
| 08:59 |
Dyrcona |
snaps-- |
| 09:02 |
|
mantis1 joined #evergreen |
| 09:07 |
mantis1 |
I have commands for it but just wanted to check before I try |
| 09:08 |
Dyrcona |
You can remotely delete branches if you own them. |
| 09:09 |
mantis1 |
Drycona++ |
| 09:20 |
Dyrcona |
How long should the nightwatch tests run? I suspect that they're not working with the firefox snap. |
| 09:20 |
|
dguarrac joined #evergreen |
| 09:32 |
Dyrcona |
Maybe it was doing something. I see output in logs/. |
| 09:44 |
Dyrcona |
Yeah. ng e2e works with the Firefox snap. |
| 15:12 |
pinesol |
berick: go with Canapés |
| 15:13 |
Dyrcona |
csharp_++ I'll have to investigate Iron & Wine. |
| 15:15 |
Dyrcona |
Oh, I guess my other mistake was "CASE" after "END" in a values list. Postgres complained about the syntax. |
| 15:17 |
Dyrcona |
I suppose I should come up with some pgtap tests for the db changes. |
| 15:20 |
Dyrcona |
Now that I think about it, those two commits might be wrong. The auto_renewal column isn't used to mean auto-renewal is allowed. It means that the renewal was an auto-renewal, doesn't it...... |
| 15:23 |
mantis1 |
Question on this commit: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=fb7e31fd790074a1b62c882913395400223556ad |
| 15:23 |
mantis1 |
I would like to remove the po files from the commit. What I have been doing is git rm <file> after checking out the working branch locally then saved the commit, but after I pushed, the files remained |
| 15:49 |
Dyrcona |
"As we get older...Stop making sense. You won't find her waiting long...." |
| 15:50 |
Dyrcona |
Talking Heads come around on the shuffle again. |
| 16:23 |
Dyrcona |
t/regress/lp1773452_copy_state_post_checkin.pg:11: ERROR: null value in column "auto_renewal_remaining" of relation "circulation" violates not-null constraint |
| 16:23 |
Dyrcona |
Looks like I get to update another test, too. |
| 16:28 |
Dyrcona |
But, wait! There's more! |
| 16:32 |
Dyrcona |
I bet I've broken some perl tests, too. I'll have to check those tomorrow. |
| 16:35 |
Dyrcona |
it's gonna be fun going through the circ and staff client code making sure that the auto_renewal fields actually get a value put into them. I suppose i could cop out and add 'default 0'. |
| 16:36 |
Dyrcona |
pgtap tests have been updated at least. |
| 16:38 |
Dyrcona |
Might be strange for me to say this, but we need more tests. |
| 17:09 |
|
mmorgan left #evergreen |
| 10:19 |
berick |
sandbergja: branch updated. thanks for the heads up. |
| 10:19 |
sandbergja |
Thanks, berick! |
| 10:20 |
|
collum joined #evergreen |
| 10:27 |
Dyrcona |
I sometimes think our triggers are out of hand. I'm updating tcn_source on 10,000 bib records and according to ps it's using 16GB of RAM and 88% of a CPU on my test database. |
| 10:27 |
Dyrcona |
I'm pretty sure it's mostly being used by the maintain 901 trigger, which is actually why I am doing this. |
| 10:32 |
Dyrcona |
I wonder if using a transaction and deferring all triggers would help with the speed of this? |
| 10:36 |
Dyrcona |
Actually, it's probably smple rec and some of the other triggers, too. I'm not sure I want to disable simple rec in a transaction. I'll have to investigate the triggers a bit more. |
| 10:40 |
pinesol |
News from commits: LP1850473 (follow-up): Update DOM selector in nightwatch test <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=bddc372d27e4ac9298ef6d265534c3b14529b2a2> |
| 10:41 |
Dyrcona |
No, I don't want to disable any triggers. It would lead to locking and possible dead locks. Setting session replication role is overkill since it disables all triggers. |
| 10:45 |
Dyrcona |
Looks like the ingest triggers are getting fired, too, but they.... Oh wait. The marc changes.... |
| 10:53 |
Dyrcona |
Trying different batch sizes, with a limit on a subquery, It did 10 in 5 seconds 100 in 26 seconds and 1000 took 4 minutes 23 seconds and used a lot more memory. |
| 13:27 |
Dyrcona |
--csv option to psql doesn't properly quote strings apparently. |
| 13:28 |
Dyrcona |
ha! I'm not paying enough attention. LibreOffice had a "from row" 1322 still set on the CSV import from the other day. |
| 13:30 |
Dyrcona |
The delete was attempted multiple times. |
| 13:59 |
csharp_ |
Dyrcona: waiting can be just waiting - becomes a deadlock when two processes start waiting on each other |
| 14:00 |
csharp_ |
but seems like a matter of time - I'm nervously watching a very slow parallel reingest on a test server and many of the PG procs are in "waiting" state |
| 14:01 |
csharp_ |
reingest began ~11:30 a.m. yesterday - a little over half done per the batch count |
| 14:07 |
Dyrcona |
csharp_: My case was nearly catastrophic. Cascading deadlocks stemming from a process trying to delete a staff account with thousands of owned records. It was acquisitions account. The person doing the delete tried it at least 3 more times after the first timed out in the client. |
| 14:10 |
Dyrcona |
This sort of thing used to happen so much in Horizon with Sybase, that I made a little GUI in Java to show me the deadlocked processes. From that I could identify the most likely culprit process. I could then click its row in the table, type Ctrl-k and that would send the Sybase equivalent of pg_cancel_backend. Every now and then, I consider adapting that to PostgreSQL and Evergreen. |
| 14:13 |
Dyrcona |
Looks like someone was also loading MARC order records at the same time. I may have clobbered their backend process, not sure. I tried to only cancel the delete_usr queries. |
| 14:23 |
Dyrcona |
Speaking of long-running processes my update of tcn_source on 530,105 bibs where it is '' has been running for 1day, 5 hours, and 27 minutes at this point. |
| 14:25 |
Dyrcona |
Fortunately, that is on a test system, or I'd have probably had to cancel it for deadlocks. |
| 14:29 |
|
smayo joined #evergreen |
| 14:58 |
|
jonadab joined #evergreen |
| 15:01 |
csharp_ |
Dyrcona: holy moly |
| 13:49 |
kmlussier |
jeffdavis: When I started, the community was on 1.6. I remember at our first MassLNC meeting, Dyrcona was telling us we should all be looking to migrate to 2.0 because it would have all the new stuff coming with the KCLS grant. In the end, we went live with later releases, but I can't forget all the hype around that one particular release. |
| 13:49 |
kmlussier |
3.5 doesn't seem long ago to me because it happened after I left. |
| 14:00 |
Dyrcona |
For us 3.5.3 was April of 2021. I had a quick look at our old 3.5.3 branch and didn't see anything in the DB upgrade. I bet there was a patch to Vandelay or something like that. |
| 14:05 |
Dyrcona |
I think I'm going to have to postpone my fix test until Monday at the latest. It doesn't look like my script to dump the pretest data for later comparison with post-test data is going to finish in a reasonable time. |
| 14:06 |
Dyrcona |
My test db refreshes this Sunday morning, so I'd have to do this all over again anyway. |
| 14:09 |
Dyrcona |
The '80s were just 20 years ago, right? :) |
| 14:13 |
kmlussier |
Dyrcona: Yes, they absolutely were. Please don't tell me any differently. |
| 14:13 |
kmlussier |
And I'm still 39 years old. |
| 09:22 |
|
Dyrcona joined #evergreen |
| 09:39 |
Dyrcona |
due_date: "3812-01-17 23:59:59-05" Sure, that's plausible. |
| 09:40 |
mmorgan |
:) |
| 09:41 |
Dyrcona |
And, it looks like a test or someone was messing with due dates. It was checked in in 2018. |
| 09:41 |
mmorgan |
Or a barcode got scanned into the due date field? |
| 09:42 |
Dyrcona |
mmorgan: That might be a possibility. 38120 looks like a valid item barcode prefix for Massachusetts. |
| 09:43 |
Dyrcona |
I think I need to do something more sophisticated than just select max(due_date) from action.circulation; :) |
| 09:43 |
Bmagic |
jeffdavis: are you working on SSO for Evergreen staff client? |
| 09:44 |
Dyrcona |
I'm looking for things I can renew in my test database with a script to try out the osrf-gateway-v1. |
| 09:44 |
Dyrcona |
I can wait until next week. The data should be refreshed on Sunday. |
| 09:51 |
Dyrcona |
Think I'll give it a shot anyway. |
| 10:03 |
Dyrcona |
Hm. Left joins with a where clause on "right_table.columns is null" seem to be a lot faster in Pg 15 than in Pg 10. |
| 11:14 |
csharp_ |
eeevil: yeah, I didn't consider FTPS in my branch |
| 11:14 |
csharp_ |
eeevil: yeah, that's a mistake - shouldn't have removed libnet-ssh-perl |
| 11:14 |
eeevil |
well, yes, but just on the SFTP addition, it removes (it looks like) SSH support |
| 11:14 |
csharp_ |
sorry libnet-ssh2-perl |
| 11:15 |
csharp_ |
I removed it in the makefiles but still call it in the perl - that would have been caught in the fleetingist of testing |
| 11:15 |
eeevil |
right, it might still get installed as a dep, which would be fine |
| 11:15 |
csharp_ |
yeah |
| 11:16 |
eeevil |
but, it looks like pure ssh2 support gets broken |
| 11:20 |
Dyrcona |
Net::STFP::Foreign does not use libnet-ssh-perl unles you tell it to. That's actually the point of Net::SFTP::Foreign. It defaults to using the sftp client on the host. |
| 11:21 |
* Dyrcona |
uses Net::SFTP::Foreign in several utility scripts. |
| 11:22 |
Dyrcona |
berick++ jeff++ Thanks for the answers. I thought I was missing a couple. |
| 11:23 |
Dyrcona |
I have another question, but I'll check the code, too. I think it's possible to login with user id and not barcode or username, right? I'm working on a program to test OPAC renewals through osrf-gateway-v1, in case anyone missed it. |
| 11:23 |
csharp_ |
eeevil: are you looking at the latest I pushed? I see the sub delete with } elsif ($self->type eq "SFTP") { |
| 11:23 |
csharp_ |
or maybe I'm misunderstanding... |
| 11:24 |
Dyrcona |
FTPS.... Ugh. Someone actually uses that? |
| 11:34 |
csharp_ |
jeez, y'all |
| 11:34 |
csharp_ |
don't you know libraries are still excited about Web 2.0? |
| 11:34 |
eeevil |
"upload your EDI messages to the blockchain and..." |
| 11:35 |
csharp_ |
eeevil++ |
| 11:37 |
csharp_ |
eeevil: with my code in place, tlittle and I were able to push files to a PINES-owned SFTP server - that's all the testing we've done |
| 11:38 |
csharp_ |
tlittle has asked Ingram for a test account to push prod files to but that request appears to have flummoxed them |
| 11:39 |
eeevil |
csharp_++ |
| 11:39 |
eeevil |
tlittle++ |
| 11:44 |
eeevil |
it certainly looks like it will work. though, to retain SSH/SCP support, the DESTROY sub should simply add an sftp->disconnect in addition to the ssh2->disconnect. other than that, maybe the need to implement delete_sftp, I don't see any obvious problems |
| 13:15 |
jeffdavis |
More specifically, our test environment remained somewhat slow after applying the fix, but I believe the remaining slowness was for other reasons. We decided not to enable DYM so we effectively stopped testing the fix at a certain point; it's possible that it introduces other issues, but no point in delaying the fix over such hypotheticals. |
| 13:16 |
jeffdavis |
"other reasons" = slower hardware + that unrelated bug that required disabling a PG "optimization" |
| 13:41 |
Dyrcona |
jeffdavis: I have not experienced the issue that "requires" disabling jit. |
| 13:42 |
Dyrcona |
I'm using Pg 15 for quite a bit of testing. Of course, the VPN to where that server is just went down, so..... |
| 13:42 |
jeffdavis |
required it on our test server, that is - we haven't seen it in production |
| 13:43 |
Dyrcona |
I was in the middle of installing updates.... I'll have to check when I get access again. I might have disabled JIT after you reported the issue, but I also wanted to test your queries with JIT enabled. |
| 13:44 |
pinesol |
News from commits: LP#2038472: stamp DB update <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=10527ec78952a27d447f675a93d13e2846fa7ae6> |
| 13:44 |
pinesol |
News from commits: LP#2038472: Revive DYM optimizations <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=7f72e22bc23ae887fefd98074a7415e852fcb4c0> |
| 13:44 |
Dyrcona |
I knew that I should have just started my test program in a tmux session and installed updates after. |
| 13:45 |
Dyrcona |
The test was not related to JIT, but to checking in and deleting copies from a spreadsheet. |
| 13:51 |
Dyrcona |
VPN is definitely down. Wonder if the site also lost Internet? |
| 13:53 |
Dyrcona |
I suppose I could test the changes to command line options on a local vm. |
| 14:11 |
|
jihpringle joined #evergreen |
| 14:12 |
Dyrcona |
Well, that looks like it will work. Guess I can test it on the training server. |
| 14:16 |
csharp_ |
@decide open-ils.serial or open-ils.cereal |
