| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
agoben joined #evergreen |
| 07:26 |
|
rjackson_isl joined #evergreen |
| 08:02 |
|
rlefaive joined #evergreen |
| 08:56 |
|
terran joined #evergreen |
| 09:19 |
|
yboston joined #evergreen |
| 09:22 |
|
kmlussier joined #evergreen |
| 09:24 |
Dyrcona |
So, the update of the visibility vector at the end of the 3.0.3 upgrade script blew up on my test database. |
| 09:24 |
Dyrcona |
Looks junk record(s). |
| 09:24 |
Dyrcona |
Looks like, that is... |
| 09:25 |
Dyrcona |
Fun part will be finding them. |
| 14:36 |
Dyrcona |
Or, did we cover that yesterday? |
| 14:36 |
terran |
We're not seeing any errors that seem like they might be problems with syndetics |
| 14:43 |
terran |
Novelist is giving a Type error in the opac, but it still loads. Haven't seen any novelist errors in the client, it's just not appearing. |
| 14:59 |
Dyrcona |
I was looking at something unrelated this morning in a 3.0.3 XUL client talking to a test VM. |
| 14:59 |
Dyrcona |
Novelist was working for me there, but I didn't pay any attention to it. |
| 15:00 |
terran |
Hmm - looks like js.tt2 is trying to call /js/dojo/dojo/openils_dojo.js that isn't there |
| 15:00 |
|
jihpringle joined #evergreen |
| 15:18 |
|
khuckins__ joined #evergreen |
| 15:28 |
dbs |
csharp: hmm, maybe we'll stay on 2.12 for a while, sounds like a single OpenSRF server instance might not be all that sustainable |
| 15:35 |
|
rlefaive joined #evergreen |
| 15:51 |
terran |
When you find out a staff person has been using the test server instead of production server for the past week... |
| 15:52 |
mmorgan |
Oops. |
| 15:54 |
JBoyer |
Thoroughly tested, though. |
| 15:54 |
terran |
Heh |
| 15:54 |
terran |
There is now a big red message on the splash page of the test server. |
| 15:54 |
rjackson_isl |
sounds like something I would do - but not for that extended a period! |
| 15:55 |
terran |
Waiting for the tickets to start coming in needing help finding out how many bills were paid, items were circulated, and accounts were created on that workstation. |
| 15:55 |
terran |
Ooh, I just remembered I have tomorrow off! YES! |
| 16:14 |
* kmlussier |
hits sends on her email to terran before she leaves for the weekend. :) |
| 16:16 |
terran |
kmlussier: got it! |
| 16:29 |
dbs |
jeffdavis: we don't have too many people using the web staff client on 2.12 (mostly me); but maybe that explains some of the mysterious spikes we saw after our upgrade |
| 16:31 |
Dyrcona |
jeffdavis: Our experience has been the same as that of dbs on 2.12. We have a few people testing the web staff client, but it hasn't shown itself to be a real problem, yet. |
| 16:32 |
Dyrcona |
Actually, it seems a bit troubling that we may need to increase drone counts after the 3.0 upgrade. |
| 16:36 |
jeffdavis |
We have 3 or 4 libraries using the 2.12 web client and haven't noticed any problems in general so far (today's pcrud drone thing is unusual, and I think also partly XUL client related). |
| 16:37 |
jeffdavis |
Maybe our app servers are over-resourced :) |
| 17:51 |
csharp |
(some discussion of resources earlier that day too) |
| 17:52 |
csharp |
obviously cross-brick router stuff requires more than one server tho :-/ |
| 18:11 |
jeffdavis |
berick++ |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 03:36 |
|
Bmagic joined #evergreen |
| 03:46 |
|
Jillianne joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:34 |
|
agoben joined #evergreen |
| 07:40 |
|
rlefaive joined #evergreen |
| 07:41 |
|
rjackson_home joined #evergreen |
| 10:06 |
|
rlefaive joined #evergreen |
| 10:07 |
kmlussier |
yboston: The XUL client won't go away until 3.2. But no more bug fixes will be added to it. |
| 10:07 |
berick |
csharp: ok, good, I can work with that... i'll probably move that to a batched post-upgrade update. |
| 10:07 |
csharp |
berick: yep |
| 10:08 |
csharp |
it wasn't quite that slow in testing - I would definitely batch it if I'd known it would take so long |
| 10:12 |
|
rjackson_isl joined #evergreen |
| 10:18 |
|
mmorgan1 joined #evergreen |
| 10:23 |
|
jvwoolf joined #evergreen |
| 13:58 |
kmlussier |
JBoyer: LOL. Sounds like something I would do. |
| 13:58 |
Dyrcona |
JBoyer: :) |
| 13:59 |
JBoyer |
One of the hazards of having files with name like record.mrc and M20180124.mrc in the same directory... |
| 13:59 |
* Dyrcona |
just realized he needed to have services running on the vm where he's testing a backstage update. |
| 13:59 |
Dyrcona |
Lots of opensrf.settings IS NOT CONNECTED TO THE NETWORK!!! |
| 14:13 |
phasefx |
just noticed that our BuildBot isn't really doing anything anymore |
| 14:14 |
* phasefx |
nominates himself to be QA wrangler |
| 14:32 |
JBoyer |
Because I thought all cover art requests went through the local Eg server so they could be cached, regardless of source? |
| 14:34 |
|
gsams joined #evergreen |
| 14:34 |
terran |
The covers are loading, it's the stuff under the Added content tab. It loads the Reviews / TOC / Author Notes links, but when we click on them it does nothing |
| 14:35 |
JBoyer |
Oh! clicking on them. I did not actually test that this morning; I thought you meant it didn't load at all. Let me look again. |
| 14:36 |
kmlussier |
phasefx: IMO, if you volunteer for the role, you can name it whatever you want. |
| 14:36 |
kmlussier |
phasefx++ |
| 14:36 |
JBoyer |
I did throw a target="new" or whatever the syntax is on all 856 links for that same reason... |
| 14:58 |
terran |
It makes sense to me that it stops you from clicking on an http link, but shouldn't it be loading the link? In the other places we had http links, it loaded them and just wouldn't let you click |
| 14:58 |
terran |
(rather, would throw an error if you did click) |
| 15:04 |
terran |
I've put in a request to EBSCO to disable the additional e-resources section of our novelist content to see if that will allow it to load in our web client. |
| 15:06 |
kmlussier |
terran: Out of curiosity, when you've tested the behavior in the public catalog, are you logged in as a patron or are you using the catalog without a login? |
| 15:08 |
terran |
kmlussier: Both |
| 15:17 |
terran |
Spotting a syndetics error in the browser console that I didn't notice before: Uncaught TypeError: Cannot set property 'innerHTML' of null |
| 15:26 |
* berick |
grabs the LP-timeout spirit stick |
| 15:31 |
JBoyer |
LP timeouts exist in all of us, we only need want to avoid them enough. |
| 15:32 |
Dyrcona |
Quantum effects.... ;) |
| 15:33 |
Dyrcona |
...caused by my running make updates-clients. |
| 15:38 |
* mmorgan |
jumps on the missing Novelist Select content bandwagon. Seeing the problem in the xul client only, on both our 2.12 production and 3.0.3 test systems. |
| 15:40 |
kmlussier |
mmorgan: I think the xul client problem is different from what terran is seeing. krvmga and Dyrcona identified the source of that problem earlier this morning. |
| 15:41 |
kmlussier |
It sounded like it's not fixable in our current version of xul. |
| 15:43 |
* mmorgan |
scrolls back |
| 16:29 |
pinesol_green |
Launchpad bug 1745233 in Evergreen "Records with located URIs are retrieved in Copy Location Group searches" [High,New] https://launchpad.net/bugs/1745233 |
| 16:32 |
* mmorgan |
looks |
| 16:45 |
* mmorgan |
needs the patch for bug 1744489 |
| 16:45 |
pinesol_green |
Launchpad bug 1744489 in Evergreen "Limit Search by Location Causes Syntax Error" [High,Fix committed] https://launchpad.net/bugs/1744489 |
| 17:03 |
|
derekz left #evergreen |
| 17:05 |
|
jvwoolf1 joined #evergreen |
| 17:11 |
|
mmorgan left #evergreen |
| 17:13 |
|
jvwoolf1 left #evergreen |
| 17:17 |
|
sandbergja joined #evergreen |
| 17:42 |
|
khuckins_ joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:40 |
|
Jillianne joined #evergreen |
| 19:49 |
|
sandbergja joined #evergreen |
| 19:51 |
|
Christineb joined #evergreen |
| 06:19 |
csharp |
jeff: yeah, I upgraded it - we'll have to hack a nagios deb that's compiled to accept remote command line args - will do that asap |
| 06:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 07:07 |
|
rlefaive joined #evergreen |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:32 |
|
agoben joined #evergreen |
| 10:50 |
csharp |
bshum: thanks |
| 11:05 |
|
rlefaive joined #evergreen |
| 11:18 |
|
rlefaive joined #evergreen |
| 11:40 |
phasefx |
bshum: 106fbf0ea5da5f50ad4746557a68331a4ce13424 Last pass: http://testing.evergreen-ils.org/~live/archive/2018-01/2018-01-10_16:00:02/ first fail: http://testing.evergreen-ils.org/~live/archive/2018-01/2018-01-11_04:00:02/ |
| 11:40 |
pinesol_green |
phasefx: [evergreen|Mike Rylander] LP#1730758: Track record visibility on all Located URI DML - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=106fbf0> |
| 11:41 |
berick |
as if millions of tuits suddenly rolled away in terror |
| 11:42 |
|
rlefaive joined #evergreen |
| 11:59 |
phasefx |
bshum: ^ |
| 12:01 |
phasefx |
so we can still use the populate_copy tool to seed data, but then something else to preserve it for re-use |
| 12:02 |
phasefx |
meaning populate_copy becomes a manual utility, but asking for the concerto data to be loaded does things with less code generation |
| 12:05 |
berick |
along those lines (I think), I was thinking again recently about using concerto for demo data only, and building a separate tiny data set thats loaded, dropped, and reloaded with each live test. |
| 12:05 |
berick |
the tiny set being the snapshot |
| 12:10 |
phasefx |
berick: yeah, I've done a few tests like that, but I'm thinking about the existing tests.. don't really want to redo those |
| 12:10 |
phasefx |
I still think concerto is useful for testing as reference data, outside of automated testing |
| 12:12 |
berick |
yeah, i'm thinking concerto == any human testing, demo, etc. |
| 12:12 |
phasefx |
and for search tests, it may be harder to constrain results if the "outside" concerto environment still changes |
| 12:12 |
|
Christineb joined #evergreen |
| 12:12 |
phasefx |
unless we mean, not use it at all for testing |
| 12:13 |
phasefx |
automated testing |
| 12:13 |
phasefx |
that's probably what you meant? |
| 12:13 |
berick |
right, all auto tests use the tiny snapshot, humans use concerto |
| 12:13 |
phasefx |
that sounds good; one downside I see is tests that need a lot of data |
| 12:14 |
phasefx |
searching, again |
| 12:14 |
berick |
are there any such tests? |
| 12:14 |
phasefx |
dunno |
| 12:14 |
berick |
seems like they are all pretty targeted to specific data |
| 12:14 |
* phasefx |
is spitballing |
| 12:14 |
berick |
and certainly concertos 250 records or so will never be used for load testing |
| 12:14 |
berick |
of course |
| 12:15 |
phasefx |
true |
| 12:18 |
phasefx |
so maybe this new data set could take a snapshot of concerto as it now so we can keep the old tests? And the two can evolve separately at that point |
| 12:19 |
phasefx |
or we need something even smaller for quick build and tear down? |
| 12:19 |
kmlussier |
I like the idea of hard-coding the concerto data as it is now. |
| 12:21 |
|
khuckins_ joined #evergreen |
| 12:25 |
phasefx |
we don't have a date for the next dev meeting, do we? |
| 17:59 |
Bmagic |
Would you consider it a bug when running a report and the template requires that you select a shelving location from a list of shelving locations. The list is showing deleted shelving locations. |
| 18:03 |
berick |
i'd consider it a bug |
| 18:11 |
|
sandbergja joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:11 |
|
sandbergja joined #evergreen |
| 19:30 |
|
_sandbergja joined #evergreen |
| 20:10 |
csharp |
berick++ # bug 1743608 |
| 06:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 07:06 |
|
JBoyer joined #evergreen |
| 07:31 |
|
agoben joined #evergreen |
| 13:40 |
csharp |
that's still on our to-implement list |
| 13:41 |
JBoyer |
B&T has a weird flag where their code is combined with yours in some field, I haven't changed the defaults but having never sent a successful message before today I don't have a lot to compare to. |
| 13:42 |
JBoyer |
(And I try not to go straight to berick all of the time because I don't know who's actually ordering from who, thought I guess B&T probably does have a pretty high % of the available market) |
| 13:43 |
* JBoyer |
is also in the middle of testing 1-2 patches and should try to finish something before starting more things... |
| 13:44 |
|
bos20k joined #evergreen |
| 13:51 |
csharp |
JBoyer++ # I'm right there with you on the multitasking thing |
| 13:52 |
|
mmorgan1 joined #evergreen |
| 14:23 |
berick |
BT traditionally wants org_san + vendcode |
| 14:24 |
berick |
applying the patch above fixed Bmagic's BT problems, fwiw |
| 14:26 |
JBoyer |
Ok. I wasn't certain since they tell libraries to set vendacct to their SAN also. so long as your org_unit_san matches their vendacct it doesn't make much difference. |
| 14:26 |
JBoyer |
I'll throw on a signoff after a quick test. |
| 14:28 |
berick |
oh and in some cases, the org-san is include as a separate part of the NAD+BY field |
| 14:31 |
Bmagic |
I've been meaning to investigate but we are having Ingram invoice issues. Can that be related to the new non-Ruby stuff? |
| 14:32 |
berick |
Bmagic: hard to say, but the new stuff is only resopnsible for sending orders |
| 16:31 |
Dyrcona |
I have two copies of it, more or less identical, it turns out. |
| 17:01 |
|
mmorgan left #evergreen |
| 17:06 |
|
jvwoolf left #evergreen |
| 18:06 |
phasefx |
so the perl live test failure, I know which commit instigates the change in behavior (which is a different distribution of generated concerto item barcodes), but I see no reason why it would. For expediency, I could update to test to expect the "new normal", but I really want to understand under what conditions assets_extras.sql will produce different output |
| 18:09 |
phasefx |
it looks like it's not really _extras.sql fault; eyes on assets_concerto.sql.. there are some barcodes that exist in one branch or the other (patch and no-patch) |
| 18:27 |
|
troy__ joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 19:43 |
bshum |
phasefx: That's one of the problems with the concerto dataset we were trying to isolate and explain better during the Hackaway |
| 19:44 |
bshum |
phasefx: We definitely notice it happening whenever bib records get added or removed in the test dataset |
| 19:44 |
bshum |
There's some other cases too |
| 19:45 |
bshum |
Changing the resulting test is certainly the easiest way out of those, but what we really need to do is potentially come up with ways of keeping the generated values more consistent. Or perhaps pinning specific copies to certain bibs, etc. to perform tests with. |
| 19:45 |
bshum |
There was some brief discussion about it, but we hadn't decided on the best way forward at the meeting. |
| 19:45 |
bshum |
I'm sure we're all open to ideas :D |
| 19:46 |
bshum |
What was the commit that threw things off? |
| 21:00 |
|
serflog joined #evergreen |
| 21:00 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 21:01 |
csharp |
ok - back |
| 02:40 |
|
StomproJosh joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:14 |
JBoyer |
jeff, I think you're remembering a discussion because I also remember one but I don't remember any bugs about actually doing it. |
| 07:15 |
JBoyer |
I found myself saying "Why am I saying this?" as I explained to our most recent library that you can have any username you like, but you have to always remember to enter it the same way every time. |
| 07:43 |
|
kmlussier joined #evergreen |
| 08:13 |
|
agoben joined #evergreen |
| 08:30 |
|
ngf42 joined #evergreen |
| 08:33 |
jeff |
JBoyer: heh, it failed the absurdity test. :-) |
| 08:34 |
JBoyer |
Very much. |
| 08:42 |
|
tlittle joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 09:17 |
Dyrcona |
And, answered my own question by checking my local logs, and seeing that csharp did say "72" as I thought I remembered. :) |
| 09:18 |
Dyrcona |
IIRC, we have cstore set to 70, so I think I'll go with something in that area. |
| 09:18 |
|
yboston joined #evergreen |
| 09:19 |
Dyrcona |
Might be neat to configure all of my bricks to share routers. Really spread the load, but maybe I'll test that with a couple of vms, first. |
| 10:14 |
|
jvwoolf joined #evergreen |
| 10:16 |
|
mmorgan joined #evergreen |
| 10:26 |
kipd |
Is there a relatively simple way to test out small changes to various perlmods without having to do a complete make; make install cycle for all of Evergreen? For example, I want some additional information printed out with the email in ~/Evergreen-ILS-3.0.2/Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/HoldNotify.pm Can I do this just from the Makefile in src/perlmods? |
| 10:37 |
berick |
kipd: copy the Perl file into place and restart all (or affected) services |
| 10:37 |
berick |
no need to 'make', etc. |
| 10:38 |
berick |
on my ubuntu test vm for example they end up in /usr/local/share/perl/5.22.1/ |
| 10:39 |
kipd |
doh, I was looking in the wrong place. Thank you! |
| 10:44 |
Dyrcona |
kipd: If the file ends in .in, you will need to make it, first. There are very few modules like that, but many of the scripts do. |
| 10:45 |
* Dyrcona |
modifies marc_export quite a bit. :) |
| 11:06 |
Dyrcona |
So, you imagine retargeting frozen holds once per day or something like that? |
| 11:09 |
berick |
Dyrcona: we retarget once a day (at night) so I was thinking weekly for frozen. |
| 11:10 |
Dyrcona |
berick: OK. We retarget twice an hour. I thought it was something along those lines. |
| 11:10 |
Dyrcona |
berick++ # I'll be happy to test the changes. |
| 11:11 |
berick |
Dyrcona: cool. i'll have a patch shortly |
| 11:13 |
|
collum joined #evergreen |
| 11:23 |
csharp |
Dyrcona: I set fielder to 72 max_children, but didn't see any further spikes after that |
| 11:27 |
csharp |
*my* max_children is set to 2, but our prod servers are set to 128 at the moment (which I think could probably dial down to 72) |
| 11:28 |
Dyrcona |
Thanks. :) |
| 11:28 |
* csharp |
has a friend about the same age (early/mid 40s) with 7 children - wondering if that was a config file error |
| 11:28 |
Dyrcona |
I'm updating our test server to 3.0.3 and getting a branch ready for 3.0. |
| 11:28 |
Dyrcona |
heh. |
| 11:29 |
Dyrcona |
There's a family at my daughter's school with 9 kids. |
| 11:31 |
csharp |
ok - we just hit bug 1736243 - and from what I can tell, it's another datatype issue (string vs. number) |
| 16:17 |
|
khuckins joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:38 |
|
jvwoolf left #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 20:03 |
|
dbwells_ joined #evergreen |
| 21:04 |
|
StomproJ joined #evergreen |
| 03:06 |
|
yar joined #evergreen |
| 03:57 |
|
Jillianne joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
JBoyer joined #evergreen |
| 07:38 |
|
agoben joined #evergreen |
| 07:39 |
|
tlittle joined #evergreen |
| 09:14 |
|
jvwoolf joined #evergreen |
| 10:02 |
kmlussier |
Would anyone be willing to look at bug 1736267 on something other than ubuntu trusty before I merge it? I would like to include it in today's maintenance release since we're unable to build the web client in 2.12 without it. |
| 10:02 |
pinesol_green |
Launchpad bug 1736267 in Evergreen "Release 2.12 should install nodejs from source" [High,New] https://launchpad.net/bugs/1736267 |
| 10:02 |
* kmlussier |
is double checking it on ubuntu trusty since it's been a while since she first tested it. |
| 10:04 |
|
mmorgan1 joined #evergreen |
| 10:12 |
|
jvwoolf joined #evergreen |
| 10:18 |
|
jvwoolf1 joined #evergreen |
| 10:39 |
|
JBoyer joined #evergreen |
| 10:47 |
|
Dyrcona joined #evergreen |
| 10:53 |
kmlussier |
cesardv++ #Following up on bug 1738249. |
| 10:53 |
pinesol_green |
Launchpad bug 1738249 in Evergreen "Circulation Library in Item Status" [Low,Confirmed] https://launchpad.net/bugs/1738249 |
| 10:54 |
kmlussier |
I'm sorry to say I had those changes sitting in a branch for a couple of weeks. I forgot about it until I saw the duplicate bug filed yesterday. |
| 11:00 |
miker |
@weather 30101 |
| 11:06 |
pinesol_green |
Launchpad bug 1743650 in Evergreen "Records with Located URIs retrieved out of scope when org units are not OPAC visible" [High,Confirmed] https://launchpad.net/bugs/1743650 |
| 11:13 |
kmlussier |
OK, I'll look at it now. |
| 11:13 |
kmlussier |
gmcharlt / dbwells: Do we still have time to push fixes to 3.0 for today's release? |
| 11:46 |
csharp |
so kmlussier, bug 1736267 should be cherry-picked onto rel_2_12 for testing right? |
| 11:47 |
pinesol_green |
Launchpad bug 1736267 in Evergreen "Release 2.12 should install nodejs from source" [High,Fix committed] https://launchpad.net/bugs/1736267 |
| 11:47 |
* csharp |
has a xenial test vm raring to go |
| 11:48 |
kmlussier |
csharp: Yes, that would be great! I ended up merging it, but if it blows something up, it would be good to know before today's release. |
| 11:48 |
* kmlussier |
could probably practice some patience. |
| 12:08 |
|
gmcharlt joined #evergreen |
| 13:09 |
gmcharlt |
kmlussier: yeah, they're important enough |
| 13:09 |
kmlussier |
gmcharlt: Thanks! I'll merge right away. |
| 13:13 |
kmlussier |
Calling 1086 |
| 13:19 |
pinesol_green |
[evergreen|Mike Rylander] LP#1743639: opac_visible on acplg is not what it seems - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=02cfe27> |
| 13:19 |
pinesol_green |
[evergreen|Mike Rylander] LP#1743639: Test location as proxy for location group - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4827005> |
| 13:19 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1743639: Stamping upgrade script for copy location group visibility - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d0dacd7> |
| 13:22 |
kmlussier |
And now calling 1087 |
| 13:29 |
pinesol_green |
[evergreen|Mike Rylander] LP#1743650: Bib vis testing needs different handling - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d32b247> |
| 13:29 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1743650: Stamping upgrade script for special bib visibility handling - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b30ae37> |
| 13:32 |
kmlussier |
Done testing and merging now for today's release. |
| 13:58 |
sandbergja2 |
Just to confirm: the only changes to the 2.12 point release are the three nodejs ones from bshum? And I'm good to start working on the release notes? |
| 14:06 |
kmlussier |
sandbergja2: Yes, that's correct. As far as I can tell, most of the fixes that have gone in were either web client fixes that didn't backport cleanly or were fixes related to new 3.0 features. |
| 14:15 |
|
annagoben joined #evergreen |
| 17:04 |
|
mmorgan left #evergreen |
| 17:12 |
Dyrcona |
sandbergja++ kmlussier++ |
| 17:15 |
|
yar joined #evergreen |
| 18:04 |
pinesol_green |
[evergreen|Dan Wells] Forward port 3.0.3 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a060e06> |
| 18:04 |
pinesol_green |
[evergreen|Dan Wells] Forward port 2.12.9 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4808f1a> |
| 18:11 |
|
rlefaive joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 03:19 |
|
yar joined #evergreen |
| 06:10 |
|
jeff joined #evergreen |
| 06:17 |
|
Guest94274 joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:05 |
|
rjackson_isl joined #evergreen |
| 07:06 |
|
rjackson_isl_ joined #evergreen |
| 08:05 |
|
rlefaive_ joined #evergreen |
| 10:03 |
|
rlefaive joined #evergreen |
| 10:04 |
Dyrcona |
Anyone else seeing not connected to the network errors that appear to be related to search.facets_for_record_set |
| 10:05 |
terran |
We're still getting reports of Hatch not working on 32-bit versions of Windows 7. Anyone else? |
| 10:07 |
csharp |
kmlussier: so far so good - the next couple of ours will be our true test |
| 10:07 |
csharp |
s/ours/hours/g |
| 10:08 |
csharp |
Dyrcona: we're not at this point |
| 10:09 |
Dyrcona |
csharp: OK. We get them infrequently, now. |
| 10:09 |
csharp |
we're seeing something that attempts to insert a new actor.card object with a null barcode |
| 10:09 |
Dyrcona |
And, it always seems to be related to a JSON query with that function. |
| 10:27 |
csharp |
in our case it runs for about 4 minutes and so far not causing pile-ups |
| 10:28 |
Bmagic |
csharp: they require that the staff browse to that section of the patron account |
| 10:28 |
Dyrcona |
csharp: Haven't seen that. Just the payments one. |
| 10:28 |
Dyrcona |
We're not using 3.0 in production, but we do have it on a test server with production data. |
| 10:28 |
Bmagic |
csharp: and it doesn't happen for ALL patrons. Just some. Probably those with more than X number of historic bills..... |
| 10:31 |
csharp |
yeah makes sense |
| 10:32 |
jeff |
reminds me of our 0.00 bills issue. :-) |
| 13:03 |
miker |
re fielder |
| 13:03 |
miker |
it's not a new services, IOW |
| 13:11 |
Dyrcona |
miker: OK. Thanks. Thought I'd heard of it, but I've never used it in my own work. |
| 13:15 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 13:16 |
Dyrcona |
Grr....Lp search is bad. I swear there was a bug to remove the permacrud service. |
| 13:16 |
* csharp |
at least remembers a discussion about that |
| 13:17 |
Dyrcona |
I tried advanced search and even filing a new bug but nothing turned up. |
| 14:35 |
Dyrcona |
Yeah, that looks like about right. |
| 14:36 |
Bmagic |
csharp ^^ |
| 14:54 |
csharp |
Bmagic: Dyrcona: cool - thanks |
| 14:58 |
jeffdavis |
This is kinda baffling. I've got a test server with the fix for bug 1736419 where search results include all matching records with located URIs, even when none of the luri's are in scope. |
| 14:58 |
pinesol_green |
Launchpad bug 1736419 in Evergreen "Search Showing Bibs with no Holdings" [High,Fix committed] https://launchpad.net/bugs/1736419 |
| 14:59 |
kmlussier |
jeffdavis: I'm about to submit a bug on this. I don't know if it's the same issue, but we've found that records are being retrieved that are outside of scope when org units are set to not opac visible. |
| 15:00 |
kmlussier |
jeffdavis: I'm still trying to nail down some kind of pattern before submitting the bug. |
| 15:01 |
|
mmorgan1 joined #evergreen |
| 15:10 |
jeffdavis |
kmlussier: Do you mean out-of-scope records are retrieved when they have luri's belonging to opac-invisible org units? |
| 15:12 |
kmlussier |
jeffdavis: Well, that's what I'm trying to nail down. In Concerto, if I made an org unit invisible, I'll start seeing out-of-scope records with luris, but I don't think it's just happening with ones owned by the invisible org unit. |
| 15:13 |
jeffdavis |
Huh, weird. That would be consistent with my test environment which has a number of invisible orgs. |
| 15:15 |
jeffdavis |
I know the bib-level visibility check involves asset.patron_default_visibility_mask() which adds an explicit list of opac-invisible org units to exclude from luri_org vis tests |
| 15:15 |
jeffdavis |
maybe a parenthesis is getting misplaced or something |
| 15:18 |
|
JBoyer joined #evergreen |
| 15:19 |
JBoyer |
csharp, were you the one looking for how to trigger inserts of null user barcodes recently? I was just watching someone renew a card and change barcode and it did it to them. |
| 15:19 |
kmlussier |
OK, when I set BR1 as OPAC invisible, the record with a BR2 luri is being retrieved out of scope. When I set BR2 as OPAC invisible, the record with a BR1 luri is retrieved out of scope. |
| 15:20 |
JBoyer |
What's most annoying is that there was 100% a barcode in the box. We initially gave her 1 card, then changed card numbers again before saving (but didn't save in between). |
| 15:20 |
kmlussier |
When I set SYS1 as OPAC invisible, they both were retrieved out of scope, I think. |
| 15:21 |
JBoyer |
I haven't tried to reproduce it yet (I'm at a new library go live and haven't had time to test much) but wanted to throw this out there in case people want to try to break things. |
| 15:23 |
|
tlittle joined #evergreen |
| 15:26 |
JBoyer |
We got the generic error in database query message (DATABASE_QUERY_ERROR or similar) because PostgreSQL was unhappy, so that's what users will see. |
| 15:27 |
JBoyer |
*poof* |
| 18:00 |
ejk |
Good stuff. I think I should be able to get a good guess from this. Thanks! |
| 18:00 |
ejk |
dbs++ |
| 18:02 |
dbs |
glad to be able to help |
| 18:32 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 19:14 |
jeff |
sounds like that's enough for your needs, but there's also the technique of using pcrud: |
| 19:14 |
jeff |
using srfsh, you could issue: request open-ils.pcrud open-ils.pcrud.id_list.bre "ANONYMOUS", {"id": {"!=": null}}, {"order_by": {"bre":"id desc"}, "limit":1} |
| 19:15 |
jeff |
or the gateway, a slightly ugly url encoded: |
| 06:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:46 |
|
rlefaive joined #evergreen |
| 08:58 |
|
bos20k joined #evergreen |
| 09:07 |
|
Dyrcona joined #evergreen |
| 10:50 |
pinesol_green |
Launchpad bug 1738488 in Evergreen 3.0 "Web client: patron billing history results in long running query" [Medium,Confirmed] https://launchpad.net/bugs/1738488 |
| 10:51 |
Bmagic |
If you don't have something to kill those off, your database could easily get clobbered once hundreds of staff are using the Web client. |
| 10:51 |
Bmagic |
of course, that's not the real* fix |
| 10:52 |
Dyrcona |
I've had to kill a number of those by hand in testing and training. |
| 10:52 |
Dyrcona |
I've noticed that they don't run for days with join_collapse_limit at 9 in production on 2.12. |
| 10:52 |
Dyrcona |
It's on the bug, but just throwing that out there. |
| 10:53 |
Dyrcona |
jeff: So, library A loaded in about 10 seconds, also. I'm not seeing a slow down today. |
| 11:06 |
* pinesol_green |
grabs some Moon Pie and some RC Cola for jeff |
| 11:08 |
Dyrcona |
Hm... One of these canceled holds is from 2013! |
| 11:08 |
Dyrcona |
No, I take that back, a lot of them are and some from 2012.... |
| 11:09 |
Dyrcona |
Yeah, I noticed relatively high load on training and testing until those queries were killed, too. |
| 11:10 |
Dyrcona |
Setting join_coallapse_limit may help some. I did that for other reasons on production, but I think it is helping with the payment history queries. |
| 11:10 |
jeff |
Dyrcona: also, if you get to a point where you're suspecting the base query, -- yeah, I think you mostly already got where I was going. |
| 11:11 |
Dyrcona |
jeff: That query does some ridiculous joins, but I won't repeat too much of what was discussed in IRC recently and linked from the bug, IIRC. |
| 16:54 |
kmlussier |
OK, I'm out. Have a nice weekend everyone! |
| 17:18 |
|
bshum joined #evergreen |
| 17:26 |
|
jvwoolf left #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 18:59 |
|
alynn26_ joined #evergreen |
| 19:05 |
|
alynn26_ joined #evergreen |
| 00:18 |
|
Jillianne joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:29 |
|
rjackson_isl joined #evergreen |
| 07:32 |
|
sandbergja joined #evergreen |
| 07:32 |
|
agoben joined #evergreen |
| 10:12 |
|
rlefaive joined #evergreen |
| 10:23 |
Dyrcona |
jeffdavis: I tried your odapi-checker.pl this morning. |
| 10:23 |
Dyrcona |
jeffdavis: I get this error: Error on API request: 405 Method Not Allowed |
| 10:23 |
Dyrcona |
That's on the test server. |
| 10:23 |
Dyrcona |
Any idea what's wrong? |
| 10:24 |
pinesol_green |
[evergreen|Jason Boyer] LP1741072: Fix JS test for template conversion - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ce01eeb> |
| 10:24 |
pinesol_green |
[evergreen|Bill Erickson] LP#1741072 Volcopy editor deposit amount format repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2f7449a> |
| 10:25 |
JBoyer |
Yay! I was wondering when those would go in. |
| 10:26 |
JBoyer |
gmcharlt++ |
| 10:26 |
Dyrcona |
jeffdavis: If I try with production values, I get 400 bad request. |
| 10:32 |
berick |
gmcharlt_: *nod* let me know if/how I can help. i'd like to dig into that soon |
| 10:33 |
|
gmcharlt joined #evergreen |
| 10:38 |
Dyrcona |
jeffdavis: Just the basic check of the account works on the standard endpoint. I get 200 OK. |
| 10:39 |
Dyrcona |
jeffdavis: Trying the same on the integration endpoint with our test account id gives 403 Forbidden, so likely something wrong on their end or I need a different token for testing that no one told me about? |
| 10:40 |
pinesol_green |
[evergreen|Jason Boyer] LP1737052: Fix Typo in Permission Name - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f3bff3e> |
| 10:44 |
pinesol_green |
[evergreen|Jane Sandberg] LP1719943: fixing typo in credential testing interface - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ce4b51e> |
| 11:11 |
Bmagic |
Before I submit this on LP, has it already been reported that the acqusitions interface is bugged when adding a note/alert on an item. The dropdown UI shows up and immediately disappears? |
| 11:14 |
csharp |
berick: thanks - that jibes with everything we're saying |
| 11:14 |
csharp |
hooray! |
| 11:36 |
Dyrcona |
rsyslog is next to useless. |
| 11:46 |
|
rlefaive joined #evergreen |
| 11:49 |
|
kmlussier joined #evergreen |
| 11:52 |
kmlussier |
Has anyone noticed a problem in the web client where titles in the holds pull list disappear when you sort the list? |
| 11:53 |
kmlussier |
I hadn't noticed it on my test VMs, but I saw it today when looking at a system with production data on it. https://drive.google.com/file/d/1F8wTMwk9tcHKMvOUPj4UkFLs-67uFeiV/view |
| 11:53 |
jeff |
Dyrcona: rsyslog problems? |
| 11:53 |
kmlussier |
Oh, I guess that video isn't ready for prime time yet. |
| 11:53 |
Dyrcona |
jeff: Things are not making it to the server, and it's seemingly random. |
| 12:07 |
|
khuckins joined #evergreen |
| 12:08 |
|
dwgreen joined #evergreen |
| 12:09 |
|
khuckins_ joined #evergreen |
| 12:11 |
phasefx |
btw, it was a perl live test that failed this morning, not the browser build |
| 12:12 |
phasefx |
Failed test 'Hold 263 has 31 mapped potential copies' at live_t/20-hold-targeter.t line 100. got: '24' expected: '31' |
| 12:20 |
|
terran joined #evergreen |
| 12:34 |
|
rlefaive joined #evergreen |
| 12:49 |
jeffdavis |
Dyrcona: Overdrive client auth uses the same endpoint for both integration and production. IIRC you use the same token for both. |
| 12:55 |
jeffdavis |
What were you doing that gave the 400 Bad request error? |
| 12:57 |
Dyrcona |
Patron auth with our production account on the man server. |
| 12:57 |
Dyrcona |
s/man/main/ |
| 12:59 |
Dyrcona |
The testing account worked for a basic connection without specifying the testing endpoint. |
| 13:02 |
Dyrcona |
I get a 400 bad request trying patronauth with the testing credentials, too. I guess they didn't actually enable that for us. |
| 13:09 |
jeffdavis |
I'm getting 200 OK for patron auth with production data. I don't have testing access set up at the moment so can't test that. |
| 13:10 |
kipd |
Tuning question about the output from osrf_control --diagnostic: I assume this isn't good, but is changing max_children for some of these processes the way to go? |
| 13:10 |
Dyrcona |
Well, I'm supposed to have it for testing but not production, at least that's what I understood from the emails. |
| 13:10 |
kipd |
https://www.irccloud.com/pastebin/Xo4UJYH6/ |
| 13:11 |
Dyrcona |
kipd: Yes, if you need more. It depends, really. |
| 13:11 |
kipd |
Everything beyond max_children is waiting in queue right? |
| 13:22 |
Dyrcona |
yes, the first number includes the spares. |
| 13:22 |
jeff |
but in theory you should never see more than 100% for #drones and I'm not sure what conditions would lead to that display (orphaned drones, something else...) |
| 13:25 |
Dyrcona |
Yeah, I've never seen that output. |
| 13:37 |
Dyrcona |
jeffdavis: Should I be making the test patron-auth requests against the standard endpoint or should I specify a test endpoint? |
| 13:39 |
jeffdavis |
The standard one |
| 13:39 |
jeffdavis |
"All patron authentication POSTs use the same URL (https://oauth-patron.overdrive.com/patrontoken) in both the production and integration environments" (http://developer.overdrive.com/apis/patron-auth) |
| 13:40 |
Dyrcona |
Ah,ok. |
| 13:40 |
Dyrcona |
I hadn't gotten that far into the docs. |
| 13:41 |
Dyrcona |
I still get 400 bad request with testing parameters. |
| 13:48 |
jeffdavis |
The --verbose option should give you the full response, which might help narrow down the cause. If nothing else you can pass the info along to their support people. |
| 13:54 |
Dyrcona |
OK. I'll try that. |
| 13:54 |
Dyrcona |
I'm starting to think that they just failed to enable patron auth. |
| 14:05 |
Dyrcona |
Oh! I think I found something in an email from Overdrive that I overlooked. |
| 14:06 |
Dyrcona |
Details! But I think I have it fixed. |
| 14:06 |
Dyrcona |
I was using the wrong authorization name. |
| 14:09 |
Dyrcona |
So, they sent me two library names in the email, the one that I'm supposed to use for the authorization name and the one that we choose on the test site. I missed the first more or less, 'cause it was on the same line with the other. |
| 14:14 |
Dyrcona |
jeffdavis++ # Thanks for the help. I think I have it working, more or less. |
| 14:15 |
jeffdavis |
yay! |
| 14:17 |
pinesol_green |
[evergreen|Dan Wells] LP#1730470 Restore XUL serial receive compatibility - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d90f69f> |
| 14:56 |
Dyrcona |
The Download button doesn't work and there's nothing in the drop down next to ti. |
| 14:59 |
|
sandbergja joined #evergreen |
| 15:17 |
|
mmorgan1 joined #evergreen |
| 15:32 |
Dyrcona |
I think the null of null happens because the records don't exist on the api testing server. |
| 15:33 |
Dyrcona |
I found one that looks like it would be there that is in our catalog, but the ISBN numbers don't match. |
| 15:33 |
Dyrcona |
We also have a record for an e-book and e-audio from Overdrive, but the integration site only has an e-book with a different ISBN from our e-book. |
| 15:37 |
kmlussier |
Dyrcona: bug 1677813 |
| 17:17 |
|
jvwoolf joined #evergreen |
| 17:32 |
|
jvwoolf joined #evergreen |
| 17:51 |
|
book` joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 18:50 |
|
Jillianne joined #evergreen |
| 23:24 |
|
jonadab joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:19 |
|
rjackson_isl joined #evergreen |
| 07:35 |
|
rlefaive joined #evergreen |
| 07:35 |
|
agoben joined #evergreen |
| 10:44 |
miker |
for each selected copy, get the circ and owning lib, and make a list of all. then add the ws_ou, just to be safe, then unique-ify that list. then, get the full-path orgs for that list, as a second array, and uniquify that. then, get all shelving locations that belong to any in that final list. |
| 10:45 |
miker |
obviously, something's funky with that... I have a suspicion, and will look soon |
| 10:45 |
csharp |
miker++ # awesome |
| 10:59 |
* Dyrcona |
is having zero luck with the Overdrive API integration and Overdrive's test environment. |
| 11:00 |
Dyrcona |
I hesitate to rest my client secret because they say I have only 2 resets left, and I also have no idea what's wrong or how this should actually work. |
| 11:05 |
Dyrcona |
I want to go eat lunch already, but I guess I'll wait. |
| 11:06 |
|
JBoyer joined #evergreen |
| 16:39 |
jeff |
drat, missed him. |
| 16:55 |
|
khuckins__ joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 18:54 |
|
khuckins_ joined #evergreen |
| 19:53 |
|
khuckins__ joined #evergreen |
| 11:45 |
JBoyer |
Yeah, that way you can see if the hold is even possible. Just finding a matching row doesn't mean you've targeted a copy. |
| 11:45 |
JBoyer |
(or that you've found a copy to target, rather.) |
| 11:51 |
|
khuckins joined #evergreen |
| 11:59 |
berick |
Bmagic: JBoyer: the copy age protect test happens in the in-db function too |
| 12:00 |
Bmagic |
berick: which function should I be testing with? |
| 12:00 |
berick |
action.hold_request_permit_test and action.hold_retarget_permit_test |
| 12:01 |
Bmagic |
the one that should be denying this copy with age protection to this patron |
| 12:01 |
terran |
Bmagic: Thanks for confirming the bill printing problem, bug reported at: https://bugs.launchpad.net/evergreen/+bug/1742194 |
| 12:04 |
terran |
Bmagic: re notification preferences: weird, I will keep my eyes open for that problem. |
| 12:05 |
miker |
kmlussier: was in a meeting ... I can look at the comment #10 thing quickly and see if it's trival |
| 12:05 |
Bmagic |
terran: along those same lines, we find that the transit slips print the wrong stuff until you print it a second time |
| 12:06 |
terran |
Bmagic: I saw your report on that, but we haven't seen that happen in testing yet either. It may be that we see both of these after we are in production next week. |
| 12:06 |
Bmagic |
terran: it's tough to find because it doesn't happen always |
| 12:06 |
krvmga |
we have an item in our catalog that includes both a CD and a DVD. is there any way for us to display both icons for this in the catalog? |
| 12:07 |
Bmagic |
I am finding a common theme, where refreshing the screen corrects the issue |
| 12:11 |
Bmagic |
terran: where the UI is ready to show but the data isn't. Like this one |
| 12:11 |
Bmagic |
https://bugs.launchpad.net/evergreen/+bug/1642036 |
| 12:11 |
pinesol_green |
Launchpad bug 1642036 in Evergreen "Web Staff Client - Group Members Don't Display" [Medium,Confirmed] |
| 12:14 |
terran |
Bmagic: FWIW, we have your patch on our test server and it's been working there, but we don't have it in production yet. |
| 12:15 |
Bmagic |
I think bug 1642036, bug 1740537, bug 1361258 might have some of the same underlying causes |
| 12:15 |
pinesol_green |
Launchpad bug 1642036 in Evergreen "Web Staff Client - Group Members Don't Display" [Medium,Confirmed] https://launchpad.net/bugs/1642036 |
| 12:15 |
pinesol_green |
Launchpad bug 1740537 in Evergreen "Web client: Transit slip printing with wrong information" [Undecided,New] https://launchpad.net/bugs/1740537 |
| 17:56 |
berick |
just guessing, but could be an issue with proximity adjusment configuration |
| 18:20 |
Bmagic |
That system does have an adjustment set... More on this when I get back to it Thursday. |
| 18:20 |
Bmagic |
berick++ |
| 18:30 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 18:40 |
|
rlefaive joined #evergreen |
| 18:43 |
miker |
autogen.sh -u should no longer be needed. a trigger should be handling that |
| 18:43 |
* miker |
disappears |
| 18:47 |
|
dbwells_ joined #evergreen |
| 19:00 |
pinesol_green |
[evergreen|Mike Rylander] LP#1736419: Located URIs vs QueryParser, round 2 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=13d0596> |
| 19:00 |
pinesol_green |
[evergreen|Mike Rylander] LP#1736419: Located URIs vs QueryParser, round 2, part deux - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d63b81f> |
| 19:00 |
pinesol_green |
[evergreen|Mike Rylander] LP#1736419: Bib visibility tests get OR'd - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=979d0c2> |
