Time |
Nick |
Message |
00:13 |
|
tpham joined #evergreen |
00:38 |
|
mnsri joined #evergreen |
05:54 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
06:37 |
|
eeevil joined #evergreen |
07:13 |
|
collum joined #evergreen |
07:33 |
|
sarabee joined #evergreen |
08:13 |
|
akilsdonk joined #evergreen |
08:13 |
|
StephenGWills joined #evergreen |
08:23 |
|
atlas__ joined #evergreen |
08:24 |
|
riot joined #evergreen |
08:37 |
|
Shae joined #evergreen |
08:48 |
|
mrpeters joined #evergreen |
08:50 |
|
athira joined #evergreen |
08:52 |
athira |
Hi when I am trying push my patch its showing some errors like "perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "en_IN" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). error: src refspec athira does not match any. error: failed to push some refs to 'gitgit.evergreen-ils.org:worki |
08:53 |
athira |
while using the command "git push working working_branch:user athira working_branch" |
08:53 |
athira |
Could someone please help me? |
08:59 |
jeff |
athira: try "git push working working_branch:user/athira/working_branch" |
09:00 |
jeff |
athira: the perl warnings are likely just that, warnings. the error is probably due to git seeing "extra" arguments due to you having spaces in your command where i placed slashes. |
09:01 |
|
ericar joined #evergreen |
09:12 |
|
RoganH joined #evergreen |
09:39 |
|
artunit joined #evergreen |
09:40 |
jeff |
athira: I'm sorry, but I didn't understand your question that you sent to me via private message. Could you try asking here in channel? Others may be able to help, also. |
09:45 |
athira |
actually I would like to give a small talk about the topic "contrbution to Evergreen" in our college.So I am new to this organization |
09:45 |
athira |
So what all things should there in a talk ? |
09:47 |
|
aashita joined #evergreen |
09:47 |
aashita |
Hii Berick! |
09:47 |
athira |
planning give a brief idea about Evergreen |
09:47 |
berick |
hi aashita! welcome |
09:48 |
aashita |
Actually i have requested wiki account from Kathy Lussier |
09:49 |
aashita |
but no response has yet come |
09:49 |
aashita |
Also i have checked each option in patron search , |
09:50 |
aashita |
and found some correction ways too, so i want without any delay grant me access rights to edit Docu wiki |
09:57 |
berick |
aashita: great... |
09:58 |
berick |
anyone around who can create a wiki account for aashita ? |
09:59 |
|
kbutler joined #evergreen |
09:59 |
bshum |
Well, it says on the wiki's front page: "How do I get an account on this wiki? Answer: please send an email request to docsevergreen-ils.org" |
09:59 |
bshum |
http://wiki.evergreen-ils.org/doku.php |
09:59 |
bshum |
So I'd probably do that. |
09:59 |
berick |
bshum: heh. good idea! |
10:00 |
bshum |
aashita: If you send a request to that email, I would expect that one of the volunteers who works that address could help get you set up. |
10:02 |
* berick |
will respond to aashita via email as well |
10:03 |
bshum |
athira: Hmm, there are certainly many ways to contribute to Evergreen. Contribution takes many forms, I often think straight to code, but there's also documentation, testing, developing proposals for new features. |
10:03 |
bshum |
(just naming things off the top of my head, there's no exact list I can point you at) |
10:13 |
|
aashita joined #evergreen |
10:13 |
aashita |
Thanks Berick and bshum |
10:13 |
aashita |
I have sent mail. |
10:31 |
|
snigdha26 joined #evergreen |
10:59 |
|
gsams joined #evergreen |
11:30 |
atlas__ |
so |
11:30 |
atlas__ |
importing a 1.2GB marc file of bibs |
11:30 |
atlas__ |
how to? |
11:30 |
atlas__ |
id prefer to have it all just happen on the server instead of through the staff client |
11:31 |
atlas__ |
my session timed out last night while it was processing it appeared |
11:31 |
atlas__ |
also no status indicator on the upload is kind of weak, I had to monitor its status with nettop :( |
11:38 |
|
StephenGWills left #evergreen |
11:39 |
* bshum |
idly wonders how many people got Columbus Day off as a holiday. |
11:40 |
bshum |
atlas__: I wish the client handled loading better too, long list of wishlist things. |
11:40 |
RoganH |
bshum: not I |
11:40 |
bshum |
atlas__: For a file that large, I think that you will definitely have to use some server side process. |
11:41 |
bshum |
There's various scribbles people have on that |
11:42 |
bshum |
I'm not really the best person to offer suggestions right now though. Migration is an area I'm still exploring to understand myself. |
11:44 |
bshum |
Maybe something like : http://docs.evergreen-ils.org/2.1/html/migrating_records_using_migration_tools.html |
11:45 |
bshum |
As an example of approaches others have used in the past. |
11:45 |
bshum |
Not 100% sure of current application. |
11:46 |
|
sandbergja joined #evergreen |
11:47 |
atlas__ |
yeah I found tht 2.1 documentation |
11:47 |
atlas__ |
just a bit concerned about how much applies to 2.7 |
11:48 |
atlas__ |
I guesss these tools were updated very recently http://git.esilibrary.com/?p=migration-tools.git;a=summary |
11:49 |
bshum |
The riskier the road, the greater the profit. |
11:57 |
atlas__ |
hmm keep getting remote host hungup unexpectedly when trying to clone from esilibrary's migrationtools git repo |
12:00 |
gsams |
bshum: We only get President's Day, Good Friday, Independence Day, Thanksgiving, Christmas +Eve, and New Years Day. |
12:00 |
gsams |
in case you were in any way curious |
12:01 |
atlas__ |
hmm error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://git.esilibrary.com/git/migration-tools.git/info/refs |
12:01 |
atlas__ |
try it without ssl |
12:02 |
atlas__ |
nooope |
12:02 |
atlas__ |
no /info/refs file there |
12:02 |
atlas__ |
hmm |
12:05 |
bshum |
atlas__: I might just go with git clone git://git.esilibrary.com/migration-tools |
12:06 |
atlas__ |
what the f |
12:06 |
atlas__ |
git clone git://git.esilibrary.com/git/migration-tools.git |
12:06 |
atlas__ |
okay |
12:06 |
atlas__ |
so no /git/ and it works |
12:06 |
atlas__ |
shit didn't even notice the path |
12:06 |
atlas__ |
thank you |
12:06 |
bshum |
Yeah the instruction on the 2.1 page is wrong |
12:07 |
bshum |
Or the git server has changed in the years since it was first written |
12:07 |
bshum |
(likely the latter) |
12:07 |
atlas__ |
yeah |
12:07 |
atlas__ |
looks like they got rid of the superfilous /git/ |
12:22 |
|
dreuther joined #evergreen |
12:23 |
jeff |
atlas__: I appreciate the candid feedback you've given here, and also appreciate some of your frustration, but could you please try to tone down your language a bit? We tend to keep things fairly free of expletives in #evergreen -- Thanks! |
12:27 |
|
chatley joined #evergreen |
12:30 |
|
mllewellyn joined #evergreen |
12:35 |
|
chatley_ joined #evergreen |
12:37 |
|
dreuther joined #evergreen |
12:41 |
|
chatley joined #evergreen |
12:55 |
|
chatley joined #evergreen |
12:55 |
|
dreuther joined #evergreen |
12:56 |
|
vlewis joined #evergreen |
13:07 |
atlas__ |
jeff: really? |
13:10 |
jeff |
atlas__: yup, I really do appreciate the feedback. there are places where Evergreen behaves in a confusing or unexpected way, and it's easy to forget and get used to some of these behaviors after the "newness" wears off. I like the reminder that there's room for improvement in these areas. |
13:11 |
jeff |
atlas__: unless you meant "really?" in response to my comment about things being kept fairly expletive-free in here, in which case, "yeah. really." |
13:20 |
|
micaela joined #evergreen |
13:21 |
|
micaelaneus joined #evergreen |
13:23 |
atlas__ |
jeff: no, no I'm glad you're reading the feedback |
13:23 |
atlas__ |
jeff: if you want help updating the documentation I can do that as I go through this |
13:23 |
atlas__ |
jeff: there have been a lot more expletives that haven't made their way into this IRC channel |
13:44 |
bshum |
Huh, we can't seem to edit copies via the edit link in the TPAC interface on 2.7 |
13:45 |
bshum |
It opens the window, we make changes, nothing saves. |
13:45 |
bshum |
And I'm not even seeing a function call in the logs to go and update the copy |
13:45 |
bshum |
Maybe it's a unified editor problem |
13:49 |
bshum |
Yep, it's the unifed editor. |
13:50 |
bshum |
When it spawns the unified editor from the new "edit" links next to the copies in the copy summary from the TPAC |
13:51 |
bshum |
Interesting... |
13:51 |
bshum |
It works in master, but not in production. Great, just great... |
13:52 |
bshum |
Yep, it's just us, master is fine. |
13:52 |
mllewellyn |
lucky us |
13:55 |
RoganH |
Somehow I get the feeling you don't actually feel lucky. |
13:57 |
mllewellyn |
well, there's luck and there's luck. |
14:16 |
bshum |
That's so weird. |
14:16 |
bshum |
It's like the call to update the copy just doesn't happen |
14:17 |
bshum |
And it commits with nothing and thinks it's fine |
14:17 |
|
micaelaneus joined #evergreen |
14:28 |
|
sseng joined #evergreen |
14:47 |
|
julialima joined #evergreen |
14:48 |
julialima |
hello evergreeners! |
14:49 |
* bshum |
waves over to julialima |
14:51 |
|
dreuther_ joined #evergreen |
15:03 |
|
gsams joined #evergreen |
15:05 |
berick |
can anyone think of a reason why a call to 'DELETE FROM action.hold_copy_map WHERE id = foo' would sit idle in transaction indefinitely -- almost two hours in this case (so far)? |
15:05 |
berick |
called from a checkout |
15:05 |
berick |
pg_stat_activity shows waiting=false |
15:08 |
RoganH |
I was going to suggest checking pg_stat_activity until I got to your third line. hmmmm...... |
15:09 |
RoganH |
Does stat_activity show any other active connections that could be locking the table? |
15:09 |
berick |
i think waiting=false means the query is not waiting on any locks |
15:11 |
RoganH |
I think so too but I was just mentally going through the list of general things to check. |
15:12 |
berick |
yeah... |
15:17 |
RoganH |
Since you said it's idle so it's not waiting on a client response and if there aren't any locks I can't think why it would. |
15:18 |
tsbere |
maybe the transaction was opened, the delete from was called, and then the client just stopped sending things so the transaction is waiting for the next statement? |
15:18 |
berick |
tsbere: was just thinking the same thing... |
15:19 |
berick |
the cstore drone is still there, polling the PG file handle |
15:19 |
berick |
which suggests (i think) it's still waiting for a response from PG |
15:19 |
tsbere |
Will cstore decide "tired of waiting" and rollback eventually? |
15:19 |
berick |
good question |
15:20 |
tsbere |
(and if so, is this an indication that said functionality broke?) |
15:20 |
|
alynn26 joined #evergreen |
15:23 |
berick |
don't think such a thing exists |
15:23 |
tsbere |
berick: "polling the handle" could also mean "poking from a keepalive POV", I think |
15:26 |
|
micaelaneus joined #evergreen |
15:26 |
berick |
I could see that, but I would expect an idle cstore child to be blocking inside a select() on the data pipe to the cstore listener (waiting for requests) instead of talking to the DB. |
15:27 |
berick |
still sitting in poll().. may just have to cancel the backend and try the checkout again. |
15:28 |
tsbere |
berick: Wouldn't an in-transaction cstore be waiting on XMPP, not the listener? |
15:28 |
berick |
yes, an active cstore child would be waiting on xmpp or the DB. |
15:29 |
tsbere |
and given that the DB is in a transaction, cstore likely is too, so I would assume the data pipe to the listener is a non-issue for the drone in question |
15:30 |
berick |
yeah, i was answering a different question that you didn't ask. |
15:30 |
berick |
indeed, the pipe would not come into place if the cstore child was alive and doing stuff |
15:30 |
berick |
s/place/play/ |
15:31 |
tsbere |
My current assumption (with very little proof, mind you, not being able to look directly at anything) is "the other process that asked the cstore drone to run the delete query never got around to telling cstore it was done for some reason" |
15:32 |
berick |
it didn't tell cstore it was done, because cstore never returned a response to the DELETE call (the one that's idle) |
15:34 |
berick |
eventually that query timed out within open-ils.circ, so it blindly went about trying new queries, all of which blocked and timeed out, becuase they were locked by the idle DELETE call. |
15:37 |
tsbere |
dunno. |
15:37 |
berick |
yeah, just gonna cancel it |
15:46 |
|
sandbergja joined #evergreen |
15:51 |
|
dreuther joined #evergreen |
16:10 |
mrpeters |
well, i can log in with 2.7 staff client on Windows 10 :P |
16:10 |
mrpeters |
thats a good sign |
16:10 |
mrpeters |
and it didnt take me googling "how to reboot" like Windows 8 did haha |
16:12 |
mrpeters |
this "Windows Feedback" feature in the technical preview is really cool |
16:12 |
mrpeters |
it noticed i used control panel instead of the settings app, and popped up asking me which i prefered and why |
16:13 |
bshum |
Heh, cute. |
16:13 |
mrpeters |
Yeah, you know I kind of liked that |
16:14 |
mrpeters |
I might put this on my laptop for a while. I just use it to play around on, and it was a touch screen built for Windows 8 maybe I should give it a whirl and use that feedback feature. Very cool, if they actually listen to the responses. |
16:15 |
* mrpeters |
doesn't think he has keys on file anymore to push a working branch for a bug fix, but its a minor one |
16:15 |
mrpeters |
index.xhtml (staff client splash page) still says Copyright 2006-2012 |
16:15 |
mrpeters |
should be updated 2014 (or maybe there is a way to make it dynamic?) |
16:18 |
bshum |
I thought it was dynamic |
16:18 |
bshum |
Maybe it's not. |
16:19 |
bshum |
Or maybe we made the TPAC dynamic and not that one |
16:19 |
bshum |
I think dynamic would be good. |
16:22 |
mrpeters |
tpac is indeed fine |
16:22 |
mrpeters |
its the splash page only |
16:46 |
|
dreuther_ joined #evergreen |
17:34 |
|
nhilton joined #evergreen |
17:36 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
17:38 |
berick |
huh, same node error we saw a few weeks ago. |
17:38 |
bshum |
I'm starting to get paranoid about that |
17:42 |
bshum |
berick's new acq bugs also make me twitchy. |
17:42 |
berick |
bshum: well, the bugs are old |
17:42 |
berick |
if that makes you feel any better |
17:42 |
bshum |
berick: No, I guess it really doesn't :) |
17:42 |
berick |
haha |
17:42 |
bshum |
berick: But thanks for trying ;) |
17:49 |
phasefx |
berick: bshum: if you guys ever need to get into the vm after such an error to poke around, we can do that |
17:51 |
berick |
phasefx: thanks. |
17:51 |
|
micaelaneus joined #evergreen |
17:52 |
berick |
i'm not *too* worried in this case, since it's related to the build instead of the running code, but if it continues i may take you up on it. |
17:54 |
phasefx |
without me doing anything now, anyone with sudo on the community buildbot server could become the "live" user and then ssh to the qa server |
18:11 |
* bshum |
googled "LRC" to mean "Library Resource Center" (maybe) |
18:33 |
|
nhilton_ joined #evergreen |
18:34 |
|
dreuther joined #evergreen |
19:29 |
|
dreuther joined #evergreen |
19:46 |
* dbs |
reopened bug 1172332 because it is a confirmed problem with Ubuntu 12.04 and we therefore need to either document it or update the prereq installer or both. |
19:46 |
pinesol_green |
Launchpad bug 1172332 in Evergreen "simple2zoom has segmentation faults" (affected: 1, heat: 8) [Undecided,Confirmed] https://launchpad.net/bugs/1172332 |
22:45 |
|
artunit_ joined #evergreen |
22:46 |
|
mmorgan1 joined #evergreen |
22:47 |
|
sbrylander joined #evergreen |
23:02 |
|
_bott_ joined #evergreen |
23:06 |
|
pastebot joined #evergreen |