| 06:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:09 |
|
rjackson_isl joined #evergreen |
| 08:04 |
|
HackawayBigScree joined #evergreen |
| 08:08 |
|
collum joined #evergreen |
| 09:00 |
agoben |
The participant livestream of the Hack-A-Way is available here: goo.gl/7UNBJ6 |
| 09:02 |
agoben |
To just watch/listen in, the link is: https://www.youtube.com/watch?v=wZyNKacICQE |
| 09:02 |
gmcharlt |
and here's a Google Doc for shared notes: https://docs.google.com/document/d/19EctprR1cybery-zbaNBntRmyASMYcRwt4-6S1-YNts/edit?usp=sharing |
| 09:02 |
rhamby |
for Hack-A-Way folks, I added an "Accomplishments" section at the bottom to feel free to add things you've done - bugs tested, patches, etc.... |
| 09:04 |
kmlussier |
Bmagic: I got my 'read more' links code working here if you wanted to look at it - https://mlnc3.noblenet.org/eg/opac/record/247 |
| 09:04 |
Bmagic |
kmlussier: sure! |
| 09:08 |
mmorgan |
kmlussier: Nice! |
| 09:12 |
|
yboston joined #evergreen |
| 09:15 |
Dyrcona |
csharp: on Lp 1325054, is that with libdbi compiled from source or installed from packages or both? |
| 09:15 |
pinesol_green |
Launchpad bug 1325054 in Evergreen "libdbi deprecation warnings when building Evergreen" [Undecided,New] https://launchpad.net/bugs/1325054 |
| 09:17 |
maryj_ |
I'm available to help test things, y'all |
| 09:18 |
csharp |
Dyrcona: in my case, just with packages, not from source |
| 09:18 |
Dyrcona |
Thanks. I haven't paid enough attention to the warnings. |
| 09:18 |
Dyrcona |
I'll take a look at those bugs/branches this morning. |
| 15:09 |
gsams |
managed to resolve the earlier clark-kent issue. All I did was wait a while and re-run clark-kent, but hey it works now so I'm not going to complain. |
| 15:11 |
|
hbrennan joined #evergreen |
| 15:19 |
* gmcharlt |
claims 1079 in the name of mergers and acquisitions lawyers everywhere! |
| 15:23 |
jeff |
berick: pushed a branch to bug 1680566, if you'd like to give it some eyes/testing/signoff. |
| 15:23 |
pinesol_green |
Launchpad bug 1680566 in Evergreen "Remove open-ils.permacrud service" [Undecided,New] https://launchpad.net/bugs/1680566 |
| 15:29 |
|
mmorgan joined #evergreen |
| 15:33 |
pinesol_green |
[evergreen|Ben Shum] LP#1730721: future proof build-db.sh (followup) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=73a1874> |
| 15:35 |
pinesol_green |
[evergreen|Rogan Hamby] LP#1145213: improvements to record merge - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d2c8443> |
| 15:35 |
pinesol_green |
[evergreen|Cesar Velez] LP#1145213: add pgTAP test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2ccdbe6> |
| 15:35 |
pinesol_green |
[evergreen|Galen Charlton] LP#1145213: fix some typos - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0ee3e8a> |
| 15:35 |
pinesol_green |
[evergreen|Galen Charlton] LP#1145213: add schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ba3b6e8> |
| 15:37 |
gmcharlt |
Bmagic: is bug 1730692 ready for a pull request? |
| 15:37 |
pinesol_green |
Launchpad bug 1730692 in Evergreen "asset.copy_attr_vis_cache != asset.copy_vis_attr_cache" [Undecided,New] https://launchpad.net/bugs/1730692 |
| 15:37 |
Bmagic |
oh, yes I believe it is |
| 16:37 |
* gmcharlt |
claims 1080 in the name of visible ghosts everywhere! |
| 16:38 |
berick |
jeff: doh. bug updated. |
| 16:40 |
jeff |
not sure if it's hack-a-way worthy, but bug 1671150 caught my attention and is now tagged pullrequest. |
| 16:40 |
pinesol_green |
Launchpad bug 1671150 in Evergreen "Unqualified references in evergreen.unaccent_and_squash lead to index creation failures with pg_restore" [Undecided,In progress] https://launchpad.net/bugs/1671150 |
| 16:43 |
|
abowling left #evergreen |
| 16:43 |
pinesol_green |
[evergreen|Mike Rylander] LP#1723977: Move no-LURIs test to be a peer of no-copies test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5a187c8> |
| 16:43 |
pinesol_green |
[evergreen|Jason Boyer] LP1724246: asset.cache_copy_visibility fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4adf54a> |
| 16:43 |
pinesol_green |
[evergreen|Galen Charlton] LP#1724246: sync schema update script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cbaca2a> |
| 16:43 |
pinesol_green |
[evergreen|Galen Charlton] LP#1724246: stamp schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dfdd5a6> |
| 16:45 |
pinesol_green |
[evergreen|Rogan Hamby] LP#1346381: remove searching child org units, requirement to have volumes and adds existing org unit - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0e326b3> |
| 16:45 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1346381: Release notes for new shelving location limiter behavior - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cfb7979> |
| 17:00 |
* Dyrcona |
calls it a day (for now). |
| 17:01 |
mmorgan |
hackers++ # great progress for the first day!! |
| 17:04 |
|
mmorgan left #evergreen |
| 17:25 |
gmcharlt |
miker: thought so -- and I sorted it out already and pushed the fix |
| 17:25 |
gmcharlt |
but I appreciate the confirmation |
| 17:27 |
miker |
ha. sorry about that :) |
| 18:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:56 |
|
jvwoolf joined #evergreen |
| 19:01 |
|
rlefaive joined #evergreen |
| 21:04 |
|
roycroft joined #evergreen |
| 05:56 |
|
gsams joined #evergreen |
| 06:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:24 |
|
Nidheesh joined #evergreen |
| 07:24 |
Nidheesh |
hi |
| 07:24 |
Nidheesh |
i need a help in SIP2 configuration |
| 14:14 |
sandbergja |
For this topic, I'm curious how much more review/assessment of the reorganized documentation we need to do |
| 14:14 |
ohiojoe |
Which reminds me, I should have put this out here too |
| 14:14 |
ohiojoe |
#link https://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:dig_meeting_20171102-agenda |
| 14:15 |
sandbergja |
We created a set of requirements for the reorg project way back when |
| 14:15 |
sandbergja |
#link https://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:reorg_2014:requirements |
| 14:15 |
sandbergja |
I don't know if we met all of the requirements. Particularly the requirement that says: "We need to identify a group of beta testers for each book that will test out each book in their day-to-day operations." |
| 14:15 |
alynn26_ |
I like the new organization. |
| 14:16 |
sandbergja |
alynn26_: oh great! That's good to hear. :-) |
| 14:16 |
ohiojoe |
even looking at the cleanup list, it looks like good progress is being made wittling down the identified needs.. |
| 14:24 |
sandbergja |
1) send out a call to the general list to help generate some feedback |
| 14:24 |
alynn26_ |
I'll let you know how it goes. |
| 14:24 |
ohiojoe |
Actually, now that I read what Lynn is describing, I'm sure I could probably make an assignment or two along the same lines, either in my library or by asking for a volunteer among the other Ohio libraries to do the same.. |
| 14:25 |
sandbergja |
2) follow alynn26_'s example and get some folks at our own libraries to test drive the new manuals |
| 14:26 |
sandbergja |
3) this one would be for me, but share knowledge of how to work with the new manuals on an asciidoc level (and I would appreciate guidance from this group on how the best way for me to share that knowledge might be) |
| 14:26 |
|
khuckins_ joined #evergreen |
| 14:26 |
sandbergja |
thoughts? |
| 14:26 |
ohiojoe |
I think those sound like good action items. Would the call just be for other folks outside of DIG to do what Lynn described? I could write up that appeal.. |
| 14:29 |
alynn26_ |
Yea, we look at the docs but don't see the holes, we need to find the holes. |
| 14:30 |
ohiojoe |
ok, this sounds like a plan to me. any objections? |
| 14:30 |
sandbergja |
none from me |
| 14:30 |
abneiman |
nope |
| 14:30 |
ohiojoe |
#action ohiojoe will make a call out to the general list for help generating feedback to the current state of the reorganized documentation |
| 14:30 |
ohiojoe |
#action everyone will find volunteers at their libraries to test drive the new manuals |
| 14:31 |
ohiojoe |
#action sandbergja will share asciidoc level knowledge of how to work with the new manuals |
| 14:31 |
ohiojoe |
although, now that I think about it, we didn't give you any feedback on how best to go about doing that.. |
| 14:32 |
alynn26_ |
I've not looked at it, so I've got no idea yet. |
| 14:33 |
ohiojoe |
and I'm still at the "reread resources and learn asciidoc" stage.. I know it's not hard, I just need to carve out the time to do it.. |
| 14:35 |
alynn26_ |
Time, i wish i had more of it. |
| 15:54 |
Bmagic |
do we have a typo in metabib.pm? |
| 15:55 |
Bmagic |
It also turns up in sitemap_generator |
| 15:56 |
hbrennan |
ohiojoe: The general list reminder is oh so helpful. Only way I remembered to put it on my calendar! Thanks! |
| 16:05 |
bshum |
Bmagic: That's what it's starting to look like to me |
| 16:05 |
bshum |
Which is newer or older I guess |
| 16:16 |
bshum |
Given that in the DB it's "asset.copy_vis_attr_cache" I'm going to go with those other two references are bad. |
| 16:17 |
bshum |
Bmagic: Change 'em up and re-test? :D |
| 16:24 |
bshum |
Bmagic++ |
| 17:14 |
|
Jillianne joined #evergreen |
| 17:56 |
|
rlefaive joined #evergreen |
| 18:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 19:09 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: replacing Admin menu with Administration menu - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8b3eb6c> |
| 19:35 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: Fixing menu refs on booking docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=096f5a5> |
| 00:54 |
|
ariez joined #evergreen |
| 00:54 |
pastebot |
"ariez" at 64.57.241.14 pasted "CANNOT CREATE MARC RECORD IN EVERGREEN ILS 3.0" (6 lines) at http://paste.evergreen-ils.org/909 |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:38 |
|
dwgreen joined #evergreen |
| 08:14 |
|
sandbergja joined #evergreen |
| 08:57 |
|
bos20k joined #evergreen |
| 14:45 |
dbwells |
berick: I'd love to see some debug logs if you can catch it in the act. We can reliably reproduce it on production only, and I've been too gunshy to crank up to debug on production at this point. |
| 14:48 |
berick |
sorry dev VM, you're disk is about to smoke |
| 14:49 |
berick |
heh, ejabberd log level 5 is certainly effective |
| 14:49 |
dbwells |
My testbed when I was poking at it for an hour or two ended up being a simple srfsh file of 500 open-ils.search.biblio.copy_counts.location.summary.retrieve calls. It almost always failed in production within those 500, but never on dev with the same test :( |
| 14:50 |
berick |
dbwells: with the same or different args each time? |
| 14:50 |
dbwells |
berick: exactly the same |
| 14:51 |
* berick |
tries that |
| 15:09 |
miker |
the process being the search drone |
| 15:14 |
berick |
miker: that's consisten w/ what I'm seeing. (finally caught it again). storage tries to send a reply to open-ils.search, jabber replies with a service-unavailable message. |
| 15:14 |
berick |
search process is gone |
| 15:15 |
miker |
right |
| 15:15 |
miker |
it dies inside the gather() that tries to fetch the result of that storage call |
| 15:15 |
miker |
I've confirmed that much, and added more logging in XMPPReader to see where in its wait() it's actually dying... trying to provoke it again |
| 15:16 |
miker |
(and wondering if that logging will "fix" it, because that would be annoying...) |
| 15:17 |
miker |
well, presuming it's in wait() ... but everything between gather() and wait() is really just test-and-pass, with a little timeout adjustment thrown in |
| 15:31 |
miker |
berick: and to board up one rabbit hole for you to avoid, I elided dispatch() and it still occurs :( |
| 15:31 |
|
kmlussier joined #evergreen |
| 15:32 |
berick |
miker: thanks. |
| 15:43 |
|
khuckins__ joined #evergreen |
| 17:16 |
jeffdavis |
s/ticket/LP bug/ |
| 17:17 |
kmlussier |
Sometimes, the slowness will disappear for a while after you apply a promising patch, making you think it's gone, only to come back in full force when you least suspect it. |
| 17:17 |
kmlussier |
It's sneaky |
| 17:18 |
miker |
berick: alternate proposal... at OpenILS/Application/Search/Biblio.pm:1417 say `alarm(0);` and likewise immediately after the close of the eval block |
| 17:18 |
* miker |
tests |
| 17:19 |
berick |
miker: +1 to adding that for sure |
| 17:19 |
miker |
that'll clear the alarm timer |
| 17:25 |
dbwells |
My usual breakage routine seems to be failing me tonight. Was probably relying unknowingly on some other load which doesn't exist at 5:25pm :) |
| 17:27 |
dbwells |
It sounds like the masters here have things well in hand, at any rate :) |
| 17:30 |
|
jvwoolf left #evergreen |
| 17:30 |
dbwells |
yay, finally broke it |
| 17:41 |
miker |
berick: I think you just found the final SIGALRM-shaped jigsaw puzzle piece under that couch cushion... some testing tomorrow will confirm (or deny), and if it's good I'll post a patch |
| 17:44 |
berick |
miker: awesome. beware the lint! |
| 17:44 |
berick |
and dog toys and old nickels and |
| 17:50 |
dbwells |
miker: berick: adding an IGNORE a la berick's suggestion also seems to work here. I certainly can contribute nothing regarding the correctness of other points being discussed :) There seems to be some light at the end of the tunnel, though! |
| 17:58 |
pinesol_green |
miker: Forget it, Jake. It's just miker. |
| 17:58 |
miker |
for those spurious ALRMs |
| 18:00 |
berick |
miker: when does that alarm code come into play? if the caller has the cache key, doesn't that imply the data is in the cache? |
| 18:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:02 |
berick |
in any event, suppose we could also replace alarm() w/ a loop that counts up to the timeout if it continues to be problematic. |
| 18:02 |
miker |
1) the main search call uses respond_complete() to send back the results and the provisional facet key early, then calculates the facets and stores them 2) the caller gets the key and says "search! give me the facets!" in a second call 3) if the first call's post-respond_complete facet logic isn't done yet, the second search call waits until it sees that it is complete, sleeping 50ms at a time |
| 18:03 |
miker |
we could |
| 18:06 |
miker |
and the mod_perl code is rearranged to do a bunch of work between the result return and the facet request, giving facets parallel time to be calculated |
| 18:07 |
miker |
shaves ~1.5 secs off the average "several hundred results" search in terms of time-to-render |
| 18:08 |
berick |
right, thought it was something like, but was missing the piece where it returned early |
| 18:09 |
miker |
originally the facet timeout was 2s, then 4s in 3.0 IIRC, but I'm going to propose bumping it up to 10 as a max for facet timeout ... there are still instances of a result page not showing facets on the first load |
| 18:09 |
miker |
esp on all-in-one test servers |
| 18:12 |
kmlussier |
I see that happening a lot in 2.12. I haven't noticed it as much in 3.0. |
| 18:33 |
jeffdavis |
^ exciting! |
| 18:50 |
kmlussier |
jeffdavis: Yes, indeed! :) |
| 19:52 |
csharp |
and, just like that, https://blog.angular.io/version-5-0-0-of-angular-now-available-37e414935ced |
| 23:52 |
kmlussier |
I'm noticing an issue with Located URI searching using the Conerto dataset. |
| 23:53 |
kmlussier |
In 2.12, I can do a keyword search for 'hobbit' and retrieve one of the ebook test records with a located URI owned by the consortium. |
| 23:53 |
kmlussier |
In 3.0, I get no results. |
| 05:41 |
|
yar joined #evergreen |
| 05:49 |
|
rlefaive_ joined #evergreen |
| 06:01 |
|
book`_ joined #evergreen |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:02 |
|
Bmagic joined #evergreen |
| 08:05 |
|
rlefaive_ joined #evergreen |
| 08:07 |
|
kmlussier joined #evergreen |
| 08:47 |
ariez |
n which ubuntu version.. 14.0 or 16.0 |
| 08:47 |
ariez |
TQ csharp |
| 08:47 |
csharp |
ariez: happy to help! feel free to ask more questions if you need assistance |
| 09:11 |
kmlussier |
csharp++ #Adding more bits to the test dataset! |
| 09:16 |
|
yboston joined #evergreen |
| 09:20 |
|
jvwoolf joined #evergreen |
| 09:41 |
|
rlefaive joined #evergreen |
| 10:08 |
|
rlefaive joined #evergreen |
| 10:24 |
|
dwgreen joined #evergreen |
| 10:30 |
mmorgan |
berick++ # Teaching the web client to display configured printers |
| 10:35 |
berick |
mmorgan: testing Hatch, I take it? |
| 10:36 |
mmorgan |
berick: Yes, and also getting better acquainted with the web client in general. |
| 10:36 |
|
jvwoolf1 joined #evergreen |
| 10:36 |
mmorgan |
Not being able to see installed printers in the xul client has been a real pet peeve of mine. :) |
| 17:54 |
phasefx |
hocus pocus! |
| 17:55 |
* phasefx |
will now dissappear |
| 17:55 |
* phasefx |
peeks his head back in, "was it that bad? |
| 18:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:02 |
Bmagic |
haha! |
| 18:02 |
Bmagic |
phasefx++ |
| 18:02 |
Bmagic |
you win |
| 06:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 08:29 |
|
mmorgan joined #evergreen |
| 08:57 |
|
_adb joined #evergreen |
| 09:05 |
|
Dyrcona joined #evergreen |
| 11:18 |
pinesol_green |
csharp: [evergreen|Kyle Huckins] LP#1511358 Patron Survey Interface - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e2ee72f> |
| 11:18 |
csharp |
bug 1511358 |
| 11:18 |
pinesol_green |
Launchpad bug 1511358 in Evergreen "webclient: Surveys are not accessible from patron account" [Medium,Fix released] https://launchpad.net/bugs/1511358 |
| 11:20 |
Dyrcona |
csharp: You know how to write a small Perl program to make those calls? If so, that would be a good way to test changes to that code. |
| 11:21 |
csharp |
Dyrcona: I don't, unfortunately :-/ |
| 11:25 |
Dyrcona |
I can paste something for you in a bit. Got something else to do right now. |
| 11:25 |
csharp |
Dyrcona: that would be great! - thank you |
| 11:44 |
jeff |
helps if i remember to start the survey. |
| 11:45 |
csharp |
jeff: and I think a quirk of surveys is that you have to start them the next day (i.e., not today) |
| 12:09 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "For csharp: pcrud script." (55 lines) at http://paste.evergreen-ils.org/908 |
| 12:12 |
Dyrcona |
And, that was an obvious edit of a script I wrote earlier this week to test something in open-ils.reporter. |
| 12:12 |
csharp |
Dyrcona++ # will test :-) |
| 12:13 |
Dyrcona |
I would have changed the $reporter variable to $request if I'd noticed. :) |
| 12:14 |
Dyrcona |
I haven't run that script, either, so beware typos. |
| 12:14 |
jeff |
confirmed in webby, it's fleshing far too much. |
| 13:07 |
Bmagic |
I agree with you Dyrcona |
| 13:36 |
|
khuckins__ joined #evergreen |
| 13:59 |
jeff |
there are days when i think i'm getting better at using jq, and there are days when i just give in and supplement what i know with a blunt usage of grep. |
| 14:02 |
csharp |
jeff: empty in the user editor - unfortunately there's no "we've already answered this so don't ask again" feature |
| 14:19 |
csharp |
btw, the lack of such a feature means that required surveys require an answer every time you edit and save the record |
| 14:19 |
csharp |
but that's a bug report for another day |
| 15:02 |
csharp |
I was just thinking about the fact that concerto doesn't approximate "real" |
| 15:02 |
csharp |
or realistic data scale |
| 15:03 |
csharp |
I think it would be beneficial to host a more realistic dataset somewhere that people can download for testing larger things |
| 15:03 |
jeff |
*nod* |
| 15:04 |
* csharp |
isn't expressing himself well |
| 15:04 |
jeff |
and/or generators. |
| 15:04 |
csharp |
anyway - keep concerto around for basic proof of concept, but when doing testing for signoffs, require the larger dataset |
| 15:04 |
csharp |
just thinking out loud |
| 15:05 |
* mmorgan |
agrees. Many times production level data makes all the difference. |
| 15:06 |
Dyrcona |
Yeah. It does. |
| 15:08 |
kmlussier |
csharp: There are several projects that I will only test using something closer to production data. For example, the recent 3.0 search work was tested against a much larger dataset. |
| 15:08 |
kmlussier |
Testing search against Concerto is never a good idea. |
| 15:08 |
csharp |
kmlussier: that's good to hear |
| 15:09 |
csharp |
well, I'm very happy we test extensively before go-live |
| 15:09 |
csharp |
this probably would have brought us to our knees on day one |
| 15:10 |
csharp |
fwiw, the offending code is also in 2.12 - which tells me that not many are using the web client in production yet |
| 15:10 |
kmlussier |
csharp: Maybe, but do you have a good sense of how many people are using surveys? |
| 15:11 |
csharp |
kmlussier: everyone in PINES uses surveys - we require it to record voter registration |
| 15:12 |
Dyrcona |
You can register to vote at the library? |
| 15:20 |
|
Jillianne joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:45 |
|
jvwoolf left #evergreen |
| 18:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 21:32 |
|
finnx1 joined #evergreen |
| 21:36 |
|
finnx1 left #evergreen |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:04 |
|
agoben joined #evergreen |
| 07:07 |
|
JBoyer joined #evergreen |
| 07:53 |
|
dwgreen joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 09:08 |
|
_adb joined #evergreen |
| 09:17 |
|
Dyrcona joined #evergreen |
| 09:24 |
csharp |
hmm - something on our 3.0.0 test server is blasting the DB with perm checks for permission.usr_has_object_perm(9554, 'VIEW_USER', 'asvr', '1541810') AS has_perm; |
| 09:24 |
csharp |
and it appears to be walking through every survey response |
| 09:24 |
csharp |
it has exhausted pcrud drones on all servers |
| 09:25 |
csharp |
many checks per second |
| 09:25 |
* csharp |
thinks something somewhere is coded all wrong |
| 09:27 |
csharp |
having trouble recreating it |
| 09:28 |
csharp |
yeah - this is a problem |
| 09:28 |
csharp |
it's happened to multiple users over the last few days |
| 09:31 |
csharp |
aha - it happens when I go to Other -> Surveys in a patron record |
| 09:34 |
csharp |
and yep, it's walking through every survey response in the DB |
| 09:35 |
csharp |
we have 3,895,615 survey responses to walk through |
| 09:35 |
* csharp |
wonders if JBoyer or Dyrcona has seen this |
| 09:35 |
csharp |
but I'm not sure if anyone else uses surveys to the same extent as we do |
| 09:36 |
JBoyer |
We have never used the Survey feature here, so no. (and thank goodness...) |
| 09:36 |
csharp |
JBoyer: yeah, thank your lucky stars! |
| 09:37 |
Dyrcona |
I don't think we use the survey feature either. We're still on 2.12, anyway. |
| 09:37 |
JBoyer |
But yes, it should obviously only do the check once, and I would assume by the point you've reached that interface it's been done already anyway. |
| 09:37 |
csharp |
Dyrcona: oh - I forgot about that |
| 09:37 |
Dyrcona |
And, I've not finished the 3.0 test server, yet. |
| 09:37 |
JBoyer |
\me is the only sucker that upgraded week 1. |
| 09:38 |
* JBoyer |
too |
| 09:38 |
csharp |
JBoyer++ pioneering |
| 14:25 |
|
khuckins__ joined #evergreen |
| 14:27 |
jeff |
JBoyer: based on last year, could be handy. |
| 14:28 |
JBoyer |
jeff++ # can't hurt to be prepared in any case. |
| 14:42 |
pinesol_green |
[evergreen|Remington Steed] Docs: Fix AsciiDoc header syntax bug - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=24c7160> |
| 15:02 |
|
sandbergja joined #evergreen |
| 15:18 |
|
mmorgan1 joined #evergreen |
| 15:21 |
|
khuckins_ joined #evergreen |
| 17:12 |
|
jvwoolf left #evergreen |
| 17:21 |
|
mmorgan left #evergreen |
| 17:58 |
|
Jillianne joined #evergreen |
| 18:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 01:01 |
|
tsbere_ joined #evergreen |
| 03:06 |
|
tsbere__ joined #evergreen |
| 04:52 |
|
jeff__ joined #evergreen |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:56 |
|
dwgreen joined #evergreen |
| 07:19 |
|
kmlussier joined #evergreen |
| 08:04 |
|
collum joined #evergreen |
| 10:05 |
berick |
not saying Perl's not to blame, just that all we know for sure at this point is jabber is mad, maybe at some xml the perl code is generating that's not valid. |
| 10:06 |
berick |
another option is to set loglevel to 5 -- that will show the XML we're sending to the jabber server |
| 10:06 |
berick |
(and it will slow everything down, beware) |
| 10:06 |
Dyrcona |
It's a test vm. No one else uses it. |
| 10:06 |
berick |
you could also up the log level, but only restart trigger |
| 10:07 |
berick |
so you're not slowing /everything/ down |
| 10:07 |
csharp |
berick: ooh - that's a good idea - I never thought of handling debug that way |
| 13:16 |
Dyrcona |
<username>opensrf</username><password>password</password> |
| 13:17 |
Dyrcona |
There's my 'super secret' password in the clear. |
| 13:17 |
bshum |
Fun |
| 13:17 |
Dyrcona |
For the logs, I'm lazy and just use password on my test vms because they're behind a firewall. |
| 13:18 |
Dyrcona |
There is a lot of "unnecessary" chatter going on. |
| 13:19 |
csharp |
Dyrcona: ah - good to know |
| 13:19 |
Dyrcona |
<<"orcester Tatnuck Magnet School\\\", |
| 13:34 |
Dyrcona |
So, I think I'll upload this 6MB of osrfsys.log to the Lp bug. I think miker had asked me to share it if I could. |
| 13:35 |
Dyrcona |
It is surprisingly small consider the log settings. |
| 13:35 |
Dyrcona |
Or, should i set loglength to the same as my ejabberd max_stana_size so the message that is too big will be clearly truncated? |
| 13:41 |
kmlussier |
I am testing something with floating, but I'm unable to get the basic floating behavior to work. I think I may be missing a step. |
| 13:41 |
kmlussier |
I edited a copy to use the default 'Everywhere' rule. If I check that copy in at another library, it should just stay there, right? Or do I need to do something else? |
| 13:42 |
kmlussier |
It keeps putting the copy into transit when I check it in at another location. :-/ |
| 13:43 |
|
jwoodard joined #evergreen |
| 13:47 |
kmlussier |
Hmmm...I can get it to work on my 2.12 server. Maybe there's a bug. |
| 13:48 |
* Dyrcona |
has never really looked into the floating implementation. |
| 13:54 |
kmlussier |
Oh, never mind. There was a hold on the title that the system was trying to fill. |
| 13:55 |
kmlussier |
This is what happens when I try substituting tea for coffee. |
| 17:01 |
|
jvwoolf left #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:39 |
|
khuckins_ joined #evergreen |
| 18:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 08:12 |
|
Dyrcona joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:44 |
|
_adb joined #evergreen |
| 11:30 |
Dyrcona |
OK. |
| 11:42 |
miker |
Dyrcona: huh, yeah... the gateways are not chunking large messages |
| 11:43 |
* miker |
just looked at the new bug |
| 11:44 |
Dyrcona |
I have an acq issue that I think is the same thing. I can add the logs if you like, or wait to test a fix. |
| 11:45 |
* Dyrcona |
is still gathering the log information and likely won't have it all together until Monday, anyway. |
| 11:45 |
miker |
Dyrcona: if you can past the logs, that'd be good. I've got a small itch in the back of my mind re the router, now... |
| 11:46 |
miker |
and I certainly won't have a fix ready before monday... |
| 14:44 |
kmlussier |
hbrennan++ indeed |
| 14:45 |
csharp |
we broke down the options a few years ago: https://pines.georgialibraries.org/tip-pull-lists |
| 14:45 |
kmlussier |
hbrennan: Is it going fairly smoothly so far? |
| 14:46 |
hbrennan |
Thanks! |
| 14:46 |
hbrennan |
So far so good |
| 14:46 |
hbrennan |
I think things broke because we moved the whole database so we could test it out before. |
| 14:47 |
hbrennan |
Emails were being generated yesterday for courtesy notices, but getting stuck because some piece of Outlook was different |
| 14:47 |
hbrennan |
Just those types of issues |
| 14:47 |
|
mmorgan joined #evergreen |
| 14:47 |
hbrennan |
Staff (besides me) haven't had any trouble |
| 14:53 |
kmlussier |
hbrennan: Are people using the web client or are they still using the xul client? |
| 14:54 |
hbrennan |
Xul client for now. About half our staff is out this week |
| 14:54 |
hbrennan |
I haven't trained anyone on Webby yet |
| 16:53 |
kmlussier |
Have a nice weekend #evergreen! |
| 17:01 |
|
mmorgan left #evergreen |
| 17:25 |
|
jvwoolf left #evergreen |
| 18:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 19:30 |
|
khuckins_ joined #evergreen |
| 00:25 |
|
yar joined #evergreen |
| 03:50 |
|
gsams joined #evergreen |
| 06:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:40 |
|
rlefaive joined #evergreen |
| 07:54 |
|
kmlussier joined #evergreen |
| 12:57 |
Dyrcona |
Not seeing how I can force the join order with JSON queries, I'm going to try gmcharlt's squashed version of jeffdavis's branch. |
| 13:09 |
dbwells |
Dyrcona: Just curious, did you try bumping up the join_collapse_limit? |
| 13:09 |
Dyrcona |
No. I didn't. |
| 13:11 |
Dyrcona |
Trouble is. I don't have a comparable db to production to test with. My testing systems always seem slow. |
| 13:11 |
dbwells |
Ultimately that's all we did to work around it when bug 1527731 bit us. Not sure what our overall penalty spread for doing that has been, but things are fast enough. |
| 13:11 |
pinesol_green |
Launchpad bug 1527731 in OpenSRF "Query for OPAC copies can be extremely slow" [Undecided,New] https://launchpad.net/bugs/1527731 |
| 13:12 |
Dyrcona |
dbwells: What, exactly, did you set? |
| 13:19 |
dbwells |
Plus, I haven't followed closely whether your issue is intermittent or constant, so maybe it doesn't really apply. |
| 13:20 |
Dyrcona |
dbwells: It seems constant. |
| 13:20 |
Dyrcona |
Or, at least, constant enough. :) |
| 13:22 |
Dyrcona |
I'll try join_collapse_limit on my test db and see if it affects the plan on the slow version of the query. |
| 13:24 |
* dbwells |
tries to read up a bit more |
| 13:25 |
Dyrcona |
I can just "set join_collapse_limit = 9;" right? |
| 13:26 |
dbwells |
I think so. |
| 13:31 |
Dyrcona |
Just stating what I see for the logs, etc. |
| 13:34 |
Dyrcona |
dbwells++ |
| 13:35 |
dbwells |
Another interesting technique I learned recently is using join_collapse_limit = 1 to force the plan to execute the joins in the order given. Doesn't help when the root problem is not being able to control the requested join order at all, but could still come in handy. |
| 13:35 |
Dyrcona |
So, making that change on my test db server dropped the execution time of my "bad" query from 40-41 seconds to 13 milliseconds. |
| 13:35 |
Dyrcona |
dbwells: Yes, I saw that in the docs and in a stackoverflow question. |
| 13:36 |
Dyrcona |
And a mailing list post maybe.... |
| 13:36 |
dbwells |
Yeah, Erwin Brandstetter? Gotta love that guy :) |
| 17:25 |
kmlussier |
Bmagic: Unfortunately, I know very little about collections. |
| 17:26 |
Bmagic |
kmlussier: no problem, I think I just wanted to bounce it around here. I decided to say that "there isn't a way to merge them" - first you have to remove the patron from collections |
| 17:49 |
bshum |
dbwells++ # behind the scenes i18n detective work |
| 18:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:44 |
|
jvwoolf left #evergreen |
| 19:21 |
csharp |
Dyrcona: check auditor.actor_usr_history for the audit_usr for the weird patron edit |
| 19:22 |
Dyrcona |
csharp: I think that was meant for Bmagic. |
| 01:31 |
|
Jillianne joined #evergreen |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:43 |
|
dwgreen joined #evergreen |
| 08:05 |
|
kmlussier joined #evergreen |
| 08:09 |
|
collum joined #evergreen |
| 09:21 |
|
yboston joined #evergreen |
| 09:45 |
|
collum joined #evergreen |
| 09:50 |
csharp |
does webby respect the session timeout YAOUSes? |
| 09:52 |
mmorgan |
csharp: I don't believe I tested in webby explicitly, but see lp 1693035 |
| 09:52 |
pinesol_green |
Launchpad bug 1693035 in Evergreen "Logins not honoring all org unit timeout settings" [Medium,New] https://launchpad.net/bugs/1693035 |
| 09:55 |
csharp |
mmorgan: perfect - thanks! |
| 10:01 |
kmlussier |
csharp: I asked that question in here a few weeks ago. Initially, I was seeing that webby wasn't timing out at all, but the next day, it started to time out based on the YAOUS. |
| 10:02 |
kmlussier |
I didn't investigate further because other things came up. |
| 10:03 |
Dyrcona |
Webby is open. Maybe someone messed with the timeouts? |
| 10:04 |
kmlussier |
Yes, let me correct myself. Not in webby, but in the web client. I did the testing on my own VM, and it wasn't an issue with the settings changing. |
| 10:08 |
csharp |
sorry, yes I was using "webby" to mean "the web client" |
| 10:11 |
kmlussier |
csharp: Dyrcona was speculating that it could be a cache issue when I reported back my results here - http://irc.evergreen-ils.org/evergreen/2017-09-29#i_327518 |
| 10:12 |
kmlussier |
But a couple of days earlier when I first started testing, I believe berick said he noticed it doesn't always work for him. |
| 10:13 |
Dyrcona |
If there are errors rendering a template, where would they show up in the logs, if at all? |
| 10:14 |
berick |
i confirmed one scenario where it fails to log out. if the server is no longer responding, as in the case w/ a temp VM I set up yesterday, it get stuck in the middle of the log out dance. that's an atypical example, but maybe there's something to be learned there. worth looking for JS console errors around the time it should have logged out... |
| 10:15 |
Dyrcona |
Oh, wait! I see the problem. Never mind. |
| 10:40 |
|
mmorgan1 joined #evergreen |
| 10:41 |
csharp |
berick: not that I've seen |
| 10:44 |
csharp |
seeing lots of no_tz.open-ils.storage.actor.user.crazy_search: prepare_cached(SELECT evergreen.unaccent_and_squash(?)) statement handle DBIx::ContextualFetch::st=HASH(0xd55f878) still Active at /usr/local/share/perl/5.18.2/OpenILS/Application/Storage/Publisher/actor.pm line 627. in the osrfwarn log |
| 10:49 |
kmlussier |
berick: I didn't file any mainly because, once I got the timeout the work a couple of days after adding the setting, I didn't continue testing it to determine if my initial problem was indeed a cache issue or if there was a larger problem. |
| 10:51 |
berick |
kmlussier: gotcha. (again, not sure if we need one, just curious) |
| 10:51 |
* berick |
looks at the API issue |
| 10:53 |
jeff |
csharp: and did those insanely high values then cause problems with webby? |
| 11:16 |
|
sandbergja joined #evergreen |
| 11:31 |
Bmagic |
berick: select * from reporter.simple_record where tcn_value = '2468087' results in 4 rows. Perhaps too many rows is the issue? |
| 11:32 |
berick |
Bmagic: do where id = <whatever> |
| 11:32 |
Bmagic |
berick: that can't be right, because I tested one of the barcodes that showed the title in the email and it had 4 rows also |
| 11:33 |
Bmagic |
berick: using the id column to match the record from asset.call_number where call_number is asset.copy.call_number, I still get 4 rows |
| 11:34 |
berick |
ok, yeah, there should only ever be 1 reporter.simple_record entry per bib ID |
| 11:34 |
Bmagic |
strange that the example where the title appeared in the email also has 4 rows |
| 11:41 |
Bmagic |
funny you should ask, I did a presentation 2 years ago showing how we have been addressing duplicate records |
| 11:42 |
Bmagic |
and we have been deduping bre on a regular basis using this 2-step approach |
| 11:43 |
berick |
well i mean multiple occurences of the same bib ID in reporter.materialized_simple_record |
| 11:44 |
Bmagic |
berick: once I started querying rmsr - there is only 1 row per bib (of the two that I tested where one is showing the title and the other is not) |
| 11:45 |
berick |
ok, good. |
| 11:45 |
berick |
that's at leat as it should be |
| 11:45 |
Bmagic |
if there is a row there, then the email should have the title? |
| 15:03 |
miker |
it shouldn't, as the network should be autoflushed, and the send() def happens before the check for max_requests... but it's a lead I'm chasing down |
| 15:03 |
Dyrcona |
dbwells: Variation on the off-by-one error: Taking a count too soon and acting on it. |
| 15:07 |
dbwells |
miker: I am able to recreate the "hang" with enough persistence using open-ils.search.biblio.copy_counts.location.summary.retrieve but it doesn't look like the log message is related, unfortunately. |
| 15:07 |
miker |
:( |
| 15:07 |
miker |
thanks for testing |
| 15:10 |
miker |
dbwells: I was going to say, before, the stderr msg looks like a bug of omission, by not closing a helper statement handle that gets cached somewheres ... seems more likely now, after your test |
| 15:11 |
miker |
so, likely not a failure-causing bug, just noise |
| 15:11 |
dbwells |
yeah |
| 15:16 |
csharp |
this call: CALL: open-ils.search open-ils.search.serial.record.bib.retrieve 5621115, 1, 1 |
| 15:17 |
csharp |
which is made while a record loads, results in a "severe query error" (Empty IN list) |
| 16:13 |
mmorgan |
open-ils.cstore open-ils.cstore.direct.config.usr_setting_type.search.atomic {"name":[]} |
| 16:16 |
dbwells |
miker: Just caught up on reading bug #1704396. Not sure if my issue is even related to the other search hangs, but is sure seems that way. The "good" news is a simple srfsh script with 500 open-ils.search.biblio.copy_counts.location.summary.retrieve calls is enough to reliably trigger this behavior for us, unfortunately only on production. |
| 16:16 |
pinesol_green |
Launchpad bug 1704396 in Evergreen "Slowness for metarecord and one-hit searches in 2.12" [High,Confirmed] https://launchpad.net/bugs/1704396 |
| 16:16 |
dbwells |
miker: so, I should at least be in a somewhat reasonable position to test patches. |
| 16:19 |
dbwells |
miker: I also wonder (without much understanding yet) whether the bug might be in the ".atomic" wrapper. Logs look like storage responds, but search just keeps waiting for it to finish. I might try a quick non-atomic copy of open-ils.search.biblio.copy_counts.location.summary.retrieve just to see if it passes the srfsh test. |
| 16:30 |
|
b_bonner joined #evergreen |
| 16:35 |
|
rlefaive joined #evergreen |
| 16:43 |
dbwells |
Just anecdotal at this point, but "atomic" in the storage call does not seem to be a factor. |
| 17:05 |
miker |
dbwells: thanks! that's one less thing to check early on |
| 17:09 |
|
mmorgan left #evergreen |
| 17:11 |
|
Jillianne joined #evergreen |
| 17:12 |
|
jihpringle joined #evergreen |
| 17:50 |
|
b_bonner left #evergreen |
| 17:54 |
|
Dyrcona joined #evergreen |
| 18:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:23 |
|
phooks joined #evergreen |
| 19:26 |
|
phooka joined #evergreen |
| 19:30 |
phooka |
working on building out new production servers and autogen.sh is erroring out while Updating OrgTree |
| 00:13 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: adding backup information to cli manual - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7ecad6e> |
| 02:27 |
|
kipd joined #evergreen |
| 06:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 08:15 |
|
collum joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 09:01 |
JBoyer |
Or, anyone else with some insider knowledge re: 3.0 search. |
| 09:01 |
JBoyer |
? |
| 09:01 |
|
Dyrcona joined #evergreen |
| 09:05 |
* csharp |
is curious about JBoyer's search concern since we're testing 3.0 right now |
| 09:06 |
JBoyer |
I've found a difference in the queries where staff can't accurately limit to a single location but patrons can. I was hoping to get some background on why. |
| 09:06 |
JBoyer |
Also, has your 3.0 testing turned up anything similar? (or, rather, have you checked?) |
| 09:12 |
csharp |
not that I know of - I can check |
| 09:14 |
mmorgan |
JBoyer: I just did a quick search logged in as a staff user on a 3.0 system, and am also seeing a problem with limiting. |
| 09:15 |
JBoyer |
Ok. So good news, I'm neither crazy* nor running a damaged system. (*At least not for this reason) |
| 11:13 |
miker |
hrm... well, I'm around now |
| 11:15 |
miker |
re the search stuff above, I looked at this last week with an upgraded system and didn't see the behavior. which obv doesn't mean it's not happening, just that something's different |
| 11:19 |
|
mmorgan joined #evergreen |
| 11:19 |
kmlussier |
I see it too on one of my test VMs. |
| 11:30 |
|
rlefaive joined #evergreen |
| 11:46 |
kmlussier |
Never mind. I don't see it on my VM. I was just seeing the standard gray bibs that always come up in a staff search. |
| 11:46 |
* kmlussier |
drinks more coffee. |
| 11:47 |
kmlussier |
This dataset shouldn't have any copy-less bibs, but I guess that's another problem to solve in my spare time on a later date. |
| 12:02 |
|
khuckins joined #evergreen |
| 12:58 |
|
yboston joined #evergreen |
| 12:59 |
|
khuckins joined #evergreen |
| 17:48 |
csharp |
maybe the wrong kind of join in the fieldmapper linkage? (but that probably would result in perl-level errors rather than blank data) |
| 17:54 |
berick |
Bmagic: you've confirmed the bibs in question have reporter.simple_record entries? |
| 17:54 |
berick |
... with titles |
| 18:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 19:04 |
rhamby |
fyi, removing roles of some wordpress accounts for those that haven't been active in 8+ years |
| 19:12 |
csharp |
wow - that bot really was wreaking havoc for us - error/warn logs are very reasonable now |
| 19:12 |
csharp |
@band add Wreaking Havoc |
| 00:41 |
|
Jillianne joined #evergreen |
| 06:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl_ joined #evergreen |
| 08:11 |
|
collum joined #evergreen |
| 08:27 |
|
kmlussier joined #evergreen |
| 09:19 |
|
bos20k joined #evergreen |
| 09:48 |
miker |
jeff / bshum: yes, there's really nothing to maintain -- the introspection stuff is old as the hills and hasn't changed ... ever. there are some issues on the C side that should be cleaned up (the atomic/streaming bool is logically reversed from the perl, signature structure is a little different) however -- but that's opensrf, not docgen |
| 09:49 |
miker |
also, I find it very handy on a dev system on occasion, so I'd like to see it unbroken as well |
| 09:55 |
bshum |
Well, so far in my re-testing of the apache config |
| 09:55 |
bshum |
I think all that's really needed was to add "AddType application/xml .xsl" to the definition |
| 09:55 |
bshum |
I'm not sure if it's an apache 2.4 specific thing |
| 09:56 |
bshum |
I have to retest with a system that's got apache 2.2, but really those should be mostly dead by now :) |
| 09:56 |
miker |
bshum: that looks like it works. 2.2 isn't all the way dead, though |
| 09:56 |
* bshum |
goes back to the archives to try finding a wheezy ISO |
| 09:57 |
bshum |
miker: I know, I'm just living my life on the edge of new :) |
| 10:53 |
bshum |
So apache 2.2 config requires no adjustment and "just works" |
| 10:54 |
miker |
it correctly sees xsl as an xml application ... :) |
| 10:54 |
jeff |
bshum: on apache 2.4, you didn't need the SSI legacy directive? That doesn't mesh with my understanding. |
| 10:54 |
bshum |
jeff: Well I was just testing with the lines one by one, and found that I only needed the one line |
| 10:55 |
miker |
jeff: you do. you need the whole block that the commit removed, plus the line bshum is talking about |
| 10:55 |
miker |
or, that's what worked for me on 2.4 |
| 10:55 |
bshum |
So now I'm not sure why, cause I thought I needed everything too |
| 10:55 |
bshum |
Maybe something got cached... re-tests |
| 10:55 |
jeff |
heh. |
| 10:56 |
jeff |
miker: that's why i was surprised and trying to make sure i understood bshum's statements above. |
| 10:57 |
bshum |
jeff: miker: well.... odd as it seems, when I only add that one line to my eg_vhost.conf definition for the docgen.xsl, the page renders as expected... |
| 16:17 |
|
mmorgan joined #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 17:13 |
|
sandbergja joined #evergreen |
| 18:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:18 |
|
jvwoolf 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 |
| 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 |
