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.php?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 jopensrfpublic.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 jopensrfprivate.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 jopensrfpublic.localhost, one failed auth for jopensrfprivate.localhost, and 25 successful authentications for jopensrfprivate.localhost -- there are zero successful authentications for jopensrfpublic.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/password-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 routerprivate.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/doku.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/evergreen/2013/evergreen.2013-06-12-14.13.html |
15:13 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-06-12-14.13.txt |
15:13 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/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.ca/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 |