Evergreen ILS Website

IRC log for #evergreen, 2014-11-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
01:34 gsams joined #evergreen
05:07 chatley joined #evergreen
05:48 csharp @later tell gsams when our libraries tell us that transactions take 5, 10, or 15 minutes, it's always something on their end related to workstation duress or network congestion, FYI.  You can verify how long things are taking on the server side and show that to your end-user staff for proof.
05:48 pinesol_green csharp: The operation succeeded.
06:14 csharp @blame reports
06:14 pinesol_green csharp: reports 's bugfix broke csharp's feature!
06:14 remingtron_ joined #evergreen
07:13 wsmoak joined #evergreen
07:39 sarabee joined #evergreen
08:18 ericar joined #evergreen
08:21 mrpeters joined #evergreen
08:22 rjackson-isl joined #evergreen
08:27 akilsdonk joined #evergreen
08:38 mmorgan joined #evergreen
08:50 Dyrcona joined #evergreen
09:05 tspindler joined #evergreen
09:19 mmorgan csharp: How do you go about verifying how long transactions are taking on the server side? From logs?
09:27 csharp mmorgan: yep - you have to get the threadtrace from the activity log, then grep for that in osrsys logs (this assumes your system is set up to use syslog and uses the rsyslog config at http://git.evergreen-ils.org/?p=Evergreen.git;a=b​lob;f=Open-ILS/examples/evergreen-rsyslog.conf;h=​ba25cea727c4aadead5635197f86040392c5ecf2;hb=HEAD)
09:29 csharp example log line:
09:29 csharp 2014-11-07 09:28:48 brick02-head osrf_json_gw: [ACT:17179:./osrf_json_gatew​ay.c:323:14153703101717933] [216.130.129.70] [auth token redacted] [en-US] open-ils.circ open-ils.circ.checkin "auth token redacted", {"barcode":"31022007414326","backd​ate":"2014-11-06T00:00:00-05:00"}
09:30 csharp (from activity.log) the threadtrace is 14153703101717933 - you can then grep for that in the osrfsys.HH.log for that hour
09:31 mmorgan ok, gotcha so far
09:32 mmorgan So the actual time the transaction takes, is that the "Message processing duration.."?
09:32 mmorgan looks like a lot of those for the same threadtrace.
09:35 csharp yeah - there's a duration for each individual opensrf message
09:36 mmorgan ok, so the actual time of the transaction is the difference between the first and last timestamp for the threadtrace?
09:36 csharp also, it depends on your loglevel (set in opensrf_core.xml) as to whether you get duration for full "transactions" (for lack of a better term to describe something like a checkin)
09:36 csharp yes
09:37 csharp if you up one of the loglevel values to debug (4), you get more information
09:37 csharp but also far larger log files, so it's a tradeoff
09:39 csharp I think it's the private opensrf loglevel that you'd need to increase - we do that on test servers, but not production
09:40 yboston joined #evergreen
09:41 mmorgan ok thanks. This is all really helpful. I spend a fair amount of time poking through logs, nice to understand them a little better.
09:41 mmorgan csharp++
09:44 csharp mmorgan: happy to help!  I've been meaning to put together a presentation for an EG conf on stuff like this, but I'm always afraid it will reveal more what I *don't* know ;-)
09:45 csharp I'm kicking around an idea for a sys admin full- or half-day training as a preconf on the "hackfest" day
09:46 mmorgan csharp: Both awesome ideas!
09:46 csharp getting people like Callender and bshum and mtate to talk about sys admin best practices, logs, Linux, etc.
09:47 csharp monitoring... that kind of thing
09:48 mmorgan unless I've missed it (which is entirely possible) there doesn't seem to be much reference info for novices for reading logs and day to day sysadmin type stuff, so that type of session would be great
09:55 Dyrcona csharp: pingest.pl is going to get some major work done on it this morning.
09:56 Dyrcona csharp: I am going to add options to skip the browse ingest, the metabib field ingest, and the record attribute ingest. I'll probably add options to override the constants for batch size and max children.
10:11 bshum Sigh, I hate that I always forget to install ntp to keep things better sync'd on our servers for time :(
10:13 kmlussier joined #evergreen
10:27 kmlussier ie--
10:27 kmlussier @karma ie
10:27 pinesol_green kmlussier: Karma for "ie" has been increased 0 times and decreased 61 times for a total karma of -61.
10:39 jeff bshum: nagios checks for ntp are handy there.
10:43 bshum jeff: I'll add it to my  list of things to build into my monitoring server
10:43 bshum When I build it later :)
10:44 csharp jeff: great idea
10:45 csharp Dyrcona: awesome!  I'm using yesterday's version on a test server now
10:46 RoganH joined #evergreen
10:48 kmlussier joined #evergreen
10:51 Dyrcona csharp: cool. I'm testing the command line options to skip browse, search and facet reingest and just do the record attributes, now.
10:51 * csharp signs off on the fix for bug 1390225
10:51 pinesol_green Launchpad bug 1390225 in Evergreen 2.7 "auth timeout redirect causes an error" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1390225
10:51 csharp Dyrcona: rock on
10:54 rfrasur joined #evergreen
10:54 rfrasur @karma parts
10:54 pinesol_green rfrasur: Karma for "parts" has been increased 26 times and decreased 26 times for a total karma of 0.
10:54 csharp hahaha
10:55 rfrasur :D, mornin'
10:55 csharp @who will bring the Force back into balance?
10:55 pinesol_green RBecker will bring the Force back into balance.
10:56 rfrasur RBecker is idle.  Muahahahahah!
10:57 * rfrasur accepts ceasefire for today.
10:57 rfrasur Just ridin' the wall.
11:01 kmlussier rfrasur: If you have the urge to send negative karma somewhere, you can always give it to IE. We can agree on that, right? :)
11:01 rfrasur We can.  We definitely can.
11:01 rfrasur I'd like to do more than send negative karma to IE.
11:02 rfrasur I'd like to deface its monuments and strike it from the annals of history.
11:02 rfrasur Can we do that in here?
11:02 * kmlussier was stuck on a computer that only had IE for 15 minutes this morning.
11:02 kmlussier rfrasur: Absolutely!
11:02 rfrasur Ugh.  My has it off to you.  I wouldn't have made it 15 minutes.
11:03 rfrasur yeah. s/has/hat
11:03 Shae joined #evergreen
11:09 buzzy joined #evergreen
11:18 Stompro bshum: Bug 1390138 - I had no trouble upgrading from 2.6.3 to 2.7.1 using the upgrade docs I edited.  Now I'm just trying to figure out the client auto update stuff.  I noticed that there are no upgrade docs for opensrf, is that on anyone's todo list?
11:18 pinesol_green Launchpad bug 1390138 in Evergreen "Documentation: 2.7 upgrade docs need to be updated" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1390138 - Assigned to Josh Stompro (u-launchpad-stompro-org)
11:19 bshum Stompro: I don't know of any active work on creating upgrade steps for OpenSRF
11:19 yboston Stompro: neither have I
11:23 Stompro Ok, I'll put that on my list of things to take a stab at, it is mostly just stripping out the things that don't need to get redone from the opensrf install docs.  I would also like to see the opensrf install docs start with downloading and untaring the software, I think someone was confused by that on the listserve a week or two ago.
11:23 RoganH joined #evergreen
11:25 Stompro Oh, and I think if we moved the opensrf user creation to the first step, and then just did the upgrade/install using the opensrf user as the non-priviledged user, it would match up with the evergreen install/upgrade style a little better.
11:36 sandbergja joined #evergreen
11:47 bshum Stompro: That's not always assumed anymore that the opensrf user is always the user used to do all the work.
11:48 bshum But I get what you mean :)
11:54 Dyrcona Stompro: Upgrading OpenSRF is just reinstall it.
11:56 Dyrcona As for making auto-updates clients, include updates-client in the make arguments when you build the client.
11:58 Stompro Dyrcona: But you don't need to do all of the steps that a first time install needs.  You don't need to create the Opensrf user, you don't need to make any ejabberd changes, you don't need to adjust the /openils/conf files.
11:58 Dyrcona Well, yeah, that *should* be obvious.
12:00 Dyrcona bshum dbwells: Should we have a 2.5.9 target?
12:01 dbwells Dyrcona: yes, for security bugs.  Feel free to add one if you can, or let me know and I will.
12:01 Dyrcona I'm mainly thinking in terms of lp 1390225 as it is related to a security fix.
12:01 pinesol_green Launchpad bug 1390225 in Evergreen 2.7 "auth timeout redirect causes an error" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1390225 - Assigned to Jason Stephenson (jstephenson)
12:01 Dyrcona I think I can.
12:02 Dyrcona I guess a better question is does that bug warrant another 2.5 release?
12:02 dbwells Probably not.
12:03 dbwells If the "hotfix" works fine, I'd lean toward a "b" release.
12:04 Dyrcona OK. I'll push it to rel_2_5 if it works for me and let you sort it out. :)
12:04 jeff this version of postgresql is too old to support multirow INSERT syntax.
12:04 Dyrcona jeff: What version?
12:04 dbwells Dyrcona: sounds good, thanks!
12:04 jeff psql (PostgreSQL) 8.1.19
12:05 Dyrcona jeff: I thought that version could....Maybe that was 8.3?
12:05 jeff Dyrcona: 8.2 and above, based on docs.
12:06 Dyrcona Ah, so looks like it is time to upgrade, then. :)
12:07 jeff well past.
12:14 nhilton joined #evergreen
12:20 Stompro Dyrcona: auto-updates - I think it is more complex than that, at lease for my testing system.  Looks like the auto-update requires a valid SSL cert, and some options that are set at configure time.  And it doesn't look like the auto-update works if I used the staff client listed on the egdownloads page, you have to have already installed a custom built staff client.
12:21 tsbere Stompro: Auto-updates don't work with community staff clients, but you don't have to use configure-time options. Staff-client build time options work as well, though the configure time options speed that up. As for the valid SSL cert, if your update host starts with http:// you can bypass that (though I wouldn't do that for production systems)
12:22 * tsbere will also admit to not having *tested* http:// updates in quite a while, though
12:23 Stompro tsbere: Thanks for the tips.
12:24 tsbere Stompro: Oh, and while it is certaintly *easier* when it is, your updates host doesn't have to be the same server as your evergreen install.
12:26 Dyrcona Heh. You'd think I would have rememberd updates_host. I just did an update with updates-client this morning. :p
12:28 Stompro tsbere++ Dyrcona++  I know this stuff is all on the wiki, I just haven't gotten through it all yet, there is a lot of info there.
12:28 Dyrcona Yep, there is a lot on the wiki.
12:37 pinesol_green [evergreen|Mike Rylander] LP#1390225: redirect to ctx.home_page instead of through ctx.logout_page - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=31b47b2>
12:37 pinesol_green [evergreen|Mike Rylander] LP#1390225: Fail to care about errors from auth.session.delete - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=8a5f306>
12:47 Dyrcona And that was pushed to master, rel_2_7, rel_2_6, and rel_2_5.
12:47 bshum Should we roll a "b" build for all the releases?
12:47 bshum (can't do it right now, but later this evening)
12:48 Dyrcona I'll leave that up to you and dbwells to decide. :)
13:04 * phasefx_ has a fix for lp1386260 if someone wants to poke at it
13:06 bshum bug 1386260
13:06 pinesol_green Launchpad bug 1386260 in Evergreen "DST bugs in perl live tests" (affected: 1, heat: 6) [Undecided,In progress] https://launchpad.net/bugs/1386260 - Assigned to Jason Etheridge (phasefx)
13:08 phasefx_ you can do perl live_t/03-overdue_circ.t to test on a stock install with concerto
13:09 * phasefx_ will add that to the bug
13:10 Dyrcona csharp: I pushed the changes I mentioned to my evergreen_utilities repo. I also made a change to db_upgrade.pl, but you probably don't use that one.
13:10 akilsdonk_ joined #evergreen
13:14 Dyrcona csharp: might want to wait. I just noticed a serious thinko/bug in my pingest changes. It won't work right as is if you try to do attribute and search or facet ingest at the same time.
13:19 phasefx oy, I just fixed one test.. not all of them, doh
13:39 csharp Dyrcona: no problem - I haven't pulled in today's changes yet
13:39 kmlussier joined #evergreen
13:40 phasefx alright, fix re-pushed for bug 1386260  :-)
13:40 pinesol_green Launchpad bug 1386260 in Evergreen "DST bugs in perl live tests" (affected: 1, heat: 6) [Undecided,In progress] https://launchpad.net/bugs/1386260 - Assigned to Jason Etheridge (phasefx)
13:41 Dyrcona csharp: I'm having some "fun" with a little hidden global variable voodo.... I was wondering why it worked at all until I noticed a little $lists++; tucked away in the browse_ingest subroutine.
13:42 jeff blargh. character encoding issues.
13:44 Dyrcona Anyway, the bug I noticed is that I had doubled the number of child processes without also adjusting the number of lists, so the program could exit prematurely.
13:44 Dyrcona I'm tying not to double the child processes this time around.
13:44 Dyrcona jeff: That seems an everyday thing for me.
13:45 jeff yeah.
13:45 Dyrcona "Hi, I'm a MARC8 record."
13:45 Dyrcona "But, no, you contain KOI8 or some such."
13:45 jeff in this case it was my own fault. i was eating MARC-8 with MARC::Record then writing out to a file that I had set as :utf8
13:46 Dyrcona Yep.
13:47 jeff I'm tempted to transform these incoming records to UTF-8 using yaz-marcdump.
13:47 Dyrcona But, I always seem to have the UTF-8 characters that won't map to MARC-8.
13:48 Dyrcona When exporting to a vendor.
13:48 Dyrcona jeff: Might be a good idea.
13:48 Dyrcona I like using yaz-marcdump to convert binary MARC to xml and UTF-8 at the same time, even. :)
13:49 jeff I thought that MARC::Record had more obvious transcoding support. Maybe I'm just thinking of MARC::File::Encode
13:49 Dyrcona Often makes those "vendor records" easier for MARC::Record to digest. Just ignore the comments in the output. :)
13:50 jeff no, if yaz-marcdump can't parse without errors/warnings, you reject the file ;-)
13:51 Dyrcona Then, I'd almost never load anything. ;)
13:51 jeff last if $outcount >= 50;
13:51 * jeff frowns
13:52 jeff i need to develop better habits with regard to "# XXX: remove after testing" or somesuch.
13:52 jeff though part of me wants hard limits (just not that low) in place for some automated things.
13:52 Dyrcona jeff: command line option to limit, by default set to zero, which means do the whole thing.
13:54 Dyrcona Well, perl -c says syntax OK. Guess that means I can commit. :)
13:54 tsbere jeff: I tend to use TODO for things I intend to change/remove before pushing, and XXX for things I see as longer-term warning notes
13:54 jeff what, no "i was able to commit, i guess that means perl -c passed!"? :-)
13:55 jeff tsbere: heh. i often end up with exactly the opposite.
13:55 * jeff wonders what the larger convention is
13:55 jeff i suppose what matters most is the local / codebase convention
13:55 tsbere jeff: Oh, and "To whomever works on this code next:" for "we should do this later, because I am being lazy and don't feel like doing it now" (but I avoid doing that if I know what should be changed/done anyway)
13:59 Dyrcona jeff: I've sometimes added --dry-run or similar options to my own stuff for testing purposes.
13:59 * jeff nods
13:59 jeff lots of this kind of thing is solved by good habits early: config file, command line arguments, etc.
13:59 Dyrcona Or in a case where I was deleting files, a --delete option to actually do the delete, otherwise it just printed out what would be deleted without deleting.
14:00 Dyrcona Yep.
14:00 jeff with some small / quick scripts, things that start as variables in the top of the script never graduate to command line arguments / config files.
14:01 Dyrcona I also like to take advantage of the environment, particularly with DBI scripts.
14:02 Dyrcona I won't configure PGDATABASE in .bashrc, but will have some files hanging around that do set the environment.
14:02 Dyrcona Then I'll source them in my shell before running a DBI script.
14:02 * jeff ponders commit checks that include perl -c as well as "are there any instances of "if (1 || ..."
14:04 tsbere jeff: what about "if (0 && ..."? :P
14:05 jeff right.
14:05 dbwells jeff: I also use XXX for 'near-future' (aka 'I need to come back to this before I finish / close this out') and TODO for 'less-near-future/someday'.  Never thought about it too hard, but I can see others using 'XXX' as more like 'warning/poison!'
14:06 jeff dbwells: yeah, XXX: for me is "if you see this still, you're probably not ready to push"
14:16 jcamins dbwells: "XXX" being what you replace your comments with if you want to maintain a reputation for gentility?
14:17 dbwells jcamins: uh, but of course (?)
14:18 jcamins dbwells: am I the only one whose comments can't be read aloud around children?
14:18 dbwells :)
14:30 Dyrcona I usually use TODO: to tell myself and others where improvement would be welcome. :)
14:33 jeff i also need to make a habit of preserving more one-off ad-hoc queries.
14:34 Dyrcona I keep a git repo for such things actually.
14:34 Dyrcona One for SQL and a separate one for Perl.
14:34 kmlussier dbwells: Is 2.5 only being updated for security releases now?
14:35 jeff Dyrcona: yeah, i was thinking of automatic presevation via .psql_history archiving or other.
14:35 dbwells kmlussier: yes, other than the small bug in the latest release
14:35 kmlussier dbwells: OK, thanks!
14:37 Dyrcona kmlussier: To be fair, the latest fix is a fix for the security fix, so should be considered part of it, IMHO.
14:38 Dyrcona It's not major, though, but people don't like see Internal Server Error pages come up.
14:41 kmlussier Dyrcona: OK. I was just wondering about bug fixes that still have yet to be merged. I just happen to be looking at a lot of them right now since Bug Squashing Day is on its way. :)
14:42 Dyrcona Yep. Makes sense.
14:44 dbwells 2.5 is fading into the ether, but it will always hold a special place in my git history.
14:45 bshum git branch -D rel_2_5
14:45 Dyrcona dbwells++
14:45 dbwells bshum: hey! :)
14:45 bshum :)
14:47 kmlussier dbwells++
14:47 kmlussier :)
15:06 RoganH dbwells++
15:20 akilsdonk joined #evergreen
15:36 rfrasur left #evergreen
15:36 rfrasur joined #evergreen
15:49 RoganH joined #evergreen
15:53 kmlussier OK, I give up on trying to figure this out by myself. I've seen other people create a branch in the working repository out of branches that came from github. I thought I would try doing the same for https://github.com/evergreen-li​brary-system/Evergreen/pull/29
15:53 kmlussier I was looking at the instructions set up to help DIG with github requests. http://evergreen-ils.org/dokuwiki/doku​.php?id=evergreen-docs:github-workflow
15:55 kmlussier When I fetch the branch into my local branch, I get a message that says "From https://github.com/evergree​n-library-system/Evergreen * branch refs/pull/29/head -> FETCH_HEAD
15:55 kmlussier If I try to rebase, it tells me there is nothing to rebase. What am I doing wrong?
15:55 kmlussier Wait, I just tried it again, and it seemed to work this time. Never mind.
15:58 kmlussier @eightball does git like to play mind games with me?
15:58 pinesol_green kmlussier: What are you asking me for?
16:01 kmlussier pinesol_green: No need to get snippy with me.
16:01 pinesol_green kmlussier: You keep using that word. I do not think it means what you think it means.
16:01 pinesol_green kmlussier: I am only a bot, please don't think I'm intelligent :)
16:07 mmorgan kmlussier: Sorry, I don't think I can be of anymore help than pinesol_green :-(
16:08 kmlussier mmorgan: That's okay. At least your not snippy like pinesol_green.
16:08 kmlussier @dessert mmorgan
16:08 * pinesol_green grabs some Mint Chocolate Chip Ice Cream for mmorgan
16:08 Dyrcona kmlussier: Sounds like you forget to specify the remote or local branch that you wanted to rebase onto, but you figured it out.
16:08 * Dyrcona speak like bad fortune cookie.
16:09 Dyrcona Or, type like, rather.
16:09 kmlussier Dyrcona: Yes, I did figure it out, but I'm pretty sure I specified the remote the first time around.
16:09 kmlussier Mmmm...fortune cookie. Now you're making me hungry.
16:11 jcamins Mmmm... cookie.
16:11 jcamins What kind of cookie should I bake this weekend?
16:12 kmlussier jcamins: What's your specialty?
16:12 jcamins kmlussier: I have a lot of specialties.
16:12 jcamins Double-chocolate mint.
16:12 jcamins Coconut oatmeal chocolate chip.
16:13 kmlussier jcamins: That's so funny. When you asked what you should bake, my first thought was a chocolate mint cookie.
16:13 jcamins Sandtarts (lemon-tinged chocolate chip cookies).
16:13 jcamins There we go, then.
16:13 kmlussier Which is what I would be baking if I had the mint chips.
16:13 jcamins Chocolate mint it shall be.
16:13 jcamins Do you have peppermint schnapps?
16:13 kmlussier jcamins: No. My recipe doesn't call for peppermint schnapps. And I don't think I've drunk any kind of schnapps since I was a teenager.
16:14 jcamins If you had peppermint schnapps, you wouldn't need mint chips!
16:15 kmlussier Oh, but mint chips can be used for lots of things, like an ice cream topping.
16:15 jcamins Peppermint extract also works, but it's $5 for a half ounce of extract or $5 for a half gallon of peppermint schnapps that works just as well and never goes bad...
16:15 jcamins True. Any stores that stock them on the way home?
16:15 jcamins :)
16:15 kmlussier Nope. I can only find them online.
16:15 jcamins Maybe I should try a new kind of mint chocolate cookie.
16:15 jcamins Mint-wasabi?
16:16 Dyrcona Waah-saah-beee!
16:16 * kmlussier wanders off to the ghirardelli web site.
16:16 jcamins kmlussier: no time! Chocolate chip cookies have been mentioned, they must be eaten!
16:16 * Dyrcona snickers.
16:17 jboyer-isl Et tu, candy bars?
16:20 jcamins Ooh... I even have food coloring so I can make the wasabi-mint cookies green!
16:21 jeff hah! this is apparently the first time i've had occasion to enter the reporter since "sort by name" became a thing.
16:21 jeff confused me for a moment until i remembered.
16:42 Dyrcona It's Friday! (Well, unless it is Saturday where you are.)
16:43 kmlussier Dyrcona: Happy Friday afternoon!
16:43 Dyrcona kmlussier: Thank you. Same to you!
16:44 Dyrcona I hope I just sent my last work email of the day/week.
16:50 kmlussier tsbere / csharp: What is the status of bug 778989?
16:50 pinesol_green Launchpad bug 778989 in Evergreen "Owning lib of asset.copy_location not visible in Item Attributes Editor UI" (affected: 3, heat: 16) [Medium,In progress] https://launchpad.net/bugs/778989 - Assigned to Thomas Berezansky (tsbere)
16:51 kmlussier We have a Sandbox request for that branch, but it looks like csharp already signed off on it? Is it still being worked on?
16:53 kmlussier Late Friday afternoon is probably not the best time to ask questions. :-/
16:53 berick @who has the friday answers?
16:53 pinesol_green ldw has the friday answers.
16:53 tsbere kmlussier: Well, I think it is good to go, but I unassigned myself.
16:53 kmlussier That makes sense. It isn't late yet for ldw.
16:53 kmlussier tsbere: OK, thanks!
16:55 Dyrcona I suppose we can worry about that one next week.
16:55 Dyrcona It took a couple of years to get signed off, so what's a few more days? :)
16:55 kmlussier Heh
16:56 kmlussier It's nice to see some dusty bugs making forward progress. :)
16:57 tspindler left #evergreen
16:57 Dyrcona Yeah.
16:57 Dyrcona Well, have a nice weekend, everybody!
17:02 kmlussier OK, MassLNC Sandboxes are ready to go for Bug Squashing Day. Have a nice weekend everyone!
17:02 mmorgan Have a nice weekend!
17:11 mmorgan left #evergreen
20:21 pastebot0 joined #evergreen
20:22 mtcarlsoz joined #evergreen
20:22 jcamins joined #evergreen

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