| 02:42 |
|
StomproJ joined #evergreen |
| 04:51 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:42 |
|
mceraso joined #evergreen |
| 06:47 |
|
bshum joined #evergreen |
| 07:08 |
|
phasefx joined #evergreen |
| 14:46 |
berick |
related, I just got around to porting the wheezy installer to trusty at random/collab/berick/trusty-auto-installer |
| 14:46 |
berick |
bonus points for being called "trusty auto installer" ;) |
| 14:47 |
bshum |
berick++ # that's awesome sounding :D |
| 14:50 |
phasefx |
berick++ Do we want to separate out the qa stuff from the wheezy installer, or bundle all installers + qa together? It looks like the trusty one would still work with the qa tests with the way it's producing output |
| 14:51 |
* berick |
wonders if anyone has had a chance to look at bug #1366964 |
| 14:51 |
pinesol_green |
Launchpad bug 1366964 in Evergreen "Transaction Issues with libdbi 0.9.0" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1366964 |
| 14:51 |
berick |
phasefx: i like having the QA stuff in there |
| 14:51 |
berick |
though, admittedly, I don't often use it all. |
| 14:52 |
bshum |
berick: I was just looking at the code, but I'm not in a position to test till next week sometime. |
| 14:53 |
* berick |
nods |
| 14:53 |
|
dcook__ joined #evergreen |
| 14:54 |
bshum |
Eager to try it out though, of course :) |
| 14:54 |
phasefx |
berick: I think we should option out the timezone stuff.. it's important for the qa tests, maybe, but not for someone in some arbitrary timezone |
| 14:55 |
phasefx |
s/arbitrary/different/ |
| 14:55 |
berick |
phasefx: ah, hadn't thought about that |
| 14:55 |
* berick |
forgets what all is in the tests |
| 14:55 |
phasefx |
something prompted us to set the timezone for the qa vm, I think |
| 14:56 |
bshum |
Ugh, speaking of timezones.... good night folks. See you all again in a week. |
| 14:57 |
berick |
sleep well, bshum |
| 15:36 |
hbrennan |
Thanks, gmcharlt |
| 15:36 |
* csharp |
saw a huge crowd of people at the Apple Store at Lenox Mall standing around for hours *just in case* a shipment of new iPhones arrived |
| 15:37 |
hbrennan |
I'm glad that's not even a choice for me |
| 15:37 |
csharp |
hbrennan: fwiw, we're running our test 2.7.0 cluster on OpenSRF 2.4 alpha, and we haven't seen problems |
| 15:38 |
* csharp |
pets his trusty Galaxy Note 2 |
| 15:38 |
bshum |
hbrennan: fwiw, we run 2.7.0ish in production with OpenSRF 2.4 alpha and haven't seen any explosions either. |
| 15:38 |
hbrennan |
That's good to know, thanks csharp |
| 15:38 |
* bshum |
tries to sleep again |
| 20:43 |
|
kmlussier joined #evergreen |
| 20:45 |
kmlussier |
@later tell csharp I think we may be having trouble with the oversight board list. There are recent 3 messages in the archive that don't appear to have been sent out. |
| 20:45 |
pinesol_green |
kmlussier: The operation succeeded. |
| 22:13 |
* jeff |
shakes his fist a marc_stream_importer.pl |
| 22:13 |
jeff |
quote the script, "Failed to import 1 records" |
| 22:19 |
jeff |
quoth, even. |
| 22:20 |
jeff |
(not to be confused with Kvothe) |
| 22:29 |
jeff |
ah. |
| 22:29 |
jeff |
1) marc_stream_importer.pl requires a full path for the spool file if running in --no-daemon mode |
| 22:30 |
jeff |
2) marc_stream_importer.pl deleted the spool file |
| 22:30 |
jeff |
3) the permissions in this particular test database are... in an interesting state. |
| 22:42 |
* jeff |
runs smack dab into bug 1170514 |
| 22:42 |
pinesol_green |
Launchpad bug 1170514 in Evergreen "vandelay.auto_overlay_bib_record discrepancy" (affected: 1, heat: 8) [Undecided,Confirmed] https://launchpad.net/bugs/1170514 |
| 23:14 |
|
dcook joined #evergreen |
| 15:55 |
pinesol_green |
Dyrcona: What are you asking me for? |
| 15:56 |
kmlussier |
eightball appears to be a little snippy today. |
| 15:56 |
kmlussier |
eightball appears to be a little snippy today. |
| 15:59 |
rangi |
Dyrcona: my plan is to get all the unit tests up to scratch, then merge your stuff and fix until the tests pass again, moving my branch to old_stuff and the new merged branch becoming master |
| 15:59 |
rangi |
Dyrcona: my plan is to get all the unit tests up to scratch, then merge your stuff and fix until the tests pass again, moving my branch to old_stuff and the new merged branch becoming master |
| 15:59 |
Dyrcona |
rangi: Cool, bro. ;) |
| 15:59 |
Dyrcona |
rangi: Cool, bro. ;) |
| 16:00 |
Dyrcona |
I'm still working with Auto-graphics. Found some template issues last night. I botched the messages a bit. |
| 16:00 |
Dyrcona |
I'm still working with Auto-graphics. Found some template issues last night. I botched the messages a bit. |
| 16:00 |
Dyrcona |
Also, it seems that when validating with the schema, the order of some of the elements matters. |
| 16:00 |
Dyrcona |
Also, it seems that when validating with the schema, the order of some of the elements matters. |
| 16:03 |
rangi |
yeah i had to work with auto graphics too .. you'd think they would know their product better, but no ... werent able to get sample messages, couldnt set up a test instance etc ... everything just takes a zillion times longer, didnt help that they first were sending ncip 1.0 messages then changed to 2.0 mid dev stream |
| 16:03 |
rangi |
yeah i had to work with auto graphics too .. you'd think they would know their product better, but no ... werent able to get sample messages, couldnt set up a test instance etc ... everything just takes a zillion times longer, didnt help that they first were sending ncip 1.0 messages then changed to 2.0 mid dev stream |
| 16:17 |
Dyrcona |
Oh, I was going to do this earlier, but got distracted by work: xmllint++ xmlstarlet++ |
| 16:17 |
Dyrcona |
Oh, I was going to do this earlier, but got distracted by work: xmllint++ xmlstarlet++ |
| 16:32 |
kmlussier |
I've always wondered - is there a reason the bib record in the catalog shows both a "Next 10" link and a "show more copies" link? Shouldn't it be one or the other? |
| 17:10 |
pinesol_green |
Hmm... kmlussier... Let me see now... RAVENCLAW! |
| 17:11 |
kmlussier |
Heh...my daughter is amused by that. |
| 17:11 |
kmlussier |
Heh...my daughter is amused by that. |
| 17:17 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:17 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:20 |
|
mmorgan left #evergreen |
| 17:20 |
|
mmorgan left #evergreen |
| 17:24 |
pinesol_green |
[evergreen|Galen Charlton] LP#1384868: limit fund drop-downs on the invoice page to only active funds - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4e29499> |
| 17:24 |
pinesol_green |
[evergreen|Galen Charlton] LP#1384868: limit fund drop-downs on the invoice page to only active funds - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4e29499> |
| 17:44 |
|
mrpeters left #evergreen |
| 17:44 |
|
mrpeters left #evergreen |
| 18:44 |
|
dbwells joined #evergreen |
| 00:58 |
|
akilsdonk joined #evergreen |
| 01:35 |
|
aliceR joined #evergreen |
| 05:05 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:42 |
|
eeevil joined #evergreen |
| 06:42 |
|
mtate joined #evergreen |
| 06:43 |
|
phasefx joined #evergreen |
| 15:11 |
kmlussier |
csharp++ |
| 15:13 |
csharp |
cool |
| 15:14 |
tsbere |
kmlussier: Actually, if you are on any aliases, you are probably benefitting from me fixing the access list. Given that you are on the same server as me and the messages are coming from the same place ;) |
| 15:15 |
kmlussier |
tsbere: No, I also tested with my gmail address just to rule out MVLC being the issue. :) |
| 15:30 |
|
buzzy joined #evergreen |
| 15:37 |
|
jwoodard joined #evergreen |
| 15:41 |
|
nhilton joined #evergreen |
| 17:50 |
|
whargrove joined #evergreen |
| 17:51 |
whargrove |
Hi all, is it possible to configure evergreen to require a terminal password for SIP commands? |
| 18:01 |
jeffdavis |
whargrove: What do you mean by a terminal password? Our SIP clients (self-check machines etc) do need to submit a username and password for authorization before they can do anything... |
| 18:05 |
whargrove |
jeffdavis: Right, I understand that and we have verified our SIP client works with evergreen |
| 18:05 |
whargrove |
jeffdavis: we are using Evergreen as a dev sandbox |
| 18:06 |
whargrove |
and another vendor wants us to send terminal password and we want to test it with evergreen |
| 18:06 |
whargrove |
not a requirement for SIP to work with evergreen, but I want to see if I can test the changes with our evergreen server |
| 18:12 |
|
rjackson-isl joined #evergreen |
| 18:13 |
|
sandbergja joined #evergreen |
| 18:30 |
|
whargrove joined #evergreen |
| 02:22 |
|
dbwells joined #evergreen |
| 03:27 |
|
StomproJ joined #evergreen |
| 05:05 |
|
Stompro joined #evergreen |
| 05:41 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:46 |
|
mtate joined #evergreen |
| 06:46 |
|
eeevil joined #evergreen |
| 06:47 |
|
Callender joined #evergreen |
| 12:29 |
|
nhilton joined #evergreen |
| 12:31 |
|
sandbergja joined #evergreen |
| 12:33 |
|
sandbergja joined #evergreen |
| 12:34 |
mmorgan |
jboyer-isl: we're on 2.6.2, in a highly unscientific test, I just edited barcodes on 20 patrons on our training system and didn't freeze up. Are you able to reproduce?mmmpooj |
| 12:34 |
mmorgan |
oops, sorry about that last... |
| 12:35 |
jboyer-isl |
mmorgan: I’ve started poking around at our migration server but I’m also on a Mac here, so there are multiple variables now. |
| 12:36 |
mmorgan |
never a shortage of variables :) |
| 12:38 |
mmorgan |
freeze ups have been an ongoing elusive problem, we've never looked at patron edit, but we'll keep it in mind to look at now. |
| 12:44 |
jboyer-isl |
Well, It may not be ram related. I edited maybe 7-8 accounts and the client is completely locked up, only 390MB in use on a 16GB machine. :-/ |
| 12:49 |
mmorgan |
Wow! Are you just editing barcodes? |
| 12:50 |
Dyrcona |
jboyer-isl: Did you say you were doing this on a Mac Book? |
| 12:51 |
jboyer-isl |
I did my personal test on an iMac, the actual issue is on Windows PCs at our new member. |
| 12:51 |
jboyer-isl |
mmorgan: I edited barcodes and added 1 day to their birthdays as if there were other edits to make. |
| 12:52 |
Dyrcona |
Well, I would not be surprised if XulRunner has more problems on a Mac than on other platforms. |
| 12:52 |
Dyrcona |
In my sporadic, and unscientific testing, it certainly appears to. |
| 12:53 |
jboyer-isl |
Dyrcona: I wouldn’t be surprised either, though I am surprised I got it to break. I can’t seem to ever run into problems when I’m trying to. |
| 12:54 |
Dyrcona |
Well, that often happens when you want something to go wrong it doesn't. That usually means your initial impression of the problem is wrong. |
| 12:55 |
Dyrcona |
But, for anyone following the bug email, I solved my Z39.50 problem. I made a typo in the config. |
| 00:44 |
|
nhilton joined #evergreen |
| 00:51 |
|
nhilton_ joined #evergreen |
| 02:47 |
|
terence joined #evergreen |
| 05:27 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:12 |
|
kmlussier joined #evergreen |
| 06:30 |
* bshum |
wishes everyone a happy Monday. |
| 06:35 |
bshum |
@later tell gmcharlt Guess we'll need a plan to upgrade Piwik someday for the webstats.http://piwik.org/blog/2014/10/announcing-piwik-will-end-php-5-3-support-six-months-may-2015/ |
| 09:10 |
bshum |
csharp: I didn't get to finish 2.7.1 before I left for my travels |
| 09:27 |
tsbere |
csharp: Sometimes git cherry-pick is better, wrapped in a "give me all the commit hashes from <base branch> to HEAD on the customized branch, then cherry-pick them into the new customization branch in order" - Lets you skip some of the "prep version and upgrade script" commits from release branches. |
| 09:27 |
tsbere |
(without having to find them in the interactive list) |
| 09:32 |
phasefx |
jeff: roger roger, thanks man re: dns and test |
| 09:47 |
csharp |
bshum: no prob ;-) |
| 09:47 |
csharp |
tsbere: thanks for the tip - I was able to quickly identify and comment out the undesired commits |
| 09:48 |
|
sarabee joined #evergreen |
| 14:05 |
jeff |
whargrove: that said, yes Evergreen + SIPServer support it. There have been... inconsistencies identified in the standard, and I cheered when I saw that SIP3 removes checksums. :-) |
| 14:06 |
|
StephenGWills joined #evergreen |
| 14:08 |
Dyrcona |
+1 what jeff says. Some 3M products don't do checksums correctly, and it is their protocol. |
| 14:09 |
whargrove |
Got it, thanks for the responses |
| 14:10 |
whargrove |
One ILS vendor we are integrating with requires checksumming ... but we wanted to test it with our evergreen sandbox first |
| 14:10 |
jeff |
Can you name the vendor so that I can personally mock them? :-) |
| 14:11 |
Dyrcona |
whargrove: You should ask them where the serial cables are, 'cause TCP has checksumming built in, so checksumming on top of that is redundant. |
| 14:13 |
whargrove |
jeff: Carl.X |
| 15:52 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 15:53 |
Dyrcona |
Too many distractions. |
| 16:09 |
|
ldwhalen joined #evergreen |
| 16:41 |
phasefx |
qa tests passed this time, yay :) |
| 16:43 |
jeff |
phasefx: yay. did resolv.conf have one or both of those nameservers, or was it a different issue? |
| 16:44 |
phasefx |
jeff: right issue, different DNS servers |
| 16:45 |
jeff |
heh |
| 16:46 |
jeff |
did QTS recently notify customers with open resolvers or something? :-) |
| 16:46 |
phasefx |
no, it was all our fault; change internally and qa01 is a second class citizen :) |
| 16:47 |
jeff |
heh |
| 16:49 |
jeff |
shows how often I use non-lowercase identifiers in postgres... couldn't figure out why certain things weren't being found. |
| 16:50 |
jeff |
twas because the relation was named temp_Foo and unless I quoted it, it was being folded to temp_foo and not being found. |
| 16:50 |
jeff |
of course, the error doesn't fold the case, so: |
| 16:50 |
jeff |
jeff=> \d temp_Foo |
| 16:50 |
jeff |
Did not find any relation named "temp_Foo". |
| 16:51 |
jeff |
hrm. maybe part of this specific quirk is limited to temporary tables. |
| 16:52 |
jeff |
ah, nope. did it to myself again by not quoting when I created my test. |
| 16:52 |
jeff |
anyway. |
| 16:53 |
jeff |
> Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case. For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are different from these three and each other. |
| 16:57 |
|
tspindler left #evergreen |
| 17:00 |
|
dreuther_ joined #evergreen |
| 17:07 |
|
dreuther joined #evergreen |
| 17:09 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:25 |
|
nhilton_ joined #evergreen |
| 18:19 |
|
StephenGWills_ joined #evergreen |
| 18:47 |
|
StephenGWills left #evergreen |
| 00:50 |
|
atlas___ joined #evergreen |
| 00:53 |
|
AliceR joined #evergreen |
| 00:55 |
|
atlas__ joined #evergreen |
| 05:33 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:23 |
|
b_bonner joined #evergreen |
| 07:23 |
|
mnsri_ joined #evergreen |
| 07:24 |
|
mtcarlson_away joined #evergreen |
| 11:25 |
kmlussier |
eeevil: Thanks for the background on the setting. It's helpful. |
| 11:25 |
eeevil |
good! :) (and I agree on the description change) |
| 11:26 |
|
vlewis joined #evergreen |
| 11:28 |
tsbere |
Looking at the reshelving complete code, I think the "fix" for allowing it to run mid-day and not screw things up may actually be a single line of code. <_< Not sure how to *test* it though. |
| 11:29 |
hopkinsju |
tsbere: Can you put your idea into a paste? We may be able to help test it. |
| 11:31 |
tsbere |
hopkinsju: I was thinking just drop it into a working branch you could cherry-pick from. |
| 11:31 |
tsbere |
(and attaching said branch to the launchpad bug) |
| 11:32 |
Bmagic |
tsbere: sounds good to me |
| 11:48 |
eeevil |
Able. Autocorrect... |
| 11:50 |
* tsbere |
watched locks with and without the status = 7 checks and didn't see any noticable difference in them, but didn't exactly do an overly complete job of watching either and wasn't on a production-level system data-wise |
| 11:51 |
dbwells |
bshum: I would typically branch rel_2_x_x from rel_2_x, do the release stuff, then forward-port the upgrade file back to rel_2_x and master (eventually). Then all the scripts are already in rel_2_x for the next point release. Does that answer your question? |
| 11:53 |
eeevil |
My bigger point is that the current reshelver has an intended purpose, and IMO we should consider that when looking for a solution that is outside that original intent. I'm 100% for code reuse, but I think this might be stretching it, in this specific case... But, testing will tell |
| 11:55 |
tsbere |
eeevil: I am all for "new code for the new intent" or even "more efficient/targeted code for this intent" (only doing short-term reshelving when open, for example) - I am also all for calling it a bug that the reshelving complete code can, regardless of when or how often it is run, change the status of something *not* in reshelving at update time. |
| 12:04 |
|
sal_ joined #evergreen |
| 12:05 |
eeevil |
fair enough. in practice, of course, it /only/ happens during open hours, but yes, it's a fair point |
| 13:07 |
gmcharlt |
RoganH: I recalled that we discussed this the other day... do you want to put it through its paces a bit before we make an announcement? |
| 13:08 |
RoganH |
Yeah, let me play with it for a couple of days. |
| 13:08 |
gmcharlt |
kmlussier: very creatively... http://evergreen-ils.org/jobs/ |
| 13:08 |
RoganH |
I'll do some test posts, deletions, etc... |
| 13:08 |
gmcharlt |
RoganH: it also exposes a jobs dashboard |
| 13:08 |
gmcharlt |
http://evergreen-ils.org/job-dashboard/ |
| 13:08 |
kmlussier |
When you've run it through its paces, I would like to share the link with OPW. As OPW sponsors, I think we get a benefit of having our jobs page listed on their site. |
| 13:11 |
RoganH |
shiny ball received |
| 13:11 |
gmcharlt |
RoganH++ |
| 13:12 |
kmlussier |
RoganH++ |
| 13:12 |
gmcharlt |
so, noting a couple action items for myself |
| 13:12 |
gmcharlt |
#action (carry-over) gmcharlt will coordinate/assist with dbs to move the planet |
| 13:12 |
gmcharlt |
#action gmcharlt with work with DIG to get a test VM for doc-building set up |
| 13:13 |
kmlussier |
gmcharlt++ |
| 13:13 |
RoganH |
gmcharlt++ |
| 13:13 |
gmcharlt |
next up, the FAQs... |
| 16:47 |
* berick |
recalls a recent conversation about that |
| 16:47 |
kmlussier |
Yup. http://markmail.org/message/jsrbhxlwr2dshglv |
| 16:49 |
|
nhilton_ joined #evergreen |
| 16:57 |
pinesol_green |
[evergreen|Bill Erickson] LP#1261486 Action/trigger aggregator script repairs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a7c3267> |
| 17:03 |
|
kmlussier left #evergreen |
| 17:04 |
|
kmlussier joined #evergreen |
| 17:16 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:45 |
gmcharlt |
dokuwiki updated to current stable version |
| 19:10 |
|
maggieWCL joined #evergreen |
| 19:13 |
|
kmlussier joined #evergreen |
| 01:46 |
|
jcamins joined #evergreen |
| 03:29 |
|
AliceR joined #evergreen |
| 03:49 |
|
AliceR joined #evergreen |
| 05:19 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:40 |
|
mtate joined #evergreen |
| 06:40 |
|
eeevil joined #evergreen |
| 07:10 |
|
Callender joined #evergreen |
| 09:05 |
aashita |
Hi Berick! |
| 09:05 |
aashita |
i Just want to know only Julia Lima has done editing of UI style guide |
| 09:24 |
|
RoganH joined #evergreen |
| 09:36 |
mrpeters |
trying to load the concerto, etc. data in 2.7 -- error that "env_create.sql" is missing. Is this a part of the test dataset that maybe got left out, or a missing dependency |
| 09:39 |
tsbere |
mrpeters: I see env_create.sql in what I believe to be the correct location |
| 09:40 |
mrpeters |
is that not /home/opensrf/Evergreen-ILS-2.7.0/Open-ILS/tests/datasets/sql ? |
| 09:40 |
* tsbere |
is also looking at master |
| 09:41 |
Dyrcona |
mrpeters: Is this from git or a tarball? |
| 09:41 |
mrpeters |
tarball |
| 09:43 |
Dyrcona |
"Someone" being bshum. ;) |
| 09:44 |
Dyrcona |
I checked rel_2_7 and tags/rel_2_7_0, and the file is in both branches where it should be. |
| 09:44 |
Dyrcona |
Just for the record. |
| 09:45 |
mrpeters |
/home/opensrf/Evergreen-ILS-2.7.0/Open-ILS/tests/datasets/sql is correct location, no? |
| 09:45 |
Dyrcona |
Yes, it is. |
| 09:45 |
Dyrcona |
jason jason:~/Src/Evergreen$ find ./ -name env_create.sql |
| 09:45 |
Dyrcona |
./Open-ILS/tests/datasets/sql/env_create.sql |
| 10:16 |
|
yboston joined #evergreen |
| 10:24 |
kmlussier |
dbs: I must have missed your comment in IRC regarding adding berick's script-based install to the README, but if you point me in the right direction, I can, at a minimum, add it to the OPW wiki page. |
| 10:25 |
kmlussier |
I'll even try to add it to the README if I get a minute to breathe. :) |
| 10:29 |
|
buzzy joined #evergreen |
| 10:31 |
mrpeters |
hmm, so the env_create is in the tarball, it's just looking for it in the cd, so you have to be in the tests/datasets/sql/ directory |
| 10:31 |
mrpeters |
my fault for the false alarm |
| 10:33 |
tsbere |
mrpeters: Are you loading the files manually, instead of with eg_db_config? |
| 10:33 |
mrpeters |
the test data? i just do psql evergreen < load_all.sql |
| 10:33 |
tsbere |
mrpeters: If you use the flags for eg_db_config it does the cd and such for you. |
| 10:33 |
mrpeters |
i just was supplying the full path to load_all.sql, not realizing i had to be in that directory |
| 10:34 |
mrpeters |
ah, interesting. didn't know you could use eg_db_config to load all of that test data |
| 10:36 |
tsbere |
mrpeters: --load-all-sample or --load-concerto-sample, I think. |
| 10:36 |
mrpeters |
awesome, good to know |
| 10:52 |
|
krvmga joined #evergreen |
| 11:18 |
mrpeters |
ok, carry on |
| 11:18 |
mrpeters |
just wanted to dispell your incorrect impression |
| 11:18 |
tsbere |
besides, if you screw up the install steps you may not realize you did so if the package has things in the right place and your install has them in the wrong one, then bash your head as to why your changes aren't working. |
| 11:18 |
mrpeters |
the packaged evergreen is a VERY good way for someone to quickly get a test system up and running as long as they understand basic IP addressing and know how to install linux packages |
| 11:20 |
mrpeters |
thats fine, if you dont see it fit for a developer don't use it, no big deal, just sharing the information that this is available to anyone, and the myth that it is "just for PINES" is completely false |
| 11:20 |
tsbere |
mrpeters: My assumption was "PINES has public non-customized and private customized package sets" - I never assumed the ones I could get at were customized for PINES. |
| 11:21 |
gmcharlt |
well, rather depends on what the ultimate purpose is - if you want a running EG instance to test or document, sure, try the packages |
| 11:21 |
gmcharlt |
if you are aiming to do *coding* ... at the moment, I don't see any responsible way around installing from a git clone if the end result is meant to be useful to a *coder* |
| 11:24 |
mrpeters |
that is fair |
| 11:25 |
Dyrcona |
And, what about production? Do you think that would work from a packaged version?\ |
| 11:25 |
Dyrcona |
Right now, Evergreen is very "old school" in how you install it. Not saying I have a problem with that, but that is not noob friendly. |
| 11:46 |
csharp |
there are some hard-coded assumptions/choices that we have to make for packaging, but we think they're sane and easily changed |
| 11:47 |
Dyrcona |
For us, we build directly from git, and make an integration branch. |
| 11:47 |
mrpeters |
built right from the same code we use to build up PINES |
| 11:47 |
Dyrcona |
We also have two developers with development and test servers, so we're doing integration on a fairly frequent basis. |
| 11:47 |
csharp |
however, (sorry mrpeters :-) ), I have to agree with others that building from source (either by hand or by script) is the best way to participate in community development |
| 11:47 |
Dyrcona |
Conflicts occur, but are often noticed and resolved quickly, and well before we go into production. |
| 11:48 |
mrpeters |
i agree for CODE development |
| 11:48 |
Dyrcona |
We also load onto the test server several weeks before we go live in production so members can have a go at finding things that might not be quite right. |
| 11:48 |
mrpeters |
but if you just want to quickly test out evergreen, man, its a fast way to do it |
| 11:49 |
csharp |
I completely agree that using our deb repo is the easiest way to get up and running on Ubuntu on the most current stable release |
| 11:50 |
mrpeters |
i just remember the days when we supplied virtual box images for people who just wanted to "test out" evergreen |
| 11:50 |
csharp |
but... it obviously comes with the same limitations as all the other methods people have discussed (preferences, best practices, etc. can vary widely) |
| 11:50 |
mrpeters |
and it was a nightmare, they were always outdated, nobody wanted to manage them, etc. |
| 11:50 |
mrpeters |
had i known about this repo back then, man the pain we could have avoided! |
| 17:49 |
berick |
Bmagic: that's probably it |
| 17:50 |
Bmagic |
You think it's possible that the update query from the reshelver could hit on rows that have their status=1 even though the query clearly is looking for 7? |
| 17:51 |
berick |
grr, i opened a LP ticket about this a really long time ago, now i can't find it |
| 17:51 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:51 |
berick |
https://bugs.launchpad.net/evergreen/+bug/1018011 |
| 17:51 |
pinesol_green |
Launchpad bug 1018011 in Evergreen 2.4 "Incorrect copy status caused by reshelving process colliding with item checkout" (affected: 4, heat: 20) [Medium,Confirmed] |
| 17:52 |
berick |
wow, for the first time ever, LP search worked better than google |
| 01:12 |
|
mnsri joined #evergreen |
| 02:42 |
|
shresh joined #evergreen |
| 03:33 |
|
RBecker joined #evergreen |
| 06:01 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:01 |
|
artunit_ joined #evergreen |
| 07:03 |
|
Callender joined #evergreen |
| 08:00 |
|
eeevil joined #evergreen |
| 11:31 |
pinesol_green |
Launchpad bug 1379824 in Evergreen "Make PermaCrud.js disconnect() actually disconnect" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1379824 |
| 11:33 |
yboston |
dbwells: nice! |
| 11:34 |
bshum |
Calling 0894 |
| 11:37 |
yboston |
dbwells: is there anything I can help with? do you need me to test the commit and sign it off? |
| 11:38 |
pinesol_green |
[evergreen|Chris Sharp] LP#1374551: Create index on money.billing.voider to speed user merge. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=44bca3b> |
| 11:38 |
pinesol_green |
[evergreen|Ben Shum] LP#1374551: Stamping upgrade script for new index on money.billing.voider - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=896dea5> |
| 11:38 |
dbwells |
yboston: testing and signoffs are always appreciated! |
| 11:50 |
bshum |
Hmm, California. |
| 11:55 |
|
ldwhalen joined #evergreen |
| 12:02 |
|
nhilton joined #evergreen |
| 13:35 |
bshum |
bmills: I just pushed the selfcheck timeout fix to the repos. Hopefully you can make use of that fix sometime. :) |
| 13:37 |
bmills |
bshum: thanks! |
| 13:38 |
bmills |
bshum++ |
| 13:39 |
bshum |
mmorgan++ # thanks for testing! |
| 13:39 |
bshum |
jboyer-isl++ # think check on the JavaScript. |
| 13:53 |
|
RBecker joined #evergreen |
| 14:07 |
mmorgan |
bshum++ # thanks for fixing :) |
| 14:09 |
|
RBecker joined #evergreen |
| 17:22 |
Bmagic |
bmills: I'm not going to be much help as our system is not currently using authority. I hope there is someone here with more expierence with the DB authority.normalize_heading. You could bring it to the email list and get more response. |
| 17:23 |
bmills |
Bmagic: thanks! |
| 17:42 |
|
bmills1 joined #evergreen |
| 17:43 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:44 |
|
nhilton_ joined #evergreen |
| 17:54 |
bbqben |
jihpringle: bring leftovers to the office next week? |
| 17:55 |
jihpringle |
bbqben: I wish, I'm going to family friends for dinner so I won't have leftovers :( |
| 20:07 |
bshum |
My experience thus far is primarily Debian/Ubuntu. |
| 20:08 |
atlas__ |
I figured I should have started with one of those since they are listed first in the instruction order |
| 20:08 |
atlas__ |
so when I try to start all the opensrf services I just get 'authentication failed' and its because ejabberd seems to be borked |
| 20:09 |
bshum |
atlas__: Fedora is one of the targets, but nobody actively uses Fedora in production for Evergreen (as far as I know) |
| 20:10 |
bshum |
I think it's mainly there cause there's a few Fedora enthusiasts among the developers :) |
| 20:10 |
bshum |
It's entirely possible that something needs more love with Fedora 20. Just a quick glance at the instructions for OpenSRF seem to me that they were written with Fedora 17+ in mind (which might also mean that they haven't been fully tested yet with 20) |
| 20:10 |
atlas__ |
what do people run in production |
| 20:11 |
bshum |
Yeah, the Fedora build slave at testing.evergreen-ils.org is only Fedora 18. |
| 20:11 |
bshum |
atlas__: Go for Debian or Ubuntu. |
| 20:11 |
bshum |
Presently, Debian Wheezy (7.0) or Ubuntu 12.04 server would be my best recommendations. |
| 20:12 |
bshum |
Ubuntu 14.04 support is still... being worked out. |
| 20:12 |
atlas__ |
any reason to do one over the other? i've got more experience with ubuntu, but yeah 14.04 would be a lot better |
| 20:13 |
atlas__ |
I'd rather Fedora (clearly!). But if Debian is what most use in production I could probably figure it out. |
| 20:13 |
bshum |
atlas__: I consider it to be a personal preference. I use Ubuntu 12.04 for our systems. |
| 22:31 |
bshum |
https://bugs.launchpad.net/opensrf/+bug/714694 like dollar signs, etc. |
| 22:31 |
pinesol_green |
Launchpad bug 714694 in OpenSRF "Passwords cannot contain certain special characters" (affected: 1, heat: 6) [Medium,Won't fix] |
| 22:31 |
atlas__ |
ba dum tish |
| 22:31 |
bshum |
You'll want to try something a little simpler for testing :) |
| 22:32 |
atlas__ |
can I just re-run these register commands to get new ejabbderctl passwords |
| 22:33 |
bshum |
I was just looking up how to change the passwords |
| 22:33 |
atlas__ |
thank you thank you |
| 22:33 |
bshum |
ejabberdctl man page, whee |
| 22:34 |
bshum |
So maybe something like |
| 22:34 |
bshum |
sudo ejabberdctl change-password opensrf private.localhost password |
| 22:34 |
bshum |
Repeat for all four users |
| 22:34 |
bshum |
But basically "ejabberdctl change-password <user> <hostname> <password>" |
| 22:35 |
bshum |
And then make sure you change up your opensrf_core.xml passwords to match it |
| 22:35 |
bshum |
And .srfsh.xml too |
| 22:35 |
bshum |
For purposes of getting going, I'd do something alphanumeric. |
| 22:35 |
bshum |
Or if it's purely a test system... *cough, cough* "password" is probably fine :) |
| 22:37 |
bshum |
Maybe we ought to consider putting a note on that in the OpenSRF README on how people should avoid certain special characters that are known to break things. |
| 22:37 |
* bshum |
adds reminder for his future self. |
| 22:40 |
|
atlas__ joined #evergreen |
| 22:43 |
|
buzzy joined #evergreen |
| 03:11 |
|
jventuro joined #evergreen |
| 05:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:41 |
|
sseng_ joined #evergreen |
| 07:06 |
|
Sato joined #evergreen |
| 07:32 |
|
rjackson-isl joined #evergreen |
| 09:48 |
|
sarabee joined #evergreen |
| 09:48 |
dbs |
Oh, I know Sid. |
| 09:49 |
dbs |
I'm still decrementing ubuntu because this problem has existed for a couple of years. |
| 09:51 |
csharp |
well, to be pedantic, the LTS releases sync with debian testing, so this is likely a problem that would exist in jessie too |
| 09:52 |
csharp |
unless it doesn't pass muster with Debian testers, that is |
| 10:01 |
|
RoganH joined #evergreen |
| 10:15 |
kmlussier |
Web client testing is also a good way to remember old bugs that I forgot to file in LP. |
| 10:42 |
|
ningalls joined #evergreen |
| 10:48 |
kmlussier |
I'm looking at the self-check docs at http://docs.evergreen-ils.org/2.7/_self_checkout.html#_configuring_self_check_behavior. For "Patron Login Timeout," it says not currently supported. Is that still true? |
| 10:48 |
bshum |
kmlussier: Right |
| 10:49 |
kmlussier |
Oh, wait. I see the bug report. |
| 10:49 |
bshum |
kmlussier: So there's a bug ticket for that and I wrote new code during the hackaway |
| 10:51 |
bshum |
I haven't decided if it's a "new feature" or a "bug fix" though. |
| 10:53 |
kmlussier |
I would think bug fix since there is an existing setting that doesn't work. |
| 10:53 |
* mmorgan |
agrees that it's a bug fix |
| 10:53 |
bshum |
Oh fun then. |
| 10:54 |
bshum |
Well if anyone feels brave to try :) |
| 10:54 |
bshum |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/lp1306814-selfcheck-timeout |
| 10:54 |
bshum |
That's where I put the initial code I was poking at |
| 10:54 |
bshum |
I have to test it with an actual library setting configured. |
| 10:57 |
bshum |
I updated the bug report with a link to the code |
| 10:57 |
bshum |
And assigned targets as a bug fix. |
| 10:57 |
csharp |
heh - so it multiplies the patron timeout value by 1000? |
| 10:57 |
bshum |
Right, cause I think the setting is assigned as seconds |
| 10:57 |
bshum |
But the value is like milliseconds |
| 11:01 |
kmlussier |
bshum: But some of that was based on your custom 001 record attribute, right? |
| 11:01 |
bshum |
kmlussier: Correct, for us, abnormally large entries in our uncontrolled values table was causing slowdown, among other things. |
| 11:01 |
* kmlussier |
is looking at search performance on a system that doesn't have custom record attributes. |
| 11:01 |
bshum |
I'm finishing testing eeevil's fixes for that. |
| 11:02 |
bshum |
Define "slow" |
| 11:02 |
bshum |
Like have you guys turned on the debug timing and grabbed numbers on how things are? |
| 11:03 |
kmlussier |
This is a system where they timed searches on 2.5 and then timed then again after uprading the same system to 2.6. We're seeing numbers where the search took 3 seconds on 2.5 and is now taking 12-14 seconds. A big difference. |
| 11:03 |
kmlussier |
bshum: No, we haven't. |
| 11:04 |
|
DPearl joined #evergreen |
| 11:38 |
dbwells |
kmlussier: We didn't experience anything like the slowdowns shown in your chart. (great chart btw!) We also have a "normal" uncontrolled_record_attr_value table size (2551 rows). |
| 11:39 |
kmlussier |
dbwells: The credit for the great chart goes to tspindler. :) |
| 11:47 |
bshum |
csharp: Vacuuming the table didn't do anything for us, the new code helped :) |
| 11:50 |
Bmagic |
Im testing 2.7, right off the bat I don't see the secondary permission group UI in the staff client. Was there something I forgot to setup? |
| 11:51 |
kmlussier |
Bmagic: It should just display in the patron editor. And you need permission to see it. |
| 11:52 |
Bmagic |
kmlussier: huh, no magic trick? I am using an account with global everything |
| 11:54 |
bshum |
Hmm, it's working for me |
| 11:55 |
|
bkuhn joined #evergreen |
| 11:55 |
Bmagic |
I preformed an upgrade on an existing directory full of 2.6.1 code |
| 11:56 |
Bmagic |
aka /openils |
| 11:56 |
bshum |
Bmagic: That I don't know, all I know is that a clean install test server I was looking at seems fine. |
| 11:59 |
|
nhilton joined #evergreen |
| 11:59 |
|
ningalls joined #evergreen |
| 12:05 |
|
jihpringle joined #evergreen |
| 12:09 |
berick |
gmcharlt: were you able to make any headway w/ your nginx for websockets test? |
| 12:10 |
berick |
one of the OPW candidates cannot access webby... wondering if it's a port issue |
| 12:10 |
Bmagic |
bshum: I got it figured out, yay! |
| 12:10 |
gmcharlt |
berick: wouldn't surprise if it were; I expect to have tuits for that tomorrow |
| 12:10 |
kmlussier |
berick: We had a similar issue with another OPW candidate. We narrowed it down to the ports issue. |
| 16:11 |
bshum |
See, this bug.... |
| 16:11 |
bshum |
https://bugs.launchpad.net/opensrf/+bug/1369169 |
| 16:11 |
pinesol_green |
Launchpad bug 1369169 in OpenSRF "Add install instructions for websockets to README (and other cleanup)" (affected: 1, heat: 6) [Undecided,New] |
| 16:11 |
berick |
Bmagic: node, bower, etc. are only used for dependency retrieval and unit tests. it's not needed for running the browser client. |
| 16:12 |
bshum |
Bmagic: http://evergreen-ils.org/~bshum/OpenSRF-README.html#_optional_websockets_installation_instructions |
| 16:12 |
bshum |
That's a generated copy of the integrated steps |
| 16:12 |
Bmagic |
!! |
| 16:38 |
|
buzzy joined #evergreen |
| 17:15 |
|
mmorgan left #evergreen |
| 17:24 |
|
buzzy joined #evergreen |
| 17:49 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:51 |
bshum |
But gmcharlt, the quest_for_knowledge is over! |
| 17:51 |
bshum |
http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=988605ececad7850f2a7276b64a697b6b5c9ae31 |
| 17:51 |
pinesol_green |
[evergreen|Dan Wells] LP#1290496: The quest for knowledge is over - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=988605e> |
| 15:08 |
bshum |
kmlussier++ # testing too :) |
| 15:08 |
jeff |
#action dbwells to update Conditional Negative Balances bug 1198465 with links to new branches, etc. |
| 15:08 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 14, heat: 62) [Wishlist,Confirmed] https://launchpad.net/bugs/1198465 |
| 15:09 |
jeff |
kmlussier++ dbwells++ berick++ Dyrcona++ and probably more :-) |
| 15:09 |
jeff |
#info jeff and csharp to test websockets work by the end of this week. |
| 15:09 |
jeff |
That happened and/or didn't happen, but what did happen was (iirc): |
| 15:09 |
jeff |
#info gmcharlt to cut alpha of OpenSRF the middle of next week (week of Aug. 4th) |
| 15:10 |
bshum |
That did occur I think |
| 15:10 |
bshum |
Or at least, there's an OpenSRF 2.4 alpha around :) |
| 15:10 |
* jeff |
nods |
| 15:15 |
bshum |
There's a few things we have to put in there I think |
| 15:15 |
bshum |
And I need to revisit the updates I made to the main README for websocket steps. |
| 15:15 |
jeff |
bshum: currently, due to websockets and other things, Evergreen 2.7 does require OpenSRF 2.4 alpha, correct? Downloads page seems to confirm... |
| 15:15 |
bshum |
Generally speaking, yes. |
| 15:15 |
bshum |
I never tested it with anything less. |
| 15:15 |
bshum |
I think that's correct though. |
| 15:16 |
bshum |
It doesn't require websockets |
| 15:16 |
jeff |
bshum: anything specific that you/gmcharlt could use help/signoff with toward the goal of OpenSRF 2.4 making it to release? |
| 15:16 |
bshum |
But I think there were other changes. |
| 15:16 |
bshum |
Bug with branch is https://bugs.launchpad.net/opensrf/+bug/1369169 |
| 15:18 |
bshum |
Now that Dyrcona mentions it, the only reason to use OpenSRF 2.4 with Evergreen 2.7 is if you wanted websockets to play with the web based staff client. I think. |
| 15:18 |
ldw |
#info ldw is Liam Whalen Sitka |
| 15:18 |
jeff |
#topic Release info - Evergreen |
| 15:18 |
bshum |
I didn't personally test OpenSRF 2.3 stable with Evergreen 2.7 though to make sure that XUL stuff and catalog is still happy. |
| 15:18 |
jeff |
Evergreen 2.7 is released! Everyone's upgraded by now, right? |
| 15:18 |
* jeff |
ducks |
| 15:18 |
bshum |
If anyone wants to volunteer to try that, maybe that's worth it. |
| 15:18 |
bshum |
But really, getting 2.4 out the door is better anyways :D |
| 15:19 |
bshum |
jeff: Actually......! |
| 15:19 |
jeff |
#info Testing of Evergreen 2.7 with OpenSRF 2.3 would be appreciated -- pass feedback to bshum |
| 15:19 |
Dyrcona |
jeff: We're on 2.7alpha give or take a few later fixes. |
| 15:19 |
bshum |
We were going to upgrade to 2.7 a few days after I cut 2.7.0, but we were delayed a bit. We plan our upgrade to 2.7 this upcoming Saturday. |
| 15:19 |
jeff |
excellent. |
| 15:21 |
jeff |
#info bshum to push things to rel_2_7 in preparation for scheduled 2.7.1 maintenance release |
| 15:21 |
bshum |
If anyone else has any bug fixes with code that they want to see in 2.7.1, please feel free to target or put a pullrequest up. |
| 15:21 |
jeff |
#info bshum pulling updated translations for tpac (and other areas) into 2.7.1 |
| 15:22 |
bshum |
And if anyone has time to test and sign-off on them, that'd be great too :) |
| 15:22 |
jeff |
bshum: anything else for Evergreen release info/updates? |
| 15:22 |
bshum |
Nothing for me. I hope to keep 2.7 series happy and stable. |
| 15:22 |
jeff |
#info targeting, testing/signoff of bugs against 2.7.1 appreciated as always |
| 15:22 |
jeff |
bshum++ |
| 15:23 |
kmlussier |
bshum++ |
| 15:23 |
Dyrcona |
bshum++ |
| 15:23 |
jeff |
#topic New Business |
| 17:13 |
|
mdriscoll1 left #evergreen |
| 17:21 |
|
nhilton_ joined #evergreen |
| 17:23 |
|
StephenGWills left #evergreen |
| 17:35 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:41 |
|
dreuther_ joined #evergreen |
| 17:47 |
|
dreuther joined #evergreen |
| 17:49 |
|
nhilton joined #evergreen |
