| Time |
Nick |
Message |
| 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 |
| 07:47 |
|
rlefaive joined #evergreen |
| 08:29 |
|
jvwoolf joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:49 |
|
Dyrcona joined #evergreen |
| 08:49 |
Dyrcona |
Whee! https://www.bleepingcomputer.com/news/software/meltdown-and-spectre-patches-causing-boot-issues-for-ubuntu-16-04-computers/ |
| 08:50 |
Dyrcona |
Though it looks like they may have fixed it already. |
| 08:50 |
Dyrcona |
Too much confusion of the two issues. You can't really patch Spectre. |
| 08:56 |
rhamby |
Dyrcona: time to break out the Amigas! |
| 08:57 |
Dyrcona |
rhamby++ |
| 08:57 |
Dyrcona |
MC60x0 was a nice processor series. |
| 08:58 |
Dyrcona |
Oops, missed the 8... 680x0 |
| 08:59 |
csharp |
Dyrcona: yeah, they released a working kernel (4.4.0-109) yesterday and I can confirm that it works |
| 08:59 |
csharp |
embarassing for Ubuntu, tho |
| 09:03 |
csharp |
I asked this the other day during off hours and didn't see (possibly missed) an answer: should we be using Hatch for more than just printing? |
| 09:05 |
Dyrcona |
I don't think so. I think it's only other purpose was going to be offline circulation, and that isn't the case any more. |
| 09:06 |
Dyrcona |
berick or JBoyer would probably know for sure. |
| 09:12 |
csharp |
we're currently under the impression that there are advantages for persistent storage when using Hatch that aren't there otherwise |
| 09:13 |
csharp |
but I'm remembering a discussion between JBoyer and Bmagic about it that sounded like that's a bad thing |
| 09:20 |
Bmagic |
good morning |
| 09:20 |
Bmagic |
Scrolling back, it looks like I have been chosen to bring some printers to the conference? |
| 09:21 |
csharp |
Bmagic: only if it's convenient! :-) |
| 09:22 |
Bmagic |
csharp: we are turning on three checkmarks for Hatch |
| 09:22 |
csharp |
Bmagic: and all is well? |
| 09:22 |
csharp |
(we're following your docs for the most part, btw) |
| 09:23 |
Bmagic |
It puts the settings in Hatch instead of the browser and in theory is less volatile |
| 09:23 |
Bmagic |
What is the problem with that? |
| 09:23 |
csharp |
Bmagic: ok - great - that's in line with what we're telling the libs |
| 09:24 |
Bmagic |
csharp: which docs? |
| 09:24 |
csharp |
there has been a lot of confusion about what Hatch is for vs. what it was originally envisioned to be |
| 09:24 |
csharp |
Bmagic: terran has some docs from MOBIUS for managing hatch setup |
| 09:25 |
Bmagic |
probably http://libraries.missourievergreen.org/content/staff-client-troubleshooting |
| 09:26 |
csharp |
yes, that's it |
| 09:26 |
csharp |
I've only seen them printed out on Terran's desk |
| 09:28 |
|
yboston joined #evergreen |
| 09:28 |
JBoyer |
I don't have any special knowledge about Hatch plans, but I had thought that when Lovefield went in for offline circ that it came up that Hatch may eventually be printing only for simplicity's sake. |
| 09:29 |
csharp |
JBoyer: thanks |
| 09:31 |
JBoyer |
(Though I do very much like the idea of "this is a small extension app to simplify printing" vs "this is how we do anything inconvenient to do in a web browser" which it isn't yet, but could become.) |
| 09:32 |
* csharp |
agrees |
| 09:32 |
csharp |
being from the pre-systemd UNIX world ;-) |
| 09:41 |
Dyrcona |
csharp: Come to the BSD-side. We don't have systemd. :) |
| 10:01 |
berick |
csharp: the consensus as I understand it is to move toward printing only for Hatch. However, until we move workstation settings onto the server, Hatch can be useful for not accidentially blowing away localStorage. well, it doesn't solve the problem, but it makes recovery easier. |
| 10:02 |
berick |
fwiw, i'm strongly in favor of printing only for hatch |
| 10:02 |
berick |
once the workstation stuff is done |
| 10:02 |
berick |
serve-side ws settings and server-configured grid columns will be big priorities for me in the coming months. |
| 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:29 |
Bmagic |
I had a library come to me with a search result issue and I am wondering if bug 1736419 fixes it. The complaint is searching with preferred library X results with details turned on, not showing X's holdings in the copy table below each bib result. |
| 10:29 |
pinesol_green |
Launchpad bug 1736419 in Evergreen "Search Showing Bibs with no Holdings" [High,Fix committed] https://launchpad.net/bugs/1736419 |
| 10:30 |
berick |
gmcharlt_: before I open a bug, do you know if we have anything written down re: storing workstation settings on the server? nothing in the hackway gdoc, just a bullet on the agenda. |
| 10:31 |
gmcharlt_ |
berick: no, I need to write that up |
| 10:32 |
pinesol_green |
[evergreen|Cesar Velez] LP#1739786 - Webstaff MarcEditor BibSource Drop Down Order - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=36d72cf> |
| 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:29 |
miker |
JBoyer: re lovefield, that's there because hatch was not (still is not) ready to handle table-ish data, and it the support infrastructure for hatch was in heavy flux while I was working on offline, worrying me about availability and features for 3.0.0 |
| 11:29 |
miker |
(for the room, really, not just JBoyer) |
| 11:30 |
Dyrcona |
Beautiful...More dropped log messages to the syslog server. I registered two workstations this morning and only see 1. |
| 11:31 |
JBoyer |
miker++ # for the EXPLAIN ANALYZE, heh. |
| 11:33 |
miker |
:) |
| 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. |
| 11:54 |
Dyrcona |
jeff: I made some tweaks suggested by JBoyer, but still some messages go missing. |
| 11:54 |
Dyrcona |
If it is something recent, it's better to grep the brick head logs simultaneously. |
| 11:57 |
jeff |
Dyrcona: if you haven't already, you might use the rsyslog daemon on the app servers then the omrelp output module to pass the messages to the actual syslog server/servers. |
| 11:59 |
jeff |
(rsyslog on both ends, if that was unclear) |
| 12:04 |
Dyrcona |
I believe it already is rsyslog on both ends, but too much to do and too little time. |
| 12:06 |
jeff |
*nod* |
| 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:50 |
Dyrcona |
jeffdavis: So, my problem is believing their documentation.... :) |
| 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:14 |
Dyrcona |
No. Everything beyond max_children is dropped on the floor. |
| 13:14 |
kipd |
Ohhh, not good at all. |
| 13:15 |
Dyrcona |
You'll get messages in the log when you run out. I was just looking for the wording of the message, but couldn't find it. |
| 13:15 |
jeff |
kipd: are you trying to understand how to interpret the #drones field? |
| 13:15 |
kipd |
Yes Jeff. |
| 13:17 |
Dyrcona |
kipd: It's number of drones/max. configured |
| 13:19 |
jeff |
i'm intrigued by open-ils.fielder's #drones=75/15 500% |
| 13:19 |
jeff |
it does appear that the 15 is max_children for that service from the opensrf.settings service. |
| 13:19 |
kipd |
Right, so the ones over the max configured are queued or dropped? |
| 13:20 |
jeff |
well, the first number is intended to be the number of running drones -- which I think DOES include idle or spare drones. |
| 13:20 |
kipd |
We’ve got pretty substantial hardware behind all of these so I’m thinking I have room to up those configured maximums but want to understand what the output really means. |
| 13:21 |
jeff |
log entries indicating that you are hitting max_children would probably be a better indicator than "i am running the max number" |
| 13:22 |
JBoyer |
One way to get numbers like that might be zombie processes, though that would be rather a lot of them. |
| 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. |
| 13:55 |
Dyrcona |
Ah, looks like a problem on their end: There was an error determining which library authentication server to contact for your request. |
| 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:19 |
Dyrcona |
I'm getting null of null available on the only record I've checked, but at least that's better than nothing at all. :) |
| 14:21 |
csharp |
there's a pun in there somewhere dying to get out |
| 14:22 |
Dyrcona |
Yeah. :) |
| 14:22 |
Dyrcona |
null is better than nothing. :) |
| 14:22 |
Dyrcona |
Irony much? :) |
| 14:32 |
Dyrcona |
jeffdavis: Do you know where'd I'd find the authorizationname on the developer site? |
| 14:32 |
Dyrcona |
I'm trying to check if I have the correct one for production. |
| 14:46 |
jeffdavis |
You have to ask them for it, it's not on their site anywhere afaik. |
| 14:48 |
jeffdavis |
Dyrcona: ^ |
| 14:49 |
Dyrcona |
jeffdavis: That's what I was beginning to think. I have an email from last April with most of that information. |
| 14:54 |
Dyrcona |
I see something that I checked out on the integration site in my E-Items Checked out list, so that's working. |
| 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 |
| 15:37 |
pinesol_green |
Launchpad bug 1677813 in Evergreen "Ebook API: OverDrive download link non-functional in My Account" [Undecided,New] https://launchpad.net/bugs/1677813 |
| 15:37 |
Dyrcona |
kmlussier++ I forgot about that. |
| 16:27 |
|
khuckins_ joined #evergreen |
| 16:29 |
|
khuckins__ joined #evergreen |
| 17:02 |
|
mmorgan joined #evergreen |
| 17:02 |
|
mmorgan left #evergreen |
| 17:04 |
|
khuckins_ joined #evergreen |
| 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 |
