Evergreen ILS Website

IRC log for #evergreen, 2015-01-07

| 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
00:00 bshum dbwells++ # 2.6.5
01:16 akilsdonk joined #evergreen
04:08 dbwells joined #evergreen
04:54 pinesol_green Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
06:12 BigRig joined #evergreen
06:12 phasefx joined #evergreen
06:12 maryj joined #evergreen
07:38 rjackson-isl joined #evergreen
07:43 Shae joined #evergreen
07:57 jboyer-isl joined #evergreen
08:05 collum joined #evergreen
08:19 ericar joined #evergreen
08:34 Dyrcona joined #evergreen
08:34 Dyrcona @wunder 01845
08:34 pinesol_green Dyrcona: The current temperature in WB1CHU, Lawrence, Massachusetts is 12.9°F (8:34 AM EST on January 07, 2015). Conditions: Scattered Clouds. Humidity: 100%. Dew Point: 12.2°F. Windchill: 12.2°F. Pressure: 29.87 in 1011 hPa (Steady).  Wind Chill Advisory in effect from 5 PM this afternoon to 10 am EST Thursday...
08:36 csharp yowza
08:36 csharp @wunder 30345
08:36 pinesol_green csharp: The current temperature in Lakeside, Atlanta, Georgia is 32.5°F (8:30 AM EST on January 07, 2015). Conditions: Clear. Humidity: 66%. Dew Point: 23.0°F. Windchill: 28.4°F. Pressure: 30.29 in 1026 hPa (Rising).  Wind Advisory in effect from 10 am this morning to 1 am EST Thursday...
08:42 Dyrcona Yep. Winter finally showed up.
08:45 StephenGWills_ joined #evergreen
08:48 abowling joined #evergreen
08:53 Dyrcona @wunder zqn
08:53 pinesol_green Dyrcona: An error has occurred and has been logged. Please contact this bot's administrator for more information.
08:53 julialima_ joined #evergreen
08:53 Dyrcona @wunder wzqn
08:53 pinesol_green Dyrcona: Error: No such location could be found.
08:53 Dyrcona Oh well.
08:58 StephenGWills_ left #evergreen
09:10 gmcharlt @wunder 30096
09:10 pinesol_green gmcharlt: The current temperature in City of Berkeley Lake, Berkeley Lake, Georgia is 32.5°F (9:05 AM EST on January 07, 2015). Conditions: Clear. Humidity: 60%. Dew Point: 19.4°F. Windchill: 32.0°F. Pressure: 30.27 in 1025 hPa (Falling).  Wind Advisory in effect from 10 am this morning to 1 am EST Thursday...
09:12 mrpeters joined #evergreen
09:16 mmorgan joined #evergreen
09:18 rjackson-isl @wunder 46280
09:18 pinesol_green rjackson-isl: The current temperature in Clay Township N7CZ, Indianapolis, Indiana is 3.0°F (9:18 AM EST on January 07, 2015). Conditions: Partly Cloudy. Humidity: 80%. Dew Point: -2.2°F. Windchill: -5.8°F. Pressure: 30.57 in 1035 hPa (Falling).  Wind chill warning in effect until 10 am EST Thursday...
09:19 finnx joined #evergreen
09:19 gmcharlt rjackson-isl: YOU WIN!
09:19 * gmcharlt is so sorry
09:20 rjackson-isl I lose!
09:20 finnx joined #evergreen
09:23 RoganH joined #evergreen
09:26 ericar_ joined #evergreen
09:35 buzzy joined #evergreen
09:51 jeff @wunder KTVC
09:51 pinesol_green jeff: The current temperature in Traverse City, Michigan is 6.8°F (9:36 AM EST on January 07, 2015). Conditions: heavy snow. Humidity: 87%. Dew Point: 3.2°F. Windchill: -11.2°F. Pressure: 30.39 in 1029 hPa (Falling).  Winter Weather Advisory in effect until noon EST today...
09:52 dbs @wunder p3e 2c6
09:52 pinesol_green dbs: The current temperature in Sudbury, Ontario is -17.0°F (9:50 AM EST on January 07, 2015). Conditions: Low Drifting Snow. Humidity: 71%. Dew Point: -23.8°F. Windchill: -16.6°F. Pressure: 30.29 in 1026 hPa (Rising).
09:52 * dbs walked into work (1/2 hour) this morning
09:53 dbs windchill is warmer than the actual temperature? Umm.
09:54 jeff heh
09:54 jeff must be summer breezes.
09:59 * csharp now has https://www.youtube.com/watch?v=MsW8rXPcnM0 in his head
10:16 jeff visibility is bad this morning.
10:17 jeff METAR KTVC 071453Z 34014G23KT 1/4SM +SN BLSN VV004 M14/M15 A3040 RMK AO2 PK WND 32028/1434 SLP309 P0001 60001 T11391150 51040 $
10:35 RoganH joined #evergreen
10:41 jeff METAR falls somewhere between SIP messages and serials holding/prediction codes.
10:42 Dyrcona So between background radiation and line noise for level of meaningfulness?
10:43 jboyer-isl tag soup; some hot, some cold, some smooth, some chunky, all one bowl!
10:43 jboyer-isl HTML is also this style of dish.
10:44 Dyrcona Which HTML? ;)
10:44 jboyer-isl Exactly.
10:45 Dyrcona <blink/>
10:54 csharp @quote random
10:55 pinesol_green csharp: Quote #73: "< dbs> jumped from LaTeX-like markup on the commodore 64 to WordPerfect w/ reveal codes to straight-up WYSWIWYG stuff, then back to SGML/XML things like DocBook, then abstracted out to AsciiDoc, now working closer to the source - circle of doc life" (added by csharp at 10:17 AM, January 13, 2014)
11:02 * csharp checks lupin
11:02 berick csharp++
11:02 berick was just trying to load a page...
11:02 ericar_ joined #evergreen
11:03 * csharp restarted apache
11:03 csharp should be back up
11:03 berick yep
11:03 csharp gonna wade into the server logs to see what was up
11:03 RoganH @blame apache
11:03 pinesol_green RoganH: It really IS apache's fault!
11:04 RoganH At first I assumed it was just my crappy ISP.  "Oh, you'll just randomly block just one domain's traffic from loading.  Well, not the first time."
11:05 * jeff watches for long-running downloads
11:05 jeff plan: check. time:
11:07 Bmagic Is there a switch somewhere to make the action triggers that send emails to change the email headers to flag the content as HTML instead of plain/text ?
11:08 eeevil Bmagic: the templates that send email control the headers, IIRC, so you can just set the mime type I'd think
11:08 Bmagic I was wondering about that
11:09 * Dyrcona shudders.
11:09 bshum https://bugs.launchpad.net/evergreen/+bug/1031335
11:09 pinesol_green Launchpad bug 1031335 in Evergreen 2.7 "Email templates should always escape headers" (affected: 2, heat: 10) [Undecided,Incomplete]
11:09 bshum It's incomplete, but some of this was discussed on that bug I think?
11:10 * bshum goes back to randomly digging for explanations for "weird holds"
11:12 jeff huh. the "maintenance required" indicator on that METAR report hasn't been on for as long as I assumed -- just kicked in this morning.
11:15 berick bshum: time permitting, i may create a page like this for EG release cutting.. I just want to be sure you didn't already do that and I missed it.  http://wiki.evergreen-ils.org/doku.ph​p?id=dev:release_process:opensrf:2.0
11:18 bshum berick: Sounds good, we should probably delete this old page for Evergreen 2.0 (subversion steps)
11:18 bshum http://wiki.evergreen-ils.org/doku.php​?id=dev:release_process:evergreen:2.0
11:19 bshum berick: dbwells shared with me a google doc when we were RMs that outlined the steps process.
11:19 bshum I added some minor notes to it based on my own dealings
11:19 bshum Maybe we can use that as a baseline to create a new page.
11:20 berick bshum: mind sharing it back? i'd like to see your notes
11:21 bshum berick: Most of my notes were for pre-req stuff
11:21 bshum Which you'll handle better once we merge the dev/packager makefile stuff
11:22 jwoodard joined #evergreen
11:24 bshum berick++ # let me know once you have a wiki page going.  I'll be glad to help read over and add further notes or refinements.
11:25 berick bshum: thanks!
11:26 berick bshum: did you make any headway on finalizing the list of needed prereqs for building releases on servers w/o EG installed?
11:26 berick thinking back to the dev/packager makefile stuff
11:26 bshum berick: It wasn't too much extra stuff.  I can probably get you a list momentarily of specific packages.
11:27 berick that would be great.  no rush, though
11:33 bshum berick: Yeah it's not a long list
11:33 bshum make, automake, autoconf, libtool (just to be sure the basics are done)
11:34 bshum libtemplate-perl liblocale-maketext-lexicon-perl
11:34 bshum That's it.
11:35 bshum Everything else is covered.
11:35 berick great, thanks
11:35 berick i'll add those to the LP branch
11:35 bshum Oh, I guess except for source-highlight asciidoc :)
11:35 bshum But that's for documentors
11:36 berick hmm
11:36 berick that's a good question.  i usually generate asciidoc output on the same machine I build releases on
11:36 berick and it it part of the process
11:36 bshum Right.
11:37 bshum Not hyper critical, just naming extras
11:37 berick so, we'd also need asciidoc (and source-highlight)
11:39 bshum We talked about calling the developer target if we select packager right?
11:39 bshum Since we need the developer pre-req's to build the web client properly
11:39 berick yes, i'll add that too
11:39 bshum berick++ # looking forward to testing :)
11:42 dbwells berick: bshum: I'd be happy to look over and otherwise help out with a EG build wiki page.  For maintenence releases, I have it mostly boiled down now to a list of 20 or so commands which I copy and paste :)
11:42 dbwells A few parts could be easily scripted, but I haven't gotten lazy enough yet.
11:45 berick dbwells: this list of which you speak...
11:45 berick ;)
11:45 berick mind sharing?
11:45 berick together we'll triangulate the real process
11:45 Dyrcona I have. I've scripted the whole thing.
11:46 Dyrcona Though I have a few manual steps in the middle of the process.
11:46 dbwells berick: sure, I'll paste it up somewhere.
11:47 Dyrcona Although, you're talking about building tarballs... Never mind me.
11:55 pastebot "dbwells" at 64.57.241.14 pasted "Dan's quick and dirty maintence build commands" (36 lines) at http://paste.evergreen-ils.org/24
11:56 dbwells berick: bshum: ^^ (also, I can't spell maintenance, apparently)
11:57 dbwells nothing special to it, I just got tired of forgetting a little detail here and there
11:58 berick dbwells++
11:58 berick will def refer to this
11:59 dbwells Those cherry-picks might be from local branches.  If that's the case, I can find the appropriate live commits.
11:59 dbwells They are definitely out there in the tags.
11:59 berick dbwells: nope, i see 'em
12:00 dbwells cool
12:02 berick dbwells: should b347e2bb be merged to master?
12:02 pinesol_green [evergreen|Dan Wells] Changes to smooth out make_release - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=b347e2b>
12:03 berick heh, pinesol_green++
12:04 dbwells berick: Yeah, I mentioned that in the notes at the bottom of the paste.  I think so.  I am not 100% confident that the ... range is better, but it seemed to give a better changelog for me in certain cases.
12:04 dbwells The HEAD url thing is just broken the way it is, so that part I am more confident in.
12:04 * berick would have to man-page that one
12:05 berick the '...', i mean
12:07 bshum Hmm, just noticed tsbere's idea for https://bugs.launchpad.net/evergreen/+bug/1018011
12:07 pinesol_green Launchpad bug 1018011 in Evergreen "Incorrect copy status caused by reshelving process colliding with item checkout" (affected: 5, heat: 24) [Medium,Confirmed]
12:08 bshum dbwells: berick: Hmm, I haven't added that commit prior to any of my builds for 2.7 series.  But I agree with the general direction :)
12:09 dbwells bshum: It's a very small deal :)
12:11 dbwells berick: It's pretty dense, but I think this helped me understand it:  http://git.661346.n2.nabble.com/Ques​tion-about-right-only-td6763571.html
12:12 dbwells Basically, I think 'right-only' only works with the '...' range selector, so it helped filter out bug fixes which had gotten into, for example, both 2.5.x and 2.6.0.
12:15 dbwells To quote the page "For example, --cherry-pick --right-only A...B omits those commits from B which are in A or are patch-equivalent to a commit in A."
12:18 dbwells The "patch-equivalent" part is what we are after.  Otherwise, ".." does the same thing for us.
12:19 berick dbwells: in the specific case of a bug committed to both 2.5.x and 2.6.0, i'm curious why we wouldn't want it represented in the 2.5.x release notes.
12:19 berick or am I misunderstanding?
12:20 dbwells No, this keeps it from reappearing in the 2.6.0 changelog, not the other way.
12:21 jihpringle joined #evergreen
12:21 berick oh, ok, i am misunderstanding.  thanks.
12:22 dbwells With ".." we see every commit since the common ancestor.  With "--cherry-pick --right-only A...B", we see every commit since the common ancestor, minus those which have an equivalent commit on "the other side".  That's my understanding, at least :)
12:23 dbwells Plus, I think the "--cherry-pick --right-only" options we have in there do nothing with the ".." operator, so something has to give.
12:24 * berick escorts 2 git commands into the thunderdome
12:34 dbwells I think it only matters when crossing a major version, as that's the only time the common ancestor won't be linear with the possible changes.
12:36 dbwells berick: You're probably trying the same thing, but I just tested a changelog from rel_2_5_5...rel_2_6_0 vs rel_2_5_5..rel_2_6_0, and the "..." successfully excluded 950dede414 / 6ec8bcea7e as being equivalent (and thus not a real change).
12:36 pinesol_green [evergreen|Liam Whalen] LP#1037171 Removed Expert Search paramters from subject links - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=950dede>
12:36 pinesol_green [evergreen|Liam Whalen] LP#1037171 Removed Expert Search paramters from subject links - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=6ec8bce>
12:38 dbwells With the full command being that from the build script: git log --cherry-pick --right-only --no-merges --pretty --summary --numstat rel_2_5_5...rel_2_6_0
12:38 dbwells vs. git log --cherry-pick --right-only --no-merges --pretty --summary --numstat rel_2_5_5..rel_2_6_0
12:39 berick dbwells: got sidetracked, so thanks for testing..  shall I pull it into master?
12:40 dbwells berick: Yes, I am confident now :)
12:40 berick cool, will do in a few minutes
12:40 bshum dbwells++
12:41 dbwells berick: thank you, sir
12:50 bmills joined #evergreen
12:52 * berick notes this will have to change again when we move to git-tag'ed releases
12:52 berick if we do, that is
12:52 bshum +1 :)
12:54 pinesol_green [evergreen|Dan Wells] Changes to smooth out make_release - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=7af5e29>
13:28 julialima_ joined #evergreen
14:00 b_bonner joined #evergreen
14:00 kmlussier Dyrcona: Cake pans? That sounds fun!
14:01 Dyrcona Yep. Moses Greeley Parker Memorial Library in Dracut.
14:02 kmlussier Dyrcona: Hmmm...this is a case where the custom code NOBLE uses to incorporate digital images in their records might come in handy at MVLC.
14:03 kmlussier Because it would be nice to see what the cake pan looks like before making a trip to the library to check it out.
14:03 Dyrcona Yes, we thought of that.
14:03 Dyrcona They don't allow requests, IIRC.
14:04 kmlussier Also, they have a lot of pans on one bib record. It probably wouldn't work well in that case.
14:05 dbs Oh, that's a cataloguing anti-pattern
14:06 dbs Can't define the proper extents (9" x 9" x 2") if you don't have one record per different cake pan dimensions, etc.
14:08 collum We had pans at one time, but they were also on a single bib.
14:08 collum I wonder how you would measure that Mickey Mouse shaped pan.
14:09 Dyrcona Yep.
14:09 jeff by volume? :-)
14:10 Dyrcona Ideally, you'd want a different bib record for each shape.
14:13 RoganH Under physical description you could define it as irregular shape.  Hmmm.... if you measured enough points of reference you could define the shape.  Where to put that.....
14:15 Dyrcona RoganH++ for mentioning tools
14:15 RoganH I'd say you could define dimensions in the 300 even of an irregular shape.
14:18 Dyrcona I suppose my answer could have been more helpful such as offering information about how they're cataloged and offering to put them in touch with someone at the library.
14:21 Dyrcona I guess you'd catalog a sewing pattern as an artifact.
14:21 RoganH I assume at this point that everything that happens by email is a hallucination and they should go on a vision quest to find the right person.  Maybe their spirit animal will help them.
14:21 Dyrcona heh.
14:21 RoganH (Yes, it has been one of those weeks.)
14:38 berick @band add Sewing Pattern Spirit Animal
14:38 pinesol_green berick: No, you're a puzzleheaded kraken!
14:38 berick pinesol_green: i know
14:38 pinesol_green berick: Yeah, well, you know, that's just like uh, your opinion, man.
14:56 buzzy joined #evergreen
14:59 krvmga joined #evergreen
15:00 Dyrcona heh
15:01 Dyrcona @eightball Will it blend?
15:01 pinesol_green Dyrcona: What are you asking me for?
15:01 sbrylander joined #evergreen
15:01 mtcarlson joined #evergreen
15:28 dreuther joined #evergreen
15:38 collum kmlussier++  Our serials person was very excited when she looked at the CWMars serials list.
15:49 kmlussier collum: Glad to hear it helped somebody!
15:54 kmlussier tspindler++ #for creating the script that updates the C/W MARS serials page.
15:54 kmlussier @karma tspindler
15:54 pinesol_green kmlussier: Karma for "tspindler" has been increased 25 times and decreased 0 times for a total karma of 25.
15:57 bshum kmlussier++
15:57 bshum :D
15:59 dreuther_ joined #evergreen
16:00 nhilton joined #evergreen
16:01 vlewis joined #evergreen
16:02 vlewis_ joined #evergreen
16:09 jwoodard Hello good peoples. Is it possible to get a list of patrons with duplicate accounts in at multiple libraries through the reports interface.
16:10 jwoodard What I want to know is if patrons at our libraries have accounts at other consortium libraries if that makes any sense.
16:11 bshum So... probably a list based on factors like similar names?  (assuming that you can't re-use barcodes for being unique)
16:11 * bshum doesn't know offhand of how to do something like that via the reports module.
16:12 jeff bshum: it's all just matchpoints. :-)
16:13 bshum jeff: True enough.
16:13 jeff first_given_name + family_name + dob + zip code, etc.
16:13 jeff it seems likely that you're going to run into problems of accuracy.
16:14 Dyrcona I've done things like that recently, but not in reports.
16:14 Dyrcona It's not easy.
16:15 jeff i wouldn't recommend using reports. it would be possible to get a report saying that X patrons have exactly this name and exactly this phone number, or exactly this name and address, but you're going to have very little room for fuzziness or other tweaking.
16:16 jeff Other than at registration time, is detection of duplicate patrons something that would be a feature many would desire?
16:17 jeff If you've access and feel comfortable with SQL, I'd start there.
16:25 jwoodard Thanks for the ideas. I know a feature to detect duplicate patrons would be received well in our consortium.
16:27 jwoodard I didn't think it was possible through the reports module but though I would ask.
16:27 jeff jwoodard: how would you see yourself using such a feature?
16:29 jwoodard Recenlty we had a very larger library join our consortium. When they join many of their patrons had library cards with several of our consortium libraries that were nearby.
16:30 jwoodard We would use it to identify patrons with duplicate accounts and merge those accounts.
16:32 jwoodard Also to prevent patrons from running up fines at one library and getting another card and doing the same but at a different library.(a issue we have ran into a few times)
16:32 * jeff nods
16:33 jeff there is built-in functionality that attempts to alert staff when they find a patron with the same address/etc.
16:33 jeff that doesn't help in the case you described where a migration took place and resulted in duplicate patrons.
16:34 jwoodard That and I'm OCD about things like this. Duplicate records are the enemy to my sanity.
16:35 jeff "incorrectly merged" records are also a bit of a pain.
16:35 jeff sometimes "this is obviously a duplicate"... isn't.
16:36 jeff so, given a report of "duplicate" patrons -- would you flag them so that the patron would need to clarify if they were duplicate or not, or would you merge first, ask questions later?
16:36 jeff (that second option scares me a bit)
16:37 nhilton_ joined #evergreen
16:38 jwoodard We are developing policies to handled that now. The way it would be handled is that the home library would be contacted and they would handled as our policy dictates.
16:38 jeff in a given set of patrons seen as duplicate to each other, you could mark all but the oldest (or "nearest", whatever) accould as inactive and flag it with an alert message -- or just put an alerting note on all of them, or...
16:39 julialima_ left #evergreen
16:40 jwoodard In that scenario one library would handle contacting the patron and from there the decision to merge or not would be made.
16:49 nhilton joined #evergreen
16:55 Dyrcona jwoodard: We had a similar scenario here last year.
16:55 Dyrcona We basically did what Jeff suggested by finding them using SQL queries.
16:56 Dyrcona Sorry I haven't paid much attention to the conversation. One of our servers decided to eat itself.
17:03 bshum joined #evergreen
17:04 mceraso joined #evergreen
17:08 nhilton_ joined #evergreen
17:23 mmorgan left #evergreen
17:52 dreuther joined #evergreen
18:10 dreuther_ joined #evergreen
19:45 gsams joined #evergreen
20:37 buzzy joined #evergreen

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