| 00:50 |
|
mcarlson joined #evergreen |
| 02:37 |
|
tsbere__ joined #evergreen |
| 02:59 |
|
tsbere_ joined #evergreen |
| 04:28 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:05 |
|
mnsri joined #evergreen |
| 05:12 |
|
book` joined #evergreen |
| 07:27 |
|
collum joined #evergreen |
| 15:14 |
kmlussier |
As part of this action item and the next one, I haven't had a chance to review the most recent code or pull together my summary. The negative balance was 1 of 4 billing projects MassLNC was working on. We decided a few weeks ago to really focus on the other three so that we can get them out of the way before we get back to negative balances, which is a harder nut to crack. |
| 15:14 |
jeff |
(for rounding up scarce tuits) |
| 15:15 |
kmlussier |
But just glancing at dbwells' most recent comment, it looks like there is still a bit of work to be done before this branch is ready to be merged? |
| 15:15 |
dbwells |
Testing at the very least, but like I mentioned, I think a few hours spent on display side would be time well spent for me. |
| 15:16 |
kmlussier |
dbwells: I'm having a hard time picturing what you suggested in your comment, but I also had some concerns on the display side. |
| 15:18 |
kmlussier |
I also don't think I'll have a chance to test the most recent code until we finish working on our two remaining billing projects. Having two dev branches loaded on the test server at the same time causes confusion over which one might be causing a problem. |
| 15:19 |
Dyrcona |
Well, when they're related to the same part of the system, anyway. |
| 15:21 |
dbwells |
kmlussier: If you have a testing timeline in mind, I can try to work on my display ideas so you can test it at the same time. Feel free to get in touch after this meeting if needed. |
| 15:21 |
kmlussier |
So I guess we need some kind of action item for me to test the current branch and provide feedback? I don't know if anyone else wants to take a look at it. |
| 15:21 |
jeff |
I've interest but cannot guarantee that I can make time for it in the next month. |
| 15:22 |
kmlussier |
dbwells: Will do. I'll have to consult with Dyrcona regarding a testing timeline, but we can figure it in short order. |
| 15:22 |
jeff |
I'll see what I *can* do, though. |
| 15:22 |
kmlussier |
jeff++ Thanks! |
| 15:22 |
kmlussier |
#action kmlussier and others to make time to test the latest branch. |
| 15:23 |
kmlussier |
#action dbwells to work on display ideas for negative balance branch |
| 15:23 |
kmlussier |
dbwells and remingtron: Thanks for taking a look at it! |
| 15:23 |
kmlussier |
Anything else before we move on? |
| 15:23 |
jeff |
reducing the number of cases where we deviate from stock is a goal, and our own branch to avoid negative balances is ripe for elimination if we can assist in testing this one. |
| 15:23 |
Dyrcona |
dbwells++ remingtron++ |
| 15:24 |
kmlussier |
#topic OpenSRF release |
| 15:24 |
kmlussier |
Anything to report one OpenSRF? |
| 15:24 |
gmcharlt |
I'm looking for volunteers to test the websockets work submitted by berick |
| 15:24 |
gmcharlt |
any takers? |
| 15:24 |
bshum |
Further down in the agenda, there's some notes about websockets |
| 15:25 |
bshum |
Sorry, juggling between meetings |
| 15:25 |
jeff |
I can test, assuming berick or others are available for questions when I reach that point. |
| 15:25 |
berick |
anything I can do to make testing easier? |
| 15:25 |
berick |
jeff: yes |
| 15:25 |
jeff |
berick++ thanks! |
| 15:25 |
eeevil |
gmcharlt: re your 3 options, I'm strongly in favor of merging what's there and getting the release out |
| 15:25 |
gmcharlt |
likewise |
| 15:26 |
gmcharlt |
jeff: can you put some testing time into this week? |
| 15:26 |
* csharp |
can test, but has not had the time lately to keep up with development, so may need assistance ;-) |
| 15:26 |
jeff |
gmcharlt: yes. i was just about to ask what timeline you had in mind. |
| 15:26 |
kmlussier |
berick: How many testers do you need? |
| 15:26 |
kmlussier |
Sorry, that was for gmcharlt. |
| 15:26 |
gmcharlt |
jeff: let's shoot for by the end of this week, if you can |
| 15:27 |
eeevil |
berick: is it true that anyone whose tested your dev on your demo server has tested the websockets code? |
| 15:27 |
berick |
eeevil: they have, indeed |
| 15:27 |
jeff |
gmcharlt: i will shoot for that. thanks! |
| 15:27 |
gmcharlt |
ok |
| 15:28 |
csharp |
then Terran has definitely been testing |
| 15:28 |
eeevil |
csharp: :) |
| 15:28 |
dbs |
They all haven't installed it locally though :) |
| 15:28 |
kmlussier |
So for an action item, that's jeff and csharp? Do we need more testers or is that good? |
| 15:29 |
berick |
bshum: it does not interract, but code the staff client uses is touched, like the JS opensrf libs |
| 15:29 |
bshum |
Just making sure that present stuff continues to function I guess over what's coming next too. |
| 15:29 |
eeevil |
bshum: only insofar as its part of opensrf ... the current SC does not attempt to make use of it |
| 15:29 |
bshum |
Okay. |
| 15:29 |
bshum |
So that's something we ought to test as well. |
| 15:29 |
berick |
bshum: definitely |
| 15:29 |
bshum |
To make sure that it doesn't break any existing functionality |
| 15:29 |
kmlussier |
#action jeff and csharp to test websockets work by the end of this week. |
| 15:30 |
kmlussier |
#action gmcharlt to cut alpha of OpenSRF the middle of next week (week of Aug. 4th) |
| 15:30 |
kmlussier |
Anything else on OpenSRF? |
| 15:31 |
kmlussier |
#topic Evergreen maintenance releases |
| 15:31 |
kmlussier |
dbwells? |
| 15:31 |
dbwells |
#info 2.6.2 and 2.5.6 were released on 7/7 |
| 15:32 |
dbwells |
I would also like to ask about the next round, which was due last Friday. |
| 15:32 |
dbwells |
There is only one actual code change: https://bugs.launchpad.net/evergreen/+milestone/2.6.3 |
| 15:42 |
kmlussier |
eeevil: Yes, an on-time release. :) |
| 15:42 |
bshum |
gmcharlt: That's something I wanted to have some debate on actually. |
| 15:43 |
bshum |
The scheduled date for 2.7.0 beta freeze and presumably soon thereafter cutting is next Thursday, August 7 |
| 15:43 |
csharp |
so we're talking about for testing purposes? or for general usage? |
| 15:43 |
dbwells |
I can be flexible if we want to coordinate OpenSRF 2.4, 2.7-beta, 2.6.3, and 2.5.7 to all roughly coincide for dependency reasons. |
| 15:43 |
eeevil |
dbwells: looks like we there's no rest for the wicked this month ;) |
| 15:43 |
gmcharlt |
well, we can sequence things like this: opensrf 2.4 alpha => EG 2.6 beta => EG 2.5/2.6 pint releases => opensrf 2.4.0 |
| 15:48 |
bshum |
That sounds reasonable. |
| 15:48 |
bshum |
The next date for 2.7 after beta is the RC date, which is Sept 4 |
| 15:49 |
dbwells |
I'd like to plan the point releases for Aug. 7 as well, if nobody minds. |
| 15:49 |
bshum |
So that gives us time to do tests, etc. with the new OpenSRF |
| 15:50 |
kmlussier |
#agree next round of point releases will be scheduled for August 7 |
| 15:50 |
kmlussier |
Anything else before we move on? |
| 15:50 |
bshum |
Just an info |
| 15:52 |
bshum |
Well, I learned how to use the make_release script tools |
| 15:52 |
bshum |
And the first alpha tarball is up on the downloads page now. |
| 15:52 |
kmlussier |
bshum++ |
| 15:52 |
bshum |
mceraso is actually testing the alpha tarball for me right now, but if anyone else has good or bad things to say about it, please let me know. |
| 15:53 |
bshum |
#info 2.7.0 alpha1 was cut and available from downloads page on Evergreen website |
| 15:53 |
bshum |
#info 2.7.0 beta1 cutoff date is August 7, 2014 (next Thursday) |
| 15:53 |
kmlussier |
Any questions for bshum before we move on? |
| 15:54 |
bshum |
Speaking on the beta deadline, if there's any specific things that people are working on that they really want in 2.7, this is the time to get action on LP for them. |
| 15:54 |
kmlussier |
bshum: What kind of action? |
| 15:57 |
bshum |
I've been saying it in IRC and I think I mentioned it in the last email, but perhaps I should write a more dedicated, "HEY PUSH THINGS" email to developers so that we can get as much work done as possible. |
| 15:57 |
vlewis |
tsbere Thanks |
| 15:57 |
Dyrcona |
Well, that brings up something that I thought of earlier today: lp1347774. |
| 15:58 |
kmlussier |
I have some code I plan to test over the next week, but I don't have the power to push, just sign off. I don't know if that helps expedite the process. |
| 15:58 |
bshum |
Given our general reliance on a week's time to review new features before push, perhaps the cutoff for new LP pullrequest targets ought to be this Thursday, July 31 |
| 15:58 |
kmlussier |
https://bugs.launchpad.net/evergreen/+bug/1347774 |
| 15:58 |
pinesol_green |
Launchpad bug 1347774 in Evergreen "Backend logic has leaked into the TPAC (and friends)" (affected: 2, heat: 12) [Wishlist,New] |
| 00:02 |
bshum |
We might just have to give Debian its fair shake again ;) |
| 03:02 |
|
pinesol_green` joined #evergreen |
| 05:03 |
pinesol_green` |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 15:46 |
|
zerick joined #evergreen |
| 16:11 |
|
serflog joined #evergreen |
| 16:11 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 16:42 |
|
gmcharlt joined #evergreen |
| 17:08 |
csharp |
bshum: 14.04 host/12.04 guest? or the other way around? |
| 17:09 |
|
tsbere_ joined #evergreen |
| 17:37 |
bshum |
csharp: 12.04 host with 12.04 guests |
| 17:38 |
bshum |
And an occasional 14.04 guest |
| 17:38 |
bshum |
And 14.04 DB servers |
| 17:38 |
bshum |
We're in a bit of flux I guess |
| 17:38 |
bshum |
Switching back to older kernels 3.11 or less, things seem to have calmed down a bit with some of the VMs. |
| 17:45 |
bshum |
I'm rolling everything back a step on the kernels later tonight to hopefully get us back to "normal" |
| 17:46 |
bshum |
csharp: What happened was we were using I think the newer kernels with 12.04. Like linux-generic-lts-saucy (13.10's) |
| 17:47 |
bshum |
And so there's all these warning about how that's ending support in August or such and recommending that we switch up to linux-generic-lts-trusty (14.04's) |
| 17:47 |
bshum |
So we did, and we ended up with all sorts of weird VM startup issues (kernel panic, massive network slowness, etc.) |
| 17:48 |
bshum |
My understanding is that clean 12.04.5 has the trusty kernel version too, but I haven't tested that far ahead. |
| 17:48 |
bshum |
In any case it's been a messy weekend. |
| 21:29 |
jeff |
bshum: do you think the kernel on the hosts or the kernel on the guests was the issue, or both? |
| 21:37 |
eeevil |
bshum: wheezy, friend. wheezy. |
| 21:49 |
bshum |
eeevil: Yeah I'm giving it strong consideration :) |
| 09:05 |
* Dyrcona |
now has to remember how to use yaz-client to check something. |
| 09:07 |
kmlussier |
Good morning! |
| 09:07 |
kmlussier |
tspindler: Chrome Vox was never a problem with autosuggest. |
| 09:08 |
tspindler |
kmlussier: ok, is there something free we can test it with then we have it on ou a dev server |
| 09:15 |
tspindler |
@coffeee |
| 09:15 |
pinesol_green |
tspindler: Zoia knows how to make fusilli. |
| 09:15 |
kmlussier |
Heh |
| 09:16 |
kmlussier |
Shouldn't that say pinesol_green instead of zoia? |
| 11:17 |
kmlussier |
I like what jeff's library does with the whitespace http://catalog.tadl.org/eg/opac/home |
| 11:17 |
|
bmills joined #evergreen |
| 11:18 |
krvmga |
kmlussier: yes, a good example of what i meant. |
| 11:24 |
jeff |
two other approaches that we have been experimenting with can be seen here: https://dev.tadl.org/responsive-web/ and here: http://dev.kalkaskalibrary.org/books/ |
| 11:27 |
jeff |
both of those are very much experiments and/or work-in-progress, hopefully as hinted at by the "dev" hostnames, robots.txt, and content like: "* just testing some things" :-) |
| 11:28 |
krvmga |
jeff: i particularly like the responsive-web one. |
| 11:29 |
krvmga |
jeff: do you have many academic libraries in your consortium? |
| 11:31 |
jeff |
krvmga: no academic libraries in our catalog. we're also not a "consortium", per se. we are a district library, plus we're contracting with a neighboring county library to provide ILS/website/etc services (going live in Aug). |
| 14:33 |
kmlussier |
eeevil++ |
| 14:34 |
krvmga |
jeffdavis: just read death-to-the-website-carousel , interesting read |
| 14:34 |
krvmga |
jeffdavis++ |
| 14:35 |
eeevil |
kmlussier: :) ... I have a followup to that that's in testing ... I'll pull the pullrequest for the ... nonce (that'll be funnier later) |
| 14:36 |
jeffdavis |
krvmga: glad you found it worthwhile! |
| 14:37 |
jeffdavis |
it seems that TADL's carousels/sliders/whatever avoid a lot of the accessibility issues that article raises, which is cool |
| 14:37 |
jeff |
jeffdavis: my intent wasn't to defend them, just to comment on how i've used slider/carousel to mean different things over time. :-) |
| 16:50 |
phasefx |
gmcharlt: we can go ahead and use cluster on the QA server to put everything in backwards orders |
| 16:50 |
mmorgan |
In our experience on Evergreen thus far, the permission group list in the edit screen has been badly sorted, and pretty consistently so from day one. If clustering can sort it better even for a short time, it's a win for us :) |
| 16:50 |
eeevil |
back when all the selinux extensions were first being designed |
| 16:50 |
phasefx |
gmcharlt: well, s/QA/demo/ or manual test server |
| 16:51 |
phasefx |
not quite the same, but partway there for finding bad assumptions in the code |
| 16:52 |
eeevil |
Dyrcona: that's, IIRC, index organized tables, where the heap tuples live on the leaf pages of the index ... yes, similare purpose, but not possible in pg in the broadest sense |
| 16:52 |
eeevil |
Dyrcona: however, for stable dataset and a covering index, you can get an index-only scan |
| 16:52 |
Dyrcona |
yep. |
| 17:06 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:11 |
mmorgan |
good weekend all! don't have nightmares about clustering... |
| 17:11 |
|
mmorgan left #evergreen |
| 17:11 |
kmlussier |
mmorgan: Have a nice weekend! |
| 00:36 |
|
mmorgan1 joined #evergreen |
| 03:39 |
|
mtcarlson joined #evergreen |
| 04:26 |
|
remingtron joined #evergreen |
| 05:06 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:49 |
|
b_bonner joined #evergreen |
| 05:52 |
|
mtcarlson_away joined #evergreen |
| 05:53 |
|
mnsri joined #evergreen |
| 14:11 |
|
RoganH joined #evergreen |
| 14:13 |
tspindler |
bshum: does Dan need to do something more with this https://bugs.launchpad.net/evergreen/+bug/1099979 |
| 14:13 |
pinesol_green |
Launchpad bug 1099979 in Evergreen "Merge Parts" (affected: 4, heat: 18) [Wishlist,Confirmed] |
| 14:16 |
bshum |
tspindler: I don't think so. The changes worked for me enough in my initial testing that I felt comfortable picking in the commit pretty soon |
| 14:16 |
bshum |
I was just getting all the t's crossed and i's dotted |
| 14:17 |
tspindler |
thank bshum, I just wasn't sure if you were looking for more testing from us |
| 14:18 |
tspindler |
i think we need to return the favor and do some testing of others code ;) |
| 14:18 |
RoganH |
bshum: you still need testing on the merge parts? |
| 14:19 |
bshum |
tspindler: There's always welcome room for further testing :) |
| 14:19 |
bshum |
RoganH: If you feel interested to take a look, that'd be great to have an extra pair of eyes look it over. My own light testing seemed fine, but I don't mind the extra checks. |
| 14:20 |
RoganH |
bshum: I've been meaning to dig around launchpad for another commit to test to help out if another signoff is needed. I just hadn't done so yet. |
| 14:20 |
RoganH |
bshum: Move from our old servers to Sequoia was last night so it's been busy. |
| 14:20 |
bshum |
I hear that |
| 14:32 |
Dyrcona |
tspindler: Keep an eye on your launchpad bug email this afternoon. |
| 14:49 |
|
muddles17 joined #evergreen |
| 14:51 |
|
muddles17 left #evergreen |
| 14:51 |
|
muddles17 joined #evergreen |
| 15:06 |
tspindler |
Dyrcona: okee dokee |
| 15:09 |
tspindler |
I had a question about testing, does everyone test with concerto data or do you also test with production (I think I know the answer for Dyrcona) but I was wondering about others? |
| 15:09 |
tspindler |
not on production but with production data that is |
| 15:11 |
RoganH |
tspindler: varies a bit, if it's a UI thing I will test on a VM with concerto data, but something like the 856 testing a while back I did on a test box with production data because I didn't feel test data would find issues |
| 15:11 |
csharp |
tspindler: we pretty much *only* test with production data |
| 15:12 |
RoganH |
If you're talking about broader testing like testing upgrades it's always with production data. |
| 15:12 |
csharp |
the default OU setup and concerto don't feel "real" enough for our end user testers, so we haul around our huge dataset from server to server |
| 15:13 |
csharp |
testing for bugfix signoffs and the like, I use default setup/concerto on current master |
| 15:13 |
tspindler |
RoganH: I was thinking more about new development and not upgrade, we ahve been testing upgrade with production data |
| 15:24 |
dbwells |
bshum: I think I may have hit that jump bug once in a custom script. I've at least targetted it for 2.5 and 2.6 now. Thanks for asking. |
| 15:24 |
Dyrcona |
I only test with production data. |
| 15:25 |
Dyrcona |
tsbere uses concerto and production depending. |
| 15:26 |
bshum |
I tend to use a mixture of both depending on what I happen to have most readily available at the time. |
| 15:26 |
bshum |
Though nominally everything eventually gets tested with production data. |
| 15:26 |
bshum |
I guess I like testing OPAC features using concerto data actually. |
| 15:32 |
Dyrcona |
bshum: In the case of dpearl's branch referenced in the lp bug above, it was handy know I had a patron with 500 or entries in their circ history. |
| 15:33 |
bshum |
True that. |
| 15:33 |
Dyrcona |
Guess my brain is still faster than my fingers. |
| 04:42 |
|
b_bonner joined #evergreen |
| 04:42 |
|
mnsri joined #evergreen |
| 04:43 |
|
mtcarlson_away joined #evergreen |
| 04:50 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 08:16 |
|
akilsdonk joined #evergreen |
| 08:27 |
|
Dyrcona joined #evergreen |
| 08:31 |
|
mrpeters joined #evergreen |
| 08:48 |
csharp |
680K deleted records from our bib cleanup a few years back |
| 08:48 |
csharp |
so those can be deleted without trouble? I'm looking for constraints for other tables, but don't see them |
| 08:49 |
eeevil |
if you aren't concerned about losing author/title/pub/isbn/etc on reports that pull data from those, you can remove that |
| 08:49 |
csharp |
ok cool |
| 08:49 |
csharp |
in my immediate instance, it's a test server we're using just for reports at the moment, so I'm willing to experiment |
| 08:49 |
eeevil |
historical reports (say, on circs from 2 years ago) will lose data |
| 08:49 |
csharp |
oh |
| 08:49 |
eeevil |
ah, yeah, for a test server I say "BURN IT ALL DOWN" |
| 08:50 |
eeevil |
but for production ... 37G is cheap, even on SSD, these days (IMNSHO ... I hate tossing data) |
| 08:51 |
csharp |
I don't like tossing data either... just looking for options ;-) |
| 08:51 |
csharp |
thanks |
| 08:58 |
|
akilsdonk_ joined #evergreen |
| 12:36 |
Dyrcona |
eeevil: Count me in. I can with high probability even help with code. |
| 12:36 |
eeevil |
Dyrcona++ |
| 12:36 |
* eeevil |
stashes the whisk[e]y video for later... |
| 12:38 |
bshum |
berick++ # make_release patch worked for me. I'll push it and then finish testing this 2.7.0-alpha tarball and get it up to Lupin |
| 12:41 |
dbs |
eeevil: so $hours = $self->editor->retrieve_actor_org_unit_hours_of_operation($lib_id); |
| 12:41 |
dbs |
in EGCatLoader/Library.pm -- that's considered "bad"? |
| 12:41 |
* eeevil |
consults idl... |
| 13:21 |
Dyrcona |
It |
| 13:21 |
Dyrcona |
oops |
| 13:26 |
|
akilsdonk joined #evergreen |
| 13:28 |
bshum |
Remind me, did we put the test builds to the left or right of the current stables on the downloads page usually? |
| 13:28 |
bshum |
I want to say to the right so that latest stable is always at the left |
| 13:28 |
bshum |
But I can't quite recall |
| 13:36 |
eeevil |
bshum: right, I'm pretty certain |
| 13:38 |
bshum |
eeevil: Thanks, just checking. I'm going to edit up the page in a moment to put up the 2.7 files. |
| 13:38 |
bshum |
I suppose at the same time, we can remove 2.4 since that series is ended. |
| 15:59 |
gmcharlt |
just think of earworm distribution as a specialization of readers' advisory |
| 16:05 |
|
Shae_ joined #evergreen |
| 16:28 |
|
tspindler left #evergreen |
| 17:23 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:23 |
|
kmlussier left #evergreen |
| 17:24 |
|
mmorgan left #evergreen |
| 17:55 |
|
akilsdonk joined #evergreen |
| 16:59 |
ahelten |
And 3 or 4 other errors like that (missing functions) |
| 16:59 |
phasefx |
looks like once before csharp had not quite the same error, but in the same vicinity: http://evergreen-ils.org/irc_logs/evergreen/2013-05/%23evergreen.22-Wed-2013.log |
| 16:59 |
phasefx |
http://evergreen-ils.org/irc_logs/evergreen/2013-05/%23evergreen.24-Fri-2013.log |
| 17:07 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:12 |
pastebot |
"ahelten" at 64.57.241.14 pasted "Errors during import into PG 9.1 database of 1.6.0.4 export" (38 lines) at http://paste.evergreen-ils.org/72 |
| 17:14 |
ahelten |
phasefx: I think csharp's problem was different and unfortunately those irc logs don't even show how he solved the problem. The more I look at this, the more I think it goes back to the upgrade to Pg 9.1 |
| 17:14 |
ahelten |
Here is the error from the Pg 9.1 import (at least I'm pretty sure that it's from the import): http://paste.evergreen-ils.org/72 |
| 17:41 |
bshum |
I'd wonder if those initial import issues were due to the method used to export / import into the new database. |
| 17:42 |
dbwells |
ahelten: It's late in the day, so this might be suspect advice, but I'd try to just comment out line 96 from that upgrade file and see what happens. It was supposed to be a safety measure, but it might be making assumptions about your DB history / setup which just aren't true. |
| 17:42 |
ahelten |
dbwells: I'll give it a try |
| 17:43 |
bshum |
ahelten: You're running your upgrades on a test server I hope. |
| 17:43 |
bshum |
Using a copy of your real database |
| 17:43 |
ahelten |
Yes |
| 17:44 |
dbwells |
There is something unexpected about your transition from the tsearch2 extension to the inbuilt stuff, but I can't exactly put my finger on where your DB is at. |
| 17:47 |
ahelten |
Error moved to line 98: psql:2.3-2.4.0-upgrade-db.sql:98: ERROR: extension "tsearch2" does not exist |
| 18:27 |
dbwells |
I'm heading out in any case. Hope things go smoother from here for you. |
| 18:27 |
ahelten |
dbwells: most of the "take a while" threats are not true on our little database but it is working away now, looks like the -d worked |
| 18:27 |
bshum |
dbwells++ |
| 18:28 |
ahelten |
dbwells: thanks for the help, you got me past a couple problems anyway |
| 18:57 |
|
jmccarty joined #evergreen |
| 19:51 |
ahelten |
bshum, I have more testing to do but so far it looks like my upgrade to 2.6.2 was successful. Thanks again for the help |
| 19:52 |
bshum |
ahelton: Good luck! Hope things continue to work out |
| 20:10 |
|
wjr_ joined #evergreen |
| 21:51 |
|
mtcarlson joined #evergreen |
| 05:09 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:57 |
|
jboyer-isl joined #evergreen |
| 08:02 |
|
jennyl joined #evergreen |
| 08:05 |
|
jboyer-isl joined #evergreen |
| 14:58 |
* kmlussier |
needs more coffee. |
| 14:59 |
kmlussier |
Dyronca: You're trying to think of a title that the three networks don't have in common? |
| 14:59 |
Dyrcona |
Well, an author title, whatever, where 1 might have a lot of stuff and the others not so much. |
| 15:00 |
Dyrcona |
I'm trying to test dpearl's z39.50 branch. |
| 15:00 |
Dyrcona |
I either get hundreds of things or nothing. |
| 15:00 |
kmlussier |
I would shoot for a title that an academic might own. |
| 15:01 |
Dyrcona |
good idea! |
| 15:04 |
Dyrcona |
I may try a title instead of the author. |
| 15:05 |
Dyrcona |
Well, z39.50 really mangles the UTF-8. |
| 15:06 |
Dyrcona |
I think I've seen that before, because its going through evergreen and yaz, its getting double decoded or rencoded or something like that. |
| 15:06 |
tspindler |
Thanks for looking at this Dyrcona, Janet tested it before on our end |
| 15:06 |
Dyrcona |
tspindler: I'm just trying to find something that resembles the original problem. |
| 15:07 |
Dyrcona |
The changes look good to me, and I get well distributed results with them. |
| 15:08 |
Dyrcona |
One thing that has changed for me with the code is before I loaded the branch when I had 400 or so hits for 'harry potter' as title, I got 12 results in the window, with 4 from each consortium. |
| 16:30 |
Dyrcona |
Does anyone ever get Z39.50 results from biblios.net? |
| 16:30 |
Dyrcona |
I don't. |
| 16:32 |
kmlussier |
It looks like Monday, July 28, 3 p.m. EDT is the winner. I'll add it to the dev calendar. |
| 16:52 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:54 |
|
ktomita joined #evergreen |
| 20:01 |
|
RBecker joined #evergreen |
| 04:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:04 |
|
riot joined #evergreen |
| 05:22 |
|
wjr_ joined #evergreen |
| 07:35 |
|
rjackson-isl joined #evergreen |
| 10:51 |
Dyrcona |
csharp: offline circulation and manualupdate.html |
| 10:52 |
csharp |
argh |
| 10:52 |
Dyrcona |
cgi-bin/offline alias also gives a nice warning when you start Apache on trusty. |
| 10:52 |
Dyrcona |
I haven't tested if it still works, yet. I probably should. |
| 10:53 |
dbs |
krvmga: probably need to provide an example like http://pastebin.com/cxHyWbHC along with some example template overrides for the likes of config.tt2 |
| 10:53 |
Dyrcona |
I'm not sure it is a general Apache 2.4 problem. It may only be a problem with trusty. I saw it after upgrading, and I think bshum saw it with a fresh install. |
| 10:53 |
bshum |
Dyrcona: Ugh, I just saw that error now in the restart I issued |
| 10:56 |
bshum |
Dyrcona: I guess we should file and fix that too |
| 10:57 |
Dyrcona |
It could be something in my configs that is unusual. |
| 10:57 |
Dyrcona |
The upgrade was a mess. |
| 10:57 |
Dyrcona |
I also configured a Dancer app for NCIP testing, but I get that with or without that configuration in place. |
| 10:57 |
bshum |
Well, my clean install gets the same "warning" but yeah. |
| 10:58 |
Dyrcona |
Oh, if you get it clean, then we should do something about it. |
| 10:58 |
bshum |
Course it didn't start giving me that warning till I turned on CGI :) |
| 11:03 |
bshum |
Seems easier to just add cgi to the makefile for trusty to me if that gets us there ;) |
| 11:04 |
csharp |
short term, I agree with bshum, long term, I agree with Dyrcona to move off of CGI if those are the only two things using it |
| 11:06 |
Dyrcona |
I want to make sure offline circ works with 2.4 on trusty before we do much of anything. |
| 11:06 |
* Dyrcona |
jots that down to test later today or tomorrow morning. |
| 11:10 |
bshum |
Yeesh |
| 11:10 |
bshum |
Using the offline gets me skull/crossbone errors |
| 11:10 |
bshum |
Unable to retrieve sessions, unable to create sessions |
| 11:13 |
bshum |
Meh |
| 11:13 |
bshum |
No, it's just an undefined error |
| 11:13 |
bshum |
But yeah, not promising |
| 11:15 |
Dyrcona |
Well, I have 4 books that came in delivery this morning that I can use for a test. |
| 11:18 |
bshum |
014-07-14 11:17:39 trusty gateway: [cgi:error] [pid 4845] [client 10.129.129.3:40991] script not found or unable to stat: /usr/lib/cgi-bin/offline |
| 11:18 |
|
kbeswick joined #evergreen |
| 11:18 |
bshum |
Oops, slightly less/more than I was going to paste. |
| 11:22 |
Dyrcona |
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ |
| 11:23 |
Dyrcona |
jeff: tried "WITH" queries and UNION? |
| 11:24 |
bshum |
Dyrcona: Yep, I see that now. |
| 11:24 |
Dyrcona |
I would try disabling it and testing, but I started a database reload, so I'll have to wait an hour or two. |
| 11:25 |
bshum |
Dyrcona: Disabling meaning commenting out that script alias portion? |
| 11:25 |
bshum |
It looks like it gets turned on when we turn on CGI? |
| 11:25 |
* bshum |
is going to do some reading |
| 11:33 |
bshum |
Yeah, it was. This is new to me. |
| 11:33 |
Dyrcona |
Yep. |
| 11:35 |
Dyrcona |
bshum: You want to add a commit to run a2disconf to my namevirtualhost branch, or do you want it separate? |
| 11:35 |
csharp |
<pedantry>Ubuntu LTS releases are synced with Debian testing, not sid</pedantry> so... |
| 11:35 |
csharp |
@blame jessie |
| 11:35 |
pinesol_green |
csharp: jessie stole csharp's ice cream! |
| 11:35 |
bshum |
Dyrcona: Might as well just make that the "fix Ubuntu 14.04 apache nonsense" branch :) |
| 11:35 |
* Dyrcona |
stands corrected by csharp. |
| 11:38 |
bshum |
for m in $(DEB_APACHE_DISCONF); do a2disconf $$m; done; |
| 11:38 |
mrpeters |
have they tagged 2.6.2 yet? or still just the release uploaded to the site |
| 11:39 |
mrpeters |
s/they/we/ |
| 11:39 |
bshum |
And then setup new params for that |
| 11:39 |
bshum |
mrpeters: I know dbwells uploaded previews and mceraso tested them last week. But I don't know if/when they'll be moved to official. Probably just a minor thing to push all that through. |
| 11:39 |
bshum |
He's probably waiting for the right moment to strike |
| 11:40 |
Dyrcona |
bshum: Why don't you add that to my lp 1341013 branch and put it in collab? |
| 11:40 |
pinesol_green |
Launchpad bug 1341013 in Evergreen "NameVirtualHost deprecated in Apache 2.4" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1341013 |
| 11:40 |
mrpeters |
yeah, we use the tag from Git to build our debs |
| 11:41 |
* Dyrcona |
figures out a configuration to auto-build a trusty VM. |
| 11:47 |
bshum |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/bshum/lp1341013_apache24_tweak |
| 11:47 |
bshum |
Dyrcona: Signed off on your commit and added the changes I think we'll need for mod CGI |
| 11:48 |
Dyrcona |
bshum: Cool. I will add your branch to my dev branch and build a test vm first thing after lunch. |
| 12:05 |
|
gsams joined #evergreen |
| 12:11 |
|
b_bonner_ joined #evergreen |
| 12:15 |
|
hbrennan joined #evergreen |
| 12:46 |
csharp |
yeah - that includes us :-/ |
| 12:47 |
csharp |
same with open-ils.auth_proxy - should be a module |
| 12:47 |
dbs |
isn't it a module? |
| 12:48 |
Dyrcona |
I find the reason for the stripe failure to be humorous: The tests are broken by later versions of Perl. The module itself, still works. |
| 12:48 |
csharp |
dbs: I was told a while back that it was effectively non-disable-able |
| 12:48 |
csharp |
so we live with the constant log errors that look just like errors we would actually care about ;-) |
| 12:49 |
dbs |
csharp: oh, maybe from the TPAC side of things? |
| 16:36 |
bshum |
I wonder if that's SQL schenanigans more than bug in the staff client. |
| 16:36 |
bshum |
But I don't know what's being referred to specifically. |
| 16:38 |
|
kbeswick joined #evergreen |
| 16:42 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:43 |
bshum |
Huh |
| 16:43 |
phasefx |
psql:950.data.seed-values.sql:5019: ERROR: VALUES lists must all be the same length |
| 16:43 |
phasefx |
LINE 2124: ,('circ.use_lost_paid_copy_status', |
| 16:45 |
jeff |
tests++ |
| 16:52 |
Dyrcona |
Actually, I can fix that right quick. |
| 16:52 |
Dyrcona |
It's missing a ", null" at the end of the arguments. |
| 16:55 |
Dyrcona |
Any one have a problem with me pushing it? |
| 03:13 |
|
dreuther joined #evergreen |
| 04:57 |
|
mtate joined #evergreen |
| 05:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:44 |
|
b_bonner joined #evergreen |
| 06:44 |
|
mnsri joined #evergreen |
| 06:45 |
|
mtcarlson_away joined #evergreen |
| 07:48 |
|
jboyer-home joined #evergreen |
| 08:09 |
|
rjackson-isl joined #evergreen |
| 08:12 |
|
akilsdonk joined #evergreen |
| 08:13 |
jboyer-isl |
dbs++ ; Vacuum Analyze took care of the search timeouts on our migration testing server. Apparently when testing it’s no longer optional for us. Thanks! |
| 08:23 |
rjackson-isl |
dbs++ and jboyer-isl++ - now the next set of libraries migrating to EI can review initial data pull! :-) |
| 08:28 |
|
mrpeters joined #evergreen |
| 08:36 |
|
tspindler joined #evergreen |
| 15:21 |
* bshum |
is trying out the make_release dance for the first time |
| 15:21 |
bshum |
Entertaining! |
| 15:29 |
jeffdavis |
gmcharlt++ |
| 15:36 |
bshum |
Oh, yay, i18n dance at last |
| 15:36 |
bshum |
Figuring out all the dependencies was "fun" :) |
| 15:40 |
bshum |
So yeah, once the environment is setup right, this does seem easier than I recalled from our 2.0 days. |
| 15:46 |
|
mrpeters left #evergreen |
| 15:50 |
|
RoganH joined #evergreen |
| 15:56 |
bshum |
RoganH: Thanks for signing off on https://bugs.launchpad.net/evergreen/+bug/1198475 ; I'm planning to get a little more testing on that myself and then push it up to master next week |
| 15:56 |
pinesol_green |
Launchpad bug 1198475 in Evergreen "Support for Lost and Paid Status" (affected: 3, heat: 16) [Wishlist,Confirmed] |
| 15:56 |
RoganH |
bshum: I've been a bad tester but at least I got one in. I'm hoping to get another couple in tomorrow if it's quiet at work. |
| 15:56 |
bshum |
Unless someone else gets there first. |
| 16:16 |
tsbere |
jeff: I know of at least one SIP2 server app that prefers things in alphabetic order. <_< |
| 16:16 |
eeevil |
tsbere: which, as I'm sure you know, is /not/ the same as spec order for some messages :) |
| 16:16 |
jeff |
tsbere: which server? |
| 16:17 |
tsbere |
eeevil: For added fun, it blows up on any field it doesn't understand. |
| 16:17 |
tsbere |
jeff: Luckily it was just a test server for a PC reservation system, though the docs implied it was ripped out of an ILS and given a different database backend... |
| 16:17 |
eeevil |
tsbere: you have a strange sense of "fun", sir... ;) |
| 16:17 |
jeff |
@decide Standard Interchange Protocol or Binary Language of Moisture Vaporators |
| 16:17 |
pinesol_green |
jeff: have you tried local mean solar time for the named city as the reference point? |
| 16:33 |
jeff |
tsbere: does that take care of re-establishing a tunnel, or starting it automatically? The fact that putty-tunnel-manager claims to use plink makes me wonder if plink has those abilities on its own. |
| 16:33 |
bshum |
That's why I didn't catch it till now |
| 16:34 |
tsbere |
jeff: I wrapped it in a cmd file with a goto and helped libraries drop that into task scheduler. |
| 16:35 |
bshum |
Reverting that commit on my test server allows me to complete the make_release dance and get clients built. |
| 16:35 |
jeff |
tsbere: got it. thanks. |
| 16:37 |
jeff |
ah, and there's also http://www.bitvise.com/tunnelier |
| 16:39 |
jeff |
as well as MyEnTunnel and some other options referenced here: http://superuser.com/q/235395/9465 |
| 11:25 |
bshum |
If they're electronic records, then I'm even more concerned about how interconnected they might be. |
| 11:25 |
bshum |
Depending on what kind |
| 11:27 |
Dyrcona |
Then, you'll want to vaccuum full analyze the tables and put the rules and triggers back in place. |
| 11:28 |
bshum |
Well, in any case, just be careful how you identify which bibs to delete. And do it all on a test server a couple of times first. People have been known in the past to have removed their protections and then deleted the wrong bibs to dangerous consequences... |
| 11:28 |
Dyrcona |
Yep, that, too. |
| 11:29 |
bshum |
There's a decent number of instances in our IRC logs for those unhappy stories. |
| 11:31 |
Dyrcona |
IOW, unless you're going to get a major benefit from it, such as cutting your database by a significant %, I wouldn't bother. |
| 11:36 |
Dyrcona |
Deleted records also have the record status field set to 'd' if not already. |
| 11:36 |
Dyrcona |
However, if you're eliminating that many records. It might be worth it to try. It just won't be easy. |
| 11:37 |
asimon |
Dyrcona: TY |
| 11:39 |
Dyrcona |
asimon: Do you have a test/training database you can test it on? |
| 11:39 |
asimon |
Dyrcona: I'll use COPY (SELECT marc FROM biblio.record_entry WHERE deleted = 't') to a file and then convert the XML to MARC with yaz-marcdump. |
| 11:40 |
Dyrcona |
asimon: That sounds like it should work, thought it should already be xml. |
| 11:41 |
asimon |
Dyrcona: Yes, but I want MARC, not XMLMARC. |
| 12:07 |
jboyer-isl |
Self-signed, and I'm tunneling directly into the same LAN with an otherwise completely open machine. |
| 12:07 |
jeff |
tunneling how? you mentioned "direct connection" earlier. |
| 12:08 |
jboyer-isl |
Direct connection just means no load balancer, poor choice of words. The IP the name resolves to is the one running Apache and OpenSRF. |
| 12:10 |
mceraso |
dbwells: Just finished testing the maintanence release for 2.6.2 using Ubuntu LTS 12.04. It works well :) |
| 12:10 |
jboyer-isl |
Tunneled over SSH, though I'm testing a "normal" connection now also. |
| 12:11 |
jboyer-isl |
(It has a public IP) |
| 12:11 |
Dyrcona |
Added content? Could that be using https and the vendor doesn't support it? |
| 12:13 |
jboyer-isl |
I guess it's possible, I'll check. |
| 12:14 |
Dyrcona |
I've never seen searches be slow just over https, so I'm grasping. |
| 12:21 |
jboyer-isl |
Disabled added content to no effect, now we try the ages-old method of restart it and see. |
| 12:28 |
dbs |
jboyer-isl: tunneled over ssh with compression of the ssh tunnel enabled? |
| 12:28 |
dbs |
compression + encryption still shouldn't be that slow though. |
| 12:29 |
jboyer-isl |
dbs: Not that I'm aware of. I'm testing over a regular connection now just to avoid the possibility that it's tunnel related. |
| 12:29 |
jeff |
At the risk of sounding like SAPS, this could be an MTU issue. |
| 12:30 |
jeff |
It would be interesting to see if an HTTPS request for a small file (such as robots.txt) and an HTTPS request for a larger (ten meg or so) are any different from each other, and are any different from the searches. |
| 12:32 |
jboyer-isl |
Oh. It appears to be at least partially related to the hour+ long bib searches that were hung up on 4 of the postgres backends that serve that installation. I cleared that out and now it's returning results in the staff client again. |
| 14:35 |
dbs |
Did anyone drop or recreate indexes recently? |
| 14:35 |
dbs |
All sorts of potential problems. |
| 14:35 |
Dyrcona |
csharp++ bshum++ |
| 14:36 |
jboyer-isl |
The data is identical to production, we did a dump/restore, and ran a test migration. It's every search. |
| 14:37 |
jboyer-isl |
Osrf/Eg versions are also the same. |
| 14:38 |
Dyrcona |
Any problems with the restore? |
| 14:42 |
jboyer-isl |
The usual (rebuild those 2 authority indexes and the auditor schema since I didn't dump it) |
| 14:44 |
bshum |
remingtron++ # taking a look at bug 1210161 and it looks good. Testing the upgrade script and then I'll probably push that on in. |
| 14:44 |
pinesol_green |
Launchpad bug 1210161 in Evergreen "TPAC "my list" still referred to as "bookbag" in some places" (affected: 3, heat: 16) [Medium,Confirmed] https://launchpad.net/bugs/1210161 |
| 14:46 |
dbs |
jboyer-isl: oh, test migration == upgrade to newer version? |
| 14:46 |
jboyer-isl |
Dyrcona: Ah, and apparently all of config.z3950_index_field_map is missing. Is that table more important than it's z3950 prefix would suggest? |
| 14:47 |
jboyer-isl |
dbs: Nope, just adding a new lib. I've got another server for upgrade testing, it went great so far as I can tell though I don't have a client built for it yet. |
| 14:47 |
Dyrcona |
No, it isn't but I've had that happen seemingly randomly before. |
| 14:48 |
dbs |
ANALYZE run after the restore? |
| 14:48 |
bshum |
Calling 0884 |
| 16:57 |
jeffdavis |
it's aliiiiiiiive |
| 16:57 |
jeffdavis |
Someday I should get around to making that list of all the things I need to get around to doing. |
| 16:57 |
jeffdavis |
Finishing old half-finished bugfixes and new features, for example. |
| 17:01 |
bshum |
Hehe |
| 17:01 |
bshum |
eeevil++ # debian defender ;) |
| 17:01 |
bshum |
That's a fair clarification, I didn't quite word my part of that correctly. |
| 17:01 |
bshum |
I should have said we only officially test Ubuntu with that particular version. |
| 17:01 |
bshum |
But others are done as well. |
| 17:03 |
eeevil |
bshum: :) |
| 17:08 |
* dbs |
wades in with a hearty encouragement to use Fedora |
| 17:08 |
eeevil |
hrm... we need to get a debian 7 buildbot host going, and upgrade the live tester ... |
| 17:09 |
eeevil |
dbs: at least that still has a buildbot slave :( |
| 17:09 |
bshum |
dbs++ |
| 17:13 |
|
mmorgan left #evergreen |
| 17:20 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:29 |
bshum |
dbs: Ooh, just found http://stuff.coffeecode.net/2014/lld_preconference/search_engine_cse/ ... I will play through this one :) |
| 17:33 |
|
akilsdonk_ joined #evergreen |
| 17:40 |
sseng |
Question: anyone encountered this error when running osrf_control -l --stop-all? error is: Can't kill a non-numeric process ID at /openils/bin/osrf_control line 149. |
| 17:48 |
jeffdavis |
i.e. does one or more of those files contain an error msg or something, rather than a process id? |
| 17:49 |
Bmagic |
sseng: I have seen that error but it doesn't seem to matter for us |
| 17:50 |
sseng |
jeffdavis: Bmagic : unfortunately i ran the osrf_control with the --kill-with-fire option.... so no longer have access to those .pids with the errors....the good news running the usual --stop_all no longer produce that error! |
| 17:56 |
jeffdavis |
Seems likely that file perms/ownership were wrong on a pid file or the directory. osrf_control just does @pids = `cat $pid_file`; if cat gives an error like "permission denied" then @pids will contain the test of the error message. |
| 17:56 |
jeffdavis |
Anyway, glad it's working now. |
| 17:56 |
jeffdavis |
s/test/text/ |
| 17:57 |
sseng |
jeffdavis: yep, thanks a bunch, will look out for those in future! |
| 18:36 |
|
sseng joined #evergreen |
| 18:36 |
|
ktomita joined #evergreen |
