12:27 |
mantis34 |
this was after running an npm install in the Angular folder |
12:40 |
jvwoolf |
We tracked the errors down to this file introduced with the fix for LP 2002435: Open-ILS/src/eg2/src/app/staff/share/admin-page/admin-page.component.spec.ts |
12:41 |
pinesol |
Launchpad bug 2002435 in Evergreen 3.9 "Can Still Delete Shelving Locations with Items Attached" [Medium,Fix released] https://launchpad.net/bugs/2002435 |
13:09 |
JBoyer |
mantis34, jvwoolf, if that's a test failure related to the defaultNewRecord test that's harmless. Because of the timing for the security release we let that through but I can fix it soon. (The "fix" is to just remove that test, because the patch being tested isn't in 3.9) |
13:10 |
JBoyer |
But the spec file was added in the conflict resolution of another patch that came after. |
13:11 |
|
mmorgan1 joined #evergreen |
13:14 |
jvwoolf |
JBoyer++ |
13:20 |
|
mmorgan joined #evergreen |
13:21 |
|
mantis41 joined #evergreen |
13:22 |
|
mmorgan2 joined #evergreen |
13:30 |
Dyrcona |
Speaking of tests: Does anyone know the magic sauce to the get cover uploader live test to pass with 3.10 on Debian Bullseye? |
13:32 |
Dyrcona |
Apparently, it is getting a 404 response, but the configuration appears to be in place. I'll check that again. |
13:34 |
|
mantis25 joined #evergreen |
13:35 |
Dyrcona |
I also changed the /tmp directory having some vague memory of that being a problem in the past. |
13:39 |
JBoyer |
The failing test on rel_3_9 has been fixed. That doesn't change the 3.9.2 tarball or branch, but we're good going forward/ |
13:42 |
JBoyer |
Dyrcona, I think that test depends on /openils/var/web/opac/extras/ac is writable by the apache user. Is apache running as opensrf on your test system? To my knowledge this is the first test that actually uses the local web server. |
13:44 |
Dyrcona |
JBoyer: Thanks for the suggestion. It looks like running autogen.sh fixed my issue. |
13:44 |
Dyrcona |
I guess I forgot to do it the first time... |
13:45 |
gmcharlt |
does anybody happen to have examples of using authorities with 148 fields in production? |
13:45 |
Dyrcona |
JBoyer++ |
13:45 |
JBoyer |
Probably the first test that depends on that too. :) (I wasn't real fond of adding that to autogen.sh, but it was more expedient than teaching the build system to create the necessary directories) |
13:45 |
Dyrcona |
Yeah. I agree. |
14:32 |
|
dtmoore joined #evergreen |
14:53 |
csharp_ |
gmcharlt: how would we know? |
10:31 |
Dyrcona |
When I hash just the relpath "ahr" I get "35b605f929209fc6cba65789d1f6b61c" with Python and with Emacs. |
10:33 |
Dyrcona |
With the Python, I went through the steps of split and join, etc., as well just to see if that made a difference. It didn't. |
10:36 |
|
mmorgan joined #evergreen |
10:42 |
Dyrcona |
I love that this is the only test for the hex_md5 function in our library: return hex_md5("abc") == "900150983cd24fb0d6963f7d28e17f72"; |
10:43 |
Dyrcona |
Python, Emacs, and our JS library all agree on that one, just not on other strings. |
10:44 |
Dyrcona |
Oops. Spoke too soon. They don't agree. The beginning and ends are the same. |
10:44 |
Dyrcona |
So, I suspect a bug in md5.js.... |
12:18 |
gmcharlt |
(though 99% of the time it would, since there's little reason to have not done a configure/make in your Git checkout) |
12:18 |
gmcharlt |
more likelike to bite one is making changes to Cronscript.pm and forgeting that Cronscript.pm.in is the file that's acdtually under version control |
12:18 |
gmcharlt |
*likely |
12:20 |
Bmagic |
I see. So in almost all of the Perl file cases, you can edit the *.pm files in the repository, and with the symlink, they would be "live" (after a service restart) - whereas, Cronscript.pm.in is not "live" and I would need to copy my changes from Cronscript.pm -> Cronscript.pm.in once tested |
12:21 |
gmcharlt |
yep |
12:21 |
Bmagic |
gmcharlt++ |
12:21 |
gmcharlt |
(though in practice, that file does not get touched all that often) |
12:29 |
Dyrcona |
All of the *.in files bet mangled during installation. Most of them are modified with sed. There's a better way to do it with make targets to have AC_SUBST run on them. |
12:29 |
Dyrcona |
s/bet/get/ |
12:30 |
Dyrcona |
Well, I guess we'd add them to a list in configure.ac. |
12:33 |
Dyrcona |
You can copy the files from lib over to the installation location after you've modified them, then restart services. That's what I do if I'm testing a change in one or two files. |
12:34 |
|
collum joined #evergreen |
12:38 |
Dyrcona |
So, when I load the report utils functions and the md5 functions in jsc, I do NOT get the same relation values that I'm seeing in this one reports template. I'm going to check another template with the same tables. |
12:44 |
* Dyrcona |
must be missing something in the composition of path, but I'm using the path that appears in the report template itself, which is what the JS code appears to use. |
10:18 |
* mmorgan |
was going to suggest inserting Autorenew notify events directly into the table, but that's not necessary in your case. |
10:31 |
Dyrcona |
Well, if I had to do that, I was going to use Perl with DBI to figure out the user data for the autorenew notify events, and then use open-ils.trigger.event.autocreate to make the notify events. |
10:31 |
|
ahazaril joined #evergreen |
10:32 |
ahazaril |
I'm having difficulty to import MARC Records. Evergreen version that I used are 3.9.1. I follow the manual exactly. I tried on test server (https://bugsquash.mobiusconsortium.org/eg/staff) seems successfully, but when I tried using our Library Server, its shown error. |
10:32 |
ahazaril |
Any advice regarding this problems? |
10:32 |
ahazaril |
Here the osrfsys.log file |
10:32 |
ahazaril |
[2023-03-10 20:30:14] open-ils.vandelay [INFO:6795:CStoreEditor.pm:155:1678451399712214] editor[1|1] request en-US open-ils.cstore.json_query.atomic {"select":{"au":[{"column":"id","transform":"permission.usr_has_object_perm","params":["CREATE_BIB_IMPORT_QUEUE","vbq",4,"1"],"alias":"has_perm"}]},"where":{"id":"1"},"from":"au"} |
10:32 |
ahazaril |
open-ils.cstore 2023-03-10 20:30:14 [INFO:6996:osrf_application.c:1075:1678451399712214] CALL: open-ils.cstore open-ils.cstore.json_query.atomic {"from":"au","where":{"id":"1"},"select":{"au":[{"transform":"permission.usr_has_object_perm","column":"id","alias":"has_perm","params":["CREATE_BIB_IMPORT_QUEUE","vbq",4,"1"]}]}} |
10:32 |
ahazaril |
open-ils.cstore 2023-03-10 20:30:14 [INFO:6996:osrf_app_session.c:1181:1678451399712214] [open-ils.cstore] sent 385 bytes of data to opensrfprivate.localhost/open-ils.vandelay_drone_at_localhost_6795 |
10:32 |
ahazaril |
open-ils.cstore 2023-03-10 20:30:14 [INFO:6996:osrf_stack.c:163:1678451399712214] Message processing duration 0.006715 |
10:32 |
ahazaril |
[2023-03-10 20:30:14] open-ils.vandelay [INFO:6795:CStoreEditor.pm:155:1678451399712214] editor[1|1] json_query : returned 1 result(s) |
10:32 |
ahazaril |
[2023-03-10 20:30:14] open-ils.vandelay [ERR :6795:Vandelay.pm:272:1678451399712214] unable to read MARC file /tmp/bc98fed09b3081514035f98464280b7c.mrc |
10:32 |
ahazaril |
[2023-03-10 12:30:14] open-ils.vandelay [INFO:6795:Transport.pm:163:1678451399712214] Message processing duration: 0.137 |
10:32 |
ahazaril |
open-ils.cstore 2023-03-10 20:30:14 [INFO:6996:osrf_stack.c:163:1678451399712214] Message processing duration 0.000004 |
10:33 |
berick |
ahazaril: see this https://bugs.launchpad.net/evergreen/+bug/1855199 |
10:33 |
pinesol |
Launchpad bug 1855199 in Evergreen "Vandelay record queuing can fail if spool directory is /tmp" [Medium,Confirmed] |
10:34 |
ahazaril |
tq berick & pinesol! |
08:48 |
|
kworstell-isl joined #evergreen |
09:03 |
|
Dyrcona joined #evergreen |
09:09 |
pinesol |
News from commits: LP1999282 Less intense badges for staff interface <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=39c44d2c0a6f5eab4d93b564b079be1cf75d85f2> |
09:56 |
Dyrcona |
BTW, if anyone wants to try development and testing on Pg 15 before Lp 1997098 and Lp 1999274 go in, I pushed user/dyrcona/pg15-master-for-dev to the working repo that combines both of those branches into master. I'm using it on my local development VMs with concerto. |
09:56 |
pinesol |
Launchpad bug 1997098 in Evergreen "Add Support for PostgreSQL 15" [Medium,Confirmed] https://launchpad.net/bugs/1997098 |
09:56 |
pinesol |
Launchpad bug 1999274 in Evergreen 3.10 "Performance of Search on PostgreSQL Versions 12+" [Medium,Confirmed] https://launchpad.net/bugs/1999274 |
09:57 |
Bmagic |
Dyrcona++ |
10:03 |
Dyrcona |
I don't know of any site running greater than Pg 10 in production. |
10:03 |
Bmagic |
right |
10:13 |
|
kworstell-isl joined #evergreen |
10:20 |
Dyrcona |
Couple of database live tests failed. I'd better have a look. |
10:36 |
|
Stompro joined #evergreen |
10:41 |
|
BDorsey joined #evergreen |
10:46 |
|
Christineb joined #evergreen |
11:09 |
Dyrcona |
Pro tip: Try to remember which port is which version of PostgreSQL, or you could waste an hour and a half trying to figure out whey pgtap live tests are failing on 1 server but not the others. |
11:09 |
Dyrcona |
s/whey/why/ |
11:09 |
pinesol |
News from commits: LP#1999274: Add Release Note <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=31e2d9a565a603f0044ce52ff1719e9eaa151dbd> |
11:09 |
pinesol |
News from commits: LP#1999274: Improve Search Performance on Pg 12+ <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=aa30c7e7b23a6dc4f10f5f1e7382cba13d787cf5> |
11:18 |
csharp_ |
ah |
11:18 |
Dyrcona |
So, tarball is busted. |
11:18 |
abowling |
Dyrcona: yes, that's our operating theory |
11:18 |
* Dyrcona |
doesn't use the tarballs, except for testing a release before release. |
11:18 |
abowling |
Git build likely works |
11:18 |
abowling |
tarball doesn't |
11:19 |
Dyrcona |
So that's bug worthy: broken tarball. |
11:19 |
abowling |
and i'm not 100% sure of this, but like i said, I wasn't the only one to witness ;) |
11:19 |
Dyrcona |
That's all supposed to be automated, but something likely went wrong with one of the npm steps. |
11:20 |
abowling |
Dyrcona: agreed; I'm hoping someone can test and disprove my theory...or confirm it |
11:20 |
csharp_ |
confirmed: no eg2 directory in the 3.10.0 tarball |
11:20 |
Dyrcona |
csharp_++ |
11:20 |
abowling |
csharp_: there's a ton missing...seemingly |
11:22 |
csharp_ |
or maybe I'm getting punchy - fasting today for Ash Wednesday |
11:23 |
Dyrcona |
:) |
11:23 |
abowling |
installing 3.9.1 THEN 3.10.0 seemed to take care of a lot of it |
11:23 |
Dyrcona |
I solved my issues with ports and testing by doing apt purge postgresql-14. :) |
11:23 |
abowling |
we jumped from 3.7.1 to 3.10.0 |
11:24 |
Dyrcona |
abowling: We were going to do the same, but decided to wait until more 3.10 bugs are fixed. |
11:24 |
abowling |
Dyrcona: you decided to wait because you're smarter than I am |
12:22 |
Dyrcona |
I've referred to the documentation quite a lot, so I have it bookmarked. |
12:34 |
|
collum joined #evergreen |
12:40 |
|
collum joined #evergreen |
13:03 |
* Dyrcona |
ponders implementing a GUI to send SIP messages for testing purposes. Might be nice to test if check out works, etc. |
13:05 |
Dyrcona |
Not today, though. |
14:23 |
Dyrcona |
My dog is funny. I got some cashews for a snack. She likes them, too, so I gave her some. She won't eat them if I put them in a bowl or on a plate. I have to hand them to her or drop them on the floor. |
14:36 |
pinesol |
News from commits: LP#2007880: fix open-ils.actor.ou_setting.ancestor_default <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=13adaa938b5621f28ee1e30d200d9cb9787f23a3> |
16:21 |
abowling |
Dyrcona: yep. nothing. |
16:22 |
Dyrcona |
Did you install this clean or on top of a previous installation? If the latter you might want to rm -rf /openils/* and reinstall both OpenSRF and Evergreen. |
16:23 |
Dyrcona |
If it was a git checkout, I find that git clean -xfd and then a complete rebuild with autoreconf sometimes helps. Assuming that the problem could be mismatched versions of files... |
16:36 |
pinesol |
News from commits: LP1841871: Add a test for creating authority record from bib field <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=35338601f56e3961672e44b1c6001469be9d05c9> |
16:38 |
csharp_ |
unfortunately our fixes for the view_perm thing for the Library Settings Editor broke holds pull lists and probably other things |
16:38 |
csharp_ |
there's another bug in one of the subs - I'll file it as soon as I get a chance, but it is not this day |
16:39 |
csharp_ |
another use case for better test coverage |
16:43 |
Dyrcona |
csharp_: Have you tested that with Galen's latest patch for Lp 2007880 that I pushed this afternoon? |
16:43 |
pinesol |
Launchpad bug 2007880 in Evergreen " open-ils.actor.ou_setting.ancestor_default broken" [High,Fix committed] https://launchpad.net/bugs/2007880 |
16:43 |
Bmagic |
sorry abowling, I stepped away. But everyone else's suggestions are perfect! |
16:44 |
csharp_ |
lawd - I chased my tail for about an hour on that without realizing gmcharlt had already found it |
16:45 |
csharp_ |
Dyrcona++ # will test on another day |
16:45 |
csharp_ |
today has accomplished its apparent mission of kicking my ass |
16:45 |
Dyrcona |
heh.... |
16:58 |
* Dyrcona |
calls it a day. |
18:41 |
|
jihpringle joined #evergreen |
10:22 |
|
sleary joined #evergreen |
10:23 |
Dyrcona |
xmllint and namespaces..... :( |
10:25 |
Dyrcona |
Remove the namespace and I still get XPath set is empty.... |
10:27 |
Dyrcona |
Can I pick records to test, or what? <datafield tag="024" ind1=" " ind2=" "><subfield code="">660355362927</subfield></datafield> |
10:27 |
Dyrcona |
No subfield code..... |
10:27 |
Dyrcona |
How's that even possible? |
10:30 |
Dyrcona |
And, another one with a blank subfield code. |
12:51 |
Dyrcona |
OK. I got back to messing with my UPCs and I've verified that the XPath should work. Guess I'll have to wait for the full ingest to finish. One of the options that I used yesterday must have prevented the identifiers from being handled. |
12:55 |
Dyrcona |
Oof! |
12:55 |
Dyrcona |
I see I still have a problem and the XPath that I updated won't work.... |
12:58 |
Dyrcona |
I had to modify it slightly for the test script, and I assumed it was equivalent to what was in the database. It was not. |
12:59 |
Dyrcona |
OK! Now, it works with the same syntax. |
13:00 |
Dyrcona |
Too many different domain specific languages to try and keep straight.... "Says you..." "Says who?" "Says you, the Lisp guy." |
13:00 |
Dyrcona |
There's a joke in there. I promise. :) |
13:22 |
Dyrcona |
And, here come the "closing early" emails on the directors' list... :) |
13:54 |
jeff |
just perpetually overcast and gray skies here: https://youtu.be/FDvImJ_6HYw |
15:12 |
Dyrcona |
Looks like I finally fixed the XPath. I've got 106 entries in identifier_field_entry and they all look like UPCs. The ingest hasn't finished, yet. |
15:44 |
jeffdavis |
I've got a 3.9.1 test server where I've generated search suggestions (ran the sideloader steps and populated search.symspell_dictionary with >6M rows) and have the org settings/internal flags set to default values, the but I'm not seeing any suggestions on my test searches. Are there other steps I need to take to make this work? |
15:58 |
Dyrcona |
jeffdavis: Are you doing single word searches? |
16:00 |
jeffdavis |
good question - I am, I'll double check with other testers |
16:05 |
jihpringle |
jeffdavis: I just tried a single word and then a multiple word search on our testing server and I don't see anything new whether I get results or not |
16:49 |
Dyrcona |
Sorry, got distracted by some work. :) |
16:50 |
Dyrcona |
It has been a while since I looked at it. I'll have to do some code diving tomorrow. |
16:50 |
Dyrcona |
Cheers! |
14:31 |
jeff |
can you explain what you mean by "do not look like UPCs"? also, depending on a number of things, you might have a lot of outliers in that LIMIT 100... |
14:31 |
Dyrcona |
Yeah, when I do field = 18 they look like ISBNs, and 18 is ISBN. |
14:32 |
Dyrcona |
jeff: No problem: 192326039 | 4144895 | 20 | 1. Selected Economic Indicators, 2014-212. Financial Soundness Indicators, 2010-16; ANNEXES; I. Risk Assessment Matrix; II. Report on the Observance of Standards and Codes (ROSCs)-Summary Assessments of BCP; III. Report on the Observance of Standards and Codes (ROSCs)-Summary Assessments of ICP; IV. Report on the Observance of Standards and Codes (ROSCs)-Summary Assessments of C |
14:32 |
Dyrcona |
PFMI; V. Previous FSAP Recommendations; VI. Banking Stress Testing Matrix; VII. Corporate Stress Testing Matrix. 1. The FSCFIGURES; 1. The Macro Context; 2. A Bank Dominated Financial Sector; 3. Banking Sector Profile; 4. Bank Business Model Convergence; 5. Bank Measures of Systemic Risk and Spillover Networks; 6. Banks' FX and Liquidity Risks; 7. Banks' Returns, Asset Quality, and Solvency; 8. Corporate Sector Risks and Vul |
14:32 |
Dyrcona |
ies; 9. Summary Results of Solvency Stress Tests of Major Banks; 10. Results of the Liquidity Stress Tests of Major Banks; 11. Funding Liquidity-Solvency Feedback in Solvency Stress Tests; 12. Corporate Sector Stress Test Analysis; TABLES. |
14:32 |
Dyrcona |
That's definitely NOT a UPC. |
14:32 |
jeff |
ah, yes. |
14:32 |
Dyrcona |
That's the first result row. I must have a conflicting definition somewhere. |
14:36 |
Dyrcona |
So, we've got 505 and 246 possibly showing up. |
14:37 |
Dyrcona |
I used to know this part of Evergreen better than I do now. |
14:38 |
Dyrcona |
jeff++ mmorgan++ |
14:39 |
Dyrcona |
This is on a development/test system. I guess I'll double check production, too. Maybe it was something in this upgrade script.... |
14:39 |
jeff |
nothing stock references 505, but in mods that's tableOfContents, which is matched by the xpath for the keyword field "toc". |
14:40 |
jeff |
also, that specific record is deleted in your live system, which may or may not mean that its being skipped on reingests/etc. |
14:40 |
jeff |
s/its/it's/ |
10:02 |
|
Dyrcona joined #evergreen |
12:39 |
|
jihpringle joined #evergreen |
13:56 |
|
dmoore joined #evergreen |
14:01 |
mantis1 |
HI all. Pushed a working branch to the EG repo but can't find it/can't check the branch out in my test box |
14:01 |
mantis1 |
command was git push working lp1853630_carousel_shelving_location_desc:user/gmonti/lp1853630_carousel_shelving_location_desc |
14:02 |
mmorgan |
mantis1: it |
14:02 |
mmorgan |
's in the working repo: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmonti/lp1853630_carousel_shelving_location_desc |
14:02 |
mantis1 |
ah thank you |
14:02 |
mmorgan |
did you do a git fetch working? |
14:02 |
mantis1 |
I did sorry I was looking in the wrong repo |
14:02 |
mantis1 |
Thank you! |
14:03 |
mantis1 |
Do we add a sign off tag to the LP ticket? |
14:04 |
mantis1 |
or is that just after testing? |
14:05 |
Dyrcona |
mantis1: If you signoff the branch, all you have to do on the ticket is say that you pushed a signoff branch and where the branch is. |
14:05 |
Dyrcona |
It's probably best to wait until after you've tested it. I don't add my signoff if I can't get it to work. |
14:05 |
mmorgan |
mantis1: It needs a pullrequest tag, the signoff tag gets added by the tester |
14:05 |
Dyrcona |
Oh, yeah. You can add the signoff tag if you tested it. |
14:06 |
Dyrcona |
I may have misunderstood the situation. |
14:06 |
Dyrcona |
The original author doesn't add the signoff tag for their signoff. |
14:06 |
mantis1 |
mmorgan++ Dyrcona++ |
15:08 |
Dyrcona |
jihpringle++ jeffdavis++ |
15:08 |
terranm |
jihpringle++ jeffdavis++ |
15:08 |
Dyrcona |
Some of those will slow things down. |
15:08 |
jeffdavis |
Testers could also use it during bug squashing weeks, people doing acceptance testing on paid development project, etc. |
15:09 |
sandbergja |
3 and 7 also seem difficult. We don't really have comprehensive information about how all our functionality/settings are supposed to work. |
15:09 |
sandbergja |
be it 100% test coverage or a super-detailed manual |
15:10 |
JBoyer |
I do like the idea of basing an interface comparison checklist on it. You don't necessarily need to know how to use all of an interface if you can tell that you can get to X on dojo but not Angular. (so long as it's not an intentional workflow change) |
15:10 |
sandbergja |
so I'd be interested in some conversation about how developers can get all that info before embarking on an angularization |
15:13 |
Dyrcona |
I wonder if the Angular version needs to have feature parity with the previous interfaces(s). What if we came up with better ways of doing things? |
15:14 |
mmorgan |
re: library settings - it seems like calls to get library settings in existing code shouldn't be too hard to identify. |
15:14 |
JBoyer |
That's what I was getting at yeah. If you can get the same outcome with a different UI that's fine, but being able to do something in the old and busted but not the new hotness isn't great. |
15:15 |
tlittle |
#info tlittle = Tiffany Little, PINES |
15:17 |
jeffdavis |
IMO the state of our tests/docs means that we'll never catch all of these problems. I think the idea with a checklist was to make sure we're consciously thinking about these types of things at some point during the contribution process. |
15:17 |
berick |
yeah, what jeffdavis said |
15:17 |
Dyrcona |
This is going to be unpopular, but maybe we need stricter standards than "works for me" and X number of signoffs. |
15:18 |
sandbergja |
Dyrcona: what did you have in mind? |
15:19 |
berick |
so more emphasis is good |
15:19 |
berick |
and having a record of usual gotchas helps focus |
15:20 |
abneiman |
this is also where non-technical end users can be helpful - in terms of interface & workflow evalution |
15:20 |
Dyrcona |
sandbergja: I'm not really looking for more process, but I do think we need better automated tests, etc. I don't have much specific in mind at the moment. |
15:20 |
mmorgan |
abneiman++ |
15:21 |
Dyrcona |
Also, what abneiman said. We need more end users involved. |
15:21 |
tlittle |
abneiman++ |
15:22 |
mmorgan |
It's difficult for end users to get more involved, difficult for them to get their hands on the new development to test on. |
15:22 |
JBoyer |
Yeah, testers rarely need to be conversant in the technical bits, and sometimes the tech types don't know so much about how the end users do their thing. |
15:23 |
mmorgan |
Bugsquashing week is huge, but test systems are not real world. |
15:23 |
gmcharlt |
yeah - I think an additional factor is committer time, and more automation can help around the edges |
15:23 |
tlittle |
Numbers 6-7 are concrete things that fall squarely on the dev's shoulders, though, imo |
15:24 |
mmorgan |
tlittle++ |
15:25 |
JBoyer |
But to mmorgan's point, it's difficult to test on realistic data if you don't have the local staff to build and rebuild test systems. :-/ |
15:25 |
Dyrcona |
Well, hire someone. What we need is more resources. It's that simple. |
15:26 |
terranm |
Yeah, we find a lot of issues when we do our intensive pre-upgrade testing with a copy of real data. And then more issues when we go live. |
15:27 |
mmorgan |
Dyrcona: Agreed more resources, but imo it doesn't seem that simple to hire someone and bring them up the Evergreen learning curve. |
15:29 |
berick |
it may be helpful to consider that this phase of EG dev won't last forever. |
15:29 |
berick |
there's only so many non-Angular UI's |
15:31 |
dmoore |
oh duh, thanks |
15:31 |
sleary |
Even just focusing on the Angular UIs is a steep learning curve. I have had trouble with the lack of inline documentation on what various components do. (This topic is on the next new dev agenda, btw.) |
15:31 |
csharp_ |
dmoore: feel free to ask if there are other acronyms/jargon you don't understand |
15:32 |
sandbergja |
Dyrcona: for me, I think that goes back to better automated tests and docs -- hopefully when/if we migrate away from Angular, we'd have better safeguards against regressions |
15:32 |
mmorgan |
All part of the learning curve :) |
15:32 |
csharp_ |
part of the answer is new devs - both in general and the new devs group |
15:32 |
sandbergja |
also, here's hoping Angular stays healthy for quite some time yet. :-) |
15:34 |
csharp_ |
jihpringle++ jeffdavis++ |
15:34 |
abneiman |
yes, jihpringle++ jeffdavis++ I have already bookmarked this |
15:34 |
terranm |
Same here |
15:34 |
sleary |
Very useful! And I would like to do more with automated testing as well. |
15:34 |
mmorgan |
Agreed QA gotchas will be useful, there will always be change, we just need to manage it well |
15:35 |
mmorgan |
*just* |
15:35 |
jvwoolf |
jihpringle++ jeffdavis++ |
15:35 |
JBoyer |
So, I do think it should go to the dev lists (perhaps quarterly or so, even) so that we can move on to the second action item from the last meeting. :) |
15:35 |
Dyrcona |
This list is a good outline of where we need to pay attention, and tests/standard can be built around it. |
15:35 |
JBoyer |
Which is |
15:35 |
JBoyer |
#info Bmagic to email the development list about a way to share common Evergreen tools with the community. |
15:36 |
JBoyer |
Though I don't think Bmagic is available at the moment and I don't recall seeing this on the lists. We'll kick that can down the road. |
15:39 |
JBoyer |
Note though, if anyone else has an interest in the expanded sample data set and opinions on integration and etc. feel free to poke around, |
15:40 |
JBoyer |
Ugh, look at me, forgetting to add something to the agenda myself, heh. |
15:40 |
JBoyer |
#topic Evergreen Release Updates |
15:40 |
JBoyer |
#info I've built a 3.8.2 release to end the 3.8 line now that 3.10 is out, if you can help test it's at https://evergreen-ils.org/downloads/Evergreen-ILS-3.8.2.tar.gz (Note, I'm going to have to make a docs change before it's final-final, but no code changes.) |
15:41 |
gmcharlt |
JBoyer++ |
15:41 |
shulabear |
Jboyer++ |
15:41 |
sandbergja |
JBoyer++ |
15:41 |
mmorgan |
JBoyer++ |
15:41 |
Dyrcona |
JBoyer++ |
15:41 |
JBoyer |
It is 1. wicked late, and 2. not too difficult to test. IF you have access to a 3.8.1 db especially and can help test it (I know the version upgrade is fine for concerto, but you know how that goes) |
15:41 |
terranm |
JBoyer++ |
15:41 |
tlittle |
JBoyer++ |
15:42 |
rfrasur |
JBoyer++ |
15:48 |
mmorgan |
jeffdavis: Yes, mostly without branches. A few have pullrequests |
15:49 |
jvwoolf |
mmorgan: I've push patches to all of the ones that were showstoppers for us so far |
15:49 |
terranm |
We're going ahead with upgrading because they're not show stoppers for us, but we know there will be some grumblings |
15:49 |
jvwoolf |
I'm likely done with my concentrated effort unless something comes up when we widen our testing to end users, or after we upgrade |
15:50 |
mmorgan |
Template issues, silent failure issues are big ones for us. |
15:51 |
mmorgan |
We're still sorting through and prioritizing |
15:51 |
|
smorrison joined #evergreen |
10:10 |
Dyrcona |
This JabberClient instance is no longer connected to the server |
10:13 |
Dyrcona |
ejabberd.log is, of course, useless. |
10:26 |
miker |
Dyrcona: I have ideas for making facets always faster (or at least never slower) since they can be turned into unique int IDs, but tuits... |
10:29 |
Dyrcona |
miker: Sounds cool. I also think that should be a separate bug from the ones I'm testing. It's just something that I've noticed. |
10:30 |
Dyrcona |
It's not always slower, just sometimes. |
10:30 |
* Dyrcona |
goes fishing through logs for a really crazy search to test. |
10:45 |
Dyrcona |
So, that jabber thing that I reported earlier: Has anyone ever seen services crash and have 8 listeners all using 100% cpu? This appears to have happened right after I restarted services this morning. |
10:47 |
Dyrcona |
I suspect something in the configuration must be busted. |
10:57 |
Dyrcona |
Huh. Just restarting ejabberd seems to have fixed it for now. |
12:41 |
jvwoolf |
(We don't have symspell in our current version, still on 3.6.5) |
12:49 |
pinesol |
News from commits: Docs: updating Global Flags docs <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8326611f8dc232dda993dca412e429713189999a> |
13:49 |
csharp_ |
jvwoolf: it's definitely quicker without all the triggers if you can spare the downtime |
13:54 |
jvwoolf |
csharp_++ |
13:55 |
jvwoolf |
We have some time so I might test still test with triggers and without |
13:56 |
jvwoolf |
My guess is that the libraries may prefer to be offline than to have their Sunday staff let loose on a new version that might be slow because of the reingest, but I'll ask that question to our user group |
14:05 |
Dyrcona |
I think there are some patches in working branches that can make the ingest more palatable, but it looks like I have it on my other laptop, unless the one I was looking at went in. |
14:07 |
jvwoolf |
Dyrcona: The fix for bug 1931737 is in 3.9.1 |
14:07 |
pinesol |
Launchpad bug 1931737 in Evergreen 3.8 "Did you mean breaks parallel reingest and causes deadlocks when loading/overlaying bib records in the client" [High,Fix committed] https://launchpad.net/bugs/1931737 |
11:27 |
berick |
BTW, not sure if the backend will cache anything for a search that times out |
11:28 |
Dyrcona |
Well, it seems to work in the OPAC most of the time. |
11:29 |
Dyrcona |
I'll have to compare the two in more depth later. |
11:29 |
* Dyrcona |
is testing some search fixes on production data. |
11:31 |
Dyrcona |
It might be this particular search is way too broad given our data, but this has been consistent with other searches, IIRC. |
11:32 |
Dyrcona |
This search isn't returning results in the OPAC, either, and it gives up almost immediately. |
11:33 |
Dyrcona |
The query doesn't run nearly as long in the database now, either. |
11:56 |
|
jvwoolf joined #evergreen |
12:06 |
miker |
not here, but staff search never uses the cache. else newly added records wouldn't show up |
12:16 |
miker |
in the olden days, the #staff modifier would force skipping the cache. I think that still works? but docache probably overrides that heuristic |
12:20 |
Dyrcona |
Well, I've done some more fiddling around with that bug and comparing produciton with my test system with search patches. I get results in production regardless of filters, etc. On the test system, I either have to change to a title search or limit by library to get results. |
12:20 |
Dyrcona |
I suppose it is just my test database being slower than production. |
12:26 |
|
dguarrac joined #evergreen |
12:34 |
|
collum joined #evergreen |
12:47 |
|
collum joined #evergreen |