Time |
Nick |
Message |
00:18 |
|
dbwells_ joined #evergreen |
01:17 |
|
dbs joined #evergreen |
02:28 |
|
cherri joined #evergreen |
02:31 |
|
jeff joined #evergreen |
03:56 |
|
vanya joined #evergreen |
04:29 |
|
vanya joined #evergreen |
05:10 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
07:27 |
|
artunit joined #evergreen |
08:00 |
|
rjackson-isl joined #evergreen |
08:00 |
|
phasefx joined #evergreen |
08:13 |
|
akilsdonk joined #evergreen |
08:18 |
|
snigdha26 joined #evergreen |
08:20 |
|
ericar joined #evergreen |
08:21 |
graced |
Happy Friday #evergreen |
08:23 |
|
mdriscoll1 joined #evergreen |
08:28 |
|
kmlussier joined #evergreen |
08:28 |
kmlussier |
graced: Happy Friday! |
08:29 |
|
snigdha joined #evergreen |
08:30 |
|
tspindler joined #evergreen |
08:32 |
|
mmorgan joined #evergreen |
08:33 |
|
mrpeters joined #evergreen |
08:38 |
kmlussier |
I noticed that vanya asked a question on https://bugs.launchpad.net/evergreen/+bug/801639/comments/1. Is there any chance someone can help her out? I'm guessing she's looking at it as her first contribution to Evergreen. |
08:38 |
pinesol_green |
Launchpad bug 801639 in Evergreen "configure of --enable-python succeeds even though OpenSRF Python is absent" (affected: 1, heat: 6) [Wishlist,Triaged] |
08:38 |
* jeff |
looks |
08:39 |
kmlussier |
jeff++ |
08:51 |
|
DPearl joined #evergreen |
08:51 |
|
snigdha26 joined #evergreen |
08:51 |
|
pmurray_away joined #evergreen |
08:56 |
|
pmurray joined #evergreen |
09:02 |
|
cherri joined #evergreen |
09:14 |
|
Stompro joined #evergreen |
09:25 |
|
vanya joined #evergreen |
09:44 |
|
Hackaway joined #evergreen |
09:44 |
Hackaway |
https://plus.google.com/hangouts/_/gy44hfmosti3dx3sqpzyzs37jea |
09:51 |
|
DPearl joined #evergreen |
09:56 |
|
yboston joined #evergreen |
09:59 |
|
berick joined #evergreen |
10:03 |
|
jboyer-laptaupe joined #evergreen |
10:04 |
remingtron |
Hackaway++ |
10:04 |
bshum |
Eeevil, mceraso, and I are outside. Save us! |
10:24 |
mmorgan |
bshum: et al at the hackaway - Ezekial's mic is muted. Are you talking about us lurkers? ;-) |
10:24 |
bshum |
mmorgan: Heh, yeah |
10:24 |
mmorgan |
figured! |
10:25 |
bshum |
We're just volunteering you for everything interesting. |
10:25 |
mmorgan |
ah. figured that, too! |
10:26 |
phasefx |
my bad; didn't realize I muted Ezekial for everyone :) |
10:29 |
|
yboston joined #evergreen |
10:35 |
|
snigdha26 joined #evergreen |
10:47 |
Stompro |
I want a surrogate setup like George Sr. on Arrested Development. "Now say something technical... no don't say that, stop saying what I'm saying, is he saying what I'm saying?" |
10:49 |
|
mrpeters left #evergreen |
11:04 |
|
DPearl joined #evergreen |
11:08 |
eeevil |
http://dojotoolkit.org/reference-guide/1.6/dojo/xhrGet.html#dojo-xhrget |
11:08 |
|
Dyrcona joined #evergreen |
11:37 |
|
cherri joined #evergreen |
11:54 |
|
ericar joined #evergreen |
12:37 |
|
tsbere joined #evergreen |
12:39 |
|
cherri joined #evergreen |
12:39 |
|
kmlussier joined #evergreen |
12:48 |
vanya |
kmlussier : Hi ! As you had mentioned, if we want to add the the recommendations to the awesome box project, we will have to break the process in blocks. How do you think the tasks should be divided? |
12:49 |
vanya |
I was thinking maybe we can start with the basic awesome box integration, and as we collect awesome points, instead of simply counting them, we can store it in the table and improve the classifier simultaneously. |
12:50 |
vanya |
What do you think? |
12:51 |
kmlussier |
vanya: Hi! |
12:53 |
kmlussier |
vanya: This might be something that's good to work with your mentors on or maybe some of the devs in here who might have an interest. They may have a better idea of what pieces are interrelated and would fit well together in one chunk than I do. |
12:54 |
kmlussier |
Certainly the collection of the data is something to start with, and making sure it is collected in a way so that you build it in a way that works for future components of the project. |
13:00 |
vanya |
kmlussier : My mentors in the awesome box project are gmcharlt and Dycrona. |
13:01 |
vanya |
Once the blocks are decided, would you suggest I start working on it right away or should I start with bugs first? |
13:01 |
kmlussier |
I don't know if they are available right now, but what you might want to do is break it up into blocks that make the most sense to you. And then share it in here for feedback. |
13:02 |
kmlussier |
Sometimes it's easier to get good feedback when people have something to react to. |
13:02 |
kmlussier |
vanya: I would recommend getting started on some bugs for the first contribution. Just to get familiar with the code. |
13:03 |
vanya |
kmlussier : Thank you :) I'll try to break the task into parts. |
13:03 |
gmcharlt |
vanya: yeah, i echo kmlussier - tackling one or two of the bitesize bugs would be a good start |
13:04 |
vanya |
gmcharlt : Hi! |
13:04 |
gmcharlt |
howdy :) |
13:05 |
vanya |
I was wondering if you could explain how exactly evergreen is envisioned to integrate with awesome box. |
13:06 |
kmlussier |
Stompro: Would you like a Wordpress account for evergreen-ils.org? |
13:06 |
vanya |
I could get a basic idea from the project page. |
13:06 |
kmlussier |
Stompro: So that we can make it as easy as possible to fix any other errors you might find? :0 |
13:17 |
kmlussier |
The discussion on the list makes me realized that we really need to document archiving circ and holds transactions in Evergreen. I don't think it's ever been done. |
13:17 |
* kmlussier |
adds it to the wiki. |
13:21 |
phasefx |
vanya: have you seen https://bugs.launchpad.net/evergreen/+bug/1297976 and some of the IRC discussion links referenced therein? |
13:21 |
pinesol_green |
Launchpad bug 1297976 in Evergreen "Awesome box integration" (affected: 7, heat: 34) [Wishlist,New] |
13:26 |
|
nhilton joined #evergreen |
13:28 |
|
nhilton_ joined #evergreen |
13:30 |
vanya |
phasefx : hi! thank you :) |
13:31 |
phasefx |
vanya: hello, you're welcome :) |
13:44 |
kmlussier |
Is the hack-a-way still happening? |
13:45 |
|
akilsdonk joined #evergreen |
13:47 |
vanya |
What is the hack-a-way? |
13:48 |
kmlussier |
vanya: Every year in the fall, the developers try to meet to work on projects. It's happening this week. People can also participate remotely, which I was doing until today. |
13:48 |
tspindler |
kmlussier: are you talking about documentation for the age circulations when yoou say 'archive circulation" |
13:51 |
kmlussier |
tspindler: Yes. |
13:51 |
kmlussier |
tspindler: Do you know of any that exists? |
13:54 |
tspindler |
kmlussier: I know I used some for the purge_circulation function but not sure where I saw it now, may have been in mails list |
13:55 |
kmlussier |
tspindler: Yes, I do recall seeing discussion on it on the mailing lists a few years ago. I was going to look there first. If I ever do the actual documentation, that is. :) |
13:56 |
kmlussier |
I just wonder how many people even know that this functionality exists. |
13:58 |
tspindler |
kmlussier: I was also wondering about the purge holds function, wondering if anyone is using that, we have not looked at it |
13:58 |
tspindler |
not sure if we would use purge holds either |
13:58 |
kmlussier |
tspindler: I think MVLC is using it. |
13:58 |
kmlussier |
Since they developed it. |
13:58 |
Hackaway |
https://plus.google.com/hangouts/_/gy44hfmosti3dx3sqpzyzs37jea --hangout link |
13:58 |
kmlussier |
Hackaway: Thanks! Just as I'm about to jump on to a conference call. :) |
13:59 |
tspindler |
kmlussier: do you know why the developed it (Maybe Dyrcona can chime in) |
14:00 |
tsbere |
tspindler: Why? Because our directors are paranoid about patron privacy. ;) |
14:01 |
|
_bott_ joined #evergreen |
14:02 |
tspindler |
tsbere: do you remove completed holds from the system eventually even after they are aged? |
14:03 |
Dyrcona |
We didn't develop it, did we? I thought we just fixed some problems it had. |
14:03 |
tsbere |
tspindler: At this point we keep the aged pretty much everything around, I believe. >_> |
14:05 |
tspindler |
i have just been wondering about aging holds out of the system eventually to just keep the table size down |
14:06 |
Dyrcona |
tspindler: drop database does wonders to reduce size. :p |
14:06 |
jeff |
Dyrcona: search results return much faster, also! |
14:06 |
Dyrcona |
jeff++ |
14:09 |
vanya |
While installing opensrf, are there any specific changes that need to be made for Ububtu 14.04? |
14:09 |
tspindler |
i could create the perfect library if I just didn't allow anyone in ;) |
14:10 |
vanya |
When I try to create OpenSRF Jabber users, it gives me the following error: |
14:10 |
vanya |
ejabberd is not running in that node |
14:10 |
vanya |
Check for error messages: ejabberd.log |
14:10 |
vanya |
or other files in that directory. |
14:10 |
vanya |
Error in ejabberd ctl process: 'error' badarg |
14:10 |
vanya |
Can someone tell me what to do regarding it? |
14:12 |
vanya |
And the enjabbered.log reports the following error: |
14:12 |
vanya |
=ERROR REPORT==== 2014-09-26 18:36:08 === |
14:12 |
vanya |
E(<0.38.0>:ejabberd_config:145) : Can't load config file: too many hosts definitions |
14:12 |
vanya |
jeff : I tried making the changes you suggested- not much luck :/ |
14:17 |
jeff |
vanya: can you paste the output of this command? grep hosts /etc/ejabberd/ejabberd.cfg |
14:17 |
Stompro |
kmlussier: Sure, I would be happy to fix the errors I've found. |
14:34 |
|
nhilton joined #evergreen |
14:36 |
vanya |
jeff : %%% {hosts, ["jabber.example.net", "im.example.com"]}. |
14:36 |
vanya |
{hosts, ["localhost"]}. |
14:36 |
vanya |
%% hosts: Domains served by ejabberd. |
14:36 |
vanya |
%% {hosts, ["example.net", "example.com", "example.org"]}. |
14:36 |
vanya |
{hosts, ["localhost", "private.localhost", "public.localhost"]}. |
14:36 |
vanya |
%% {hosts, ["localhost"]}. |
14:36 |
vanya |
%% {hosts, ["icq.localhost", "sms.localhost"], |
14:36 |
vanya |
%% Default s2s policy for undefined hosts. |
14:36 |
vanya |
%% Modules enabled in all ejabberd virtual hosts. |
14:37 |
jeff |
vanya: it looks like you have two hosts declarations: |
14:37 |
jeff |
{hosts, ["localhost"]}. |
14:37 |
jeff |
and |
14:37 |
jeff |
{hosts, ["localhost", "private.localhost", "public.localhost"]}. |
14:37 |
jeff |
vanya: if you remove or comment out one of those (probably the first would be best), ejabberd should start. |
14:38 |
kmlussier |
Dyrcona: I thought you fixed some things with the aged circulations but developed the aged holds. But I could be misremembering. |
14:39 |
vanya |
jeff : I tried that. Infact, I tried to run it with both the host declarations removed too(just to test). But it still gave the same error. |
14:39 |
vanya |
Just a second- I'll try it again. |
14:40 |
kmlussier |
vanya: Did you say Ubuntu 14.04? Dyrcona/bshum: Are there still problems with using Evergreen on 14.04? |
14:41 |
vanya |
Same error |
14:41 |
kmlussier |
vanya: Also, I recommend you use a site like pastebin to paste your output. It's a little cleaner than pasting it in the channel. :) |
14:41 |
vanya |
kmlussier : Yes. Is the problem with the OS? |
14:42 |
vanya |
Sorry...I'll be neater from now on. |
14:42 |
bshum |
kmlussier: vanya: Those problems with Ubuntu 14.04 are not related to ejabberd as far as I know. |
14:42 |
kmlussier |
vanya: I don't know. But I'm asking some of the folks I know who are using Ubuntu to see what they think. |
14:42 |
bshum |
Something else. |
14:42 |
kmlussier |
bshum: OK, thanks! |
14:43 |
kmlussier |
Darn! I finally got around to clicking the Hangout link. Told me the party was over. :) |
14:43 |
kmlussier |
That is, :( |
14:43 |
bshum |
It looks like it's too many entries |
14:43 |
jeff |
vanya: if you'd like to try with a fresh install of ejabberd, you should be able to use this command to completely remove, then reinstall it: apt-get purge ejabberd && apt-get install ejabberd |
14:44 |
bshum |
{hosts, ["localhost"]}. and {hosts, ["localhost", "private.localhost", "public.localhost"]}. |
14:44 |
bshum |
Defined twice? |
14:44 |
bshum |
Should only be once. |
14:44 |
bshum |
It doesn't have %% in front of one of those, so that's probably the problem. |
14:44 |
* bshum |
dives back to DB troubleshooting... |
14:44 |
jeff |
there was some mention a while back about ejabberd stuffing its bootstrap config from ejabberd.cfg into the ejabberd database, and then always using that. i've never actually seen that, though. also, it would be silly for it to stuff a bootstrap config that's invalid into the db... |
14:45 |
vanya |
bshum : Yes, initially it was defined twice. Then, as jeff suggested, I commented out the first one. |
14:45 |
jeff |
bshum: yup, we've already identified that as the likely issue. :-) |
14:45 |
vanya |
jeff : Oh! In that case, I'll try a fresh install. |
14:45 |
vanya |
Thank you :) |
14:46 |
jeff |
i've never actually seen that behavior in the wild, though. just a possibility. |
14:46 |
jeff |
vanya: when you have a fresh ejabberd.cfg, i'd recommend finding the one uncommented hosts declaration and editing it, as opposed to adding a new one. hopefully that will work well! |
14:47 |
vanya |
jeff : Sure thing! I'll try it right away! |
14:54 |
|
snigdha26 joined #evergreen |
14:58 |
vanya |
jeff : Turns out the bug does exist. I stopped getting that error. |
14:58 |
vanya |
But now it is telling me that the the RPC connection to the node failed. |
15:06 |
Bmagic |
ok guys, I have a brain buster, or not. I have a 28 day old copy of our production database. I count the number of rows in action.circulation for a paticular month in 2013 (xact_start), then I query the production database and I get different counts! So, how does 1.5 year old rows fluxuate in action.circulation? |
15:07 |
kmlussier |
Bmagic: Do you age your circulations? |
15:07 |
Bmagic |
kmlussier: I had that thought and yes, we have some rows in action.aged_circulation but they are mystery to me. I can't figure out how they get there. But I was told that the rows do not get removed from action.circulation anyway so it's a red herring |
15:09 |
kmlussier |
Bmagic: I could be totally misunderstanding aged circulations (I hope not), but I do think they are removed from action.circulation when they are moved to action.aged_circulation. |
15:10 |
Bmagic |
hmmmm |
15:10 |
kmlussier |
The reason for moving them is to anonymize the data, but if they remain in action.circulation, the data isn't anonymized. |
15:10 |
mmorgan |
Bmagic: If a patron record is delete that patron's circulations are moved to the aged circulation table. |
15:10 |
mmorgan |
deleted, that is |
15:10 |
kmlussier |
Ah, that makes sense. |
15:10 |
Bmagic |
AH! |
15:10 |
Bmagic |
That must be it |
15:10 |
kmlussier |
@praise mmorgan |
15:10 |
* pinesol_green |
the upgrade came off brilliantly, and it's all because of mmorgan |
15:10 |
mmorgan |
:-[ |
15:12 |
Bmagic |
mmorgan++ kmlussier++ |
15:14 |
phasefx |
Bmagic: offline transactions can also affect numbers like that |
15:16 |
Bmagic |
deleting a patron and moving the action.circulation to aged, doest explain the numbers in action.circulation INCREASING though? |
15:17 |
kmlussier |
No |
15:17 |
kmlussier |
But maybe phasefx's explanation works? |
15:19 |
phasefx |
Bmagic: see if the checkin_scan_time for some of those old circs comes after your snapshot date |
15:19 |
Bmagic |
well, I find it hard to believe that someone would hold onto offline circs for 1.5 years |
15:19 |
phasefx |
belay that, doesn't make sense |
15:19 |
phasefx |
Bmagic: no, all it takes is for the offline xacts to be loaded the minute after your snapshot |
15:20 |
Bmagic |
these rows are 1.5 years old |
15:20 |
Bmagic |
xact_start > 2013-04-01 and xact_start < 2013-05-01 |
15:21 |
phasefx |
Bmagic: the scenario I'm thinking of, if it happened at all, would be you have circs happen 1.5 years ago, some offline, some online.. you take a snapshot of the db, and then those offline circs get loaded into place.. your snapshot does not have them, but they're still 1.5 years old |
15:22 |
Bmagic |
phasefx: yeah, and my argument is that, that scenario would be extremly unlikely because who uploads offline transactions that are that old? |
15:22 |
phasefx |
Bmagic: my argument is, when all this happened, they weren't old at all |
15:22 |
phasefx |
again, if it happened :) |
15:23 |
Bmagic |
the snapshot is 28 days out of current sync |
15:23 |
phasefx |
Bmagic: ah! that's what I was missing |
15:23 |
Bmagic |
so basically, in the last 28 days, those 1.5 year old rows fluxuated on production |
15:23 |
phasefx |
you really need to scurtinize some of the specific circs to figure it out, I think |
15:24 |
Bmagic |
phasefx: yeah, im working on that as we speak, I though I would check with you all to see if I was wasting my time |
15:25 |
phasefx |
offline xacts are still a possibility, but even more unlikely.. say someone had a broken clock locally and had not synchronized with the EG server before then |
15:31 |
jeff |
Bmagic: you might find it helpful to examine action.circulation.create_time and action.circulation.id for additional clues. |
15:32 |
Bmagic |
jeff: Thanks, I'll check |
15:34 |
Bmagic |
checkout date= create_date or xact_start? |
15:35 |
tsbere |
In theory checkout date is the xact_start, but offline circs can happen well before they enter the system |
15:35 |
jeff |
Bmagic: i believe they differ mostly in the case of offline transactions. |
15:36 |
tsbere |
checkin_time vs checkin_scan_time is another one of those. checkin_time is the effective checkin time but may not be the same as the actual scan time (say, backdates) |
15:36 |
* jeff |
nods |
15:36 |
Bmagic |
it's the checkout dates that Im looking at |
15:37 |
jeff |
Bmagic: i was going to suggest you also look at the possibility of a SIP device batching in some offline transactions, but I don't think the current version of SIPServer + Evergreen will do that. I could be wrong, though. |
15:37 |
Bmagic |
this all came about when a library ran the same report for the same span of time and got 2 different answers.... and I can't figure it out either, the deleting of patrons explains the numbers going down |
15:41 |
jeff |
Bmagic: are you limiting/grouping by some field other than just action.circulation.xact_start? |
15:41 |
jeff |
Bmagic: something that could change, like a COPY circ lib, or a patron home_ou or a patron profile group? |
15:41 |
Bmagic |
Im working from 2 reports that they ran, and I can reproduce the numbers where they went down over time, but I can't reproduce the numbers where they went up over time. All of the examples where the numbers went up on their reports, both my snapshot and production agree with eachother and with the higher number on their reports |
15:42 |
jeff |
now i'm confused. :-) |
15:42 |
jeff |
oh, so you cannot reproduce the situation where the circ numbers went up? |
15:42 |
Bmagic |
jeff: good point, yes, I am filtering on call_number.owning_lib - I suppose that the copies could transfer ownership |
15:43 |
* jeff |
nods |
15:43 |
jeff |
if a copy were transferred to another library, or possibly if you have some/any floating going on, filtering on acn.owning_lib may differ over time. |
15:44 |
jeff |
action.circulation.circ_lib would be more stable |
15:44 |
Bmagic |
jeff: yep, that is correct! Meaning that I can easily explain the numbers going down when a patron is deleted, and I verified that was the case. But I can not explain the numbers going up, unless the copy changed owner *or the patron changed home_ou |
15:44 |
mmorgan |
Bmagic: Are there other filters, too? |
15:44 |
|
jboyer-laptaupe joined #evergreen |
15:45 |
Bmagic |
my query counts circulations in a given month by asset.call_number.owning_lib and actor.usr.home_ou (to match the report they are using) |
15:45 |
jeff |
Bmagic: if you can get to a point where you are able to identify individual circulations that appear with an xact_start within range in your current db vs your previous snapshot, then you'll probably have more to go in in terms of comparing copy/patron attributes between the two copies of the db. |
15:46 |
kmlussier |
OK, I have another web client question similiar to my printing question from earlier this week. All reloading/refreshing of the screens should be down through the browser, so we don't need to worry about seeing those buttons in the web client? Is that correct? |
15:46 |
jeff |
s/go in in/go on in/ |
15:46 |
Bmagic |
jeff: I have found those missing circs and found that the related patron was deleted. But I couldn't get the ones where the circs went up and I am going to chalk that up to the copy changing owning_lib. Thank you all! I think I have arrived at a conclusion |
15:47 |
Bmagic |
jeff++ |
15:47 |
jeff |
kmlussier: good question. my immediate thought is that reloading in the browser may be slower than a dedicated refresh option -- making such an option/button useful in some interfaces. |
15:47 |
jeff |
Bmagic: you're welcome! |
15:48 |
kmlussier |
jeff: Good point. I hadn't thought of that. Thanks! |
15:50 |
jeff |
kmlussier: you're welcome! |
15:53 |
mmorgan |
kmlussier: Hmm. I'm also thinking the lack of a dedicated refresh button may make users less inclined to think a refresh could be needed. |
15:53 |
|
nhilton_ joined #evergreen |
15:56 |
|
nhilton joined #evergreen |
15:57 |
jeff |
and in some interfaces, it's possible/likely that fewer manual refreshes would ever be needed -- i don't know if that's been a goal of work up until this point or not. |
15:57 |
jeff |
likely a little more backend support would be needed for anything but polling-based updates... |
15:58 |
kmlussier |
jeff: That would be nice. :) |
16:09 |
vanya |
jeff: sorry to keep bothering you like this. I looked into the RPC node failure and found that it was probably some bug in erlang. The suggestion given to rectify was to add "ERLANG_NODE=ejabberdFQDN" in the config file. |
16:10 |
vanya |
But since you had told me that I'd have to have a fresh installation of ejabbered for making changes in the config file, I tried "apt-get purge ejabberd && apt-get install ejabberd", but now the process of starting the server is failing. |
16:25 |
jeff |
vanya: ERLANG_NODE=ejabberdlocalhost can go in /etc/defaults/ejabberd on debian-based systems. You're using Ubuntu, right? |
16:26 |
vanya |
Yes. |
16:26 |
vanya |
I'm using ubuntu. |
16:27 |
vanya |
I'm sorry. Actually, I thought Debian and Ubuntu had similar config. |
16:27 |
|
whargrove joined #evergreen |
16:27 |
vanya |
Any idea how I should get myself out of this fix? |
16:28 |
whargrove |
What is the password/pin for seeded users? Is there a default? |
16:29 |
kmlussier |
Seeded users? |
16:29 |
|
tspindler left #evergreen |
16:29 |
kmlussier |
whargrove: Do you mean the users from the Concerto data set? |
16:30 |
whargrove |
kmlussier: Yes |
16:30 |
kmlussier |
whargrove: http://wiki.evergreen-ils.org/doku.php?id=qa:concerto_logins |
16:31 |
whargrove |
kmlussier: Hey look at that! Thanks :) |
16:31 |
jeff |
whargrove: you were running into an error with SIP, yes? Did you get past that? |
16:32 |
whargrove |
jeff: I did! You were spot on with the host name change messing with ejabberd |
16:32 |
kmlussier |
whargrove: I don't think we actually link to it from any page on the wiki, so it's a little hard to find. :) |
16:32 |
jeff |
whargrove: ah, good! |
16:34 |
* jeff |
pesters whargrove with a question via msg |
16:34 |
whargrove |
We're QAing our SIP integration right now and it seems all is good at this point |
16:38 |
jeff |
whargrove: cool! if you have time to answer my questions (via msg -- probably appearing in another window or tab) that would be great, otherwise -- perhaps another time. :-) |
16:38 |
|
nhilton_ joined #evergreen |
16:39 |
jeff |
and if you run into any trouble, ask away -- we try to be a pretty helpful bunch. |
16:45 |
|
vanya joined #evergreen |
16:48 |
kmlussier |
It would be nice to have a minimum resolution for the web client that we should be checking in testing. |
16:49 |
kmlussier |
Does anyone know if there was a minimum resolution that was in mind when it was being designed? |
16:52 |
graced |
kmlussier: I believe there was. berick is the one who would have that off the top of his head |
16:53 |
kmlussier |
graced: Ah, you're still here. I would have sent you a pm, but I assumed you would be weekend'ing already. :) |
16:53 |
graced |
I am often weekending by now... so it was a good bet |
17:00 |
kmlussier |
graced: Also, is there a set of supported browsers for the web client? IOW, should I be telling people not to be testing on IE? |
17:02 |
graced |
kmlussier: there is some kind of new issue with Firefox that we've found where we can't even get past the login screen. So that's a known issue at this point but should get resolved soon. |
17:03 |
graced |
I have the best luck with Chrome. IE is okay but I don't think it will be a supported browser. |
17:03 |
kmlussier |
OK. I can log in with Firefox still. Lucky me! :) |
17:04 |
graced |
Safari works but there's a known issue with screens with certain column configurations |
17:05 |
|
mdriscoll1 left #evergreen |
17:05 |
kmlussier |
graced: But if there's an issue I only see in Firefox, I'm guessing you still want me to report it so that it can eventually be supported? |
17:05 |
kmlussier |
Once people can log in, that is. |
17:06 |
graced |
yes. |
17:06 |
graced |
:) |
17:06 |
kmlussier |
I don't even know why I'm asking now because I know I'm just going to do what I want. :) |
17:06 |
kmlussier |
graced: Thanks for bearing with my questions! |
17:06 |
graced |
heh no problem |
17:07 |
|
vanya joined #evergreen |
17:07 |
kmlussier |
Woo hoo! Working branch for deletable copy locations! |
17:07 |
kmlussier |
jboyer-isl++ |
17:09 |
mmorgan |
jboyer-isl++ |
17:10 |
bshum |
@later tell hbrennan I made some progress on https://bugs.launchpad.net/evergreen/+bug/1306814 with help from jboyer-isl, maybe we'll have this "fixed" in a future release near you. |
17:10 |
pinesol_green |
bshum: The operation succeeded. |
17:10 |
pinesol_green |
Launchpad bug 1306814 in Evergreen "Self checkout ignoring patron timeout library setting" (affected: 4, heat: 18) [Medium,In progress] - Assigned to Ben Shum (bshum) |
17:10 |
jeff |
whargrove++ |
17:10 |
jeff |
kmlussier++ |
17:14 |
|
mmorgan left #evergreen |
17:18 |
vanya |
jeff : It worked! :D |
17:20 |
kmlussier |
Yay! |
17:20 |
kmlussier |
@praise jeff |
17:20 |
* pinesol_green |
jeff is one of the few who deserves to be praised |
17:22 |
vanya |
@dessert jeff |
17:22 |
* pinesol_green |
grabs some Krispy Kreme Donuts for jeff |
17:38 |
kmlussier |
Good night #evergreen! |
17:42 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
17:43 |
|
berick joined #evergreen |
17:48 |
|
vanya joined #evergreen |
18:12 |
vanya |
Is anyone there? |
18:13 |
vanya |
When I'm trying to test the default OpenSRF services, it gives me the error message: Received no data from server. |
18:14 |
vanya |
When I looked it up, I found that many people had reported the same on the mailing lists, but I couldn't find a solution to it. |
18:14 |
vanya |
Does anyone have an idea what I should be doing about it? |
18:20 |
|
geoffsams joined #evergreen |
18:30 |
|
tsbere joined #evergreen |
19:41 |
|
vanya joined #evergreen |
20:29 |
vanya |
jeff : are you there? |
20:36 |
bshum |
vanya: "Received no data from server" is a pretty generic message that things aren't working |
20:37 |
bshum |
vanya: Looking at the logs might reveal any specific errors. Perhaps something in /openils/var/log/osrfsys.log |
20:37 |
vanya |
bshum : Hi! I figured I'm having a lot of problem because of Ubuntu 14.04 |
20:37 |
bshum |
~troubleshooting |
20:37 |
bshum |
Ooops, guess no factoid for that one. |
20:37 |
vanya |
As 14.04 does not have postgresql 9.1 |
20:37 |
bshum |
vanya: Well, 14.04 can be strange at times, but overall it ought to work. I have three or four of htem so far. |
20:37 |
bshum |
vanya: Ahh! |
20:38 |
bshum |
vanya: What version of Evergreen are you attempting to install? |
20:38 |
bshum |
Err, nevermind, you're still on the OpenSRF part? |
20:38 |
vanya |
I am trying to install the 2.6 series |
20:38 |
bshum |
For OpenSRF, PostgreSQL 9.1 isn't required. |
20:39 |
bshum |
But yes, for Evergreen, it depends on what version you're installing. |
20:39 |
vanya |
(mainly because it supports the latest stable version of openSRF) |
20:39 |
vanya |
Yes, I'm done with openSRF |
20:39 |
bshum |
The 2.6 series of Evergreen only operates with Ubuntu 12.04 |
20:39 |
bshum |
14.04 is only supported after 2.7 series of Evergreen. |
20:39 |
vanya |
Oh! |
20:39 |
bshum |
That's something new that we're still working on in the community |
20:40 |
bshum |
Is to complete support for 14.04. |
20:40 |
bshum |
The current recommendation is to use Ubuntu 12.04, 64-bit server edition for things you wish to test out with OpenSRF/Evergreen. |
20:40 |
bshum |
For Ubuntu anyways. |
20:40 |
vanya |
In that case, I guess I'll have to find a virtual machine to support 12.04, or just revert back to 12.04 on my system. |
20:41 |
bshum |
vanya: It's definitely helpful to use virtual machines when testing things. |
20:42 |
vanya |
I'll browse around for a virtual machine then :) |
20:42 |
vanya |
Thank you! I was unable to sleep until I got the environment set up. I've been struggling with 14.04 for a while now. |
20:47 |
bshum |
vanya: Sure thing, good luck on your next steps. 14.04 has been a little tricky at times :( |
20:48 |
vanya |
bshum : So I learnt the hard way. Although you saved me- I wouldn't have been able to move from my desk unless I got that done. |
20:49 |
vanya |
How come you are still awake? :o |
20:49 |
bshum |
vanya: Oh it's only 8:49 pm where I am. |
20:49 |
bshum |
And I'm poking at some unruly servers :) |
20:50 |
vanya |
Oh! It's 6:25 a.m. here |
20:50 |
bshum |
Ah, pretty early then. |
20:51 |
vanya |
oh yes! I can have breakfast before I finally go to sleep. |
20:59 |
bshum |
Breakfast is good :) |
22:05 |
|
kmlussier joined #evergreen |
22:08 |
kmlussier |
~troubleshoot |
22:08 |
pinesol_green |
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 |
22:08 |
kmlussier |
That's the one. |
22:18 |
bshum |
Heh |
22:35 |
|
nhilton joined #evergreen |
23:12 |
|
artunit joined #evergreen |
23:31 |
|
sbrylander joined #evergreen |