| Time |
Nick |
Message |
| 00:41 |
|
Bmagic007 joined #evergreen |
| 00:43 |
|
mtj_- joined #evergreen |
| 00:45 |
|
jcamins_ joined #evergreen |
| 00:52 |
bshum |
@coin |
| 00:52 |
pinesol_green |
bshum: heads |
| 01:12 |
|
b_bonner_ joined #evergreen |
| 01:18 |
|
gmcharlt joined #evergreen |
| 01:25 |
|
b_bonner joined #evergreen |
| 01:25 |
|
mtcarlson_away joined #evergreen |
| 01:36 |
|
Mark__T joined #evergreen |
| 02:21 |
|
artunit joined #evergreen |
| 02:22 |
|
artunit_ joined #evergreen |
| 06:23 |
|
smyers_ joined #evergreen |
| 06:43 |
|
artunit joined #evergreen |
| 06:50 |
|
mrpeters joined #evergreen |
| 07:02 |
|
timlaptop joined #evergreen |
| 07:07 |
|
RBecker joined #evergreen |
| 07:36 |
|
RBecker joined #evergreen |
| 07:41 |
smyers_ |
good morning evergreen I have a problem getting marc records to view properly in the staff client |
| 07:42 |
smyers_ |
method=open-ils.cat.biblio.record.metadata.retrieve.authoritative |
| 07:42 |
smyers_ |
params=["037d85cae8a55edda566136f7a23044f",["712961"]] |
| 07:42 |
smyers_ |
THROWN: |
| 07:42 |
smyers_ |
{"payload":[],"debug":"osrfServerError : Internal Server Error\nCan't locate object method \"method_lookup\" via package \"OpenILS::Application::Cat\" at |
| 07:42 |
smyers_ |
/usr/lib/perl5/site_perl/5.8.8/OpenSRF/Application.pm line 154.\n","status":500} |
| 07:42 |
smyers_ |
STATUS: |
| 07:42 |
smyers_ |
anybody seen that before? |
| 07:43 |
csharp |
smyers_: anything in the logs that corresponds to that? |
| 07:43 |
smyers_ |
csharp: no |
| 07:43 |
smyers_ |
nothing in the error log and opensrf log |
| 07:44 |
smyers_ |
apache error log |
| 07:44 |
csharp |
what version of EG? |
| 07:44 |
smyers_ |
2.4 |
| 07:44 |
smyers_ |
fresh install on centos5.9 |
| 07:45 |
smyers_ |
everything else works but loading the top pane of the staff client marc view |
| 07:45 |
|
Dyrcona joined #evergreen |
| 07:47 |
Dyrcona |
Well, that's interesting. |
| 07:48 |
Dyrcona |
My script to find matching bibs ran 6x as fast in production as it did in my development environment. |
| 07:48 |
smyers_ |
if you ignor the first error you get a second one from js |
| 07:48 |
Dyrcona |
smyers_: That's typical, a cascade effect, the first is usually the only one that matters. |
| 07:48 |
csharp |
smyers_: could be an older-than-expected version of perl? (just spitballing here...) |
| 07:48 |
* Dyrcona |
should check logs. |
| 07:49 |
smyers_ |
csharp: problably as centos5.9 has lots of older-then-expected verision issues |
| 07:49 |
smyers_ |
csharp: any idea of which package or all of perl> |
| 07:49 |
dbwells |
csharp: c'mon, 5.8 is only 11 years old ;) |
| 07:49 |
Dyrcona |
WE DO NOT SUPPORT CENTOS HERE. YOU ARE ON YOUR OWN! |
| 07:49 |
csharp |
smyers_: any reason for using CentOS over Debian or Ubuntu (which are in use in most installations?)? |
| 07:50 |
csharp |
s/?)/)/g |
| 07:50 |
smyers_ |
csharp: yes subborness, I even offered bribes to get off centos |
| 07:50 |
Dyrcona |
Ok, to continue: But the statistics gathering script is taking longer than in development.....indexes probably. |
| 07:50 |
csharp |
heh - understood |
| 07:51 |
csharp |
Dyrcona: is this the new marc_export script? |
| 07:51 |
Dyrcona |
No, migration script. |
| 07:51 |
csharp |
ah |
| 07:51 |
Dyrcona |
Just weird behavior between production and development. |
| 07:51 |
* Dyrcona |
should have called in sick. |
| 07:51 |
* Dyrcona |
check IRC logs. |
| 07:51 |
csharp |
smyers_: so KCLS was on RHEL but consented to move to CentOS? |
| 07:52 |
smyers_ |
csharp: yes |
| 07:52 |
smyers_ |
csharp: was a simple move I want to get them to ubuntu or debian |
| 07:52 |
Dyrcona |
Well, that was stupid of them. |
| 07:52 |
smyers_ |
but that would mean a shutdown |
| 07:52 |
smyers_ |
at least I am getting them to 2.4 and closer to community code |
| 07:53 |
csharp |
smyers_: ah - so one of the issues is avoiding downtime? |
| 07:53 |
smyers_ |
csharp: yep |
| 07:53 |
Dyrcona |
There is a quote about that in pinesol_green. |
| 07:56 |
csharp |
smyers_: is any of the cluster virtualized? I ask because we've found that VMs are a good way to make changes with minimal downtime. |
| 07:57 |
csharp |
might be a way to demonstrate to the people who make OS decisions that it works just as well |
| 07:57 |
smyers_ |
csharp: I have made that recommendation as well. All our dev works from vms now it makes it easy to spin up and shutdown |
| 07:57 |
csharp |
right |
| 07:58 |
csharp |
@quote search downtime |
| 07:58 |
pinesol_green |
csharp: No matching quotes were found. |
| 07:58 |
csharp |
@quote random |
| 07:58 |
pinesol_green |
csharp: Quote #17: "* csharp hasn't smoked a good SIGPIPE since his college days" (added by gmcharlt at 12:33 PM, October 28, 2011) |
| 07:58 |
smyers_ |
either way back to the trouble at hand do you have anything specific that I might have missed? |
| 08:00 |
csharp |
smyers_: you might try to recreate the issue on a Debian or Ubuntu for Fedora platform? If you can't then that's a clue that the older Perl base may be the issue (you've probably thought of that, but just suggesting) |
| 08:02 |
* Dyrcona |
finds it amusing when an org. insists on using a distro with Evergreen that is a) not supported by the community, and b) know not to work with Evergreen. |
| 08:02 |
|
artunit joined #evergreen |
| 08:03 |
smyers_ |
I wish I could see the humor but now just frustrated with the task at hand |
| 08:04 |
csharp |
smyers_: for reference - Debian stable is on perl 5.14.2, as is Ubuntu 12.04 |
| 08:04 |
Dyrcona |
Install Debian, tell them it is CenOS. They probably won't know the difference. |
| 08:04 |
smyers_ |
lol |
| 08:04 |
Dyrcona |
You'll have to upgrade all the packages anyway, so it won't be CentOS any more. |
| 08:04 |
Dyrcona |
I would not waste time on it. I'd tell them it doesn't work on CentOS. |
| 08:05 |
csharp |
Dyrcona has a point - you might be able to make a case with your findings of what's not working? |
| 08:05 |
Dyrcona |
There's plenty of evidence in the IRC logs for that matter. |
| 08:08 |
Dyrcona |
If they insist on something from Red Hat land, the latest Fedora Core should work. |
| 08:09 |
dbwells |
smyers_: It is very odd that that's the only thing breaking, because I don't think there is anything particularly special about Cat.pm. It's just a perl services similar to about a dozen others. |
| 08:09 |
smyers_ |
dbwells: I agree it seems to be tied to opensrf |
| 08:10 |
csharp |
smyers_: I would also expect more messages in the logs - maybe up the log level in opensrf_core.xml? |
| 08:11 |
smyers_ |
csharp: will try give me a sec to roll the bricks |
| 08:11 |
csharp |
the front-end error messages are usually not very helpful in knowing what the actual error is |
| 08:11 |
Dyrcona |
We should just use Moden::Perl in every module, which forces you to have at least perl 5.10.1 installed. |
| 08:12 |
Dyrcona |
Gah! Can't type today. |
| 08:12 |
* Dyrcona |
really should have called in sick. |
| 08:17 |
smyers_ |
csharp: 2013-09-30 05:15:59 app1-staging open-ils.cat: [INFO:7526:Application.pm:152:1380543330104891] CALL: open-ils.cat open-ils.cat.biblio.record.metadata.retrieve.authoritative 90a622c7c261d1dffe37c1d4f849d3a9, ARRAY(0x6524500) |
| 08:17 |
smyers_ |
is the last call in the logs |
| 08:17 |
smyers_ |
silently fails after that |
| 08:18 |
csharp |
smyers_: you could try 'grep 1380543330104891 osrf<whatevertheactualfilenameis>.log' |
| 08:18 |
Dyrcona |
smyers_: The error you posted earlier suggests that OpenSRF itself is busted, since "method_lookup" fails. |
| 08:18 |
|
jboyer-isl joined #evergreen |
| 08:18 |
Dyrcona |
Either that or Cat is not registering properly. |
| 08:22 |
Dyrcona |
try "perl -cw /path/to/OpenILS/Application/Cat.pm" |
| 08:22 |
Dyrcona |
you'll probably get an error about a module it uses. |
| 08:22 |
csharp |
also, I think "ARRAY(0x6524500)" should actually be a record ID |
| 08:22 |
csharp |
lemme check my logs |
| 08:23 |
csharp |
nope I'm wrong |
| 08:23 |
Dyrcona |
charp: That call likely takes either an ID or an Object. |
| 08:24 |
csharp |
all of mine have similar entries with ARRAY(blah) |
| 08:24 |
Dyrcona |
yep. It's a bre object. |
| 08:25 |
Dyrcona |
Nope. it's a list of ids. |
| 08:26 |
Dyrcona |
I still think the problem is hidden in the creaky version of perl on CentOS |
| 08:26 |
|
collum joined #evergreen |
| 08:27 |
* csharp |
's searches of upgrade perl CentOS yielded sketchy results |
| 08:27 |
Dyrcona |
The upgrade is Fedora Core. |
| 08:27 |
Dyrcona |
If you want to run Evergreen on it. |
| 08:27 |
csharp |
I guess when you start upgrading system dependencies like perl, you lose all of the arguments for using CentOS in the first place |
| 08:28 |
smyers_ |
Dyrcona: I think you found it |
| 08:28 |
smyers_ |
Dyrcona: Cat.pm fails with can't locate try/tiny.pm |
| 08:29 |
|
akilsdonk_ joined #evergreen |
| 08:30 |
Dyrcona |
smyers_: You'll get the same error from OpenSRF/EX.pm, I'll bet. |
| 08:31 |
|
kbeswick joined #evergreen |
| 08:37 |
smyers_ |
Dyrcona: fixed the try tiny still have the same problem |
| 08:37 |
csharp |
same error? |
| 08:37 |
smyers_ |
EX.pm and cat.pm now have no syntax errors |
| 08:37 |
smyers_ |
yep |
| 08:38 |
smyers_ |
could this be opensrf2.2 |
| 08:39 |
smyers_ |
should I got back to opensrf 2.1 |
| 08:39 |
csharp |
smyers_: did you have trouble tracking down EG/OpenSRF dependencies for CentOS? |
| 08:39 |
smyers_ |
I used the extras install file |
| 08:39 |
csharp |
in my tinkering with centos in the past, I always got stuck |
| 08:43 |
bshum |
smyers_: Not that it helps, but normally it's important to be on the latest opensrf for a given Evergreen release. There's usually some new feature depending on something new in the latest of each. |
| 08:43 |
csharp |
smyers_: you cleared the cache on the staff client right? |
| 08:43 |
csharp |
just making sure |
| 08:44 |
csharp |
(probably won't help, but just ruling out static) |
| 08:46 |
smyers_ |
csharp: I had to get new memchaced and libmecached to get opensrf2.2 |
| 08:47 |
smyers_ |
and using cpans rpc-xml |
| 08:48 |
|
_bott_ joined #evergreen |
| 08:49 |
Dyrcona |
Upgrade to Fedora Core. It's the only way to be sure. |
| 08:49 |
smyers_ |
bricks rolled cache cleared same error |
| 08:50 |
|
kmlussier joined #evergreen |
| 08:52 |
|
mmorgan joined #evergreen |
| 08:57 |
csharp |
smyers_: maybe at least CentOS 6 would be better? I know your hands are probably tied on the OS choice :-/ |
| 09:03 |
Dyrcona |
If the customer says they're trying to be a part of the community, then why are they insisting on OS choices that buck community consensus? |
| 09:04 |
|
SimonHM joined #evergreen |
| 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:10 |
jeff |
Dyrcona: no, I agree with you that using a supported distribution of Linux is going to be a better approach, but that seems to have been stated earlier as not possible at this time. |
| 09:11 |
Dyrcona |
I don't buy that it is not possible. |
| 09:11 |
csharp |
having said that, we would probably only support CentOS 6+ |
| 09:11 |
bshum |
csharp: Yeah, well, it's nice to support lots of things. Just not something we're clearly all clammering to get on board :) |
| 09:12 |
csharp |
I agree |
| 09:12 |
Dyrcona |
smyers_: If you want to be CentOS maintainer for Evergreen, go ahead. Patches are always welcome. |
| 09:13 |
smyers_ |
Dyrcona: please don't suggest that, I want nothing more then to move off cnetos |
| 09:13 |
smyers_ |
centos |
| 09:15 |
smyers_ |
now that I read what you guys are saying Centos6 would be easy for Evergreen to add but I would not recommened it |
| 09:16 |
smyers_ |
I am | | close to getting centos 5.9 to work but that involved compiling several things from source |
| 09:17 |
smyers_ |
I bet the issue is I need to compile something else from source to get a newer version of somethign |
| 09:17 |
jeff |
If you're not interested in developing and maintaining support for CentOS (and if no one else is either), moving yourself away from CentOS is likely the best approach. Until that time, you're going to be facing the inherent burdens associated with trying to make software work on an unsupported platform. |
| 09:17 |
|
rfrasur joined #evergreen |
| 09:18 |
jeff |
Perl 5.8 is quite old, and it is likely that you're going to need at least Perl 5.10 to even have a chance at success. |
| 09:18 |
jeff |
I say "likely" there, because I haven't confirmed enough to state as fact. :-) |
| 09:18 |
Dyrcona |
jeff: I can very easily make perl 5.10 a requirement. :) |
| 09:19 |
Dyrcona |
Which it very likely is, though not documented anywhere. |
| 09:21 |
jeff |
Right, and if we know we're using features that are only available in Perl 5.10, I'd support a use statement in the libraries to that effect, which could be removed at some point in the future if someone contributed changes that had support for ancient perl versions. At some point, it's no longer productive to support something that old, unless you have specific reasons and resources to do so. |
| 09:21 |
* csharp |
has been looking around for min/max versions of deps since the beginning ;-) |
| 09:21 |
rfrasur |
jboyer-isl: is the cause of the memory leak known? |
| 09:22 |
jeff |
Perl 5.8 had a good run... it was first released in 2002. It might be time to let it go. :-) |
| 09:23 |
smyers_ |
I would agree it would give me more ammo for getting off centos5.9 |
| 09:23 |
jboyer-isl |
Some. Some of them are fixed, some aren't. Even 2.5 isn't completely perfect, but it's improved. |
| 09:23 |
Dyrcona |
rfrasur: Which memory leak? |
| 09:23 |
rfrasur |
Dyrcona: 2.4 |
| 09:23 |
rfrasur |
I dunno anything other than that |
| 09:24 |
csharp |
rfrasur: read the discussion on bug 1086458 for the status |
| 09:24 |
pinesol_green |
Launchpad bug 1086458 in Evergreen 2.4 "Staff client memory leaks in 2.3 and later" (affected: 10, heat: 70) [High,Triaged] https://launchpad.net/bugs/1086458 |
| 09:24 |
csharp |
https://bugs.launchpad.net/evergreen/+bug/1086458/comments/41 links to a report from development we've been funding |
| 09:25 |
jeff |
smyers_: If "CentOS is not a supported platform for running Evergreen" isn't enough to get you off CentOS, you may have some larger problems. :-) |
| 09:27 |
|
Dyrcona left #evergreen |
| 09:27 |
|
Dyrcona joined #evergreen |
| 09:27 |
smyers_ |
jeff: its an easier argument to talk perl verisions not being supported, we have been running an unsupported os for years now |
| 09:27 |
jeff |
smyers_: understood. |
| 09:28 |
rfrasur |
csharp: reading |
| 09:28 |
csharp |
rfrasur: there was a suspected leak around patron search, but that was proved not to be a leak after all when isolating that specific function |
| 09:29 |
* rfrasur |
suggests dishsoap for detecting leaks |
| 09:29 |
rfrasur |
still reading |
| 09:30 |
graced |
rfrasur: Equinox's report on the patron search "memory leak" is here if you're interested. http://nox.esilibrary.com/~jason/patron_search/patron_search.html |
| 09:30 |
rfrasur |
graced++ #thank you. |
| 09:31 |
graced |
no problem |
| 09:31 |
csharp |
smyers_: to that point, since the community devs tend to run Debian stable/Ubuntu LTS platforms, all of the dependencies will be newer than RHEL/CentOS 5 (and even 6) |
| 09:31 |
csharp |
and if you're slower than Debian, well... :-) |
| 09:32 |
csharp |
graced++ # thanks |
| 09:32 |
rfrasur |
Does this 2.3 stuff apply to 2.4 then? |
| 09:32 |
csharp |
rfrasur: yep |
| 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:20 |
|
gmcharlt joined #evergreen |
| 10:22 |
|
jbfink 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 |
| 11:29 |
|
ktomita_ joined #evergreen |
| 11:29 |
|
fparks joined #evergreen |
| 11:32 |
|
tspindler joined #evergreen |
| 11:47 |
rfrasur |
I just love hearing those few and far between patrons who insist that they're the victims of incompetent circulation staff who NEVER credit their overdue fine payments. |
| 11:47 |
* rfrasur |
rolls eyes |
| 11:48 |
rfrasur |
"yes...patron...we're stupid and forget the same line over and over and over...and believe you...really." |
| 11:58 |
|
jdouma joined #evergreen |
| 12:00 |
|
artunit joined #evergreen |
| 12:02 |
|
fparks_ joined #evergreen |
| 12:06 |
|
smyers_ joined #evergreen |
| 12:11 |
|
mrpeters joined #evergreen |
| 12:11 |
|
mrpeters joined #evergreen |
| 12:13 |
|
RBecker joined #evergreen |
| 12:17 |
|
mrpeters joined #evergreen |
| 12:21 |
|
mrpeters joined #evergreen |
| 12:33 |
rfrasur |
Hmm, if the government shuts down, does that mean I don't have to do quarterly reporting until it starts up again? |
| 12:34 |
mmorgan |
Can anyone shed any light on errors in the client like: TypeError:$("patronStrings").getString is not a function |
| 12:34 |
paxed |
no dojo? |
| 12:35 |
mmorgan |
another one is TypeError: document.getElementById("commonStrings").getFormattedString is not a function |
| 12:35 |
kmlussier |
When do these errors come up? Not that I can help, but I'm curious. |
| 12:37 |
mmorgan |
the errors are intermittent in the client. Sometimes it works just fine, other times, clicking on a tab brings up an error. |
| 12:37 |
|
hopkinsju joined #evergreen |
| 12:37 |
paxed |
well, the second one doesn't depend on dojo. so i guess you don't have the translation file common.properties on the server |
| 12:37 |
paxed |
or it doesn't get loaded for some reason? |
| 12:39 |
jeff |
poor client network connectivity? |
| 12:39 |
jeff |
(sorry, stabbing in the dark) |
| 12:39 |
mmorgan |
paxed: you're a little over my head :) |
| 12:40 |
mmorgan |
jeff: I was wondering if it could be that, they have been seeing these pop up for the past month or so. |
| 12:41 |
paxed |
err. i can't recall off the top of my head, but perhaps .getFormattedString is from dojo, too... |
| 12:42 |
paxed |
actually, it almost certainly is. |
| 12:43 |
paxed |
but if dojo was missing, the UIs would be breaking quite badly. so, i'd probably start by looking if it's the common.properties -file not getting loaded |
| 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 |
| 13:02 |
|
artunit joined #evergreen |
| 13:28 |
|
mllewellyn joined #evergreen |
| 13:42 |
|
artunit joined #evergreen |
| 13:52 |
|
natschil joined #evergreen |
| 13:59 |
csharp |
LP 1203796 |
| 13:59 |
pinesol_green |
Launchpad bug 1203796 in Evergreen 2.4 ""Total Circs" Count in Alternate Item Status View is undercounting" (affected: 1, heat: 6) [Low,Fix committed] https://launchpad.net/bugs/1203796 |
| 14:00 |
bshum |
csharp: Uh oh? |
| 14:01 |
csharp |
bshum: nah - I was just using pinesol_green to get the bug link :-D |
| 14:02 |
bshum |
csharp: Oh whew. Was starting to worry :) |
| 14:02 |
csharp |
heh - don't mind me ;-) |
| 14:02 |
* bshum |
pats pinesol_green, "That'll do pinesol_green, that'll do." |
| 14:02 |
csharp |
pinesol_green: botsnak |
| 14:02 |
pinesol_green |
csharp: http://cat.evergreen-ils.org.meowbify.com/ |
| 14:02 |
csharp |
pinesol_green: botsnack |
| 14:02 |
pinesol_green |
csharp: Go away, or I'll replace you with a very small shell script! |
| 14:02 |
rfrasur |
yikes |
| 14:03 |
csharp |
@dunno |
| 14:03 |
rfrasur |
pinesol_green must be a cat. |
| 14:03 |
pinesol_green |
csharp: http://www.firstpersontetris.com/ |
| 14:03 |
pinesol_green |
rfrasur: Fire BAD! Reading GOOD! |
| 14:07 |
csharp |
@dunno add Yeah, well, you know, that's just, like, your opinion, man. |
| 14:07 |
pinesol_green |
csharp: The operation succeeded. Dunno #20 added. |
| 14:07 |
natschil |
Hello. I remember that a while back there were some sort of beta debian packages of opensrf. Has there been any work on that recently? |
| 14:08 |
bshum |
natschil: Not to my recollection. It's been a long time since folks were working on packaging of things. |
| 14:08 |
bshum |
Though I don't know of any unofficial packaging work that's gone on in secret :) |
| 14:08 |
csharp |
natschil: we maintain a deb for OpenSRF at http://archive.georgialibraries.org |
| 14:09 |
csharp |
our goal is that's for general use, but in practice it's only adopted by GPLS at this point |
| 14:09 |
csharp |
we haven't been trying to get it in shape for Debian acceptance or anything at this point |
| 14:10 |
|
tspindler left #evergreen |
| 14:10 |
csharp |
(though with the /usr/local install by default that may open the doors for that) |
| 14:17 |
|
Callender_ joined #evergreen |
| 14:19 |
|
Callender__ joined #evergreen |
| 14:21 |
|
Callender joined #evergreen |
| 14:23 |
|
Callender_ joined #evergreen |
| 14:23 |
|
egbuilder joined #evergreen |
| 14:25 |
|
natschil 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. |
| 14:33 |
jeff |
at least, i'm pretty sure he uses it. :-) |
| 14:33 |
* csharp |
uses pgadmin as well |
| 14:34 |
bshum |
jeff: I was literally doing a SQL refresher training this morning |
| 14:34 |
rfrasur |
when I learn more, I'll know who to ask. |
| 14:34 |
csharp |
@love pgadmin |
| 14:34 |
pinesol_green |
csharp: The operation succeeded. csharp loves pgadmin. |
| 14:34 |
bshum |
And pgadmin is the bestest :D |
| 14:34 |
csharp |
day to day I probably use psql more often, but pgadmin's great for browsing tables, functions, etc. |
| 14:37 |
rfrasur |
I'm not through db tutorials yet....so psql will be a ways down the road. I'm just trying to figure out how to explain to end users WHY precise, consistent inputs are important. |
| 14:38 |
rfrasur |
without swear words |
| 14:39 |
jeff |
rfrasur: the following Charles Babbage quote springs to mind: |
| 14:39 |
jeff |
On two occasions I have been asked, — "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. |
| 14:39 |
jeff |
Passages from the Life of a Philosopher (1864), ch. 5 "Difference Engine No. 1" |
| 14:39 |
jeff |
http://en.wikiquote.org/wiki/Charles_Babbage |
| 14:39 |
gmcharlt |
jeff++ |
| 14:39 |
rfrasur |
jeff++ |
| 14:40 |
rfrasur |
and yet people still ask the question...and wonder at the answer |
| 14:42 |
|
artunit joined #evergreen |
| 14:47 |
rfrasur |
so all the patron registration stuff in the staff client feeds into one table? |
| 14:48 |
jeff |
most, but not all. |
| 14:48 |
jeff |
there's actor.usr but then also actor.card and actor.usr_address... |
| 14:48 |
rfrasur |
oh....and more stuff that just the registration stuff anyway also. |
| 14:49 |
bshum |
actor.usr_setting too, probably. |
| 14:49 |
jeff |
the patron statistical categories are in another table, actor.stat_cat_entry_usr_map |
| 14:49 |
bshum |
Stat cats |
| 14:49 |
rfrasur |
right |
| 14:49 |
csharp |
surveys too are in their own table(s) |
| 14:49 |
|
kbutler joined #evergreen |
| 14:49 |
bshum |
Sigh, speaking of stat cats, I should probably get back to that bug |
| 14:49 |
csharp |
bug? |
| 14:50 |
rfrasur |
o0 (this is behemoth) |
| 14:50 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1130389 |
| 14:50 |
pinesol_green |
Launchpad bug 1130389 in Evergreen 2.4 "Blank stat_cat_entry in actor.stat_cat_entry_usr_map" (affected: 2, heat: 10) [Medium,Confirmed] |
| 14:50 |
bshum |
Not that we really need the extra blank entries to remind us they're there |
| 14:54 |
* csharp |
looks for evidence of this in PINES |
| 14:55 |
jeff |
Hrm. Do we as a project have a standard for indentation of XML data? |
| 14:56 |
jeff |
I suppose following the indent style of tpac html templates would be closest if we don't have one for xml. |
| 14:56 |
* jeff |
looks as well |
| 14:56 |
jeff |
"The general rule for all files needing indentation is 4 space indents, no literal tabs" |
| 14:56 |
jeff |
from the unofficial-but-first-result-in-google http://evergreen-ils.org/dokuwiki/doku.php?id=code_formatting_standards |
| 14:57 |
|
DPearl joined #evergreen |
| 14:58 |
bshum |
csharp: http://pastie.org/8367640 |
| 14:58 |
bshum |
That's what I just ran to find the blank stat cat entries that match up to the circumstances described in the bug. |
| 14:59 |
csharp |
bshum: thanks |
| 14:59 |
csharp |
0 rows in our case |
| 14:59 |
bshum |
Lucky you |
| 14:59 |
bshum |
:) |
| 14:59 |
csharp |
heh |
| 14:59 |
bshum |
I apparently have 134085 |
| 14:59 |
bshum |
Though only one stat cat affected. |
| 15:00 |
bshum |
It's a use case we weren't really anticipating |
| 15:00 |
bshum |
Where we weren't requiring the stat cat, but also weren't allowing it to be freetext and only something you could choose the values for. |
| 15:00 |
bshum |
Oh well :) |
| 15:01 |
* bshum |
likes digging up random old bugs |
| 15:01 |
bshum |
senator: dbwells: Looking at this old serials bug: https://bugs.launchpad.net/evergreen/+bug/1194602 |
| 15:01 |
pinesol_green |
Launchpad bug 1194602 in Evergreen "serials receiving error" (affected: 1, heat: 6) [Undecided,Triaged] |
| 15:02 |
bshum |
senator: dbwells: I'm thinking this may no longer be valid in more recent forms of Evergreen now that you guys have made the caption/pattern wizard more robust. |
| 15:02 |
bshum |
But now I want to file my bug about old crummy data that pre-dates the changes that still break receiving serials. |
| 15:02 |
bshum |
:) |
| 15:02 |
bshum |
Let me know what you think. |
| 15:05 |
DPearl |
Schema question: I am seeing two asset.copy_part_map entries that point to the same target_copy (asset.copy records) and reference two different (but similar) asset.monograph_part entries, which themselves refer to two different biblio.record_entry's. This seems a bit unusual to me, as the asset.copy references the asset.call_number, which references one biblio.record_entry. Am I confused or is the database not quite in the des |
| 15:05 |
jeff |
DPearl: your message truncated at "not quite in the desi", fyi |
| 15:06 |
DPearl |
Not quite in the desired state? (Missed it by THAT MUCH) |
| 15:07 |
|
Bmagic joined #evergreen |
| 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 |
DPearl |
tsbere: OK. So db inconsistency. I won't sweat this for now, it is only a 100 records out of millions. |
| 15:10 |
csharp |
Bmagic: red light/green light as far as whether the service is running? or what? |
| 15:10 |
DPearl |
kmlussier: Thanks! Not quite the symptom I was looking at, but same underlying cause. |
| 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. :) |
| 15:14 |
dbwells |
bshum: Still, I encourage you to open your bug, too, since I consider that a regression rather than a missing edge case (which is what I would label the bug above). |
| 15:15 |
bshum |
dbwells: Sounds reasonable. I wasn't sure how to name my bug. |
| 15:15 |
bshum |
I'm horrible with naming things well enough to find later. |
| 15:15 |
csharp |
bshum: Bmagic: osrf_control in opensrf master does have a --diagnostic flag. Sample output line: * open-ils.actor [19396] uptime=4-03:20:58 cputime=00:00:01 #drones=3 |
| 15:15 |
Bmagic |
does it work when the process is running but not working? |
| 15:15 |
csharp |
Bmagic: I doubt it does that much |
| 15:16 |
Bmagic |
we commonly see all of the processes running but when interacting with them, you start to see issues |
| 15:22 |
bshum |
dbwells: For lack of a better name, I filed https://bugs.launchpad.net/evergreen/+bug/1233340 |
| 15:22 |
pinesol_green |
Launchpad bug 1233340 in Evergreen "2.5 serials receiving error" (affected: 1, heat: 6) [Medium,Triaged] |
| 15:22 |
senator |
bshum: launchpad's awful search sure doesn't help with the finding things later; don't blame yourself too much |
| 15:22 |
* senator |
agrees with dbwells totally re that bug |
| 15:27 |
rfrasur |
was it in here where we were wishing for a barcode registry? |
| 15:27 |
* rfrasur |
wants one right now |
| 15:28 |
jeff |
Some states have one. I recall discussion in here in the recent past, yes. |
| 15:29 |
rfrasur |
after further investigation....it wouldn't have helped this situation. Poor workflows. Meh. |
| 15:34 |
* bshum |
filed https://bugs.launchpad.net/evergreen/+bug/1233343 too |
| 15:34 |
pinesol_green |
Launchpad bug 1233343 in Evergreen "alternative title indexing in broken in 2.5" (affected: 1, heat: 6) [Medium,Confirmed] |
| 15:35 |
bshum |
eeevil++ for a proposed fix. And senator++ for helping to mention it to us |
| 15:50 |
jeff |
someday bug 28649 will be fixed. |
| 15:50 |
pinesol_green |
Launchpad bug 28649 in Launchpad itself "mail word wrapping breaks urls and other words" (affected: 9, heat: 90) [Low,Triaged] https://launchpad.net/bugs/28649 |
| 15:53 |
bshum |
That'd be nice. |
| 15:55 |
bshum |
I just clicked "affects me too" to bump the heat on that slightly :D |
| 15:55 |
bshum |
Not that it matters, but it makes me feel better. |
| 15:56 |
* rfrasur |
can also push a button pretty affectively. |
| 15:56 |
rfrasur |
effectively? |
| 15:57 |
bshum |
"This and the difference between "affect" and "effect" are the only two things he's serious about." |
| 16:00 |
|
depesz joined #evergreen |
| 16:00 |
depesz |
hi |
| 16:01 |
depesz |
i'm looking at plpgsql/sql functions in evergreen on postgresql, and i'm scared. plpgsql function, which calls sql function, which calls sql function, which calls sql function. |
| 16:03 |
rfrasur |
bshum++ |
| 16:05 |
depesz |
is there any reason why it is made that way, as opposed to just writing queries that touch tables? |
| 16:05 |
senator |
well, worse than such a chain of functions would be a situation where all the code from those deeper functions was just inlined in the higher ones (and repeated wherever else it was needed) right? |
| 16:07 |
depesz |
well, yes and no. from performance point of view - it would be better. |
| 16:07 |
depesz |
maintenance would be probably more difficult, but performance and debugging would be *way* easier. |
| 16:10 |
senator |
are plpgsql and sql function calls that expensive per se? i'm not sure i've seen that. |
| 16:11 |
depesz |
no. |
| 16:11 |
depesz |
but when you're doing function that is based on function - especially if the subfunction (or subview) is using certain things (order, grouping) - it basically becomes optimization barrier for pg. |
| 16:12 |
eeevil |
depsez: if the pattern that's scaring you were used in a critical path where performance were of particular concern, I'd agree with you. debugging is not that hard when you know the code, of course, and the code is reusable when split up |
| 16:12 |
depesz |
the biggest problem for me now is that I can't really pinpoint the [problem because logic is spread across *many* function. so it's not easy to even understand where the data *really* comes from. |
| 16:13 |
eeevil |
feel free to ask for clarification |
| 16:13 |
depesz |
well, the i don't think it's easily providable. |
| 16:13 |
depesz |
i'm looking at function evergreen.ranked_volumes() |
| 16:14 |
depesz |
it joins in query with function actor.org_unit_descendants() |
| 16:14 |
depesz |
and i need to know if any of the columns in the org_unit_descendants are unique |
| 16:14 |
depesz |
especially the one named "id" |
| 16:14 |
eeevil |
id is |
| 16:15 |
rfrasur |
depesz: there are some people in here who basically live inside the code (or have in the past). they're pretty good at guided tours. eeevil is one of them... |
| 16:16 |
* eeevil |
is also home sick, currently... I'll be more help tomorrow |
| 16:17 |
kmlussier |
eeevil: Bleh...sorry to hear that. Hope you feel better soon! |
| 16:17 |
natschil |
I'm currently trying to install opensrf, and I get the following message when starting it. Is there a way to get rid of it: * service router pid=21944 21945 is running with no pidfile! use --force-clean-process to automatically kill orphan processes |
| 16:17 |
natschil |
? |
| 16:18 |
rfrasur |
eeevil: I hope your sick is the kind that lets you stay home but doesn't make you not enjoy being home. |
| 16:18 |
depesz |
eeevil: so, the subselect, that starts at line 2 in the function - SELECT acn.id, aou.name, acn.label_sortkey, ... |
| 16:18 |
depesz |
there is group by in there, but as I understand, the only duplicated rows can be there due to asset.copy table? |
| 16:19 |
depesz |
i.e. many rows in asset.copy with the same call_number and status? |
| 16:19 |
eeevil |
rfrasur: unfortunately no |
| 16:20 |
eeevil |
depsez: unlimited |
| 16:20 |
rfrasur |
eeevil: blech. sorry to hear it. |
| 16:20 |
depesz |
and it looks like the group by is there only to weed out duplicated rows - it doesn't actually do any aggregates? |
| 16:20 |
depesz |
eeevil: ? |
| 16:20 |
depesz |
"unlimited" doesn't sound like answer to the questions i asked (or wanted to ask, my english is far from good) |
| 16:21 |
eeevil |
you can have as many copies with the same status on the same call number as you want |
| 16:21 |
depesz |
eeevil: yes, i understand. but do i see correctly that it is the ony source of "duplicated" rows, and the the group by is only to remove them? |
| 16:22 |
eeevil |
on my phone, so please excuse my brevity |
| 16:22 |
|
dMiller_ joined #evergreen |
| 16:23 |
eeevil |
also don't have the code in front of me... |
| 16:23 |
depesz |
ok. i'll assume i got it right. and what it will give me ... |
| 16:24 |
eeevil |
its likely that's the case, though. perhaps an exists where-clause would be worth a try |
| 16:25 |
depesz |
i'll try a bit different approach. one question, though - which pg version is the code targetting? |
| 16:25 |
depesz |
I am not very familiar with evergreen - i was just asked to check db performance, and am tracking potential issue. |
| 16:26 |
eeevil |
9.1+ today, but it started targeting 8.0. lots of legacy |
| 16:26 |
|
fparks joined #evergreen |
| 16:27 |
eeevil |
we just recently moved to CTEs instead of connectby |
| 16:28 |
eeevil |
well, relatively recently. last 2 years |
| 16:28 |
jeff |
depesz++ for explain.depesz.com -- I've found that handy on more than one occasion. thanks. :-) |
| 16:28 |
depesz |
9.1 is good enough. thanks. |
| 16:28 |
depesz |
jeff: you're welcome. |
| 16:29 |
eeevil |
indeed! |
| 16:30 |
eeevil |
depsez: there's more than a few evergreen queries stored at explain.depsez.com :) |
| 16:31 |
depesz |
glad that you find it useful. |
| 16:36 |
eeevil |
I'm gonna go be I'll away from a computer-ish device. depsez, I'm mostly always around and there are plenty of other helpful folks in here. don't hesitate to ask anything in here |
| 16:41 |
* rfrasur |
is off to buy homecoming attire for children. W00t. |
| 16:55 |
depesz |
ok. just decreased runtime from 0.7s to 0.045s by inlining one function. |
| 16:56 |
depesz |
will talk with my client, and they will most likely reach back to you about it. |
| 16:56 |
pinesol_green |
[evergreen|Kathy Lussier] Responsive tpac release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e6617bd> |
| 16:57 |
jeff |
depesz: sounds promising. can you share more details in terms of which query's runtime was improved, and which function you inlined? |
| 16:58 |
depesz |
not sure I can. this is the first optimization I'm doing for this client, and I want to clear it with them first. |
| 16:58 |
jeff |
understood. just thought I'd ask. :-) |
| 16:58 |
depesz |
I don't suspect thay will want to keep it only to themselves, but I want to be 100% sure. |
| 16:59 |
kmlussier |
depesz: Your suspicion is correct. Feel free to share whatever your find. :) |
| 16:59 |
depesz |
kmlussier: :) |
| 17:00 |
depesz |
restesting now, as when I started to write summary email, I got weird results |
| 17:00 |
kmlussier |
depesz: OK, fair enough. |
| 17:03 |
natschil |
Hello. Has the format of what osrf-http-translator sends back changed in a relatively major way in the last half-year? |
| 17:06 |
natschil |
I seem to get back a message that looks like this: |
| 17:06 |
pastebot |
"natschil" at 64.57.241.14 pasted "What I get from osrf-http-translator" (6 lines) at http://paste.evergreen-ils.org/22 |
| 17:06 |
bshum |
kmlussier++ # like the release notes for responsive catalog :) |
| 17:06 |
jeff |
natschil: you'll probably want to clarify if you're talking about OpenSRF alone, or in combination with Evergreen. Also, any examples of what is causing you to ask the question would help. :-) |
| 17:07 |
natschil |
jeff: I'm talking about opensrf alone. |
| 17:09 |
natschil |
jeff: I'm simply trying to use the opensrf http translator using a forked version of the js libs (from about half a year ago), and what I'm getting back doesn't look like what I expected to get back (see paste), so I'm wondering whether my http translator is misconfigured. (Note that I'm using opensrf from git) |
| 17:09 |
jeff |
natschil: does the output/behavior appear to have changed from what you're seeing vs what you've seen before? |
| 17:09 |
jeff |
natschil: do you have an example of what you're used to seeing as output, for comparison? |
| 17:09 |
|
mmorgan left #evergreen |
| 17:09 |
natschil |
jeff: I'm not used to seeing the first two lines of the paste. Given that they look like http headers, I suspect that I've misconfigured something. |
| 17:10 |
jeff |
natschil: ah. that looks like a chunked response. perhaps you need to adjust your client to not request / accept chunked responses? |
| 17:12 |
natschil |
jeff: That would make sense. Do you happen to know whether returning chunked responses is something recent? |
| 17:17 |
jeff |
natschil: i might be wrong on the chunked issue -- can you paste the full client http request headers and the full http server response headers? |
| 17:18 |
|
ktomita joined #evergreen |
| 17:19 |
jeff |
natschil: you might be running into a change introduced by commit cd6dcc -- i'm curious if the user agent header you're sending has changed at all. |
| 17:19 |
pinesol_green |
[opensrf|Bill Erickson] LP1198983 disable multipart/mixed for Firefox - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=cd6dccc> |
| 17:19 |
jeff |
natschil: but... headers, please. :-) |
| 17:36 |
|
fparks_ joined #evergreen |
| 17:44 |
natschil |
jeff: The response-headers do say "multipart/x-mixed-replace;etc..." |
| 17:45 |
natschil |
jeff: But that commit suggests that multipart responses have existed before too. Maybe the problem isn't related to the headers, but is related to something else and I simply forgot about the fact that the http-translator returns multipart responses sometimes. |
| 18:00 |
depesz |
kmlussier: mailed to our mailing list. there will be furter editions, but so far it looks very promising |
| 18:41 |
|
natschil left #evergreen |
| 19:36 |
|
graced_ joined #evergreen |
| 19:45 |
|
fparks joined #evergreen |
| 19:53 |
|
kbeswick joined #evergreen |
| 20:45 |
jeff |
gmcharlt++ esi++ |
| 20:46 |
jeff |
and phasefx++ Callender++ moodaepo++ graced++ while i'm at it. |
| 21:23 |
eeevil |
hardware-- |
| 21:38 |
jeff |
illness-- |
| 21:41 |
jeff |
i try not to openly speak ill of hardware lest it hear me and retaliate. :P |
| 21:44 |
* gmcharlt |
has been (in other contexts) been finding myself summong Murphy a *lot* the past two weeks |
| 22:04 |
rangi |
their irish red isn't too bad |
| 22:45 |
|
Callender joined #evergreen |
