Evergreen ILS Website

IRC log for #evergreen, 2013-06-12

| 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:15 zerick joined #evergreen
00:49 Mark__T joined #evergreen
02:52 paxed jeffdavis: the "mar" is an executable binary, right? sounds like your system is missing a dynamic library the binary needs.
02:54 paxed jeffdavis: "ldd mar" will show the libs it needs.
04:22 serflog joined #evergreen
04:22 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org
06:37 b_bonner_ joined #evergreen
06:48 Mark__T joined #evergreen
07:10 bkuhn joined #evergreen
08:07 bshum jeffdavis: Just guessing, but are you using a 64-bit Ubuntu OS?  If so, it's likely that the problem is that mar doesn't work with that system.  Problem with needing the 32-bit libraries to function.
08:07 bshum jeffdavis: See https://bugs.launchpad.net/evergreen/+bug/1147116
08:07 pinesol_green Launchpad bug 1147116 in Evergreen "Include Mozilla Xul mar tools as subpackage in external" (affected: 2, heat: 10) [Wishlist,Fix committed]
08:09 bshum jeffdavis: We've merged new martool functionality for the future in master/2.5, but for older Evergreens, what we used to do locally was to install ia32-libs prior to running the make commands.
08:09 mrpeters joined #evergreen
08:11 csharp mrpeters: didn't we get mar files working with Ubuntu 64 bit?
08:12 bshum csharp: For a short time there was also a custom mar tool file that Dyrcona was experimenting with that I shared with mrpeters.  But ultimately that wasn't the direction the development took.
08:12 csharp ah - I see
08:13 bshum For that, I think Dyrcona compiled a version of mar that worked with 64-bit Ubuntu manually.  But he couldn't get it to work nicely as part of the automated build process or something.  Or actually it might have been a licensing problem.
08:14 csharp okay - makes sense
08:14 csharp I only have a surface understanding of autoupdate at this point :-/
08:15 csharp as in "Hey it works!" = "I don't have to spend any time on it"
08:15 bshum Heh
08:15 bshum During Vancouver, I thought about using my 5 minute lightning talk time to talk about autoupdate and pitfalls
08:16 bshum But as I explained the idea to someone, it was taking me longer than 5 minutes :D
08:16 csharp yep - that's how that goes
08:16 csharp good program idea for 2014
08:16 bshum Might make a nice longer session though.
08:17 bshum Have to remember that one for later I guess.
08:25 Dyrcona joined #evergreen
08:27 csharp @later tell DPearl if you can share your /openils/conf/opensrf.xml file with me, I'll check it too
08:27 pinesol_green csharp: The operation succeeded.
08:27 Dyrcona paxed: Was it yesterday you asked about upgrade script for master?
08:28 Dyrcona Anyway, for the benefit of everyone, I will once again share my evergreen_utilities repository: http://git.mvlcstaff.org/?p=jason/​evergreen_utilities.git;a=summary
08:28 Dyrcona I added a perl script to handle the upgrades for master last month: http://git.mvlcstaff.org/?p=jason/evergreen_​utilities.git;a=blob;f=scripts/db_upgrade.pl​;h=b5532b789f688ec7afae47bd88b25a2060a6ddf7;​hb=b212ac95e7d7e06a5ed1fdfd075109ca89c16926
08:29 jboyer-isl joined #evergreen
08:30 * Dyrcona just ran it for development this morning, which is why he thought to mention it.
08:34 akilsdonk_ joined #evergreen
08:36 csharp Dyrcona++
08:39 tspindler joined #evergreen
08:41 paxed Dyrcona: i did ask about that, yes.
08:41 Dyrcona Yeah, I couldn't remember if it was yesterday or Monday.
08:42 * Dyrcona is too lazy to look at logs for trivial things. :)
08:42 paxed heh
08:47 Dyrcona @blame naco_normalize
08:47 pinesol_green Dyrcona: naco_normalize stole Dyrcona's ice cream!
08:47 Dyrcona J'aime la glace!
08:47 Dyrcona Too funny....
08:50 DPearl joined #evergreen
08:51 ASMK568 joined #evergreen
08:51 ASMK568 left #evergreen
09:01 ASMK879 joined #evergreen
09:01 ASMK879 left #evergreen
09:01 Meliss joined #evergreen
09:07 ericar joined #evergreen
09:12 Meliss joined #evergreen
09:14 misilot left #evergreen
09:17 collum joined #evergreen
09:19 ASMK324 joined #evergreen
09:19 ASMK324 left #evergreen
09:28 remingtron joined #evergreen
09:28 Ruth joined #evergreen
09:31 kmlussier joined #evergreen
09:33 rfrasur @love overcast days
09:33 pinesol_green rfrasur: The operation succeeded.  rfrasur loves overcast days.
09:34 mmorgan joined #evergreen
09:43 rfrasur jboyer-isl:New IRC clothes.  Nice :)
09:49 csharp jboyer-isl++
09:50 rfrasur makes my (transplanted) hoosier heart proud
10:15 yboston joined #evergreen
10:32 Meliss1 joined #evergreen
10:33 bshum jboyer-isl++
10:34 Ruth joined #evergreen
10:35 jboyer-isl Thanks everyone, I've been AFK for a bit, but appreciate the support!
10:35 rfrasur support today...tasklist tomorrow
10:35 rfrasur muahahah
10:36 rfrasur (and then my browser crashed.  karma? perhaps)
10:40 _zerick_ joined #evergreen
10:40 zerick joined #evergreen
10:43 dboyle joined #evergreen
10:47 collum joined #evergreen
11:14 DPearl I'm continuing with my struggle to get opensrf to work.  csharp has asked for the opensrf.xml file.  (This is a stock file from the release)
11:14 pastebot "DPearl" at 204.193.129.146 pasted "opensrf.xml" (262 lines) at http://paste.evergreen-ils.org/23
11:15 csharp DPearl: so to be clear, you're trying to get opensrf up and running or are you trying to get Evergreen running?
11:16 * csharp asks because this is the example opensrf.xml for OpenSRF, not Evergreen
11:17 * csharp answers his own question by looking at the chat logs from yesterday
11:17 csharp OpenSRF
11:18 DPearl Just following the directions.  Evergreen install says to install opensrf first.  Opensrf says to bring up opensrf!
11:18 csharp yes, that's right
11:18 csharp can you pastebin your /etc/hosts file?
11:19 granitize joined #evergreen
11:21 DPearl csharp: I thought I pasted, but I don't see it yet.   I'll try again.
11:21 csharp ok
11:22 pastebot "DPearl" at 204.193.129.146 pasted "hosts" (12 lines) at http://paste.evergreen-ils.org/25
11:22 csharp ~troubleshoot | DPearl, also this:
11:22 pinesol_green DPearl, also this:: If you're having trouble getting Evergreen to work, please follow this guide for isolating the problem: http://evergreen-ils.org/dokuwiki/doku.ph​p?id=troubleshooting:checking_for_errors
11:23 csharp okay, one more question - are you starting opensrf with 'osrf_ctl -l -a start_all' (as the opensrf user)?
11:23 DPearl csharp: Yeah. I used that. It's useful -- up to the point it says essentially "we don't know what's wrong. go to the IRC"
11:23 csharp ha
11:24 DPearl csharp: That is the command I have been using
11:24 csharp ok
11:24 csharp DPearl: have you looked in /openils/var/log/osrfsys.log?
11:25 * csharp wishes we logged to syslog by default :-/
11:25 DPearl csharp: Yeah.  I couldn't find the proximate cause.  I'll pastebot it.
11:25 csharp thanks
11:25 csharp or at least logged to /var/log
11:26 pastebot "DPearl" at 204.193.129.146 pasted "[2013-06-11 12:28:52] /openils" (776 lines) at http://paste.evergreen-ils.org/26
11:26 DPearl csharp: A few tries are recorded in the log
11:29 mcooper joined #evergreen
11:44 fparks joined #evergreen
11:50 csharp DPearl: and you've confirmed that ejabberd is running?
11:53 DPearl csharp: Seems to be.  I haven't shut it down (except to try things).
11:54 csharp DPearl: have you confirmed that the ejabberd users were created correctly?  (you can verify with 'ejabberdctl registered_users private.localhost' for example)
11:54 DPearl csharp:  I have done that.  Checked the passwords, too.  Frustrating!!
11:55 bshum DPearl: Out of curiosity, what distribution are you using again?
11:55 DPearl csharp: 2.2
11:56 DPearl bshum: opensrf 2.2
11:58 csharp DPearl: seems to me that this has to be a configuration issue that we've not been able to uncover
11:58 csharp since this isn't too far down the path of installation, would it be possible for you to start over with a fresh OS?
11:58 Meliss joined #evergreen
11:59 bshum DPearl: distribution meaning Linux distribution
11:59 DPearl bshum: Debian 6.0.2
12:00 kmlussier Not much on the agenda for today's dev meeting. Feel free to add to it - http://www.evergreen-ils.org/dokuwiki​/doku.php?id=dev:meetings:2013-06-12
12:00 DPearl csharp: I suppose I can try a fresh OS.  I'll try anything at this point!
12:00 jeff_ the errors in the most recent log indicate an authentication error when connecting to ejabberd.
12:01 DPearl jeff_: Yeah, as if the passwords were wrong.
12:04 jeff_ you can use ejabberdctl to verify the passwords, like this:
12:04 jeff_ ejabberdctl check_password router private.localhost 'password' && echo OK
12:04 csharp jeff_: nice - I didn't know that
12:04 jeff_ that will return OK if the user "router" on the domain "private.localhost" has the password 'password'
12:04 kmlussier We've been spending some time on MARC Import Tag Stripping today. We set up  an optional profile owned by the consortium, and the person who set it up can now see the option to use the profile on the Z39.50 screen. However, when another user logs into a workstation at another OU, she can't see the option.
12:05 DPearl Got that in the "bonus" section of the Troubleshooting Doc.  All pws check out  btw.
12:06 jeff_ any special characters in the passwords? that's been a trouble spot before, if care is not taken to escape the special characters on the command line.
12:06 Dyrcona @hate dates and calendar math
12:06 pinesol_green Dyrcona: The operation succeeded.  Dyrcona hates dates and calendar math.
12:06 granitize left #evergreen
12:06 * csharp uses psql for date math (thanks to jeff_'s suggestion somewhat recently)
12:07 jeff_ for example, if the password is password and i check on the command line with password$foo the $foo is interpreted as an empty string, and the check returns OK -- but if i have password$foo in my config file, it isn't going to work. :-)
12:07 jeff_ DPearl: have you pastebinned your ejabberd.cfg file?
12:07 csharp DPearl: and settings-tester.pl works?
12:07 DPearl jeff_: I have been using VERY SIMPLE passwords
12:08 DPearl csharp: Haven't checked settings-tester.pl
12:08 csharp oh wait - that's EG
12:08 bshum Right.
12:08 csharp hmm - it'd be nice to have for the opensrf testing step, though, huh?
12:09 * bshum still dislikes how opensrf is a separately installed thing.  When will we just bundle it all together already :D
12:09 acoomes joined #evergreen
12:10 pastebot "DPearl" at 204.193.129.146 pasted "ejabberd.cfg" (644 lines) at http://paste.evergreen-ils.org/28
12:10 bshum DPearl: Just curious, the .srfsh.xml file has the right password for ejabberd in it right?  Might be unrelated, but for some reason I have this nagging feeling that it needed to be right to work properly.
12:11 jeff_ DPearl: ejabberd.cfg looks fine.
12:11 jeff_ DPearl: do your ejabberd logs have any clues for you?
12:11 csharp bshum: only for srfsh
12:11 bshum csharp: Yeah, that's what I thought, but it just somehow crept into my mind that all had to be right in the world.
12:11 bshum But maybe I'm misremembering
12:11 jeff_ DPearl: ejabberd logs to /var/log/ejabberd/ejabberd.log by default
12:12 DPearl jeff_: I wish. They just aren't too informative.
12:12 * csharp often forgets for a while to setup ~/.srfsh.xml after installation
12:13 pastebot "DPearl" at 204.193.129.146 pasted "ejabberd log" (3485 lines) at http://paste.evergreen-ils.org/29
12:13 DPearl .srfsh.xml is a trap waiting to happen, but in my case, it's OK.
12:13 jeff_ Failed legacy authentication for jopensrf@public.localhost
12:14 bshum jopensrf?
12:14 jeff_ you've verified that your passwords are correct. how about your usernames?
12:14 DPearl jeff_: I call my opensrf user "jopensrf".
12:14 DPearl jeff_: The "router" user name is "router"
12:14 csharp looks like jopensrf@private.localhost works, though
12:15 jeff_ DPearl: all signs point to your username or password being incorrect for the user "jopensrf" on the domain "public.localhost"
12:15 DPearl csharp: It looks like it works at one point, but fails at another point later in the log, if I remember correctly.
12:15 * csharp suspects a typo in opensrf_core.xml
12:15 csharp oh ok
12:16 bshum Works at one point but fails later...
12:16 bshum How much RAM does the machine have?
12:16 bshum But no, it's just OpenSRF
12:16 bshum Should be really light
12:16 bshum And there'd be errors talking about it killing off processes
12:18 jihpringle joined #evergreen
12:19 Dyrcona OOM killer.....
12:19 jeff_ DPearl: in the ejabberd logs you provided, there are two failed auths for jopensrf@public.localhost, one failed auth for jopensrf@private.localhost, and 25 successful authentications for jopensrf@private.localhost -- there are zero successful authentications for jopensrf@public.localhost -- you should confirm that that user exists in that domain with the password you think.
12:21 jeff_ DPearl: All that said, it could still be another issue that is presenting a problem for you -- this one just bears double-checking.
12:21 kivilahtio joined #evergreen
12:22 DPearl bshum: 7gig
12:22 kivilahtio Does anyone have any experience using the perl debugger in OpenSRF services?
12:22 DPearl jeff_: I'll check 'em again!
12:26 kivilahtio I have been trying to launch a debugging session from the /openils/bin/opensrf-perl.pl but having issues with forking the debugger and subsequently perl services crashing down with this:
12:26 kivilahtio http://pastebin.com/WkkE58DB
12:27 jeff_ DPearl: have you pasted your opensrf_core.xml file?
12:27 DPearl jeff_: Yesterday.  I do it again for convenience.  I'm gonna obscure the pws
12:28 jeff_ DPearl: keep in mind that they were already present in the ejabberd logs
12:29 pastebot "DPearl" at 204.193.129.146 pasted "opensrf_core" (161 lines) at http://paste.evergreen-ils.org/30
12:31 DPearl jeff_: Well, the cat's out of the bag.  If I can get this fixed, I'll change the pws!
12:32 kivilahtio joined #evergreen
12:36 kbeswick joined #evergreen
12:37 jeff_ DPearl: another... have you pasted your opensrf.xml file?
12:37 jeff_ DPearl: and... are you certain that you have successfully restarted ejabberd with that ejabberd.cfg file in place?
12:38 DPearl jeff_: Yes on the restart
12:38 pastebot "DPearl" at 204.193.129.146 pasted "opensrf.xml" (262 lines) at http://paste.evergreen-ils.org/31
12:39 jeff_ DPearl: when was the last time you restarted ejabberd, and what's the current timestamp on your ejabberd.cfg file?
12:39 DPearl -rw------- 1 ejabberd ejabberd 17031 Jun 11 13:17 ejabberd.cfg
12:40 jeff_ okay, and ejabberd seems to have been restarted after that, 2013-06-11 13:37:02 by the logs.
12:41 DPearl jeff_: I emptied the log before restarting, so I agree.
12:46 granitize joined #evergreen
12:51 hopkinsju Is the requirement for password complexity somewhere besides library settings? I'm going to change the text of NOT_STRONG in /openils/var/templates/pas​sword-reset/strings.en-US but I don't know what our requirements are exactly.
12:51 hopkinsju The value in Library Settings is blank...
12:54 Ruth joined #evergreen
12:54 jeff_ DPearl: this command will dump the ejabberd database to a text file, where you can grep it for various things. can you try this, to look at the live maxrate settings? ejabberdctl dump /tmp/ejabberd-dump.txt ; grep maxrate /tmp/ejabberd-dump.txt
12:56 jeff_ i'd also be interested in the output of pgrep -lfu ejabberd (you might need to instal the psmisc package to have pgrep)
12:56 jeff_ DPearl++ for willing troubleshooting
12:57 DPearl jeff_: {config,{shaper,fast,global},{maxrate,500000}}. {config,{shaper,normal,global},{maxrate,500000}}.
12:57 DPearl jeff_++ for helping!
12:58 jeff_ no need to re-dump again, but grepping for max_user and max_stanza_size would help confirm / rule out things
12:58 pastebot "DPearl" at 204.193.129.146 pasted "pgrep output" (2 lines) at http://paste.evergreen-ils.org/32
12:59 jeff_ pgrep output looks fine.
12:59 jeff_ mostly i was looking for signs of multiple ejabberd instances running.
12:59 pastebot "DPearl" at 204.193.129.146 pasted "complete ejabberd dump" (316 lines) at http://paste.evergreen-ils.org/33
13:01 rfrasur There is seriously not enough time in the day.
13:04 jeff_ oh.
13:04 rfrasur pardon.  my comment was not in reference to your work
13:04 jeff_ DPearl: it is possible that you have stray opensrf processes getting in your way.
13:05 DPearl jeff_: Doubt it.  This was failing from my very first attempt to run opensrf on my machine.  I even rebooted the sucker just to be sure.
13:05 jeff_ DPearl: i'd start with the "osrf_ctl.sh -l -a stop_all" command, then log out of your opensrf user shell/sessions, and do a pgrep -lfu opensrf -- if there are processes still there, consider killing them.
13:05 jeff_ DPearl: ah, if you rebooted, it's less likely that i'm correct. :P
13:06 DPearl jeff_: No stray processes
13:09 kivilahtio does anybody use a perl debugger with Evergreen?
13:13 kbeswick joined #evergreen
13:18 jeff_ DPearl: was this ejabberd setup several weeks ago, as early as May 30?
13:19 stevenyvr2 joined #evergreen
13:20 DPearl I think so.  The machine was configured for me about then, and then I got access.
13:20 DPearl jeff_:  see above
13:20 jeff_ got it.
13:27 jeff_ DPearl: what happens now when you (as the opensrf user) run osrf_ctl.sh -l -a start_all
13:28 berick kmlussier: i'll create an LP entry for the Remove Fields issue (unless you already have)
13:30 kmlussier berick++ I didn't do anything in LP - wasn't sure if it was a bug or feature.
13:31 kivilahtio1 joined #evergreen
13:31 berick k
13:31 jeff_ joined #evergreen
13:32 jeff_ joined #evergreen
13:34 DPearl jeff_: Surprise!! same results
13:36 jeff_ well, not that much of a surprise.
13:36 jeff_ but still... drat.
13:36 jeff_ so, what are the results?
13:42 csharp I'm taking a stab at berick's bug 1190279 for ubuntu deps... I'm wondering whether we should bother continuing to support Ubuntu 10.04?
13:42 DPearl jeff_: Well the logs look pretty much like they have looked, so the failure is repeatable
13:42 pinesol_green Launchpad bug 1190279 in Evergreen "Modularize Makefile.install" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1190279
13:43 * csharp tends to think we should drop support for lucid
13:43 jeff_ DPearl: what output do you receive in your terminal in response to the osrf_ctl command?
13:43 berick csharp++
13:43 jeff_ DPearl: and, what distro and version of linux are you running on?
13:43 berick csharp: copy/paste the wheezy script and a few minor tweaks should do it, i think
13:44 csharp yeah - that was my approach
13:44 DPearl jeff_: Debian 6.0.2
13:44 bshum csharp: +1 Lucid is dead to me.
13:44 csharp I was thinking the same for 10.04/squeeze, but then wondered if that was worth the bother
13:44 jeffdavis lucid is supported by ubuntu until april 2015...
13:44 bshum Though if folks are volunteering for Lucid work, that's different?  :D
13:45 pastebot "DPearl" at 204.193.129.146 pasted "results from stopping, then starting opensrf" (15 lines) at http://paste.evergreen-ils.org/34
13:45 bshum I'll refer to "For Ubuntu, please use the latest LTS (long term support) release." which isn't specific bug generally reflects the community's intent to only work on the latest LTS.
13:45 bshum bug/but
13:45 csharp yeah - that makes sense
13:46 berick csharp: i'd like to keep squeeze for a while longer.
13:46 csharp jeffdavis: are you dissenting?  I don't want to pull the rug out from someone needing 10.04
13:46 csharp berick: yeah - makes sense to me
13:46 rfrasur bshum: do you have a gnexus tablet or phone?
13:46 bshum Counter argument to that is that while Ubuntu's community might support 10.04 that long, the Evergreen community never committed to that.
13:46 jeffdavis csharp: we've still got some lucid servers in our prod environment; we can cope with that but others might find it more troublesome
13:46 bshum But that said, I think it really depends on who's working on it.
13:47 jeffdavis that said, ... what bshum sad ;)
13:47 jeffdavis said*
13:47 csharp makes sense
13:47 bshum I know we've moved on to Precise for our application servers.  We still use Lucid for our PostgreSQL servers though.
13:47 csharp I guess I'll do the work for 10.04 too since it's pretty straightforward
13:47 * bshum would need to go back to the dev meeting where we said which distros we would support.
13:48 bshum But I don't expect 10.04 to have drifted too much to be a problem to support for the moment.
13:48 csharp bshum: I believe "latest LTS" makes sense
13:48 csharp that was my recollection too
13:48 bshum It's also kind of like how we have Fedora support.  If you really, really love it and provide patches :D
13:49 bshum Then by all means.
13:49 jeff_ DPearl: since the passwords are already out, can you pastebin your unmodified opensrf_core.xml file?
13:52 DPearl jeff_: Oh, OK.
13:53 frank joined #evergreen
13:53 pastebot "DPearl" at 204.193.129.146 pasted "opensrf core" (161 lines) at http://paste.evergreen-ils.org/35
13:55 granitize joined #evergreen
13:55 dbs router / password ?
13:55 dbs those are the right usernames & passwords for both routers?
13:56 jeff_ yep. confirmed in the ejabberd dump DPearl pasted earlier.
13:58 jeff_ they appear to match ok, yet ejabberd logs (from earlier -- haven't seen any from the most recent attempt) claim "Failed legacy authentication for router@private.localhost/router"
13:59 frank hi everybody, I have a problem when I try to renew one item from the TPAC, I get the Internal Server Error, but it just happend with just one specific item, I hace other 2 items and I renew them without any problem,  the log error is EX::ERROR 2013-06-12T12:39:10 OpenSRF::AppRequest /usr/local/share/perl/5.10.1​/OpenSRF/AppSession.pm:1064 System ERROR: Exception: OpenSRF::DomainObject::oilsMethodException 2013-06-12T12:39:10 OpenS
14:01 frank *** Call to [open-ils.circ.renew] failed for session [1371058750.805024078.32138159165], thread trace [1]:
14:05 phasefx frank: does it also break if you try to renew from the staff client?
14:05 phasefx (it probably will)
14:07 frank no, I can renew the item from the staff client without any problem!, the error occurs just in the TPAC renew
14:07 phasefx interesting
14:07 bshum frank: Which version of Evergreen is it?
14:07 bshum (and unrelated, was there supposed to be a dev meeting today?)
14:08 frank 2.3.7 Eg version
14:08 phasefx frank: I'd check the apache error log too; I always do when I see an Internal Server Error
14:08 paxed bshum: i thought dev meeting was going to be today...
14:09 csharp yeah I have that on my calendar too
14:09 csharp @dunno
14:09 pinesol_green csharp: I see nothing, I know nothing!
14:09 bshum Heh
14:09 paxed http://www.doodle.com/ps8garwxwqsgfr6x
14:09 dbwells http://evergreen-ils.org/dokuwiki/d​oku.php?id=dev:meetings:2013-06-12
14:10 bshum It's a short meeting.  We can start that up.
14:10 csharp [placeholder]
14:10 bshum csharp++
14:10 pastebot "frank" at 204.193.129.146 pasted "error renew" (3 lines) at http://paste.evergreen-ils.org/36
14:10 frank this is the apache error log
14:11 dbwells csharp: I agree, +1
14:11 csharp :-D
14:12 bshum @eightball Shall we have a meeting today?
14:12 pinesol_green bshum: One would be wise to think so.
14:12 bshum The eightball has spoken.
14:13 bshum #startmeeting Developer Meeting 2013-06-12
14:13 pinesol_green Meeting started Wed Jun 12 14:13:44 2013 US/Eastern.  The chair is bshum. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:13 pinesol_green Useful Commands: #action #agreed #help #info #idea #link #topic.
14:13 pinesol_green The meeting name has been set to 'developer_meeting_2013_06_12'
14:13 bshum #topic Introductions
14:14 bshum #info bshum = Ben Shum, Bibliomation
14:14 phasefx #info phasefx = Jason Etheridge, Equinox
14:14 jeff_ #info jeff = Jeff Godin, TADL
14:14 dbwells #info dbwells = Dan Wells, Hekman Library (Calvin College)
14:14 remingtron #info remingtron = Remington Steed, Hekman Library (Calvin College)
14:15 eeevil #info eeevil = Mike Rylander, ESI
14:15 senator #info senator = Lebbeous Fogle-Weekley, ESI
14:15 bshum As folks arrive, feel free to announce yourselves.  Sorry we'll try and make this meeting quick and helpful.
14:16 bshum #topic Action items from the last meeting
14:17 ktomita_ joined #evergreen
14:17 bshum #info 1. gmcharlt will put out another call for 2.5 road map items and start a 2.6 road map
14:17 kmlussier #info kmlussier = Kathy Lussier, MassLNC
14:17 bshum He didn't speak up, but I think that occurred to add more road map items.
14:17 granitize joined #evergreen
14:17 csharp #info csharp = Chris Sharp, GPLS
14:17 bshum Though I'm unsure about the 2.6 roadmap.
14:17 tsbere #info tsbere = Thomas Berezansky, MVLC
14:18 gmcharlt #info gmcharlt = Galen Charlton, ESI
14:18 bshum gmcharlt: Deferred to the next meeting I guess on the 2.6 part at least?
14:18 gmcharlt bshum: yeah
14:18 DPearl #info DPearl = Dan Pearl, C/W MARS
14:18 bshum #action Start on the 2.6 development road map page
14:19 bshum #info 2. bshum to email lists about bug tracking changes
14:19 paxed #info paxed = Pasi Kallinen, Regional Library of Joensuu
14:19 bshum #action bshum to summarize bug tracking based on feedback from developers
14:19 bshum I'm deferring this as well, since we just put that to summary just yesterday thanks to dbwells.
14:20 bshum #topic GSOC reports
14:20 bshum #info laque (Dmitry Nechai) was accepted as the student for this year's GSOC.  He'll be working on a library dashboard with stats, etc.
14:21 csharp nice
14:21 bshum #info Dyrcona and bshum are primary mentors and will be involved in mentoring the student as the summer progresses.
14:21 bshum Not sure if Dyrcona has more to add at this time.  We've sent an email welcoming them and will hopefully start getting some active communication going.
14:22 kmlussier Dyrcona isn't around right now.
14:22 bshum Moving on for now then.
14:22 bshum #topic OpenSRF release
14:22 bshum Anything for this?
14:22 bshum Other than [placeholder] :)
14:23 kayals joined #evergreen
14:23 bshum Alright
14:24 bshum #topic Evergreen releases
14:24 * bshum turns over to dbwells for 2.5 news
14:24 dbs #info dbs = Dan Scott, Laurentian University
14:24 dbwells Sure.  I sent out a wrap-up email for m1 this morning, so I am not sure how many have seen that yet.
14:25 dbs 0.5++
14:25 bshum #link Wrapup email on 2.5-m1 - http://markmail.org/message/u6fgf2zqicuaskra
14:25 bshum dbwells++
14:25 eeevil huh ... never saw that
14:26 dbwells In essence, with a few extra days and extra pleas, we met the initial (non dreamy) goal of cutting the list in half.
14:26 eeevil dbwells++ #pleas
14:26 dbwells I haven't heard anything along the lines of "master is totally broken" yet, so I think it was a success.
14:27 dbwells One thing I wanted to bring up is that I deferred on the big whitespace push due in part to lack of feedback.  Anyone have anything to add on that topic?
14:28 eeevil I'm a-feared, but not for any logical reason I can point to
14:28 kayals How do reports work against multiple databases? How can I configure the same under reporter section in the opensrf.xml file.
14:28 dbwells Yeah, same here :)
14:28 phasefx the diff -b thing gmcharlt pointed out was reassuring
14:29 bshum kayals: Bear with us for a moment, there's a developer meeting happening for the next little while.  We'll be done soonish.
14:29 kayals sure.
14:29 gmcharlt dbwells: one thing I didn't specifically test was that code using heredocs remained unbroken
14:29 gmcharlt (or at least in its current state of brokeness or not ;)
14:30 eeevil gmcharlt: that's where my fear lies, but dbwells' logic seems sound in first analysis
14:30 gmcharlt agreed, the logic seems sound
14:30 dbwells At a few stages I ran a recursive 'perl -c' over the whole set, and at this point the output from those is identical.
14:30 eeevil the centroid of my fear, if you will
14:30 dbwells FWIW
14:30 eeevil dbwells: one question
14:30 dbwells So, at least all the HEREDOCs find their ends.
14:31 eeevil had you considered setting up a more complex perltidy config instead of sed+expand? (curious about methodology more than requesting an alternate approach)
14:32 paxed dbwells: one small breakage in master, bug 1158211
14:32 pinesol_green Launchpad bug 1158211 in Evergreen "Empty translatable string in 950.data.seed-values.sql" (affected: 1, heat: 6) [Low,Triaged] https://launchpad.net/bugs/1158211
14:34 bshum So, for the notes
14:34 eeevil paxed: that's not related to the whitespace expansion, though, is it?
14:34 paxed eeevil: no
14:34 eeevil oh, you just mean breakages in general, nevermind me
14:35 dbwells eeevil: I did try a number of different perltidy configs, but almost every option seemed a little to aggressive to be run over every file.  Basically, I am thinking we should concentrate on taking the smallest step which makes the biggest difference.
14:36 gmcharlt agreed -- settling on a perltidy config would be nice, IMO, but would definitely entail more than just whitespace
14:36 eeevil certainly ... thanks!
14:38 dbwells so... who wants to sign off?
14:39 bshum On the small steps first?  +1 to small steps
14:39 gmcharlt my view -- I'm comfortable with pushing the whitespace change provided somebody explicitly tests the heredocs; alas, I doubt I have any tuits for that this week
14:39 gmcharlt and in any event, I'd rather that it be done, if done at all, sooner rather than later
14:41 eeevil dbwells: is it only perl modules (*.pm), or all perl-type files?
14:41 dbwells Well, let's not hold up the meeting.  I'll run a few more tests, make sure the branch is up-to-date, then see if I can round up a volunteer to jump with me.
14:41 kayals joined #evergreen
14:42 bshum Adding some dates to the notes
14:42 bshum Does anyone have anything about Dan's suggested dates for the next round of commit action?
14:42 berick heh, dbwells and louise, flying over the cliff
14:42 bshum They seemed reasonable to me.
14:43 bshum #info 7/1 - suggested last day for targetting bugs/features at 2.5-m2
14:43 bshum #info 7/2-7/12 - Suggested period to focus energy on reviewing/committing m2
14:43 bshum bugs/features
14:44 bshum #info dbwells working on whitespace cleanup; will do more tests and find others
14:44 bkuhn joined #evergreen
14:44 dbwells eeevil: The command as written is limited to the *.pm.  I looked briefly for other common file patterns, and came up empty.  I also grepped for tabs in the whole perlmods dir after running the commands, and found just one in a test file, so I figured that was close enough.
14:44 bshum Anything else about 2.5 before we move on?  I'd like to have a short word on the next maintenance releases.
14:44 eeevil (one last thing re whitespace ... it's really just HEREDOCs with space in front. for those that want to test, it looks like circ, actor, cat, search and resolver-resolver services, and added content, exporter, tpac and supercat web stuff could all break .... if they're not broken, things are looking good)
14:45 eeevil I found that using `ack '<<"' --type=perl|grep \.pm|cut -f1 -d:|sort -u`
14:46 dbwells eeevil: Thanks for the list.  In my testing, I believe every service at least started, but it never hurts to triple-check.
14:46 eeevil and `ack "<<'" --type=perl|grep \.pm|cut -f1 -d:|sort -u` adds booking and bib batch update to the list to test
14:47 dbwells bshum: nothing from me
14:47 bshum Cool, eeevil++ showing us the things to check :D
14:47 bshum So next
14:47 bshum #info Maintenance releases are scheduled for June 19
14:48 bshum While I was cleaning up bugs from 2.2/2.3 the last round, I marked a bunch of things with specific targets to the next milestones, 2.3.8 and 2.2.10.
14:48 bshum Specifically these were bugs with backport requests, but had yet to be done.
14:48 bshum Otherwise, I left other bugs untargeted for now.
14:48 bshum #link Link to 2.3.8 targeted bugs: https://launchpad.net/evergreen/+milestone/2.3.8
14:49 bshum #link Link to 2.2.10 targeted bugs: https://launchpad.net/evergreen/+milestone/2.2.10
14:49 eeevil for those following along with bug 1187433, there are now 2 branches on that, both for testing, both to repair 2.4-era regressions. one's been tested and one is new as of this morning. That's the most important outstanding 2.4/master bug I would like to appeal for eyes on for the june 2.4 release
14:49 bshum I assigned them to the maintainers, but that's something we can help out with.
14:49 pinesol_green Launchpad bug 1187433 in Evergreen "apostrophe search issues in 2.4" (affected: 1, heat: 6) [Medium,Confirmed] https://launchpad.net/bugs/1187433
14:49 eeevil (since were talkin' maint releases)
14:49 bshum Oh right.
14:50 bshum #link Link to 2.4.1 targeted bugs: https://launchpad.net/evergreen/+milestone/2.4.1
14:50 dbs We should get a 2.4.0 release announcement out some time
14:50 bshum I forgot we're doing maintenance on that too :(
14:50 eeevil dbs: touche'
14:52 bshum So, general request to help merge bugs for the maintenance releases too.  Thanks all.
14:53 bshum Which leads us to the bug squashing agenda item...
14:53 bshum #topic Bug squashing
14:53 * bshum pokes kmlussier
14:53 dbwells Can somebody remind me when 2.2 support is supposed to end?  (or, where that information exists?)
14:54 kmlussier I added this to the agenda before a lot of the backlog was pushed into master.
14:54 * senator would like to be reminded too
14:54 rfrasur not before December 2013?
14:54 bshum It's 15 months of support (two 6-month release cycles and 3 months of security fixes)
14:54 kmlussier I thought it might be useful to return to those pullrequest meetings we used to do a year or two ago. To help keep on top of the bugs.
14:55 csharp released last June, right?
14:55 kmlussier And then I had also seen the bug squashing day that Koha did last month, and I thought that might be another good way to attack the bug backlog.
14:55 senator yes
14:55 kmlussier So I'm just throwing those ideas out there for feedback.
14:55 bshum 2.2.0 was June 13, 2012.
14:55 bshum So... September?
14:55 csharp yeah
14:55 senator so the 2.2 series is out of general bugfix releases, and gets security releases through september
14:55 bshum Well actually this is the last release with general backports.
14:56 rfrasur (foiled)
14:56 bshum It'll be security releases after that.
14:56 mrpeters lets remind people....2.2 is not going to STOP working
14:56 rfrasur of course not
14:56 rfrasur But, does that mean that bug reports will lower priority or no priority?
14:56 rfrasur other than security issues?
14:56 mrpeters i dont think they will be valid unless they impact later versions
14:56 csharp rfrasur: pretty much, yeah
14:57 mrpeters but they wont get backported to 2.2
14:57 rfrasur k
14:57 mrpeters unless someone takes pity
14:57 rfrasur meh...no need for pity.
14:57 csharp (or unless your support vendor can do it)
14:57 mrpeters you'll be on a  new version soon enough rfrasur
14:57 phasefx someone can always volunteer to maintain an otherwise defunct branch
14:57 rfrasur yup
14:58 bshum kmlussier: So to try being on track... the suggestion is that outside of 2.5 merging, maintenance releases, we try setting aside a specific time/day to work on miscellaneous bugs that have not had much love yet?
14:58 rfrasur I'll just make it more of a priority to get in on some testing
14:58 ktomita joined #evergreen
14:59 kmlussier bshum: Yes, that's what I'm suggesting. If others think it's a good idea.
14:59 mrpeters i like that idea
14:59 jdouma joined #evergreen
15:00 kmlussier When we used to have those pullrequest meetings, I loved seeing all the unloved patches finally getting merged in.
15:00 kmlussier Of course, I wasn't do much testing then, but would be able to help out now. :)
15:03 bshum For myself, I feel that bug squashing tends to happen best in conjunction with the maintenance releases.
15:03 bshum Maybe we should designate a particular day prior to the cutting date where we try to focus a bit more on it?
15:04 bshum Since bug squashing and getting fixes in would lead ultimately to being part of a maintenance release anyways for others to take.
15:05 bshum Maybe we should table this topic and bring it to the lists for some more feedback / refinement?
15:05 kmlussier That sounds good. Do you want to give it to me as an action item since I raised the topic?
15:05 bshum Sure.
15:06 rfrasur joined #evergreen
15:06 bshum #action kmlussier to raise bug squashing day to the lists for further discussion/feedback
15:06 bshum Alright, anything else we need to discuss today?  (that's the end of the agenda)
15:07 bshum kmlussier++ # keeping our eyes on the prize with bug squashing :)
15:07 dbwells Re: bug squash days, my main concern is simple fatigue.  If I am going to poking people to push for the 2.5 timeline, I am not sure how much more we can wring out of the group.  That's all.
15:08 kmlussier dbwells: Sure, but if it's something that has to wait until after 2.5 is out, I think that's fine too.
15:08 bshum Well there's always going to be Evergreen-next
15:08 kmlussier Of course, with a six-month release schedule, it doesn't give much time between releases to focus on bug squashing.
15:08 bshum We have to figure out how to try balancing it.
15:09 bshum For myself, I think it really helps me when I get signoffs from others (anybody) to say whether a thing is good or not for them.
15:09 bshum Even if they say in the comment something works, that's fine because we still try it.  But I always feel better with more signoffs :)
15:09 dbwells I do think it is sort of built into the 2.5 goals to keep cutting the backlog, so it does make some sense to see where we are at when the cycle is over.
15:09 bshum (and it doesn't have to be core committer signoffs, I love seeing the sys admins step up)
15:10 bshum Or non-devs...
15:11 dbwells My biggest concern would be for bugs which *only* affect older versions.  Those tend to be fairly rare, though.
15:11 kmlussier dbwells: I agree. The recent reduction in the backlog was very encouraging. :)
15:12 rfrasur When the time comes, can we talk re: the hackaway?
15:12 bshum Alright, going to end the meeting notes, but since dbwells is around, I imagine he could help with hackaway questions post-meeting ;)
15:13 bshum Thanks everybody for coming, we'll try to be more on-time with things.
15:13 bshum #endmeeting
15:13 pinesol_green Meeting ended Wed Jun 12 15:13:42 2013 US/Eastern.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:13 pinesol_green Minutes:        http://evergreen-ils.org/meetings/evergr​een/2013/evergreen.2013-06-12-14.13.html
15:13 pinesol_green Minutes (text): http://evergreen-ils.org/meetings/evergr​een/2013/evergreen.2013-06-12-14.13.txt
15:13 pinesol_green Log:            http://evergreen-ils.org/meetings/evergree​n/2013/evergreen.2013-06-12-14.13.log.html
15:14 kmlussier bshum++
15:14 gmcharlt bshum++
15:14 rfrasur bshum++
15:15 bshum rfrasur: Go ask dbwells about the hackaway.  I'm eager to learn more too :D
15:15 dbs bshum: Q about the GSoC - are you and Dyrcona going to write up a blog post / mailing list message announcing the exciting student + project?
15:15 bshum dbs: I started a blog post actually and got as far as the title last week :(
15:15 rfrasur okay, related to dbwells talking re: dev fatigue, it sounds like we need more developers.  I'd like to shout out to our Indiana community and see if there are people that aren't involved yet but could be.
15:15 dbs bshum++ # better than nothing!
15:15 bshum dbs: It's been crazy times.  But I really need to be better and more proactive, so thanks for reminding me.
15:15 paxed it's a long, slow process to become a dev ...
15:15 rfrasur hmm, I think it was dbwells
15:16 rfrasur yeah...but, at the hackaway, could there maybe be an intro for people that know the languages, etc?
15:16 rfrasur or am I oversimplying?
15:16 dbwells rfrasur: Yes, I said that, and yes, more devs is good.
15:18 jeffdavis bshum: thanks for the autoupdate advice. I installed ia32-libs and the updates built without errors.
15:18 jeffdavis They're not actually *applying* correctly at this point, but it is a step forward. ;)
15:19 bshum jeffdavis++ # forward stepping!
15:19 dbwells rfrasur: The actual agenda for the Hack-a-way is still TBD, but I'm not sure how much time we could set aside for intro-level topics.  That said, I think if a programmer is familiar with the languages used in Evergreen, simply observing at the Hack-a-way would be a potentially valuable experience.  Does that make sense?
15:20 rfrasur If I can find people with the skills or the capacity to develop the skills in a meaningful amt of time, I'd like some guidance as to where to get them plugged in.  I thought maybe the hackaway might be a good place, but maybe it's too much too soon?
15:20 dbwells And do others agree?
15:20 rfrasur dbwells: perfect sense
15:20 tspindler joined #evergreen
15:21 mjingle joined #evergreen
15:22 paxed i have to agree with dbwells that observing when you already know the language is good. i learn a lot looking at the commit diffs :P
15:22 paxed "oh, so that's how you add a foo"
15:22 berick dbwells: agreed.  more developers is good, obviously, but that's not the main purpose of the hackaway
15:22 berick the EG conf, on the other hand...
15:23 rfrasur I, of course, agree that the EG conf is the best way to go, but it's a pretty big commitment of resources for potentials.
15:23 dbs maybe EG 2014 could have an intro-to-eg-hackery on day 0, and a hackfest on day 4
15:24 berick dbs: i like that
15:25 berick day 4 => when you /really/ know what you want to hack on
15:25 rfrasur dbs:I think that's a good idea...
15:25 dbs and maybe at the hackaway we could "hack away" lots of crufty complex code that inhibits newbies and greybeards alike :)
15:25 rfrasur lol
15:25 bshum Interesting.
15:26 bshum dbs: berick:  I'll pass that suggestion to the programs committee (in case they weren't paying attention already)
15:26 dbs :)
15:26 bshum I know we've been toying with different approaches to the scheduling.
15:27 * kmlussier is paying attention.
15:27 rfrasur kmlussier++
15:28 * kmlussier will apparently add one more option to alternate schedule scenarios. :)
15:29 dboyle_ joined #evergreen
15:32 rfrasur thanks all for feedback
15:34 * bshum idly wonders what csharp and Rogan learned last year at Hack-A-Way
15:34 bshum I know I learned a ton sitting next to folks.
15:37 remingtron rfrasur: are you aware that EG conf 2013 now has all their videos online? http://eg2013.sitka.bclibraries.c​a/schedule/session-descriptions/
15:38 berick remingtron++
15:38 remingtron I wasn't able to attend this year, so that's my new portal to EG education
15:38 remingtron as a new dev, that is
15:38 rfrasur remingtron: yes...and I think that's gonna be the first step.  am thinking that if there's gonna be enough buy-in from local(ish) people to be willing to shell out $225(ish) plus transportation/board...
15:39 * rfrasur will have to start plugging now, and the videos will be a good tool for that.
15:39 rfrasur remingtron++
15:40 remingtron also, the wiki has lots of good info for devs, including: http://evergreen-ils.org/dokuwiki/​doku.php?id=eg_developer_overview
15:42 rfrasur ty remingtron. I'll use those.
15:47 artunit joined #evergreen
15:53 bshum kayals: When you say multiple databases, do you mean like there's the evergreen database that you work primarily off of and then have other replicated databases that you run against just for reports?
15:53 bshum (goes back to your question from during the meeting)
15:54 kayals bshum: We want to create different databases for different libraries within one Database server
15:54 kayals meaning each library will have their own database
15:55 bshum Interesting...
15:55 bshum So separate Evergreen systems running on the same Postgres server?
15:55 kayals we will create small VMs for each library and then point to their individual database
15:55 bshum (could see some interesting resource fights)
15:56 kayals one database server with multiple databases for each library
15:56 jeffdavis But you wanted to have a single reports server for all of them?
15:56 kayals yes
15:57 jeffdavis as bshum says, interesting... :)
15:58 jeffdavis We've got a setup like that for our test environment but not with shared services like reports
15:58 bshum Yeah our test database server has multiple databases for various distinct Evergreen test systems too.
15:58 bshum But we don't run reports together.
15:58 kayals how can we configure reports for each library then
15:58 bshum Is there a reason the libraries need to be split up like that into disparate databases?
15:59 bshum Well, you could run clark-kent reporter on each Evergreen VM.  As long as the opensrf.xml was pointed to the right DB, I imagine that'd be fine.
15:59 kayals http://paste.evergreen-ils.org/37
15:59 bshum I mean, if you're running stats for the whole group together, might be simpler to be in one Evergreen system with some nice restrictions on behaviors or such.
16:00 kayals my guess is configure opensrf.xml like http://paste.evergreen-ils.org/37
16:01 kayals bshum- we want to scope each library in a different way
16:02 kayals give them different rules
16:02 kayals loan rules etc*
16:02 kmlussier @marc 700
16:02 pinesol_green kmlussier: An added entry in which the entry element is a personal name. (Repeatable) [a,b,c,d,e,f,g,h,j,k,l,m,n,​o,p,q,r,s,t,u,x,3,4,5,6,8]
16:03 bshum kayals: Well... I know we have different rules for each library in our consortium.
16:03 acoomes joined #evergreen
16:03 bshum And I know it's possible to erect barriers so that it's not as easy to slip between libraries in the same Evergreen system.  Thinking of org unit scoping and patron opt-ins
16:05 kayals say if I go with my idea of separate VMs for each library pointing to a central Database server and configured to point to individual database...configure to reside clark-kent to reside in the VM itself..
16:05 bshum That all said, the "eg_db_config" step of the install process should set the opensrf.xml options nicely towards whatever DB you need.  The only thing might be updating the hostname URL to point at the individual VMs
16:05 mjingle joined #evergreen
16:05 kayals and you are suggesting not to have one reporter server
16:06 kayals bshum - thanks. let me check the eg_db_config setup
16:06 kayals what do you suggest for reporting
16:06 bshum kayals: Okay, you've got me really curious what your library setup needs to include to require separate Evergreen instances and databases and yet consolidated reporting :)
16:07 kayals consolidated reporting is optional :)
16:07 kayals each library can have separate reporting
16:08 mjingle1 joined #evergreen
16:09 bshum Right... what I guess I'm saying is that consolidated reporting as described doesn't exist.
16:09 kayals ok
16:09 bshum I couldn't even imagine dumping all the contents into a single database without collisions.
16:10 bshum It's just an interesting hosting scenario.
16:11 mjingle joined #evergreen
16:13 kayals We were curious too :) but I was confused how to point reporter to each database
16:13 bshum Well.
16:13 bshum In the scenario described (if I get it)
16:14 bshum You've got an Evergreen VM pointed to a database (on a shared server)
16:14 bshum So you'd just run clark-kent reporter on each VM for each distinct group.
16:14 bshum You couldn't run just one.
16:14 kayals we were planning one Reporter server, One utility sever where clark-kent will be residing
16:14 bshum And you'd likely have to do that for each utility cron job task too.  Like reshelving, fines, etc.
16:15 mjingle1 joined #evergreen
16:15 bshum kayals: Okay, tell me more about your libraries, I think I must be misunderstanding something :D
16:15 bshum Do you do resource sharing?
16:16 bshum Are the libraries even related?  :P
16:17 kayals sent you a pm
16:25 tspindler left #evergreen
16:27 ldwhalen joined #evergreen
16:36 rfrasur The internet is failing me
16:50 jeffdavis so much depends upon rfrasur's quest...
16:51 senator jeffdavis++
17:05 mmorgan left #evergreen
17:14 ldwhalen Can I use the newest xulrunner package with the staff client?
17:14 tsbere probably not
17:15 ldwhalen Should I stick with 1.9?
17:23 Dyrcona ldwhalen: We use 14.0.
17:23 ldwhalen I am building an OS X 2.4 client.  I will try 14.0.  Thank you.
17:29 dbs joined #evergreen
17:34 eby joined #evergreen
17:34 eby joined #evergreen
17:46 dbs joined #evergreen
17:46 dbs @curse squeeze -> wheezy upgrades that go awry
17:46 pinesol_green dbs: Beyond here be dragons.
17:46 dbs zactly
17:56 pinesol_green [evergreen|Mike Rylander] Search clicked /and/ preceding sf values - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=b14ece4>
18:15 ldwhalen joined #evergreen
18:20 ktomita joined #evergreen
18:47 ldwhalen joined #evergreen
19:07 dbs joined #evergreen
19:31 dbs joined #evergreen
19:48 dboyle joined #evergreen
19:57 dboyle_ joined #evergreen
20:07 swwet joined #evergreen
20:08 swwet left #evergreen
20:27 stevenyvr2 left #evergreen
21:01 kmlussier joined #evergreen
21:10 Rogan joined #evergreen
22:15 mcooper joined #evergreen
22:16 pinesol_green [evergreen|Mike Rylander] Use the centralized initialization method for QP - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=da4074d>
22:18 dbs bah, just pushed a rel_2_4_mergery to upstream instead of conifer. sorry git-admin folks :/
22:27 gmcharlt dbs++ # I like the term mergery
22:27 gmcharlt I'll kill that branch now
22:28 gmcharlt gone
22:31 dbs gmcharlt++ # thanks
23:58 paxed mornin

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