| Time |
Nick |
Message |
| 01:23 |
|
serflog joined #evergreen |
| 01:23 |
|
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 |
| 03:50 |
|
abowling joined #evergreen |
| 04:34 |
|
jonadab joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:16 |
|
agoben joined #evergreen |
| 07:56 |
|
lualaba joined #evergreen |
| 07:58 |
lualaba |
Hello Team. i have one question. for import marc records from other library, only way is z39.50? if yes, how to configure z39.50 server to give possibility other librarys import my records and i import others? thank you |
| 08:26 |
phasefx |
lualaba: that might be a good question to ask on the mailing list. z39.50 isn't the only way, but it might be the best way, depending on your needs. |
| 08:32 |
|
mmorgan joined #evergreen |
| 08:39 |
|
kmlussier joined #evergreen |
| 08:41 |
Stompro |
Bmagic, there are options to still target even when closed, we are in the same boat, it makes more sense to wait for a closer copy then to page a farther one. I think the new hold targeter allows you to skip the targeting switcharoo (moving between the two closest copies). |
| 09:04 |
|
dteston joined #evergreen |
| 09:12 |
|
Dyrcona joined #evergreen |
| 09:18 |
Bmagic |
Stompro: In this example, it did targeted the copy with the lower proximity dispite it being closed. I think the difference is closed holiday and closed hours |
| 09:19 |
Bmagic |
targeted/target |
| 09:19 |
|
yboston joined #evergreen |
| 09:21 |
Stompro |
Bmagic, I remember finding out about that distinction, that it only considers days in the days closed table, not from the weekly schedule. |
| 09:21 |
Bmagic |
right, in this case, it's a library that is only open Monday through Thursday |
| 09:29 |
Dyrcona |
Stompro Bmagic: That sounds like a bug to me, if that is the case. |
| 09:31 |
csharp |
as far as I know, the hold targeter considers both hours of operation and closings |
| 09:31 |
csharp |
if it didn't work that way here, we would know about it |
| 09:35 |
mmorgan |
So does the targeter respect both Days Closed and Hours Open, but the option to target when closed only consult Days Closed? |
| 09:39 |
csharp |
hmm - maybe I'm wrong - looking at Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Publisher/action.pm I don't see any references to hours of operation (at least using strings 'hour', 'clos', and 'hoo') |
| 09:40 |
Stompro |
csharp, I cannot see any mention of hours... oh you beat me to it. |
| 09:40 |
|
mdriscoll joined #evergreen |
| 09:41 |
csharp |
so I guess that means our libraries don't care that it doesn't :-) |
| 09:42 |
csharp |
btw, if anyone is planning to change that, consider that berick has re-written the hold targeter (which follows existing logic): https://bugs.launchpad.net/evergreen/+bug/1596595 |
| 09:42 |
pinesol_green |
Launchpad bug 1596595 in Evergreen "Hold targeter features and refactoring" [Wishlist,New] |
| 09:42 |
csharp |
we're running it in PINES with no reported problems (after the last patch) |
| 09:43 |
csharp |
just so somebody doesn't invest a lot of time changing Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Publisher/action.pm |
| 09:47 |
Stompro |
It does seem like a bug, but it doesn't effect us since we always want to target even if closed, since we already prioritize targeting order based on number of hours open and transit time. So I'm not inclined to spend time on creating a bug report. |
| 09:48 |
Stompro |
++hold_proximity_adjustments |
| 09:59 |
berick |
i can confirm the targeter does not care about hours of operation |
| 10:00 |
Dyrcona |
And, I some how thought that was the case, actually. Though I might still consider it to be a bug. |
| 10:04 |
* mmorgan |
would tend to agree with Dyrcona |
| 10:04 |
* Dyrcona |
recalls looking into that question in the past couple of years and shrugging it off. |
| 10:05 |
berick |
how often do people set their retarget interval so short that it would make sense to inspect hours of operation? |
| 10:05 |
Dyrcona |
BTW, folks! In addition to fm_IDL.xml, you should make sure that you get the configuration files for your extra software installed properly when setting up a new VM. |
| 10:05 |
Dyrcona |
oils_ncip.xml is apparently important. :) |
| 10:08 |
kmlussier |
:) |
| 10:08 |
mmorgan |
berick: As an example, we have libraries that are always closed on Sundays. Hours of Operation has them "closed" They don't add Sundays in the days closed editor. |
| 10:09 |
berick |
mmorgan: ohh, right, i was not considering all-day closing |
| 10:14 |
kmlussier |
gmcharlt / miker / dbwells: Are we still planning for a point release today? |
| 10:15 |
miker |
kmlussier: checking, but I think a couple of patches are yet to be merged ... and, I've got a fix for a vandelay-via-acq issue on opensrf master (which I think you said you had problems with) when activating a PO |
| 10:17 |
kmlussier |
miker: Any specific patches you want me to look at? The issue I had was related to the bundling / chunking thing, I think. |
| 10:17 |
* kmlussier |
can look at that one. |
| 10:22 |
|
jvwoolf joined #evergreen |
| 10:23 |
kmlussier |
Has anyone running the web client noticed a lot of log bloat? I've found that the two MassLNC VMs that are running the web client run out of space very quickly. I never have any problem on the VMs that are webby free. |
| 10:26 |
kmlussier |
I reduced the log level to 2 last week, but it's still a problem. I suppose I can reduce the log level even further, but that won't be an option for production servers. |
| 10:31 |
kmlussier |
Ah, I see. The earlier bundling / chunking fix only addressed the pull list issue. miker: are you planning to add the vandelay fix to the same branch as the pull list fix? If so, I'll hold off on testing. |
| 10:31 |
csharp |
hmm - I'm curious about the types of messages that are causing that |
| 10:31 |
JBoyer |
kmlussier, can you post some samples somewhere so we can try to see what kinds of messages you're getting and if they can be fixed/toned down? |
| 10:31 |
miker |
kmlussier: I can, if that's easier for you |
| 10:32 |
kmlussier |
miker: Either works for me. I'm not picky. |
| 10:32 |
JBoyer |
csharp, I'm hoping several "use of uninitialized etc." because those are fairly easy to wash away. If it's just super chatty because it makes so many calls that will be harder to clean up. |
| 10:32 |
kmlussier |
JBoyer: Sure, but I just cleared them out this morning. I'll post something later when they've had some time to grow. |
| 10:33 |
JBoyer |
kmlussier++ |
| 10:33 |
miker |
kmlussier: well, it's less work for me to not create a new bug, so I'll add to the same branch :) |
| 10:34 |
kmlussier |
Works for me |
| 10:39 |
kmlussier |
Is anyone actively testing the latest branch at bug 1657237? |
| 10:39 |
pinesol_green |
Launchpad bug 1657237 in Evergreen "Trigger function maintaining hold-target mapping not well constrained" [Critical,Confirmed] https://launchpad.net/bugs/1657237 |
| 10:41 |
miker |
kmlussier: I know of several sites that are actively using it in production ... so, yes? |
| 10:41 |
kmlussier |
miker: I was thinking of somebody who could add a signoff to it. :) |
| 10:42 |
miker |
csharp and JBoyer, maybe? |
| 10:43 |
JBoyer |
Definitely, let me shine up my sign-off pen. |
| 10:46 |
csharp |
works for me too |
| 10:46 |
csharp |
miker++ |
| 10:46 |
csharp |
JBoyer++ # signin' off |
| 10:50 |
|
bos20k joined #evergreen |
| 11:02 |
miker |
kmlussier: branch at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp1657885-alt-pull-list-print updated (this does fix PO activation for some broken cases) |
| 11:02 |
miker |
updating the LP ticket now |
| 11:02 |
kmlussier |
OK, thanks. I'll test it now. |
| 11:03 |
JBoyer |
miker, merge away! It fixed up the migration and dev servers that I had heretofore ignored with no problems. |
| 11:04 |
miker |
JBoyer: thanks! |
| 11:11 |
|
khuckins joined #evergreen |
| 11:13 |
pinesol_green |
[evergreen|Michele Morgan] LP#1659006: Treat the Cost field like the other money fields in the copy editor, - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=72df5dc> |
| 11:20 |
mmorgan |
kmlussier++ |
| 11:21 |
* kmlussier |
works on release notes while waiting for VMs to build. |
| 11:21 |
kmlussier |
mmorgan++ |
| 11:27 |
|
Christineb joined #evergreen |
| 11:28 |
miker |
kmlussier: I'll merge 1657237 now |
| 11:30 |
|
brahmina joined #evergreen |
| 11:33 |
pinesol_green |
[evergreen|Mike Rylander] LP#1657237: Rewrite the hold target cache - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cbe4cae> |
| 11:50 |
|
bmills joined #evergreen |
| 12:13 |
|
sandbergja joined #evergreen |
| 12:22 |
kmlussier |
miker: I noticed when testing Vandelay imports on OpenSRF 2.4, I'm not getting the usual updates on progress. Looking at your comments in the commit, I'm guessing that's expected? |
| 12:22 |
miker |
kmlussier: it is ... does the import succeed? |
| 12:24 |
miker |
kmlussier: I'll see if I can think of a good way to retain the behavior for 2.4 |
| 12:24 |
kmlussier |
miker: Yes, it does. But for a larger one, the progress bar never went away when the import was complete. When importing a smaller set of records, that wasn't a problem. |
| 12:25 |
miker |
kmlussier: gotcha. I'll see what I can do. do updates show up with opensrf master? (or are you not testing that yet?) |
| 12:25 |
kmlussier |
miker: Yes, they do in opensrf master. And they also work in opensrf master, so that's a big improvment. :) |
| 12:26 |
miker |
:) |
| 12:37 |
miker |
kmlussier: the branch is updated ... that should bring back the update stuff for 2.4 |
| 12:46 |
|
jihpringle joined #evergreen |
| 12:47 |
|
lualaba joined #evergreen |
| 12:53 |
kmlussier |
miker: Thanks! I'll take a look. |
| 12:57 |
* Dyrcona |
cheers for a non-Evergreen bug 1380702 |
| 12:57 |
pinesol_green |
Launchpad bug 1380702 in Canonical System Image "No keyboards shortcuts in QT apps" [High,In progress] https://launchpad.net/bugs/1380702 - Assigned to Łukasz Zemczak (sil2100) |
| 13:07 |
|
maryj joined #evergreen |
| 13:13 |
* csharp |
continues to learn that the key to successfully running A/T-based notices is granularity |
| 13:15 |
|
remingtron joined #evergreen |
| 13:44 |
kmlussier |
miker: Looks good, but I'm about to jump on a conference call and won't be able to sign off until later. |
| 13:45 |
miker |
kmlussier: thanks, no worries |
| 13:56 |
|
brahmina joined #evergreen |
| 13:57 |
|
mmorgan1 joined #evergreen |
| 14:50 |
|
jvwoolf joined #evergreen |
| 14:55 |
|
mmorgan joined #evergreen |
| 14:56 |
|
kmlussier joined #evergreen |
| 15:21 |
|
brahmina joined #evergreen |
| 15:24 |
kmlussier |
miker / gmcharlt: Should I backport bug 1657885 to 2.10 or do we assume people on 2.10 will not be running opensrf 2.5? |
| 15:24 |
pinesol_green |
Launchpad bug 1657885 in Evergreen "Alt pull list breaks with the chunking/bundling change in OpenSRF 2.5" [High,Confirmed] https://launchpad.net/bugs/1657885 |
| 15:26 |
Bmagic |
with the new actor.passwd situation, how can I update a password from sql? update actor.passwd set salt=salt('password'); ? |
| 15:28 |
pinesol_green |
[evergreen|Mike Rylander] LP#1657885: Account for new bundling/chunking logic in OpenSRF 2.5+ - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5b9cc11> |
| 15:28 |
pinesol_green |
[evergreen|Mike Rylander] LP#1657885: Inform Vandelay of new chunking/bundling logic - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c7feda1> |
| 15:28 |
pinesol_green |
[evergreen|Mike Rylander] LP#1657885: Inform Vandelay of new chunking/bundling logic, part deux - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ac5e878> |
| 15:29 |
gmcharlt |
kmlussier: my inclination -- don't backport for now to avoid regression |
| 15:30 |
kmlussier |
gmcharlt: OK, thanks. |
| 15:30 |
gmcharlt |
we can evaluate whether we want to _not_ pin EG 2.10.x to OpenSRF 2.4.x, but after today's release |
| 15:34 |
miker |
agreed |
| 15:41 |
Bmagic |
oh found it... actor.set_passwd |
| 15:51 |
|
_adb left #evergreen |
| 15:53 |
berick |
Bmagic: beware calling actor.set_passwd() directly.. |
| 15:53 |
berick |
see how Actor.pm uses the function |
| 15:54 |
Bmagic |
I am looking at that actually |
| 15:54 |
berick |
migrated passwords have an intermediate round of MD5 hashing.. |
| 15:54 |
berick |
great |
| 15:54 |
Bmagic |
can I use postgresql to do the md5 instead of perl? |
| 15:54 |
Bmagic |
md5($salt$$2a$10$aDE0Uy0tylzAQ3vhbTOfyu$salt$||md5($pass$passwordyo$pass$)), |
| 15:54 |
berick |
yeah |
| 15:54 |
Bmagic |
ok good |
| 15:55 |
berick |
see also actor.migrate_passwd |
| 15:55 |
berick |
well, no, that will just confuse things furhter ;) |
| 15:55 |
berick |
you want what Actor.pm uses |
| 15:56 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: Adding release notes for 2.10.9 point release - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c514153> |
| 15:56 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: Adding release notes for 2.11.2 point release - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1c9ac7f> |
| 15:56 |
|
_adb joined #evergreen |
| 15:57 |
Bmagic |
berick++ |
| 15:57 |
Bmagic |
hehe |
| 15:57 |
Bmagic |
pw_usr, 'main', MD5(pw_salt || usr_row.passwd), pw_salt); is the key line fo rme |
| 16:07 |
gmcharlt |
OK, I'm going to start rolling out 2.10.9 |
| 16:10 |
berick |
Bmagic: well,that won't give you exactly what you need :( |
| 16:10 |
berick |
Bmagic: usr_row.passwd in that code is already MD5-hashed |
| 16:10 |
Bmagic |
right, I get it |
| 16:11 |
berick |
ok, cool |
| 16:11 |
berick |
carry on then :) |
| 16:15 |
Bmagic |
:) |
| 16:18 |
pinesol_green |
[evergreen|Galen Charlton] 2.10.8-2.10.9 schema upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f81ed38> |
| 16:19 |
|
jvwoolf left #evergreen |
| 16:33 |
dbwells |
2.11.2 en route |
| 16:37 |
jeff |
Evergreen 2.11.2: "We've taken care of everything" |
| 16:38 |
jeff |
maybe Evergreen 2.11.2: "What can this strange device be?" |
| 16:56 |
berick |
wondering if there is a reason au.created was made a passive trigger. seems like it would be more efficient to create the events from the api as users are created. finally reading bug #1392396 .. |
| 16:56 |
pinesol_green |
Launchpad bug 1392396 in Evergreen "Wishlist: Action Trigger for new user creation" [Wishlist,Fix released] https://launchpad.net/bugs/1392396 |
| 16:59 |
berick |
hah, there is already an 'au.create' even fire in the patron update API |
| 16:59 |
berick |
*event |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:08 |
|
mmorgan left #evergreen |
| 17:23 |
gmcharlt |
I've uploaded 2.10.9 and updated the downloads page |
| 17:23 |
gmcharlt |
I'll check in later this evening for 2.11.2 and to do the release announcement |
| 18:17 |
|
bshum_ joined #evergreen |
| 18:39 |
dbwells |
gmcharlt: 2.11.2 is up; downloads page updated |
| 19:57 |
gmcharlt |
dbwells++ |
