| Time |
Nick |
Message |
| 01:47 |
|
Newziky joined #evergreen |
| 02:27 |
|
dreuther joined #evergreen |
| 02:27 |
|
chatley joined #evergreen |
| 02:34 |
|
dreuther joined #evergreen |
| 02:34 |
|
chatley joined #evergreen |
| 05:02 |
|
dreuther joined #evergreen |
| 05:03 |
|
chatley joined #evergreen |
| 05:08 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:31 |
|
remingtron joined #evergreen |
| 06:02 |
|
rashma_ joined #evergreen |
| 06:22 |
|
gsams joined #evergreen |
| 07:25 |
|
jboyer-isl joined #evergreen |
| 07:26 |
|
graced joined #evergreen |
| 07:48 |
|
mrpeters joined #evergreen |
| 07:58 |
|
collum joined #evergreen |
| 08:05 |
|
rjackson_isl joined #evergreen |
| 08:49 |
|
RoganH joined #evergreen |
| 08:55 |
|
Shae joined #evergreen |
| 09:03 |
|
ericar joined #evergreen |
| 09:07 |
|
Dyrcona joined #evergreen |
| 09:10 |
* jeff |
does the "no longer on 2.5" dance |
| 09:10 |
csharp |
jeff++ |
| 09:11 |
|
tsbere joined #evergreen |
| 09:11 |
* csharp |
does the "trying to build EG debs on 14.04" shuffle |
| 09:12 |
jeff |
ESI++ also |
| 09:12 |
* Dyrcona |
does "the cleanup after OOM killer" twitch. |
| 09:12 |
jeff |
and Callender++ in particular |
| 09:22 |
|
substack left #evergreen |
| 09:28 |
|
yboston joined #evergreen |
| 09:29 |
|
Dyrcona joined #evergreen |
| 09:33 |
dbwells |
bshum: https://bugs.launchpad.net/evergreen/+bug/1443952 |
| 09:33 |
pinesol_green |
Launchpad bug 1443952 in Evergreen 2.8 "Fines can accrue past max (up to double) on lost item return with certain settings" (affected: 1, heat: 6) [High,New] |
| 09:42 |
Dyrcona |
kmlussier: Would you like to test the above on my dev server? |
| 10:06 |
bshum |
dbwells: I'll poke at that again shortly. |
| 10:06 |
bshum |
Trying to see if we found more problems. Got a report that checkin modifiers aren't working now. |
| 10:07 |
bshum |
Specifically clear hold shelf. |
| 10:09 |
bshum |
Ugh, yep, bug |
| 10:10 |
bshum |
It's spawning network errors. |
| 10:13 |
Dyrcona |
So that's on 2.8? |
| 10:13 |
bshum |
Yeah |
| 10:13 |
bshum |
I'm not sure if it's cause of the last round of changes last night. |
| 10:14 |
bshum |
Nobody mentioned it till this morning, but it could be that nobody was using circ modifiers till this morning. |
| 10:14 |
bshum |
Err, checkin modifiers I mean |
| 10:14 |
kmlussier |
Do you want me to test the clear holds shelf on another server? |
| 10:15 |
bshum |
kmlussier: If you don't mind, yeah |
| 10:15 |
kmlussier |
Dyrcona: I don't know if I should test that patch since I never saw the problem behavior. |
| 10:15 |
bshum |
I'm getting a snap of the error |
| 10:15 |
bshum |
It looked mightily unhappy |
| 10:15 |
Dyrcona |
kmlussier: It apparently only happens in master/2.8, so you wouldn't have seen it in the wild. |
| 10:16 |
bshum |
kmlussier: Actually it'd be good to see if you see the error in master or 2.8 before dbwells' refactoring of code |
| 10:16 |
bshum |
From the branch above |
| 10:16 |
bshum |
If it doesn't happen there, then it might be something that got moved around wrong in the code |
| 10:16 |
Dyrcona |
bshum: Under what circumstances do you see the error? |
| 10:16 |
Dyrcona |
I mean the network error with clear holds shelf. |
| 10:17 |
Dyrcona |
Never mind, I found it! |
| 10:18 |
bshum |
Call to [open-ils.circ.checkin] failed for session ... thread trace [1]:\nCan't locate object method \"max_chunk_size\" via package \"OpenSRF::AppSubrequest\" at /usr/local/share/perl/5.14.2/OpenILS/Application/Circ/Holds.pm line 3630. |
| 10:18 |
bshum |
Something like that. (sorry typed that, I hate screenshots) |
| 10:18 |
Dyrcona |
Looks like an OpenSRF problem. |
| 10:18 |
kmlussier |
I found it too. But I suspect Dyrcona and I might be using the same server. :) |
| 10:18 |
bshum |
Yeah, it's not good. |
| 10:18 |
Dyrcona |
Yep, that's what I get. |
| 10:19 |
Dyrcona |
Although, could be something was removed from OpenSRF and Holds.pm was missed when Evergreen was fixed. |
| 10:19 |
bshum |
We didn't change OpenSRF when we upgraded. Since not enough changed for us. |
| 10:19 |
Dyrcona |
bshum: if you bug it, I'll comfirm it. |
| 10:19 |
csharp |
that sub does exist in OpenSRF::AppSession |
| 10:20 |
tsbere |
Doesn't look like OpenSRF changed much in that department |
| 10:20 |
Dyrcona |
Right, but is it in the OpenSRF::AppSubrequest package? |
| 10:21 |
csharp |
nope - AppRequest |
| 10:21 |
Dyrcona |
Well, then, Holds.pm has the bug. |
| 10:21 |
csharp |
OpenSRF::AppRequest |
| 10:22 |
tsbere |
Looks like 4ccbf980e1f2eadf9f99e015e7ac3d4765d046f2 is the likely "added max_chunk_size" commit |
| 10:22 |
pinesol_green |
[evergreen|Mike Rylander] LP#1402797 Hold Shefl: Use max_chunk_size to pass updates in a timely fashion; Notify on the correct array to allow paging back to work - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4ccbf98> |
| 10:22 |
bshum |
http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4ccbf980e1f2eadf9f99e015e7ac3d4765d046f2 |
| 10:22 |
pinesol_green |
[evergreen|Mike Rylander] LP#1402797 Hold Shefl: Use max_chunk_size to pass updates in a timely fashion; Notify on the correct array to allow paging back to work - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4ccbf98> |
| 10:22 |
bshum |
Ah, yeah |
| 10:23 |
bshum |
bug 1402797 |
| 10:23 |
pinesol_green |
Launchpad bug 1402797 in Evergreen "Browser client sprint1 miscellaneous repairs" (affected: 2, heat: 12) [Undecided,New] https://launchpad.net/bugs/1402797 |
| 10:23 |
bshum |
of course... |
| 10:23 |
bshum |
Sigh |
| 10:23 |
bshum |
Well that ain't good |
| 10:23 |
berick |
what version of opensrf you running, bshum? |
| 10:24 |
bshum |
berick: Master as of e8f78636586aeca15632bcfbf0cae20beb2d66a6 |
| 10:24 |
pinesol_green |
[opensrf|Galen Charlton] LP#1002028: set Access-Control-Expose-Headers - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=e8f7863> |
| 10:24 |
bshum |
I didn't apply the last websocket thinko fix, the rest are just README changes |
| 10:25 |
tsbere |
Looks to me like OpenSRF has had the max_chunk_size in the current state for years anyway? |
| 10:25 |
berick |
yeah, been there a while |
| 10:27 |
berick |
ah, ok, so the func probably just needs to be added to OpenSRF::AppSubrequest |
| 10:28 |
berick |
or teach EG to check for the presence of the func before calling it directly |
| 10:30 |
* bshum |
ponders ripping it out for now and seeing if people can at least circ while we think about further solutions. |
| 10:32 |
kmlussier |
Since it came from a web client repair, one would think it wouldn't cause harm to rip it out. |
| 10:32 |
bshum |
That's what I'm thinking. |
| 10:32 |
berick |
it won't hurt to remove it. but it's just as easy to: |
| 10:32 |
* bshum |
tries that first to get his people back on track |
| 10:32 |
berick |
+ $client->max_chunk_size($$params{chunk_size}) if $client->can('max_chunk_size'); |
| 10:34 |
berick |
ok, it's not just as easy, but it's close |
| 10:39 |
bshum |
berick: Alright I can try that. |
| 10:39 |
bshum |
I wonder about the other line additions from that changeset and whether those need modification later. |
| 10:39 |
bshum |
I haven't tested what those other things are yet. |
| 10:40 |
berick |
hm, it is called in a couple of places |
| 10:41 |
berick |
though i doubt any of the others are called in subrequests |
| 10:41 |
Dyrcona |
Well, I can test it and see. |
| 10:43 |
Dyrcona |
Wouldn't hurt to add the if everywhere though. |
| 10:43 |
berick |
agreed |
| 10:46 |
|
RoganH joined #evergreen |
| 11:02 |
bshum |
Whoops |
| 11:02 |
bshum |
$$params is bad |
| 11:03 |
bshum |
And causes things to blow up |
| 11:04 |
Dyrcona |
kmlussier: Did you clear the hold shelf on my dev system? |
| 11:04 |
bshum |
Or hmm |
| 11:04 |
* bshum |
double checks what he's missing here |
| 11:04 |
kmlussier |
Did I clear it? No |
| 11:07 |
Dyrcona |
Well, looks like clear holds shelf in checkin behavior may have changed. |
| 11:08 |
Dyrcona |
I checked in one copy with that modifier, but all of my expired hold shelf items now say they were cleared. |
| 11:08 |
Dyrcona |
Hmm... I wonder if I have a dump old enough. |
| 11:10 |
Dyrcona |
Nope. Can't get those holds back. I'd have to rig something or change locations. |
| 11:21 |
Dyrcona |
Is Clear Holds Shelf supposed to clear the holds when you open the interface? I thought you had to actually do something to clear the holds. |
| 11:22 |
jboyer-isl |
Dyrcona: That sounds familiar, and may be why we recommend staff here not use that feature. Should be an LP on it somewhere... |
| 11:23 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1189980 |
| 11:23 |
pinesol_green |
Launchpad bug 1189980 in Evergreen "Clear Shelf-Expired Holds confirmation needed" (affected: 4, heat: 18) [Wishlist,Confirmed] |
| 11:23 |
jboyer-isl |
Ah, bshum beat me to the paste. :) |
| 11:24 |
bshum |
Dyrcona++ # rescuing me from bad mistakes |
| 11:24 |
bshum |
berick++ # we're testing your fix now |
| 11:24 |
bshum |
I'll get a bug report going on it later this afternoon after I finish writing up after-action reports. |
| 11:27 |
Dyrcona |
I'll add the if statements in the other two places, just in case. |
| 11:28 |
Dyrcona |
I'm not sure how to trigger clear_shelf_cache. |
| 11:33 |
berick |
that's called by the UI after running clear-shelf |
| 11:34 |
|
sandbergja joined #evergreen |
| 11:38 |
Dyrcona |
Well, so far it looks like only the clear holds shelf circ modifier needed the change, but I've added the ifs on all three max_chunk_size calls just to be safe on my dev system. |
| 11:39 |
Dyrcona |
The pull lit and clearing the holds shelf seem to still work. :) |
| 11:40 |
berick |
cool, as expected. Dyrcona++ |
| 12:27 |
|
bmills joined #evergreen |
| 12:33 |
|
Newziky1 joined #evergreen |
| 12:38 |
|
mglass joined #evergreen |
| 12:41 |
|
Dyrcona joined #evergreen |
| 12:42 |
|
mglass_ joined #evergreen |
| 12:44 |
|
mglass__ joined #evergreen |
| 12:47 |
Dyrcona |
I am getting database query errors with browse holds shelf in master. |
| 12:48 |
Bmagic |
delete from action.hold_request where 1=1 That should do it |
| 12:48 |
Dyrcona |
Looks like it retrieved 46 out of 96 clearable holds then the errors start. |
| 12:48 |
|
jihpringle joined #evergreen |
| 12:48 |
Dyrcona |
Don't even need the where. |
| 12:49 |
Bmagic |
I know, lol, just wanted to be more funny |
| 12:49 |
Bmagic |
Anything showing up in the opensrf logs? |
| 12:50 |
Dyrcona |
2015-04-14 12:40:14 EDT STATEMENT: SELECT * FROM money.open_balance_by_owning_lib AS x WHERE 1=0; |
| 12:50 |
Dyrcona |
2015-04-14 12:40:14 EDT ERROR: relation "money.open_circ_balance_by_circ_and_owning_lib" does not exist at character 15 |
| 12:50 |
Dyrcona |
That's from the postgres logs. |
| 12:50 |
csharp |
I've seen that before |
| 12:51 |
Dyrcona |
It may be related to a branch I installed, maybe that rings a bell with dbwells? |
| 12:51 |
jeff |
i think that's an optional view in Open-ILS/src/sql/Pg/example.reporter-extension.sql |
| 12:51 |
Dyrcona |
Although, that might not be it because that is possibly older. |
| 12:51 |
berick |
yeah, looks like a startup error, probably harmless |
| 12:52 |
berick |
(if you're not using the view) |
| 12:52 |
jeff |
yah. there's an IDL entry for rmocbbcol but it's not referenced... so it's not that something's trying to flesh to a class that lacks a view/table. |
| 12:52 |
Dyrcona |
Oh, nice.. Ran out of circ drones. |
| 12:53 |
csharp |
so... has anyone played around with trying to get EG/OpenSRF running within the normal FHS locations (i.e., not /openils)? |
| 12:53 |
tsbere |
Perhaps something reading the IDL is checking "does that exist for me to publish my methods for it?" |
| 12:53 |
berick |
csharp: dbs has |
| 12:53 |
Dyrcona |
Guess I should go with fresher data. |
| 12:53 |
jeff |
tsbere: likely -- as berick said, "looks like a startup error, probably harmless" |
| 12:54 |
Dyrcona |
Well, think my real problem is I ran out of circ drones. |
| 12:54 |
csharp |
I'm interested in what would happen if I moved /openils/conf to /etc/openils or /etc/opensrf and moved the binary files to /usr/bin |
| 12:54 |
Dyrcona |
And, I tried using a not so busy library. |
| 12:54 |
* csharp |
will play with that if he gets the time |
| 12:55 |
csharp |
right now just trying to build a deb the ol' fashioned way |
| 12:55 |
jeff |
csharp: you'd likely find overlooked hardcoded assumptions worthy of bugs :-) |
| 12:55 |
jeff |
(and fixing!) |
| 12:55 |
csharp |
yep |
| 12:56 |
dbwells |
people stop blaming me for stuff! Just kidding, it's actually a pretty good strategy ;) |
| 12:56 |
Dyrcona |
heh. |
| 12:56 |
jeff |
the nice thing is that there are good examples to pattern fixes after, like how sitemap_generator uses "eg_config --sysconfdir" to construct a path to opensrf.xml instead of saying "/openils/conf/opensrf.xml unless otherwise specified on the command line" |
| 12:57 |
Dyrcona |
Sorry, I just have the negative balance branch loaded and wasn't sure if it was something you added.... |
| 12:57 |
jeff |
(sitemap_generator being just the closest example at-hand) |
| 12:58 |
Dyrcona |
csharp: You'll likely end up with a lot more .in files. |
| 12:58 |
Dyrcona |
Well, maybe not a lot, but I'd suspect a few. |
| 13:07 |
|
bmills joined #evergreen |
| 13:10 |
dbs |
csharp: I run EG/OpenSRF in FHS locations on Fedora, I put a bunch of work into patches that were accepted for that purpose a while back |
| 13:11 |
dbs |
just bear in mind that I might have missed lots of scripts that wouldn't get invoked in regular dev/testing workflows that would suddenly become important in production |
| 13:12 |
dbs |
I was hoping that we would cut over to standard FHS locations rather than continuing to document --prefix=/openils but since we've followed the latter path, wouldn't be surprised if more non-relocatable stuff creeps in |
| 13:43 |
csharp |
dbs: great - looks like a good foundation |
| 13:43 |
csharp |
I'll try and get that working on Ubuntu 14.04 and/or Debian jessie |
| 13:45 |
* csharp |
wants the next Debian release to be "lotso" |
| 13:47 |
jeff |
so i'd like to make a minor change to sitemap_generator to exclude the precat bib (bre.id -1) -- "id >= 1", "id >0", "id >-1"? I'm leaning toward "id >= 1" |
| 13:47 |
csharp |
looks like that discussion has been had before, though: https://lists.debian.org/debian-curiosa/2010/07/msg00013.html |
| 13:47 |
jeff |
i'm sure there are a myriad other ways of spelling it in the code already... |
| 13:48 |
bshum |
jeff: I think that seems logical to me. |
| 13:48 |
bshum |
Also there are potentials for negative bib IDs anyways (can't remember what uses it, but I think we go upwards past -45 last I looked) |
| 13:49 |
jeff |
oh? i figured we'd potentially have others in the future, but i'm surprised that you have them now. :-) |
| 13:49 |
bshum |
I can't remember what feature generates those. |
| 13:49 |
bshum |
But something did. |
| 13:49 |
bshum |
They're all deleted now, at least... |
| 13:49 |
bshum |
But they still lurk there. |
| 13:52 |
eeevil |
csharp: not FHS, but it certainly works outside /openils |
| 13:52 |
eeevil |
(from before) |
| 14:12 |
jboyer-isl |
eeevil: does that "not FHS" mean that it currently can't work from /usr/bin, or just that it will work from some other prefix and /usr/bin is uncertain? |
| 14:13 |
jeff |
jboyer-isl: i took his statement to mean that eeevil has experience operating from a non-FHS, non-/openils location. |
| 14:13 |
berick |
jboyer-isl: i think he means he didn't specifically test FHS, but did test other non-/openils options |
| 14:16 |
jboyer-isl |
jeff, berick: makes sense, thanks. |
| 14:19 |
eeevil |
jboyer-isl: there's no reason it won't work under FHS, but I'm using under a set of paths that are non-FHS |
| 14:19 |
eeevil |
what berick said :) |
| 14:20 |
jboyer-isl |
eeevil: that's good to hear. Maybe the next time I go to rebuild a dev server I'll try /usr/bin out and see how it goes. |
| 14:22 |
jeff |
i believe we have gotten staff excited about trying the web staff client for basic patron/circ tasks. not 24 hours since upgrading to 2.7 we have inquiries. :-) |
| 14:22 |
csharp |
jeff: the sign of a smooth upgrade ;-) |
| 14:24 |
berick |
jeff++ |
| 14:26 |
eeevil |
Callender++ |
| 14:26 |
berick |
Callender++ indeed |
| 14:26 |
jeff |
upgrade-wise, i just tested and cherry-picked things beforehand. Callender pulled the trigger in production, and every single contributor helped build a quality release. upgrades keep getting smoother. |
| 14:27 |
jeff |
and yes, i'll repeat my increments from this morning's "no longer on 2.5 dance": ESI++ and Callender++ in particular :-) |
| 14:30 |
|
Newziky1 left #evergreen |
| 14:31 |
jeff |
I think part of it is "lots of development effort focused elsewhere", part of it is "things are a bit more mature/stable", but also a good helping of "intentional efforts to make upgrades less painful" :-) |
| 14:32 |
jeff |
I was surprised at how few external systems/processes needed tweaking as part of the upgrade. Even the number of (immediately required) changes to templates was low. |
| 14:33 |
jeff |
And by low, I think I mean "zero changes required to maintain functionality", though of course we'll be making changes to enable new features, etc. |
| 14:59 |
|
bmills joined #evergreen |
| 15:11 |
|
TaraC joined #evergreen |
| 15:15 |
|
bmills1 joined #evergreen |
| 15:27 |
jeff |
It's gone well enough that I'm putting non-upgrade-related template changes in place (closing pre-upgrade tickets) and experimenting with sitemaps and robots.txt changes. |
| 16:20 |
|
RBecker joined #evergreen |
| 16:27 |
pinesol_green |
[evergreen|Galen Charlton] LP#1442701: prune 'message_id' and 'single' CGI params from TPAC dashboard links - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=07da4e2> |
| 16:29 |
pinesol_green |
[evergreen|Galen Charlton] LP#1442695: install purge_pending_users.srfsh to /openils/bin by default - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=73d671a> |
| 16:30 |
|
sarabee joined #evergreen |
| 16:31 |
pinesol_green |
[evergreen|Dan Wells] LP#1443952 Move overdue restore above lost void/adjustment - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=749e63f> |
| 16:31 |
pinesol_green |
[evergreen|Dan Wells] LP#1443952 Lost fine handling refactor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6b0d8e7> |
| 16:43 |
|
bmills joined #evergreen |
| 16:51 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:39 |
|
mglass joined #evergreen |
| 17:40 |
|
Newziky left #evergreen |
| 18:02 |
|
akilsdonk joined #evergreen |
| 18:02 |
jeffdavis |
anyone able to spare some eyeballs for bug 1429317 ? |
| 18:02 |
pinesol_green |
Launchpad bug 1429317 in Evergreen "Serials in holdings view should be able to sort in ascending and descending order as well as by call number" (affected: 2, heat: 14) [Wishlist,New] https://launchpad.net/bugs/1429317 |
| 18:02 |
|
maryj joined #evergreen |
| 18:24 |
dbwells |
jeffdavis: I'm just about to head home, but I have looked at it a few times. It seems pretty intense, and I have a number of questions about it. |
| 18:26 |
dbwells |
Chief among them: is there a reason we aren't using the existing serial.unit sort_key field to sort? |
| 18:27 |
dbwells |
The sort_key is currently lacking for serials with no enumeration at all, but that would be a very doable enhancement. |
| 18:28 |
dbwells |
I'll try to find some time tomorrow morning to comment on the bug ticket. |
| 18:28 |
ldw |
dbwells: I wrote this code about a year ago, and I was not aware of sort_key at the time. |
| 18:29 |
dbwells |
ldw: back in JSPAC we had a branch which tried to do something similar to this using the sort_key, but it never got integrated, then JSPAC went the way of the dodo. |
| 18:30 |
dbwells |
It generally worked for us, but we never ported it to TPAC, as we generally don't track our serials at the issue-as-copy level. |
| 18:30 |
dbwells |
At least not on the public side. |
| 18:31 |
ldw |
the code in: XXX.schema.rank_serial_copy_by_issuance could be repurposed to populate sort_key if I understand how sort_key is supposed to be used. |
| 18:32 |
dbwells |
I really gotta run, but I will still plan to comment on the bug as soon as possible. |
| 18:33 |
ldw |
I tried to document that function fairly in-depth, but I will admit it was created over a week long nightly process with some other tweaks, and it is complex for me to look at as well. |
| 18:39 |
jeffdavis |
dbwells++ |
| 18:39 |
jeffdavis |
ldw++ |
| 18:39 |
jeffdavis |
thanks! |
| 20:37 |
|
graced joined #evergreen |
| 22:31 |
kmlussier |
@librarian |
| 22:31 |
pinesol_green |
kmlussier: Management:12, Cataloging:15, Acquisitions:15, Reference:16, Circulation:10, Systems:14, Research:11, Custodial:9 |
| 22:47 |
bshum |
@roulette |
| 22:47 |
pinesol_green |
bshum: *click* |
| 23:12 |
kmlussier |
@sortinghat |
| 23:12 |
pinesol_green |
Hmm... kmlussier... Let me see now... RAVENCLAW! |
| 23:14 |
bshum |
Heh |
| 23:14 |
kmlussier |
@sortinghat bshum |
| 23:14 |
pinesol_green |
Hmm... bshum... Let me see now... SLYTHERIN! |
| 23:14 |
kmlussier |
I knew it! |
| 23:24 |
|
RBecker joined #evergreen |
