| Time |
Nick |
Message |
| 00:59 |
|
dcook joined #evergreen |
| 02:10 |
|
Mark__T joined #evergreen |
| 03:53 |
|
DPearl joined #evergreen |
| 06:53 |
|
mtj_ joined #evergreen |
| 06:58 |
|
mtj_ joined #evergreen |
| 07:36 |
|
sarabee joined #evergreen |
| 07:44 |
|
rjackson_isl joined #evergreen |
| 07:53 |
|
jboyer-isl joined #evergreen |
| 08:10 |
|
mrpeters joined #evergreen |
| 08:11 |
|
collum joined #evergreen |
| 08:31 |
|
mtj_ joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:41 |
|
Shae joined #evergreen |
| 09:00 |
DPearl |
Question... I'd like to use features in a cpan module (not yet used by EG). Besides the "use" in the perl code, I see that referenced cpan modules are in a list at Open-ILS/src/perlmods/Build.PL. Are there any other places that I should be aware of to ensure that the module is installed on the server during EG install or upgrade time? |
| 09:01 |
|
Dyrcona joined #evergreen |
| 09:01 |
Dyrcona |
Record length of 160129 is larger than the MARC spec allows (99999 bytes). at /usr/share/perl5/MARC/File/USMARC.pm line 314. |
| 09:01 |
Dyrcona |
I think I need to modify my export to report the id numbers of those records. |
| 09:03 |
|
ericar joined #evergreen |
| 09:03 |
|
krvmga joined #evergreen |
| 09:04 |
jeff |
DPearl: If you are creating a new package under the OpenILS namespace, I think you've got it covered with adding it to Open-ILS/src/perlmods/Build.PL. |
| 09:05 |
jeff |
DPearl: if you're just using a module from CPAN, you don't need (or want) to add it to Build.PL, you want to add it to the appropriate Makefile (Makefile.install and its includes) |
| 09:07 |
DPearl |
Jeff: Thanks! |
| 09:07 |
jeff |
DPearl: Open-ILS/src/extras/Makefile.install has reference to the various included makefiles, such as Open-ILS/src/extras/install/Makefile.debian-jessie |
| 09:08 |
DPearl |
jeff++ |
| 09:08 |
jeff |
in that dir, there is also Makefile.common and Makefile.debian -- knowing if a suitable version of your CPAN Perl module is packaged for Debian or not is going to be helpful. |
| 09:10 |
jeff |
If you know that you can get a suitable version of the module via apt-get install, you can probably add that package name to the DEBS variable in Makefile.debian-jessie, etc. |
| 09:15 |
DPearl |
jeff: Hmmm... DateTime::SpanSet is in CPAN, and it is not mentioned in any makefile, but it IS in Build.PL..... What am I not getting? |
| 09:18 |
jeff |
DPearl: dunno. maybe I'm missing something. looking. :-) |
| 09:19 |
jeff |
ah, first off, I was thinking Open-ILS/src/perlmods/MANIFEST and not Open-ILS/src/perlmods/Build.PL |
| 09:19 |
jeff |
so, adjust my earlier statement... |
| 09:19 |
jeff |
DPearl: If you are creating a new package under the OpenILS namespace, I think you've got it covered with adding it to Open-ILS/src/perlmods/MANIFEST |
| 09:19 |
jeff |
:-) |
| 09:20 |
DPearl |
jeff: To narrow things, I'm just using official CPAN Text::Unaccent. |
| 09:21 |
jeff |
DPearl: If you are doing a "use DateTime::SpanSet" or the effective equivalent from within the OpenILS namespace, I'd add DateTime::SpanSet to the requires argument of the Module::Build constructor in Open-ILS/src/perlmods/Build.PL, just as you see for many other modules. |
| 09:21 |
jeff |
and I see you're talking about Text::Unaccent and DateTime::SpanSet is already there. :-) |
| 09:22 |
jeff |
"Dammit Bones, where's that torpedo?" |
| 09:22 |
jeff |
And by torpedo I mean coffee. |
| 09:22 |
* jeff |
sips |
| 09:22 |
jeff |
Alas, I am not cool enough to actually have any friends or co-workers known as "Bones", nor have we named our coffee machine that. |
| 09:23 |
DPearl |
jeff: Thanks for the clarification. Enjoy your coffee! |
| 09:40 |
|
yboston joined #evergreen |
| 10:09 |
csharp |
Could someone on 2.7 though 2.9 please confirm that going to Messages -> Apply Standing Penalty/Message within a patron account results in a pop-up window with a dropdown menu with no entries in the upper right? |
| 10:11 |
bshum |
No entries is usually from not having any custom penalty types. |
| 10:11 |
csharp |
oh? |
| 10:11 |
bshum |
So that's always looked like that I think. |
| 10:11 |
tsbere |
csharp: We get entries in the upper right. But as bshum just said, we have custom penalty types. |
| 10:11 |
csharp |
ah - thank you - I'll look into that |
| 10:12 |
tsbere |
csharp: Specifically, we ensured the default three that show up in there get applied consortia-wide, and then made ones that apply at depth 1 that show up in the dropdown. |
| 10:12 |
csharp |
tsbere: good to know your use case |
| 10:14 |
tsbere |
csharp: Other possibilities are creating additional ones that only block specific things instead of everything. No holds but allow circs otherwise for example. |
| 10:15 |
csharp |
yep, adding a custom penalty now makes that usable |
| 10:15 |
csharp |
I guess it'd probably be better (i.e., less broken looking) to hide that dropdown if there are no custom penalties, but hey, webby's on the way! |
| 10:18 |
bshum |
Dyrcona: I thought you started a patch for that, but if you do make one, I'd love to see it. Identifying those sucky bibs would be nice. |
| 10:20 |
* Dyrcona |
is going through ssh key update hell. Thanks, dbs for pointing out the problems with DSA keys. :) |
| 10:23 |
jeff |
heh |
| 10:27 |
csharp |
hmm - ubuntu 15.04 is still on OpenSSH 6.7 and it looks like 15.10 will have 6.9 |
| 10:27 |
csharp |
so maybe 16.04 will have the new version |
| 10:28 |
Dyrcona |
Well, DSA keys are theoretically crackable. |
| 10:28 |
Dyrcona |
And OpenSSH's ECDSA implementation only supports the standard curves that looks suspicious for NSA back doors. |
| 10:28 |
csharp |
Dyrcona: I'll second bshum's interest in your reporting the ID of long-enough-to-be-invalid-MARC records ;-) |
| 10:29 |
Dyrcona |
I though about using ED25519, but didn't want to be the black sheep. ;) |
| 10:29 |
csharp |
oh, so this is not just a "new version of SSH is requiring something new" issue |
| 10:29 |
* csharp |
asks the Goog about it |
| 10:31 |
Dyrcona |
This turned out to be something that was taking too long to script, so I'm replacing my keys by hand. |
| 10:36 |
|
jwoodard joined #evergreen |
| 10:47 |
|
TaraC joined #evergreen |
| 11:00 |
Dyrcona |
I don't recommend changing ssh keys unless you have to. |
| 11:00 |
Dyrcona |
It's a pain. |
| 11:00 |
|
jwoodard joined #evergreen |
| 11:08 |
Dyrcona |
Well, that's fun. |
| 11:35 |
|
krvmga joined #evergreen |
| 11:50 |
|
Christineb joined #evergreen |
| 11:52 |
kmlussier |
@weather 02771 |
| 11:52 |
pinesol_green |
kmlussier: Seekonk, MA :: Rain :: 74F/23C | Wednesday: Cloudy with showers. High 76F. Winds SW at 15 to 25 mph. Chance of rain 70%. Localized flooding is possible. Wednesday Night: Showers early, then cloudy overnight. Low near 50F. Winds N at 10 to 15 mph. Chance of rain 60%. |
| 11:53 |
|
bmills joined #evergreen |
| 11:53 |
csharp |
@weather 32459 |
| 11:53 |
pinesol_green |
csharp: Santa Rosa Beach, FL :: Overcast :: 78F/26C | Wednesday: Variable clouds with scattered thunderstorms. High near 85F. Winds NW at 5 to 10 mph. Chance of rain 50%. Wednesday Night: Scattered thunderstorms during the evening. Mainly clear skies after midnight. Low 67F. Winds N at 5 to 10 mph. Chance of rain 40%. |
| 11:53 |
csharp |
gonna be there tomorrow - long-delayed beach vacation ;-) |
| 12:01 |
|
kitteh_ joined #evergreen |
| 12:10 |
|
bmills joined #evergreen |
| 12:23 |
|
ericar joined #evergreen |
| 12:27 |
Dyrcona |
@weather 01845 |
| 12:27 |
pinesol_green |
Dyrcona: North Andover, MA :: Overcast :: 76F/24C | Wednesday: Rain. High 73F. Winds WNW at 10 to 15 mph. Chance of rain 60%. Localized flooding is possible. Wednesday Night: Showers early, then cloudy overnight. Low 49F. Winds N at 10 to 15 mph. Chance of rain 30%. |
| 12:28 |
berick |
@weather Eye-of-Joaquin |
| 12:28 |
pinesol_green |
berick: Error: I could not find a valid location for: Eye-of-Joaquin |
| 13:37 |
|
serflog joined #evergreen |
| 13:37 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 13:38 |
bshum |
jeff: If I select multiple entries, some "In process" and others "checked out" I can't edit the status field |
| 13:38 |
bshum |
So, that doesn't seem to be it. |
| 13:38 |
jboyer-isl |
Dyrcona: Oof, I’m assuming that’s Pan |
| 13:38 |
* bshum |
tries from item status though |
| 13:38 |
jboyer-isl |
’s, which I have not seen. |
| 13:38 |
bshum |
I tried it from the patron's checkout items out list |
| 13:38 |
jboyer-isl |
Google IS is not kind. |
| 13:38 |
bshum |
Which is where the library claims they did it |
| 13:39 |
|
ericar joined #evergreen |
| 13:39 |
jboyer-isl |
bshum: can you see teh change in your auditing tables, or has it been cleared away? |
| 13:39 |
bshum |
jboyer-isl: It is in the audit table yes. |
| 13:39 |
bshum |
And it shows up as NULL for audit user and ws |
| 13:39 |
jboyer-isl |
Still have logs for the time period? |
| 13:39 |
bshum |
So that wasn't a good clue unfortunately |
| 13:39 |
jboyer-isl |
(It gives you a time) |
| 13:40 |
bshum |
I have the timestamp, yes. |
| 13:40 |
bshum |
So I was about to go log diving to see what the command calls were |
| 13:40 |
jeff |
still working on those VNC-based flight recorders for circ desk terminals. |
| 13:40 |
jeff |
:P |
| 13:41 |
bshum |
Heh, indeed. |
| 13:46 |
* bshum |
sets the items back to a status of 1 for now and will pursue the mystery a little later. |
| 13:46 |
Dyrcona |
Pretty bad when the rain is so loud, you can't hear your music. |
| 13:48 |
Dyrcona |
dbs: Hear your music you cannnot. When rain so loud is. :) |
| 13:50 |
bshum |
I'm really not sure why the bots went away. |
| 13:50 |
bshum |
I know freenode has been doing some user cleanup lately, and they ban kicked even me the other day for no apparent reason. |
| 13:50 |
bshum |
I didn't see anything in the logs |
| 13:51 |
bshum |
@eightball Should I stay or should I go? |
| 13:51 |
pinesol_green |
bshum: No clue. |
| 13:52 |
Dyrcona |
@eightball Do you know which clothes even fit me? |
| 13:52 |
pinesol_green |
Dyrcona: What are you asking me for? |
| 13:53 |
Dyrcona |
Well, the rain beats the construction noises in the other part of the offices. |
| 13:58 |
|
jlitrell joined #evergreen |
| 14:00 |
|
kitteh_ joined #evergreen |
| 14:00 |
Dyrcona |
So many places to update ssh keys... |
| 14:02 |
Dyrcona |
csharp: I based my statements about ssh keys earlier from reading this stackexchange conversation and some of the linked articles: http://security.stackexchange.com/questions/5096/rsa-vs-dsa-for-ssh-authentication-keys |
| 14:09 |
Dyrcona |
Mostly... ;) |
| 14:19 |
Bmagic |
I have a copy level hold in hold_request and the copy is available. It's not getting targeted. The copy is holdable, the shelf it's on is holdable. However, they are both set to opac_visible=false. The only thing different is that it was frozen and thawed 9-14, not sure if that matters. |
| 14:19 |
Bmagic |
Anyone have similar troubles? |
| 14:19 |
bshum |
Bmagic: Is the patron a good one? |
| 14:19 |
bshum |
i.e. is there any blocks preventing hold capture |
| 14:20 |
Bmagic |
good question, I didn't check that |
| 14:20 |
bshum |
Invisible items may still be targeted by the hold targeter all other things being equal, as far as I know anyways. |
| 14:20 |
bshum |
So that shouldn't be the issue. |
| 14:21 |
Bmagic |
no blocks |
| 14:21 |
bshum |
When you say "was frozen" that means it's not frozen now right? |
| 14:21 |
bshum |
Having a thaw date alone isn't enough |
| 14:21 |
Bmagic |
it's not frozen now, it was thawed 9-14 |
| 14:21 |
bshum |
You have to actually run the script to flip the hold |
| 14:21 |
bshum |
Hmm, okay |
| 14:22 |
Bmagic |
I have prev_check_time up to date. It has been checked every day and still not targeted |
| 14:22 |
bshum |
Was the copy always available? Maybe the hold copy map is broken, and you have to reset the hold with "find another target"? |
| 14:22 |
Bmagic |
ill check the hold map |
| 14:22 |
bshum |
If the hold map doesn't contain the copy, even though it's a copy hold, it won't ever target, obviously. |
| 14:22 |
csharp |
Dyrcona: thanks - looking now |
| 14:23 |
Bmagic |
the map has the copy |
| 14:24 |
Bmagic |
I played around in srf shell trying to simulate the hold targeter for just this one hold, but I can't seem to get it to only do this one |
| 14:24 |
Bmagic |
request open-ils.storage open-ils.storage.action.hold_request.copy_targeter { "client" : null , "check_expire" : true, "one_hold" : 370938 } |
| 14:26 |
Dyrcona |
Bmagic: For copy holds, the copy status, copy, and copy location all have to be holdable. |
| 14:26 |
Dyrcona |
And the copy not deleted, of course. |
| 14:27 |
Bmagic |
Dyrcona: All of those things are holdable |
| 14:28 |
Dyrcona |
Are any of the org_units involved closed? |
| 14:28 |
bshum |
Oh good point |
| 14:28 |
Dyrcona |
That will also stop it. |
| 14:28 |
bshum |
I always forget about the closed dates |
| 14:28 |
Bmagic |
hmm, let me check that out |
| 14:30 |
jboyer-isl |
There’s also an aou setting that says “Skip me,” but if the whole location was not targeting holds that would stand out. |
| 14:30 |
Bmagic |
no, the copy has been attempted to be targeted since 9-14, and during that time, there hasn't been a closed day for the org units |
| 14:31 |
Dyrcona |
Could be that OpenILS::Utils::PermitHold::permit_copy_hold is failing. |
| 14:31 |
Bmagic |
perhaps if I could get the srf shell to focus this one hold, I could analyze the logs |
| 14:36 |
berick |
you can target a specific hold via srfsh |
| 14:36 |
Bmagic |
berick: right, I've been trying and failing to do so |
| 14:37 |
Bmagic |
I pasted my syntax above ^^ |
| 14:37 |
Dyrcona |
Bmagic: request open-ils.storage open-ils.storage.action.hold_request.copy_targeter "", 370938 |
| 14:37 |
Dyrcona |
The hold id is it's own argument. |
| 14:38 |
Bmagic |
well, that was easy! |
| 14:38 |
Dyrcona |
The "" takes the place of your argument hash. |
| 14:38 |
Dyrcona |
You can add more hold ids. |
| 14:38 |
Bmagic |
"found_copy":null, "eligible_copies":1 |
| 14:39 |
Dyrcona |
I get the same on my test hold, but I think that's because the old target is the only valid target. |
| 14:40 |
Dyrcona |
Could be you need some options in the hash. |
| 14:40 |
Bmagic |
I think I need to back date the prev_check_date ? |
| 14:42 |
Dyrcona |
Bmagic: request open-ils.storage open-ils.storage.action.hold_request.copy_targeter {"check_expire":true, "one_hold":true, "find_copy":true}, 370938 |
| 14:42 |
Dyrcona |
You probably only need the find_copy argument. |
| 14:43 |
Bmagic |
Dyrcona: Still didnt target the copy, but we are getting close, I have some logs |
| 14:44 |
Dyrcona |
Actually looks like find_copy takes a copy id. |
| 14:44 |
Bmagic |
max_org_unit_target_loops |
| 14:44 |
bshum |
That sounds like a setting. |
| 14:44 |
Dyrcona |
Well, I was wondering about that earlier and also the various proximity things being done. |
| 14:45 |
Bmagic |
max_org_unit_target_loops isn't set so that cant be it |
| 14:45 |
Bmagic |
Im having trouble understanding the logs |
| 14:46 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "Failing to target copy level hold" (58 lines) at http://paste.evergreen-ils.org/13 |
| 14:47 |
Bmagic |
Recall threshold was not set; bailing out on hold 370938 processing. ?? |
| 14:48 |
bshum |
Well, more so, the log line that matters is "There were no targetable copies for the hold" |
| 14:48 |
jeff |
What is the value of hold_type for hold id 370938? |
| 14:48 |
Bmagic |
'C' |
| 14:50 |
jeff |
Okay, I see the logic there now. |
| 14:50 |
bshum |
Based on the description for http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c403d6bb543625fa235b78300b890047c9a99559 |
| 14:50 |
pinesol_green |
[evergreen|dbs] Initial support for recall of items triggered by placing a hold - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c403d6b> |
| 14:50 |
bshum |
"When a hold is placed and no available copies are found by the hold targeter, |
| 14:50 |
bshum |
the recall logic checks to see if the recall threshold and return interval |
| 14:50 |
bshum |
settings are set" |
| 14:50 |
bshum |
So, I suspect that recall thing is unrelated, Bmagic |
| 14:50 |
Bmagic |
I see |
| 14:50 |
Bmagic |
Im going to check out the results of this fuction "action.hold_retarget_permit_test","182","182","1771746","192089","242420" |
| 14:50 |
bshum |
Something is causing the item not to appear to be targetable. |
| 14:51 |
bshum |
It could be rules. |
| 14:51 |
jboyer-isl |
That message is referring to bailing out of the process_recall function only. (next statement is just return;_ |
| 14:51 |
jboyer-isl |
) |
| 14:51 |
Dyrcona |
yep. |
| 14:51 |
Bmagic |
so, that fails |
| 14:51 |
Bmagic |
so, there is a hold rule blocking it? |
| 14:51 |
bshum |
So maybe the hold was created while the rules allowed it, but then afterwards, rules changed |
| 14:52 |
bshum |
And it fails |
| 14:52 |
bshum |
Like maybe the item had a different circ mod that was holdable at first, then changed by the lib to something else that isn't holdable |
| 14:52 |
Bmagic |
I was wondering, cause the hold shouldnt have been able to make it into action.hold_request in the first place? |
| 14:53 |
bshum |
It can happen. |
| 14:53 |
Dyrcona |
Depends on how and when the hold was placed. |
| 14:53 |
Dyrcona |
Recall and Force holds bypass a lot of the rules. |
| 14:54 |
jboyer-isl |
There’s also the “Place unfillable hold” permission. Bmagic, change the name of that function to action.find_holds_matrix_matchpoint and you can see what rule caused it to fail. |
| 14:54 |
jeff |
copy level holds used to (and may still) have a few ways that they can be placed which result in unintentionally unfillable holds. |
| 14:54 |
jeff |
especially if the hold was staff-placed. |
| 14:54 |
bshum |
Dyrcona: Don't recall and force holds come up with R or F? Not C? |
| 14:54 |
jeff |
i think some/all of those may have been fixed. |
| 14:54 |
Dyrcona |
Yes, they do. |
| 14:54 |
tsbere |
and R and F don't check the hold rules *at all* anymore anyway |
| 14:55 |
Dyrcona |
tsbere: is also correct. So if it were still a R or F hold, it would target. |
| 14:57 |
Bmagic |
Thanks guys |
| 14:57 |
Bmagic |
I think it's coming together now |
| 14:57 |
Bmagic |
I didnt realize that it checked the rules again after the hold was placed, that makes sense |
| 15:05 |
Bmagic |
Dyrcona++ bshum++ jeff++ jboyer-isl++ #thanks again for helping me figure out that brain buster, what a relief |
| 15:07 |
bshum |
"I say we take off and nuke the entire site from orbit. It's the only way to be sure." |
| 15:16 |
dbs |
Dyrcona++ |
| 15:32 |
Stompro |
Is there any documentation out there on the "Patron Requests" "Patron account -> other -> acquisiion requests" feature. I can find a heading in the 2.1 docs, but nothing recent. |
| 15:36 |
csharp |
Stompro: it probably hasn't changed since 2.1 |
| 15:36 |
|
gmcharlt joined #evergreen |
| 15:36 |
Stompro |
csharp, there is only a heading in the 2.1 docs, no actual documentation. |
| 15:36 |
csharp |
I see :-/ |
| 15:36 |
jwoodard |
well that was a learning experience Dyrcona++ bshum++ jeff++ jboyer-isl++ |
| 15:38 |
csharp |
Stompro: bug 1268054 |
| 15:38 |
pinesol_green |
Launchpad bug 1268054 in Evergreen "Documentation needed for Acquisitions-->Patron Requests" [Wishlist,Triaged] https://launchpad.net/bugs/1268054 |
| 15:38 |
csharp |
Stompro: bug 985075 gives some insight for what's intended |
| 15:38 |
pinesol_green |
Launchpad bug 985075 in Evergreen 2.4 "acquisition request on behalf of patron will not save" [Medium,Fix released] https://launchpad.net/bugs/985075 |
| 15:40 |
csharp |
Stompro: http://screencast.com/t/IctEX5UoF (from Sally's comment on that bug) shows it in action (though not working as expected, hence the bug report) |
| 15:51 |
Stompro |
Thanks csharp, that helps me understand it. There doesn't seem to be a web based form for customers to send in their own requests. Or maybe I just haven't found it yet. |
| 15:53 |
csharp |
Stompro: from the relevant part of http://wiki.evergreen-ils.org/lib/exe/fetch.php?media=the_acquisitions_module_ev.pdf, it looks like something on the OPAC side was an intended feature that wasn't ready for 2.0 - maybe it got dropped along the way |
| 16:00 |
Stompro |
csharp, thanks for finding all this good stuff. csharp++ |
| 16:07 |
csharp |
Stompro: happy to assist! |
| 16:14 |
dbs |
argh nullability strikes again argh! |
| 16:16 |
|
rlefaive joined #evergreen |
| 16:42 |
miker |
dbs: shall I kill nullability with the webstaff template rewrite? ;) |
| 16:45 |
|
bmills joined #evergreen |
| 16:45 |
tsbere |
miker: Kill the ability to make templates with that disabled. Please. ;) |
| 16:45 |
miker |
heh |
| 17:16 |
|
mmorgan left #evergreen |
| 17:29 |
|
jihpringle_ joined #evergreen |
| 18:30 |
|
jihpringle_ joined #evergreen |
| 18:49 |
|
jihpringle joined #evergreen |
| 20:59 |
kmlussier |
@sortinghat |
| 20:59 |
pinesol_green |
Hmm... kmlussier... Let me see now... RAVENCLAW! |
| 21:02 |
|
geoffsams joined #evergreen |
| 21:12 |
|
parsleyfirefly joined #evergreen |
