| Time |
Nick |
Message |
| 06:01 |
|
rlefaive joined #evergreen |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:16 |
|
JBoyer joined #evergreen |
| 07:33 |
|
jvwoolf joined #evergreen |
| 07:36 |
|
Dyrcona joined #evergreen |
| 07:41 |
JBoyer |
Poof. |
| 07:42 |
JBoyer |
So much for @later I guess. Good thing I read the logs now and then. |
| 07:44 |
JBoyer |
Anyway, Dyrcona, I'm not currently logging the POST data from NCICServer, only the messages themselves, which I'm doing by reconstituting them into XML strings in NCIPServer and dumping them that way, and then doing the same with the responses just before sending them. It's kind of a gross hack, but it's all of the logging NICP has as far as I can tell. :/ |
| 07:45 |
Dyrcona |
JBoyer: Thanks. I'm looking into moving to Dancer2. |
| 07:46 |
Dyrcona |
JBoyer: I'm gonna look into logging headers and POST bodies via Apache, also. |
| 07:46 |
JBoyer |
Imagine my sentences as water pipes; water dripping from every couple of feet as a comma splice leaks just a little here and there... |
| 07:47 |
JBoyer |
Actually I may have done that once, maybe with the trace module? I have to crank the logging up to debug:trace7 or something similar. |
| 07:47 |
JBoyer |
Don't believe I have many notes about it handy though |
| 07:47 |
Dyrcona |
I'm only interested in the 1 URL. I don't have the space to log everything. :) |
| 07:47 |
Dyrcona |
I'll look into it a bit later when I'm on the clock. :) |
| 07:48 |
JBoyer |
Definitely not, I just don't know how easy that is to do. :) And yes, not until the meter is running. |
| 08:01 |
|
collum joined #evergreen |
| 08:40 |
Dyrcona |
JBoyer: There are options, at least for the POST body: https://stackoverflow.com/questions/989967/best-way-to-log-post-data-in-apache |
| 08:41 |
Dyrcona |
I like the suggestion of doing it in the application, except my problem is the application can't parse it properly. |
| 08:43 |
Dyrcona |
mod_dumpio apparently only works for everything: Context: server config. |
| 08:44 |
|
_adb joined #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:50 |
Dyrcona |
Based on this line "dumpost_cfg_t *) ap_get_module_config(r->per_dir_config, &dumpost_module)" I assume that mod_dumpost can be configured per directory, so I'll give that one a shot. It can also log headers. |
| 09:01 |
JBoyer |
Oh, yeah, dumpio was what I had used. I was using it on a test system so while it was crazy chatty it wasn't *All the things* I hope dumppost works, that sounds more generally useful. |
| 09:04 |
Dyrcona |
I'll give it a whirl. |
| 09:19 |
|
abowling1 joined #evergreen |
| 09:19 |
Dyrcona |
I have to use this on production to capture what Autographics sends us. I'd rather not have to take the time to set up a test with them. |
| 09:19 |
Dyrcona |
But, I'm gonna try it on a test vm, first. |
| 09:21 |
Dyrcona |
@decide stay or go |
| 09:21 |
pinesol_green |
Dyrcona: go with go |
| 09:22 |
Dyrcona |
pinesol_green: I knew you'd say that. ;) |
| 09:22 |
pinesol_green |
Dyrcona: http://xkcd.com/1739/ |
| 09:22 |
Dyrcona |
pinesol_green: Touché! |
| 09:22 |
pinesol_green |
Dyrcona: We're going to need a bigger boat. |
| 09:22 |
Dyrcona |
pinesol_green: Indeed, we are. |
| 09:22 |
pinesol_green |
Dyrcona: http://wonder-tonic.com/geocitiesizer/content.php?theme=2&music=6&url=evergreen-ils.org |
| 09:22 |
Dyrcona |
pinesol_green: Now, you're just being silly. |
| 09:22 |
pinesol_green |
Dyrcona: well, that's what you get for not being a shell script |
| 09:23 |
Dyrcona |
ha! |
| 09:23 |
Dyrcona |
ROTFLMAO! |
| 09:23 |
Dyrcona |
A shell script is what got me into this mess in the first place. |
| 09:24 |
|
kmlussier joined #evergreen |
| 09:24 |
|
yboston joined #evergreen |
| 09:26 |
Dyrcona |
Ah, kmlussier and yboston missed the fun. |
| 09:27 |
Dyrcona |
pinesol_green: Either you're sentient or I'm insane, though likely bot at the rate things are going. |
| 09:27 |
pinesol_green |
Dyrcona: connect to host dev port 22: Connection refused |
| 09:30 |
Dyrcona |
@decide sentient or insane |
| 09:30 |
pinesol_green |
Dyrcona: go with insane |
| 09:30 |
Dyrcona |
Yeap. |
| 09:34 |
Dyrcona |
@praise pinesol_green |
| 09:34 |
* pinesol_green |
The itself abides. |
| 09:42 |
|
rlefaive joined #evergreen |
| 10:02 |
|
mmorgan1 joined #evergreen |
| 10:09 |
Dyrcona |
Ah, no. It looks like that line is deceiving and DumpPost configs have to be server wide. |
| 10:26 |
Dyrcona |
JBoyer: I've logged a few messages from Autographics, and I'm surprised. |
| 10:27 |
Dyrcona |
JBoyer: What I see blows up with the old version of HTTP::Body, too, so the change that causes the issue is elsewhere. |
| 10:27 |
Dyrcona |
But, now I have some real data to test with. |
| 10:34 |
JBoyer |
Dyrcona, did you manage to pull any POST info with them or just the XML? If it's not too much trouble to anonymize I could poke at it on occasional too |
| 10:34 |
Dyrcona |
I'm grabbing the content-type head and the POST body. |
| 10:34 |
Dyrcona |
s/(head)/\1er/ |
| 10:35 |
Dyrcona |
I only have 1 message so far. I'm going to let it go for an hour or so. |
| 10:35 |
JBoyer |
++ |
| 10:35 |
Dyrcona |
I'm getting a lot of Evergreen messages, too. |
| 10:35 |
Dyrcona |
Since this is server-wide. |
| 10:36 |
Dyrcona |
I've got at least 5 more messages from autographics, now. |
| 10:37 |
Dyrcona |
I may shut it down before an hour. The file grows a few hundred KB per minute. :) |
| 10:39 |
Dyrcona |
They're using Content-type: application/xml, and my testing shows that blows with Dancer 1.3202 with the old and the new version of HTTP::Body. |
| 10:39 |
JBoyer |
Not as bad as dumpio but still a but chatty, yeah |
| 10:40 |
Dyrcona |
In fact, the xml handler for HTTP::Body is the same, other than the version number. |
| 10:40 |
JBoyer |
Huh. So something about the older version of HTTP::Body on 14.04 is why it doesn't blow up here? |
| 10:40 |
JBoyer |
Oh, maybe not then. |
| 10:40 |
Dyrcona |
So, the older Dancer on Debian 7 must not be using HTTP::Body to parse xml. |
| 10:41 |
Dyrcona |
See, I started with the assumption that HTTP::Body was the problem, but it's apparently not. |
| 10:41 |
Dyrcona |
It may not be Dancer, either. It could be a change in some XML module. |
| 10:43 |
JBoyer |
Ick. If I can get my changes for bug 1691269 finished before the hackaway I suppose we could see about reimplementing NCIPServer as an internal Evergreen module and bypass all of this. That's my only "must have" thing that I need to work on at this year's hackaway. |
| 10:43 |
pinesol_green |
Launchpad bug 1691269 in Evergreen "web client: copy templates created on XUL not displayed" [Undecided,New] https://launchpad.net/bugs/1691269 |
| 10:44 |
Dyrcona |
Right. I figured going with Dancer2 would be easier/quicker. :) |
| 10:49 |
|
abowling joined #evergreen |
| 11:06 |
|
mmorgan joined #evergreen |
| 11:38 |
Dyrcona |
Anyone remember the message that shows up in logs when you hit max children for a service? I want to grep my logs for that message. |
| 11:41 |
Dyrcona |
Is it crucial that all brick head has the same cache key? |
| 11:42 |
berick |
Dyrcona: search for 'children' at WARN level (osrfwarn.log) |
| 11:42 |
Dyrcona |
berick: Thanks. I was search for children in all logs and getting more than I wanted. :) |
| 11:42 |
berick |
may be related logs at ERR as well |
| 11:43 |
berick |
i usually just grep children osrfwarn.log |
| 11:43 |
|
krvmga joined #evergreen |
| 11:43 |
Dyrcona |
Oh nice. I'm finding failed email templates with that. |
| 11:45 |
berick |
heh, yes, there may be dragons |
| 11:49 |
Dyrcona |
'could not launch a new child' may be a better grep string. |
| 11:49 |
Dyrcona |
And, looks like I need to make adjustments on the sip servers. |
| 12:04 |
|
rlefaive joined #evergreen |
| 12:04 |
|
mmorgan1 joined #evergreen |
| 12:11 |
Bmagic |
OMG that wonder-tonic geocitiesizer has me rolling on the floor! |
| 12:12 |
kmlussier |
@hate inconsistent bugs |
| 12:12 |
pinesol_green |
kmlussier: But kmlussier already hates inconsistent bugs! |
| 12:16 |
mmorgan |
When a bug is inconsitent, is that a bug? |
| 12:19 |
kmlussier |
mmorgan: A bug in the bug? |
| 12:19 |
JBoyer |
What is the sound of a bug not bugging? |
| 12:21 |
mmorgan |
:) |
| 12:35 |
|
jihpringle joined #evergreen |
| 12:39 |
|
khuckins joined #evergreen |
| 12:50 |
|
rlefaive joined #evergreen |
| 12:56 |
Dyrcona |
Heisenbugs |
| 12:57 |
mmorgan |
Heh. If you don't look too closely at it, you don't know if it's fixed or not :) |
| 13:14 |
Dyrcona |
Forget the -n option to your sed command and watch the whole file echo to your terminal. |
| 13:26 |
|
sandbergja joined #evergreen |
| 13:33 |
JBoyer |
So, having been the first group of this size that I'm aware of, we upgraded to 3.0 Monday night. |
| 13:33 |
JBoyer |
I have some patches coming. |
| 13:34 |
JBoyer |
But before that, I wanted to ask if anyone has seen either of these issues: |
| 13:35 |
JBoyer |
1. searching a specific library. < 3.0 choosing a specific library in adv search limited your results to items held by that library. >= 3.0 that's not happening anymore and I have found neither rhyme nor reason why. |
| 13:35 |
dbwells |
Dyrcona: I was doing some fiddling and was able to recreate your Dancer ->body issue. |
| 13:36 |
JBoyer |
And 2, when customizing receipt templates, (checkout specifically) I |
| 13:36 |
Dyrcona |
OK. It shouldn't be hard to recreate. Just set content-type to application/xml for one. |
| 13:37 |
JBoyer |
ve heard from staff that they can't add patron name and barcode. Meaning that {{patron.first_given_name}} and so on works in the preview, but not on paper. Is that a regression or is the preview just ahead of the backend? |
| 13:37 |
Dyrcona |
JBoyer might also be interested to know that after 2-1/2 hours of logging, I have 127 actual messages from autographics to test with. |
| 13:37 |
dbwells |
Dyrcona: yes :) In my opinion, the bug is in HTTP::Body::XForms. It just lazily sets body to the buffer contents, which isn't going to be a handle. |
| 13:38 |
Dyrcona |
dbwells: What's odd is that hasn't changed since 2010, and that older version "worked." |
| 13:38 |
Dyrcona |
Unless autographics changed their content-type to coincide with our upgrade... |
| 13:39 |
Dyrcona |
I can try a quick hack on that module, though. I believe I know what I'd need to do. |
| 13:39 |
dbwells |
Dyrcona: I think cribbing the body setting code from HTTP::Body::OctetStream would be an easy place to start. |
| 13:40 |
Dyrcona |
Yeah, or something like the patch for UrlEncoded from that CPAN RT bug. |
| 13:40 |
JBoyer |
Dyrcona, that seems high volume, we only got ~500 total yesterday. |
| 13:41 |
Dyrcona |
dbwells, thanks. I was giving up on a quick fix, but I'll give this a shot. |
| 13:41 |
Dyrcona |
JBoyer: Dunno what to say. It is what it is. :) |
| 13:41 |
dbwells |
Dyrcona: Also, I think this "broke" it: https://github.com/PerlDancer/Dancer/pull/1134/files Dancer used to just pass the body through, then decided it would be better to read from the buffered version, of which there was none in this case. At least that's my interpretation :) |
| 13:42 |
dbwells |
So, I think the bug was there all along, just obscured in convenient way. |
| 13:43 |
Dyrcona |
Yeah, that looks like the culprit. |
| 13:43 |
Dyrcona |
Technical debt. :) |
| 13:44 |
Dyrcona |
JBoyer: Let move NCIPServer to mod_perl and get it into Evergreen as a WWW module during the hack-away. |
| 13:44 |
Dyrcona |
Let's... |
| 13:45 |
kmlussier |
JBoyer: Wait, you're saying you can't limit search results by library? |
| 13:45 |
* Dyrcona |
feels like joining #dancer on irc.perl.org, sharing that github pull request and saying, "Here's my problem." ;) |
| 13:45 |
Dyrcona |
dbwells++ |
| 13:46 |
JBoyer |
kmlussier, not entirely, no. I haven't had time to research it much, but we're getting consistent (repeatable) reports. :/ |
| 13:46 |
JBoyer |
I don't think they're the same results as searching the entire consortium (I should try that...) |
| 13:47 |
JBoyer |
Oh, goodie. No, it's a different order searching everywhere vs here, but here is still showing a lot of ... not here. |
| 13:49 |
JBoyer |
Dyrcona, I'm up for trying. It'll definitely be a learning experience for me though... |
| 13:50 |
dbwells |
Dyrcona: Personally, I blame XForms. :) The standard is so complicated and difficult to read, I think the guy who added 'application/xml' support to HTTP::Body just gave up on figuring what the ->body should actually be, and was only interested in moving that data over to the "XForms:Model" param. |
| 13:51 |
Dyrcona |
dbwells: Sure, I can see that. |
| 13:51 |
Dyrcona |
But I'm not looking for a generic solution, just one that works for this specific case is good enough for me. :) |
| 13:51 |
Dyrcona |
I didn't pick Dancer. rangi did. |
| 13:53 |
* Dyrcona |
has given up on any pretense of our NCIPServer being compatible with Koha. |
| 13:53 |
dbwells |
Dyrcona: I suppose another potential fix would be to pull out the "XForms:Model" param instead of the request->body in Dancing.pm, perhaps. |
| 13:54 |
Dyrcona |
That may be easier. I'll try that first. |
| 13:54 |
Dyrcona |
dbwells++ # again for the suggestions. |
| 13:59 |
dbwells |
Dyrcona: trying to familiarize myself a bit with NCIPServer, figure we'll probably move in that direction sooner or later :) |
| 14:00 |
kmlussier |
JBoyer: You might want to check in with Terran on the receipt issue. I know she did a lot of testing to see which fields worked and which didn't. |
| 14:02 |
kmlussier |
JBoyer: When I tested the new search code, I did a lot of side-by-side testing on two different servers to try to verify the code was retrieving the same set of search results, except in cases where it was retrieving more because of the higher cap. |
| 14:02 |
kmlussier |
I didn't see anything strange at that time, but I don't know if I limited by library from advanced search in my testing. |
| 14:03 |
* kmlussier |
returns to trying to figure out why badges don't always show when they should. |
| 14:19 |
miker |
JBoyer: not seeing that on demo.evergreencatalog.com ... and I can't remember you're catalog's URL |
| 14:20 |
JBoyer |
evergreen.lib.in.us |
| 14:21 |
JBoyer |
berick, re: bug 1656036, If I have time tomorrow to through something together I'd appreciate some thoughts, but if I can't get things together go with your plan. Like you said, it's better to get something going than continually bikeshedding this thing. |
| 14:21 |
pinesol_green |
Launchpad bug 1656036 in Evergreen "Web based staff client needs tab details on the tab label" [Medium,Confirmed] https://launchpad.net/bugs/1656036 - Assigned to Bill Erickson (berick) |
| 14:21 |
miker |
JBoyer: you have timing on for the main public opac? (good, thanks!) |
| 14:22 |
JBoyer |
Yeah, that metarecord search bug was driving me nuts, but I didn't see any point in letting people see it. |
| 14:22 |
JBoyer |
I mean, as far as I know it still is, I haven't had time to track anything down. :/ |
| 14:23 |
JBoyer |
miker, a simple search that shows what I mean: search Indiana state library for title Bag of Bones (we mainly collect large print for users with poor sight) there are several results that have nothing to do with us. |
| 14:26 |
miker |
so, I may not be testing what you're testing, but I just searched for 'harry potter' globally (773 results), went to advance search and restricted to Andrews and got what I expected (77 results) and added added a cache killer, and got the same 77 results. all hav copies at andrews AFAICT |
| 14:26 |
kmlussier |
JBoyer: They're all ebooks? |
| 14:26 |
miker |
or are ebooks |
| 14:26 |
|
khuckins_ joined #evergreen |
| 14:28 |
miker |
JBoyer: "bag of bones" just gives e-records and one bib for the King novel |
| 14:29 |
kmlussier |
It looks like the Located URIs on those ebooks are all set to the top of the org tree |
| 14:30 |
JBoyer |
The ebooks aren't the problem, we've had OverDrive records at the top level from the time we started importing them. When I do that search I get this record at the top: https://evergreen.lib.in.us/eg/opac/record/21116992 |
| 14:30 |
kmlussier |
JBoyer: Can you post the URL for the search results page? You might be performing the search differently than we are. |
| 14:30 |
miker |
JBoyer: I see a copy attached at the state lib... |
| 14:31 |
miker |
hrm... well, hold on |
| 14:31 |
miker |
I'm getting http://evergreen.lib.in.us/eg/opac/record/21117295?query=bag%20of%20bones;qtype=keyword;locg=72;detail_record_view=0;_adv=1;page=0;sort=poprel as the top result |
| 14:32 |
JBoyer |
regular book, no holdings at STLIB-IND, and when I follow the link none of the holdings are displayed in the client. |
| 14:32 |
miker |
yeah, I'm seeing a different print record in the search results |
| 14:32 |
miker |
http://evergreen.lib.in.us/eg/opac/results?query=bag+of+bones&qtype=keyword&fi%3Asearch_format=&locg=72&detail_record_view=0&_adv=1&page=0&sort=poprel |
| 14:32 |
JBoyer |
ALSO, didn't realize the timings busted out of their HTML comment prison in the upgrade... :( |
| 14:33 |
miker |
:) |
| 14:33 |
miker |
that's why I asked, actually ... |
| 14:34 |
JBoyer |
I figured you were looking at the source for some reason and noticed them. (Since the footer isn't in the client I haven't seen it...) |
| 14:34 |
kmlussier |
JBoyer: Is this problem happening when you're logged into the client, in the public catalog or both? |
| 14:35 |
JBoyer |
logged in. I need to check the public opac real quick |
| 14:35 |
JBoyer |
BAH. Yeah, the regular opac looks cool. |
| 14:35 |
JBoyer |
4 results, ours at the top and 3 online records. |
| 14:37 |
JBoyer |
The web client gives me 11 results including ours, some Overdrive and Hoopla records, and 3 non-STLIB-IND print records. |
| 14:37 |
kmlussier |
Well, at least we now have an explanation on why miker and I couldn't see it. ;) |
| 14:37 |
miker |
:) |
| 14:40 |
|
tspindler joined #evergreen |
| 14:42 |
JBoyer |
I'm currently rebuilding all of the app servers to hide the timings, but since it's only staff I guess it's less dire, though staff are more likely to notice anyway. |
| 14:42 |
JBoyer |
So I'll keep looking, and that's a way to test webby to make sure it's just us. |
| 14:48 |
Dyrcona |
dbwells++ # One more time, because hacking HTTP::Body::XForms seems to have fixed it for me. Changing NCIP::Dancing didn't work. :( |
| 14:50 |
miker |
JBoyer: I'm not seeing this in a (quick) test at demo.evergreencatalog.com, fwiw |
| 14:51 |
miker |
logged in as staff, obv |
| 14:51 |
JBoyer |
miker, thanks for checking; moar data, moar help. I'll continue to poke. |
| 14:52 |
JBoyer |
Just because I'm curious, does the new asset.copy_vis_cache stuff get used in searches like this, or is that used elsewhere? (record details or something else) |
| 14:52 |
miker |
it's used in searches |
| 14:53 |
JBoyer |
ok. I'm hoping those misplaced records show up somewhere in that table in a way that helps make sense of it. |
| 14:54 |
dbs |
JBoyer: preferred library for your account playing a part maybe? |
| 14:57 |
|
khuckins_ joined #evergreen |
| 14:59 |
JBoyer |
dbs, preferred lib is unset in the workstation settings, and I've wiped out all of my personal aus entries and that didn't help either. |
| 14:59 |
|
khuckins__ joined #evergreen |
| 14:59 |
|
tspindler left #evergreen |
| 15:11 |
JBoyer |
(but thanks for the idea) |
| 15:12 |
Dyrcona |
dbwells: A hack to HTTP::Body::XForms is working in production. I see a 200 response in the logs instead of a 500! |
| 15:12 |
JBoyer |
That's good news. |
| 15:12 |
JBoyer |
dbwells++ |
| 15:12 |
JBoyer |
Dyrcona++ |
| 15:13 |
JBoyer |
Also, |
| 15:13 |
JBoyer |
miker++ |
| 15:13 |
JBoyer |
kmlussier++ |
| 15:13 |
JBoyer |
dbs++ |
| 15:13 |
JBoyer |
Thanks for the suggestions above, I'll keep digging |
| 15:14 |
kmlussier |
Dyrcona: yay! |
| 15:14 |
kmlussier |
dbwells++ |
| 15:34 |
kmlussier |
OK, here's a puzzle. Why does this search retrieve results: |
| 15:34 |
kmlussier |
http://bark.cwmars.org/eg/opac/results?query=beloved+world+badges%281%29&qtype=keyword&fi%3Asearch_format=&locg=1&detail_record_view=0&sort=poprel |
| 15:34 |
kmlussier |
But this one doesn't |
| 15:34 |
kmlussier |
http://bark.cwmars.org/eg/opac/results?query=my+beloved+world+badges%281%29&qtype=keyword&fi%3Asearch_format=&locg=1&detail_record_view=0&sort=poprel |
| 15:35 |
bshum |
I get no results from either link, so, hmm |
| 15:35 |
kmlussier |
bshum: Well, that's strange, I get 150 |
| 15:35 |
kmlussier |
On the first one. |
| 15:35 |
kmlussier |
Sigh... |
| 15:36 |
kmlussier |
But the problem I was originally troubleshooting was badges inconsistently not displaying when they should. |
| 15:36 |
Bmagic |
Can we help the SimplyE people in this area? https://github.com/NYPL-Simplified/Simplified/wiki/Evergreen |
| 15:36 |
kmlussier |
I guess the badge searches are just as inconsistent. :( |
| 15:37 |
* kmlussier |
just did a hard refresh and is now getting no results for both. |
| 15:38 |
Bmagic |
kmlussier: I got no results when I checked those links |
| 15:38 |
kmlussier |
Bmagic: Yes, that's what bshum reported |
| 15:38 |
Dyrcona |
kmlussier: If I get the badge configuration correct, it should just get calculate when the badge generator runs, right? |
| 15:39 |
* Dyrcona |
is tired...no can English. |
| 15:39 |
kmlussier |
Dyrcona: Well, there are records matching that search that have a badge. |
| 15:40 |
Dyrcona |
I'm talking about the one you added to training that didn't get added to production because unquoted fields. |
| 15:40 |
Dyrcona |
Syntax'll get ya every time, and so will sin taxes. |
| 15:41 |
jeff |
XForms... now there's a term I haven't heard in a long time. |
| 15:41 |
Dyrcona |
Crazy: "I'm seeing it now and the relevance is better. Thanks!!" |
| 15:41 |
Dyrcona |
jeff: I've only ever seen them in theory, never in actual practice. |
| 15:42 |
Dyrcona |
Though, maybe ODF uses them.... |
| 15:43 |
jeff |
I had to use something like this to work around CGI.pm flipping into some kind of XForms mode when it saw certain content types, I think: my $xml = $cgi->param('POSTDATA') || $cgi->param('XForms:Model'); |
| 15:43 |
jeff |
https://github.com/iNCIPit/iNCIPit/commit/8ed2a2d4f1fad079ac263641f68be1b0a0446436 |
| 15:56 |
Dyrcona |
jeff: How 'bout you join JBoyer and I at the hack-away to come up with a better NCIP implementation for Evergreen? |
| 16:00 |
kmlussier |
OK, and the two links I just posted are working for mmorgan now. :( |
| 16:04 |
kmlussier |
@swill Dyrcona |
| 16:04 |
* pinesol_green |
grabs a bottle of MD 20/20 and sends it sliding down the bar to Dyrcona |
| 16:12 |
Bmagic |
Do we have documentation on using the open-ils.actor OpenSRF gateway? Where I can maybe point this community to https://github.com/NYPL-Simplified/Simplified/wiki/Evergreen |
| 16:24 |
|
khuckins_ joined #evergreen |
| 16:26 |
Dyrcona |
Bmagic: There's nothing in the central documentation but there are some tutorials floating around how to access OpenSRF in various ways. |
| 16:26 |
Bmagic |
I remember stumbling on a public facing page within the evergreen server where it generated a list of all of the function calls loaded in opensrf... what was that url? |
| 16:26 |
Dyrcona |
Bmagic: As for the APIs there are the introspect calls in srfsh. |
| 16:27 |
Dyrcona |
I don't think I've seen that, and hopefully it is only the list of things allowed through public router. |
| 16:28 |
Dyrcona |
There's also the source code if you really want to know what is going on, or just want to get confused, it can go either way. ;) |
| 16:28 |
Bmagic |
it's a dynamically created page that loads the "documentation" from each of the register_method's loaded during runtime |
| 16:29 |
Dyrcona |
Dunno. Doesn't ring a bell. |
| 16:29 |
bshum |
I think Bmagic is talking about docgen.xsl |
| 16:29 |
Bmagic |
that's the one! |
| 16:29 |
bshum |
Which is one of those addons you can install to a live system |
| 16:30 |
Dyrcona |
Oh, that. Never install it. |
| 16:30 |
bshum |
You can copy it from source Bmagic and put it in /openils/var/web/opac/extras/docgen.xsl to have it available |
| 16:30 |
Bmagic |
are you saying that you don't recommend installing it (and you shouldnt for security reasons) - or are you saying you have never installed it? |
| 16:31 |
Bmagic |
bshum, thanks! |
| 16:31 |
bshum |
I don't know how up to date it is |
| 16:31 |
bshum |
Or how great it is at revealing all the API stuff |
| 16:33 |
Dyrcona |
I've just never bothered to install it, but if it works the way I think it does, you'll get incomplete information on some methods because the internal documentation is not complete or, as bshum said, out of date. |
| 16:33 |
Dyrcona |
Same is true for introspect, for that matter, but it's better than nothing. |
| 16:34 |
Bmagic |
bshum: It looks like there needs to be some apache config to light it up. The browser is offereing a download instead of executing the script |
| 16:35 |
bshum |
That wouldn't surprise me if that was removed from our apache configs |
| 16:35 |
bshum |
Or not documented I mean |
| 16:35 |
bshum |
Hmm |
| 16:35 |
bshum |
It's in eg_vhost.conf |
| 16:35 |
bshum |
So hmm |
| 16:41 |
bshum |
Oh |
| 16:41 |
bshum |
Probably cause we ripped out all those legacy jspac things? |
| 16:41 |
bshum |
From eg_vhost |
| 16:41 |
Dyrcona |
There's this: http://docs.evergreen-ils.org/3.0/_developer_resources.html |
| 16:42 |
Dyrcona |
And I have some links to specific tutorials that may or may not be listed there. |
| 16:42 |
Dyrcona |
I'm not so sure the support scripts section should be there, either. |
| 16:43 |
miker |
kmlussier: I think you may have some brick differences at cwmars ... with cache killers, both of your "beloved world" search variants are working intermittently for me. another possibility: seeing any PG errors? we've seen casting problems before that look like that |
| 16:44 |
Dyrcona |
heh. It's probably the different hashes I asked about earlier. |
| 16:44 |
Dyrcona |
Perl 5.22 wants to be secure like that. |
| 16:46 |
kmlussier |
miker: krvmga and I had talked about brick differences earlier today when we were just looking at the badge display issue, but the problem didn't seem to consistently occur on one brick or set of bricks. |
| 16:48 |
miker |
Dyrcona: oh, by "cache killer" I mean appending "-kljaskjldfkjlfwk" or the like to the query string ;) |
| 16:49 |
miker |
kmlussier: ah, well, then we'll def want to look at PG logs. thanks for likely crossing bricks off the list ;) |
| 16:57 |
Dyrcona |
Well, the brick should be the same, since everything is built from the same model vm and each head and drone has so far had the exact same things done to them. |
| 16:57 |
Dyrcona |
I shoulda signed out a while ago. |
| 16:58 |
kmlussier |
Dyrcona: Yes, you should have around the time I gave you the MD 20/20 |
| 17:00 |
Dyrcona |
:) |
| 17:00 |
Dyrcona |
With that, I'll sign out now and listen to my old buddy, Joel Crisp's new videos on youtube... I'll be sure to reshare. |
| 17:02 |
bshum |
jeff: Ooops, looks like when we yanked /opac/extras/ cause bookbags and old selfcheck went bye-bye, we missed that docgen.xsl uses part of it |
| 17:03 |
jeff |
bshum: specifically, what broke? |
| 17:03 |
|
khuckins__ joined #evergreen |
| 17:03 |
bshum |
jeff: Well it's not exact, but it looks like the .xsl file gets downloaded instead of run as a server side include |
| 17:04 |
bshum |
I'm still playing with the apache definition for /opac/extras/docgen.xsl to find the right set of parametes |
| 17:04 |
jeff |
ah. |
| 17:05 |
bshum |
Bmagic: See -- https://gist.github.com/anonymous/7718e9801ef31a3715e70d3bdd849ccb |
| 17:05 |
bshum |
That location definition in my eg_vhost.conf got me a working page for docgen.xsl when I copied it into place |
| 17:05 |
jeff |
bshum: do you have this? |
| 17:05 |
jeff |
<Location /opac/extras/docgen.xsl> |
| 17:05 |
jeff |
AddOutputFilter INCLUDES .xsl |
| 17:05 |
jeff |
</Location> |
| 17:05 |
bshum |
I'm not too sure about the AddType at the end there |
| 17:05 |
bshum |
jeff: Yep, but that alone wasn't enough |
| 17:05 |
bshum |
Have to turn on SSILegacyExprParser, etc. |
| 17:05 |
jeff |
hrm. |
| 17:05 |
jeff |
Apache 2.4? |
| 17:06 |
bshum |
Yes, it's apache 2.4 |
| 17:07 |
jeff |
ah, commit bcd6bb |
| 17:07 |
pinesol_green |
jeff: [evergreen|Jeff Godin] LP#1312309: Remove old bbags.xml interface, apache config - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bcd6bb6> |
| 17:07 |
bshum |
Since docgen.xsl isn't installed by default (and probably isn't well maintained anyways) I guess this is how we changed things up |
| 17:07 |
bshum |
Yeah that's where I went back to, sorry jeff. That's why I blamed us :) |
| 17:07 |
jeff |
there's not much to maintain. i'd argue that this is worth fixing. :-) |
| 17:07 |
jeff |
i'll take a look tonight. |
| 17:09 |
|
mmorgan left #evergreen |
| 17:14 |
bshum |
jeff: Neat, I'll play with it more later too, thanks! |
| 17:14 |
bshum |
But first, locating dinner... |
| 17:14 |
bshum |
It's out there. Somewhere. |
| 17:14 |
jeff |
i'd still recommend not installing it by default, and perhaps even recommend restricting it, and give it a look-over, but part of why it has lasted as long as it has is that it doesn't require much in the way of upkeep -- it uses opensrf system calls to get methods and their signatures from the running system. |
| 17:26 |
|
Jillianne joined #evergreen |
| 17:59 |
|
yboston joined #evergreen |
| 18:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 19:01 |
|
Christineb joined #evergreen |
| 19:22 |
* csharp |
cranks up Bmagic's docker image |
| 20:09 |
csharp |
btw, my suggestion to use Fedora server/cockpit makes downloading/installing/running the docker image super easy |
| 20:10 |
csharp |
(running cockpit on my workstation: http://picpaste.com/pics/docker-cockpit-TgT5NxOR.1507851675.png |
| 20:10 |
csharp |
) |
| 21:28 |
Bmagic |
csharp: that's cool! |
