| Time |
Nick |
Message |
| 01:05 |
|
Stompro joined #evergreen |
| 04:52 |
|
rangi joined #evergreen |
| 04:52 |
|
rangi joined #evergreen |
| 04:52 |
|
jonadab joined #evergreen |
| 04:52 |
|
jeffdavis joined #evergreen |
| 04:53 |
|
phasefx joined #evergreen |
| 04:53 |
|
eady joined #evergreen |
| 04:53 |
|
RBecker joined #evergreen |
| 04:54 |
|
hopkinsju joined #evergreen |
| 04:54 |
|
Bmagic joined #evergreen |
| 04:54 |
|
dluch joined #evergreen |
| 05:02 |
|
eby joined #evergreen |
| 05:03 |
|
rangi joined #evergreen |
| 05:03 |
|
rangi joined #evergreen |
| 05:08 |
|
jonadab joined #evergreen |
| 05:08 |
|
tsbere joined #evergreen |
| 05:10 |
|
pmurray joined #evergreen |
| 05:49 |
|
bwicksall joined #evergreen |
| 05:49 |
|
jvwoolf joined #evergreen |
| 05:49 |
|
dbwells joined #evergreen |
| 05:51 |
|
mtj_ joined #evergreen |
| 05:52 |
|
jeff___ joined #evergreen |
| 05:53 |
|
akilsdonk joined #evergreen |
| 06:04 |
|
berick joined #evergreen |
| 06:05 |
|
gmcharlt joined #evergreen |
| 06:05 |
|
egbuilder joined #evergreen |
| 06:05 |
|
Stompro joined #evergreen |
| 06:08 |
|
eby joined #evergreen |
| 06:41 |
|
phasefx_ joined #evergreen |
| 06:43 |
|
dkyle joined #evergreen |
| 06:44 |
|
rlefaive joined #evergreen |
| 06:46 |
|
eady joined #evergreen |
| 06:50 |
|
pmurray joined #evergreen |
| 06:50 |
|
egbuilder joined #evergreen |
| 06:50 |
|
jvwoolf joined #evergreen |
| 06:51 |
|
dcook joined #evergreen |
| 06:51 |
|
remingtron joined #evergreen |
| 06:51 |
|
gsams joined #evergreen |
| 06:55 |
|
jeffdavis joined #evergreen |
| 07:00 |
|
serflog joined #evergreen |
| 07:00 |
|
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 |
| 07:02 |
|
pinesol_green joined #evergreen |
| 07:03 |
|
akilsdonk joined #evergreen |
| 07:04 |
|
miker joined #evergreen |
| 07:04 |
|
Callender joined #evergreen |
| 07:04 |
|
b_bonner joined #evergreen |
| 07:04 |
|
rashma joined #evergreen |
| 07:07 |
|
rashma_away joined #evergreen |
| 07:07 |
|
b_bonner joined #evergreen |
| 07:25 |
|
bshum joined #evergreen |
| 07:25 |
|
dbs joined #evergreen |
| 07:25 |
|
kmlussier joined #evergreen |
| 07:25 |
|
csharp joined #evergreen |
| 07:25 |
|
mceraso joined #evergreen |
| 07:25 |
|
_bott_ joined #evergreen |
| 07:25 |
|
sandbergja joined #evergreen |
| 07:26 |
|
rangi joined #evergreen |
| 07:26 |
|
rangi joined #evergreen |
| 07:26 |
|
graced joined #evergreen |
| 07:26 |
|
sarabee joined #evergreen |
| 07:30 |
|
rjackson_isl joined #evergreen |
| 07:33 |
|
dbwells joined #evergreen |
| 07:33 |
|
jonadab joined #evergreen |
| 07:33 |
|
Bmagic joined #evergreen |
| 07:33 |
|
hopkinsju joined #evergreen |
| 07:33 |
|
dluch joined #evergreen |
| 07:37 |
|
book` joined #evergreen |
| 07:47 |
|
artunit_away joined #evergreen |
| 07:55 |
|
Stompro joined #evergreen |
| 07:58 |
|
eby joined #evergreen |
| 08:02 |
|
JBoyer joined #evergreen |
| 08:08 |
|
jvwoolf left #evergreen |
| 08:19 |
|
collum joined #evergreen |
| 08:28 |
|
rjackson_isl joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:59 |
|
csharp joined #evergreen |
| 09:27 |
|
Dyrcona joined #evergreen |
| 09:37 |
|
mllewellyn joined #evergreen |
| 09:47 |
|
pmurray joined #evergreen |
| 09:49 |
|
yboston joined #evergreen |
| 09:56 |
Dyrcona |
jeff: Do you want to make a branch to fix the fork bug in OpenSRF, or should I? |
| 09:57 |
Dyrcona |
jeff: Also this should go on Launchpad if it isn't there already. |
| 09:57 |
|
pmurray left #evergreen |
| 09:58 |
* Dyrcona |
looks at lp 1544606 before starting on release cutting. |
| 09:58 |
pinesol_green |
Launchpad bug 1544606 in Evergreen "tpac translations broken in 2.9" [High,Confirmed] https://launchpad.net/bugs/1544606 |
| 10:09 |
|
mrpeters joined #evergreen |
| 10:24 |
Dyrcona |
kmlussier && anyone else who uses it: my regular development vm is being shut down and a new concerto vm will take its place. |
| 10:24 |
Dyrcona |
I'll be testing leading up to a 2.9.2 release. |
| 10:28 |
Dyrcona |
Hrm.... Maybe I need to fix our training/development db server first.... |
| 10:32 |
|
abowling joined #evergreen |
| 10:36 |
Dyrcona |
Looks like it ran out of free disk space last night. |
| 10:41 |
|
mrpeters joined #evergreen |
| 10:44 |
jeff |
disk space, ram... a server craves [a lot] these things. |
| 10:47 |
Dyrcona |
jeff++ |
| 10:48 |
Dyrcona |
So, think it was the full ingest i left running last night. |
| 10:48 |
tsbere |
Running 4 or more copies of production data in a lesser DB server tends to use a lot of disk space. <_< |
| 10:48 |
Dyrcona |
Dropped my database and freed up 100GB of disk space. |
| 10:48 |
Dyrcona |
tsbere++ |
| 10:50 |
* gmcharlt |
claims 0952 in the name of Truth, Justice, and the Ruritanian Way! |
| 11:12 |
|
collum joined #evergreen |
| 11:14 |
Dyrcona |
First time I've had a vm build fail because of package hash sum mismatches. Must have been an update in the mean time? |
| 11:14 |
pinesol_green |
Showing latest 5 of 6 commits to Evergreen... |
| 11:14 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1067823 Add genre facet by default and remove tag 659 from definition - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5744d8a> |
| 11:15 |
pinesol_green |
[evergreen|Galen Charlton] LP#1067823: add release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d51a6b0> |
| 11:15 |
pinesol_green |
[evergreen|Galen Charlton] LP#1067823: follow-up: add back a space - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=efc9db5> |
| 11:15 |
pinesol_green |
[evergreen|Galen Charlton] LP#1067823: tweak new identifier|genre index - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8107995> |
| 11:15 |
pinesol_green |
[evergreen|Mike Rylander] LP#1067823: Genre links launch subject search - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c064522> |
| 11:41 |
|
bmills joined #evergreen |
| 11:44 |
kmlussier |
Dyrcona / berick: I'm just getting started on point release notes now. I should have those done shortly. |
| 11:44 |
Dyrcona |
kmlussier++ |
| 11:45 |
Dyrcona |
I'm still working on testing bshum's i18n fixes for tpac/webstaff. |
| 11:45 |
berick |
kmlussier++ |
| 11:45 |
Dyrcona |
I ran into an unexpected delay with our second database server. |
| 11:45 |
|
jwoodard joined #evergreen |
| 11:46 |
Dyrcona |
I want to get the branch that affects 2.9 before releasing the tarball today. |
| 11:48 |
dbs |
RFID question: if you're not using PV Supa equipment, does the RFID reader effectively work the same as an optical barcode scanner? |
| 11:50 |
dbs |
that is, just delivers a set of digits like a virtual keyboard? |
| 11:51 |
|
Christineb joined #evergreen |
| 11:53 |
jeff |
the ones i have seen work like a software shim keyboard wedge. |
| 11:53 |
jeff |
the 3M software targets a window by window name (not pattern!) |
| 11:54 |
jeff |
and it will switch to that window if not already active, and it will blindly type digits and a return. |
| 11:54 |
jeff |
by default, two returns -- which will work fine in most interfaces but will trigger an error if you have async checkin enabled. :-) |
| 11:56 |
jeff |
you can adjust inter-barcode delay and i think even inter-digit delay. |
| 11:57 |
dbs |
jeff: okay, that's helpful. targeting a window by window name is a bit weird but okay :) |
| 11:58 |
jeff |
yeah, it has its ups and downs. |
| 11:59 |
JBoyer |
I think at least Bibliotheca/ITG's software will do partial matches on window names. (doesn't auto-focus though, it just tries to avoid dumping digits randomly) |
| 12:01 |
dbs |
Okay. I'll ask the vendors for this RFP to describe how their readers work then |
| 12:01 |
dbs |
Is anyone using RFID tags + optical barcodes (where the barcodes are the same, just providing optical fallback at locations without RFID readers)? |
| 12:02 |
* dbs |
assumes so, but is "ass u me" wary |
| 12:05 |
kmlussier |
The fix for bug 1519925 says it is for MARC federated search (which I always think of as an acq interface), but appears to really be for the Z39.50 interface. Am I right on that? |
| 12:05 |
pinesol_green |
Launchpad bug 1519925 in Evergreen 2.9 "Add UPC search to MARC Federated Search - Native Evergreen option" [Medium,Fix committed] https://launchpad.net/bugs/1519925 |
| 12:06 |
|
vlewis joined #evergreen |
| 12:07 |
jeff |
dbs: when we started using RFID, we did not move away from our existing barcode practices -- two barcodes on each item, one on the outside, one on the inside. the RFID tag is programmed with the barcode value. |
| 12:08 |
jeff |
dbs: because RFID tags get torn off or get damaged or just fail. also, you don't want to be in the position of "every place where we might deal with an item gets an expensive RFID reader, otherwise people type in barcodes by hand" |
| 12:09 |
dbs |
jeff: cool. So our belt-and-suspenders (but actually "we don't have enough $$$ to get RFID equipment everywhere") thoughts are sane. |
| 12:09 |
dbs |
jeff++ |
| 12:09 |
jeff |
dbs: better to be in the position of being able to use barcode scanners on those computers/tablets/whatever where you don't have an RFID reader |
| 12:16 |
kmlussier |
Or maybe it affects both. |
| 12:17 |
jeff |
JBoyer: i look forward to some future day when the 3M software is replaced/upgraded by their new Bibliotheca ITG owners and grows partial-window-match capabilities. :-) |
| 12:25 |
|
jihpringle joined #evergreen |
| 12:26 |
gmcharlt |
kmlussier: should affect both |
| 12:27 |
kmlussier |
gmcharlt: OK, thanks! |
| 12:27 |
kmlussier |
Now I get to figure out if it goes in the acq or cataloging section of the point release notes. |
| 12:30 |
* kmlussier |
goes with the bold move of combining the two categories. |
| 12:32 |
gmcharlt |
:) |
| 12:32 |
gmcharlt |
Tech Services? |
| 12:35 |
|
Christineb joined #evergreen |
| 12:40 |
|
ericar joined #evergreen |
| 12:40 |
kmlussier |
Dyrcona: The translation bug you're looking at only applies to 2.9, right? |
| 12:41 |
Dyrcona |
kmlussier: That is correct. It will go into master too, though. |
| 12:41 |
Dyrcona |
It does not affect 2.8. |
| 12:41 |
kmlussier |
Thanks! |
| 12:48 |
|
eby joined #evergreen |
| 12:56 |
csharp |
Dyrcona: have you done any experimentation with Ubuntu 16.04? I built a VM last night and got immediately stymied by the lack of apache2-mpm-prefork in 16.04 - I'm researching why that package doesn't exist anymore... |
| 12:57 |
Dyrcona |
csharp: I have not tried 16.04 yet. |
| 12:58 |
csharp |
Dyrcona: I'll let you know how it goes (assuming you're interested ;-) ) |
| 12:58 |
Dyrcona |
I have heard rumors that a threaded mpm is actually more efficient on GNU/Linux. |
| 12:58 |
Dyrcona |
Yes, I am interested. |
| 12:58 |
csharp |
cool |
| 13:00 |
Dyrcona |
I have been thinking of building a 16.04 vm, but missing tuits.... |
| 13:05 |
berick |
can't use threaded mpm w/ opensrf |
| 13:05 |
berick |
it's not threadsafe |
| 13:06 |
berick |
more to the point, it's not opening a separate xmpp connection per thread, which is what it would require. |
| 13:11 |
berick |
moving all API communication to websockets would make it more attainable, but i bet there are other thread safety issues to contend with at a higher level, e.g. in the mod_perl code. |
| 13:12 |
Dyrcona |
Yep, could be. |
| 13:22 |
Dyrcona |
bshum (if you're around): It looks like the staff client translations are not getting installed with your branch on lp 1544606. |
| 13:22 |
pinesol_green |
Launchpad bug 1544606 in Evergreen "tpac translations broken in 2.9" [High,Confirmed] https://launchpad.net/bugs/1544606 |
| 13:22 |
Dyrcona |
I'll see if I can figure out why and fix it. |
| 13:24 |
Dyrcona |
Actually, if you're expecting translations in /openils/var/data/locale, nothing ends up in there. |
| 13:29 |
jeff |
Dyrcona: bug 1546683 |
| 13:29 |
pinesol_green |
Launchpad bug 1546683 in OpenSRF "fork() failure results in Perl service Listeners becoming Drones" [Undecided,New] https://launchpad.net/bugs/1546683 |
| 13:29 |
Dyrcona |
jeff++ |
| 13:37 |
jeff |
csharp: apache2-mpm-prefork has been a transitional package for a while now. It was finally removed, so we should probably adjust the pre-req makefiles. |
| 13:37 |
jeff |
csharp: if you stop trying to install that package, do things in general still work? |
| 13:38 |
JBoyer |
dbs: It's a little late now, but when my previous library went RFID they stopped buying barcodes and instead printed the barcodes on the tags. Don't do that. |
| 13:38 |
jeff |
i.e., do you have an mpm prefork module installed and such? |
| 13:39 |
jeff |
csharp: on jessie, /usr/lib/apache2/modules/mod_mpm_worker.so is supplied by the apache2-bin package |
| 13:39 |
jeff |
(which is installed when you install just straight up "apache2") |
| 13:39 |
dbs |
JBoyer: yeah, that seems like an expensive option |
| 13:40 |
Dyrcona |
bshum and I sorted out the locale installation issue. |
| 13:40 |
berick |
still have a dev meeting today, yeah? |
| 13:41 |
Dyrcona |
It's on the calendar, yes. |
| 13:42 |
jeff |
csharp: as of Debian Jessie (8) and Ubuntu Trusty (14.04), apache2-mpm-prefork is just a dummy transitional package. As you've found, it's gone completely in 16.04 / Xenial. |
| 13:50 |
|
justdoglet joined #evergreen |
| 13:52 |
berick |
yikes, I never pushed a 2_8_5 tag branch. fortunately, still have the original. |
| 14:14 |
Dyrcona |
I've got some automobile-related stuff going on and the rest of my day is very likely wrecked. |
| 14:19 |
Dyrcona |
I will push bshum's i18n fixes though. |
| 14:20 |
kmlussier |
Dyrcona: Are you ready for the release notes now? Or should I hold off? |
| 14:20 |
Dyrcona |
kmlussier: I won't be adding anything else to 2.9, so go ahead. |
| 14:20 |
kmlussier |
okie dokie |
| 14:21 |
pinesol_green |
Showing latest 5 of 6 commits to Evergreen... |
| 14:21 |
pinesol_green |
[evergreen|Ben Shum] LP#1544606: Change i18n Makefile so that there are different dirs for opac vs webstaff - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=18e4313> |
| 14:21 |
pinesol_green |
[evergreen|Ben Shum] LP#1544606: Change docs to more specific locale/opac location - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=344032d> |
| 14:21 |
pinesol_green |
[evergreen|Ben Shum] LP#1544606: Change apache examples for TPAC to more specific locale/opac location - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=36fa29f> |
| 14:21 |
pinesol_green |
[evergreen|Ben Shum] LP#1544606: Change static entry to variable in config example for locale/staff - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9250622> |
| 14:21 |
pinesol_green |
[evergreen|Ben Shum] LP#1544606: Remove trailing whitespace from sample configs for locale/staff - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b4d59a4> |
| 14:26 |
Dyrcona |
"Latest" is not exactly latest....It excluded the topmost commit and included the bottom-most. |
| 14:39 |
pinesol_green |
[evergreen|Kathy Lussier] Adding 2.9.2 bug fixes and acknowledgements to the 2.9 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b6b0af4> |
| 14:39 |
pinesol_green |
[evergreen|Kathy Lussier] Adding 2.8.6 bug fixes to the 2.8 Release Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0524f5e> |
| 14:42 |
|
jvwoolf1 joined #evergreen |
| 14:42 |
kmlussier |
Ugh. Forgot an acknowledgement. Sigh... |
| 14:44 |
|
bmills joined #evergreen |
| 14:45 |
pinesol_green |
[evergreen|Kathy Lussier] Forgot an acknowledgement in the 2.9.2 point release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fb65ec1> |
| 14:48 |
Stompro |
Hello all, Holds question for you all. I've been under the impression that a hold would keep targeting the same copy until that copy was checked in or became unavailable. But now I think I was wrong about that. It looks like the hold targeter excludes the current copy unless the current copy is the only copy left that is holdable. Is that correct? |
| 14:48 |
|
DPearl joined #evergreen |
| 14:55 |
tsbere |
Stompro: Yes, but that doesn't stop it from bouncing between two copies. |
| 14:56 |
Stompro |
tsbere, Thanks, that is what we are seeing, and since we are using the stalling feature, we just had one branch with 20 items that wouldn't check in because they were retargeted between the time the pull list was run and the items were checked in. |
| 15:01 |
|
jlitrell joined #evergreen |
| 15:02 |
mmorgan |
Interesting. We don't use stalling, but it's good to know about that side effect. |
| 15:05 |
csharp |
jeff: thanks - I figured as much |
| 15:06 |
csharp |
just wanted to make sure it wasn't necessary for some reason |
| 15:09 |
* berick |
uploads 2.8.6 files to the server |
| 15:10 |
dbwells |
Are we still meeting now? I know there's been some changes along the way, so I'm not 100% sure. |
| 15:10 |
kmlussier |
I thought we were. |
| 15:10 |
tsbere |
Stompro: For note, that won't happen if that library is the pickup library with stalling, only if it is going into transit. |
| 15:10 |
kmlussier |
I would take meeting controls, but I'm digging through something right now. |
| 15:13 |
Dyrcona |
I'm digging through other stuff right now, too, and may have to leave early. |
| 15:14 |
Dyrcona |
I will try to get the 2.9.2 tarball done tonight or tomorrow morning. |
| 15:17 |
* berick |
wonders if we need to elect a meeting manager when we elect the RM. |
| 15:18 |
dbwells |
gmcharlt, berick: It looks like you guys have the whole agenda for the meeting, but we're apparently low on participants. Should we run through a quick meeting or punt? |
| 15:18 |
gmcharlt |
give me 5 minutes, then let's go through a quick meeting |
| 15:18 |
dbwells |
gmcharlt++ |
| 15:28 |
gmcharlt |
ok, I'm ready |
| 15:28 |
gmcharlt |
#startmeeting Evergreen Development Meeting, 17 February 2016 |
| 15:28 |
pinesol_green |
Meeting started Wed Feb 17 15:28:43 2016 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:28 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:28 |
pinesol_green |
The meeting name has been set to 'evergreen_development_meeting__17_february_2016' |
| 15:29 |
berick |
gmcharlt++ |
| 15:29 |
gmcharlt |
#link http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2016-02-17 |
| 15:29 |
gmcharlt |
#topic Introductions |
| 15:29 |
gmcharlt |
#info Galen Charlton, ESI, release manager for 2.10 |
| 15:29 |
dbwells |
#info dbwells = Dan Wells, Hekman Library (Calvin College) |
| 15:29 |
DPearl |
#info dpearl = Dan Pearl, C/W MARS Inc. |
| 15:30 |
berick |
#info berick Bill Erickson King County Library System |
| 15:30 |
jlitrell |
#info jlitrell = Jake Litrell, MassLNC |
| 15:30 |
kmlussier |
#info kmlussier = Kathy Lussier, MassLNC |
| 15:31 |
gmcharlt |
#topic OpenSRF release |
| 15:32 |
gmcharlt |
#info release of 2.4.2 to occur later in February; main purpose will be fixing bug 1350457 |
| 15:32 |
pinesol_green |
Launchpad bug 1350457 in OpenSRF "method_lookup drops session info" [High,Fix committed] https://launchpad.net/bugs/1350457 |
| 15:33 |
csharp |
#info csharp Chris Sharp, GPLS |
| 15:33 |
gmcharlt |
#info a 2.5 series has been started; main proposed enhancements are support for passing client timezone and example websockets proxy configs |
| 15:34 |
gmcharlt |
and in particular, if the Evergreen client time zone enhancement makes it in (bug 1485374), that will mean that OpenSRF 2.5.0 will become the minimum required version for Evergreen 2.10 |
| 15:34 |
pinesol_green |
Launchpad bug 1485374 in Evergreen "Use client TZ in the database when supplied to the server" [Wishlist,New] https://launchpad.net/bugs/1485374 |
| 15:34 |
jeff |
#info jeff == Jeff Godin, Traverse Area District Library (TADL) |
| 15:35 |
gmcharlt |
so, that's that for my OpenSRF update; any comments or questions |
| 15:35 |
gmcharlt |
by the way, jeff++ for sleuthing the failed fork issue |
| 15:35 |
* gmcharlt |
awards jeff a virtual golden spork |
| 15:35 |
Dyrcona |
:) |
| 15:36 |
jeff |
:-) |
| 15:36 |
Dyrcona |
#info Dyrcona = Jason Stephenson, MVLC |
| 15:36 |
gmcharlt |
actually, we might discuss it now: specifically, the question of whether to fail fast or attempt to retry the fork |
| 15:36 |
Dyrcona |
I vote for fail fast, because when you can't fork(), you're typically, um, forked. |
| 15:37 |
jeff |
I'd like to limit the scope of the bug to fixing the issue of "the listener becomes the drone" -- this breaks an otherwise working system. |
| 15:39 |
Dyrcona |
Well, I think you could possibly achieve what berick suggested on the bug by limiting the check to == 0 for the child pid. |
| 15:39 |
jeff |
And given the choice of "client gets an error" or "client waits a little longer for a response", I opt for the latter. |
| 15:39 |
Dyrcona |
Then if it was undefined, the listener would go on and do nothing, but that could make things worse. |
| 15:40 |
jeff |
I agree with JBoyer that once the OOM killer has fired once, the machine is first in line for a reboot, but we don't currently try to detect or handle that kind of thing within OpenSRF/Evergreen at present, so that's probably left for tools better suited for the task. |
| 15:40 |
Dyrcona |
I'm in favor of die(), but would live with wait(). |
| 15:40 |
Dyrcona |
Err, sleep() rahter. |
| 15:41 |
jeff |
Current behavior is the entire service is dead, and client requests time out. |
| 15:42 |
Dyrcona |
Well, that and the listener turns into a drone. ;) |
| 15:42 |
gmcharlt |
I'm also in favor of die(), but maybe we can compromise? e.g., to handle the case where the OOM is just caused by a bad Clark report, let it retry once, then die() |
| 15:43 |
jeff |
I think (roughly) "detect failed fork, log error, sleep, defer to the next available drone" leaves us with good flexibility for recovery. |
| 15:43 |
Dyrcona |
Did berick suggest a retry count and/or configurable sleep interval? Those could work. |
| 15:43 |
berick |
no, I suggested basically what jeff said a line up. |
| 15:44 |
jeff |
Overall, the bug has existed for a while, and likely isn't causing frequent problems. I was going to mark it a Low priority before adding my next comment on it. :-) |
| 15:44 |
jeff |
I do like that it has us thinking a bit more about how to handle failures. |
| 15:45 |
gmcharlt |
OK, I think we can move on |
| 15:45 |
gmcharlt |
#topic Evergreen 2.10 update |
| 15:46 |
gmcharlt |
#info Feature slush is end of day on 19 February; any enhancements should have a pullrequest on the by then (and be plausibly ready to merge, although there'll be leeway for further work the following work) |
| 15:47 |
gmcharlt |
I'm leaving the definition of "end of day" intentionally squishy, but it won't stretch further than start of business on Monday, 22 February |
| 15:47 |
kmlussier |
I'm sure late Monday is start of business somewhere in the world. :) |
| 15:48 |
gmcharlt |
heh |
| 15:48 |
gmcharlt |
start of business for MEEEEE |
| 15:48 |
kmlussier |
How are things looking as far as having the web client ready for some production use. Does it still seem doable? |
| 15:48 |
berick |
i'll have a pull request on the patron editor stuff soon |
| 15:48 |
kmlussier |
berick++ |
| 15:50 |
berick |
before start of business monday in Hawaii |
| 15:50 |
gmcharlt |
kmlussier: other than that... I think it will amount to a more solid beta for circ desk; I think some more Hatch work would be necessary |
| 15:50 |
gmcharlt |
to get it more to fully production-ready |
| 15:51 |
gmcharlt |
another update: I've started using the rm-to-write-notes tag in LP to signify that I'll provide release notes entries when I cut 2.10 |
| 15:51 |
gmcharlt |
these are meant for minor enhancements that can be described in one line |
| 15:52 |
gmcharlt |
so, moving on to specific bugs |
| 15:52 |
gmcharlt |
#topic Password manage bug 1468422 |
| 15:52 |
pinesol_green |
Launchpad bug 1468422 in Evergreen "Improve Password Management and Authentication" [Undecided,New] https://launchpad.net/bugs/1468422 |
| 15:52 |
gmcharlt |
dbwells: berick: do you think it's basically ready for a pullrequest tag? |
| 15:53 |
berick |
i believe so, yes, maybe w/ some light code cleanup/squashing |
| 15:53 |
gmcharlt |
the other question, per the agenda, is dealing with the additional time it will take to log in |
| 15:53 |
berick |
right.. |
| 15:53 |
dbwells |
I think so. We've been running it in production for a while through various iterations, and no problems in the last few weeks. |
| 15:53 |
gmcharlt |
berick: (and it occurs to me that you're in a great position to quickly check how high-volume SIP2 clients would deal with that) |
| 15:53 |
berick |
gmcharlt: that's exactly my concern :( |
| 15:54 |
* gmcharlt |
had a feeling |
| 15:54 |
berick |
and how staff will feel about unhappy patrons, etc. |
| 15:54 |
dbwells |
Nobody here has mentioned the additional login time, but we've got no automation of that sort. |
| 15:54 |
berick |
thinking out of the gate, we lower the iteration count some. we still get the benefits of better encryption and better data protection. |
| 15:54 |
gmcharlt |
I think the patron OPAC login wait can be dealt with by putting up a spinner if need be |
| 15:55 |
gmcharlt |
berick: what's the current iteration coutn? |
| 15:55 |
berick |
10, I think |
| 15:56 |
berick |
actualy, no, 14 |
| 15:56 |
gmcharlt |
berick: Koha uses a bcrypt variant with 8 iterations |
| 15:56 |
jeff |
In your and dbwells' testing, what is the wallclock difference in time required to log in? |
| 15:57 |
berick |
jeff: quick test shows .1 seconds to 1 second (roughly) |
| 15:57 |
berick |
for just the auth calls combined |
| 15:57 |
kmlussier |
berick: Is that an OPAC login? |
| 15:57 |
berick |
i.e. via srfsh |
| 15:57 |
berick |
opac will take a little longer w/ API overhead |
| 15:57 |
dbwells |
maybe 1 second for us, I'd say |
| 15:58 |
berick |
gmcharlt: good to know... |
| 15:58 |
Dyrcona |
Does this require any client changes for logging in? |
| 15:58 |
berick |
Dyrcona: no, it's all backwards compat. |
| 15:58 |
Dyrcona |
berick: Thanks. I wasn't sure. |
| 15:59 |
gmcharlt |
berick: dbwells: would it be relatively straightforward to add a way to tweak the iterations per password? in particular, to make it possible to lower it a bit for SIP2 accounts? |
| 15:59 |
gmcharlt |
(if need be) |
| 15:59 |
berick |
gmcharlt: hmm, as it stands, the iter count is configured by password type, not by individual password. |
| 16:01 |
dbwells |
Not totally sure how the SIP2 workflow works, but one possibility would be an AuthProxy.pm plugin (or similar) to bypass the internal password check entirely. |
| 16:01 |
berick |
we could look at moving it to the password. not sure what that would take OTTOMY |
| 16:01 |
gmcharlt |
right |
| 16:02 |
dbwells |
i.e. There are new methods to get you logged in without actually logging in the client-y way. |
| 16:02 |
gmcharlt |
so, a suggestion: we put a pullrequest on it; the number of iterations can be tuned based on benchmarking before we cut 2.10 |
| 16:02 |
jeff |
i've been meaning to dust off that "stop requiring that the ILS password be the SIP2 password" branch, too. might relate. |
| 16:03 |
gmcharlt |
and I'll be willing to accept a late PR for a bug to tweak things for SIP2 authentication |
| 16:03 |
berick |
gmcharlt: sounds good. I'll start by trying 8 and see how that feels. |
| 16:03 |
berick |
and I'll add a pullrequest |
| 16:03 |
gmcharlt |
OK |
| 16:04 |
jeff |
berick: since your environment was cited as having "high-volume SIP2 clients", are they really logging in often? |
| 16:04 |
jeff |
berick: i.e., once logged in once with an increased ~1s delay, aren't all all subsequent SIP2 messages unaffected? |
| 16:05 |
jeff |
(per SIP2 client-server session) |
| 16:05 |
gmcharlt |
patron requests with PINs would get checked (though that's not relevant to the particular workflow that I think berick and I have in mind) |
| 16:05 |
berick |
jeff: we do have some sip clients that log in and out w/ every auth check. (not many, but at least 2 I can think of). I'm actually more concerned about the patron auth checks that occur via sip |
| 16:06 |
jeff |
ah. |
| 16:06 |
jeff |
kill them with fire. |
| 16:06 |
* jeff |
grins |
| 16:06 |
jeff |
(i know, out of scope) |
| 16:06 |
* gmcharlt |
sings the stunnel/SSH port-forwarding/VPN song, since SIP2 is immortal! |
| 16:06 |
* gmcharlt |
then weeps |
| 16:07 |
gmcharlt |
OK, I think we can move on |
| 16:07 |
gmcharlt |
#topic Squitch (bug 1521693) |
| 16:07 |
pinesol_green |
Launchpad bug 1521693 in Evergreen "Investigate using Sqitch for database change management" [Wishlist,New] https://launchpad.net/bugs/1521693 - Assigned to Bill Erickson (berick) |
| 16:07 |
gmcharlt |
so, I think where this stands is that berick presented this at the hackfest |
| 16:07 |
gmcharlt |
got a lot of nods that this looks useful |
| 16:07 |
gmcharlt |
and then... that's that |
| 16:08 |
gmcharlt |
have folks played around with the branch at all? |
| 16:08 |
jeff |
alas, not i. |
| 16:09 |
* JBoyer |
finally can pay some attention. |
| 16:09 |
Dyrcona |
No time. :( |
| 16:09 |
berick |
and to clarify, the reason I'm pushing on this is that it will require a lot of effort to maintain the branch in limbo. my strong pref. would be to move forward or kill it (for now). |
| 16:10 |
JBoyer |
Hm. I haven't had a chance to look at the branch either. :( I do very much like the idea though; dependency based db building is great. |
| 16:10 |
berick |
each DB upgrade has to be cross-ported, which I was doing for a while. but now i've set it aside. |
| 16:10 |
berick |
pending this discussion |
| 16:10 |
gmcharlt |
my inclination (at the moment) would be to put it aside for 2.10, but merge it into master immediately after rel_2_10 is branched |
| 16:11 |
berick |
agreed I was also assuming this would be post-2.10 |
| 16:11 |
gmcharlt |
that would then give us plenty of time at the beginning of the 2.11 cycle to see if we like it during dev |
| 16:11 |
JBoyer |
I'd say let the existing branch sit as a proof of concept, unless it's so close to ready as to go in as gmcharlt mentioned. |
| 16:11 |
JBoyer |
Talking it up a lot at the conference may get more exposure and opinoins. |
| 16:11 |
jeff |
+1 to post-2.10 squitch merge |
| 16:11 |
berick |
it could be made ready in a day or 2 if needed. (can't say the same in 6 months, though) |
| 16:12 |
gmcharlt |
and much easier to make ready immediately after 2.10 is cut, if I'm understanding things correctly |
| 16:13 |
* berick |
should probably do another demo/discussion somewhere at the conf. |
| 16:14 |
jeff |
berick: i'll drink to that. |
| 16:14 |
kmlussier |
berick: I would appreciate seeing another demo |
| 16:14 |
berick |
OK, I'll revisit after 2.10, spruce it up and slap a pullrequest on it then |
| 16:14 |
berick |
jeff: kmlussier: OK. |
| 16:14 |
JBoyer |
It would be a good state of evergreen thing too, "This is what we're thinking, speak now or etc." |
| 16:14 |
gmcharlt |
OK, so one way or another, we have candidates for a set point in time for introducing Sqitch into master (either 2.10 release or right after the EG conference); I encourage folks to try out the proof-of-concept branch in the meantime |
| 16:15 |
gmcharlt |
that brings us to the end of the agenda; are there any other topics that folks want to (briefly) raise before I end the meeting? |
| 16:15 |
gmcharlt |
#action berick planning on making a pullrequest for sqitch support after 2.10; will also be a discussion item at conference |
| 16:17 |
gmcharlt |
hearing no clamor for discussing another topic... I hereby |
| 16:17 |
gmcharlt |
#endmeeting |
| 16:17 |
pinesol_green |
Meeting ended Wed Feb 17 16:17:58 2016 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:17 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-02-17-15.28.html |
| 16:17 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-02-17-15.28.txt |
| 16:17 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-02-17-15.28.log.html |
| 16:18 |
jeff |
gmcharlt++ |
| 16:18 |
DPearl |
gmcharlt++ |
| 16:18 |
berick |
gmcharlt++ |
| 16:19 |
dbwells |
gmcharlt++ |
| 16:19 |
jlitrell |
gmcharlt++ |
| 16:19 |
JBoyer |
gmcharlt++ |
| 16:20 |
kmlussier |
gmcharlt++ |
| 16:25 |
* kmlussier |
is still mulling over the readiness of the web client. |
| 16:26 |
* jeff |
is currently tracking 36 incoming rockets. |
| 16:26 |
kmlussier |
jeff: Incoming rockets? Should you be running? |
| 16:26 |
jeff |
sorry, that was a bit apropos of nothing. i just don't get to say that very often. |
| 16:26 |
jeff |
:-) |
| 16:26 |
* jlitrell |
is shaking his fist at glibc |
| 16:26 |
jlitrell |
Send some of those rockets this way. |
| 16:27 |
kmlussier |
Who is using the web client in production right now? Is it MOBIUS? |
| 16:28 |
JBoyer |
kmlussier We give people the option just for circ. |
| 16:28 |
kmlussier |
JBoyer: How is it going? |
| 16:29 |
JBoyer |
We make it clear that they're probably going to want to keep the old client handy |
| 16:29 |
* kmlussier |
nods |
| 16:30 |
JBoyer |
I've heard from 1 user that had trouble registering a patron on an iPad because the Save buttons were over the Generate Password button, that's all I've heard. I'll probably ask Anna if she's heard anything more. |
| 16:30 |
kmlussier |
There are a few bugs that would make me concerned about using it in production, even with us clearly advertising it as beta. Particularly bug 1437109 and bug 1522635 |
| 16:30 |
pinesol_green |
Launchpad bug 1437109 in Evergreen "renew and edit due date features do not calculate correctly in web staff client" [Undecided,Confirmed] https://launchpad.net/bugs/1437109 |
| 16:30 |
pinesol_green |
Launchpad bug 1522635 in Evergreen "webclient: Checkout of Lost items fails with no feedback to the user" [Medium,Confirmed] https://launchpad.net/bugs/1522635 |
| 16:31 |
kmlussier |
And I'll add a bug 1527694 on top of that. |
| 16:31 |
pinesol_green |
Launchpad bug 1527694 in Evergreen "web client: Need to clear out last patron data at end of session" [Medium,New] https://launchpad.net/bugs/1527694 |
| 16:31 |
kmlussier |
JBoyer: berick's new patron editor should help with that issue. :) |
| 16:32 |
JBoyer |
I figured. I've been looking forward to it. :) |
| 16:32 |
JBoyer |
berick++ |
| 16:32 |
JBoyer |
I'll try to look at some of those bugs, we should probably be more on top of that stuff if we're letting people use it. :-/ |
| 16:33 |
JBoyer |
(Also I rather like working with Angular what little I have so far) |
| 16:34 |
JBoyer |
I'd also like something like an old web browser throbber. I don't know when the webstaff client is "finished" until nothing new has popped in for a good while. |
| 16:35 |
|
abowling1 joined #evergreen |
| 16:35 |
JBoyer |
Another day, another wishlist. Ah, well. |
| 16:58 |
|
jlitrell joined #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 17:11 |
jlitrell |
Kinda OT, but it seems maybe not everybody knows about it... there's an ugly bug in glibc for those of you running that. CVE-2015-7547 Sounds hard to exploit, but it is a remote hole, so patch up. :-/ |
| 17:11 |
pinesol_green |
** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547) |
| 17:12 |
jlitrell |
https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html |
| 17:30 |
|
jvwoolf1 left #evergreen |
| 17:36 |
justdoglet |
For Ubuntu users, 2.19-0ubuntu6.7 is the version that fixes the issue. The fixed packages were pushed to the repos yesterday. Upgrading libc-bin should pull in all required packages. |
| 17:37 |
justdoglet |
(Ubuntu 14.04, that is.) |
| 17:45 |
gmcharlt |
for Debian, it's 2.19-18+deb8u3 (jessie) and 2.13-38+deb7u10 (wheezy) and 2.11.3-4+deb6u11 (squeeze) |
| 17:46 |
justdoglet |
Here's the full list for Ubuntu 12.04 to 16.04: http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-7547.html |
| 17:46 |
pinesol_green |
** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547) |
| 18:21 |
|
bmills joined #evergreen |
| 18:28 |
|
dcook joined #evergreen |
| 18:35 |
|
Christineb joined #evergreen |
| 21:45 |
|
scrawler joined #evergreen |
| 21:46 |
scrawler |
hi all. |
| 21:50 |
scrawler |
ok, so I made it though the installation instructions up to restarting apache. it failed, but I enabled apache using systemctl. If I point a browser at localhost I get the default apache index.html. What port should evergreen be running on? |
| 21:52 |
scrawler |
oh wait. I have to install a client too, don't I? |
| 21:52 |
scrawler |
I forgot about that. |
| 21:52 |
scrawler |
see you in emails. |
| 21:53 |
|
scrawler left #evergreen |
