| 00:43 |
|
beanjammin joined #evergreen |
| 02:06 |
|
beanjammin 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:46 |
|
agoben joined #evergreen |
| 13:00 |
|
jvwoolf joined #evergreen |
| 13:03 |
|
jvwoolf joined #evergreen |
| 13:03 |
|
khuckins__ joined #evergreen |
| 13:08 |
Dyrcona |
berick: I commented Lp 1739803 with the results of a failed npm run test. Hope that is helpful! |
| 13:08 |
pinesol_green |
Launchpad bug 1739803 in Evergreen "Webstaff: Replace Grunt with Webpack + Angular 1.6" [Medium,New] https://launchpad.net/bugs/1739803 |
| 13:09 |
* Dyrcona |
will be happy to pull/try again if you have any updates or advice. |
| 13:11 |
|
rlefaive joined #evergreen |
| 16:39 |
csharp |
yep - sounds like the libraries that found what led to bug 1741309 |
| 16:39 |
pinesol_green |
Launchpad bug 1741309 in Evergreen "Hatch: Installer does not grant proper file permissions" [Undecided,Fix released] https://launchpad.net/bugs/1741309 |
| 16:42 |
gsams |
csharp: Well I'm glad that got settled before our upgrade! Thank you pioneering libraries. |
| 16:42 |
csharp |
seriously - our testing period was crucial to our relatively smooth upgrade to 3.0/web client |
| 16:45 |
gsams |
I've gotta say, our upgrade to 3.0.3 was about the smoothest upgrade we've had even with the web client being new to us. |
| 16:46 |
gsams |
so kudos to everyone one way or another. |
| 16:51 |
gsams |
Bmagic++ #That data URL method works perfectly for receipts. |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
agoben joined #evergreen |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:39 |
|
rlefaive joined #evergreen |
| 13:07 |
jeffdavis |
and I do hate npm just in general :) |
| 13:07 |
jeffdavis |
good luck! |
| 13:08 |
Dyrcona |
Yeah, it's not reliable enough...packages just come and go without warning. |
| 13:08 |
Dyrcona |
Thanks! We'll see how it goes. This install is specifically to test this issue, so no pressure for it to work. |
| 13:20 |
|
jvwoolf joined #evergreen |
| 13:31 |
|
rlefaive joined #evergreen |
| 13:41 |
Dyrcona |
npm install produces this output with master on a fresh install: angular-order-object-by 1.3.0 (git://github.com/rxfork/ngOrderObjectBy.git#78ab8d0fb4ecb9fd308eef43394d5bd3f649826e) |
| 14:16 |
pinesol_green |
csharp: go with node.js |
| 14:16 |
Dyrcona |
So, it looks like it will work with a fresh install. |
| 14:17 |
Dyrcona |
At least on Ubuntu 16.04. That's the other thing... The training server is still running Wheezy. |
| 14:18 |
Dyrcona |
Yeah. angular-order-object-by is installed on my test vm. |
| 14:19 |
Dyrcona |
And, grunt all passed all of the tests. |
| 14:23 |
Dyrcona |
And, yes, the web staff client appears to work. |
| 14:25 |
Dyrcona |
So, it must be that the Node on the training server is out of date. |
| 14:31 |
Dyrcona |
I don't have any wheezy isos hanging around to set up a wheezy test, so I'll leave it at that. |
| 14:36 |
Dyrcona |
Oh, nice. It sends me to a mirror in Sweden. :) |
| 14:36 |
* Dyrcona |
decided to download an ISO after all. |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 16:13 |
Dyrcona |
Well, it's worth it for the verification and the practice, I suppose. |
| 16:13 |
|
mmorgan joined #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 23:22 |
|
remingtron_ joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Failed Log Output: osrfsys.log - Expected 3 errors but encountered 6. <http://testing.evergreen-ils.org/~live> |
| 07:30 |
|
rjackson_isl joined #evergreen |
| 07:46 |
|
agoben joined #evergreen |
| 08:41 |
|
rlefaive joined #evergreen |
| 15:33 |
gmcharlt |
but in the short term, folks have been loading the web client in iOS in the wild |
| 15:33 |
gmcharlt |
and although it's not officially supported, it worked well enough for folks to log on, broke, and is getting unbroken for 3.0.4 |
| 15:33 |
dbs |
I guess the least we can do is document things we know won't / can't work (offline support, whatever Hatch does, ...) |
| 15:34 |
gmcharlt |
yeah |
| 15:35 |
gmcharlt |
and going further, is there any appetite to take it a bit further to put in guards against access the stuff known not to work? and interest in cycles on the part of anybody to do testing against iOS/Safari? |
| 15:35 |
JBoyer |
I don't imagine that many iOS users are interested in printing receipts (Hatch's primary use case). The idea of taking whatever tablet you have on hand into the stacks to capture holds live and without printing anything is something that comes up on occasion when discussing the web client. |
| 15:35 |
kmlussier |
From our perspective, when we decided early on that Chrome and Firefox would be supported browsers, we didn't think it would preclude use on iOS devices since those browsers can be used there. |
| 15:36 |
kmlussier |
I could see a use case for using offline circ on an iPad, but I think if we make it clear that it won't work on iOS, that's a good start. |
| 15:37 |
gmcharlt |
yeah, at the moment anybody who badly wants offline circ on an ipad probably needs to consider writing a native app |
| 15:37 |
JBoyer |
I don't like telling anyone that they can't use a currently supported modern browser when the current breakage is small to unnoticeable. That said I don't know that I'd want to spend a lot of time getting Edge to work. |
| 15:37 |
kmlussier |
gmcharlt: I can't commit to testing against iOS/Safari, but I might be able to find people who can. |
| 15:38 |
gmcharlt |
yeah, blocking service-worker-based offline in iOS would be doable |
| 15:38 |
gmcharlt |
but one thing I'm wondering is what other uses, if any, we want to apply service workers to |
| 15:39 |
miker |
in the long run, they could streamline a lot of things. but it's not just service workers, it's broadcast channels between tabs on the same domain |
| 15:43 |
miker |
edge and ie claim messagechannel support, per caniuse.com |
| 15:44 |
berick |
i'm all for documenting issues, moving in that direction, but outright saying we support it is.. a bit more. |
| 15:44 |
gmcharlt |
berick: yeah, I think it in part depends on identifying folks/institutions willing to commit to it |
| 15:44 |
jeffdavis |
fwiw the Co-op is not in a position to support iOS in dev/testing, much as I'd like iOS to be supported |
| 15:44 |
miker |
berick: I agree with best-effort, until/unless there's a maintainer |
| 15:45 |
* berick |
nods |
| 15:46 |
kmlussier |
I understand the toll it takes, but mobile use was one of the selling points to get our libraries excited about moving to the web client. |
| 15:59 |
gmcharlt |
the last in particular sounds like a useful, quickly implemented step |
| 15:59 |
gmcharlt |
maybe combined with a copy easy-to-calculate metrics of work done since the previous meeting |
| 15:59 |
gmcharlt |
e.g., commits added |
| 15:59 |
phasefx |
tests added |
| 15:59 |
phasefx |
tests fixed, tests removed |
| 16:00 |
JBoyer |
Dev meeting reports are a good idea, especially if it can keep most of the stats going so you don't have to do a lot behind the scenes. And I agree with not wanting only negative feedback. |
| 16:01 |
phasefx |
and of course, I still want what I put on the agenda, tech/feature suggestions :) |
| 16:01 |
JBoyer |
That said, one common piece of negative feedback is "you broke the build!" notifications. I don't think we want to have a stoplight board like some projects I've seen (What did JBoyer do now?) But a gentle nudge to the author of a commit that broke things may be helpful. |
| 16:02 |
gmcharlt |
do I remember correctly that the the tests are run once or twice a day, not triggered when stuff is pushed to master? |
| 16:02 |
JBoyer |
IF it can / should run often enough to be able to pick that out. False positives in that case (1 + n commits go in, the break is attributed to the wrong one) would be frustrating. |
| 16:02 |
phasefx |
gmcharlt: right, twice a day |
| 16:03 |
phasefx |
buildbot may be different |
| 16:03 |
phasefx |
were it working for anything other than OpenSRF |
| 16:03 |
JBoyer |
If changing that would be a significant undertaking in resources it may not be worth it. |
| 16:04 |
phasefx |
it could maybe run more often if we go with berick's smaller dataset notion |
| 16:04 |
phasefx |
right now it's designed with the notion that side effects might not be well contained and/or reversible |
| 16:04 |
phasefx |
thus, complete vm wipes to a known state between runs |
| 16:05 |
phasefx |
we could also farm out the test machines with some infrastructure improvements, let it mimic (or run off of) buildbot in that regard |
| 16:06 |
phasefx |
and get more time of day coverage that way |
| 16:06 |
gmcharlt |
well, we're past the hour, but somethign that warrants further discussion on open-ils-dev (and tuits donations) |
| 16:07 |
gmcharlt |
any other (very quick) items or annoucements? |
| 16:08 |
gmcharlt |
ok, sounds like not |
| 17:38 |
|
khuckins_ joined #evergreen |
| 17:59 |
|
kmlussier joined #evergreen |
| 18:22 |
|
yboston joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:59 |
|
sandbergja joined #evergreen |
| 19:28 |
|
sandbergja joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:03 |
|
agoben joined #evergreen |
| 08:11 |
|
collum joined #evergreen |
| 08:14 |
|
rjackson_isl joined #evergreen |
| 13:40 |
Dyrcona |
In your case, I'd look into any local customizations. Maybe your templates have something wrapped in a check for not ctx.is_staff or similar. |
| 13:44 |
terran |
Thanks, I've already checked for customizations in the templates and the div block is being created (<div data-novelist-novelistselect="0439420105"></div>) but there's nothing inside it. I'm getting a " |
| 13:44 |
terran |
Type error but I'm getting that in the OPAC too where it's working. |
| 13:45 |
mmorgan |
terran: Our Novelist select is working in the web client on our test server. |
| 13:45 |
terran |
mmorgan: Hmm |
| 13:49 |
terran |
I wonder if Novelist is providing the content to us in the same format. |
| 13:51 |
Dyrcona |
I apparently didn't configure Novelist on our 3.0 testing server. |
| 13:51 |
JBoyer |
Also, mmorgan mentioned Novelist Select, that's the product we're using also, are you using one of the other tiers of it? I know they offer more than what we're doing but I don't know much more about it. |
| 13:52 |
Dyrcona |
It is working on our training server with 3.0.3. |
| 13:54 |
|
mmorgan1 joined #evergreen |
| 17:29 |
pinesol_green |
[evergreen|Jane Sandberg] LP1735572: replacing placeholder title attribute with something more meaningful - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bd3a71e> |
| 17:45 |
berick |
gmcharlt: yes, looking now. |
| 17:45 |
gmcharlt |
berick++ |
| 18:11 |
pinesol_green |
[evergreen|Galen Charlton] LP#1724052: move stat-cat cache initialization to patron search service - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f655525> |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 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 |
| 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 |
