| 09:35 |
miker |
jboyer-isl: I'm sure you've already investigated this, but we've seen auto-sensing duplex settings fail with HP NICs and some switches ...have to force port speeds and duplex settings. the symptoms are what you describe |
| 09:36 |
* Dyrcona |
has seen auto-sensing fail with a number of different NICs. |
| 09:39 |
|
jlundgren joined #evergreen |
| 09:44 |
kmlussier |
A question about our QA guidelines. A good percentage of the fixes I loaded for Bug Squashing Day have changes made to a .pm file, but I don't think any had a regression test. |
| 09:45 |
kmlussier |
I just want to make sure I'm clear on the guidelines before I start adding needstest tags. Any change made to perl code since May of this year, no matter how large or how small, should have a test? Is that right? |
| 09:46 |
|
ericar_ joined #evergreen |
| 09:51 |
Dyrcona |
kmlussier: I don't think we have been quite that strict, although "should" is a recommendation, not a commandment. |
| 09:51 |
Dyrcona |
My understanding is if the commit messages provide adequate test instructions, the live test can be waived. |
| 09:53 |
kmlussier |
I thought the waiver was only given when there is a statement from the patch author explaining why a test is infeasible without significant refactoring |
| 09:53 |
* csharp |
gets indecisive about which bugs to focus on. Candidates today are bug 1175293 (highest "heat" of acq bugs), bug 1413352, and bug 924952 |
| 09:53 |
pinesol_green |
Launchpad bug 1175293 in Evergreen "ACQ: Allocate to Fund drop down menu (in Funding Source) Not Following Precedents Set by Other Fund Menus" [Medium,Confirmed] https://launchpad.net/bugs/1175293 |
| 09:54 |
pinesol_green |
Launchpad bug 1413352 in Evergreen "New Brief Record estimated price does not populate" [High,Confirmed] https://launchpad.net/bugs/1413352 |
| 09:54 |
pinesol_green |
Launchpad bug 924952 in Evergreen "Acquisitions: Order record loads fail when there is a null value in a holdings subfield" [High,Confirmed] https://launchpad.net/bugs/924952 |
| 09:54 |
Dyrcona |
csharp: Those look like good ones to work on to me. |
| 09:54 |
jeff |
I'm not sure what's more realistic: working toward a point where we aren't considering waiving tests like that, or expecting that regression testing is accomplished by reading commit messages and manually testing things as directed there. |
| 09:54 |
jeff |
(on all future commits) |
| 09:55 |
|
yboston joined #evergreen |
| 09:55 |
Dyrcona |
jeff: I agree. I think we want tests on all things in the future. It's a matter of taking the time to get there. |
| 09:55 |
kmlussier |
I didn't think the commit messages / manual instructions were related to whether a test was provided or not. It was just something that is a best practice to include in any bug fix. |
| 09:56 |
jeff |
@decide kick the can down the road[map] or test paralysis |
| 09:56 |
pinesol_green |
jeff: go with kick the can down the road http://www.firstpersontetris.com/ |
| 09:56 |
Dyrcona |
Well, that was my understanding. I could be mistaken. |
| 09:56 |
* jeff |
gives pinesol_green a look |
| 09:56 |
|
genpaku joined #evergreen |
| 09:57 |
csharp |
@decide [someone] or [someone |
| 09:57 |
pinesol_green |
csharp: Error: Missing "]". You may want to quote your arguments with double quotes in order to prevent extra brackets from being evaluated as nested commands. |
| 09:57 |
Dyrcona |
I know some bug fixes have been written and pushed since May that have not had live tests. |
| 09:57 |
csharp |
@decide [someone] or [someone] |
| 09:57 |
pinesol_green |
go with ericar |
| 09:57 |
jeff |
here i was hoping that pinesol_green would give us the kobayashi maru style solution when presented with those two equally undesirable options. :P |
| 09:58 |
kmlussier |
OK, but in re-reading that, if it is waived, an additional signoff is required. So, for the bug I'm looking at now, I guess I shouldn't be merging it because it either requires a test or requires an additional signoff. |
| 09:59 |
Dyrcona |
What we really need it a complete regression suite. Basically what we have are a strange hybrid of unit tests and some regression tests of some features. |
| 10:00 |
kmlussier |
But we will have more regression tests of more features if we continue to strongly encourage people to follow the guidelines. |
| 10:01 |
kmlussier |
Unless there is someone out there who has time to write a complete regression suite. :) |
| 10:02 |
Dyrcona |
Someone would have to make that a priority, yes, and devote resources to it. |
| 10:05 |
dbwells |
kmlussier: My understanding of the new test recommendations are the same as yours, though I'm also pretty sure that Dyrcona is right, and others have pushed stuff in without tests (which has generally confused me, and also made me wonder if others felt the descriptive tests were adequate) |
| 10:07 |
Dyrcona |
It was acknowledged that somethings are difficult to test, but I'll go along with requiring tests if that is what others understood. |
| 10:07 |
kmlussier |
Yeah, I don't doubt that some things have been merged without the tests. |
| 10:07 |
Dyrcona |
It could just be a minority (me) who misunderstood. :) |
| 10:14 |
dbwells |
It also isn't explicit in the 2.9 section of the document, but in my understanding we are still only requiring at least one new relevant test with each patch, not a complete and extensive suite (though it would be welcomed :) ). |
| 10:16 |
kmlussier |
Ok, so it looks like the guidelines were formalized at the August dev meeting. What I'm going to do then, for the patches I loaded on Sandboxes, is if the patch was created since August and makes any change to perl or database code, I'll add the needstest tag. |
| 10:16 |
kmlussier |
If it seems excessive for the code being changed, there is always that waiver that a dev can request if it seems excessive. |
| 10:16 |
kmlussier |
Bleh. Just a bit of redundancy in that sentence. |
| 10:19 |
|
rlefaive joined #evergreen |
| 10:24 |
Dyrcona |
I wonder if both pgtap and perl tests are required when the perl tests sufficiently exercise the database changes, but that could be a different discussion. |
| 10:24 |
* Dyrcona |
has a specific branch in mind where he added perl tests but not a pgtap test for the database changes, because function changes can be tricky in pgtap. |
| 10:24 |
kmlussier |
My gut reaction is that if the perl test sufficiently exercises the database changes, the perl test should be adequate. |
| 10:25 |
dbwells |
I agree. |
| 10:27 |
Dyrcona |
Sounds good to me. :) |
| 10:27 |
* Dyrcona |
returns to modifying a library's circ parameters. |
| 10:28 |
kmlussier |
For the discussion we just had, those tests are just for patches that fix bugs, right? In the case of jeff's code for bug 1013786, then, they wouldn't be required since it really is a new feature. |
| 10:28 |
pinesol_green |
Launchpad bug 1013786 in Evergreen "tpac: Check for password strength at login" [Medium,Confirmed] https://launchpad.net/bugs/1013786 - Assigned to Christine Burns (christine-burns) |
| 10:28 |
kmlussier |
I know it' says Medium importance, but, at this point, it feels like new feature to me. |
| 10:30 |
kmlussier |
Heh, I suppose we can remove the jspacremovalblocker tag from that one. :) |
| 10:31 |
* jeff |
looks at that bug |
| 10:31 |
berick |
no, we have to merge jspac back in until all of those bugs are closed. |
| 10:32 |
jeff |
Oh, forgot I added pullrequest-worthy code to that bug. |
| 10:35 |
dbwells |
I think the test standards, whatever they may be, should apply more or less equally to bugs and new features. The document refers to "new code contributions", so I think it covers everything. |
| 10:36 |
dbwells |
(Of course, later parts reference "fixes a bug", so who knows :P) |
| 10:37 |
* kmlussier |
nods |
| 10:40 |
Dyrcona |
Right, I thought the standard for bug fixes was deliberately lower than for new features, and that may be 1 source of any misunderstanding. |
| 10:42 |
* Dyrcona |
awaits angularpac.... ;) |
| 10:52 |
* Dyrcona |
isn't surprised. |
| 10:53 |
Dyrcona |
i might be surprised when you figure out the why, however. ;) |
| 10:54 |
* Dyrcona |
should revisit the circ history download bug with a new solution. |
| 10:55 |
kmlussier |
Once I focused just on patches added since August, the number requiring tests wasn't so high. |
| 10:55 |
* kmlussier |
returns to actual testing now. :) |
| 10:55 |
tsbere |
jeff: Do you have metarecord or part holds on no longer existing metarecords/parts? |
| 10:55 |
Dyrcona |
That would not surprise me. |
| 10:56 |
Dyrcona |
And I was think parts holds on part that have since disappeared. |
| 12:51 |
kmlussier |
But I know it doesn't reflect all of the work that has been happening |
| 12:53 |
|
mrpeters1 joined #evergreen |
| 13:14 |
|
mrpeters joined #evergreen |
| 13:19 |
mmorgan |
Bmagic: I'm testing lp 1331174. and am curious what your intervals for LONGOVERDUE and LOST are in production. |
| 13:19 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 - Assigned to Michele Morgan (mmorgan) |
| 13:20 |
mmorgan |
The seed mark Long Overdue trigger worked fine to mark items long overdue at 6 months. |
| 13:22 |
mmorgan |
Then I changed the mark Lost trigger to mark the items Lost at 7 months. But the Lost trigger didn't find anything to mark Lost. It's looking for transactions with stop_fines NULL or MAXFINES, so my LONGOVERDUE transactions didn't get picked up to be marked Lost. |
| 10:02 |
jeff |
especially if it was something other than a catalog search followed by placing a hold. |
| 10:03 |
jeff |
flight recorders. |
| 10:17 |
Dyrcona |
They make those: event loggers. |
| 10:19 |
jeff |
screen recording software exists for software testing and usability studies. i've often wanted to install at package and either enable it on machines that are having difficult-to-reproduce issues or have them recording semi-constantly with a X minute cyclical buffer. |
| 10:33 |
Dyrcona |
Event loggers are more fun: mouse_down btn 1 coords: 865, 124 and you get figure out what they clicked on. |
| 10:36 |
|
Shae joined #evergreen |
| 10:39 |
|
mmorgan1 joined #evergreen |
| 15:35 |
lualaba |
FIXME: If you encounter this alert, please inform your IT/ILS helpdesk staff or your friendly Evergreen developers. Sat Dec 12 2015 00:34:28 GMT+0400 (Georgian Standard Time) The action involved likely failed due to insufficient permissions. However, this part of the software needs to be updated to better understand permission messages from the server, so please let us know about it. PERM_FAILURE Permission Denied |
| 15:35 |
lualaba |
I try everything but nothing was helped |
| 15:37 |
|
lualaba_ joined #evergreen |
| 15:48 |
jboyer-isl |
I don't know if I'm making things better or worse, but I'm trying ubuntu's wily kernels on my new machines to see if that knocks out their network issues. The first test is "does it survive sudo shutdown -r now ?" |
| 15:53 |
Bmagic |
jboyer-isl++ |
| 15:55 |
Bmagic |
lualaba_: how about "STAFF_LOGIN" ? |
| 15:57 |
jboyer-isl |
By Jove; so far so functional. |
| 16:12 |
Dyrcona |
lualaba: You could try that. A stock installation should just work. |
| 16:12 |
lualaba |
have any chance to disable permission or delete? |
| 16:12 |
lualaba |
2.9 release is stable? |
| 16:12 |
Dyrcona |
lualaba: I was going to suggest altering the depth that the view_billing_type permission is granted to existing groups as a test. |
| 16:12 |
jeff |
if the existing admin user works and newly created users do not work, it may be that the new users do not have a working location set. |
| 16:12 |
Dyrcona |
jeff++ could be that. |
| 16:13 |
Dyrcona |
I thought of the perm depth because the client appears to checking loc 1. |
| 10:14 |
* Dyrcona |
wonders how that happened. |
| 10:14 |
jeff |
mrpeters: i wouldn't want to hazard a guess. if you're building debs, you can probably just patch it locally in the meantime as part of the usual build process on your end. |
| 10:14 |
Dyrcona |
I could try building a new 2.9.1 tarball, or anyone else could for that matter. |
| 10:15 |
Dyrcona |
I didn't test the fresh install from the tarball. |
| 10:15 |
mrpeters |
no, i certainly can patch it on our end that is no worries |
| 10:15 |
mrpeters |
but, maybe we should pull the tarball from the site until fixed? |
| 10:17 |
Dyrcona |
And, everyone just ignores me.... |
| 10:20 |
Dyrcona |
mrpeters jeff: I or anyone else can build a new 2.9.1 tarball and test it. I do not have time at this very moment to do that. |
| 10:21 |
mrpeters |
Dyrcona: I'm not suggesting you should have to. I am happy to fix it and test it -- I just don't know where the bug is |
| 10:21 |
Dyrcona |
mrpeters: Probably just one of those things that happens at the last minute. |
| 10:22 |
mrpeters |
no im not trying to assess blame or figure out what caused it -- i'm saying i dont know where the duplicated insert into the upgrade log occurs to fix the tarball and give you a new one |
| 10:22 |
Dyrcona |
Like you said, it works fine from git. |
| 10:23 |
jeff |
mrpeters: it should contain only one instance of that line. |
| 10:23 |
mrpeters |
jeff: perfect, thats exactly what i needed to know |
| 10:23 |
Dyrcona |
Yeah, probably because make_release was run more than once. |
| 10:23 |
mrpeters |
lets just pull it from git, don't you think? |
| 10:24 |
mrpeters |
and put the 002.schema.config.sql from git in the tarball and then i can test it and confirm its fixed and we can release it on the site |
| 10:24 |
jeff |
I don't know if there are other likely places where there will be issues that share the same underlying cause as that duplication. |
| 10:25 |
Dyrcona |
As much fun as this is, and as much as this is my fault, I have work to do for my employer, now. I'll catch up later if I can. |
| 10:25 |
mrpeters |
good point |
| 16:16 |
|
maryj joined #evergreen |
| 16:20 |
Dyrcona |
@eightball Will Francis lighten up? |
| 16:20 |
pinesol_green |
Dyrcona: It is so. |
| 16:37 |
phasefx |
re: qa tests, I'm changing the ultimate pass/fail logic for the "Installing Evergreen pre-requisites" section, so that it just considers the final return value from the pre-req Makefile. There are 3 "Result: FAIL"'s currently from 3rd party tests in that section, one for Business-PayPal-API, one for Business-OnlinePayment-PayPal, and an expected one for Class-DBI-Frozen-301 |
| 16:45 |
|
rlefaive joined #evergreen |
| 16:58 |
|
bmills joined #evergreen |
| 17:00 |
|
jlitrell joined #evergreen |
| 10:47 |
jboyer-isl |
Everyone seems to have also taken the day off. |
| 10:48 |
Dyrcona |
Just quiet today. |
| 10:48 |
Dyrcona |
Installed some NCIPServer changes this morning. |
| 10:49 |
jboyer-isl |
Ugh. That reminds me. NCIP is the one thing I haven’t tested on our dev server yet. I need to get back on that. |
| 10:50 |
Dyrcona |
You might be interested in the changes I put in lately, then. |
| 10:50 |
jboyer-isl |
Dyrcona: Almost certainly. Also, is your NCIP testing script somewhere handy? |
| 10:50 |
Dyrcona |
One stops a hold from being placed if all of the eligible copies are checked out or can't fill the hold. |
| 10:51 |
Dyrcona |
The other creates a dummy call number if they don't send one in the AcceptItem message. |
| 10:51 |
Dyrcona |
Not publicly, but I'll throw it in a gist for you. |
| 11:03 |
Dyrcona |
heh |
| 11:03 |
|
Christineb joined #evergreen |
| 11:06 |
Dyrcona |
I added a sample LookupUser request and added a comment on the fields you need to fill in. |
| 11:06 |
Dyrcona |
LookupUser for a known patron is a good smoke test. |
| 11:06 |
jeff |
there are a bunch of sample messages in the iNCIPit repo as well as several in some of the PDFs -- might have been the INN-Reach implementation PDFs from the ncip.info site. |
| 11:06 |
* jeff |
nods |
| 11:06 |
jeff |
few state-related dependencies. |
| 11:35 |
Dyrcona |
After making changes, one of the first things I do, is send a LookupUser request with my barcode. |
| 11:35 |
Dyrcona |
That will tell me if things are basically working, or if I really botched something. |
| 11:35 |
jboyer-isl |
I might even make that a daily (ish) icinga check, even though I don’t plan to modify it much. |
| 11:38 |
Dyrcona |
It's a good test for configuration changes, etc. |
| 11:39 |
jboyer-isl |
Hmm. I need to go over all of the set up again, I’m assuming that a Dancer stack trace isn’t ever the expected output. :-/ |
| 11:40 |
Dyrcona |
No, but if you look closely enough it can point to what is wrong. |
| 11:41 |
Dyrcona |
I've not documented this, but you could run this as a stand-alone dancer app on a vm with OpenSRF and Evergreen backend installed in what I call "client mode." |
| 11:41 |
Dyrcona |
I did my initial development and testing with Dancer listening on its own port on my development vm. |
| 11:42 |
jboyer-isl |
Bah, views is still pointing to the default (/home/chrisc/…) That’s likely related, even though I should have things set correctly. |
| 11:42 |
Dyrcona |
Yeah. that would make it hard to find the templates. |
| 11:43 |
* Dyrcona |
makes a note to autoconfiscate the installation some day or use Makefile.PL. |
| 08:58 |
|
Callender joined #evergreen |
| 09:12 |
|
Callender joined #evergreen |
| 09:26 |
|
maryj joined #evergreen |
| 09:26 |
* csharp |
tests dbs 's approach to bug 1206936 but is still seeing the wrong last_billing_note and last_billing_type for his original example |
| 09:26 |
pinesol_green |
Launchpad bug 1206936 in Evergreen "money.transaction_billing_summary view displays incorrect billing_type and billing_note for the actual last transaction" [High,Triaged] https://launchpad.net/bugs/1206936 |
| 09:26 |
|
drigney joined #evergreen |
| 09:27 |
csharp |
I'm wondering if the problem is that the older data in money.materialized_billable_xact_summary is what's wrong there (which would be a separate bug, probably) |
| 12:48 |
* csharp |
investigates actor.calculate_system_penalties() |
| 12:48 |
tsbere |
csharp: org_depth will only change new entries, assuming it isn't overridden by whatever sets it |
| 12:49 |
csharp |
ah - that helps |
| 12:49 |
tsbere |
csharp: I would start by checking what org unit your test is already set at. Change that to 1 (or the top of your tree if that isn't 1) to force it to show up everywhere. |
| 12:52 |
csharp |
I thought that's what 0 was doing - "all PINES libraries" is "0" for is |
| 12:53 |
csharp |
s/is/us/ |
| 12:53 |
jeff |
you have an actor.org_unit row with id = 0? |
| 12:53 |
jeff |
or do you mean 0 as "depth"? |
| 12:54 |
csharp |
jeff: 0 is depth here, I think |
| 12:54 |
csharp |
if it's consistent with other uses of "depth" in EG |
| 12:56 |
jeff |
i'm fairly certain tsbere was recommending that you set the org_unit value of your test row in actor.usr_standing_penalty to be the id of the org that is top of tree, which in most systems (and i think PINES also) is 1. |
| 12:57 |
tsbere |
csharp: What jeff said. As I pointed out, changing the depth on the penalty type will, at best, only apply to future applications |
| 12:57 |
csharp |
ah - I see |
| 12:57 |
csharp |
okay - lemme try something |
| 17:00 |
|
vlewis_ joined #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 17:35 |
|
vlewis joined #evergreen |
| 17:47 |
Bmagic |
Is there a trick to get the web based staff client working on 14.04? Firewall or something. All the node/bower/grunt are installed and working as far as I can tell. Tests pass. Apache2-websockets is running. |
| 17:47 |
Bmagic |
domainname/eg/staff/ opens and shows the login |
| 17:47 |
berick |
https? |
| 17:48 |
Bmagic |
logging in, I see that there is a request for port 7682, which is attempted and timed out |
| 08:53 |
pgardella |
jboyer-isl++ |
| 08:53 |
pgardella |
jeff++ |
| 08:53 |
jboyer-isl |
Definitely. Now the simple fix is "is shared actually set to true" everywhere it needs to be? Hopefully that will be a simple fix. |
| 08:57 |
pgardella |
jboyer-isl: I think the issue is that the report templates are now owned by other users, which are not parent/child of one of the others. Most of the parents are null in template_folder |
| 08:58 |
pgardella |
All the folders except a few testing ones are shared, the templates just aren't where people expect them to be. |
| 08:58 |
jboyer-isl |
That's fine if they're not sub-folders. ("Templates", "Reports", and "Outputs" don't count as parent folders, even though that's how they're displayed.) |
| 09:00 |
* tsbere |
usually avoids sub-folders for a number of reasons |
| 09:21 |
|
jwoodard joined #evergreen |
| 13:43 |
jeff |
you can also \copy temp_staging FROM pstdin WITH CSV HEADER |
| 13:44 |
* csharp |
dives back into his "acq vandelay no longer creates copies" issue :-/ |
| 13:44 |
jeff |
which can be handy for something where you are using a psql variable like :somevar |
| 13:44 |
csharp |
I was hoping that upgrading the acq test server to 2.9.0 would Just Fix™ it |
| 13:45 |
jeff |
then you call psql -v somevar=3 -f script.sql dbname < $CSV_FILE |
| 13:46 |
csharp |
so hmm... what is supposed to happen if subfields are defined for a vendor/provider but not used in the file being uploaded? |
| 13:47 |
csharp |
$u barcode and $j call number are set up but they are not in the file being imported |
| 13:57 |
pinesol_green |
csharp: The operation succeeded. csharp hates acq way more than before. |
| 13:58 |
csharp |
well, they don't match in that barcode and call number are defined as holdings subfields but are not present in the uploaded file |
| 13:58 |
csharp |
but everything else lines up |
| 13:58 |
kmlussier |
csharp: I will confirm that mapping call number and barcode and then not including them in the upload shouldn't be a problem. I do it all the time in testing. |
| 13:58 |
csharp |
okay good |
| 13:59 |
csharp |
I *think* what I'm looking for is in the DB |
| 13:59 |
kmlussier |
csharp: They have values for quantity and owning library? |
| 14:01 |
csharp |
yep - that's where I'm spending a lot of my time lately |
| 14:02 |
csharp |
my coworkers love it! |
| 14:06 |
csharp |
huh acq.extract_provider_holding_data() returns no rows for one of the lineitems I just imported - maybe whatever is causing that not to work is the issue |
| 14:21 |
kmlussier |
csharp: I'm going to take back what I said earlier. I'm just retested, and I'm having trouble with the automatic barcode generation. I don't know if it's related to what's in the provider record or not. |
| 14:21 |
kmlussier |
I'm going to test a little further. |
| 14:21 |
kmlussier |
In my case, the acq.copies were generated, but I was getting a message saying that the barcode already exists. It was generating the same barcode for each lineitem. |
| 14:23 |
Dyrcona |
So, there isn't a good way to reprocess EDI messages, eh? |
| 14:23 |
Dyrcona |
IOW, it looks like it would be more hassle than it is worth. |
| 14:24 |
kmlussier |
@dunno |
| 14:24 |
pinesol_green |
kmlussier: Down time is a fact of business when you're a poor 501c3 corporation. |
| 14:25 |
Dyrcona |
But, to follow up on the conversation from hours ago, it does look like the problem with processing the invoic message was the space in the PO name. |
| 14:30 |
kmlussier |
csharp: After further testing, I can confirm that there is a problem with automatically generating barcodes if the provider record includes a subfield for barcodes but the incoming record doesn't include that subfield. |
| 14:31 |
csharp |
holy shiznit - I recreated the acq.extract_holding_attr_table function that was returning no rows with some RAISE NOTICE statements and after that it works |
| 14:31 |
csharp |
I have no idea why that would have work |
| 14:31 |
csharp |
ed |
| 14:31 |
csharp |
@eightball do we need to start reingesting acq functions now? |
| 14:31 |
pinesol_green |
csharp: Maybe... |
| 14:31 |
kmlussier |
csharp: Call numbers seem to generate fine in the same situation. Apparently, my comment above - "I do it all the time in testing" - was a big lie. |
| 14:31 |
csharp |
heh |
| 14:31 |
miker |
csharp: sounds like maybe you had an old version? |
| 14:32 |
csharp |
no idea |
| 15:29 |
dbwells |
csharp: Just read the backlog including the conclusion to your recent acq saga. Classic. :) Definitely been there once or twice. |
| 15:31 |
* dbwells |
feels better after thinking somehow, someway, he's the one who broke it |
| 15:39 |
csharp |
dbwells: I knew it was either something I did and didn't remember or something an end user did and wasn't saying ;-) |
| 15:41 |
phasefx |
out of sight, out of mind. QA tests have been failing for a while. Suspect it's the environment and not EG code. Need to resubscribe pinesol to the RSS feed |
| 15:43 |
kmlussier |
yikes |
| 16:14 |
berick |
dbwells: i'm done w/ bug 1468422 for now. i left the authproxy for you if you want it. |
| 16:14 |
pinesol_green |
Launchpad bug 1468422 in Evergreen "Improve Password Management and Authentication" [Undecided,New] https://launchpad.net/bugs/1468422 |
| 16:20 |
dbwells |
berick: Thanks. You're right, it should be very simple (and remove some of the ugliness from AuthProxy to boot). I appreciate your efforts to handle the hard bits, and I'll definitely make it a priority. |
| 16:20 |
berick |
dbwells++ |
| 16:38 |
mmorgan |
Lovely moonrise tonight! Though I hate that it happens at 4:30 :-( |
| 17:06 |
phasefx |
a lot better this time: http://testing.evergreen-ils.org/~live/ |
| 17:10 |
|
mmorgan left #evergreen |
| 17:11 |
kmlussier |
phasefx++ |
| 17:42 |
Bmagic |
anyone played with running more than one instance of Evergreen on the same postgres cluster? divided by database and dbuser? |
| 14:14 |
kmlussier |
miker then suggested that we try removing uniqueWords in addition to documentLength. And we did. |
| 14:14 |
kmlussier |
krvmga: That's what you went live with. |
| 14:14 |
* krvmga |
adds opensrf.xml file to watch list |
| 14:15 |
kmlussier |
It didn't work out very well. Coverage density didn't come into play at all. So we restored them. |
| 14:15 |
kmlussier |
krvmga: I think the lesson is, don't touch those settings unless you do a lot of testing ahead of time. I personally have been scared away from touching them ever again. |
| 14:15 |
krvmga |
lol |
| 14:16 |
kmlussier |
krvmga: If you think back to the phrase search bug we discovered this week, search relevance in your early days were very similar to those results. |
| 14:16 |
miker |
kmlussier: removing all is effectively the phrase bug I just fixed, BTW. |
| 14:16 |
krvmga |
heh |
| 14:16 |
kmlussier |
miker: Not sure why removing documentLength on its own didn't do anything for us, because it is a question that has come up time and time again at all of our sites. |
| 14:18 |
miker |
kmlussier: part of it is that "document" really means "each individual field indexed, on its own" in evergreen |
| 14:19 |
kmlussier |
Yeah, but IIRC, we were testing it on keyword searches at the time. And it's back before we had added additional indexes before the blob. |
| 14:20 |
miker |
which, for titles especially, is a pretty narrow range of lengths |
| 14:21 |
miker |
tuits, but it wouldn't hurt to analyze in detail |
| 14:21 |
kmlussier |
We've generally found that the preference for shorter documents also leads to older records coming up high, because apparently we didn't catalog as much detail decades ago. |
| 14:22 |
krvmga |
yes, we have seen that is so. |
| 14:22 |
kmlussier |
Yeah, it might be worth taking another look at again since I don't have the pressure of two upcoming migrations as I did the last time we looked at it. |
| 14:23 |
krvmga |
i'm up for it. what i'm trying to do is document and test and document... |
| 14:23 |
* krvmga |
has to run to another meeting. back in a while. |
| 14:24 |
kmlussier |
Yes. One thing I want to do is put some of the search configuration for C/W MARS and NOBLE on the Evergreen wiki as examples of what they have done for adding indexes and improving relevancy. Maybe putting failed experiments there would be worthwhile too. |
| 14:36 |
gmcharlt |
dbs: looking at bug 1516867, and a quick question: any objection if sortable were moved to under Open-ILS/web/js/ ? |
| 14:36 |
pinesol_green |
Launchpad bug 1516867 in Evergreen "HTML reports should be dynamically sortable" [Wishlist,Confirmed] https://launchpad.net/bugs/1516867 - Assigned to Galen Charlton (gmc) |
| 14:37 |
* berick |
bites the bullet and updates to 15.10 on the laptop |
| 14:39 |
dbs |
gmcharlt: no particular objections; I had avoided it largely because everything under web/js/ appeared to be dojo, but there's always a first :) |
| 14:40 |
dbs |
gmcharlt: would you like me to refactor and push a revised branch? |
| 14:41 |
gmcharlt |
dbs: that would be great; meanwhile I'll finish testing its functionality |
| 15:23 |
* dbs |
suspects a Google Form might help the "CC gmcharlt" barrage (then either working with a google sheet backend to generate the JSON, and/or store the JSON in git for pull request delight) |
| 15:24 |
gmcharlt |
yeah, we'll certainly want something of the sort by the time it goes from beta to production |
| 15:27 |
dbs |
Oh right, it was the disturbing nature of having a CSS file located under a /js/ directory that gave me pause :) |
| 15:29 |
gmcharlt |
but not unprecented; lots of CSS files accompanying the Dojo stuff under /js/ |
| 15:30 |
dbs |
gmcharlt: I've pushed the branch with a second commit; you can squash it if you like |
| 15:31 |
gmcharlt |
thanks |
| 15:31 |
dbs |
thanks for testing! |
| 15:31 |
gmcharlt |
speaking of which, my substantive feedback from said testing |
| 15:31 |
gmcharlt |
1. looks nice and necessary |
| 15:32 |
gmcharlt |
2. the time it takes to render the table and sort it can really bog down after a certain point. with some emperical testing I've done in the XUL client and Chrome, up to 10,000 rows or so is fine |
| 15:33 |
gmcharlt |
but 100,000 can be a browser-killer |
| 15:33 |
dbs |
I think 100,000 rows is a killer without any javascript, isn't it? |
| 15:33 |
gmcharlt |
since the average # of rows in report output I've measured for a large consortium today is 4,300, on average things are fine as is |
| 15:34 |
gmcharlt |
but I'm thinking that perhaps picking a magic row count number, after which the JS isn't loaded, might be good |
| 16:36 |
Dyrcona |
Well, the IDL is valid XML. |
| 16:36 |
Dyrcona |
All the services are running. |
| 16:39 |
Dyrcona |
Lots of warnings about subroutines being redefined, but no syntax errors in AppUtils or CStoreEditor. |
| 16:45 |
Dyrcona |
Hmm... AppUtils.pm has undergone some changes in the past few weeks, including some from a test branch of my own, so guess I did modify AppUtils. :) |
| 16:47 |
Dyrcona |
So, I added a new subroutine that looks good and self-contained. |
| 16:48 |
Dyrcona |
I would almost think if this failed that the staff client would be unusuable. |
| 16:54 |
|
vlewis joined #evergreen |
| 10:29 |
Bmagic |
it could* work |
| 10:30 |
Bmagic |
lol |
| 10:30 |
* bshum |
doesn't think he's ever played Doom. |
| 10:30 |
gmcharlt |
Dyrcona: indeed, better ways for staff to visualize and/or test circ policies would be great |
| 10:30 |
Dyrcona |
The idea behind the solver is to show you how your rules actually work. |
| 10:30 |
phasefx |
Dyrcona: one useful entrypoint might be from the item editor, but you'd need a lot of context options |
| 10:30 |
Dyrcona |
You put in barcodes and locations and it tells you what happens. |
| 10:30 |
Dyrcona |
phasefx: I have been considering something standalone that only talks to the database. |
| 10:31 |
phasefx |
probably the safest option as far as clutter goes |
| 10:31 |
Dyrcona |
Another option is to add an open-ils.circ-solver service and make calls against that. |
| 10:31 |
phasefx |
there is a circ test api call, IIRC |
| 10:32 |
gsams |
Dyrcona: As someone more or less on the outside of things, I think this is a great idea. |
| 10:32 |
miker |
you know, I thought there was a UI in the xul client for supplying a patron and item barcode to "fake" a circ... maybe just a wishlist thing from long ago |
| 10:32 |
Dyrcona |
phasefx: yeah, but it either does too much or doesn't do enough depending on what I want to know. :) |
| 10:33 |
Dyrcona |
Most of the db functions that I use are not exposed directly in the open-ils api. |
| 10:33 |
miker |
ah, well, nevermind me ... phasefx++ |
| 10:34 |
gmcharlt |
it's a start though - and I think it would be good if the code that test circ policies were essentially accessing exactly the same pathways that real loan and hold transactions do... just with additional instrumentation as needed for Dyrcona's purposes |
| 10:34 |
phasefx |
miker: there's a Test Circulation option for some A/T stuff; you may be thinking of that. I never played with it |
| 10:36 |
kmlussier |
gmcharlt: I was just reviewing your RM proposal on supporting the web client for production use. When you mention holds, are you thinking of all holds functions, including pull list and managing the holds shelf, or were you just thinking of things you would most commonly do while working with a patron, (i.e. placing, viewing, updating holds)? |
| 10:36 |
Dyrcona |
Lovely: ERROR: column "ccvm.ctype" must appear in the GROUP BY clause or be used in an aggregate function |
| 10:37 |
Dyrcona |
Guess string_agg( ccvm.ctype || 'something else') doesn't count..... |
| 16:05 |
Dyrcona |
Well, I suspect something is slightly off on the input, but I don't read EDI. |
| 16:06 |
berick |
Dyrcona: not even enough to be fun at parties? |
| 16:06 |
Dyrcona |
What I think should happen is the id: for the line items should come from the RFF+LI after the / or whatever. |
| 16:07 |
berick |
useful tool: cd Open-ILS/src/support-scripts/test-scripts/; perl edi_reader.pl <edi_file> |
| 16:07 |
Dyrcona |
What happens on this one is they all get the same number from somewhere else in the INVOIC. |
| 16:08 |
Dyrcona |
And that seems to be happening with all of the invoices from this vendor for this library, so I'm tempted to say, just stop using that vendor. ;) |
| 16:08 |
csharp |
@quote add < Dyrcona> Acquisitions: It's all EDI to me. |
| 09:10 |
kmlussier |
miker++ #The fix for bug 1516707 is working great! |
| 09:10 |
pinesol_green |
Launchpad bug 1516707 in Evergreen "Relevance ranking deteriorates when phrases are added to search" [Medium,New] https://launchpad.net/bugs/1516707 |
| 09:10 |
kmlussier |
Dyrcona++ #Loading the fix on his VM |
| 09:11 |
Dyrcona |
kmlussier: Should we target that for 2.8 and 2.9? It could make it into today's releases, unless we think it needs more testing. |
| 09:12 |
kmlussier |
Dyrcona: I think it's good to go. I can merge it in a minute. Yes, I think it should be backported. |
| 09:14 |
Dyrcona |
I've targeted it for 2.8.5 and 2.9.1. I think we should let berick decide if it goes into 2.8, though. |
| 09:17 |
kmlussier |
OK, I'll hold off until I get the ok (or not ok) from berick then. |
| 10:29 |
bshum |
:) |
| 10:31 |
jboyer-isl |
Dyrcona: It’s probably not a great plan, but after our upgrades I stop looking at upstream (aside from security) until the next upgrade approaches, when I have to dust off a bunch of knowledge and start over. |
| 10:31 |
jboyer-isl |
Though that makes me wonder, why rebase to 2.9, I thought you stayed on master for the most part? |
| 10:31 |
Dyrcona |
I build new development/test branches almost weekly, sometimes more often, sometimes less. |
| 10:31 |
Dyrcona |
I typically include our customization branches unless I'm build for concerto. |
| 10:32 |
Dyrcona |
So they get rebased with some frequency. |
| 10:32 |
jboyer-isl |
That makes sense. |
| 10:37 |
Dyrcona |
kmlussier++ # for release notes |
| 10:37 |
Dyrcona |
Head's up: I've decided to roll 2.9.1 early in the day. |
| 10:38 |
Dyrcona |
Most of the fixes are in, and we'll have a few left for 2.9.2. |
| 10:38 |
Dyrcona |
Most of the ones that haven't made it are not things that I think I can test easily, i.e. would take me more than one day or we don't normally use that feature. |
| 10:39 |
pinesol_green |
[evergreen|Kathy Lussier] Adding bug fixes and acknowledgements to 2.9.1. Release Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ada78de> |
| 10:59 |
|
ericar_ joined #evergreen |
| 11:09 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.8.5 point release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f14e164> |
| 11:10 |
berick |
kmlussier++ |
| 11:11 |
|
sarabee joined #evergreen |
| 11:11 |
Dyrcona |
berick: Did you want the QP fix branch in 2.8? kmlussier and I weren't sure if you wanted to test it before or not. |
| 11:11 |
kmlussier |
berick: For reference bug 1516707 |
| 11:11 |
pinesol_green |
Launchpad bug 1516707 in Evergreen 2.8 "Relevance ranking deteriorates when phrases are added to search" [Medium,New] https://launchpad.net/bugs/1516707 |
| 11:12 |
Dyrcona |
heh. I was just looking the bug# up. |
| 11:12 |
kmlussier |
I had it in an open tab |
| 11:12 |
berick |
Dyrcona: yes, i do want it. |
| 11:13 |
berick |
did we ever find a suitable concerto test for that? |
| 11:13 |
berick |
(not that worried about it, really, if it works in 2.9) |
| 11:13 |
Dyrcona |
I don't think so, but kmlussier would know better than i. |
| 11:13 |
kmlussier |
berick: No, I don't think it's something you can test in concerto. I tested it with production data. |
| 11:13 |
Dyrcona |
It works on my production data. |
| 11:14 |
berick |
k |
| 11:14 |
berick |
i'll just make sure it doesn't blow up |
| 11:14 |
kmlussier |
berick: Actually, "violin concerto" might be a good test. |
| 11:15 |
Dyrcona |
:) |
| 11:16 |
berick |
i'll try that |
| 11:16 |
berick |
thanks |
| 12:25 |
|
ericar_ joined #evergreen |
| 12:39 |
|
Christineb joined #evergreen |
| 12:40 |
Dyrcona |
Yay for new server(s)! |
| 12:42 |
csharp |
are there currently test suites for javascript in EG? |
| 12:42 |
csharp |
we're looking at karma/jasmine and it's very simple to use |
| 12:43 |
csharp |
(in the angularjs bootcamp) |
| 12:43 |
csharp |
https://jasmine.github.io/2.3/introduction.html & https://github.com/karma-runner/karma |
| 12:45 |
* csharp |
has a stack of new dells sitting on the cage floor waiting for power which is waiting for contract stuff :-/ |
| 12:47 |
Dyrcona |
kmlussier and anyone else: Head's up that I am shutting down my normal vm to test the 2.9.0 to 2.9.1 upgrade. |
| 12:48 |
Dyrcona |
csharp: I'm not aware of any JS tests, but I've not looked into the Angular staff client code much. |
| 12:48 |
Dyrcona |
I know that Angular is supposed to be easy to write tests for. |
| 12:51 |
|
gsams joined #evergreen |
| 13:01 |
|
gsams joined #evergreen |
| 13:07 |
gmcharlt |
webstaff does have some tests for the Angular code |
| 13:08 |
Dyrcona |
I thought it might, but wasn't sure. |
| 13:10 |
|
jihpringle joined #evergreen |
| 13:10 |
berick |
csharp: we use karma/jasmine now for the angular stuff |
| 14:44 |
pinesol_green |
Launchpad bug 1517596 in Evergreen "webclient: merge patrons missing" [Medium,New] https://launchpad.net/bugs/1517596 |
| 14:44 |
pinesol_green |
Launchpad bug 1517595 in Evergreen "webclient: delete patron action is missing" [Medium,New] https://launchpad.net/bugs/1517595 |
| 14:45 |
csharp |
kmlussier: will do |
| 14:45 |
kmlussier |
I would have added that comment when I submitted them, but I didn't see it until it was too late. |
| 14:46 |
kmlussier |
Despite many, many hours of us of the web staff client, I sometimes feel as if I've only scratched the surface of testing it. There's just so much there. |
| 14:46 |
kmlussier |
s/us/use |
| 14:49 |
Dyrcona |
Oh, speaking of web client testing. My dev vm should be back to "normal." |
| 14:50 |
csharp |
kmlussier: I agree - PINES is about to dive into testing it on 2.9.X, so we'll have more data to work with |
| 14:52 |
|
vlewis__ joined #evergreen |
| 14:52 |
|
vlewis___ joined #evergreen |
| 14:56 |
|
vlewis joined #evergreen |
| 15:17 |
berick |
had to add -lm -lpthread and -lrt |
| 15:17 |
berick |
following along with https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713616 |
| 15:17 |
pinesol_green |
Debian bug 713616 in src:netcfg "netcfg: FTBFS: ld: /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libcheck.a(check.o): undefined reference to symbol 'floor@@GLIBC_2.2.5'" [Serious,Fixed] |
| 15:17 |
berick |
yay, tests pass |
| 15:18 |
berick |
that is, add it to Open-ILS/src/c-apps/tests/Makefile LIBS = |
| 15:18 |
pinesol_green |
[evergreen|Ben Shum] Docs: Change references to release 2.9.1 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=26d08db> |
| 15:18 |
* berick |
makes a note to open an LP |
| 15:20 |
berick |
kmlussier: I def. notice a difference in the "violin concerto" query after applying the QP patch |
| 15:26 |
Bmagic |
no problem! |
| 15:27 |
berick |
this is the result of the latest hackaway https://bugs.launchpad.net/evergreen/+bug/1513872 |
| 15:27 |
pinesol_green |
Launchpad bug 1513872 in Evergreen "Move EDI toggles into DB" [Wishlist,New] |
| 15:28 |
kmlussier |
berick: I'm not surprised about the "violin concerto" query. the results were quite remarkable in my testing on Dyrcona's database. I'm surprised I never noticed the problem before. |
| 15:29 |
kmlussier |
Pre-patch we have these results for "the blue": |
| 15:29 |
kmlussier |
http://catalog.mvlc.org/eg/opac/results?query=%22the+blue%22&qtype=keyword&fi%3Asearch_format=&locg=1 |
| 15:30 |
kmlussier |
And post-patch we have: |
| 15:30 |
csharp |
berick: happy to test whatever you need |
| 15:30 |
kmlussier |
https://jasondev.mvlcstaff.org/eg/opac/results?query=%22the+blue%22&qtype=keyword&fi%3Asearch_format=&locg=1 |
| 15:30 |
csharp |
(or otherwise help) ;-) |
| 15:30 |
berick |
kmlussier: makes all the difference |
| 09:19 |
|
mmorgan joined #evergreen |
| 09:36 |
|
yboston joined #evergreen |
| 09:54 |
|
sarabee joined #evergreen |
| 10:07 |
kmlussier |
Dyrcona: For clarification, test writing day is today, not tomorrow. |
| 10:08 |
Dyrcona |
Well, now you tell me. |
| 10:08 |
kmlussier |
ldw sent his email last night. |
| 10:08 |
Dyrcona |
And, goodbye. I have a day of meetings. |
| 10:51 |
* Dyrcona |
is likely to disappear in a minute or so. |
| 10:51 |
gmcharlt |
dbs: wheee! incompatible changes FTW! at least it was documented |
| 10:53 |
berick |
oh right... release cutting. |
| 10:53 |
* dbs |
ponders the work required to set up a suite of tests for the reporter |
| 10:54 |
dbs |
live tests I guess |
| 10:54 |
berick |
kmlussier: are you still our point person for release docs? |
| 10:54 |
kmlussier |
berick: Yup. I haven't done the legwork to find somebody to take my place yet. |
| 10:55 |
|
sandbergja joined #evergreen |
| 11:00 |
Dyrcona |
dbs: Of course it does. |
| 11:00 |
bshum |
"Can open.... worms everywhere...." |
| 11:01 |
Dyrcona |
bshum++ |
| 11:07 |
StomproJ |
Question for the core devs. I was working on combining all the outstanding "Permission missing from system" launchpad tickets into one branch. And I was also planning on merging all of the database upgrade scripts into one file. I was thinking that it would be easier to deal with them all at once, and just have one db update to apply and test. Is this an ok practice? |
| 11:07 |
bshum |
StomproJ++ # yes |
| 11:07 |
bshum |
And in fact I mentioned doing something similar at the Hackaway with mmorgan |
| 11:07 |
|
ericar joined #evergreen |
| 12:19 |
dbs |
yeah, yeah that's the ticket |
| 12:20 |
gmcharlt |
kmlussier: I think it reasonable to treat it as a backportable bugfix |
| 12:23 |
gmcharlt |
dbs: what about CSV and the debug HTML output? |
| 12:23 |
ldw |
Following the emails regarding test writing day and patch release day, I will postpone test writing day until next week. I will send out an email shortly. |
| 12:25 |
dbs |
gmcharlt: CSV seems to be handled by the Text::CSV_XS module, same way Excel module does |
| 12:25 |
gmcharlt |
OK |
| 12:26 |
gmcharlt |
(I'm asking on the basis of having just read the patch, not yet putting it through its paces) |
| 12:27 |
dbs |
I haven't bugged this or submitted it as a formal fix because I'm curious about what happens on a system with DBD::Pg 3.0.0+ |
| 12:28 |
dbs |
tsbere: I can believe that |
| 12:35 |
|
jihpringle joined #evergreen |
| 12:41 |
kmlussier |
ldw: I don't think that's necessary. Dyrcona thought test-writing day was tomorrow, not today. |
| 12:42 |
kmlussier |
ldw: I clarified the date for him in channel, but forgot to send something out to the list. |
| 12:45 |
|
sarabee joined #evergreen |
| 12:45 |
dbs |
fwiw, the debug output seems thoroughly escaped; a report name of 'Test Francais 8é' gets translated in the output as 'name' => "Test francais 8\x{e9}" |
| 12:46 |
dbs |
which seems fine. But then the subject of the email gets corrupted because we're not doing the right SMTP things |
| 12:46 |
dbs |
so... how far down this rathole do we really want to go? Me, I'm happy just seeing the HTML output fixed as a start. |
| 12:47 |
dbs |
Having fixed the email output for action-trigger notifications way back when, the path is reasonably clear, but the cost/benefit ratio is suspect |
| 12:48 |
gmcharlt |
do what you can, LP the rest and move on |
| 12:50 |
kmlussier |
ldw: Another thing to consider, next week could be problematic due to U.S. Thanksgiving. |
| 12:57 |
|
jihpringle_ joined #evergreen |
| 12:57 |
|
Shae_ joined #evergreen |
| 13:11 |
pinesol_green |
[evergreen|blake] LP1402018_Acq_Copy_location_UI_scoped_to_registered_workstation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4b094b1> |
| 13:20 |
ldw |
kmlussier: ahhh. I think now that I have gone and spammed the list about a date change, I might as well stick with it. Hopefully, we can find one day next week that works for everyone in the US. |
| 13:24 |
ldw |
Unless everyone here wants to write tests today (just reading the emails now). I am fine with doing it today too. |
| 13:34 |
kmlussier |
I'm fine going along with the crowd. Based on the silence, I'm guessing there aren't many people around to do it today. |
| 13:34 |
ldw |
kmlussier: seems to be the case. Do people take extended holidays for Thanksgiving? Should I move it to the next week? |
| 13:38 |
kmlussier |
I think it's common for people to take both Thursday and Friday off - don't want to miss all those Black Friday sales. Monday and Tuesday might be better. |
| 17:28 |
kmlussier |
Excellent! I may load up a VM with it now. |
| 17:28 |
kmlussier |
miker++ |
| 17:28 |
* csharp |
finds http://search.cpan.org/~drolsky/DateTime-1.21/lib/DateTime.pm#0-based_Versus_1-based_Numbers based on miker's last comment |
| 17:28 |
kmlussier |
hmmm...I wonder if I can find a good example in Concerto to test the branch against. |
| 17:29 |
miker |
kmlussier: it's a one-liner ... maybe noble's test system can absorb it? |
| 17:31 |
miker |
csharp: right... my thinking was, "if we use the /explicit/ *_0 method names in the perl, there will never be a question" ... whether that thinking was sound is left as an exercise for the reader to determine ;) |
| 17:31 |
kmlussier |
miker: Maybe. I'll run it by them in the morning since it looks like mmorgan just left. |
| 17:31 |
csharp |
miker: makes sense ;-) |
| 17:32 |
miker |
of course, the module's contention that "There is a year 0." is ... problematic :) |
