| 00:45 |
|
dbwells joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:54 |
|
JBoyer joined #evergreen |
| 07:18 |
|
JBoyer joined #evergreen |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 12:21 |
|
khuckins joined #evergreen |
| 12:27 |
|
hbrennan joined #evergreen |
| 12:51 |
|
kmlussier joined #evergreen |
| 12:56 |
JBoyer |
remingtron, you're right. I think I addressed 1720002 because of issues spotted locally while testing the rest of the cat templates code. It should also be marked fix released. |
| 12:56 |
JBoyer |
Thanks for finding that! |
| 12:56 |
JBoyer |
remingtron++ |
| 13:06 |
kmlussier |
JBoyer / remingtron: Actually, I would mark it Invalid if it's no longer a bug. |
| 14:32 |
Dyrcona |
I've seen that query go between 4 to 10 minutes or so on our production hardware. |
| 14:33 |
Dyrcona |
Then calling that page up again usually populates right away after the query has run once....cache. |
| 14:33 |
Dyrcona |
But, yeah, that needs to be fixed. |
| 14:47 |
kmlussier |
Do expired holds automatically cancel? I've been told they do, but I don't see it happening in my own testing. |
| 14:50 |
berick |
kmlussier: yes the targeter cancels them |
| 14:50 |
berick |
supposed to, anyway |
| 14:51 |
kmlussier |
OK, I'll dig further. Thanks berick! |
| 15:01 |
Dyrcona |
Cancel reason #1. |
| 15:02 |
Dyrcona |
cancel_cause in the db terminology. |
| 15:02 |
* Dyrcona |
should stop trying to multitask. :) |
| 15:03 |
kmlussier |
OK, it was a problem with my test plan. Once I modified my prev_check_time, it canceled. |
| 15:03 |
kmlussier |
Dyrcona: In my case, there was no cancel time or cause. |
| 15:03 |
Dyrcona |
You're running the hold targeter regularly? |
| 15:04 |
kmlussier |
Dyrcona: Yes |
| 15:04 |
kmlussier |
Dyrcona: But, like I said, prev_check_time hadn't arrived yet. |
| 16:33 |
berick |
:) |
| 16:33 |
berick |
we're in this boat together, people! |
| 16:33 |
mmorgan |
berick++ |
| 16:34 |
terran |
berick++ yet again |
| 16:38 |
terran |
Pulling csharp away from other drama so we can test it :) |
| 16:40 |
* csharp |
vacuums terran's hair from office hallway |
| 16:40 |
berick |
would make for a great reality show |
| 16:41 |
berick |
*terran throws a glass of pinot at csharp* |
| 17:35 |
csharp |
berick++ |
| 17:35 |
csharp |
terran++ |
| 18:26 |
|
abowling1 joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:31 |
|
abowling joined #evergreen |
| 18:46 |
|
abowling1 joined #evergreen |
| 00:30 |
|
StomproJosh joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:39 |
|
rlefaive joined #evergreen |
| 07:57 |
remingtron |
wow, the most recent search results from native irc.evergreen-ils.org are from 2014! |
| 12:42 |
* phasefx |
nods |
| 12:42 |
* kmlussier |
is straying away from what she was supposed to be focusing on with spine labels, but she has a better understanding of how they work in the web client now. |
| 12:43 |
kmlussier |
phasefx++ |
| 13:01 |
jvwoolf |
Question for folks who have set up Stripe payments in the OPAC: Is it supposed to work normally when you use the test keys and a test credit card from Stripe? |
| 13:02 |
mmorgan |
jvwoolf: By normally, do you mean should it apply the payments in evergreen? |
| 13:02 |
jvwoolf |
Instead of the main_pay page loading with transaction info, we're seeing an internal server error. The payments are applied and Evergreen and seem to be successful in Stripe as well. |
| 13:03 |
jvwoolf |
*in Evergreen, not an |
| 13:03 |
jvwoolf |
d |
| 13:04 |
mmorgan |
In our testing experience, the catalog screens have worked the same in testing mode and live mode. |
| 13:05 |
mmorgan |
You shouldn't see an internal server error just because you're using stripe test mode. |
| 13:06 |
csharp |
jvwoolf: there should be something in the opensrf error log that points to what's wrong |
| 13:09 |
|
rlefaive joined #evergreen |
| 13:09 |
jvwoolf |
csharp: Thanks. We'll take a look. |
| 15:50 |
|
Christineb joined #evergreen |
| 17:03 |
|
mmorgan left #evergreen |
| 17:33 |
|
jvwoolf left #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:34 |
|
agoben joined #evergreen |
| 07:56 |
|
rlefaive joined #evergreen |
| 09:56 |
berick |
or it's supposed to be in escape_edi |
| 09:59 |
jeff |
This morning I realized that one of the reasons I am most looking forward to the elimination of the XUL client is that it will make it that much easier to make large changes to billing. |
| 10:02 |
berick |
Bmagic: anyway, I have questions... |
| 10:30 |
csharp |
berick: so is it easy to add a 10 second sleep to the Perl API? not sure where to begin (testing bug 1746577) |
| 10:30 |
pinesol_green |
Launchpad bug 1746577 in OpenSRF "Websocket translator responder thread loops on broken jabber socket" [Undecided,New] https://launchpad.net/bugs/1746577 |
| 10:31 |
|
collum joined #evergreen |
| 10:31 |
berick |
csharp: yep |
| 10:31 |
berick |
i tested patron search, want to see a patch for that? |
| 10:31 |
csharp |
sure |
| 10:31 |
Bmagic |
berick: here |
| 10:31 |
|
BAMkubasa joined #evergreen |
| 10:45 |
berick |
it's also possible to backtrack from a sip checkout to a sip login by searching the logs if you are logging the PID |
| 10:45 |
pastebot |
"berick" at 64.57.241.14 pasted ""UNB+UNOA:3+HIDDENSANAGAIN:31B" (1 line) at http://paste.evergreen-ils.org/116 |
| 10:45 |
berick |
but that's not reportable |
| 10:46 |
BAMkubasa |
Dyrcona: Ok, we're doing some testing to see how self checkout machines behave when disconnected, so we'll likely use a specific SIP account for the one machine we're testing with so I can go back and try to find the circulations once we put it back on the network |
| 10:46 |
berick |
Bmagic: thanks. So the PO name is "Ingram 01/31/18 Books" ? |
| 10:46 |
Bmagic |
berick: yes, but I believe the name is longer than that |
| 10:47 |
berick |
i see |
| 11:18 |
|
rjackson_isl joined #evergreen |
| 11:25 |
Bmagic |
berick: if I update the status of acq.edi_message to 'retry' - it will recreate the message right? |
| 11:26 |
berick |
Bmagic: yes, it should |
| 11:26 |
Bmagic |
and furthermore I could just --test-mode ? |
| 11:27 |
berick |
Bmagic: and you can always pass a --po-id to edi_order_pusher.pl |
| 11:27 |
Bmagic |
yep, that's where I am headed |
| 11:27 |
berick |
and it will run regardles of the state of the edi message |
| 11:28 |
berick |
and of course --test-mode will just spit out the EDI |
| 11:28 |
berick |
w/o delivering anything |
| 11:28 |
Bmagic |
Use of uninitialized value in concatenation (.) or string at /usr/local/share/perl/5.22.1/OpenILS/Utils/EDIWriter.pm line 173. |
| 11:29 |
berick |
one of these.. $compiled{org_unit_san}.' '.$po->provider->edi_default->vendcode |
| 11:29 |
Bmagic |
ok |
| 12:32 |
Bmagic |
it's becoming clear that the INVOICE having been truncated like that would cause it to not link back |
| 12:32 |
csharp |
berick++ # bug 1746577 |
| 12:32 |
pinesol_green |
Launchpad bug 1746577 in OpenSRF "Websocket translator responder thread loops on broken jabber socket" [Undecided,Confirmed] https://launchpad.net/bugs/1746577 |
| 12:32 |
csharp |
works for me - I've signed off |
| 12:33 |
csharp |
now I'm interested in testing the other opensrf bug you found that was similar |
| 12:33 |
berick |
Bmagic: yes, exactly. the lineitem ID gets dropped on the floor |
| 12:34 |
berick |
and that's needed for the linking |
| 12:34 |
berick |
csharp++ |
| 12:34 |
|
stephengwills left #evergreen |
| 12:35 |
Dyrcona |
csharp++ # I'll test it, too. |
| 12:35 |
Dyrcona |
If it works for me, I'll push it. |
| 12:35 |
Bmagic |
berick: in theory, it would link back with the full PO name as long as they didn't truncate it |
| 12:35 |
berick |
arg, no direct flights from rdu to stl |
| 15:02 |
jihpringle |
ohiojoe++ |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:18 |
* miker |
blinks at two spinning websockets threads from one process |
| 15:20 |
* Dyrcona |
is just about done testing berick's branch on Lp 1746577 |
| 15:20 |
pinesol_green |
Launchpad bug 1746577 in OpenSRF "Websocket translator responder thread loops on broken jabber socket" [Undecided,Confirmed] https://launchpad.net/bugs/1746577 - Assigned to Jason Stephenson (jstephenson) |
| 15:20 |
Dyrcona |
It's working for me, and I am going to push it. |
| 15:20 |
Dyrcona |
miker: Do you want to give it a go? |
| 15:22 |
miker |
Dyrcona: no, feel free to push it, please. and the other related, if you've tested that too |
| 15:22 |
Dyrcona |
I've not tested that one, but might as well. |
| 15:47 |
Dyrcona |
miker | berick: The branch on Lp 1744158 is also working for me. I'll add my signoff to both branches and push 'em to master and rel_3_0. |
| 15:47 |
pinesol_green |
Launchpad bug 1744158 in OpenSRF "osrf_websocket_translator send requests to the bit-bucket" [Undecided,Confirmed] https://launchpad.net/bugs/1744158 |
| 15:48 |
berick |
Dyrcona++ |
| 17:57 |
csharp |
berick: working from screenshots from a staff member - I'll inspect them to see if they're share-able |
| 17:57 |
csharp |
looks like we need to have them expand the arrow for some of these details |
| 18:20 |
|
abowling1 joined #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:35 |
|
abowling joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:09 |
|
rjackson_isl joined #evergreen |
| 08:18 |
|
ngf42 joined #evergreen |
| 08:38 |
|
Dyrcona joined #evergreen |
| 11:10 |
miker |
berick: strace shows either, waiting on a futex (how the threads decide who's allowed to use our non-reentrant functions at a given moment), or nothing at all (spinning in user-mode code, no system calls going on) |
| 11:15 |
|
collum joined #evergreen |
| 11:17 |
berick |
miker: thanks |
| 11:19 |
miker |
well... "thanks", maybe ... :) not a lot to go on. since we just get tmsg, or not, I guess we'll have to go scrobling through the opensrf client object to find the socket and test connectedness |
| 11:23 |
berick |
one thing that's telling is the lack of a select(..) in the strace. could be short-circuiting before that normally fires... |
| 11:27 |
miker |
that was my thought. a deep check that says "well, we can't do anything, return now!" |
| 11:28 |
miker |
I've traced the code and didn't see a code comment to that effect, nor spot an obvious implementation ... but I was looking quickly |
| 13:17 |
berick |
jabber has to go away between request and response. |
| 13:22 |
csharp |
miker: yes, I've seen the waiting for futex straces on high-load apache2-websockets procs |
| 13:22 |
* csharp |
may even be able to find them now |
| 13:27 |
* miker |
reads up |
| 13:28 |
miker |
berick: ooo... you could use the new open-ils.slooooooooow app to test that! just kill ejabberd after the request goes to the server, perhaps |
| 13:30 |
berick |
miker: yeah.. that rings a bell. /me looks |
| 13:32 |
csharp |
yeah, we have those raising system load on all of our app bricks |
| 13:33 |
csharp |
(just to confirm) |
| 17:17 |
|
derekz left #evergreen |
| 17:54 |
|
abowling1 joined #evergreen |
| 18:15 |
|
abowling joined #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:30 |
|
finnx joined #evergreen |
| 20:31 |
|
Guest11856 left #evergreen |
| 20:36 |
|
jvwoolf joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:12 |
|
agoben joined #evergreen |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 08:05 |
|
rlefaive joined #evergreen |
| 09:45 |
|
yboston joined #evergreen |
| 10:02 |
|
mmorgan1 joined #evergreen |
| 10:24 |
|
jvwoolf joined #evergreen |
| 10:35 |
* phasefx |
is going to try building a new vm for testing.evergreen-ils.org soon, and will then poke folks about buildbot slaves |
| 10:36 |
miker |
Dyrcona: the main thing WRT that part of the query is to capture records that should, but don't currently, have a source component in the vis_attr_vector column. You could look for records where this is the case with something like the following: select id from biblio.record_entry where source is not null and not vis_attr_vector @> intset(source + 268435456); |
| 10:37 |
Dyrcona |
miker: Thanks! I'll try that. |
| 10:38 |
csharp |
phasefx: I set up a couple of VMs for that purpose on mundungus some time ago - just let me know if I can help |
| 15:50 |
* JBoyer |
vanishes |
| 15:51 |
csharp |
JBoyer++ |
| 17:02 |
|
mmorgan left #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:47 |
|
khuckins joined #evergreen |
| 20:05 |
|
rlefaive joined #evergreen |
| 20:25 |
|
rlefaive joined #evergreen |
| 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: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: |
