| Time |
Nick |
Message |
| 02:33 |
|
geoffsams joined #evergreen |
| 04:26 |
|
dbwells_ joined #evergreen |
| 07:15 |
|
Callender joined #evergreen |
| 07:33 |
|
rjackson_isl joined #evergreen |
| 07:46 |
|
Stompro joined #evergreen |
| 07:51 |
|
JBoyer joined #evergreen |
| 08:20 |
|
Dyrcona joined #evergreen |
| 08:22 |
Dyrcona |
pinesol_green: Got any laters for me? |
| 08:22 |
pinesol_green |
Dyrcona: Have you confirmed your ISBN SPIDs with your service provider? |
| 08:22 |
pinesol_green |
Dyrcona: I am only a bot, please don't think I'm intelligent :) |
| 08:25 |
kmlussier |
Dyrcona: No laters, but gmcharlt mentioned last night that collab/gmcharlt/webstaff-sprint2-sprint3-round2 is ready for testing. |
| 08:36 |
Dyrcona |
OK. Looks like i use the round2 branch. |
| 08:37 |
|
mrpeters joined #evergreen |
| 08:38 |
jeff |
and we have reached the point in the morning where i wish i had a rolling packet capture on all SIP2 traffic. |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:44 |
Dyrcona |
jeff: the logged messages are not enough? |
| 08:44 |
jeff |
nope! |
| 08:44 |
Dyrcona |
jeff: Just ask the NSA. ;) |
| 08:45 |
Dyrcona |
a belated gmcharlt++ |
| 08:46 |
Dyrcona |
Oh, look at that, kernel security updates. |
| 08:46 |
Dyrcona |
I'll make sure Evergreen is working on my dev vm, then install the updates, and restart it. |
| 08:50 |
|
jwoodard joined #evergreen |
| 08:58 |
kmlussier |
@coin |
| 08:58 |
pinesol_green |
kmlussier: heads |
| 08:59 |
csharp |
blame [coin] |
| 08:59 |
csharp |
@blame [coin] |
| 08:59 |
pinesol_green |
csharp: It's all tails's fault! |
| 09:01 |
Dyrcona |
csharp++ |
| 09:04 |
|
jihpringle joined #evergreen |
| 09:11 |
JBoyer |
csharp: since you've been having db issues, have your users noticed any extreme delays in the Record Summary loading for titles with 100+ copies? |
| 09:11 |
JBoyer |
I've seen a couple that are taking multiple minutes... |
| 09:15 |
* Dyrcona |
wonders if we have any of those titles with 100+ copies. |
| 09:18 |
Dyrcona |
Yes, we do. |
| 09:18 |
* Dyrcona |
has a look. |
| 09:20 |
Dyrcona |
Refresh my memory: This problem is mainly with Pg 9.3? |
| 09:20 |
JBoyer |
Dyrcona: Appreciate it. I'm hoping to find some rhyme/reason. |
| 09:21 |
JBoyer |
The problem is that we changed Eg versions (2.7 -> 2.9) AND Pg versions (9.1 -> 9.3) |
| 09:21 |
JBoyer |
It's also possible that PINES is having unrelated issues with 9.4 that we wouldn't see on 9.3. |
| 09:22 |
Dyrcona |
I just tried one with 218 current holds on 113 total copies and it loads pretty quick both in production and development. |
| 09:22 |
Dyrcona |
I'll try one with 600+ copies next. |
| 09:23 |
Dyrcona |
I'm doing a numeric search for the TCN in the OPAC. |
| 09:25 |
JBoyer |
Dyrcona: The issue I'm seeing is only in the client, the Record Summary bar at the top (with the Actions for this Record menu) loads extremely slowly. The OPAC view itself is fine and fast. |
| 09:25 |
JBoyer |
Which is even more frustrating. |
| 09:25 |
|
maryj joined #evergreen |
| 09:28 |
Dyrcona |
JBoyer: I switched to the staff client and I'm not seeing it being extraordinarily slow. |
| 09:28 |
Dyrcona |
The one with 688 copies did take a noticeable amount of time to load the summary, but something on the order of two to three seconds, not minutes. |
| 09:28 |
JBoyer |
What Pg version are you on? |
| 09:28 |
Dyrcona |
9.3 |
| 09:29 |
JBoyer |
Curses. |
| 09:29 |
JBoyer |
I probably have some tuning params out of whack. Time to poke about. :-/ |
| 09:29 |
JBoyer |
It is nice to have identical dev hardware though, hopefully that makes this less shot-in-the-dark. |
| 09:30 |
csharp |
JBoyer: I haven't heard that specific complaint |
| 09:31 |
csharp |
btw, after more tweaks from miker, we had no issues at all yesterday |
| 09:31 |
JBoyer |
Excellent to hear! |
| 09:31 |
csharp |
if today is trouble-free, we're considering it good-to-go |
| 09:31 |
Dyrcona |
JBoyer: It could be a missing index or you might have missed a fix for mvf/cra to speed up one of the views. |
| 09:31 |
JBoyer |
Dyrcona++ # thanks for checking. |
| 09:31 |
JBoyer |
csharp++ |
| 09:31 |
JBoyer |
miker++ |
| 09:33 |
JBoyer |
Dyrcona: I've done a check against stock for really missing indexes and we're ok there, that's not to say there shouldn't be a new one, but I'm not seeing any queries that reference these bib ids taking over 300ms... |
| 09:33 |
JBoyer |
I'll keep looking though. |
| 09:36 |
JBoyer |
Ah. Of course things aren't consistent. One that takes ages on production comes up in under 10 seconds on dev, because no one uses dev... |
| 09:37 |
|
yboston joined #evergreen |
| 09:37 |
|
JBoyer joined #evergreen |
| 10:01 |
|
RoganH joined #evergreen |
| 10:43 |
|
pmurray_away joined #evergreen |
| 11:03 |
* csharp |
is rudely reminded of clark's new statement-timeout parameter when several monthly reports are killed when they exceed 1 hour (the default) |
| 11:10 |
|
Christineb joined #evergreen |
| 11:11 |
jeff |
impressive run time. |
| 11:17 |
RoganH |
o.O what are they trying to get reports of? |
| 11:18 |
RoganH |
Makes me have flashbacks back to when staff crashed the reporter at least once a week, 2011-ish. |
| 11:20 |
JBoyer |
Hah, "Sales Team: Before submitting, be sure to refresh TOC and delete this note." Ever the optimist, that one. |
| 11:23 |
RoganH |
JBoyer: at least it didn't say "make sure you fleece those suckers" |
| 11:25 |
JBoyer |
RoganH++ # Having read the rest, that appears to go without saying. |
| 11:32 |
|
mmorgan left #evergreen |
| 11:41 |
|
pmurray_away joined #evergreen |
| 11:42 |
|
pmurray joined #evergreen |
| 11:43 |
|
pmurray left #evergreen |
| 11:56 |
Dyrcona |
I get the following with grunt build: |
| 11:56 |
Dyrcona |
Running "cssmin:combine" (cssmin) task |
| 11:56 |
Dyrcona |
>> Destination not written because minified CSS was empty. |
| 11:57 |
Dyrcona |
bower EMALFORMED Failed to read /home/opensrf/Evergreen/Open-ILS/web/js/ui/default/staff/bower.json |
| 11:57 |
Dyrcona |
Ah ha! |
| 11:57 |
Dyrcona |
Something botched with a merge conflict, I bet. |
| 12:00 |
Dyrcona |
Fix one error, find another. ;) |
| 12:03 |
kmlussier |
Dyrcona++ |
| 12:03 |
Dyrcona |
kmlussier++ |
| 12:03 |
Dyrcona |
And now, it is lunch time. |
| 12:04 |
Dyrcona |
I chose the "wrong" line when resolving a conflict and so a , was missing. |
| 12:07 |
Dyrcona |
chieffancypants, huh? :) |
| 12:29 |
|
vlewis joined #evergreen |
| 12:32 |
|
mmorgan joined #evergreen |
| 12:41 |
|
bmills joined #evergreen |
| 13:01 |
* jwoodard |
saw "Duras" as an authority record |
| 13:01 |
* jwoodard |
was disappointed to find the author was french |
| 13:06 |
Dyrcona |
jwoodard: Marguerite Duras? |
| 13:16 |
|
dbs joined #evergreen |
| 13:17 |
|
gmcharlt joined #evergreen |
| 13:18 |
|
gmcharlt joined #evergreen |
| 13:21 |
jeffdavis |
jwoodard: as opposed to Klingon? |
| 13:21 |
Dyrcona |
heh |
| 13:24 |
bshum |
@quote get 49 |
| 13:24 |
pinesol_green |
bshum: Quote #49: "<bshum> I've never trusted Klingons, and I never will. I can never forgive them for the death of my boy." (added by Dyrcona at 05:02 PM, April 03, 2013) |
| 13:24 |
bshum |
Apparently I say that a lot. |
| 13:24 |
bshum |
Or so google tells me |
| 13:52 |
|
vlewis_ joined #evergreen |
| 14:05 |
|
gmcharlt_ joined #evergreen |
| 14:07 |
|
csharp_ joined #evergreen |
| 14:10 |
|
mnsri_ joined #evergreen |
| 14:15 |
|
_bott_ joined #evergreen |
| 14:31 |
geoffsams |
I have a question regarding the setting "Delete volume with last copy" |
| 14:31 |
geoffsams |
when this setting is set to true, would it then work on any currently empty volumes? |
| 14:33 |
Dyrcona |
gsams: No it does not. You'll have to find them and delete them yourself. |
| 14:33 |
gsams |
Dyrcona: I had a feeling that'd be the case, thanks for the info! |
| 14:33 |
Dyrcona |
It works when deleting the last copy on a call number/volume. |
| 14:33 |
tsbere |
gsams: Also, I don't think it works if the volume is emptied by anything other than a delete. Say, "transfer copy to marked volume" on the last copy... |
| 14:33 |
gsams |
Dyrcona++ |
| 14:34 |
gsams |
tsbere: ah, that's also good to know. I'll keep that in mind! |
| 14:34 |
gsams |
tsbere++ |
| 14:34 |
tsbere |
gsams: Also, not all empty call numbers should be removed. Some may be there for URI purposes, so be careful if batch deleting. |
| 14:34 |
* tsbere |
is willing to dig up some of the code MVLC uses for that cleanup, though |
| 14:35 |
gsams |
tsbere: That'd be pretty great actually, because it looks like I have a heck of a task ahead of me |
| 14:36 |
RoganH |
gsmas: it's not that bad. I do it annually in a batch with other things and it's pretty straightforward. |
| 14:37 |
tsbere |
gsams: I think this may actually be reasonably up to date: http://pastebin.com/b7cuAEAe |
| 14:37 |
tsbere |
May need some adjusting for you as I hardcoded a bib source or two in the bibs sans call numbers query |
| 14:38 |
* tsbere |
has that (and some other things) running nightly for MVLC, though I think we have upped the period variable to 90 days instead of 30 |
| 14:39 |
kmlussier |
gsams: I just checked. Transferring items to volumes will delete the volume too if it's left empty. |
| 14:40 |
gsams |
kmlussier++ #I appreciate the quick test! |
| 14:40 |
|
jlitrell joined #evergreen |
| 14:40 |
kmlussier |
gsams: I just happened to be in holdings maintenance when you asked the question. :) |
| 14:41 |
tsbere |
I know empty volumes still crop up for us. Probably from failed creates and other things. |
| 14:43 |
* jeff |
tries to sort out his feelings for call numbers like "DVD AVE RATED PG-13" |
| 14:43 |
Bmagic_ |
yeah, lol |
| 14:44 |
|
RoganH_ joined #evergreen |
| 14:46 |
kmlussier |
OK, everything looks okay on Dyrcona's test system. I think I'm ready to merge the sprint2/sprint 3 branch |
| 14:47 |
kmlussier |
Thank you, cat, for hitting the Enter key before I was done. |
| 14:47 |
tsbere |
kmlussier: The cat apparently thought it was a good place to stop. |
| 14:47 |
kmlussier |
Does the branch need an LP bug before I merge it? |
| 14:48 |
kmlussier |
tsbere: Yeah, he then hit All Caps afterwards, which is why it took me a while to pose my next question. |
| 14:48 |
|
yboston_ joined #evergreen |
| 14:49 |
Dyrcona |
I don't think LP bugs are required, but I'll defer to the consensus of the other devs. |
| 14:51 |
|
jlitrell joined #evergreen |
| 14:59 |
kmlussier |
@love quickpick |
| 14:59 |
pinesol_green |
kmlussier: The operation succeeded. kmlussier loves quickpick. |
| 15:04 |
|
csharp joined #evergreen |
| 15:06 |
kmlussier |
Oh, so the hotkeys branch is in the main sprint2/3 branch? I won't have to merge that separately then. |
| 15:06 |
Dyrcona |
It is? I didn't think it was. |
| 15:07 |
Dyrcona |
I merged it in mine before adding round2, but it may have skipped those commits. |
| 15:07 |
|
collum joined #evergreen |
| 15:08 |
kmlussier |
Dyrcona: Yeah, I didn't realize it was there either. But I noticed it as I was scanning through the commits |
| 15:10 |
Dyrcona |
Yes, it is and it's very small. |
| 15:10 |
Dyrcona |
It's the line that I had the conflict with that I didn't resolve correctly. |
| 15:11 |
kmlussier |
Your branch is ahead of 'origin/master' by 141 commits. :) |
| 15:13 |
Dyrcona |
:) |
| 15:25 |
csharp |
hmm 1) Edit -> Alert Message 2) Messages -> Apply Standing Penalty/Note 3) Other -> Notes -> Add New Note and 4) Message Center |
| 15:25 |
Stompro |
Has anyone ever experienced an error using the "Show More Copies" button in the catalog with a larger number of copies. Our consumer reports 2015 record has 200+ copies and the "Show More Copies" link results in a "An internal server error occurred. Please try again later." |
| 15:25 |
csharp |
I think I'd like to see fewer notes interfaces! |
| 15:25 |
csharp |
Stompro: have you dug out the log message that corresponds with that error? |
| 15:26 |
tsbere |
csharp: I agree, but they each have different pros/cons/intents. <_< |
| 15:27 |
csharp |
tsbere: yeah, off the top of my head, I think we should build on the message center to handle all/most use cases and dump the others, but I want to think on it some more before filing a wishlist bug |
| 15:27 |
csharp |
I also haven't used the web client enough to see what's coming ;-) |
| 15:28 |
tsbere |
csharp: I am not sure I fully agree. Maybe the Other->Notes interface, but standing penalties are a different story. |
| 15:28 |
* tsbere |
has no real feelings on the continued existence of the "Alert Message" field on patrons |
| 15:28 |
csharp |
yeah - that's why I want to ponder it some more |
| 15:29 |
Dyrcona |
Stompro: Not I. (I just tried with a magazine that has 688 copies.) |
| 15:29 |
csharp |
the reason I'm even looking at it is that a library here realized that their notes aren't visible outside their OU and vice-versa |
| 15:29 |
tsbere |
That can be a pro and a con at the same time. |
| 15:30 |
csharp |
and we at the system office realized the same thing recently regarding "in collections" penalties |
| 15:30 |
Dyrcona |
Stompro: How many copies does your Show More Copies go to? Ours goes from 10 to 50, but I'm not sure if that's configurable. |
| 15:30 |
csharp |
well, in PINES, the assumption is that all of us can see everything |
| 15:30 |
tsbere |
MVLC ended up adjusting some of the standing penalty depths and added a few new ones for staff |
| 15:30 |
csharp |
and that's obviously not what the feature was built to accommodate |
| 15:31 |
csharp |
yeah, I'll play with that in the short term |
| 15:31 |
tsbere |
csharp: If you want standing penalties to generally be at the top level then set the depths to 0. I think that will generally work across the board. |
| 15:31 |
csharp |
tsbere: cool - I'll do some testing |
| 15:31 |
tsbere |
We set many of them that way, if you want to poke me on some of that |
| 15:31 |
csharp |
thanks! |
| 15:32 |
tsbere |
We also have some "System-level" versions that staff can set for more local issues (blocking another library's patron from their library, for example) |
| 15:32 |
jeff |
keep in mind that you'll need to update existing rows in actor.usr_standing_penalty where you have adjusted depths. |
| 15:32 |
tsbere |
There is that |
| 15:32 |
tsbere |
Though for "set them all to 1" it wouldn't be that hard |
| 15:33 |
* jeff |
nods |
| 15:33 |
jeff |
just don't expect that you can change config.standing_penalty and see the effects on existing user penalties. :-) |
| 15:33 |
jeff |
(this isn't one of those things) |
| 15:34 |
jeff |
changes to config.standing_penalty.org_depth will only affect new penalties (and possibly recalculated ones -- i haven't looked at that recently) |
| 15:35 |
tsbere |
jeff: I think recalculated ones may actually end up with a "delete and re-create" because of OU mis-match... |
| 15:35 |
tsbere |
Either that or messing with the depth may cause issues, anything based on penalty thresholds should probably have the org_depth left null. |
| 15:35 |
tsbere |
csharp: ^^^^ |
| 15:44 |
|
gmcharlt joined #evergreen |
| 15:46 |
Stompro |
dyrcona, ours also tries to show 50 more... I played around with it and the most I can display for the record in question is 17/18. I wonder if there is a 15 second timeout, the error seems to come up around 15 seconds after the request is made. I see a "Apache2::RequestIO::print: (32) Broken pipe" error in the logs. |
| 15:46 |
Dyrcona |
Stompro: Does this happen for any other titles with that many copies or just this one? |
| 15:47 |
Dyrcona |
Stompro: Yeah, broken pipe after 15 seconds sounds like something unexpectedly closed a connection. |
| 15:47 |
Dyrcona |
Given that it is print, I'd assume the browser to be at fault, but I could be wrong. |
| 15:47 |
jeff |
@who in the library catalog with the broken pipe |
| 15:47 |
pinesol_green |
kitteh__ in the library catalog with the broken pipe. |
| 15:51 |
Dyrcona |
Stompro: It could also be unrelated..... |
| 15:56 |
Stompro |
Dyrcona, Tried 3 other records with >100 copies and saw the same issue. |
| 15:58 |
Dyrcona |
Stompro: Have you checked the opensrf logs for messages related to the bib id? There might be some clues in the message chains there. |
| 16:15 |
bshum |
Parts, bleh |
| 16:16 |
kmlussier |
bshum: You aren't even working with Evergreen anymore?. How is it that parts are still troubling you? |
| 16:16 |
Dyrcona |
Stompro's record has parts apparently. |
| 16:16 |
bshum |
No, just looking at Stompro's example. It's a bib with all part copies |
| 16:16 |
Dyrcona |
The records that I looked at don't have parts. |
| 16:19 |
kmlussier |
Ah, in that case. I know a catalog I can check to see if the same thing occurs. |
| 16:20 |
kmlussier |
It's always bothered me that we have a "Next 10" link along with a "shore more copies" link. |
| 16:21 |
miker |
I'm pretty sure there's a speed issue with "mono parts used as serial issuances" ... they're not designed for that, so I'm not surprised that doesn't work well TBH |
| 16:22 |
kmlussier |
Stompro: No, I'm not seeing that problem either. I was checking here. http://bark.cwmars.org/eg/opac/record/140910 |
| 16:23 |
kmlussier |
If you count Stompro's library, it's the 3rd Evergreen site I'm aware of that is using parts to handles serials. |
| 16:24 |
kmlussier |
The issue is that there is a lot of overhead involved in using serials. When you're a small library with a small collection of popular magazines, it's not worth it. |
| 16:25 |
kmlussier |
The speed issue isn't just related to loading the record. In my search timings, I noticed that the consumer reports search was particularly slow for those sites that use parts for serials. |
| 16:27 |
kmlussier |
I've always thought it would be nice to have a way for non-serials libraries to somehow attach a copy to an issuance that was created by another library. Which, now that I think about it, doesn't make sense since issuances are owned by specific OUs. |
| 16:28 |
miker |
the issue (heh) here is that there are 2 cataloging concepts: monograph works with a bounded set of multiple parts; serial (continuing resource) works with a (potentially unbounded) series of issuances ... |
| 16:29 |
miker |
each cataloging concept starts from certain assumptions, from a cataloging point of view. so the backing software is based on those concepts and assumptions |
| 16:30 |
* kmlussier |
nods. |
| 16:30 |
miker |
it sounds like what's needed is a simpler workflow for continuing resource managements, so that the cataloging is correct |
| 16:30 |
miker |
and, therefore, the correct backing code is used for the shape of the real data |
| 16:32 |
kmlussier |
Yeah, the workflow is a big thing, but the other advantage of using parts is the ability to place holds on the same part from multiple libraries. Issuance holds are restricted to the one library. |
| 16:32 |
jeff |
kmlussier: they are? |
| 16:32 |
miker |
kmlussier: but the "subscription" object, and therefore the issuances, can be owned anywhere |
| 16:32 |
kmlussier |
But it's not as big as the workflow issue. You're never going to get our smaller libraries to set up prediction patterns. |
| 16:32 |
jeff |
we're not using issuance holds in production, so i can't claim anything other than naive surprise. :-) |
| 16:32 |
miker |
you could certainly have a CONS-wide "People magazine" |
| 16:33 |
miker |
and all the small libraries add distributions and streams to that |
| 16:33 |
kmlussier |
hmmm...I thought we tried doing a CONS-wide subscription at one point. I can't remember what the problem was with it. It would have been back in the early days when we were migrating. |
| 16:33 |
dbwells |
Yes, I would agree that the subscription should ideally be set as high in the org tree as cooperation will allow. |
| 16:33 |
miker |
and "receive" items there, and then make units as needed |
| 16:34 |
kmlussier |
It's certainly in idea I can play with. In my spare time. |
| 16:34 |
jeff |
i can see the wishlist bug now... metasubscription holds |
| 16:34 |
kmlussier |
s/in/an |
| 16:34 |
jeff |
or would that be metaissuance holds? :-) |
| 16:34 |
miker |
I think we'd still need to expose the issuance for the unit, in a way similar to parts, in the unit display |
| 16:35 |
miker |
dbwells: or, is that already exposed? I don't recall |
| 16:35 |
miker |
jeff: HUSH |
| 16:35 |
miker |
;) |
| 16:36 |
dbwells |
miker: Yes, works great... in JSPAC :( Maybe a good hackfest project to get it out in more places. |
| 16:36 |
miker |
dbwells: HA! ... yeah. that and peer bibs. |
| 16:38 |
miker |
(and search range) |
| 16:38 |
* miker |
ducks |
| 16:42 |
* miker |
disappears |
| 17:04 |
|
rlefaive joined #evergreen |
| 17:14 |
Stompro |
kmlussier, what EG version is bark.cwmars.org running? It does look like it works fine there, with close to 4000 copies. |
| 17:15 |
kmlussier |
They're on 2.8 |
| 17:17 |
Bmagic_ |
I could have swore this was a reported bug on LP: void lost item fee at checkin leaves the transaction open when there are no other fines on the transaction and the bill is $0 as a result of the void. It fails to set xact_finish ? |
| 17:18 |
|
Bmagic joined #evergreen |
| 19:38 |
|
bmills joined #evergreen |
| 23:01 |
|
dcook joined #evergreen |
| 23:12 |
kmlussier |
@sortinghat |
| 23:12 |
pinesol_green |
Hmm... kmlussier... Let me see now... RAVENCLAW! |
| 23:23 |
pinesol_green |
Showing latest 5 of 142 commits to Evergreen... |
| 23:28 |
kmlussier |
hmmm... |
| 23:28 |
kmlussier |
Is that leftover from the merge I did earlier today? |
| 23:39 |
pinesol_green |
[evergreen|Yamil Suarez] Docs: small leveloffset fix for root.txt - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aea2ddd> |
