| 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 |
| 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: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 |
| 11:25 |
|
terranm joined #evergreen |
| 11:47 |
|
jihpringle joined #evergreen |
| 11:56 |
|
Stompro joined #evergreen |
| 11:59 |
Stompro |
Is anyone already working on testing the stripe messages on terran-master? |
| 12:08 |
terranm |
I don't think so |
| 12:14 |
|
terranm joined #evergreen |
| 12:20 |
|
jihpringle joined #evergreen |
| 12:30 |
Stompro |
terranm, thanks for the instructions, I just emailed Dawn Dale to get a screenshot of the stripe dashboard. |
| 13:12 |
JBoyer |
terranm++ |
| 13:14 |
collum |
Stompro - I was testing while you were writing. I just posted a signed-off branch. |
| 13:15 |
Stompro |
collum, double tested then! |
| 13:16 |
collum |
Excellent. Never can have too much testing. |
| 13:17 |
Stompro |
collum, I was just trying to remember how to do a signoff branch, so you let me know just in time. |
| 13:21 |
terranm |
Stompro++ collum++ Yay! Adding the patron id has helped us greatly since we implemented it. |
| 13:22 |
collum |
terranm, I really like that feature. It will help us, as well. |
| 13:36 |
terranm |
berick: If you do any updates on your test server this week can you please add the angular self-check as well? https://bugs.launchpad.net/evergreen/+bug/1840773 (I was going to test on mine, but I don't want to install the Angular circ branch on mine for this round of testing) |
| 13:36 |
pinesol |
Launchpad bug 1840773 in Evergreen "Angularize the Self-Check Interface" [Wishlist,Confirmed] |
| 13:39 |
berick |
terranm: can do. |
| 13:40 |
terranm |
berick++ |
| 13:52 |
|
terranm joined #evergreen |
| 13:55 |
|
jihpringle joined #evergreen |
| 14:16 |
terranm |
mmorgan: I loaded the current version of https://bugs.launchpad.net/evergreen/+bug/1891369 - wanted to let you know since you did a thorough testing of an earlier version |
| 14:16 |
pinesol |
Launchpad bug 1891369 in Evergreen "Circulation renewals near the due date should be extended" [Wishlist,Confirmed] |
| 14:17 |
mmorgan |
terranm++ |
| 14:17 |
mmorgan |
I'll see if I can take a look. |
| 14:30 |
JBoyer |
going to rebuild pattypan with pretty much all of berick's Angular-patron-related branches to try to get a little bit of testing for all of them. |
| 14:36 |
|
jihpringle joined #evergreen |
| 14:36 |
JBoyer |
And something I wanted to throw out since I noticed it go by in email: Testing at all is great, but don't forget to fire up Firefox also; there are still 2 supported browser engines! |
| 14:37 |
JBoyer |
And everyone++ |
| 14:38 |
terranm |
+1 |
| 15:06 |
JBoyer |
So that Angular patron statement is a little less impressive because one of the branched labeled as requiring it was mislabeled. (and it conflicts with the Angular stuff, so oops.) |
| 15:08 |
terranm |
That was probably my fault, sorry! |
| 16:19 |
|
terranm joined #evergreen |
| 16:19 |
|
jvwoolf1 joined #evergreen |
| 16:30 |
JBoyer |
FYI, there's a preview Hatch Installer linked from the spreadsheet. Both patches are client-side only so you can test them against any Evergreen server |
| 16:31 |
JBoyer |
Though both fixes are *also* client-side only so you could pretty much install, check perms in a couple places, uninstall and make sure everything is really gone. |
| 16:42 |
jvwoolf1 |
terranm: The link to festivus seems to go to pattypan |
| 16:53 |
* berick |
updates evgdemo.kcls.org |
| 17:07 |
csharp_ |
@decide evgdemo or venmo? |
| 17:07 |
pinesol |
csharp_: go with evgdemo |
| 17:20 |
berick |
terranm: https://evgdemo.kcls.org/eg2/en-US/staff/scko -- this demo server has some odd caching proxy in front of it, sometimes I have to add a ?foo=bar to the end of the URL to get the latest page. |
| 17:21 |
terranm |
jvwoolf1 - it sure did! Fixed |
| 17:22 |
terranm |
berick: okay, thanks |
| 17:22 |
terranm |
berick: I will test in the morning! |
| 17:33 |
|
jvwoolf1 left #evergreen |
| 15:57 |
berick |
i think it only uses memcache for certain types of values |
| 15:57 |
berick |
otherwise, just a locally cached value |
| 15:58 |
Bmagic |
browser cache? apache cache maybe? |
| 15:58 |
Bmagic |
on a test machine, the variable looks like this: $VAR1 = bless( [569,'icon_format','eaudio','E-audio',undef,'t','E-audio','f',undef], 'Fieldmapper::config::coded_value_map' );node |
| 15:59 |
Dyrcona |
The memcache key looks like "EGWeb.$locale.$hint." where $locale is the current locale (probably en-US) and $hint is the IDL classs: ccvm. |
| 15:59 |
Bmagic |
but on the broken system: $VAR1 = '' |
| 16:00 |
Dyrcona |
The list will have list appended, so : "EGWeb.en-US.ccvm.list" or something like that. |
| 16:30 |
Bmagic |
sounds good to me. I'll just have to wait till night |
| 16:31 |
Dyrcona |
If you empty out the list key, it might reload. I think it works like that. berick would know better than I. |
| 16:31 |
Bmagic |
that key isn't in the cache |
| 16:32 |
Bmagic |
it exists on my test system, but not on the broken system |
| 16:37 |
berick |
the only thing that would prevent it from getting added to the cache is if the value for the requested ID is in the process-level cache |
| 16:37 |
berick |
but if you reload Apache, then that should be moot |
| 16:37 |
berick |
may restart apache instead *shrug* |
| 09:57 |
Dyrcona |
~~~~~~~~~~~~~~~~~~~~~~ |
| 09:57 |
Dyrcona |
src/app/share/fm-editor/fm-editor.component.ts:518:51 - error TS2339: Property 'linkedSearchConditions' does not exist on type 'FmFieldOptions'. |
| 09:57 |
Dyrcona |
518 field.idlBaseQuery = fieldOptions.linkedSearchConditions; |
| 10:00 |
Dyrcona |
Yeahp. Looks like Lp 1851884 should not have been backported or should have been tested/modified for rel_3_7. |
| 10:00 |
pinesol |
Launchpad bug 1851884 in Evergreen 3.8 "eg-fm-record-editor: take care wiring up comboboxes" [High,Fix committed] https://launchpad.net/bugs/1851884 |
| 10:02 |
Dyrcona |
JBoyer | gmcharlt_ ^^ |
| 10:03 |
Dyrcona |
I'm gonna revert it locally and will likely revert it before building the actual 3.7.4 release unless someone comes up with a fix. |
| 14:44 |
Dyrcona |
So, ng build --prod blows up on rel_3_7, but just ng build doesn't. |
| 14:47 |
gmcharlt_ |
hmm - I may have a bit of time to look over the weekend |
| 14:48 |
gmcharlt_ |
but yeah, AIUI, --prod vs. not is actually two different copilers |
| 15:03 |
Dyrcona |
gmcharlt_: Cool. I'll not revert anything else. It looks like 5380bfb11a3a38bac521ce8ef92216c13d46f3b9 has issues as well. I swear that worked when I looked at it, but maybe I didn't really test it on 3.7. |
| 15:03 |
Dyrcona |
backports-- |
| 15:10 |
|
mantis1 joined #evergreen |
| 15:18 |
Dyrcona |
I am inclined to just revert that commit, too, but I'll wait to see what gmcharlt_ thinks. |
| 11:16 |
gmcharlt_ |
berick++ |
| 12:14 |
berick |
Bmagic++ # just saw your earlier comment. |
| 12:15 |
berick |
working on cleaning up the branch now |
| 12:18 |
Dyrcona |
Crazy. I'm still seeing the discrepancy in 856 display on this test vm compared to production, and I can't find the difference in the code. |
| 12:28 |
Dyrcona |
Hmm.... Looks like the difference may be in the database. 856$3 shows up in asset.uri.label in the test db but goes in asset.uri.use_restriction in production. |
| 12:28 |
Dyrcona |
But! The database code should be identical since the test db was restored from a dump on Sunday. |
| 12:29 |
|
collum joined #evergreen |
| 12:29 |
mmorgan |
Dyrcona: Is there a difference in the function biblio.extract_located_uris? |
| 12:34 |
Dyrcona |
mmorgan: I'll check but there shouldn't be. It's a restored dump, both on Pg 10. |
| 12:47 |
Dyrcona |
But, how..... |
| 12:48 |
Dyrcona |
I have only 1 biblio.extract_located_uris, so there's not one with a different signature hanging around. |
| 12:51 |
Dyrcona |
According to the db function, $Z or $2 should go in use_restriction and $y or $3 should go into label. My production db entries look like $y or $z is in label and $3 is in use_restriction. |
| 12:53 |
Dyrcona |
My old entries in the test database look like production, but when I update them, they get the "correct" values. I'm going to see if I can find some that were recently added. I suspect we had a hacked version of the db function that didn't make it through an upgrade. |
| 12:55 |
Dyrcona |
Too bad I don't have any really old dumps hanging around.... |
| 12:55 |
Dyrcona |
Hmm... I'll check the training server it might be old enough. |
| 12:55 |
Dyrcona |
mmorgan++ |
| 15:22 |
Dyrcona |
DB server is slow while it's creating a database with another as a template. |
| 15:29 |
|
dbriem joined #evergreen |
| 15:43 |
|
collum joined #evergreen |
| 16:35 |
* Dyrcona |
tests if setting an internal flag during a transaction, doing an update, then resetting the flag before commit works. I think it does, but the answer is that may depend on deferred triggers or not. |
| 16:36 |
Dyrcona |
I know that the internal flag update won't be visible outside of the transaction. |
| 16:36 |
Dyrcona |
Hmm... what's the thing to make all triggers immediate..... |
| 16:40 |
Dyrcona |
SET CONSTRAINTS ALL IMMEDIATE; # If you ever need it. |
| 16:40 |
Dyrcona |
That might break things for me but we'll see. |
| 16:41 |
* Dyrcona |
has a feeling the test transaction won't finish in the next 20 minutes, so we'll have to wait until tomorrow morning. |
| 16:51 |
|
jvwoolf left #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 19:56 |
|
jihpringle joined #evergreen |
| 10:50 |
pinesol |
News from commits: LP1958573 PMC messages created by action triggers not patron-visible <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ba2fc41399e9723361245a95e64d78a6c1eb2e59> |
| 12:15 |
mmorgan |
berick++ gmcharlt++ # fixing :) |
| 12:32 |
Dyrcona |
DBD::Pg++ |
| 13:03 |
Dyrcona |
Hrm.. URIs aren't displaying correctly on my test VM, and I just merged my production branch into my test branch.... |
| 13:04 |
Dyrcona |
And, there are no differences in the OPAC according to git diff.... |
| 13:13 |
Dyrcona |
Grr... Thought maybe a git clean -xfd and a rebuild would help, but no.... |
| 13:14 |
Dyrcona |
In production, the link is on subfield z and subfield 3 appears after it. On my test VM it is the opposite in both ways. |
| 13:21 |
Dyrcona |
Not even wiping out the installed bootstrap templates and reinstalling them helped.... |
| 13:22 |
|
jvwoolf left #evergreen |
| 13:29 |
Dyrcona |
Ah, wait a minute.... I recall something now about a difference between the ttopac and bootstrap opac and I had to patch it. However the patch doesn't seem to be missing from the git branch AFAICT. |
| 15:31 |
berick |
gmcharlt_: so you're thinking flip the big switch on day one too? |
| 15:32 |
terranm |
I could work up a list of tasks that need to be tested for each of the new interfaces as a starting point. It might be easier to get people to test if it's broken into bite-sized pieces. |
| 15:32 |
mmorgan |
Just to clarify, right now, the new uis are under an org unit setting? |
| 15:32 |
gmcharlt_ |
more like stand up test systems that have the switch flipped |
| 15:32 |
berick |
mmorgan: sort of. it's kind of a mess what we have. |
| 15:32 |
berick |
that we were going to test with |
| 15:32 |
berick |
i'm of the opinion that when we do flip the switch, it has to be fully flipped or it's going to get really confusing real fast |
| 15:33 |
berick |
hopping between the same UI's depending on how you got there |
| 15:33 |
gmcharlt_ |
(also noting that soon there will be a dump of the Angular acquisitions sprint 4 stuff, though that's more self-contained than the patron/circ stuff) |
| 15:34 |
JBoyer |
terranm++ I do think having a reminder of what all needs to be tested helps. I wonder if some of the staff interfaces have the 1-2 things users do *most* and then say "yeah, didn't fall over" by end users. A guide would help them test things they maybe do quarterly or less. |
| 15:34 |
mmorgan |
terranm++ |
| 15:34 |
mmorgan |
+1 to broad community testing |
| 15:35 |
shulabear |
terranm++ |
| 15:35 |
gmcharlt_ |
also, I think the more that the branch can be cleaned up to have new and changed shared component live in self-contained patches, the better |
| 15:36 |
gmcharlt_ |
as individually, those should be much more amenable to piecemeal testing by devs and committers |
| 15:38 |
berick |
yeah, i can clean up the shared/core changes. that's a small portion of it. |
| 15:39 |
gmcharlt_ |
and I think the other thing that would help is ensuring that there's one big ol' switch (or maybe a small set of them) to reliably switch between old and new interfaces |
| 15:39 |
berick |
it gets a little complicated with the patron UI, since it's basically one big application. it kind has to be added as a whole. |
| 15:43 |
* Bmagic |
scrolls up |
| 15:44 |
* phasefx |
still remembers having three or so pull lists |
| 15:44 |
gmcharlt_ |
but I mislike the notion of potenially have 3.10.0 end up being intentionally full of regressions |
| 15:44 |
berick |
but going back to my original proposal, if we merge the code without any menu/link updates, then we have a body of code we can start building on, which will have the affect of testing said code. Eg. it's a lot easier to test a new Item Status UI then overhauling the whole patron UI. |
| 15:44 |
mmorgan |
gmcharlt_++ |
| 15:44 |
gmcharlt_ |
I wonder if we should consider an extended timeframe for 3.10, balanced with a brief 3.11 |
| 15:45 |
berick |
i wasn't trying to flip the switch for 3.10. a full switch flip should happen basically the day after a major release is made |
| 15:48 |
mmorgan |
berick: Meaning not going all in and the "switch" being don't upgrade. |
| 15:48 |
gmcharlt_ |
JBoyer: one huge change and a largish change (acq) |
| 15:48 |
Dyrcona |
Why not add it after 3.10, go all in, and 3.11 becomes 4.0 if the changes are that big? |
| 15:49 |
gmcharlt_ |
because anything that isn't turned until 3.11 will largely not get significant testing untikl 3.11 starts (is my fear) |
| 15:50 |
Dyrcona |
Anyone testing leading up to the 3.11 release would be using the new interfaces. |
| 15:50 |
gmcharlt_ |
berick: let me ask you this - assuming a longer 3.10 cycle, is your branch essentially feature complete now? (barring the inevitable obscure YAOUS implementations and so forth)? |
| 15:50 |
phasefx |
this is probably crazy, but how about we hold releases hostage until we get significant testing? super long rc-1 for whatever holds the new stuff |
| 15:55 |
gmcharlt_ |
2. merge sooner rather than later, hopefully with some cleanup of the branch |
| 15:56 |
gmcharlt_ |
3. target this for 3.10, then aim for broad testing |
| 15:56 |
berick |
what if the Big Red Switch is a patch/commit? making all the links/buttons have optional destinations is non-trivial |
| 15:56 |
gmcharlt_ |
3a including nudges, test systems, etc. |
| 15:57 |
gmcharlt_ |
4. we agree to prepare to extend 3.10 into November, possibly early December |
| 15:58 |
gmcharlt_ |
5. and by mid-November, review the state of the bugs against the Angular interfaces and make a go/no-go decision |
| 15:58 |
gmcharlt_ |
5a. (which is potentially when the decision to apply the BRS as a commit, if that's what it has to be, gets made) |
| 15:58 |
gmcharlt_ |
(end of my list) |
| 15:59 |
gmcharlt_ |
but basically, combine (a) a quick merge so that the code doesn't age or diverge too much with (b) a much more intentional testing stance for a big change like this than may have been the case in the past |
| 16:00 |
gmcharlt_ |
without kicking the can to 3.11, since the testing needs to happen eventually and it would be good not to block the potentiall for normal enhancements to patrons/circ |
| 16:00 |
berick |
gmcharlt_: ok, that makes sense. and the BRS will be a commit that just reverses all the link/button/menu changes? |
| 16:01 |
berick |
or a revert, basically |