| 09:42 |
|
yboston joined #evergreen |
| 09:42 |
|
kmlussier joined #evergreen |
| 09:42 |
RoganH |
Patience is more of a necessity than a virtue with Overdrive. |
| 09:42 |
jeff |
They claim to review applications on a "weekly basis", but we applied Oct 1 and it is now Oct 15. |
| 09:43 |
jeff |
At this rate, I could have driven down to Cleveland, spent some time with friends, and knocked on OverDrive's door for a personal interview to obtain access to the Circulation APIs and/or test environment. ;-) |
| 09:43 |
RoganH |
Time is highly subjective. |
| 09:44 |
RoganH |
They may only be counting the third hour of every meal break towards the week. |
| 09:48 |
|
misilot joined #evergreen |
| 12:08 |
pinesol_green |
Launchpad bug 1239837 in Evergreen 2.4 "Undefined variable prevents quick PO creation" (affected: 1, heat: 6) [High,New] https://launchpad.net/bugs/1239837 |
| 12:10 |
berick |
dbwells: looking now, sorry |
| 12:10 |
dbwells |
np |
| 12:13 |
berick |
dbwells++ looks correct, testing and signing off now |
| 12:14 |
dbwells |
berick++ # thank you, sir |
| 12:34 |
gmcharlt |
berick++ |
| 12:34 |
berick |
does this look odd to anyone else? http://dev198.esilibrary.com/eg/opac/results?query=violin&qtype=keyword |
| 13:21 |
gmcharlt |
#info gmcharlt to release 2.2.1 this week |
| 13:22 |
kmlussier |
gmcharlt++ |
| 13:22 |
gmcharlt |
(and KohaCon as a vacation for Koha's release manager? you jest, surely! ;) ) |
| 13:22 |
kmlussier |
#info csharp to test 2.4.2 rc so we can officialize it |
| 13:22 |
eeevil |
gmcharlt: this includes the new opensrf controller script from berick, yes? |
| 13:22 |
bshum |
Related to opensrf, is there anything in master that lends cutting of a 2.3.0? |
| 13:22 |
eeevil |
kmlussier: that happened, 2.4.3 is waiting in the wings |
| 13:27 |
csharp |
senator++ |
| 13:27 |
gmcharlt |
as recommended, with note that 2.2.1 is compatible |
| 13:27 |
eeevil |
(yes, 2.3+ recommended) |
| 13:28 |
kmlussier |
#info 2.3.0 will be recommended to run with EG 2.5, but 2.2.1 will be compatible as well. |
| 13:28 |
kmlussier |
Moving on to the next action item... |
| 13:28 |
kmlussier |
#info senator to find old incomplete action items to move forward (with help from the channel in making sure I get the right ones) - Done! |
| 13:29 |
kmlussier |
senator++ # Thanks for all the action items! |
| 13:29 |
kmlussier |
#info eeevil to commit a techref doc explaining how to build pgTAP test |
| 13:31 |
eeevil |
kmlussier: I have not done that yet. it's on my gtasks list, though! |
| 13:31 |
eeevil |
nor have I had time to do the next one |
| 13:31 |
kmlussier |
OK, I'll add both as action items for next time then. |
| 13:31 |
kmlussier |
#action eeevil to commit a techref doc explaining how to build pgTAP test |
| 13:32 |
eeevil |
thanks |
| 13:32 |
kmlussier |
#action o publish detailed plan about freezing baseline schemas between EG releases and using deprecates/supersedes in database upgrade scripts. This will go on the mailing list and the thread should structure further discussion of pros and cons of eeevil's plan. |
| 13:32 |
kmlussier |
That's it for action items, and I think we've also covered OpenSRF Release Info? |
| 13:33 |
kmlussier |
#topic Evergreen release info |
| 13:33 |
|
Callender_ joined #evergreen |
| 13:33 |
kmlussier |
dbwells: Should we start with 2.5? |
| 13:34 |
dbwells |
Sure. After a couple brief rounds of testing and bug squashing, RC1 is uploaded to the usual. |
| 13:34 |
dbwells |
usual place, that is |
| 13:35 |
dbwells |
Been having fun working out the release notes, but that is done as well, and will be uploaded shortly. |
| 13:35 |
|
Callender__ joined #evergreen |
| 13:36 |
kmlussier |
#info 2.5 RC1 is uploaded. Release notes will be uploaded shortly. |
| 13:36 |
kmlussier |
dbwells: Anything else to add? |
| 13:36 |
dbwells |
Since we are a day late already for the delayed version of 2.5 final, I am not sure where to pin down the timeline, but I am pretty confident things we'll get there soon. |
| 13:37 |
dbwells |
It's really all about more testing at this point, so maybe RC will inspire some folks. |
| 13:37 |
|
Callender joined #evergreen |
| 13:37 |
dbwells |
That's about it, unless folks have questions I might be able answer. |
| 13:37 |
kmlussier |
How much time do we usually allow for testing between RC1 and final? |
| 13:38 |
* csharp |
is testing beta1, but will upgrade to RC |
| 13:38 |
gmcharlt |
dbwells: apologies if it's already been mentioned, but I'd like to take this opportunity to mention the fixes for bug 1086458 |
| 13:38 |
pinesol_green |
Launchpad bug 1086458 in Evergreen 2.4 "Staff client memory leaks in 2.3 and later" (affected: 11, heat: 76) [High,Confirmed] https://launchpad.net/bugs/1086458 |
| 13:39 |
gmcharlt |
whether or not it's a candidate for inclusion in 2.5.0, I'm pretty sure lots of folks will be very happy if it makes it in by 2.5.1 |
| 13:39 |
dbwells |
gmcharlt: I haven't looked at it, but I certainly will. |
| 13:40 |
kmlussier |
I think a lot of people would love to see those patches in sooner rather than later. I'm not sure how to approach testing, though. |
| 13:41 |
csharp |
kmlussier: our approach will probably be a due diligence approach on a test server to make sure nothing breaks, then move to production as soon as we're satisfied |
| 13:41 |
dbwells |
gmcharlt: It doesn't look too bad, and if there are no objections, I can pull back RC1 and cram it in there. No formal announcements have been made yet. |
| 13:41 |
csharp |
seems like it's too difficult to simulate in a test environment |
| 13:41 |
kmlussier |
csharp++ |
| 13:42 |
csharp |
dbwells: +1 # fwiw |
| 13:42 |
eeevil |
dbwells: I know it's a pain, having just gone through packaging, but I'm +1 to that |
| 13:43 |
gmcharlt |
dbwells: thanks -- but also, TIA to anybody who tests it |
| 13:43 |
kmlussier |
Is everyone in agreement to include the memory leak patches in RC1 then? |
| 13:43 |
* gmcharlt |
will search for a suitable libation whose name encodes the concept of "at the last minute" for delivery next time I see you ;) |
| 13:44 |
dbwells |
I would also appreciate a test/sign-off/push to master on that branch by anyone else who can take a look. |
| 13:44 |
gmcharlt |
+1 |
| 13:45 |
* dbwells |
will test what he can of it, but RC1 will be out today, or BUST |
| 13:45 |
csharp |
dbwells++ |
| 13:46 |
kmlussier |
#agree dbwells will pull back RC1 and incorporate memory leak patches. Sign-off from other testers will be appreciated. |
| 13:46 |
kmlussier |
Any other questions for dbwells? |
| 14:41 |
rfrasur |
but maybe not |
| 14:41 |
* rfrasur |
hasn't done much using the bib source |
| 14:41 |
RoganH |
I'll be honest, I can use the reports interface but I have to think about it. I mostly use sql. |
| 14:41 |
gmcharlt |
rfrasur: then there's the scenario where online circulation works perfectly when the main catalog is offline -- due to somebody not noticing that they were connecting to the test system |
| 14:42 |
rfrasur |
gmcharlt: please never tell my staff there's more than one server. |
| 14:42 |
* rfrasur |
has visions of mushroom clouds |
| 14:43 |
RoganH |
rfrasur: so .... no staff development day discussion of load balancing and bricks? |
| 14:43 |
gmcharlt |
rfrasur: let's just say that we now will consider turning off a test system temporarily at appropriate times to avoid asploding heads |
| 14:43 |
RoganH |
rfrasur: we could explain round robin database setups to them :) |
| 14:43 |
rfrasur |
no....not this staff. They're great, but technology is perhaps not their greatest area of interest and expertise. |
| 14:44 |
rfrasur |
gmcharlt++ |
| 15:38 |
senator |
i remember fixing this once in a totally different, not-serials interface |
| 15:39 |
senator |
i had though the way i did that should apply to cases like this too, but will check it out |
| 15:39 |
senator |
oh, well you have a solution already too |
| 15:40 |
jeff |
Hrm. fieldmapper.standardRequest seems to be able to get into a state where none of oncomplete, onerror, ontransporterror, nor onmethoderror will fire. |
| 15:41 |
jeff |
Testing in both xulrunner and Firefox |
| 15:42 |
jeff |
My test is to force a user edit save to fail by creating a usrname collision. |
| 15:42 |
jeff |
(which isn't handled in register.js, and I was trying to add handling) |
| 15:44 |
senator |
jeff: so the error is a DATABASE_QUERY_FAILED event? |
| 15:44 |
|
dMiller joined #evergreen |
| 15:45 |
senator |
i would expect oncomplete to fire for that |
| 16:11 |
rfrasur |
yep...and that was a good one. |
| 16:17 |
jeff |
senator: it appears that onmethoderror will fire, but only in the staff client. also, "onerror" is not (always?) a less-specific handler for method errors. |
| 16:19 |
senator |
hrm. at least onmethoderror should work then for your cases of catching an event in the patron editor... odd |
| 16:19 |
jeff |
it does. my testing was incomplete. |
| 16:19 |
jeff |
i was updating my earlier assertion. |
| 16:20 |
jeff |
it works, but not in Firefox -- just in the staff client. i suspect I'm running into broken multipart as an issue, which is known and fixed. |
| 16:20 |
jeff |
so, probably-mostly mystery solved. |
| 16:21 |
dbwells |
berick: If you get a chance, I just posted an acq bug, bug #1239837. It is pretty simple, I think, but was causing us some grief today. |
| 16:21 |
pinesol_green |
Launchpad bug 1239837 in Evergreen 2.4 "Undefined variable prevents quick PO creation" (affected: 1, heat: 6) [High,New] https://launchpad.net/bugs/1239837 |
| 16:21 |
* dbwells |
heads out for a bit, will be back |
| 16:33 |
|
mrpeters left #evergreen |
| 16:34 |
jeff |
yeah, confirmed. it was multipart breaking. |
| 16:51 |
jeff |
and with multipart disabled in firefox, both onmethoderror and onerror fire. they also fire in the staff client as expected. |
| 16:52 |
jeff |
my test appears to have been sabatoged at least partly by muscle memory. when you are IN tab 3 in the client and you hold down alt and hit -, -, 3 -- there's very little clue that what actually happened was you did not clear cache, but you switched to tab 3. :-) |
| 16:58 |
|
akilsdonk joined #evergreen |
| 17:36 |
|
hopkinsju joined #evergreen |
| 17:37 |
hopkinsju |
Good afternoon gents. Can someone help me learn how to use the newish Org Unit Hiding feature in the OPAC? |
| 14:54 |
|
remingtron joined #evergreen |
| 14:54 |
eeevil |
dbwells: yes, a joiner of <empty-string> instead of NULL should do exactly what dbs wants in title|proper |
| 14:54 |
dbwells |
eeevil: IIRC, using the joiner of '' would fail when the call-template "part" made nodes (that is, they would stick together too). I thought about stringifying that too, but called it a day instead. |
| 14:54 |
* eeevil |
looks |
| 14:55 |
eeevil |
arg ... yeah... you're right |
| 14:55 |
eeevil |
ok, separate for now ... more thinking on this for .NEXT |
| 14:56 |
eeevil |
dbwells: ok. I've exhausted all complaints with the branch. there's too much to do to make it perfect, and it's good enough. :) |
| 14:56 |
eeevil |
dbwells++ |
| 14:56 |
eeevil |
and |
| 14:56 |
eeevil |
bshum++ |
| 14:56 |
eeevil |
senator++ |
| 14:56 |
eeevil |
for testing |
| 14:57 |
dbwells |
eeevil: we arrived at exactly the same place :) |
| 14:59 |
dbwells |
eeevil: I do want to continue down the better road for .NEXT, and really, the sooner, the better. 3-4 months out I am not likely to remember any of this. |
| 14:59 |
berick |
phasefx: finally, is this expected when running the tests? "Subroutine section_pkg redefined at (eval 1493) line 4."? -- seems to repeat w/ each test. |
| 14:59 |
berick |
they pass OK |
| 15:01 |
dbwells |
eeevil: I am also very keen to start documenting all the reasons for what we are doing, and I tried to do some of that on the bug / in the commits. It's definitely the sort of case where you try to push down one thing and something pops out on the other side, so to speak. |
| 15:01 |
phasefx |
berick: it happens with however make livecheck does it, but does not happen if you run the tests directly out of the live_t/ directory with perl or prove. I didn't try very hard to figure out why |
| 15:01 |
|
rfrasur joined #evergreen |
| 15:02 |
* phasefx |
blindly based livecheck off of what check was doing, but it may not make sense to do it that way |
| 15:02 |
berick |
phasefx: copy that. i'll leave it for another day -- maybe the same day we fix uninitialized value $dup_args{"real_api_name"} |
| 15:02 |
berick |
(from make check) |
| 15:03 |
phasefx |
whenever someone goes on a holy mission to eliminate all warnings :) |
| 15:05 |
berick |
skabam! live tests. |
| 15:05 |
* berick |
tries to think of a good live test to add |
| 15:07 |
phasefx |
berick++ |
| 15:07 |
pinesol_green |
[evergreen|Jason Etheridge] tests against stock test data and live Evergreen - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=310a0d5> |
| 15:07 |
pinesol_green |
[evergreen|Jason Etheridge] test bill payment - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5c883f0> |
| 15:07 |
pinesol_green |
[evergreen|Jason Etheridge] Add a TestUtils library for live tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6530fb4> |
| 15:08 |
phasefx |
berick: we could use examples for how to use MARC in a perl test |
| 15:10 |
berick |
phasefx: as in, inspect bre.marc (e.g. via xml::Libxml) or specifically marc::record? |
| 15:11 |
phasefx |
berick: let's say someone wants to test some parameter to an opensrf marc update method, how might they represent/get the MARC they're using in the perl environment? |
| 15:14 |
berick |
phasefx: k, i can probably come up w/ something. gracias |
| 15:14 |
eeevil |
dbwells: indeed. we've turned search into a stress ball! ;) |
| 15:15 |
dbwells |
heh |
| 16:05 |
* Dyrcona |
knows there are Princess Bride related jokes in all of these ouses. |
| 16:05 |
jboyer-isl |
It does exist and I've set and cleared it to no avail. I'm finding a patron with claimed items now. |
| 16:07 |
jeff |
jboyer-isl: on the patron whose counts you pasted earlier... can you confirm that they have a circ with a null checkin_time and with stop_fines of CLAIMSRETURNED, and that circ has an xact_finish that is non-null? |
| 16:07 |
berick |
phasefx: is this at all what you were thinking? http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/berick/bre-marc-live-test (top commit) |
| 16:07 |
|
kbutler joined #evergreen |
| 16:09 |
jboyer-isl |
jeff: Yes. For the pasted account xact_finish is set (no fines) and checkin_time is null |
| 16:10 |
jeff |
jboyer-isl: okay. and on your dev system you have a patron with a circ matching that same criteria, and it is shown where in production is it not? |
| 16:19 |
jboyer-isl |
jeff: I suppose that means that tomorrow I can file a bug on it in LP. At least I can stop chasing geese. |
| 16:23 |
jeff |
it appears that the storage method is more accurate but slower, and is only used by legacy scripts. the IDL view could just have its logic fixed rather easily. |
| 16:25 |
jboyer-isl |
That's good. I may see if I can get it working on our dev server tomorrow unless someone beats me to it. I'm out today in a couple mins. |
| 16:26 |
jeff |
it's an edit to fm_IDL.xml and some testing. :-) |
| 16:27 |
jboyer-isl |
Splendid. |
| 16:28 |
jboyer-isl |
thanks for talking it out, it would likely have taken me longer to find my mistake on my own. |
| 16:28 |
jboyer-isl |
jeff++ |
| 12:33 |
bshum |
phasefx_: It's not unprecedented, but if there anything in particular that doing so would gain us? |
| 12:33 |
bshum |
*is there |
| 12:33 |
bshum |
Just curious why we wouldn't just use whichever packaged version was available to us from indexdata |
| 12:34 |
phasefx_ |
bshum: I'm using berick's eg_wheezy_installer.sh script to install Evergreen from scratch periodically and run tests. It gets derailed whenever ftp.indexdata.dk is down, which is often enough to annoy me |
| 12:36 |
phasefx_ |
of course, it's working now :) |
| 12:36 |
bshum |
I guess I don't really have a strong opinion either way. |
| 12:37 |
bshum |
Though I would have wondered why the packaged yaz wasn't working for Wheezy |
| 12:37 |
phasefx_ |
may never have been tested |
| 12:37 |
bshum |
Though also, the packaged yaz for Precise has issues with it, so I guess I can't talk about that too much either. |
| 12:41 |
phasefx_ |
you know what, it's not yaz, it's simple server |
| 12:42 |
|
mrpeters joined #evergreen |
| 13:38 |
|
smyers_ joined #evergreen |
| 13:48 |
|
kbutler joined #evergreen |
| 14:01 |
Dyrcona |
cstore starts. cstore connects to the database. cstore dies silently. |
| 14:02 |
jeff |
try setting ON_ERROR_EXPLODE=1 |
| 14:03 |
jeff |
"push to test. *click* release to detonate." |
| 14:03 |
jeff |
Dyrcona: is this under some exceptional / test scenario, or in production? |
| 14:04 |
Dyrcona |
I'm just going to rebuild the VM with the old RAM parameters. |
| 14:04 |
Dyrcona |
jeff: It is a development VM with 4GB of RAM, and immediately after running osrf_control to start everything. |
| 14:04 |
Dyrcona |
reporter-store does the same thing, too. |
| 14:14 |
jeff |
good luck. i am interested from afar. |
| 14:15 |
Dyrcona |
I wonder if it is a memory limitation, but I don't see OOM killer messages. |
| 14:16 |
Dyrcona |
swap was not being used, and there were about 600MB of free RAM, out of 4GB. |
| 14:19 |
yboston |
Within 15 minutes I want to try an "on air" Google Hangout as preparation of the asciidoc training I want to give. Any volunteers to join me? |
| 14:19 |
yboston |
Your can send me your Google linked email accounts through private message. Thanks in advance |
| 14:34 |
yboston |
Any one see this test stream? http://youtu.be/fnH71b6rSWo |
| 14:34 |
jeff |
I'm not in an environment to participate or listen, but I can see the video, yes. |
| 14:35 |
kmlussier |
yboston: I see it! |
| 14:37 |
kmlussier |
yboston: I also see the presentation screen. But, like jeff, I'm not in a position to join the Hangout at the moment. |
| 15:37 |
Dyrcona |
the first object does, but the one being fleshed doesn't. |
| 15:38 |
Dyrcona |
should it work with a search? |
| 15:38 |
Dyrcona |
I'll try money::billing lacks pcrud. |
| 15:39 |
Dyrcona |
I'll test with the target copy which I know does.... |
| 15:41 |
Dyrcona |
So, if you search and request a flesh of something that doesn't have pcrud support, you get nothing. |
| 15:41 |
Dyrcona |
If you retrieve and flesh the same thing, you get the object you're retrieving, but the flesh_field is empty. |
| 15:45 |
* Dyrcona |
goes back to the original idea of using cstore. |
| 11:10 |
ElliotFriend |
awesome thought-process, but I'm 90% confident I would do more damage than good by modifying anything in Perl haha |
| 11:11 |
robertl_ |
Hi. Anyone knows how long it takes for beta release before it becomes stable? |
| 11:12 |
RoganH |
robertl_: as soon as bugs are squashed |
| 11:13 |
RoganH |
The beta blocker list is pretty small, then we get RC. How long something stays at RC depends partly on how much testing it gets. |
| 11:22 |
robertl_ |
thanks Rogan |
| 11:50 |
|
Dyrcona joined #evergreen |
| 11:52 |
Dyrcona |
pinesol_green: Any laters for me? |
| 12:46 |
pinesol_green |
[evergreen|Dan Wells] Stamping upgrade 0839: alternative title index fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b8ec73d> |
| 12:47 |
jeff |
dbwells++ |
| 12:48 |
* Dyrcona |
is back |
| 12:52 |
jeff |
bah. pound appears to be unsuitable for use in environments where your local interface IP is not your public-facing IP, unless you go down the path of split dns. |
| 12:53 |
jeff |
perhaps exclusively where the local interface IP can change. |
| 12:53 |
jeff |
and another option is to update pound.cfg dynamically. |
| 12:59 |
jeff |
oh that's weird. re-test server behavior seems to skip/cache the version check. |
| 13:11 |
* tsbere |
hates library vendors that refuse to change how they send email because it worked the way they are when they started decades ago... |
| 13:16 |
Dyrcona |
@later tell gmcharlt Would you be interested in records that appear to OK in UTF-8 but cause warnings when converted to MARC-8 with MARC::Charset? |
| 13:16 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 15:15 |
Dyrcona |
Hope I didn't step on backporting 0839, or is it for 2.5+ only? |
| 15:18 |
berick |
@later tell dbwells since we're in beta now, can we get an origin/rel_2_5 branch so master can remain open for business? |
| 15:18 |
pinesol_green |
berick: The operation succeeded. |
| 15:19 |
dbwells |
berick: I think in the past we have deliberately closed master until final release to encourage more testing and less new stuff. Maybe I am mistaken, though. |
| 15:19 |
dbwells |
berick: And by closed, I mean kept for bugfixes only. |
| 15:22 |
kmlussier |
It's been a while since I updated that page. I also added fparks_ and yboston to http://wiki.evergreen-ils.org/doku.php?id=contributing:contributors. fparks++ yboston++ |
| 15:22 |
kmlussier |
new_contributors++ |
| 15:22 |
berick |
hm, i think that's great as a policy -- let's focus on bug fixes - i'm not fond of enforcing it in that manner, though |
| 15:44 |
roses |
Dyrcona: I'm going to steal that line and tell them that!! |
| 15:44 |
Dyrcona |
Crazy staff.... |
| 15:44 |
bshum |
"I don't recognize this account, I'm gonna delete it." |
| 15:44 |
roses |
bshum: sounds like something i would do to myself while "testing" |
| 15:44 |
jeff |
All disclaimers about deleting users aside, to answer the original question, a staff user deleting another user will need DELETE_USER at the target user's home_ou, and may also need ACTOR_USER_DELETE_OPEN_XACTS.override at the target user's home_ou as well. You'll also need the same group application permissions that you would need to be able to edit the user in the first place -- for a stock install, that means you'd need group_application.user.patron fo |
| 15:45 |
jeff |
oh, and that truncated. if someone would kindly tell me where, i can re-send. |
| 15:45 |
bshum |
group_application.user.patron for... |
| 16:15 |
pinesol_green |
Launchpad bug 1097399 in Evergreen 2.4 "Reserve room for system config.metabib_field values" (affected: 4, heat: 24) [Medium,Confirmed] |
| 16:16 |
bshum |
I knew it existed somewhere |
| 16:17 |
dbwells |
bshum: very interesting, so it isn't in yet. Bummer. Same problems, different day :) |
| 16:18 |
bshum |
Dyrcona: Fwiw, my test system that I setup last Saturday only goes to id 30. With 30 being LCCN, so something is awry in there. |
| 16:19 |
bshum |
dbwells: Yeah, I think it was covered in an upgrade SQL during the 2.0 era. |
| 16:19 |
bshum |
dbwells: So folks who upgraded in that time were covered, but folks who went to Evergreen or always were on master were broken by the lack of proper sequencing. |
| 16:21 |
bshum |
dbwells: I'm curious about something (which I guess I would see if I did apply the branch), but... |
| 16:21 |
dbwells |
bshum: you must be right, because our custom indexes start at 101. |
| 16:21 |
bshum |
dbwells: What should the title data look differently between browse vs. regular? |
| 16:21 |
bshum |
*how should |
| 16:25 |
bshum |
Dyrcona: Yeah, the bug I linked to has a branch you created to do that ;) |
| 16:25 |
dbwells |
bshum: the bigger issue it fixes (which is why it is a blocker) is that the non-filing stuff was ending up in the sort_value in metabib.browse_entry. |
| 16:26 |
dbwells |
Dyrcona: so, you agree with yourself from 5 months ago, that's good :) http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=95251643c7a60945f50b30be7e328ecbcae38cd6 |
| 16:26 |
Dyrcona |
I can still test it, though. |
| 16:28 |
Dyrcona |
That's amazing. These days I'm lucky if I agree with myself from 5 minutes ago. |
| 16:28 |
|
Bmagic joined #evergreen |
| 16:28 |
dbwells |
:) |
| 16:46 |
bshum |
dbwells: That helps, thanks! Sorry, I got distracted reminiscing about the old days. |
| 16:47 |
|
sseng__ joined #evergreen |
| 16:47 |
|
smyers_ joined #evergreen |
| 16:47 |
dbwells |
bshum: the second (more minor) change is that trailing punctuation for titles should be gone now from the title browse display (especially '/'). |
| 16:47 |
|
dconnor joined #evergreen |
| 16:48 |
|
smyers_ joined #evergreen |
| 16:51 |
|
dconnor joined #evergreen |
| 16:52 |
|
dconnor joined #evergreen |
| 16:53 |
dbwells |
bshum: Dyrcona: one thing I should also point out if you are watching the DB while testing is that metabib.browse_entry builds up dead rows. I don't think any code ever deletes them. I intend to open that as a separate bug, but it practice, I don't think it is a big deal. |
| 16:53 |
|
dMiller_ joined #evergreen |
| 16:56 |
mrpeters |
any syslog-ng experts left? i know most have switched to rsyslog but I am pulling my hair out trying to figure out why gateway and eg-stats logs are going to both their own log files, AND to osrfsys.$HOUR.log |
| 16:56 |
mrpeters |
its making troubleshooting a nightmare |
| 17:09 |
kmlussier |
Dyrcona: OK, well thanks for the attempt. :) |
| 17:09 |
* mrpeters |
now debates time investment vs switching them to rsyslog versus fixing syslog-ng |
| 17:13 |
Dyrcona |
kmlussier: Or maybe it will. A little regexp magic goes a long way. |
| 17:14 |
bshum |
dbwells: Interesting.... on the concerto test dataset from clean to running the reingest after applying the patch I do notice there are extra rows in metabib.browse_entry that don't appear in the metabib.browse_entry_def_map |
| 17:15 |
bshum |
I should have checked right before I ran it... doh |
| 17:16 |
dbwells |
bshum: right, those are the old rows which no longer apply. It will need a fix, but since those rows are likely to build up very slowly in real life, I don't want to block RC for it. |
| 17:16 |
bshum |
"slowly" |
| 17:16 |
* bshum |
goes to try his query in production for kicks :) |
| 17:28 |
dbwells |
bshum: I did this: |
| 17:28 |
dbwells |
select * from metabib.browse_entry mbe LEFT JOIN metabib.browse_entry_def_map mbedm ON mbedm.entry = mbe.id LEFT JOIN metabib.browse_entry_simple_heading_map mbeshm ON mbeshm.entry = mbe.id where mbedm.id IS NULL AND mbeshm IS NULL; |
| 17:29 |
dbwells |
I still found 5 things I wasn't expecting to be orphaned from the concerto set, so I am not sure what is going on there. |
| 17:30 |
bshum |
What is simple_heading_map? |
| 17:30 |
* bshum |
doesn't seem to have that in his production DB... |
| 17:31 |
bshum |
Oh I see |
| 17:31 |
bshum |
We don't have it yet, nevermind. |
| 17:31 |
bshum |
That went in after our last step forward |
| 17:37 |
bshum |
dbwells: Is there supposed to be a difference in how 6 vs. 31 metabib field present in the metabib.title_field_entry? Or are they basically identical and the question is just how they are rendered in the browse table values? |
| 17:38 |
bshum |
Having only just run that against the concerto test set quickly, the only 7 bibs that show differences in those indexed values were like: |
| 17:38 |
bshum |
L'unique et sa propriété vs. L' unique et sa propriété |
| 17:38 |
bshum |
The extra space gets removed, and so forth |
| 17:39 |
bshum |
Otherwise, every other 6 and 31 were exactly the same on every bib in the test dataset. |
| 17:39 |
* bshum |
needs more test databases |
| 17:40 |
dbwells |
bshum: I am totally confused, as that is a change I would not expect to see. |
| 17:40 |
bshum |
dbwells: Well, I didn't inspect very closely, I just ran the final upgrade SQL from the branch on the bug ticket. |
| 17:40 |
bshum |
Maybe I missed something |
| 17:41 |
pinesol_green |
Launchpad bug 1235497 in Evergreen "Title browse has display and sorting issues" (affected: 1, heat: 6) [Undecided,New] |
| 17:41 |
dbwells |
bshum: maybe you still have the old 31? |
| 17:41 |
dbwells |
(though I assume the upgrade would have blown up at you) |
| 17:41 |
bshum |
dbwells: The test system I applied the upgrade to didn't have a 31 in it before I applied the sql. |
| 17:42 |
senator |
"the baroque concerto" moves from the wrong place to the right place in my test |
| 17:42 |
bshum |
It's a fresh DB as of last Saturday, but I can rebuild again just in case. |
| 17:42 |
senator |
and similar |
| 17:42 |
bshum |
Oops, maybe tomorrow. (just saw the clock) |
| 17:45 |
dbwells |
senator: thanks for the testing and signoff. Glad it worked for you. |
| 17:48 |
|
RBecker joined #evergreen |
| 17:51 |
dbwells |
senator: I also responded to Liam before I saw your comment. We said roughly the same thing, save one point. The stock MODS <titleInfo> field does have the <nonSort> tag, so the main hang up is that we only get one 'joiner' for everything in title, while we (ideally) need a different joiner from <nonSort>-><title> than from <title>-><subtitle>. |
| 17:52 |
dbwells |
maybe I misunderstood what you were saying. In any case, it is a topic for another day. |
| 17:53 |
* dbwells |
hopes not tomorrow |
| 17:56 |
senator |
heh |
| 17:56 |
|
smyers_ joined #evergreen |
| 17:57 |
senator |
ah k, well, that is a significant point |
| 12:31 |
dbwells |
kmlussier: yes, I plan to redo them again. The way I did it for the beta was pretty ad hoc, so hopefully the second time through I can be a little more systematic about it. |
| 12:32 |
kmlussier |
dbwells: Great! That's what I was hoping you would say. :) |
| 12:35 |
|
yboston joined #evergreen |
| 12:38 |
bshum |
dbwells: So we're testing that fix for receiving |
| 12:38 |
bshum |
dbwells: And it looks like it received properly and we created the item |
| 12:38 |
bshum |
But apparently the range in the summary holdings doesn't show the updated issue |
| 12:40 |
dbwells |
bshum: what holdings display are you using? |
| 12:40 |
bshum |
Mary was looking at http://acorn.biblio.org/eg/opac/record/2236299?expand=issues;sid=1644;stype=basic;sepath=2013;sepath=09;seoffset=0;seoffset=0;seoffset=0#issues for example. |
| 12:40 |
bshum |
Where the last issue that was just added was the Sept 15 one |
| 12:46 |
dbwells |
I should probably just say "Oh, 'use fully compressed holdings'? That's senator's problem." ;) |
| 12:50 |
|
mllewellyn joined #evergreen |
| 12:58 |
_bott_ |
I hate weird problems. |
| 12:58 |
dbwells |
bshum: I can see what you are saying on the record you posted, but I can't duplicate it on my test box. I'd need to see the exact holding codes for your Sep.08 and Sep.15 issues, I guess, then go from there. |
| 12:59 |
* dbwells |
goes to lunch, back in a bit |
| 12:59 |
_bott_ |
Has anyone found the status_changed_time trigger not firing consistently? I have random cases where the status is changed at checkin, but the status_changed_time is not updated, it's left at the checkout time. This in turn screws up reshelving delay. |
| 13:08 |
bshum |
dbwells++ # we figured it out, it was a local holding_code problem |
| 13:08 |
bshum |
The holding_code had been modified with a bad copy/paste and the date in the code was 08 not 15 |
| 13:08 |
bshum |
User error |
| 13:08 |
bshum |
We'll test again with another sample, but I think this means your patch works to resolve the receiving problem. |
| 13:10 |
|
ericar joined #evergreen |
| 13:11 |
pinesol_green |
[evergreen|Kathy Lussier] Move various release notes into correct directory - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=30a69c4> |
| 13:11 |
pinesol_green |
[evergreen|Kathy Lussier] Adding new OPAC features to Release Notes. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e66a212> |
| 13:20 |
mllewellyn |
pleading guilty to the operator causing the error. |
| 13:31 |
|
RoganH joined #evergreen |
| 13:42 |
dbwells |
bshum: yay :) |
| 13:42 |
bshum |
dbwells: Yep, she tested on a different issue and it received perfectly fine. |
| 13:42 |
bshum |
I'll sign off on your fix and get that pushed to master. |
| 13:43 |
bshum |
dbwells++ |
| 13:45 |
rfrasur |
jcamins: this speaker is talking exactly what you were talking about earlier... |
| 13:46 |
pinesol_green |
[evergreen|Dan Wells] Relax MFHD subfield 'a' requirement for caption/patterns - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a420b0e> |
| 13:46 |
jcamins |
rfrasur: oh? What speaker? |
| 08:29 |
Dyrcona |
Four records were too large, and likely not exported. |
| 08:29 |
csharp |
Dyrcona: so how long did it take before? |
| 08:31 |
Dyrcona |
With marc_export from support scripts, it took so long that I never let one finish, over 24 hours in every case. |
| 08:31 |
csharp |
wow |
| 08:31 |
csharp |
ours takes 48 hours |
| 08:31 |
* csharp |
would like to test Marque.pm |
| 08:32 |
bradl |
csharp: speaking of speed, have you guys thought any more about SSD? |
| 08:32 |
* csharp |
loves that name |
| 08:32 |
Dyrcona |
Marque.pm is not the final version. It's basically a test bed/proof of concept. |
| 08:32 |
csharp |
bradl: we have thought about it, but it will probably be next year before we can do anything about it ;-) |
| 08:32 |
Dyrcona |
The final version will be ready for 2.6. |
| 08:33 |
csharp |
Dyrcona: well, if you want a tester, just let me know |
| 08:35 |
Dyrcona |
Crazy: I installed an update for libyaz4 yesterday, and today Update Manager is telling me that libyaz5 wants to install. |
| 08:36 |
paxed |
sounds a bit premature ... :P |
| 08:37 |
Dyrcona |
Eh, whatever. |
| 08:37 |
Dyrcona |
I'm going to update my VM today, too, so might as well try testing z39.50 with libyaz5. |
| 08:38 |
Dyrcona |
I use IndexData's repo for debs by way of explanation. |
| 08:39 |
|
Shae joined #evergreen |
| 08:41 |
bshum |
Dyrcona: libyaz5 as a client seemed fine so far in my light testing. |
| 08:42 |
Dyrcona |
bshum: I want to test it with the server. |
| 08:42 |
bshum |
I haven't gotten to try it with the server part yet. |
| 08:42 |
bshum |
Cool. |
| 08:43 |
bshum |
Also, super exciting for Marque test. |
| 08:44 |
Dyrcona |
Yeah. I figure if you want to use Marque.pm for Boopsie, then go ahead. |
| 08:44 |
Dyrcona |
It all has to be installed by hand, but the final version in the branch on lp1223903 will do all the right things. |
| 08:45 |
Dyrcona |
bug 1223903 |
| 11:47 |
|
jdouma joined #evergreen |
| 11:55 |
|
artunit joined #evergreen |
| 11:57 |
|
smyers_ joined #evergreen |
| 12:03 |
Dyrcona |
bshum++ # for testing before I get to ti. |
| 12:03 |
Dyrcona |
it |
| 12:07 |
Dyrcona |
bshum: We might be able to trap the MARC::File error with an eval and print the bib id. |
| 12:08 |
* Dyrcona |
was away from his desk for the past hour or more, chatting with a coworker about Evergreen issues and our new member library's first day. |
| 14:13 |
depesz |
http://depesz.privatepaste.com/82ebcbeadf - that's the original |
| 14:14 |
depesz |
http://depesz.privatepaste.com/350bbaf122 -> that's the new one |
| 14:14 |
eeevil |
depesz: I'm looking at master now ... at a real computer today :) |
| 14:14 |
depesz |
YAY :) |
| 14:15 |
depesz |
eeevil: anyway for some particular set of data, and query - original functions does it's work in ~ 400ms, and new one in ~ 16ms |
| 14:16 |
depesz |
of course 400ms is not that bad, but - when I tested pg logs for all slow queries, the one that used the most time was call to "unapi.bre()" function - not sure if this is part of evergreen. |
| 14:16 |
eeevil |
it is |
| 14:16 |
depesz |
when I profiled it - 98% of its runtime was call to unapi.holdings_xml, which in turn had bulf of its time from evergreen.ranked_volumes |
| 14:17 |
depesz |
so - while the immediate speedup is perhaps not all that great, it looks like it should optimize very often (in this system) called query. |
| 16:25 |
senator |
my verbiage, if you can parse it, should incidentally explain why you never really saw a difference with Callender's branch |
| 16:26 |
senator |
although it should have worked too |
| 16:26 |
|
Dyrcona left #evergreen |
| 16:26 |
bshum |
senator: Yeah I saw the changes for the actual index in yours. I'm not entirely sure what I was testing back then and all. It seems like forever ago now. |
| 16:26 |
senator |
no, that's separate |
| 16:26 |
bshum |
senator: That and bibcn is like the worst search in a consortium that doesn't share any call numbers uniformly :D |
| 16:27 |
bshum |
So it hasn't been a huge priority on my end of things. |
| 10:13 |
|
artunit joined #evergreen |
| 10:21 |
|
ericar_ joined #evergreen |
| 10:24 |
Bmagic |
I am attempting to come up with some basic sanity checks on all/most of the openSRF services. The API documentation doesnt seem to have examples of how to call the methods within. Anyone have some basic pointers on this subject? An example that I have found so far is my( $user, $evt ) = simplereq( STORAGE(), 'open-ils.storage.direct.actor.user.retrieve', 1 ); which seems to do a quick and |
| 10:24 |
Bmagic |
easy job of interfacing with the storage component and will tell me if it's alive or not. I would like to test some of the other services with a basic perl script. I am looking at /opac/extras/docgen.xsl - perhaps there is a better resource? |
| 10:27 |
|
mrpeters1 joined #evergreen |
| 10:27 |
senator |
Bmagic: combine the api documentation you get from docgen.xsl with this article (see parts 1 and 2) in order to know how to invoke the methods in general: http://journal.code4lib.org/articles/3284 |
| 10:28 |
senator |
if you're impatient you can skip down to "Calling OpenSRF methods from Perl applications", but all of both parts of the article are worth the read for getting the big picture |
| 10:29 |
Bmagic |
open-ils.vandelay and open-ils.fielder and open-ils.acq for example |
| 10:30 |
senator |
not sure what you mean. you call methods from any service in the same way. the number and type of arguments required by any given method can be totally different, as can the shape of results |
| 10:30 |
Bmagic |
right on, sounds like I'm on the right path |
| 10:30 |
jeff |
some services may not have a suitable method to call for testing purposes. others may require the creation of test objects for them to be suitable. |
| 10:31 |
jeff |
Bmagic: what are your goals? |
| 10:31 |
Bmagic |
we find ourselves having to restart these services after clients call to tell us about it |
| 10:31 |
Bmagic |
we would like to know before hand |
| 10:31 |
|
mrpeters joined #evergreen |
| 13:50 |
Dyrcona |
I should shut up now 'cause I've not really looked into it beyond what I've done here. |
| 13:50 |
* csharp |
doesn't have full context either |
| 13:50 |
kmlussier |
I was wondering if the entry from opac.dtd was a leftover from jspac. |
| 13:50 |
csharp |
nor a good way to set that up for testing (quickly, anyway ;-)) |
| 13:51 |
csharp |
kmlussier: yeah - you may be right - that's the only occurrence of 'circ.fail_part.config.circ_matrix_test.available_copy_hold_ratio' I can find |
| 13:52 |
kmlussier |
Thanks for looking into it anyway! csharp++ Dyrcona++ |
| 13:53 |
Dyrcona |
I say open a launchpad bug. 'cause it looks like something is missing or at least not looking up the right string in a file somewhere. |
| 13:54 |
kmlussier |
Dyrcona: Sure, I'll do that. |
| 14:14 |
pinesol_green |
csharp: Yes! |
| 14:15 |
kmlussier |
dbwells: So, how can you tell if it's in the DB code? |
| 14:15 |
* kmlussier |
can't remember where she copied the text from to begin with. |
| 14:17 |
dbwells |
kmlussier: that's a good question, especially since, if it exists, it might just be in a certain upgrade script or whatnot. Have you tested this on master, or just your local install? Like I said, it might just be a weird anomaly in the email, and not related to the problem. |
| 14:18 |
kmlussier |
dbwells: It was on master from maybe a month ago. I was using Dyrcona's dev server. |
| 14:19 |
csharp |
a<200b>vailable_copy_hold_ratio |
| 14:19 |
csharp |
that's the way it displays in vim |
| 15:54 |
|
dMiller_ joined #evergreen |
| 15:54 |
tsbere |
I wouldn't mind if vendors would stop wanting referrer auth. Even if I have to give them access to SIP2. >_> |
| 15:54 |
* tsbere |
*hates* referrer auth |
| 15:54 |
Dyrcona |
That's not even auth. That's just a test if you can fake a HTTP header or not. |
| 15:55 |
Dyrcona |
bshum: 65,454 records exported in under 1 hour, more like 40 minutes. |
| 15:55 |
Dyrcona |
Just the new records I added this weekend. |
| 15:55 |
bshum |
That sounds awesome. |
| 09:04 |
|
SimonHM joined #evergreen |
| 09:05 |
Dyrcona |
Seems to me that from Day -365 they've made choices that went made their Evergreen installation more difficult, and then they blame Evergreen and the community for the consequences of their decisions. |
| 09:06 |
|
ericar joined #evergreen |
| 09:08 |
jeff |
CentOS 5.9 seems to ship with Perl 5.8, which was released in 2008 and is End of Life. If the version of Perl that ships with your OS is your primary stumbling block, going down the perlbrew path might be a possible approach. I use perlbrew in development / testing, and I can tell you that it will be a bit of a challenge to use in production, but perhaps less of a challenge than you are currently dealing with. |
| 09:09 |
Dyrcona |
Well, I'll shut up since I seem the lone voice in the wilderness suggesting that they go with a distro that others in the community actually use and can support. |
| 09:09 |
jeff |
For one thing, using perlbrew with mod_perl is tricky, and will likely require compiling mod_perl from source as well. This might be a rabbit hole that makes the whole thing more difficult than its worth. Your decision. :-) |
| 09:10 |
csharp |
well, we used to support CentOS and we do support Fedora, so I think (theoretically) it would be good if we did have up-to-date CentOS support |
| 09:33 |
rfrasur |
k |
| 09:36 |
rfrasur |
bshum++ #best comments ever |
| 09:37 |
rfrasur |
"So maybe instead of slowing down and dying from memory issues, it just crashes...So maybe it's a good sign..." |
| 09:37 |
smyers_ |
I feel dumb |
| 09:38 |
smyers_ |
Dyrcona: Thanks you pionted me in the right spot I just was dumb and didn't update try tiny on the app boxes too |
| 09:38 |
smyers_ |
2.4 is now running and passing all automated tests we have on centos5.9 |
| 09:42 |
|
smyers__ joined #evergreen |
| 10:16 |
|
yboston joined #evergreen |
| 10:16 |
|
hopkinsju joined #evergreen |
| 10:36 |
|
RoganH joined #evergreen |
| 10:37 |
|
artunit joined #evergreen |
| 10:38 |
|
Berklee joined #evergreen |
| 10:54 |
yboston |
which OSRF version should I be using to test EG 2.5 beta1, 2.2.0 or master? |
| 10:57 |
senator |
yboston: afaik it should not matter, but if you're testing the beta EG tarball, i'd probably use the 2.2.0 opensrf tarball with it |
| 10:57 |
senator |
just so your experience will match what most people looking at the downloads page would do |
| 10:59 |
yboston |
senator: thanks, just wanted to make sure |
| 10:59 |
jeff |
yboston++ testing |
| 11:06 |
|
ericar joined #evergreen |
| 11:12 |
|
Shae joined #evergreen |
| 11:14 |
|
gsams joined #evergreen |
| 12:46 |
mmorgan |
paxed: the errors are only intermittent, for one of our libraries. How would we check to see if common.properties is getting loaded? |
| 12:48 |
phasefx |
mmorgan: check that DNS is consistently working.. and/or try using an IP address instead of your hostname |
| 12:49 |
paxed |
also perhaps check if there are any dropped packets, with ping for example. |
| 12:49 |
smyers_ |
mmorgan: is the internet connection at the one library slow? if only one branch has the issue it might be the js isn't getting downloaded or properly cached |
| 12:50 |
smyers_ |
pingtest.net and speedtest.net are great for testing |
| 12:52 |
mmorgan |
It's a college libary on their own network, with their own IT department, so it's sounding like a network issue. We'll check speed and DNS, and maybe have them contact IT to see if they made any changes. Thanks, everyone! |
| 12:54 |
* paxed |
goes for a jog |
| 13:00 |
|
jbfink joined #evergreen |
| 14:29 |
|
Callender joined #evergreen |
| 14:30 |
rfrasur |
Is there somewhere that I can go and just look at EG tables? |
| 14:30 |
natschil |
rfrasur: You can use the postgresql client application "psql" |
| 14:31 |
jeff |
rfrasur: look at the "database schema" links here: http://docs.evergreen-ils.org/ |
| 14:31 |
jeff |
rfrasur: if you're purely looking for structure -- if you're looking for data, your best bet is a report, or in the case of a test instance (since iirc you don't have sql access to EI production), what natschil suggested with psql. |
| 14:32 |
rfrasur |
natschil: thank you...not ready to start installing things I don't understand yet...just a librarian (I forget to preface anymore). |
| 14:32 |
rfrasur |
jeff: thank you, that's what I wanted. I don't care about data at this point. |
| 14:32 |
* rfrasur |
just wants to see the table structure |
| 14:32 |
jeff |
also on a test database you can use a tool like pgadmin or phppgadmin |
| 14:32 |
jeff |
rfrasur: excellent. much easier to accomplish that goal! |
| 14:33 |
bshum |
@love pgadmin |
| 14:33 |
pinesol_green |
bshum: The operation succeeded. bshum loves pgadmin. |
| 14:33 |
jeff |
rfrasur: yeah, bshum's probably your guy if you have interest in pgadmin. |
| 15:08 |
tsbere |
DPearl: Moving copies with parts across records seems to cause that kind of thing. I think. We see it at times, I do manual cleanup... |
| 15:08 |
* tsbere |
has had issues reproducing it to be sure what the problem is |
| 15:08 |
kmlussier |
DPearl: I believe there is a related bug report on that. |
| 15:09 |
Bmagic |
before I start writing a bunch of code to test services. Does anyone already have some scripts to show green light red light for these services: opensrf.settings open-ils.acq open-ils.booking open-ils.cat open-ils.supercat open-ils.search open-ils.circ open-ils.actor open-ils.auth_proxy open-ils.storage open-ils.penalty open-ils.justintime open-ils.collections open-ils.ingest open-ils.reporter |
| 15:09 |
Bmagic |
open-ils.permacrud open-ils.trigger open-ils.url_verify open-ils.fielder open-ils.vandelay open-ils.serial |
| 15:10 |
kmlussier |
DPearl: https://bugs.launchpad.net/evergreen/+bug/904472 |
| 15:10 |
pinesol_green |
Launchpad bug 904472 in Evergreen "Transferring items with monographic parts to a new bib record causes problems with holds placement" (affected: 3, heat: 22) [Undecided,Triaged] |
| 15:10 |
bshum |
Doesn't the newest opensrf already do that now? |
| 15:11 |
Bmagic |
yep, query the service and expect something good |
| 15:11 |
Bmagic |
something simlar to this: my( $user, $evt ) = simplereq( STORAGE(), 'open-ils.storage.direct.actor.user.retrieve', 1 ); |
| 15:11 |
* csharp |
doesn't know of such tests |
| 15:12 |
bshum |
I guess I was thinking of the osrf_control --diagnostic stuff. Not that I've played with or know how to play with those. |
| 15:13 |
dbwells |
bshum: That bug isn't too old, and is probably still valid. I am not 100% sure what is going on with it, but it seems like our code fails whenever you have an 'x' or 'y' (calandar change or exception data), and that 'x'/'y' refers to a level of chronology which doesn't exist in the caption. That's my hunch, anyway. In any case, I think it is worth leaving open. |
| 15:14 |
bshum |
dbwells: Alrighty, I'll leave it be. Thanks. :) |
| 10:51 |
gmcharlt |
this cannot be left un-noted |
| 10:52 |
gmcharlt |
@quote add <senator> what a nice smile, dojo. why thank you, angularjs, and that's a nice outfit you're wearing. |
| 10:52 |
pinesol_green |
gmcharlt: The operation succeeded. Quote #68 added. |
| 10:53 |
Dyrcona |
I'm processing the final file MARC data file for this weekend's migration into my development server for testing. |
| 10:53 |
jeff |
I found some interesting (and not so interesting) tidbits in this article, its comments on site and on hn: https://coderwall.com/p/3qclqg https://news.ycombinator.com/item?id=6452960 |
| 10:53 |
Dyrcona |
I think I'm getting a few more messages about using the object hash as a call number than I did with the previous sample files. |
| 10:54 |
Dyrcona |
That means more copies without call numbers. |
| 12:00 |
|
dMiller_ joined #evergreen |
| 12:01 |
|
gdunbar joined #evergreen |
| 12:15 |
pastebot |
"remingtron" at 64.57.241.14 pasted "EG branch patch splitter/applier" (117 lines) at http://paste.evergreen-ils.org/15 |
| 12:16 |
remingtron |
Dyrcona, if you're bored today, you can checkout my paste |
| 12:17 |
remingtron |
I wrote it to help me test a branch, since I got tired of splitting and applying patches manually |
| 12:17 |
remingtron |
I'd love feedback and/or improvements |
| 12:19 |
jeff |
remingtron: how does this compare to creating a branch and merging other branches to it, then installing from that? |
| 12:20 |
remingtron |
jeff: it just reduces the need to actually install from source |
| 12:20 |
remingtron |
instead, you patch an existing install and restart things |
| 12:20 |
jeff |
remingtron: ah, i think i follow now. |
| 12:20 |
remingtron |
I haven't gotten cool enough to install from source for testing yet |
| 12:20 |
|
smyers_ joined #evergreen |
| 12:21 |
Dyrcona |
Well, this would work for simple things like perl modules that don't have a .in form and sql upgrade scripts. |
| 12:22 |
Dyrcona |
What I typically do is update my test/dev branch, push it to a bare repo on my test/dev server, then pull it into my active repo on the test/dev server. |
| 12:22 |
Dyrcona |
I'll run the necessary upgrade scripts by hand if it is a small update. |
| 12:23 |
Dyrcona |
I'll copy perl and other files when necessary. |
| 12:23 |
Dyrcona |
If .in or files that go into the staff client download have changed, then I'll definitely run my script to build everything from source. |
| 14:23 |
|
yboston joined #evergreen |
| 14:24 |
jeff |
i'd suspect those snuck in at merge conflict resolution time, but I don't think cnbrowse had any merge conflicts. |
| 14:28 |
dbwells |
bshum: you mentioned earlier something about a Z39.50 problem in master. Can you elaborate? |
| 14:32 |
egbuilder |
build #380 of evergreen-master-ubuntu-12.04-x86 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/380 |
| 14:32 |
|
kbeswick joined #evergreen |
| 14:36 |
jeff |
hrm. testing.esilibrary.com is not a build slave, correct? |
| 14:38 |
jeff |
(aka testing.evergreen-ils.org) |
| 14:38 |
jeff |
yeah, looks like it is not a build slave, thus it was pointless for me to install libbusiness-issn-perl on it just now. oh well. |
| 14:42 |
jeff |
the joy of books from ten years ago: ``Many other interesting changes have already happened to mod_perl in Version 2.0, and more will be developed in the future. Some of these will be covered in this chapter, and some you will discover on your own while reading mod_perl documentation.'' |
| 14:53 |
berick |
heh, "and the explosive error messages are also chock full of useful information!" |
| 14:55 |
rfrasur |
(should I just start scheduling programs and commit staff and worry about the budget later?) |
| 14:56 |
berick |
@eightball should rfrasur start scheduling programs and commit staff and worry about the budget later? |
| 16:03 |
bshum |
Those always make me sad. |
| 16:03 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "recreate lost bilings" (11 lines) at http://paste.evergreen-ils.org/21 |
| 16:04 |
Dyrcona |
Bmagic: That's a rough start. You might need to do another for copies that lack prices, to put in the ou setting value for minimum price or whatever. |
| 16:05 |
Dyrcona |
I'd try it on a test database if you have one first. |
| 16:06 |
Dyrcona |
k |
| 16:06 |
Dyrcona |
wrong window. |
| 16:06 |
|
kbeswick joined #evergreen |
| 16:10 |
rfrasur |
yboston: Is it alright to say that you'll send out more details in a future email? |
| 16:10 |
rfrasur |
yboston++ |
| 16:11 |
yboston |
rfrasur: yes, we can talk about it at the meeting |
| 16:14 |
Bmagic |
Dyrcona: I am working on a test database, I have double checked and all the prices are already set. I was just concerned that the action trigger would do more than insert a money.billing row equal to the price. That is why I would prefer the action trigger to do what it does but it doesnt sound like I can get it to trigger on these old circs again without altering/deleting some data. |
| 16:17 |
Dyrcona |
Bmagic: The action_trigger is not a database trigger. It's an Evergreen thing that you have to configure and run a cron job for. |
| 16:18 |
Bmagic |
I understand that |
| 16:19 |
Dyrcona |
ok. |
| 13:59 |
pinesol_green |
[evergreen|Jeff Godin] Add apache config examples for AC by record id - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e5eccfe> |
| 13:59 |
jeff |
my irc clients just went a bit nuts. |
| 14:00 |
bshum |
jeff++ # it's finally in! |
| 14:00 |
jeff |
bshum++ thanks! |
| 14:00 |
jeff |
yboston++ for testing and for test data |
| 14:00 |
bshum |
yboston++ #for helping me test cause my syndetics subscription level sucks |
| 14:00 |
berick |
jeff++ |
| 14:00 |
|
abneiman joined #evergreen |
| 14:01 |
gmcharlt |
show time |
| 14:11 |
jeff |
dbwells++ |
| 14:12 |
yboston |
dbwells I really applaud the approach you took and the time to report back metrics to the community at large |
| 14:12 |
Dyrcona |
dbwells++ |
| 14:12 |
egbuilder |
build #400 of evergreen-master-debian-6.00-x86_64 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/400 blamelist: Bill Erickson <berick esilibrary.com>, Jeff Godin <jgodintadl.org> |
| 14:12 |
egbuilder |
build #376 of evergreen-master-ubuntu-12.04-x86 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/376 blamelist: Bill Erickson <berickesilibrary.com>, Jeff Godin <jgodintadl.org> |
| 14:12 |
egbuilder |
build #343 of evergreen-master-fedora-18 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/343 blamelist: Bill Erickson <berickesilibrary.com>, Jeff Godin <jgodintadl.org> |
| 14:12 |
yboston |
also, you guys were an excellent host |
| 14:12 |
yboston |
for the hack-a-way |
| 14:12 |
jeff |
buildbot likely needs a new dependency installed: Business::ISSN |
| 14:52 |
gmcharlt |
#agreed The EOB is in favor of calling a resource allocator summit, and requests a fleshed-out proposal from interested parties, including Ben Hyman |
| 14:53 |
yboston |
I wanted to make a comment on a way the EOB can help |
| 14:53 |
gmcharlt |
go for it |
| 14:53 |
yboston |
it is multi line, head up |
| 14:53 |
yboston |
Besides providing funding, the EOB can select a point person or small committee to help push this issue forward by doing non-funding based things like... |
| 14:53 |
yboston |
(off the top of my head) |
| 14:53 |
yboston |
1) (only) proposing the client be worked on during hack fest or hack-a-way |
| 14:53 |
yboston |
2) attending dev loper meetings and give feedback thinking as the community as a whole, instead f just a single isntitution |
| 14:53 |
yboston |
3) running special IRC meeting on the client topic |
| 14:53 |
yboston |
4) helping set up ddodle polls for these meetings |
| 14:53 |
yboston |
5) helping create user survey to get more feedback from communtiy |
| 14:53 |
yboston |
6) volunteer to test prototype web clients, and or provide test data |
| 14:54 |
yboston |
(sorry about the spelling) |
| 14:55 |
gmcharlt |
a champion, as it were |
| 14:56 |
yboston |
yes, also thought of the role of just a facilitator(s) |
| 14:56 |
gmcharlt |
some of that would depend on resources for enough devs to participate -- but I think for now, certainly anybody who is interested should advocate for it |
| 14:57 |
gmcharlt |
but I think some of that also anticipate the final form of how the work gets done and funded |
| 14:57 |
gmcharlt |
(briefly) any other comments? |
| 14:57 |
* gmcharlt |
is going to charge forward |
| 14:57 |
gmcharlt |
#topic Evergreen testing efforts |
| 14:57 |
gmcharlt |
#info Summary of recent activity - http://list.evergreen-ils.org/pipermail/eg-oversight-board/2013-September/000601.html |
| 14:58 |
gmcharlt |
Shauna_: anything to add -- and are there things you need from the EOB? |
| 14:58 |
Shauna_ |
Nothing to add unless anyone has documentation they would like to contribute to the effort. |
| 14:59 |
Shauna_ |
I did hear back from one other consortia on that front. |
| 14:59 |
Shauna_ |
I'll be happy to entertain any questions or comments. |
| 14:59 |
kmlussier |
Shauna_++ This all looks great! |
| 15:00 |
abneiman |
Shauna_: if your model is successful (and personally I think it will be), are you planning to open it up to the community at large? |
| 15:00 |
gmcharlt |
my main comment is that if you want to go ahead and start a testing page on the wiki, I encourage you to go for it |
| 15:00 |
RoganH |
I agree and applaud the work. |
| 15:00 |
RoganH |
I think once your work is up there it will encourage others to add onto. |
| 15:01 |
Shauna_ |
abneiman We are writing the documentation using generic project management software that anyone can get access to. |
| 17:07 |
|
mllewellyn left #evergreen |
| 17:11 |
|
mmorgan left #evergreen |
| 18:16 |
pinesol_green |
[evergreen|Dan Wells] Translation updates - po files - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b4cc2ba> |
| 18:22 |
egbuilder |
build #344 of evergreen-master-fedora-18 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/344 |
| 18:52 |
|
dMiller joined #evergreen |
| 18:59 |
pinesol_green |
[evergreen|Dan Wells] Translation updates - newpot - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8c7c9ee> |
| 19:01 |
pinesol_green |
[evergreen|Dan Wells] Translation updates - fix Finnish translator email - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a9c36ee> |
| 19:31 |
jeffdavis |
I want to shove a bunch of MARC records directly into the database of an EG test server. Would `marc_stream_importer.pl --spoolfile=$MARCFILE --nodaemon --noqueue` be a good way to do this? Is there a faster/easier way? |
| 19:34 |
jeffdavis |
"a bunch" = 38K records |
| 19:35 |
pinesol_green |
[evergreen|Dan Wells] Move 'floating groups' release note docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ee61da7> |
| 20:08 |
|
sseng_ joined #evergreen |
| 20:33 |
|
jboyer-laptaupe joined #evergreen |
