| Time |
Nick |
Message |
| 00:21 |
|
dbwells_ joined #evergreen |
| 00:48 |
|
stevenyvr2 joined #evergreen |
| 00:48 |
|
stevenyvr2 left #evergreen |
| 01:25 |
|
Mark__T joined #evergreen |
| 01:55 |
|
stevenyvr2 joined #evergreen |
| 01:55 |
|
stevenyvr2 left #evergreen |
| 03:50 |
|
altin joined #evergreen |
| 03:50 |
altin |
admmin |
| 03:50 |
altin |
demo123 |
| 03:50 |
altin |
is not working |
| 03:50 |
altin |
on the demo servers... |
| 03:51 |
altin |
http://demo.evergreencatalog.com/eg/opac/home |
| 07:51 |
|
rjackson-isl joined #evergreen |
| 08:30 |
|
akilsdonk joined #evergreen |
| 08:33 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
akilsdonk joined #evergreen |
| 08:47 |
|
akilsdonk joined #evergreen |
| 08:52 |
|
akilsdonk joined #evergreen |
| 08:55 |
|
mdriscoll joined #evergreen |
| 09:05 |
|
misilot joined #evergreen |
| 09:07 |
|
kbeswick joined #evergreen |
| 09:08 |
|
Dyrcona joined #evergreen |
| 09:10 |
|
akilsdonk joined #evergreen |
| 09:13 |
|
akilsdonk joined #evergreen |
| 09:15 |
|
RoganH joined #evergreen |
| 09:15 |
|
akilsdonk joined #evergreen |
| 09:16 |
|
akilsdonk joined #evergreen |
| 09:17 |
tsbere |
Quick question: Should a patron privacy issue on launchpad be marked as private and/or security? |
| 09:20 |
jeff |
to start, yes. |
| 09:21 |
jeff |
(purely imo) |
| 09:22 |
tsbere |
jeff: Security, or just private for now? |
| 09:23 |
Dyrcona |
On the upside, all the issues turning up related to this bug indicate the best fix is a complete rewrite of OpenILS::Appication::Circ and friends! |
| 09:23 |
Dyrcona |
This is also NOT the kind of thing the proposed automated testing would turn up. |
| 09:27 |
jeff |
tsbere: i'd recommend private security. we can worry about making some clear policy on what the difference is later. |
| 09:33 |
tsbere |
Well, for those who can see such things: https://bugs.launchpad.net/evergreen/+bug/1249367 |
| 09:33 |
pinesol_green |
tsbere: Error: malone bug 1249367 not found |
| 09:33 |
Dyrcona |
malone bug? |
| 09:34 |
* bshum |
shrugs |
| 09:34 |
bshum |
Who knows what that's all about |
| 09:35 |
Dyrcona |
"Sam?" "Yes, Woody?" "I'm a better actor than you." |
| 09:35 |
bshum |
Hmm |
| 09:35 |
bshum |
Must be what the bugtracker plugin defaults to: http://launchpad.readthedocs.org/en/latest/malone.html |
| 09:35 |
|
misilot left #evergreen |
| 09:44 |
|
mllewellyn joined #evergreen |
| 09:44 |
|
collum joined #evergreen |
| 09:56 |
jeff |
ah yes, that moment when you stand looking at a reasonable set of sql functions, and are considering just how messy they're going to look after implementing the "if a copy has this stat cat set to this value, make it appear as this virtual circ_lib in the export" |
| 09:58 |
phasefx_ |
:-( |
| 09:59 |
jeff |
it's that line between "dirty hack" and "full-featured framework for making this thing possible in a way suitable for others" |
| 10:00 |
phasefx_ |
try to keep the reasonable sql and make a wrapper/decorator function? |
| 10:01 |
Dyrcona |
Throw in an Adapter and a Visitor, because you can never have too many patterns. |
| 10:02 |
phasefx_ |
or salesmen |
| 10:02 |
Dyrcona |
Then you need a Factory because it just isn't reusable OO without at least a dozen Factories and FacotryFactories! |
| 10:02 |
Dyrcona |
@blame fingers |
| 10:02 |
pinesol_green |
Dyrcona: Your failure is now complete, fingers. |
| 10:03 |
Dyrcona |
That's about right. :) |
| 10:03 |
Dyrcona |
thank you, pinesol_green. |
| 10:03 |
* phasefx_ |
implements some stored procedures in java for good measure |
| 10:03 |
Dyrcona |
pljava! |
| 10:03 |
phasefx_ |
plcalgon |
| 10:03 |
Dyrcona |
plpilsner! ;) |
| 10:04 |
bshum |
dbwells: The thing I'm checking for in a bit is the upgrade SQL that was included in the 2.5.0.tar.gz; I noticed that it was marked 2.4.3-2.5.0 upgrade (and there isn't a 2.4.3 yet) Or rather, we're also missing the 2.4.2-2.4.3 upgrade SQL from the repos and the tarball |
| 10:05 |
Dyrcona |
bshum++ # for checking scripts he'll never run. |
| 10:05 |
phasefx_ |
Dyrcona: pl1554 :) |
| 10:05 |
Dyrcona |
phasefx_: plUrquell |
| 10:06 |
phasefx_ |
will have to try that |
| 10:07 |
dbwells |
bshum: 2.4.3 came out a few weeks ago. The upgrade script is in the tagged branch (and presumably in the release tarball for that release): http://git.evergreen-ils.org/?p=Evergreen.git;a=shortlog;h=refs/heads/tags/rel_2_4_3 |
| 10:07 |
jeff |
When all you have is a java general-purpose tool-building factory factory factory, everything looks like an AbstractAbstractNailImpl? |
| 10:07 |
bshum |
dbwells: Gotcha, I think we just need to forward port that to master and rel_2_5 then |
| 10:07 |
jeff |
(alas, i don't actually know enough java nomenclature to make that joke particularly accurate) |
| 10:08 |
Dyrcona |
jeff: You hit the nail on the head. :) |
| 10:09 |
jeff |
heavily inspired by http://discuss.joelonsoftware.com/?joel.3.219431.12 |
| 10:10 |
* bshum |
will be back a little later |
| 10:13 |
dbwells |
bshum: yeah, I'm not sure I understand the pros and cons of putting all those upgrade scripts in master, but if we want to continue that practice, we might as well throw in the 2.3.11 upgrade script as well. Or maybe our goal would be a single linear history in master (which would mean including 2.4.2-2.4.3, but not all the 2.3.x scripts which came post 2.4. I'd support that, FWIW. |
| 10:13 |
berick |
Dyrcona: wondering if you can check my logic.. looking at LP 1198465 and want to add a "clear negative balance" option. i need to 1) delete the existing void-payment and 2) apply a new void-payment equal to the remaining balance on the xact? For example.. |
| 10:13 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 7, heat: 24) [Wishlist,In progress] https://launchpad.net/bugs/1198465 - Assigned to Jason Stephenson (jstephenson) |
| 10:13 |
berick |
patron billed 20, patron paid 10, 20 billing "voided" (i.e. void-payment of 20 created), patron is now owed 10. |
| 10:14 |
berick |
i need to delete the $20 void-payment, then add a $10 void-payment? |
| 10:14 |
berick |
to result in a balance_owed of 0 |
| 10:14 |
jeff |
i implemented that as "don't over-void in the first place" |
| 10:14 |
Dyrcona |
berick: have you looked at my branch? |
| 10:14 |
berick |
Dyrcona: i have |
| 10:14 |
jeff |
though in our case it's "forgive", since we're on 2.2 and void-as-payment-type doesn't exist there. |
| 10:15 |
berick |
i won't say it's all digested, though |
| 10:15 |
Dyrcona |
jeff: void-as-payment-type doesn't exist outside of the branch. |
| 10:15 |
jeff |
right. |
| 10:15 |
jeff |
oversimplification on my part. |
| 10:15 |
berick |
also, imagine a legacy billing w/ a negative balance |
| 10:15 |
berick |
s/billing/xact/ |
| 10:16 |
Dyrcona |
berick: My suggestion: Get all the libraries to stop charging fines. |
| 10:16 |
berick |
problem solved! ;) |
| 10:16 |
jeff |
when we "un-void", we do the math on how much we forgave, and re-bill a single billing for that amount. |
| 10:16 |
Dyrcona |
jeff: That is pretty much what my branch attempts to do. |
| 10:17 |
Dyrcona |
Billing ought to be simple, but it isn't because staff get up to some pretty fucked scenarios with voiding and unvoiding and so on ad nauseum. |
| 10:17 |
jeff |
so, 10 overdue billings, a cash payment, a forgive (poor man's partial void) for the rest, then a lost item billing, then the lost item is returned, another forgive for the lost amount, and a re-bill of the forgiven overdues amount to "un-void" the unpaid overdues. |
| 10:18 |
jeff |
i filled a whiteboard or two with this a while back. it was "fun". |
| 10:18 |
* Dyrcona |
gives jeff a lollipop. :) |
| 10:19 |
jeff |
in bringing mmpbbt back out of the freezer, i'm considering how we can test billing things. probably starting with finding some clean and some pathological examples from our live data for mmpbbt itself. hope to learn something that can be applied elsewhere. |
| 10:21 |
RoganH |
Billing is simple. I didn't give staff forgive or void permissions. |
| 10:21 |
dbwells |
When it comes to the fines situation in EG, I think we could benefit from some more careful semantics. We can't really solve problems until we are talking about the same things. |
| 10:22 |
Dyrcona |
RoganH: Lucky you. Ours would kill us if we didn't. |
| 10:22 |
jeff |
dbwells: standardizing terminology and expectations and such, yes. |
| 10:22 |
RoganH |
Only a few managers have forgive permissions and they know they can be held accountable and no one has void (except me). |
| 10:22 |
Dyrcona |
dbwells: When it comes to fines, just remove it from Evergreen, and say, we don't do fines. |
| 10:23 |
jeff |
dbwells: i was thinking that this would likely be necessary for testing as well, since if you and i define "correct behavior" differently, my tests will not match your expectations. |
| 10:23 |
dbwells |
For instance, I would say that any system which allows "partial voids" is a path to madness. Not that we don't need something *like* that, but shouldn't void mean "void" (aka, it never happened)? |
| 10:23 |
Dyrcona |
I would now like to point to something Edsger Djikstra said about testing, but you can Google it yourself. |
| 10:24 |
jeff |
dbwells: right. better "written off", etc. |
| 10:25 |
dbwells |
jeff: exactly! |
| 10:25 |
jeff |
but if you bill someone overdue fines, then you make those fines no longer due, is that the same as "voided, never happened"? hard line to draw. |
| 10:25 |
jeff |
but this is something that will become increasingly more important to lay out and agree on. |
| 10:26 |
Dyrcona |
dbwells jeff: So, I'll just outsource the contract to you guys. |
| 10:26 |
jeff |
heh |
| 10:27 |
dbwells |
IANAA, but in accounting systems I've used, I could only ever avoid the last "event" in a transaction. Once another event happens, the first is history, and should never be changed. Hence the invention of the "credit memo" :) |
| 10:27 |
dbwells |
s/avoid/void/ |
| 10:27 |
Dyrcona |
dbwells: Evergreen is not accounting software, and I don't think you really want to go there. |
| 10:29 |
|
dbs_mob joined #evergreen |
| 10:29 |
dbs_mob |
dbwells: https://bugs.launchpad.net/bugs/894052 for brief rationale on upgrade scripts |
| 10:29 |
pinesol_green |
Launchpad bug 894052 in Evergreen "Point-to-point version upgrade scripts should be kept in master and backported through applicable releases" (affected: 1, heat: 6) [Undecided,Fix released] - Assigned to Mike Rylander (mrylander) |
| 10:30 |
Dyrcona |
One thing that makes billing so tricky is that payments are not linked to individual bills, but to transactions. |
| 10:30 |
dbwells |
Dyrcona: I have looked at your branch a bit, and I think it is on the right track, especially since it simplifies things. I am just suggesting we establish some basic principles, then follow them. |
| 10:31 |
Dyrcona |
dbwells: I agree on agreeing on terminology. |
| 10:31 |
Dyrcona |
Bills aren't really bills, for instance. They seem more like "line items" on a bill to me. |
| 10:31 |
jeff |
billings. |
| 10:32 |
dbwells |
dbs_mob: thanks, I'll check it out! |
| 10:32 |
jeff |
yeah, in my mind in an evergreen context, bills == billings == billing line items |
| 10:32 |
Dyrcona |
billing/bill: same thing really. there is no "bill" in Evergreen. |
| 10:33 |
jeff |
part of the lost_avoid_voids work was an effort to not change the history of what money in a payment should be credited towards what billing line item -- to have a linear progression, rather than a "this billing line item was voided after being paid, then it was unvoided..." |
| 10:33 |
jeff |
we avoided the unvoiding process/logic and replaced it with re-billing. |
| 10:34 |
|
rfrasur joined #evergreen |
| 10:35 |
Dyrcona |
jeff: My branch does the same in a slighty more tricky form. |
| 10:35 |
Dyrcona |
It was inspired by your work, and you get a mention in the comments. :) |
| 10:36 |
jeff |
thanks. :-) |
| 10:36 |
Dyrcona |
http://git.mvlcstaff.org/?p=jason/ILS.git;a=shortlog;h=refs/heads/Bill_01-Conditional-Negative-Balances |
| 10:37 |
dbwells |
jeff: I think linear progression is a prime principle for accounting information, so that makes two of us, anyway. |
| 10:37 |
Dyrcona |
It also embodies something that I think should happen with more of the circ code: It makes heavy use of *Common.pm and library functions to handle the heavy lifting. |
| 10:38 |
Dyrcona |
I found at least two places doing voids in slightly different ways in the original code. |
| 10:38 |
rfrasur |
(oy...when you realize that Dropbox hasn't been syncing on this computer for two weeks) |
| 10:39 |
jeff |
rfrasur: fun. hopefully that machine's backups were running okay during that time? |
| 10:39 |
rfrasur |
yeah, they were...and I use Google Drive just as much anyway, so it was just a fewish files. |
| 10:40 |
rfrasur |
just stupid on my part. |
| 10:42 |
rfrasur |
well, it's fixing...so, that's good. |
| 10:42 |
dbwells |
dbs: the rationale in bug 894052 makes a lot of sense, thanks again |
| 10:42 |
pinesol_green |
Launchpad bug 894052 in Evergreen "Point-to-point version upgrade scripts should be kept in master and backported through applicable releases" (affected: 1, heat: 6) [Undecided,Fix released] https://launchpad.net/bugs/894052 - Assigned to Mike Rylander (mrylander) |
| 10:43 |
* Dyrcona |
loves it when the ownCloud desktop sync program just dies for no apparent reason. |
| 10:45 |
remingtron |
bshum: FYI, http://open-ils.org/ doesn't seem to display the social links in the header. |
| 10:46 |
remingtron |
bshum: same thing in the footer |
| 10:50 |
|
kbeswick joined #evergreen |
| 10:50 |
jeff |
remingtron: seems to work here. |
| 10:51 |
dbwells |
jeff: bet you didn't check Firefox! ;) |
| 10:53 |
jeff |
ah. bet it's the web font / woff file tripping up a cross-domain/origin check. |
| 10:54 |
dbwells |
that sounds like good thinking to me |
| 10:59 |
jeff |
SIP and standing penalties... if a user has reached max items out, that's a circ block, and sets "charge privileges denied" in the patron status fixed field. |
| 11:00 |
jeff |
setting that vs setting "too many items charged" is one debate. |
| 11:00 |
jeff |
our self checkout terminals turn the patron away if "charge privileges denied" is set. |
| 11:01 |
jeff |
which means patrons can't do other things, like renewals. |
| 11:01 |
jeff |
i suppose this comes down to a workaround for one device's behavior. |
| 11:01 |
Dyrcona |
Well, it's debatable if you want them renewing in that situation, and I believe there is/was a bug where renewal fails anyway if a patron hits that limit. |
| 11:01 |
jeff |
sal_: how do you guys react to "charge privileges denied" vs "renewal privileges denied" vs "too many items charged"? |
| 11:02 |
jeff |
i also find myself wondering what in the world "too many items renewed" is. :P |
| 11:02 |
Dyrcona |
It's a SIP field.... |
| 11:02 |
Dyrcona |
;) |
| 11:02 |
berick |
Dyrcona: fyi @ bug 1249398 |
| 11:02 |
pinesol_green |
Launchpad bug 1249398 in Evergreen "Clear negative balance billing option" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1249398 - Assigned to Bill Erickson (erickson-esilibrary) |
| 11:03 |
Dyrcona |
jeff: I have seen some SIP vendors who treat any of the fields having one of the blocks fields set as meaning, they're blocked and can't do anything. |
| 11:03 |
Dyrcona |
Granted, I don't think these were selfchecks. |
| 11:03 |
Dyrcona |
berick++ |
| 11:05 |
bshum |
remingtron: That issue just makes me really want to add the final nail to the coffin that is open-ils.org and setup a redirect from open-ils.org to the proper evergreen-ils.org |
| 11:08 |
Dyrcona |
bshum: They have the same IP address. Are they not configured in the same virtual host in Apache? |
| 11:08 |
bshum |
Dyrcona: Yeah, right now it's just a ServerAlias open-ils.org |
| 11:09 |
bshum |
I'm looking for some good examples of how to setup the redirect. (I'm rusty at this part of apache) |
| 11:09 |
bradl |
bshum: I'd +1 a redirect. I think it should have been done a while ago. |
| 11:10 |
Dyrcona |
bshum: Why is a redirect necessary? Is it because the font thing jeff mentions earlier? |
| 11:10 |
Dyrcona |
Seems to me if the links were all relative, the hostname wouldn't matter. |
| 11:11 |
* Dyrcona |
runs several domains all pointing at the same virtual host. |
| 11:11 |
bshum |
Dyrcona: Well, I expect that'll be dealt with in the change, but also, people get back to open-ils.org vs. evergreen-ils.org all the time. |
| 11:11 |
bshum |
Really, it's supposed to be evergreen-ils.org, just that we've let all the other ones (including the www.open-ils.org and www.evergreen-ils.org) live on |
| 11:11 |
Dyrcona |
bshum: I don't understand this part: "people get back to open-ils.org vs. evergreen-ils.org" |
| 11:12 |
Dyrcona |
I see. |
| 11:12 |
Dyrcona |
If open-ils.org should not exist, then simply remove it from the configuration and drop if from DNS. |
| 11:12 |
bshum |
I think people wanted it to continue existing because it's gotten eaten up over the years through all the linking etc. |
| 11:13 |
bshum |
Hence the thought of either leaving it be and functional any which way, or making it a proper redirect. |
| 11:13 |
Dyrcona |
Sites come and go all the time. Links die. It is the nature of the web. |
| 11:13 |
Dyrcona |
I think the redirect is more trouble than it is worth. |
| 11:13 |
Dyrcona |
It should work without a redirect, just make sure all the links are relative. |
| 11:14 |
bradl |
Dyrcona: what problems are you forseeing with an apache redirect? |
| 11:14 |
Dyrcona |
bradl: None. My point is why do it if it isn't necessary. |
| 11:15 |
Dyrcona |
If you want open-ils.org to go away. Then make it go away. |
| 11:15 |
Dyrcona |
I figure some of my bookmarks will break. It will affect me. Big deal. This stuff happens all the time. |
| 11:16 |
Dyrcona |
Anyway, we've probably wasted more time chatting about it than the problem is worth. Do what you will. |
| 11:20 |
jeff |
bshum: my recommendation is a virtualhost for the domains that should be redirected, optionally one for each if you care about them individually (or change their logging to include hostname). in that virtualhost block/blocks, Redirect permanent / http://evergreen-ils.org/ |
| 11:20 |
jeff |
bshum: you then have logging of things using the "old" hostnames |
| 11:20 |
jeff |
bshum: all domains go to the same place, including subpaths/etc |
| 11:20 |
bradl |
yeah, I'm in the non-napalm camp. at least in the morning. ;) |
| 11:20 |
Dyrcona |
heh. thought "All domains to heaven." |
| 11:20 |
Dyrcona |
gah... |
| 11:20 |
Dyrcona |
I quit |
| 11:21 |
Dyrcona |
I'm having typos today. |
| 11:21 |
jeff |
bshum: and google and other search engines see you as a single site (though i think either due to better detection or use of the correct setting in Google Webmaster Tools google has it figured out already for the domains in question) |
| 11:22 |
bshum |
jeff: I don't know, I added something that's redirecting open-ils.org, etc. to evergreen-ils.org |
| 11:22 |
bshum |
You can check my work if you feel like looking at the config. |
| 11:22 |
jeff |
sorry, thought you said you were looking for ideas. :-) |
| 11:23 |
bshum |
jeff: Sorry, yes I was. I'm not entirely sure about the logging side of things, but really I don't care about that aspect of it :) |
| 11:23 |
Dyrcona |
bshum: Have you reloaded the config, yte. |
| 11:23 |
Dyrcona |
yeti? |
| 11:23 |
Dyrcona |
:p |
| 11:23 |
bshum |
Dyrcona: Yes, I did. |
| 11:23 |
jeff |
bshum: looks reasonable from outward appearances. |
| 11:24 |
collum |
cyber heaven. I think a redirect is an indication to the user that old name may be going away, eventually. |
| 11:24 |
bshum |
With the way it's setup, the other hosts should stay the way they are, I think |
| 11:24 |
bshum |
Like irc.evergreen-ils.org, wiki.evergreen-ils.org, etc. |
| 11:24 |
bshum |
It's just open-ils.org, www.open-ils.org, and www.evergreen-ils.org that get reset to evergreen-ils.org |
| 11:25 |
jeff |
bshum: http://www.open-ils.org/robots.txt http://open-ils.org/robots.txt and http://www.evergreen-ils.org/robots.txt all 301 to http://evergreen-ils.org/robots.txt and that final url is 200 ok without a redirect (loop!) |
| 11:26 |
* dbwells |
sheds a tear for open-ils.org |
| 11:27 |
* Dyrcona |
sings "Don't Cry for me, Argentina" |
| 11:33 |
pinesol_green |
[evergreen|Dan Wells] Forward-port upgrade scripts from recent releases - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=92be8d6> |
| 11:37 |
jeff |
@later tell csharp PINES nagios may need to be updated to reference evergreen-ils.org -- not sure if the 301 it's getting will trip an alert or not. :-) |
| 11:37 |
pinesol_green |
jeff: The operation succeeded. |
| 11:37 |
* bshum |
smacks head on desk. |
| 12:12 |
|
akilsdonk_ joined #evergreen |
| 12:16 |
|
smyers_ joined #evergreen |
| 12:32 |
|
yboston joined #evergreen |
| 12:38 |
rfrasur |
meh - screaming baby for an hour (not crying...just screaming) and closing employee calls in sick. |
| 12:40 |
rfrasur |
hmm, and I missed Dyrcona channeling Evita |
| 12:40 |
rfrasur |
On the bright side, I get to finally weed the last of the Left Behind series. |
| 12:47 |
rfrasur |
jboyer-isl++ #it works |
| 12:47 |
|
mcooper joined #evergreen |
| 12:48 |
|
linuxhiker joined #evergreen |
| 12:48 |
linuxhiker |
Howdy folks, anyone ever seen this?? Can't locate object method "has_a" via package "actor::user" (perhaps you forgot to load "actor::user"?) at /usr/lib/perl5/site_perl/5.8.8/OpenILS/Application/Storage/CDBI.pm line 433. |
| 12:50 |
jeff |
linuxhiker: more context would be helpful -- when/where are you encountering this? |
| 12:51 |
bshum |
Also, 5.8.8? Yeesh |
| 12:52 |
linuxhiker |
bshum: centos5.10 :P |
| 12:52 |
linuxhiker |
jeff: good question, I am checking, I was just given the file to test, I believe it is on load (we are getting an 550 from the website) |
| 12:54 |
Dyrcona |
Fieldmapper isn't loaded or properly inited. Usually because the OpenILS::System->bootstrap failed. Usually because it can't find or was not given the bootstrap config. <- Just a wild guess. |
| 12:54 |
Dyrcona |
;) |
| 13:39 |
linuxhiker |
when running autogen.sh I am getting: Session Error: router apache05-priv/opensrf.settings IS NOT CONNECTED TO THE NETWORK!!! |
| 13:39 |
linuxhiker |
any thoughts? |
| 13:40 |
jeff |
you probably have an earlier error from opensrf.settings failing to start, or dying. |
| 13:40 |
jeff |
(check logs) |
| 13:40 |
jeff |
or, alternately -- services were not started to begin with. |
| 13:41 |
jeff |
or you're dealing with a lostlhost-vs-hostname issue. |
| 13:41 |
* tsbere |
finds the concept of a lostlhost interesting - Is that a lost localhost? ;) |
| 13:42 |
jeff |
heh |
| 13:42 |
jeff |
localhost is indeed what i intended to type. :-) |
| 13:42 |
linuxhiker |
jeff: stupid me... I didn't realize that services had to be running to run autogen.... it runs now. Ty |
| 13:43 |
jeff |
linuxhiker: 'welcome! |
| 14:14 |
sseng |
there's an api for retrieving an auth record (open-ils.cat.authority.record.retrieve). I've been trying to call this api via the opensrf shell with no success. my call: request open-ils.cat open-ils.cat.authority.record.retrieve "93b7b6fbf37cea3fa02c0f1eda27eb52",1,{} . I get the error "Can't locate object method "retrieve_authority_record" via package "OpenILS::Utils::CStoreEditor" at /usr/local/share/perl/5.14. |
| 14:14 |
sseng |
2/OpenILS/Application/Cat/Authority.pm line 153." |
| 14:14 |
sseng |
on line 153, there's a call "my $rec = $e->retrieve_authority_record($rec_id) or return $e->event;" |
| 14:15 |
sseng |
could it be that the call needs to be $e->retrieve_authority_record_entry(_) instead of $e->retrieve_authority_record(_) ? |
| 14:17 |
berick |
for fun, document your api call signature => {return {stuff}} instead of {return => {stuff}} and spend several minutes wondering why your call isn't published. |
| 14:17 |
berick |
sseng: yep, that's probably it |
| 14:17 |
jeff |
berick: oops |
| 14:20 |
sseng |
berick: great, thanks, now can move on from trying different ways =) ! (if this is an erryr, this is in master, fyi) |
| 14:20 |
bshum |
parts-- |
| 14:20 |
bshum |
#just cause |
| 14:21 |
Dyrcona |
sseng: It's not an error. the proper way to do it is $e->retrieve_authority_record_entry(); |
| 14:22 |
berick |
Dyrcona: but it's doing $e->retrieve_authority_record() |
| 14:22 |
berick |
in 2 places, it seems |
| 14:22 |
sseng |
Dyrcona: got it : but in master, line 153 + 175 in file /usr/local/share/perl/5.14.2/OpenILS/Application/Cat/Authority.pm, it is the wrong way i think |
| 14:23 |
Dyrcona |
oh. I misunderstood. I thought you were writing your own script to do something. |
| 14:24 |
sseng |
Dyrcona: nope, just trying to learn to do some api calls, and got stuck on that one =) |
| 14:24 |
Dyrcona |
Ah, I see what you were asking.... I usually use CStoreEditor and bypass the other calls. |
| 14:26 |
bshum |
So I'm thinking of dropping the rule protecting bib deletion and then really deleting a bunch of old bibs from past (failed) migration work. |
| 14:26 |
bshum |
Other than asset.call_number, biblio.monograph_part, metabib.* |
| 14:26 |
bshum |
Can anyone else think of any other tables I should check for referencing back to biblio.record_entry? |
| 14:27 |
Dyrcona |
sseng berick: That, I would say, is a bug. ;) |
| 14:27 |
sseng |
Dyrcona: berick: should i put a ticket in? |
| 14:27 |
Dyrcona |
sseng: Yes, please. |
| 14:27 |
sseng |
Dyrcona: great, going to do that now, thanks! |
| 14:27 |
berick |
sseng++ |
| 14:28 |
Dyrcona |
I'll take a look and add a branch to fix it. |
| 14:28 |
Dyrcona |
unless berick wants to. |
| 14:30 |
berick |
not at the moment, no |
| 14:30 |
Dyrcona |
that bug has been there sine 2008. |
| 14:30 |
berick |
nice |
| 14:30 |
Dyrcona |
since, even... |
| 14:32 |
sseng |
berick: Dyrcona: bug submitted (https://bugs.launchpad.net/evergreen/+bug/1249476) |
| 14:32 |
pinesol_green |
Launchpad bug 1249476 in Evergreen "Api to retrieve an authority record not working" (affected: 1, heat: 6) [Undecided,New] |
| 14:33 |
Dyrcona |
Ok. I'll make a branch that you and anyone else can test. I'll throw it on my dev server, too. |
| 14:33 |
sseng |
Dyrcona: great, thanks!! |
| 14:34 |
Dyrcona |
sseng++ |
| 14:42 |
|
gsams joined #evergreen |
| 14:43 |
mceraso |
dbwells: Just did a clean installation of 2.5.0 and it worked |
| 14:44 |
jeff |
mceraso++ thanks for testing! |
| 14:44 |
mceraso |
dbwells: using Ubuntu 12.04 |
| 14:45 |
bshum |
mceraso++ |
| 14:45 |
dbwells |
mceraso++ # thanks so much! |
| 14:50 |
rfrasur |
I'm a fan of asking forgiveness unless it comes with a really big fine. |
| 14:50 |
rfrasur |
well...or a small fine. |
| 14:51 |
Dyrcona |
It is often easier to ask forgiveness than to ask for permission. |
| 14:51 |
rfrasur |
in other news...teaching 5th grades how to find stuff in the library reminds me that I like being a librarian. |
| 14:52 |
Dyrcona |
In Evergreen news...trying to naively parallelize a bib reingest with fork() doesn't work. |
| 14:53 |
rfrasur |
(does the attempt to parallelize paralyze?) |
| 14:54 |
Dyrcona |
No, it fails with duplicate key values in browse_entry_sort_value_value_key at apparently random intervals. |
| 14:54 |
rfrasur |
oh |
| 14:55 |
Dyrcona |
Probably two batches updating related records simultaneously. |
| 14:55 |
Dyrcona |
So, it depends entirely on timing. |
| 14:55 |
eeevil |
sseng: the scrollback is dense, so ignore if you already got this answer, but I'd suggest open-ils.pcrud for authority record retrieval, since you have an auth token handy |
| 14:56 |
eeevil |
Dyrcona: yeah, I recommend disabling browse ingest on the first (parallel) run, and then doing browse-only re-ingest. "there's a flag for that!" (in 2.5+) |
| 14:57 |
sseng |
eeevil: am working way through some api calls via opensrf, will check that out, thanks!! |
| 14:57 |
Dyrcona |
eeevil: So, don't do browse-only reingest in parallel? |
| 14:58 |
jeff |
dear pg_restore: can we pretend that i remembered to remove the auditor table data from the toc before starting you? |
| 14:58 |
eeevil |
Dyrcona: right. that part is much faster anyway, and least critical for having a working system (IMO, anyway) |
| 14:58 |
Dyrcona |
eeevil: Thanks for the tip. I'll try that. |
| 15:04 |
eeevil |
np |
| 15:07 |
Dyrcona |
sseng: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1249476_fix_open-ils.cat.authority.record.retrieve |
| 15:08 |
|
krvmga_ joined #evergreen |
| 15:08 |
|
kbeswick joined #evergreen |
| 15:11 |
|
mjingle joined #evergreen |
| 15:15 |
jeff |
tsbere: you had a branch a while back that included dns-based validation of email addresses -- did that ever get a wishlist bug or rolled into master? |
| 15:15 |
jeff |
tsbere: and have you ever used it in production? |
| 15:16 |
tsbere |
jeff: I did the OpenSRF side, I think, but have not yet had time to make Evergreen use it |
| 15:19 |
jeff |
tsbere: did you have a working branch? |
| 15:19 |
jeff |
i'm not finding it in a few quick greps. |
| 15:19 |
jeff |
though perhaps it was entirely an opensrf service and thus in that repo. |
| 15:19 |
tsbere |
jeff: Not on the Evergreen side. The OpenSRF side it is in master. src/perl/lib/OpenSRF/Application/Validator.pm and such |
| 15:21 |
jeff |
thanks! |
| 15:21 |
tsbere |
jeff: I think I lost steam when I went through a pile of hoops to try and figure out how to make a mailing address validator, only to come up with "tis a PITA and would cost too much money to get the data I would need" >_> |
| 15:22 |
jeff |
yeah. i've at least one api that does free address validation, but i suspect that they would tire of validation with no mailings. :P |
| 15:23 |
jeff |
i have a local street index which could be handy for a number of things, but the format is a little wacky, and i don't know if other counties have this kind of thing usually available in this form. |
| 15:38 |
|
stevenyvr2 joined #evergreen |
| 15:40 |
* jeff |
waits to see if he has search path issues on index creation |
| 15:41 |
|
jecs joined #evergreen |
| 15:56 |
|
kbeswick joined #evergreen |
| 16:01 |
|
jecs1 joined #evergreen |
| 16:01 |
|
DPearl joined #evergreen |
| 16:08 |
|
kbeswick joined #evergreen |
| 16:19 |
Dyrcona |
Ha ha! |
| 16:20 |
Dyrcona |
Um... Sort of wrong window.... I meant to delete that. |
| 16:20 |
|
kbeswick joined #evergreen |
| 16:20 |
jeff |
hah |
| 16:20 |
Dyrcona |
But. I do have a mad scheme to do my ingesting entirely in parallel... |
| 16:21 |
Dyrcona |
One forked process doing all of the records with browse ingest, and then several forked processes doing the other reingests in groups of 10 000 records! |
| 16:21 |
Dyrcona |
Let the madness commence! |
| 16:23 |
Callender |
dbwells: Just FYI, I've loaded 2.5.0 onto our public demo box, login information here (http://evergreen-ils.org/dokuwiki/doku.php?id=community_servers) and ran it through a lot of random tests and everything is looking good to me |
| 16:24 |
dbwells |
Callender++ # awesome, thanks! |
| 16:56 |
|
linuxhiker joined #evergreen |
| 16:58 |
|
mdriscoll left #evergreen |
| 16:59 |
|
jecs1 left #evergreen |
| 17:11 |
|
kbeswick joined #evergreen |
| 17:16 |
|
linuxhiker1 joined #evergreen |
| 17:22 |
pinesol_green |
[evergreen|Dan Wells] TPAC: Remove fixed height from 'View My List' button - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4120328> |
| 17:28 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] Acq: Improvements to account-matching incoming EDI messages - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2462d7f> |
| 17:35 |
|
mcooper joined #evergreen |
| 17:43 |
|
TominMichigan joined #evergreen |
| 17:44 |
bshum |
dbwells++ # happy 2.5.0! |
| 17:45 |
TominMichigan |
Hi. Is there anyone here who can help me troubleshoot an error when I try to launch autogen.sh ? |
| 17:46 |
bshum |
TominMichigan: It's Friday evening in the east coast of US, and many folks might no longer be around. |
| 17:46 |
bshum |
I'm wandering off momentarily myself. |
| 17:47 |
TominMichigan |
bshum: I thought that might be the case but thought I'd reach out in case someone was around. |
| 17:47 |
bshum |
But what seems to be your error? |
| 17:47 |
TominMichigan |
bshum: everything seems to be running OK, until I run the autogen. I get an error message, and then I can't connect to opensrf |
| 17:48 |
TominMichigan |
The error message is: Exception: OpenSRF::EX::Session 2013-11-08T22:46:10 OpenILS::Utils::Cronscript /usr/local/share/perl/5.14.2/OpenILS/Utils/Cronscript.pm:276 Session Error: routerprivate.localhost/opensrf.settings IS NOT CONNECTED TO THE NETWORK!!! |
| 17:50 |
bshum |
TominMichigan: That error message definitely sounds like your open-ils services aren't working correctly. |
| 17:50 |
bshum |
Couple things to check: |
| 17:50 |
bshum |
Look at your logs to see if there's any obvious error |
| 17:50 |
bshum |
Another thing is to try stopping open-ils services, then starting them again |
| 17:50 |
|
dMiller joined #evergreen |
| 17:50 |
TominMichigan |
bsum: I did, but I don't see anything obvious. |
| 17:51 |
bshum |
I haven't done this in awhile, but does the settings-tester script give you anything? |
| 17:52 |
TominMichigan |
I get the same error when testing. If I run the script before autogen, it seems to come through clean. But if I run it after that, then the opensrf tests fail. |
| 17:53 |
bshum |
That's... weird sounding. |
| 17:54 |
dbwells |
TominMichigan: after restarting all services, are you able to do the srfsh login test in the install doc? |
| 17:54 |
TominMichigan |
dbwells: sometimes. |
| 17:55 |
TominMichigan |
I can't figure out when it fails. Like right now, I can to srfsh, but I get a received no data from server error when I do the math test. |
| 17:55 |
TominMichigan |
Other times when I've tried, I get a completely different error and srfsh doesn't launch at all. Unfortunately, I didn't copy that error message. |
| 17:56 |
dbwells |
TominMichigan: I am not sure if the math service runs after Evergreen is installed, since it sets up its own services (the math one is just for testing OpenSRF). |
| 17:56 |
TominMichigan |
dbwells: the login test comes back with Received no data from server |
| 17:57 |
TominMichigan |
dbwells: that's insteresting. I think it works after a fresh reboot. I'm going to try that to see if I'm chasing my tail with the math test. |
| 17:58 |
TominMichigan |
dbwells: I know it's late ... don't let me keep if you want to go. I can come back here on Monday. |
| 17:58 |
dbwells |
TominMichigan: it looks like the 'math' service is in the Evergreen default configs too, so that should be working for you. |
| 18:00 |
TominMichigan |
dbwells: I'm double-checking now that the math works on a fresh restart. |
| 18:00 |
dbwells |
How much memory is on this test box? |
| 18:00 |
TominMichigan |
1G |
| 18:00 |
bshum |
1 G is too low |
| 18:00 |
bshum |
You probably need at least 2 GB |
| 18:00 |
bshum |
It's likely that it's sacrificing services as you keep starting off new things. |
| 18:00 |
bshum |
Well, that's happened to other people before that is. |
| 18:02 |
TominMichigan |
bshum: that's a good point. The documentation lists 1G as the minimum, I guess it didn't cross my mind that it's on the way too low end of minimum. I may try upgrading my RAM. What would you say is the realistic minimum for Ubuntu Precise? |
| 18:03 |
TominMichigan |
Keep in mind this is just a sandbox for me, so there won't be much user load on it. |
| 18:03 |
bshum |
I would start with at least 2 GB still. |
| 18:03 |
bshum |
For my own purposes, I tend to play higher, but my laptops have more to play with :D |
| 18:04 |
bshum |
TominMichigan: Assuming by documentation you might mean this page? http://evergreen-ils.org/dokuwiki/doku.php?id=system_requirements |
| 18:04 |
TominMichigan |
bshum: OK. I'll start with allocating more RAM. Do you think another Linux distro would give me better results? |
| 18:04 |
bshum |
(if so, we really need to fix that) |
| 18:04 |
dbwells |
TominMichigan: I run 2GB on my main dev server, and don't hit any out of memory issues. |
| 18:04 |
TominMichigan |
bshum: I was looking here http://docs.evergreen-ils.org/2.4/_system_requirements.html#_server_minimum_requirements |
| 18:04 |
bshum |
TominMichigan: Ubuntu Precise and Debian Squeeze or Wheezy are your best bets. |
| 18:05 |
bshum |
Fwiw, we use Ubuntu Precise at our site. |
| 18:05 |
bshum |
So I feel comfortable recommending that to you :D |
| 18:05 |
TominMichigan |
OK. I'll stick with Precise on a better-configured machine. Wish me luck. And thank you both for your help. |
| 18:05 |
dbwells |
TominMichigan: two more thoughts, then I need to run. |
| 18:05 |
TominMichigan |
Good. I'm most familiar with Ubuntu, but would be willing to give Debian a try. |
| 18:06 |
bshum |
TominMichigan: Thanks, I'll poke at the varying docs later next week. It really should say 2 GB at this point, good to know that it doesn't... |
| 18:06 |
bshum |
And good luck! |
| 18:06 |
* bshum |
wanders off |
| 18:06 |
TominMichigan |
dbwells: Thanks, tell me your thoughts :) |
| 18:07 |
dbwells |
TominMichigan: 1) If you want to tinker and see if memory is the problem, you could try hacking away some services and see if you get more reliable results. I think it would mean just commenting some lines from the <activeapps> section in opensrf.xml, but that's without looking. |
| 18:08 |
bshum |
(also look at top to see what you're using) |
| 18:08 |
* bshum |
really wanders off |
| 18:08 |
TominMichigan |
dbwells: I could try that. Can you think of some services that would be worth cutting out as a test. |
| 18:08 |
dbwells |
e.g. Just run opensrf.settings and opensrf.math and see if the math service works every time, then maybe try the same with open-ils.auth for the login test. |
| 18:08 |
dbwells |
Evergreen won't work, obviously, but at least you would know the plumbing was in place correctly. |
| 18:09 |
TominMichigan |
dbwells: I'll try that. I'm going to reconfigure the server with more RAM, and then try commenting out services if I still have trouble. |
| 18:09 |
TominMichigan |
You've both been very helpful. Thanks for staying late to help me out |
| 18:11 |
dbwells |
dang, thought two was only half typed, oh well |
| 19:07 |
|
BigRig joined #evergreen |
| 19:31 |
|
mjingle left #evergreen |
| 19:42 |
|
hopkinsju joined #evergreen |
| 19:43 |
hopkinsju |
Hi guys. Anyone around that can clue me in as to how EG chooses a copy to fulfill a hold? Assuming all possible sources are the same distance from the requesting lib how does it pick a copy? |
| 20:01 |
|
smyers_ joined #evergreen |
| 20:13 |
|
stevenyvr2 left #evergreen |
| 20:19 |
|
smyers_ joined #evergreen |
| 20:47 |
|
linuxhiker joined #evergreen |
| 23:00 |
|
kbeswick joined #evergreen |
| 23:19 |
jeff |
schema diffing. whee! |
| 23:23 |
|
smyers__ joined #evergreen |
| 23:25 |
|
hopkinsju joined #evergreen |
| 23:27 |
|
hopkinsju left #evergreen |
| 23:30 |
|
stevenyvr2 joined #evergreen |
| 23:31 |
|
stevenyvr2 left #evergreen |
