Evergreen ILS Website

IRC log for #evergreen, 2016-06-03

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
04:34 artunit_away_ joined #evergreen
04:38 webmind_ joined #evergreen
05:14 justdoglet joined #evergreen
05:39 gsams joined #evergreen
06:39 justdoglet joined #evergreen
06:49 jyorio joined #evergreen
06:49 abowling joined #evergreen
06:49 jonadab joined #evergreen
07:18 rjackson_isl joined #evergreen
07:28 maryj joined #evergreen
07:36 graced joined #evergreen
08:05 mrpeters joined #evergreen
08:41 mmorgan joined #evergreen
08:41 kmlussier joined #evergreen
08:58 Dyrcona joined #evergreen
09:03 Dyrcona oc-FR: Occitan, France, not French. The first two are the language and the second are the country.
09:04 Dyrcona ar-AR: Arabic, Argentina. Always found that amusing, but there is apparently a tradition of repeating the language code when the country is not known or irrelevant.
09:04 Dyrcona Anyway, gonna reply to gmcharlt's email about the threshold of completeness.
09:07 remingtron tsbere++ #for sharing 'git whatchanged' yesterday
09:08 tsbere remingtron: Happy to help, I almost want to set things up so that "git log" runs "git whatchanged" instead some days...
09:08 tsbere But then I will forget that I am really running whatchanged, and will get confused when people can't see filenames, so I probably shouldn't
09:12 remingtron tsbere: true, that's the trouble with command aliases
09:13 Dyrcona git log -p  shows all the diffs
09:13 Dyrcona Which is more than whatchanged, but handy some times.
09:16 bos20k joined #evergreen
09:26 * tsbere got curious about log vs whatchanged, and it looks like "git whatchanged" may be a shortcut for "git log --no-merges --sparse --raw"
09:27 Dyrcona Well, whatchanged is a bit easier to type. :)
09:29 tsbere Apparently whatchanged comes from an era where log didn't know how to show diffs of any kind. A year or so later they taught log how to load diffs.
09:35 jeff and around that time, changed "whatchanged" to an alias for the equivalent new functionality in log?
09:38 tsbere jeff: I believe that happened at or shortly after that point, I haven't gone looking for commits or anything
09:38 * jeff nods
09:43 tsbere As Dyrcona said, "git whatchanged" is easier to type. And remember.
09:46 Dyrcona Uh-huh....autogen.sh says cstore is NOT CONNECTED TO THE NETWORK!!!
09:46 Dyrcona osrf_control --localhost --diagnostic says it is.
09:47 Dyrcona Hmm... Maybe I ran autogen.sh too soon after starting services. :)
10:02 kmlussier On bug 1528647, since terran is changing the author to Bob Wicksall, and has hasn't signed off on the bug, should Bob add a DCO to the LP bug before the code gets merged?
10:02 pinesol_green Launchpad bug 1528647 in Evergreen "Self-check only accepts user name value if regex for barcode not set up" [Undecided,New] https://launchpad.net/bugs/1528647
10:03 csharp @seen bwicksall
10:03 pinesol_green csharp: I have not seen bwicksall.
10:04 Bmagic Dyrcona: The sandbox is up and I don't have any plans to take it down. You have several weeks
10:04 Dyrcona Bmagic: Thanks. I saw what I needed to see last night.
10:05 Dyrcona I have a sandbox of my own to test the fix.
10:05 * Dyrcona can't believe he made such a silly error. ;)
10:06 kmlussier @dessert 36 [someone]
10:06 * pinesol_green grabs some Boston Cream doughnuts for serflog
10:06 Dyrcona Well, he can, but....
10:06 kmlussier In honor of National Doughnut Day
10:07 * kmlussier doesn't think serflog can truly appreciate a good doughnut
10:08 gsams heh, I bought some for the staff today
10:09 kmlussier gsams++ # Making staff happy with doughnuts
10:09 kmlussier @decide doughnut or donut
10:09 pinesol_green kmlussier: go with doughnut
10:11 afterl joined #evergreen
10:15 * kmlussier will add a comment to the bug regarding the DCO
10:27 Dyrcona @decide donut or donut
10:27 pinesol_green Dyrcona: That's a tough one...
10:27 Dyrcona :)
10:27 Dyrcona @decide cruller or fritter
10:27 pinesol_green Dyrcona: go with cruller
10:29 gsams I feel like pinesol_green is nailing it today
10:29 kmlussier Yes, I agree, The cruller is a better choice.
10:30 gmcharlt @decide Dunkin Donuts or Krispy Kreme
10:30 pinesol_green gmcharlt: go with Krispy Kreme
10:30 gmcharlt pinesol_green: you are wrong. your wrongness is immense.
10:30 pinesol_green gmcharlt: No, you're a puzzleheaded kraken!
10:30 pinesol_green In #evergreen, gmcharlt said: pinesol_green: you are wrong. your wrongness is immense.
10:30 gsams well, it had a good run
10:30 * kmlussier has never had a Krispy Kreme doughnut
10:30 gsams My advice is to not
10:31 gsams my opinion of course
10:31 kmlussier But, even though I'm from the land of Dunkin Donuts, I have to say I've never been impressed with their doughnuts.
10:31 * Dyrcona likes Heav'nly Donuts better than Dunkin'.
10:31 gsams I prefer a local shop myself, though we don't have a lot of Dunkin's around here.
10:31 bshum Pfft, I like Krispy Kremes :(
10:32 Christineb joined #evergreen
10:32 kmlussier Dunkin's coffee is okay, as long as you don't get it in the afternoon when it takes on a decidedly burnt taste.
10:32 Dyrcona Heav'nly is more local than Dunkin' and a much smaller chain.
10:32 kmlussier Yeah, I like Honey Dew Donuts, which is a much smaller chain too
10:33 * tsbere prefers Heav'nly to Dunkins, but has no experience with Honey Dew
10:33 gsams I go to a local shop called Donut Paradise, really nice lady, supports our summer reading program
10:36 kmlussier terran++ # For organizing a great Bug Squashing Day!
10:36 kmlussier That I mostly missed. :(
10:49 Dyrcona Whee! Fun with new MARC templates: subfield s comes before subfield b in this tag....
10:52 * Dyrcona hands himself a lollipop. :)
11:02 jvwoolf joined #evergreen
11:04 rjackson_isl all this talk of donuts reminds me of an Indiana chain closed down years ago due to "extra" ingredients added by the 4 legged residents of the shop! :(
11:05 kmlussier Ewwww
11:05 rjackson_isl fur sure
11:12 jeff woohoo! found more hidden-but-useful options in a vendor product.
11:13 berick rjackson_isl: sprinkles!
11:13 rjackson_isl rice
11:14 Dyrcona chocolate rice.
11:15 mmorgan What kmlussier said: Ewwww...
11:22 berick haha
11:24 * Dyrcona is going to try webalizer on the public opac logs to see if our usage has been going up.
11:25 * Dyrcona is trying to figure out why we've started having issues after all these months.
11:26 Dyrcona Bmagic: Have you worked anything out with your Apache issues?
11:27 Dyrcona I increased our settings for MinSpareServers, MaxSpareServers, and let MaxRequestWorkers go to the default, and things have apparently improved for us.
11:27 Bmagic Dyrcona: it's a tough nut to crack because it only shows its ugly face during load. We did tweak some settings in lvs: ipvsadm --set 30 30 45
11:28 Dyrcona Bmagic: So, what does that do?
11:28 Bmagic Dyrcona: what numbers are you using for those Apache settings?
11:28 Bmagic http://linuxcommand.org/man_pages/ipvsadm8.html
11:28 Dyrcona MinSpareServers: 20 MaxSpareServers: 40 StartServers: 100
11:28 Bmagic The first number is tcp timeout, the second is after the fin packet and the third number is udp (probably unused)
11:29 Dyrcona MaxRequestWorkers is commented out, so it gets the default of 256.
11:29 Bmagic Without configuring LVS, the defaults were very high, like lvs was hanging onto connections for 2 minutes after the fin packet
11:31 Dyrcona OK. We're just using kvm and libvirt.
11:31 Bmagic We are seeing much lower numbers in our LVS connection report (ipvsadm -L)
11:32 Dyrcona So then it appears to have helped to lower the timeouts.
11:32 Dyrcona That's good.
11:32 Bmagic and Apache hasn't been getting clobered on the app servers. CPU is hovering around 1 on each of the 8
11:33 Bmagic however, we have started getting reports of SIP connections not working, and hold requests (of all things) not giving the UI the "submit" button
11:33 JBoyer Unless I can't math (checked twice) the default TCP timeout for ldirector/LVS is 15 minutes. I'm losing my mind here.
11:33 Bmagic JBoyer: yes, I believe you are correct - we changed that to 30 seconds
11:33 Dyrcona JBoyer: I lost mine a long time ago. ;)
11:34 Bmagic JBoyer: I was talking about the other setting "TCPFIN" which is defaulted to 120 seconds
11:34 Dyrcona Somebody said something about the keep alive setting in Apache the other day......
11:34 * Dyrcona searches logs.
11:35 Bmagic JBoyer: Like I said though, Im not entirely sure that we are out of the woods. We have been getting reports of hold requests UI and Overdrive SIP auth failing now with the new LVS config
11:35 berick Dyrcona: me.  keepalive should be 1.
11:35 JBoyer Ah, lots of closed connections just waiting to fall off.
11:35 Dyrcona Yep, just found it.
11:35 JBoyer Well, the command you posted shows that both the TCP and TCPFIN were set to 30, raising the first one to 60 or 120 may help with those other issues
11:36 Bmagic keepalive was set to 5 for us at the beginning of the issues, Changing that to 1 had a profound impact on performance. The CPU's on the bricks never went out of control again, but we still had a "slowness" issue (which in my theory was due to apache not having enough workers to serve everyone, and they had to wait)
11:37 Dyrcona That's interesting. Ours is set to 5 still.
11:37 Dyrcona I'll try changing that when it acts up again.
11:38 Dyrcona Wonder if outright disabling keepalive would help....probably not.
11:38 JBoyer Bmagic, are you using persistent connections at all in lvs?
11:38 Bmagic Dyrcona: Yes, I believe it needs to be set to 1. The Evergreen install instructions even say that, lol
11:39 Bmagic Dyrcona: We did disable keepalive on one brick just to see. We didn't see any difference between off and 1
11:39 Dyrcona Bmagic: Yep. They do.
11:39 * Dyrcona fixes that...
11:39 brahmina_ joined #evergreen
11:40 Bmagic JBoyer: no we are not using persistent currently. We used to use that because there was an issue with SSL connections needing to stay on the same brick
11:46 Dyrcona Whee! 161 zombie after apache2 reload....
11:46 Dyrcona And now, 0 zombies.
11:49 * Dyrcona gives it 15 minutes or so for the load to settle to see if that helped.
11:51 bmills joined #evergreen
11:53 rlefaive joined #evergreen
11:58 Stompro Hello All, is the staff member that canceled a hold recorded anywhere that is accessible in the staff client?  I'm looking through the column picker in the canceled hold screen and nothing is leaping out at me.
12:00 jeff Stompro: nope, as that information is not stored in the database.
12:00 jeff Stompro: cancel time, cause, and note is it.
12:00 Dyrcona Stompro: Doesn't look like that information is available in the database, either.
12:01 Stompro Thanks
12:01 jeff Stompro: there is some information you could get from logs, and the audit user and audit ws *might* be stored if you have enabled auditing on the action.hold_request table (it isn't audited by default).
12:02 * Dyrcona was gonna mention the logs might be useful.
12:02 jeff Stompro: do you mind if i remove you as assignee on bug 1519879? I'm not sure if you're actively working on it.
12:02 pinesol_green Launchpad bug 1519879 in Evergreen "SIP Precedence Warning, possible logic issue" [Undecided,Confirmed] https://launchpad.net/bugs/1519879 - Assigned to Josh Stompro (u-launchpad-stompro-org)
12:04 Stompro jeff, no go right ahead, I haven't done any work on that, just throught about it.
12:04 jihpringle joined #evergreen
12:04 bmills joined #evergreen
12:06 jeff I think that (rather than fix the precedence issue), we can remove both the user active and the card active checks, as they are redundant with code elsewhere.
12:07 jeff And the only effective change will be that we will no longer block patrons whose primary card is inactive, but they were retrieved by an active card. :-)
12:07 jeff (there are actually other issues with that -- SIP2 code has some problems with multiple cards in general, but that's somewhat tangental)
12:16 jeff web staff client does not currently require a workstation, and i think in some ways that may be a good thing.
12:16 jeff but there are other ways in which it is probably a bad thing, such as lacking a workstation on payments.
12:16 Dyrcona yep.
12:17 jeff cash payment doesn't fail on lack of workstation, which it probably should.
12:17 Dyrcona or if I login as myself, and everything happens at my home library as a patron, when it should happen at my work_ou.
12:17 jeff (at a low level)
12:17 JBoyer jeff, I thought that was also in the process of being "corrected."
12:17 mmorgan Stompro: lp 1501790
12:17 pinesol_green Launchpad bug 1501790 in Evergreen "action.hold_request should store user and workstation ids related to the cancellation" [Wishlist,New] https://launchpad.net/bugs/1501790
12:18 jeff JBoyer: I think I've been part of a conversation or two regarding that, but I'm not sure if there's any active work or bug toward changing it -- which was part of my reason for bringing it up again. :-)
12:18 kmlussier I would prefer that the web client require a workstation.
12:18 JBoyer I see. I may have misremembered any progress on it. I'm with kmlussier though, WS or OPAC.
12:18 kmlussier At the moment, if you don't have a registered workstation, there are lots of things that don't work properly.
12:19 kmlussier JBoyer: There is a bug with plans. But I don't know if anyone is actively working on it.
12:20 JBoyer Ok, so that's what I'm remembering. Maybe I should poke about if I could ever find the time. :/
12:21 * kmlussier just noticed bug 1529892.
12:21 pinesol_green Launchpad bug 1529892 in Evergreen "Web Client: Wish List - Make it more obvious when there isn't a workstation" [Undecided,New] https://launchpad.net/bugs/1529892
12:21 JBoyer So, Launchpad search, we meet again, for the last time.
12:21 kmlussier I'll add my opinion there too.
12:21 kmlussier JBoyer: The discussion is on bug 1467663
12:21 pinesol_green Launchpad bug 1467663 in Evergreen "Cannot login to web staff client if work station does not exist in database" [Medium,New] https://launchpad.net/bugs/1467663
12:25 brahmina joined #evergreen
12:32 brahmina_ joined #evergreen
12:53 tspindler joined #evergreen
13:10 Dyrcona And, webalizer churns through a 1.7GB gzip file.
13:57 ssieb joined #evergreen
14:03 tspindler left #evergreen
14:13 bmills joined #evergreen
14:46 Dyrcona You know you're lazy when you're using perl one liners on the command line as a calculator.
14:46 Dyrcona perl -e 'print 100/38.9 . "\n";'
14:47 miker Dyrcona: easier to remember than the correct syntax for bc
14:47 Dyrcona Yep, and faster than moving the fingers from the keyboard to open the graphical calculator on the local desktop.
14:49 Dyrcona Plus, I get decimals without needing it on both sides.
14:50 Dyrcona BTW, that's my speed up using dbwells patch for metabib.reingest_record_attrs, approximately 2.5X.
14:51 Dyrcona I think my db hardware is the biggest bottleneck in this case.
14:52 dbwells Dyrcona: cool, thanks for the update.  The 7x in my test was for just the attribute reingest step isolated, so it is expected that the overall speedup will be less than that.
14:53 Dyrcona dbwells: my measurements both times were made with this query: SELECT COUNT(metabib.reingest_record_attributes(id)) FROM biblio.record_entry;
14:54 Dyrcona I included deleted ones, both times.
14:54 Dyrcona Still, any increase is better than nothing....
14:54 dbwells Oh, ok.
14:54 Dyrcona 26 hours after the patch versus 67 before.
14:55 * Dyrcona can't get webalizer to build a proper index page.
14:56 Dyrcona I keep running into this: http://askubuntu.com/questions/638887/webalizer-​shows-only-2-months-on-summary-page-ubuntu-14-04
15:07 Dyrcona Yay. It worked from the tarball!
15:19 Dyrcona So, it shows that hits have generally trended up but not much, while the number of files served has gone up, even over months where the # of hits are basically the same.
15:23 Bmagic Is not being able to change your phone number in the OPAC "by design" ? Or is there a setting that I am missing?
15:24 tsbere Bmagic: I don't recall it ever being implemented, at least. Though you can change the default hold notification phone number.
15:24 * tsbere suspects it is similar to "don't let them change their address(es)"
15:25 Bmagic hmmm, the address change is in the OPAC
15:25 tsbere Bmagic: Postal address(es), not email address
15:26 Bmagic tsbere: that is what I meant, postal address is editable in the OPAC currently. So why not the phone number?
15:26 tsbere I wasn't aware postal address was editable
15:27 tsbere In fact, in MVLC's catalog, at least, it doesn't appear to be
15:28 Bmagic oh, oops, you're right (I misunderstood at a glance when I saw "pending")
15:28 Bmagic Well, we have some call for allowing the patron change their phone number. Is there a reason we shouldn't?
15:29 tsbere Bmagic: Which one? :P
15:29 Bmagic any or all three I would guess
15:30 berick you can create pending addresses in the catalog, but staff have to approve them via the user editor
15:30 berick if the feature is enabled
15:31 Bmagic berick: I was about to say that
15:31 Bmagic (I thought so!)
15:32 tsbere Bmagic: Staff verification, I guess? :P Add "Pending Phone Numbers"?
15:32 Bmagic I suppose. Not sure why though
15:33 kmlussier I would think staff verification is needed more for addresses than for phone numbers.
15:33 jeff phone numbers are easier (and cheaper) to verify in an automated fashion.
15:33 Bmagic I think that leaving it the way it is might be the best course. Because the hold notification business is really the main function of the OPAC, and they can change that!
15:34 jeff but yes, i'd like to make it (optionally?) easier for patrons to update their contact info.
15:35 jeff for those of you with "sms" notification options enabled for your patrons: would you be willing to share volume statistics, especially if i crafted the query required?
15:36 jeff i'd like to get a sense of what it might cost "the average library" to move away from the sms-via-email-gateways approach.
15:36 tsbere jeff: I have some queries for statistics already, though I don't know if they would tell you what you want to know.
15:37 jeff roughly, "number of email messages sent via sms gateway grouped by day/month/year/something"
15:37 jeff broken down by something like A/T hook type.
15:37 jeff (since i wouldn't want to rely on stock event_def ids, etc)
15:39 * mmorgan would be willing to run a query for sms stats
15:43 phasefx hey guys, what could cause the staff client to create a hold transit with the same source and destination orgs?
15:43 tsbere capture local holds as transits
15:43 jeff "capture local holds as transits"
15:44 jeff we use that routinely
15:44 phasefx not really familiar with that, what is it, an org setting?
15:44 tsbere Modifier
15:44 jeff checkin modifier
15:44 phasefx ah!
15:44 jeff also SIP setting
15:44 phasefx jeff++ tsbere++
15:44 tsbere Originally written to be a SIP setting
15:44 * jeff nods
15:44 tsbere But I added the modifier so I didn't have to use SIP to test
15:44 jvwoolf joined #evergreen
15:44 tsbere and then decided "this is useful" and left it in the client
15:45 jeff useful for: copy has been checked in, but is currently sitting at the bottom of a sorter bin and is not actually ready for pickup yet.
15:45 tsbere Yep. Also useful for "We can't actually give you this for three days due to the release date, but want to get holds capturing now"
15:45 jeff also useful for: "we sometimes check in items at this desk, but we do not want to print hold slips or have the hold become available until it is actually checked in where normal holds are scanned", etc.
15:46 tsbere Can be good for "the library is closed for a week, but we are processing transit bins anyway" too
15:46 * jeff deletes line saying similar
15:46 phasefx trippy :)  thanks guys
15:47 jeff just remember: if you're closed for a week and then you have more holds go "available" in one day than you've ever had before... keep an eye on your automated phone notification runtime.
15:49 jeff "hi, I got a call that my hold was ready... at 1 AM?"
15:50 kmlussier tsbere / jeff: Wow! It's as if you practiced that routine in anticipation of phasefx asking the question.
15:50 Bmagic new wishlist bug 1588953
15:50 pinesol_green Launchpad bug 1588953 in Evergreen "WISHLIST: Allow patrons to change account phone number in OPAC My Account Preferences" [Undecided,New] https://launchpad.net/bugs/1588953
15:53 jeff kmlussier: glad you enjoyed the performance!
15:54 kmlussier I wish I had thought to make some popcorn ahead of time.
15:54 * mmorgan could never come up with any use for capture holds as transits before.
15:54 tsbere mmorgan: Now you have a whole pile! ;)
15:56 jeff if we were still doing the thing that caused us to desire something like "hold capture verify", and both "hold capture verify" and "capture local holds as transits" existed, we'd probably opt to use "capture local holds as transits"
15:57 mmorgan We've had staff users occasionally turn it on by mistake and be VERY confused.
15:59 jeff tsbere++ for providing some stats from existing infrastructure
15:59 jeff mmorgan++ for being willing to also provide stats
15:59 jeff i'll probably throw a query out to the list if i remember to next week.
16:13 jlitrell joined #evergreen
16:14 * jeff discards draft email requesting gitadmin@ create top-level Hatch repo
16:14 jeff (since it already exists!)
16:16 mmorgan Hmm. So working in the web client, I'm noticing lots of warnings about unsaved data when leaving a page.
16:16 kmlussier mmorgan: Which page?
16:16 mmorgan Both in the patron editor and item editor.
16:17 kmlussier mmorgan: Take a look at bug 1581196
16:17 pinesol_green Launchpad bug 1581196 in Evergreen "webstaff: fix dirty form detection for the patron editor" [Medium,Confirmed] https://launchpad.net/bugs/1581196
16:17 kmlussier There's a patch there that I don't think has been merged to master
16:18 mmorgan Ok, that looks promising.
16:18 mmorgan kmlussier++
16:18 kmlussier mmorgan: However, it doesn't ook like it touches the copy editor.
16:20 kmlussier ook, that's a new word
16:20 mmorgan Been looking mostly at the patron editor, will need to try the copy editor again to be sure.
16:20 mmorgan Ook!
16:20 mmorgan I like it :)
16:21 berick don't ook at me, I'm hiddeous
16:26 JBoyer berick, I think you mean iddeous. :D
16:27 jeff berick: i rebased collab/berick/hatch2 to eliminate the root commit (the "random" repo readme) and pushed to http://git.evergreen-ils.org/?p=working/Hatch.git;​a=shortlog;h=refs/heads/user/jeff/master_candidate -- do you have thoughts/objections/alternate plans regarding this becoming the master branch on the top-level Hatch.git repo?
16:27 afterl left #evergreen
16:27 jeff berick: as a next step in making Hatch be a "thing that exists outside the random repo"?
16:28 berick JBoyer: :)
16:28 berick jeff: no objections.
16:28 berick and thanks!
16:28 tsbere jeff: I think I remember making that repo at a hackaway.
16:36 jeff that moment when you think you're starting to understand git, then you run "git gc" and your repo swells by a third.
16:37 kmlussier There a moment when you think you're starting to understand git?
16:37 kmlussier *There's
16:37 tsbere jeff: I had that happen at least twice. Once when a sparse file stopped being sparse and another time when it de-compressed a few things that had previously been compressed.
16:37 jeff kmlussier: I know -- the epitome of hubris, right?
17:03 jeff anyway, Hatch has a home outside of random now: http://git.evergreen-ils.o​rg/?p=Hatch.git;a=summary
17:04 gsams_ joined #evergreen
17:06 gsams joined #evergreen
17:12 mmorgan left #evergreen
17:13 jvwoolf left #evergreen
17:19 kmlussier jeff++
17:28 kmlussier @quote random
17:28 pinesol_green kmlussier: Quote #67: "< Rogan_Ni> Star Wars" (added by berick at 01:38 PM, September 17, 2013)
17:38 mrpeters left #evergreen
17:43 Bmagic berick++

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat