| Time |
Nick |
Message |
| 01:21 |
|
Mark__T joined #evergreen |
| 02:49 |
|
barbara joined #evergreen |
| 02:49 |
|
phasefx_ joined #evergreen |
| 02:49 |
|
miker joined #evergreen |
| 02:49 |
|
abneiman joined #evergreen |
| 02:49 |
|
Shae joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:58 |
|
jvwoolf joined #evergreen |
| 08:32 |
|
kmlussier joined #evergreen |
| 08:33 |
csharp |
@weather 30345 |
| 08:33 |
pinesol_green |
csharp: Atlanta, GA :: Overcast :: 53F/12C | Wednesday: Cloudy skies. Slight chance of a rain shower. High 66F. Winds S at 5 to 10 mph. Wednesday Night: Some passing clouds. Low around 50F. Winds light and variable. |
| 08:40 |
kmlussier |
@weather |
| 08:40 |
pinesol_green |
kmlussier: Seekonk, MA :: Mostly Cloudy :: 48F/9C | Wednesday: A mix of clouds and sun. High 49F. Winds SW at 10 to 20 mph. Wednesday Night: Rain showers early will evolve into a more steady rain overnight. Low 37F. Winds S at 10 to 20 mph. Chance of rain 100%. Rainfall near a quarter of an inch. |
| 08:45 |
csharp |
@wunder --forecast 30345 |
| 08:45 |
pinesol_green |
csharp: You keep using that word. I do not think it means what you think it means. |
| 09:14 |
|
Dyrcona joined #evergreen |
| 09:26 |
|
maryj joined #evergreen |
| 09:29 |
Dyrcona |
Gah! Why did DNS decide to stop working on my VM this morning? |
| 09:31 |
csharp |
Dyrcona: if you changed IP ranges, try 'dpkg-reconfigure resolvconf' |
| 09:31 |
csharp |
very annoying ubuntu bug |
| 09:32 |
Dyrcona |
csharp: Good idea! I'll give that a shot before messing the interfaces file again. |
| 09:32 |
Dyrcona |
resolvconf is not installed... |
| 09:34 |
|
mmorgan1 joined #evergreen |
| 09:35 |
Dyrcona |
I should probably install it, once I get DNS working again.... :( |
| 09:35 |
Dyrcona |
I really don't want to have to rebuild this VM, again. |
| 09:37 |
Dyrcona |
I dunno. I'm lost at this point. Not sure what I did to break it..... |
| 09:37 |
Dyrcona |
Whew! I fixed it! |
| 09:38 |
Dyrcona |
I had to edit /etc/resolv.conf manually. |
| 09:39 |
|
jvwoolf joined #evergreen |
| 09:39 |
Dyrcona |
This means trouble.... |
| 09:42 |
Dyrcona |
csharp++ # For suggesting resolvconf. |
| 09:43 |
|
mdriscoll joined #evergreen |
| 09:43 |
Dyrcona |
This is how quickly installing a couple of packages on a vm before shutting it down and making a new copy turns into an hour-long affair. |
| 09:45 |
|
yboston joined #evergreen |
| 09:49 |
csharp |
Dyrcona: glad it worked! |
| 09:54 |
Dyrcona |
After manually editing /etc/resolv.conf, I then installed resolvconf and rebooted. |
| 09:55 |
Dyrcona |
That should automagically fix things when the VM images are edited by a script and then started. |
| 09:55 |
Dyrcona |
We will be cloning VMs by "hand." |
| 10:20 |
|
NawJo joined #evergreen |
| 10:25 |
|
krvmga joined #evergreen |
| 10:54 |
Dyrcona |
After rebooting VMs that are back up in seconds, real servers take forever to reboot.... |
| 10:58 |
csharp |
@love virtualization |
| 10:58 |
pinesol_green |
csharp: But csharp already loves virtualization! |
| 11:30 |
csharp |
thanks to Terran's tirelessness, we're finally transitioning to all-A/T notices and retiring the old perl scripts |
| 11:31 |
csharp |
so far so good - that and the patron message center are very cool |
| 11:31 |
berick |
huzzah |
| 11:32 |
bshum |
csharp: A/T to create notice content and the actual notices themselves? Or just the content? |
| 11:33 |
csharp |
both |
| 11:34 |
bshum |
Neato! |
| 11:38 |
|
Christineb joined #evergreen |
| 12:01 |
|
rlefaive joined #evergreen |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:09 |
|
brahmina joined #evergreen |
| 12:15 |
|
rhamby joined #evergreen |
| 12:25 |
|
bmills joined #evergreen |
| 12:57 |
|
collum joined #evergreen |
| 13:16 |
|
rlefaive joined #evergreen |
| 13:24 |
|
rlefaive_ joined #evergreen |
| 13:47 |
bshum |
Is anyone else hitting refresh repeatedly on the feeds to learn ESI's big secret for today? :) |
| 13:48 |
kmlussier |
Maybe just a few times. :) |
| 14:03 |
|
rlefaive joined #evergreen |
| 14:09 |
Dyrcona |
Is there any reason to have GIST and GIN indexes on some fields? I've noticed some of our table fields have both. |
| 14:13 |
JBoyer |
Dyrcona, Depending on data types I suppose I could believe there |
| 14:14 |
csharp |
Dyrcona: we use GIN on the metabib.* tables, but we dropped the GIST ones as we installed them |
| 14:14 |
JBoyer |
s a reason, but I don't know them off hand. Although when I say that I'm thinking GiST on one field, GIN on another, do you mean both on the same fields in some places? |
| 14:15 |
Dyrcona |
JBoyer: Yes, both on the same fields in some places. |
| 14:15 |
Dyrcona |
csharp: There are metabib.*field_entry.index_vector. At least on the identifier_field_entry.index_vector column we've got both. |
| 14:15 |
JBoyer |
Oh, that sounds like a waste of bytes. pg_stat_all_indexes might have some interesting information in it. (I've been looking at that a lot lately...) |
| 14:16 |
Dyrcona |
Thanks! I'll probably drop the extra GIST indexes soonish. |
| 14:17 |
JBoyer |
csharp, Am I remembering correctly that GIN is (roughly) 3x faster and 3x bigger? |
| 14:18 |
JBoyer |
(Than GiST, that is.) |
| 14:21 |
bshum |
Bigger, at least till you get the new stuff in PG 9.4+ (we hope) |
| 14:21 |
bshum |
I didn't get to test it, but PG 9.4 boasted reduced GIN size in the release notes |
| 14:21 |
bshum |
Well, test it with live data |
| 14:24 |
csharp |
JBoyer: yep and yep |
| 14:24 |
csharp |
I rebuilt the GIN indexes in 9.4, but didn't measure the size difference |
| 14:24 |
csharp |
we did notice a performance improvement though |
| 14:24 |
csharp |
(non-benchmarked) |
| 14:26 |
JBoyer |
Ah. So I'll be laying off of those for a little bit then. We overlaid 2M+ bibs without frequent enough vacuums, so I need to shed a ton of table bloat and don't have room for larger base index sizes. :/ Good to hear they're faster though! |
| 14:28 |
JBoyer |
Ack. There's about 15G0Gb that needs swept up... |
| 14:29 |
|
terran joined #evergreen |
| 14:29 |
kmlussier |
Hooray for deadline extensions! |
| 14:30 |
Dyrcona |
I love deadlines, especially that whooshing sound they make as they fly past. |
| 14:30 |
JBoyer |
Also something to consider for your 2.11 upgrade, you might throw a vacuum -F at the reporter.hold_request_record table, it's got pretty heavy churn and the dead rows pile up fast. |
| 14:31 |
JBoyer |
Uh, I meant to put that in a cron job that runs semi-frequently, I assume everything gets a vacuum here and there anyway. |
| 14:32 |
Dyrcona |
JBoyer: According to one Pg optimization HOWTO that I read: "You can't run autovacuum too much. If you think it is slowing down your database, you are not running it enough." |
| 14:34 |
JBoyer |
Oh, I know. I boosted our max AV processes to 120. It's the Freeze part that I don't think AV necessarily does that can still sometimes help with space. |
| 14:38 |
JBoyer |
I need to run a Full against the thing, but that's miserable at this rate. :/ |
| 14:39 |
Dyrcona |
Uh huh. |
| 14:40 |
csharp |
We run a weekly vacuum analyze on top of AV |
| 14:41 |
* csharp |
learns lots about dryer parts/repair |
| 14:42 |
JBoyer |
Ours used to be nightly. |
| 14:42 |
* JBoyer |
has not enjoyed past dryer education sessions |
| 14:43 |
csharp |
well, I replaced a fuse/thermostat only to learn upon visible inspection that the element is busted |
| 14:44 |
csharp |
pretty much just like computers ;-) |
| 14:44 |
JBoyer |
Hey! We learned the same lesson. ;D |
| 14:45 |
jeff |
lesson being, "don't skip the continuity check"? |
| 14:45 |
berick |
Vacuum Full Day should be an annual national holiday |
| 14:45 |
Dyrcona |
csharp: While you're at it, could you replace the igniter in my oven? |
| 14:46 |
* JBoyer |
preps a Dryer Element Continuity of Operations Plan, 2017 ed. |
| 14:46 |
Dyrcona |
berick: ha! |
| 14:46 |
JBoyer |
berick++ |
| 14:47 |
Dyrcona |
So, I have a "working" VM in the sense that it boots and everything looks good. |
| 14:47 |
JBoyer |
I sense an "until..." |
| 14:47 |
Dyrcona |
Of course, the network is all fouled up because it's not on the LAN it is configured for. |
| 14:48 |
Dyrcona |
JBoyer: There's always that feeling of "I forgot something." |
| 14:48 |
Dyrcona |
And, then, it hangs for a bit starting the MTA because the IP addresses are "wrong" and there's no connectivity. |
| 14:49 |
Dyrcona |
And, I realize, "Oh! Right! I need to configure the MTA to use a smarthost!" |
| 14:50 |
Dyrcona |
But, what I have is a model VM, that I can copy into place and mangle a bit with a shell script, then define it. |
| 14:50 |
Dyrcona |
It can be a brick head, drone server, or a SIP server depending. |
| 14:53 |
JBoyer |
Meaning that now it's fixed and you have a clonable VM, or it's still wobbly on the network but this is your plan? |
| 14:54 |
Dyrcona |
The latter. I'm on a 10.x network but the destination is a 192.168., so the host's IP will change when the machine is physically moved, and everything should "just work." |
| 14:55 |
Dyrcona |
I'm setting the VM's up to use the 19.168. network. |
| 14:57 |
JBoyer |
Oh, ok. Now I follow. |
| 14:58 |
Dyrcona |
Yeah. The network breakage is deliberate and expected. |
| 14:59 |
Dyrcona |
Now that I think about it, I may not have to touch the MTA config. Most of the mail comes from the utility server. |
| 15:04 |
terran |
I'm struggling trying to make an action trigger to send a preminder via text msg, but having trouble getting the SMS info from the patron account. I can follow the fieldmapper from the au table to the aus table for the user settings, but then I get stuck. Anyone have any advice? |
| 15:12 |
* jeff |
takes a moment to appreciate the term "preminder" |
| 15:12 |
terran |
jeff: I can't take credit for that one |
| 15:13 |
|
collum joined #evergreen |
| 15:21 |
mmorgan1 |
terran: The "helpers" used in action trigger templates are still a bit of a mystery to me, but I notice that the sms hold notifications use helpers.get_sms_gateway_email(target.0.sms_carrier,target.0.sms_notify) as the To: address |
| 15:22 |
terran |
mmorgan1: yes, I tried that first, but it appears they are getting their values from what is stored in the hold record (which is mapped in the fieldmapper) and not from the patron's user settings |
| 15:22 |
mmorgan |
Ah, ok, that makes sense. |
| 15:23 |
|
abneiman joined #evergreen |
| 15:23 |
|
graced joined #evergreen |
| 15:24 |
jeff |
but what if i want to be reminded of my due date for this particular item via a different phone number than this other item? |
| 15:24 |
|
miker joined #evergreen |
| 15:25 |
mmorgan |
jeff: you forgot to duck ;-) |
| 15:25 |
jeff |
ALTER TABLE action.circulation ADD sms_carrier INTEGER; |
| 15:25 |
jeff |
mmorgan: i was waiting for the timing to be right. :-) |
| 15:25 |
jeff |
but yes, |
| 15:25 |
* jeff |
ducks |
| 15:26 |
terran |
* terran throws like a girl, so don't worry |
| 15:28 |
* mmorgan |
has been meaning to learn more about those helpers, but notices helpers.get_user_setting and wonders if that might be of use. |
| 15:28 |
terran |
mmorgan: ooh, yes, that sounds promising |
| 15:29 |
* mmorgan |
is also hoping someone who has actual knowledge about the helpers might chime in. |
| 15:29 |
|
barbara joined #evergreen |
| 15:31 |
terran |
Found this in an old irc log: [%- user = target.0.usr; sms_number = helpers.get_user_setting(user.id, 'opac.default_sms_notify'); sms_carrier = helpers.get_user_setting(user.id, 'opac.default_sms_carrier'); -%] |
| 15:31 |
terran |
Going to try it out... |
| 15:32 |
|
rhamby joined #evergreen |
| 15:33 |
|
akilsdonk joined #evergreen |
| 15:36 |
dbs |
Hey my 10-year old girl throws pretty damned hard. |
| 15:38 |
terran |
dbs: Probably harder than I do. I pack a helluva punch, though. |
| 15:40 |
|
maryj joined #evergreen |
| 15:43 |
terran |
mmorgan++ for the nudge towards the helper - it works! |
| 15:44 |
mmorgan |
Yay!! |
| 15:44 |
|
rlefaive joined #evergreen |
| 15:44 |
mmorgan |
terran++ for action trigger mastery |
| 15:45 |
terran |
here's the log that had the info: http://irc.evergreen-ils.org/evergreen/2015-10-16 -- tsbere++ and Bmagic++ |
| 15:50 |
|
sarabee joined #evergreen |
| 15:55 |
|
brahmina joined #evergreen |
| 15:57 |
|
Shae joined #evergreen |
| 16:06 |
|
abowling left #evergreen |
| 16:09 |
|
rlefaive_ joined #evergreen |
| 16:09 |
collum |
@weather 41017 |
| 16:09 |
pinesol_green |
collum: Fort Mitchell, KY :: Overcast :: 53F/12C | Wednesday: Windy with rain at times. Lows overnight in the mid 50s. Wednesday Night: Windy at times with occasional rain. Low 56F. Winds SSW at 20 to 30 mph. Chance of rain 80%. Rainfall near a quarter of an inch. | Updated: 17m ago |
| 16:30 |
Dyrcona |
@weather 01601 |
| 16:30 |
pinesol_green |
Dyrcona: Worcester, MA :: Mostly Cloudy :: 45F/7C | Wind Chill: 41F/5C | Wednesday: Cloudy with rain. Lows overnight in the upper 30s. Wednesday Night: Periods of rain. Low 37F. Winds SSW at 15 to 25 mph. Chance of rain 90%. Rainfall around a quarter of an inch. |
| 16:30 |
Dyrcona |
Sparse files are weird. :) |
| 16:32 |
jeff |
Bmagic, terran: can either of you elaborate on the "helps staff detect a less-than-honest patron" bit of bug 1655158? |
| 16:32 |
pinesol_green |
Launchpad bug 1655158 in Evergreen "Patron Search by date of birth" [Wishlist,Confirmed] https://launchpad.net/bugs/1655158 |
| 16:36 |
jeff |
is it a matter of searching for a name fragment + dob off of ID and then seeing high-probability duplicate / variant accounts? |
| 16:37 |
jeff |
now having asked, i have a stong feeling of deja vu, but the bug is new, so... |
| 16:47 |
|
rlefaive left #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:08 |
|
jvwoolf left #evergreen |
| 17:11 |
|
mmorgan left #evergreen |
| 17:25 |
terran |
jeff: yes, that's it - in our case, we just have so many patrons that duplicate names is a huge problem, especially if we're searching by "j smith" to catch variations of john / jon / jonathon etc |
| 17:26 |
terran |
Our staff have wanted it for ages, but I didn't realize there hadn't been a wish list bug in there for it until this was added. |
| 19:05 |
|
genpaku joined #evergreen |
| 22:10 |
Bmagic |
jeff: The language that one of our libraries used was "less than honest" - but I really don't know what that means. I can add a little bit though |
| 22:11 |
Bmagic |
Someone racks up a bill with their account, and then simply applies for a new card under the same last name but a different first name. The date of birth search by it self would turn up all of the patrons with that date, and could* find a matching patron |
| 22:12 |
Bmagic |
Or applies for a new card with a name that is close but not exactly the same. A name that wouldn't turn up the duplicate account |
| 22:14 |
Bmagic |
jeff: the deja vu feeling was probably from this: http://irc.evergreen-ils.org/evergreen/2015-03-25#i_166015 |
| 22:17 |
Bmagic |
I never made a bug before but the topic has recently been revived by our libraries |
| 22:19 |
dcook |
Folk don't need ID to enroll? |
| 22:20 |
dcook |
I guess a lot of libraries must have different policies.. |
| 23:11 |
Bmagic |
dcook: I'm not sure I understand your question |
| 23:20 |
dcook |
Well, I was just wondering how someone would apply for a new card with a different first name, unless they changed their name on their ID |
| 23:20 |
dcook |
At my local library, I actually had to bring in my lease to show that I was a resident of the area. |
| 23:20 |
Bmagic |
dcook: You got me, I am just relaying the story that I was told |
| 23:20 |
dcook |
Damn |
| 23:20 |
dcook |
I'm intrigued by it :/ |
| 23:21 |
dcook |
Maybe there's an industry of making fake IDs to defraud libraries who fine people for late books :O |
| 23:21 |
Bmagic |
none the less, adding date of birth to the patron search seems reasonable |
| 23:21 |
dcook |
From a deduplication point of view, yeah I could see that |
| 23:21 |
dcook |
From a privacy perspective, I wonder sometimes if we should store less and less about our patrons.. |
| 23:22 |
Bmagic |
Yeah, we share that sentiment |
| 23:24 |
dcook |
I was going to say it's a shame we don't have more formal designations like FN-2187, but that led me to this... http://www.telegraph.co.uk/film/star-wars-the-force-awakens/finn-john-boyega-george-lucas-fn-2187/ |
