| 09:18 |
|
stephengwills joined #evergreen |
| 09:18 |
Dyrcona |
miker: Since it would take a day pretty much to restore and "re-upgrade" the database, I'll stick with what I've got checked out. I'll see about pulling the top commits from your other branch. |
| 09:57 |
Dyrcona |
miker: Everything is failing with the changes to metabib.reingest_metabib_field_entries. I'm going to back it out. |
| 09:59 |
miker |
awesome. if you have more info than that, that'd be great. I'm not seeing everything fail... |
| 09:59 |
miker |
thanks for testing, regardless |
| 10:02 |
miker |
Dyrcona: that function has changes that depend on the deadlock branch, fwiw |
| 10:03 |
Dyrcona |
Yeah, I have those. I did the DYM deadlock upgrade, too. |
| 10:03 |
Dyrcona |
miker: Here's a PostgreSQL log entry, https://pastebin.com/SsECj4QB |
| 10:13 |
Dyrcona |
I stopped the coordinator, replaced the function, and it seems to be working again. |
| 11:15 |
|
mantis1 joined #evergreen |
| 11:27 |
Dyrcona |
miker: By "replaced the function," I mean that I went back to the version from the base schema. |
| 11:33 |
miker |
ah, ok. well, I confess that the error message in the log doesn't make much sense to me, it's complaining about a different table... but I'll see if I can sus out what's up there |
| 11:34 |
Dyrcona |
I'll try the new implementation again tomorrow or next week. I'm also trying to test a load of records that say they're MARC8, but I have my suspicions. |
| 11:35 |
Dyrcona |
I have some smaller batches that I'll use with the new implementation. |
| 11:36 |
Dyrcona |
Yeah, I wasn't really sure about the error message, either. I've got a couple of thousand more if you want to extract another. |
| 11:36 |
Dyrcona |
Something like 2,500 failed by the time that I noticed. |
| 11:40 |
Dyrcona |
Let me make sure it does the new thing for the password. |
| 11:41 |
Dyrcona |
It does! How about that! |
| 11:41 |
* Dyrcona |
cranks up the Iron Maiden... |
| 11:46 |
miker |
Dyrcona: so, I found the issue. the problem is in the details of PG's fkey checks. the cause is updating the id (which the named table points to as "entry"), even with the original value. we can replace sort_value, since it's the same and (basically) a key as well with the same effect and not bonk into that issue. I'm testing that change now (no explosions after 5min+), but it comes down to this if you want to use "\ef metabib. |
| 11:46 |
miker |
reingest_metabib_field_entries" to adjust the new version in situ: https://pastebin.com/PKDrhfSX |
| 11:46 |
|
jihpringle joined #evergreen |
| 11:48 |
Dyrcona |
miker: Cool, I'll give that a shot after I play with my new SIP accounts. |
| 11:48 |
miker |
+1 |
| 12:15 |
Dyrcona |
I suppose that I could just replace the function while it's running and see what happens. |
| 12:39 |
Dyrcona |
miker++ I swapped ou the function definition and it's still working. |
| 12:39 |
miker |
huzzah! |
| 12:49 |
Dyrcona |
My SIP test is not going so well. I can't tell if I'm failing to log in or if my test script is just blowing up. I'm getting a socket error. |
| 13:04 |
Dyrcona |
hmm. I get no response from server when I try to login with a newly created account, but pre-existing ones work. I even tried running actor.change_password() with the password that I'm using. |
| 13:09 |
Dyrcona |
There's a bug, I think. I was trying to use the location to add a workstation for the new users. When I removed the location, it worked. |
| 13:09 |
|
mrtnnbr joined #evergreen |
| 14:12 |
|
sleary joined #evergreen |
| 14:13 |
Dyrcona |
The other 3 are also deadlocks. |
| 15:29 |
Dyrcona |
So, I am now getting sharelock violations. That's it. I'll have to reload everything next week and start over with a clean upgrade to master, etc., to make sure I have everything, but I am pretty sure that everything is up to date. |
| 15:37 |
jeffdavis |
Do we have a way to flag bugs that need discussion rather than testing for bug squashing week? There's a fix for bug 1863387 that I'd like to commit as-is, but it would be good to know if end users think it needs more work. |
| 15:37 |
pinesol |
Launchpad bug 1863387 in Evergreen "Carousels: shelving location selector should limit initial set of choices" [Medium,Confirmed] https://launchpad.net/bugs/1863387 |
| 15:37 |
Dyrcona |
jeffdavis: needsdiscussion tag. |
| 15:40 |
jeffdavis |
oh, are needsdiscussion bugs already included in bug squashing? that would be great! |
| 15:49 |
sleary |
I forgot about that tag |
| 15:50 |
Dyrcona |
On the plus side, the ingest coordinator has stayed up and running. |
| 15:51 |
|
jvwoolf left #evergreen |
| 16:16 |
mmorgan |
jeffdavis: I am pretty sure the main focus of bug squashing week is bugs with pullrequests, terranm does a masterful job of organizing them on test servers with signoffs as a goal. |
| 16:17 |
mmorgan |
But I would think BSW is a great opportunity to look at needsdiscussion bugs, too. |
| 16:50 |
|
stephengwills left #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 18:25 |
|
sandbergja joined #evergreen |
| 18:57 |
pinesol |
News from commits: LP1952931 release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b33f1170050401a0c6066452a09d391fd97a7cd2> |
| 18:57 |
pinesol |
News from commits: LP1952931 stamp upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=25f23ca394d5759f685f6b54933e9d0db18423cd> |
| 18:57 |
pinesol |
News from commits: LP1952931 Support ACQ Advanced Shipment Notices (DESADV -- Dispatch Advice Messages) <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=eae6c7e0eacc9ebf4bfd2014d9c6485a61de8a0c> |
| 19:28 |
gmcharlt |
testing, then pusing fix to 1344 |
| 19:38 |
|
sandbergja joined #evergreen |
| 19:38 |
sandbergja |
gmcharlt++ |
| 19:57 |
pinesol |
News from commits: LP#1724032: add release note entry <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2cad20e67af7d630b18834313960e00414dd758e> |
| 20:28 |
pinesol |
News from commits: LP1904036 Mark Damaged always handles checkin <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=55941c65290a23c682746c230b96fff12d38efc4> |
| 20:28 |
pinesol |
News from commits: LP1904036 Checkin grid routeTo visible by default <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=5bc6f2816ba2124198c9763f0d17c9aac88b05c4> |
| 20:44 |
* gmcharlt |
claims 1347 |
| 20:57 |
pinesol |
News from commits: LP#1934162: stamp DB update <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=00d6528742c31a7b04aa876e6e4a471fec8c6bfc> |
| 20:57 |
pinesol |
News from commits: LP#1934162: add release note <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=1ea534594a176b72b404f12f8071faf870e96c8f> |
| 20:57 |
pinesol |
News from commits: LP1934162: (follow-up) sync whitespace <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=5ec73fa03414a59bd8516e571da6070b45e3b3ce> |
| 20:57 |
pinesol |
News from commits: LP1934162: add pgtap test, refreshing upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=a51d2366a735903adf04cfe7a32af1565313b334> |
| 20:57 |
pinesol |
News from commits: LP#1934162: delete user messages and curbside notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=d24c4dbe1e9b3b4dc924647c4c29082242b37622> |
| 21:07 |
* gmcharlt |
claims 1348 |
| 21:16 |
* gmcharlt |
claims 1349 |
| 21:27 |
pinesol |
News from commits: LP#1982031: add release note <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=244f0c732b9358e8c272364047e03f1b92406d06> |
| 00:21 |
pinesol |
News from commits: LP1411819 stamp upgrade script and add release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8da533ecb4126fdaa6cd6386a4468fe11550e4da> |
| 00:21 |
pinesol |
News from commits: LP1411819 follow-up: add a pgtap test <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fd0a11c18fbac315b81d04da359ba062d002d916> |
| 00:21 |
pinesol |
News from commits: LP#1411819: org setting to override PATRON_EXCEEDS_FINES penalty on renewals <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=98ce2c013c295509d530df40bed947279dc3b9f5> |
| 00:51 |
pinesol |
News from commits: LP1953692: release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=18c15f0957fdea5d1213ed137d80f879b9aa7ade> |
| 00:51 |
pinesol |
News from commits: LP1953692 follow-up: missing character <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=6b9a7d9bdf64144b8138025713575d9f79c61650> |
| 00:51 |
pinesol |
News from commits: LP1953692 Angular Catalog Record Summary links should open in new tab <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=781f399afa75a6f9fae4ef164c797f1231821f22> |
| 02:18 |
|
tsadok joined #evergreen |
| 07:42 |
|
collum joined #evergreen |
| 08:07 |
|
BDorsey joined #evergreen |
| 09:28 |
|
Dyrcona joined #evergreen |
| 09:45 |
|
dguarrac joined #evergreen |
| 09:46 |
|
jvwoolf joined #evergreen |
| 09:57 |
mmorgan |
Asked this in the hackaway, but I'll try here, too. |
| 09:57 |
mmorgan |
Trying to build a test vm using ansible and I'm getting this: "Open-ILS/src/extras/Makefile.install:156: recipe for target 'ubuntu-bionic-developer' failed" |
| 09:57 |
mmorgan |
What am I missing? |
| 10:00 |
|
sleary joined #evergreen |
| 10:03 |
Dyrcona |
miker: Getting different behavior with ingest_ctl today after the patch from yesterday. I'm loading the same records that I used last week after a database reload. Updating 378 records worked fine. Inserting 314 has produced 7 errors and after that, it seems to have really slowed down. |
| 10:05 |
Dyrcona |
And, of course, after I mention it here, it picks back up again. |
| 10:14 |
Dyrcona |
I have all of the patches from DYM and queued ingest. |
| 10:17 |
Dyrcona |
The rest are all pretty much the same. |
| 10:24 |
Dyrcona |
I processed 1 by hand and it worked. I update fail_time to null and the rest of them worked in parallel. |
| 10:28 |
JBoyer |
mmorgan, regardless of the specific error you'll want to update your testing VM to a later version of Ubuntu; building Evergreen on Bionic from a fresh git checkout is likely to start failing within days. |
| 10:28 |
JBoyer |
see lp 1990969 |
| 10:28 |
pinesol |
Launchpad bug 1990969 in Evergreen "Discontinue Support for Ubuntu 18.04 "Bionic Beaver"" [Wishlist,Confirmed] https://launchpad.net/bugs/1990969 |
| 10:29 |
JBoyer |
OR, if you're running a later version of Ubuntu on your VM it's entirely possible that some package name has changed since bionic and that's what's failing. |
| 11:59 |
Dyrcona |
miker: I noticed two entries for the same author name back to back, so there's some evidence of that. |
| 12:02 |
mmorgan |
Bmagic: Right. Will look at that when I find some time. |
| 12:14 |
|
Dyrcona joined #evergreen |
| 12:23 |
miker |
Dyrcona: https://pastebin.com/csTYASPu is what I'm proposing. commit coming in a moment |
| 12:45 |
miker |
Dyrcona: 2 new commits on the QI branch now, though just the first is strictly required for the browse ingest conflict. the second is about a long-standing oversight that removes too much data in a "just update this one field" reingest request |
| 12:47 |
miker |
(IOW, you may want to pick and test just the first new commit, but I think the second is needed generally) |
| 12:49 |
|
collum joined #evergreen |
| 12:55 |
|
kworstell-isl joined #evergreen |
| 12:59 |
Dyrcona |
miker: I'll try them both in a bit. |
| 10:02 |
miker |
Dyrcona: AFAICT, the QI coordinator is always dying when trying to gather orphaned entries. is that right? |
| 10:02 |
miker |
that's based on the log snippets |
| 10:02 |
Dyrcona |
Yes. |
| 10:03 |
Dyrcona |
BTW, I've dropped that database and I'm testing something else at the moment. I could reload it. |
| 10:16 |
|
sleary joined #evergreen |
| 11:15 |
|
jihpringle joined #evergreen |
| 11:31 |
|
Christineb joined #evergreen |
| 11:31 |
miker |
Dyrcona: if/when you get back to QI, there's a small change on the current branch that should at least let us get past the "can't use undef as ARRAY ref" death. |
| 11:41 |
|
sleary joined #evergreen |
| 11:44 |
miker |
grabbing upgrade stamps 1340 and 1341 |
| 11:45 |
Dyrcona |
All right. I'll stop what I'm doing and reload the database that I was using to test queued ingest. I can rerun my tests on a different database. |
| 11:49 |
Dyrcona |
Well, crap. I can't reload it from the dump. Pg version mismatches, etc. |
| 11:49 |
Dyrcona |
I'll have to do it differently and rerun the db upgrade scripts. |
| 11:56 |
Dyrcona |
I probably won't be able to do anything with it until tomorrow. I'd really like for someone else to look at queued ingest. |
| 08:53 |
|
Dyrcona joined #evergreen |
| 08:57 |
|
stephengwills joined #evergreen |
| 09:23 |
|
dguarrac joined #evergreen |
| 10:22 |
csharp_ |
Dyrcona: are you targeting PG 14 in your testing? looking at moving past PG 11 since we're back in the same boat soon |
| 10:22 |
csharp_ |
(on PG 10 now, just looking at an upgrade target) |
| 10:23 |
Dyrcona |
If you're referring to queued ingest, I've only been testing it on Pg 10. |
| 10:23 |
csharp_ |
upgrading my staging server and thinking about what version to move towards |
| 10:23 |
csharp_ |
no, just generally |
| 10:23 |
Dyrcona |
Pg 14 should work. |
| 10:24 |
csharp_ |
ok - I'll give it a go |
| 10:24 |
Dyrcona |
I've done light testing on Pg 11 - 13. I use Pg 14 on all of my local VMs where I run concerto. (By local I mean on my laptop.) |
| 10:24 |
Dyrcona |
I might have 1 or 2 older ones (bionic, maybe?) on Pg 10. |
| 10:25 |
Dyrcona |
Does anyone know how to get of screen prompting for a password? I tried closing a window using Ctrl-a x because Ctrl-b x closes a window in tmux. Didn't remember is was the lock command and screen just keeps asking for a password. |
| 10:26 |
Dyrcona |
None of the Ctrl-a commands work with the password prompt. |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:58 |
|
Dyrcona joined #evergreen |
| 09:05 |
|
dguarrac joined #evergreen |
| 09:15 |
Dyrcona |
miker: Well, ingest_ctl survived the other 157, 000 records yesterday with nothing much going on. I'm deleting a few more URIs and then going to load some as another test. |
| 09:16 |
* mmorgan |
added an additional commit to abneiman, jweston and jihpringle's release notes: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mmorgan/docs-releasenotes-2022-10-18 |
| 09:19 |
Dyrcona |
mmorgan++ |
| 09:20 |
miker |
Dyrcona: that's good news |
| 10:05 |
Dyrcona |
Checking the database real quick looks like it actually worked for at least one of the failed records when I processed it manually. |
| 10:06 |
* Dyrcona |
keeps looking. |
| 10:12 |
Dyrcona |
My 502 is probably because I'm running an out of date Apache configuration. |
| 10:50 |
Dyrcona |
OK. Another batch of about 28,000 records to use for a stress test. |
| 10:55 |
|
stephengwills joined #evergreen |
| 10:55 |
Dyrcona |
Ugh. Forced to use screen because tmux is not installed.... |
| 10:56 |
stephengwills |
morning. if I RAISE some text in a postgresql function should I see that message in postgresql-10-main.log? or does it channel it somehwere else? |
| 14:04 |
Dyrcona |
I'm going to work on Pg 15 during the hack-a-way if it happens. |
| 14:17 |
berick |
pg10 here |
| 15:15 |
|
jihpringle joined #evergreen |
| 15:45 |
csharp_ |
trying to test bug 1898775 - how do I enable the traditional catalog? I've set the Library Setting GUI: Enable Traditional Staff Catalog to True for CONS but not seeing a difference |
| 15:45 |
pinesol |
Launchpad bug 1898775 in Evergreen "Bootstrap OPAC: Add to bucket broken" [Medium,Confirmed] https://launchpad.net/bugs/1898775 |
| 15:48 |
mmorgan |
csharp_: You need to change /etc/apache2/eg_vhost.conf Look for this line: |
| 15:48 |
mmorgan |
PerlAddVar OILSWebTemplatePath "@localstatedir@/templates-bootstrap" # Comment this line out to use the legacy TPAC |
| 16:10 |
csharp_ |
jeez, we're supporting too many things, huh? |
| 16:11 |
csharp_ |
mmorgan++ # was able to trigger the bug |
| 16:11 |
mmorgan |
csharp_++ |
| 16:11 |
jihpringle |
csharp_ I see it in the menu on our test server when I set the setting to True - but I have to log out and back if before it appears |
| 16:11 |
csharp_ |
jihpringle: ah |
| 16:14 |
csharp_ |
fix works! |
| 16:14 |
Dyrcona |
#worksforme |
| 16:38 |
Dyrcona |
Right... Processes that change their name after they start.... |
| 16:41 |
Dyrcona |
Wow! |
| 16:42 |
Dyrcona |
The updates immediately started going "faster." |
| 16:44 |
Dyrcona |
Testing two things at the same time. :) |
| 16:46 |
mmorgan |
Dyrcona: What else are you testing? |
| 16:46 |
Dyrcona |
Seems to be working. Some of the records have been ingested. Others haven't been ingested, yet. |
| 16:47 |
Dyrcona |
I was just making sure that a script to remove URIs for a vendor by library is still working. |
| 16:47 |
Dyrcona |
No failures, either. |
| 16:48 |
mmorgan |
Sounds promising! |
| 16:48 |
Dyrcona |
One of our members wants to refresh their Ebrary records. |
| 16:48 |
Dyrcona |
Yeahp. |
| 16:48 |
Dyrcona |
I was sitting here with that process going and thinking how can I test queued ingest, and well, it worked out perferctly. |
| 16:49 |
Dyrcona |
Well, better than my spelling anyway. :) |
| 16:50 |
mmorgan |
Dyrcona++ |
| 16:51 |
Dyrcona |
miker++ |
| 15:20 |
gmcharlt |
for obvious reasons, I'm kinda hoping that it does turn into "let's try Angular 14 for the back branches" |
| 15:20 |
gmcharlt |
er, does *not* |
| 15:20 |
|
lew54 joined #evergreen |
| 15:21 |
sandbergja |
I could throw together a branch with npm audit --fix, but it would be nice to have some help testing the results |
| 15:22 |
gmcharlt |
happy to help (and I am actually pretty concerned about the potential for breakage) |
| 15:22 |
berick |
sandbergja: is your focus at the moment just on angjs? |
| 15:23 |
gmcharlt |
but I may be unduly distrustful of the state of backwards compatibiliy in the NPM ecosystem |
| 15:24 |
sandbergja |
I definitely share the concerns about regressions... |
| 15:24 |
Dyrcona |
I've run npm update in the past without ill effects, but not sure if that does what's needed. I've also not done it in a while. |
| 15:24 |
gmcharlt |
sandbergja: certain a gold star to any of use who figures out that we can _remove_ dependencies during the process :) |
| 15:24 |
sandbergja |
If you'll allow me a soapbox for a minute, it sure would be nice if we had more test coverage, so we could just run any automated dependabot PRs against the test suite and get a quick yes/no |
| 15:25 |
sandbergja |
about whether it introduces regressions |
| 15:26 |
|
tlittle joined #evergreen |
| 15:27 |
JBoyer |
sandbergja++ gmcharlt++ |
| 15:27 |
|
terranm joined #evergreen |
| 15:28 |
JBoyer |
csharp_++ |
| 15:28 |
gmcharlt |
just wanted to mention something that had come up in a meeting with a few of you recently - if we step back a bit... we've done a LOT towards migrating to Angular |
| 15:28 |
gmcharlt |
so I do think that warrants an IRC collective back-patting |
| 15:28 |
csharp_ |
sandbergja: I'll do some experimentation and will test your branch if you push one |
| 15:29 |
shulabear |
sandbergja++ |
| 15:29 |
sandbergja |
angular++ |
| 15:29 |
terranm |
backpatting++ |
| 16:13 |
* Dyrcona |
is considering taking over SpamAssassing on FreeBSD. It's currently looking for a maintainer. |
| 16:13 |
Dyrcona |
It's late in the day, and my typing skills are on the fritz.... |
| 16:15 |
Dyrcona |
Autotools doesn't really cover installing HTML files for a website, beyond maybe using localstatedir. I s'pose inventing a new option is not out of the question, but.... |
| 16:15 |
mrtnnbr |
anyway, it looks like there's some interest/curiosity here, so how about I finish configuring my test system and put it online for review. I'll send a a link to -dev |
| 16:17 |
Dyrcona |
OK. I'd like git branches, too. :) |
| 16:28 |
mrtnnbr |
Dyrcona: A quick survey of existing ports shows somewhat even usage of --htmldir, --datadir, and --datarootdir. one of the latter two might be reasonable. |
| 16:30 |
Dyrcona |
Yeah. We have an option to not install the web files, but not one for where. |
| 11:31 |
|
sleary joined #evergreen |
| 12:12 |
|
jihpringle joined #evergreen |
| 12:26 |
|
Christineb joined #evergreen |
| 13:45 |
mantis1 |
Doing some 3.9 testing. Can anyone explain the Org selector now supports entry styling a bit further than what's in the release notes? |
| 13:45 |
mantis1 |
"The Org Selector now supports the ability to pass in an object composed of an array of Org Unit IDs and a function returning a CSS key value pair." |
| 13:49 |
jeff |
more information may be in bug 1739277 |
| 13:49 |
pinesol |
Launchpad bug 1739277 in Evergreen 3.8 "web client: holdings view owning libraries not marked in drop down menu" [Medium,Fix released] https://launchpad.net/bugs/1739277 |
| 13:50 |
jeff |
commit d51454b and commit 625c862 have an example and the first (only?) implementation |
| 13:55 |
jeff |
and i guess in actuality, the function just returns a string that's interpreted as a css class name. |
| 13:56 |
jeff |
so, the "CSS key value pair" in the release notes seems off, or I'm looking at the wrong feature/code. :-) |
| 14:05 |
|
tlittle joined #evergreen |
| 14:11 |
tlittle |
I updated my test server now that the Acq purchase order work is in master, and when opening PO's I get this console error: "open-ils.acq.lineitem.retrieve.batch failed! stat=404 msg=Method [open-ils.acq.lineitem.retrieve.batch] not found for OpenILS::Application::Acq". I can see that API/method is in Lineitem.pm, so why would it be telling me it |
| 14:11 |
tlittle |
can't see it? I don't know if this is just something I've done incorrectly or if there's something actually missing. I never saw this message on the EOLI test server, so idk what's up |
| 14:14 |
Dyrcona |
tlittle: You did a "make install"? |
| 14:17 |
tlittle |
Yes, I think so. I have a script that csharp_made for Terran and I so that probably obfuscates troubleshooting a bit, but it looks like that's what it did |
| 14:18 |
Dyrcona |
Did the script or you stop and restart services? |
| 14:47 |
Dyrcona |
I don't recall what my first album on CD was, but I definitely got Dark Side of the Moon before The Wall. |
| 14:49 |
csharp_ |
Dark Side of the Moon followed quickly |
| 14:54 |
Dyrcona |
Matter of fact, it's all dark.... |
| 14:55 |
Dyrcona |
I should probably have edited a commit message, too. I could have fixed a typo and/or removed the paragraph about tests failing... I should maybe look at that qatester bug that I removed myself from, but I though JBoyer was going to have a look. |
| 14:56 |
* Dyrcona |
has some things on Lp that he should get in digital format. |
| 14:56 |
Dyrcona |
Hah... Lp Lauchpad. LP long playing disc. :) |
| 14:56 |
JBoyer |
Well, that bug depends on the state of the "remove Stretch" bug; 2/3 of the changes are Stretch-only |
| 15:34 |
Dyrcona |
I think they finally found Part I. |
| 15:34 |
|
Stompro joined #evergreen |
| 15:53 |
Stompro |
Ah Shoot, missed feedback fest... I need to put them on my calendar. |
| 15:53 |
terranm |
There are still plenty of things loaded that can be tested :D |
| 15:55 |
Stompro |
terranm, I'm checking out the list now. |
| 16:36 |
|
jvwoolf left #evergreen |
| 16:41 |
JBoyer |
I spoke too soon about figuring out that SSO BPAC integration. My initial plan was a bust, but I |
| 11:22 |
* csharp_ |
weeps a single tear thinking about placing third in the fourth grade spelling bee |
| 11:23 |
Dyrcona |
Well, that's interesting: -bash vi: command not found # Tramp mode to the rescue! |
| 11:24 |
Dyrcona |
csharp_++ |
| 11:32 |
jeff |
csharp_: oh, I didn't actually notice your typo... but now that you pointed it out, that's probably why my brain went where it did. |
| 11:54 |
|
collum joined #evergreen |
| 11:56 |
jeff |
Drat. It was not the template. |
| 11:57 |
jeff |
test prints with this printer print okay. multiple templates have "extra space" at the bottom. |
| 12:24 |
|
mmorgan joined #evergreen |
| 13:06 |
|
collum joined #evergreen |
| 13:45 |
jeff |
Ah. It was both! |
| 17:08 |
|
mmorgan left #evergreen |
| 19:37 |
jeffdavis |
the unapi.bre db function has suddenly become very slow, but only for one specific bib record (AFAIK) - it takes ~30s for the bad record, but <1s for others that I've tried |
| 19:38 |
jeffdavis |
can't find anything weird about the bad record, and the sudden slowness wasn't triggered by edits to it or holdings changes or anything AFAICT |
| 21:03 |
jeff |
do you have data that suggests that this particular record was taking less time before now? |
| 21:09 |
jeff |
and it sounds like you've narrowed it down to the db function call itself? are you calling it directly from psql as a test? |
| 15:03 |
JBoyer |
#topic Action Items from Last Meeting |
| 15:03 |
JBoyer |
#info Dyrcona will take a look at LP 1979357 |
| 15:03 |
pinesol |
Launchpad bug 1979357 in Evergreen "fixes for qatester failures" [Undecided,New] https://launchpad.net/bugs/1979357 - Assigned to Jason Stephenson (jstephenson) |
| 15:03 |
JBoyer |
I should probably have signed off on that already, I've already tested and verified most of it anyway. |
| 15:04 |
jeffdavis |
just as long as some Jason looks at it |
| 15:04 |
Dyrcona |
I have not had time to really look at it, so maybe I should remove myself from the bug? |
| 15:04 |
JBoyer |
Dyrcona, do you have time to investigate or should I grab that one |
| 15:22 |
gmcharlt |
the two biggest pieces I'm aware that are pending are the Angular patron/circ app and the Angular acquisitions blob |
| 15:22 |
gmcharlt |
(yes, that's right, Acquisitions Blob is the new official title) |
| 15:22 |
mmorgan |
:) |
| 15:23 |
gmcharlt |
I'm curious (terranm? berick?) how testing of the patron/circ app is going |
| 15:23 |
terranm |
There were a lot of small issues found during BSW that were tracked on a big ole spreadsheet. I'm not sure if any of those have been addressed yet. |
| 15:23 |
gmcharlt |
(and where I'm leading up to is the question about whether Angular patron/circ is a 3.10 thing, 3.10 "experimental" thing, or a 3.11 thing) |
| 15:24 |
gmcharlt |
(I'm partial, but I'm feeling generally pretty comfortable about Angular Acq Blob being suitable for 3.10) |
| 15:26 |
gmcharlt |
sandbergja: yeah, I recall there was a discussion a few meetings back |
| 15:27 |
|
mdriscoll joined #evergreen |
| 15:27 |
gmcharlt |
FWIW, I'm in the camp that some sort of overlap period is going to be a necessary evil, but I have significant concerns if such a period is allowed to go on too long |
| 15:29 |
mrussell |
I think it would be best if we had an overlap period so that people can test functionality/ workflow and give feedback on what features work best |
| 15:29 |
JBoyer |
I wonder how many of us are reading the last meeting's notes... :D |
| 15:30 |
gmcharlt |
so to spin a tale: maor testing in 3.10, possibly a non-default alt mode available in 3.10 (although I think I remember from berick that he doesn't think it would be easy to do that/) |
| 15:30 |
|
Guest4 joined #evergreen |
| 15:30 |
gmcharlt |
3.11 - fully relased; new interface is default but can switch back as needed |
| 15:30 |
gmcharlt |
3.12 - new interface only, the old one is actively removed |
| 15:31 |
gmcharlt |
(and I acknowledge that that is probably an aggressive timeline) |
| 15:31 |
terranm |
I seem to recall him saying that the code could be in there so that certain new elements could be available to other interfaces without the new patron interfaces being visible |
| 15:31 |
Bmagic |
That sounds pretty good to me |
| 15:31 |
JBoyer |
The first step proposed last time was non-ui stuff first since so many components have been updated, that could be 3.10 even if the alt-mode isn't available yet |
| 13:23 |
kmlussier |
I need to head out, but thanks everyone for listening to me vent. If I have time this weekend, maybe I'll do the legwork of going through the Wayback machine in the hopes that somebody with power can address this. |
| 13:23 |
kmlussier |
Have a good weekend! |
| 13:24 |
Bmagic |
you too! |
| 14:12 |
JBoyer |
Dyrcona, an FYI for you since I know we're both interested, I was testing NCIPServer on Buster and Bullseye and things seem fine without the patch from lp 1732485 . Have you tested things on Ubuntu 20.04+ |
| 14:12 |
JBoyer |
? |
| 14:12 |
pinesol |
Launchpad bug 1732485 in NCIPServer "Crash with mime type application/xml on recent distros" [High,Confirmed] https://launchpad.net/bugs/1732485 |
| 14:14 |
JBoyer |
(granted, I'm mostly throwing LookupUser requests at it with curl, but things work with and without the Content-Type: application/xml header. |
| 14:15 |
Dyrcona |
JBoyer: I don't think I have tested NCIP on Ubuntu 20.04+. I know that I have not tested it on Ubuntu 22.04. |
| 14:16 |
JBoyer |
Possibly good news then, though i guess if you're not going to be managing the hosting it's not such a big deal locally. :) |
| 14:19 |
Dyrcona |
Well, I should try it anyway. |
| 14:21 |
Dyrcona |
Not today, though... |
| 14:21 |
JBoyer |
Dyrcona++ |
| 14:22 |
JBoyer |
And yeah, just wanted to make sure you knew it was worth checking out whenever there's free time. |
| 14:24 |
Dyrcona |
JBoyer++ |
| 14:24 |
Dyrcona |
I may have tested it on 20.04 and don't remember doing it. |
| 14:51 |
Dyrcona |
hmmm... Looks like we can lose a modification to the IDL. Either it was fixed or our change was unnecessary to begin with. I should try to figure out if we're using the field we added in any reports. |
| 14:59 |
Dyrcona |
Wudnchanoit.... 3 templates use our "junk" field. |
| 15:25 |
|
jihpringle joined #evergreen |
| 10:21 |
csharp_ |
holy crazznap: Execution time: 127095178.213 ms |
| 10:22 |
csharp_ |
35.3041666667 hours (thanks to DuckDuckGo) |
| 10:25 |
Dyrcona |
That's what happens when you do a Cartesian product of two very large tables, provided you don't run out of memory first. |
| 10:26 |
Dyrcona |
Which reminds me...I've got something running on a test vm that I should check. It's probably finished by now. |
| 10:27 |
Dyrcona |
I used time on it: 2719m34.212s |
| 10:33 |
Dyrcona |
45 hours 19 minutes. |
| 10:37 |
Dyrcona |
PostgreSQL and kernel updates..... |
| 10:42 |
Dyrcona |
Pg 15 release planned "in the third quarter of 2022." I can't find anything more specific than that, though Beta 3 was just released. |
| 11:39 |
|
BDorsey joined #evergreen |
| 11:51 |
|
jihpringle joined #evergreen |
| 11:54 |
Dyrcona |
Well, no errors in the test record load since I fixed the encoding in the Perl code. |
| 13:21 |
|
stephengwills left #evergreen |
| 14:15 |
|
BDorsey joined #evergreen |
| 22:33 |
|
bshum joined #evergreen |
| 10:14 |
berick |
miker: k, yeah, i figure there's some indexes, etc. we could add. as a data point, my last attempt timed out out after 6 hours. |
| 10:14 |
berick |
it was barebones |
| 10:20 |
|
rjackson_isl_hom joined #evergreen |
| 10:21 |
csharp_ |
I'm backporting it here to my 3.8 test server just to play around |
| 10:25 |
miker |
berick: well, barebones is ... relative, if you look at the source query. "less filters" doesn't necessarily mean "less work for PG" |
| 10:26 |
berick |
this one was count of circs per month in 2018 |
| 10:38 |
miker |
I'd suggest SR might be the wrong tool for that particular report ;) ... and that's only about 1/4 snarky -- the example a trivial template to create and share in the normal reporter, and SR is meant to make Hard(tm) things (arguably some impossible things, for normal folks in the normal reporter) simple(r), not all things one-click easy AND fast. It trades internal complexity for external simplicity. |
| 14:20 |
|
jvwoolf left #evergreen |
| 14:27 |
|
rjackson_isl_hom joined #evergreen |
| 15:27 |
|
rjackson_isl_hom joined #evergreen |
| 15:31 |
mmorgan |
FIFO question. If a library has FIFO set as best-hold selection sort order, shouldn't the item be captured for the hold with the highest priority, no matter the pickup location? |
| 15:32 |
mmorgan |
I'm finding that a local hold is captured when there are higher priority holds for pickup elsewhere. |
| 15:33 |
mmorgan |
We don't use FIFO, just testing for a particular situation. |
| 17:04 |
|
mmorgan left #evergreen |
| 10:16 |
Dyrcona |
I'm going to try and solve my record issue by rewriting the prep script in Python using PyMarc and chardet to autodetect the character set of each record. I wonder what chardet will say about MARC-8 records? Maybe, it will call them ISO 2022? |
| 10:23 |
Dyrcona |
Maybe I can keep most of the Perl code and just throw the XML at a character set detection program? |
| 10:30 |
Dyrcona |
Running chardet on the input files says, "utf-8 with confidence 0.99." |
| 10:30 |
* Dyrcona |
sighs. Guess I'll just jam the bad records in, like my current test is doing. |
| 10:49 |
|
jvwoolf joined #evergreen |
| 11:08 |
|
jihpringle joined #evergreen |
| 11:29 |
Dyrcona |
I wonder if $raw =~ s/\xC2/.../g; works on UTF-8 files that might have \xC2A9 and other multibyte sequences.... |
| 11:32 |
Dyrcona |
I suppose that I could test it. |
| 11:53 |
Dyrcona |
Weird, 0xC2A doesn't give me they copyright symbol. Let me try it reversed for little endian. |
| 11:54 |
Dyrcona |
Funny, too, how 0xC2 only prints "correctly" when other unicode sequences are in the string. Otherwise it prints as an unknown character glyph. |
| 12:26 |
Dyrcona |
Unicode in Perl is a pain. |
| 11:21 |
Dyrcona |
berick foun the missing step... :) |
| 11:21 |
Dyrcona |
found, even.. |
| 11:26 |
|
jihpringle joined #evergreen |
| 11:38 |
mmorgan |
berick++ |
| 11:38 |
mmorgan |
Thanks! |
| 11:38 |
* mmorgan |
now moves on to 4. profit and 5. invest wisely :) |
| 11:45 |
* mmorgan |
has been trying all morning to test a checkin of an item in a certain shelving location with a particular variety of item alerts. |
| 11:46 |
mmorgan |
It has been an adventure just setting up the scenario :-/ |
| 11:55 |
csharp_ |
has anyone developed/found any tools that would be useful in de-duping authority records? |
| 11:56 |
csharp_ |
mmorgan: don't you wish some of the end users who are always mad that something "isn't fixed" could watch what we do sometimes? :-) |
| 12:01 |
mmorgan |
csharp_: Actually, I feel for them! This library is trying to use the shelving location attribute Hold capture delay and it's not working with item alerts. Evergreen just seems to "forget" that it's in the middle of a checkin. |
| 12:03 |
mmorgan |
Our test system is on 3.8.1 and I ran across a couple of item alert bugs that are fixed - in 3.8.2 |
| 12:04 |
mmorgan |
rabbit-holes-- |
| 12:07 |
jihpringle |
mmorgan: that sounds very similar to https://bugs.launchpad.net/evergreen/+bug/1735221 |
| 12:07 |
pinesol |
Launchpad bug 1735221 in Evergreen "webclient: items with copy alert and hold verify fail to capture for hold" [Low,Confirmed] |
| 12:08 |
mmorgan |
jihpringle++ |
| 12:08 |
mmorgan |
Aha! Didn't find that and it's exactly the issue! |
| 12:10 |
mmorgan |
And it's not a new issue either. |
| 12:11 |
jihpringle |
ya, we've been running into that one since we switched to the web client |
| 12:12 |
jihpringle |
it's on my list to test in 3.9 and possibly in the angualr circ (if that server is still up this week) |
| 12:14 |
mmorgan |
Definitely still an issue in 3.8! |
| 12:18 |
mmorgan |
Our library is trying to use hold capture delay for hotspots, I think they need to check or reset them before they can go out again. I suggested they use the hold capture delay, not knowing there was a bug :-( |
| 12:21 |
jihpringle |
they could use the Suppress Holds and Transits check in modifier (not as good since staff have to remember to use it) but could work for now |
| 12:25 |
mmorgan |
jihpringle: Thanks, I will suggest that option. Just commented on the bug. |
| 12:27 |
jihpringle |
just tested it in the new angular circ and it's still an issue there |
| 12:27 |
jihpringle |
I'll update the bug and the circ spreadsheet |
| 12:45 |
Dyrcona |
I didn't look very hard, but it appears to me that hold verify is just gonna break checkin no matter what. The location having hold_verify set does a bail on events, and do checkin returns if there is a bail on events right after that check is made. However, I didn't look much farther than that and circulation code is tricky. |
| 13:01 |
|
mmorgan left #evergreen |
| 13:11 |
* Dyrcona |
wonders if it is time to have the community git discussion again. We're looking at possibly making some changes here because of things going on, and it would be useful if we could link what we're doing with the community. |
| 08:58 |
|
smorrison joined #evergreen |
| 09:03 |
|
terranm joined #evergreen |
| 09:28 |
|
terranm joined #evergreen |
| 09:29 |
terranm |
berick: For the Angular circ/patron interface testing, do you want me to copy over all the findings onto the LP ticket, or would it be easier for you to go off of the testing spreadsheet at https://docs.google.com/spreadsheets/d/1PL04fcjom0l2xuum_Do-w04asn-ifAEHwuBY6yWIESQ/edit#gid=0 ? |
| 09:37 |
|
smorrison joined #evergreen |
| 09:40 |
|
jihpringle joined #evergreen |
| 09:50 |
|
smorrison joined #evergreen |
| 09:55 |
csharp_ |
berick: I was testing https://bugs.launchpad.net/opensrf/+bug/1970667 and saw a very long delay when installing ejabberd while running the OpenSRF Makefile.install - this is on a stock 22.04 machine - did you see simlar? |
| 09:55 |
pinesol |
Launchpad bug 1970667 in OpenSRF "Add Installation Support for Ubuntu 22.04 Jammy Jellyfish" [Undecided,New] |
| 09:57 |
csharp_ |
Created symlink /etc/systemd/system/multi-user.target.wants/ejabberd.service → /lib/systemd/system/ejabberd.service. |
| 09:57 |
csharp_ |
... <several minutes delay> ... |
| 12:53 |
csharp_ |
@decide git blame or git blam? |
| 12:53 |
pinesol |
csharp_: go with git blame |
| 15:21 |
|
smorrison joined #evergreen |
| 16:19 |
terranm |
You guys... we're actually running out of pullrequests to test! (Well, ones that end users can test anyway.) |
| 16:25 |
mmorgan |
Wow! That's great! |
| 16:25 |
mmorgan |
terranm++ |
| 16:28 |
JBoyer |
I won't be around tomorrow so pattypan and festivus are pretty much The Way They're Going To Be, but there are some good things to check out on both! Also that Hatch patch; you can test that against any server, not necessarily a testing one! |
| 16:28 |
JBoyer |
and yeah, terranm++ Great work, it's much appreciated. |
| 16:30 |
terranm |
JBoyer++ The multiple server refreshes definitely kept things moving this week! |
| 17:15 |
|
mmorgan left #evergreen |
equinoxOLI.org