Time |
Nick |
Message |
04:58 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
06:46 |
|
timf joined #evergreen |
07:44 |
|
collum joined #evergreen |
08:16 |
|
rjackson-isl joined #evergreen |
08:20 |
|
mrpeters joined #evergreen |
08:22 |
|
akilsdonk joined #evergreen |
08:26 |
|
Dyrcona joined #evergreen |
08:39 |
|
Dyrcona joined #evergreen |
08:44 |
|
ericar joined #evergreen |
08:47 |
|
yboston joined #evergreen |
08:51 |
mrpeters |
is there a handy way to dump srfsh output to text instead of dumping to screen? |
08:52 |
mrpeters |
maybe just creating a .srfsh file and feeding it to srfsh and > foo.log |
08:52 |
mrpeters |
yes indeed...that works (for the logs) |
08:55 |
mrpeters |
rjackson-isl++ jboyer-isl++ |
08:56 |
jboyer-isl |
You seeing folder sharing problems at other installations, or just being cautious? |
08:57 |
mrpeters |
no, seeing them |
08:57 |
mrpeters |
a big list of them for a newly migrated library |
08:57 |
jboyer-isl |
Good times tracking them down the first time. |
08:58 |
mrpeters |
oh yeah its a nightmare, thats why i was hoping you still had my nagios checks |
08:58 |
mrpeters |
but i can see you've even improved upon them |
08:58 |
jboyer-isl |
I do like to tinker. |
09:08 |
|
RoganH joined #evergreen |
09:13 |
|
kbeswick joined #evergreen |
09:17 |
|
dbwells joined #evergreen |
09:17 |
csharp |
so is anyone out there in Evergreen land running their staff workstations in virtualized environments? I'm specifically interested in whether anyone's running Windows on VMWare, but I wanted to cast a wide net |
09:18 |
RoganH |
I have one library that runs on the MS platform (can't remember it's name). |
09:18 |
csharp |
one of our member libraries is complaining of constant freezes and needs for restarts and I was looking for a comparison point |
09:19 |
RoganH |
I know a few more that have talked about it. I'll check to see where they are in their testing. |
09:19 |
csharp |
RoganH: thanks! |
09:19 |
RoganH |
Actually, now that I think about it, we have another who has been virtual for a long time and they might be VMWare. I tend to forget about them because they did it before it was cool. |
09:20 |
RoganH |
They had a really top notch IT guy at the time. |
09:20 |
csharp |
yeah - these guys have been on it for a few years - it was a county IT departmental decision, and it apparently works well everywhere except for the library :-/ |
09:20 |
phasefx |
csharp: I put together a vmplayer image once with xubuntu and an auto-started staff client, as a last ditch-workaround for the client crashing on a particular machine; not sure how that played out afterward |
09:21 |
csharp |
phasefx: yeah, I would *love* to steer them towards something like Lubuntu, but that's almost certainly out of the question ;-) |
09:21 |
* csharp |
reboots the Fedora buildslave |
09:22 |
phasefx |
csharp: if it's all configured, they can just pretend it's a weird app :) |
09:22 |
RoganH |
OK, I'm seeing a very narrow problem with searching for email. Can I get anyone else to test it in their staff clients? |
09:22 |
csharp |
heh - yeah, I'll see if I can sneak that in ;-) |
09:22 |
RoganH |
What happens is if you search for an email that starts with an 'a.' will fail. |
09:23 |
RoganH |
So, for example, a.smithgeneric.net will generate an error. Or A.smithgeneric.net |
09:23 |
csharp |
@eightball what will happen if I type 'google' into Google? |
09:23 |
pinesol_green |
csharp: Yes! |
09:23 |
RoganH |
But it's that narrow, b.smithgeneric.net will. |
09:23 |
bshum |
RoganH: On my staff client, if I key in "a" (just that) into the email field, it works fine |
09:24 |
RoganH |
or aa.smithgeneric.net will work. |
09:24 |
bshum |
My guess is a timeout from overabundunt results |
09:24 |
bshum |
I've seen that happen before on the city field |
09:24 |
jeff |
bshum: what about searching for a. |
09:24 |
bshum |
When using our most populated city |
09:24 |
bshum |
Ah that, hmm |
09:24 |
csharp |
we had a problem with email searches until we added an index on them |
09:24 |
bshum |
Yes, I get hits for "a." as well |
09:25 |
RoganH |
bshum: I get results for "a." as well but not "a.emailaddress.net" |
09:25 |
csharp |
RoganH: that worked ok for me too |
09:25 |
jeff |
RoganH: what is the error, and is there any corresponding error in the database logs or opensrf logs? |
09:25 |
bshum |
Well I wouldn't expect any results for that, given that I have no patrons with that style of address :) |
09:25 |
bshum |
For me anyways |
09:26 |
bshum |
But I get the usual "no patrons found matching search criteria" popup when I try it. |
09:26 |
RoganH |
Well, what prompted this is a valid email address that is in a record. |
09:26 |
RoganH |
But, made up ones cause it too. |
09:26 |
jeff |
RoganH: that was my next question. thanks. |
09:27 |
RoganH |
It is like it's timing out but that doesn't make sense since I can give it far more intensive searches and it responds fine. |
09:27 |
jeff |
RoganH: that seems to rule out the likelihood of it being a malformed patron record tripping up the client when it tries to display one of the results matching your email address criteria. |
09:27 |
jeff |
searching in 2.5.1 for email a.smithexample.com i get the usual "no patrons found" message, no errors. |
09:27 |
RoganH |
We've been playing around to narrow down the criteria. It's odd. |
09:28 |
RoganH |
Specifically I get a 500 network error. |
09:28 |
jeff |
and server side, what is the error? |
09:28 |
RoganH |
I tested this last night at 11 pm when there was no server load. |
09:29 |
RoganH |
I haven't gone that far yet. I was looking to see if others knew of anything similar but it sounds like a unique to us thing now. |
09:30 |
RoganH |
The weird ones are kind of fun so long as they don't affect too many situations. :) |
09:30 |
jeff |
RoganH: not that I think that method has changed much recently, but what version are you on? |
09:30 |
RoganH |
jeff: 2.5.3 |
09:30 |
jeff |
thanks. |
09:32 |
bshum |
Well, I modded one of my test accounts to include a style of email like a.testsomewhere.com |
09:32 |
bshum |
And while it took awhile to search, it did retrieve the patron in search |
09:33 |
bshum |
Might just be a timing issue of some sort. Where the DB takes just a little too long, and the service stops paying attention? |
09:33 |
jeff |
server logs are going to be the next best clue. |
09:33 |
bshum |
Indeed. |
09:34 |
RoganH |
bshum: that's what I'm thinking but yeah, just odd since it coughs up responses to just "a" or "a." with no problem but we've all seen weirder |
09:35 |
jeff |
can you tell me the exact string that you were searching on that does fail? |
09:35 |
jeff |
i think you did above, but i just wanted to be sure. |
09:35 |
RoganH |
There are days I would accept that it's because nibiru is too close in orbit or somehting. |
09:52 |
Dyrcona |
RoganH: It's the polar shift. |
09:52 |
RoganH |
Dyrcona++ |
10:02 |
|
jwoodard joined #evergreen |
10:11 |
jeff |
RoganH: if you can get more detailed client logs or server logs, i'm intrigued by your a.somethingexample.com issue. |
10:11 |
RoganH |
jeff: I am too. I'm slammed this morning with more critical things but I'll let you know what I find out. |
10:14 |
* jeff |
nods |
10:22 |
|
ldw joined #evergreen |
10:24 |
|
afterl joined #evergreen |
10:31 |
jeff |
another interesting challenge with linked/shared/cloned addresses: what happens when you receive returned mail for one patron? |
10:31 |
jeff |
you could retrieve the patron that owns the address and uncheck the valid checkbox. |
10:31 |
jeff |
(which is likely what i'll do here) |
10:31 |
jeff |
but there isn't an easy way to end up with no address on the subordinate patron account. |
10:32 |
jeff |
a "copy this shared address to this user" option would probably help. |
10:33 |
csharp |
and possibly an ON DELETE trigger that does it automatically if the "master" address is deleted? |
10:35 |
jeff |
or prevent deletion at that low level, and have something higher up handle it. |
10:35 |
jeff |
the idea is neat, and could probably use some interface TLC |
11:19 |
|
ldw joined #evergreen |
11:21 |
Bmagic |
who is using keepalived ? |
11:44 |
csharp |
bshum: can you catch me up on the status of 14.04 and Evergreen? |
11:49 |
Dyrcona |
csharp: I can tell you that on the vms and other computers where we at MVLC have tried upgrading from 12.04 to 14.04, we've had horrible luck. |
11:49 |
csharp |
yeah, I expected that from my early tests |
11:50 |
csharp |
right now I'm going for clean install - I just didn't want to duplicate effort |
11:50 |
Dyrcona |
Even going from 13.10 to 14.04 on my laptop left it in a state that it wouldn't boot. |
11:50 |
csharp |
my "desktop" ubuntu upgrades went fine |
11:50 |
csharp |
but we don't really upgrade |
11:51 |
csharp |
we install the base OS and install debs from there |
11:51 |
csharp |
though, right now I'm just working on building from source on 14.04 |
11:53 |
* csharp |
wants to start messing with upgrading dojo (coming from a very naive perspective, hoping to learn as I go ;-) ) |
11:53 |
Dyrcona |
csharp: Good luck with that. |
11:55 |
* Dyrcona |
realizes that his lunch salad would be better if he had added apple slices. |
11:57 |
csharp |
Dyrcona: :-D thanks |
11:58 |
csharp |
if nothing else, I hope *I* will get a better understanding of the dojo pieces ;-) |
11:58 |
Dyrcona |
csharp: Aren't the Dojo pieces going away with the web-based staff client? |
11:58 |
csharp |
Dyrcona: no, as far as I understand, they are coming along with |
11:59 |
* csharp |
invites berick to correct him, though |
12:01 |
tsbere |
csharp: Given some of the headaches with previous attempts of my own to upgrade dojo I would recommend we remove it, not update it. >_> |
12:02 |
* tsbere |
thinks he had found that we are using features that they did not continue to include in later versions |
12:05 |
csharp |
ah - well if going forward with dojo isn't certain, I'll not spend too much time on it |
12:06 |
csharp |
I'm just reacting to some UI glitch-type frustrations discovered when testing acq, and was hoping to ameliorate things |
12:10 |
|
ericar joined #evergreen |
12:12 |
csharp |
no mention of dojo in the agendas/minutes of dev meetings over the last year |
12:12 |
csharp |
I guess with angular.js in the picture, that would be the preferred toolset, though, right? |
12:13 |
csharp |
@ana TOO MANY TOOLSETS |
12:13 |
pinesol_green |
csharp: Tamest loony to so |
12:14 |
dbs |
angular is not a toolset the way that dojo is (at least, not in terms of widgets) |
12:14 |
dbs |
It tries to be minimalist |
12:14 |
bshum |
csharp: So, I've been a bit distracted as of late from getting Evergreen working with 14.04. |
12:14 |
csharp |
bshum: that's okay - I finally have some time to devote, so I was going to give it a go |
12:14 |
bshum |
At the very least, I'm happy enough that my postgresql database is moving along with 14.04 though. |
12:14 |
csharp |
awesome ;-) |
12:15 |
bshum |
We changed up the core, but I didn't trust Evergreen and the bricks quite yet |
12:15 |
csharp |
bshum: is this on the server with SSDs? |
12:15 |
bshum |
csharp: Yes. |
12:15 |
csharp |
is it awesome? |
12:15 |
bshum |
I'm fairly pleased so far. |
12:15 |
csharp |
rock and roll |
12:16 |
* csharp |
looks forward to receiving ours in the next couple/few weeks |
12:17 |
bshum |
I had enough room to change all my GIST to GIN for metabib indexes. |
12:17 |
bshum |
Not sure if it matters yet, but I like it :) |
12:18 |
csharp |
GIN++ |
12:18 |
csharp |
we saw a marked difference after that switch |
12:20 |
|
ericar joined #evergreen |
12:20 |
bshum |
csharp: fwiw, I think we committed the initial changes for 14.04 to OpenSRF |
12:21 |
bshum |
So there is that |
12:21 |
mrpeters |
so no go on 14.04 at this time? |
12:21 |
mrpeters |
was considering upgrading to 14.04 when we upgrade someone to 2.6 |
12:22 |
csharp |
mrpeters: I'm working on that right now |
12:22 |
csharp |
bshum: did you have an EG branch you were working on? or was my branch the only one? |
12:22 |
mrpeters |
yeah, cool. i need to set up their testing server within the next week or two so i may have to just roll with 12.04 for that, and then 14.04 for production |
12:23 |
bshum |
csharp: I think yours is the only one I know about. |
12:23 |
mrpeters |
which i dont love, but we can always rebuild test server at a later date |
12:23 |
csharp |
bshum: okay - cool - thanks! |
12:23 |
berick |
csharp: i would love to replace the dojo UIs with angular versions, but there is no specific plan in place to do that yet |
12:23 |
csharp |
berick: do you think it's best then to stay with old dojo for the foreseeable future? |
12:25 |
berick |
csharp: well, if you have the time to update dojo, i don't think anyone will stop you. my guess is your time could be better spent, though. |
12:26 |
csharp |
berick: thanks - exactly what I was thinking about |
12:28 |
|
zerick joined #evergreen |
13:12 |
|
jihpringle joined #evergreen |
13:13 |
pinesol_green |
[evergreen|Mike Rylander] LP#1310751: Reorder query-building wrapper for QueryParser - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c3327de> |
13:15 |
bshum |
marc-- |
13:17 |
csharp |
@karma marc |
13:17 |
pinesol_green |
csharp: Karma for "marc" has been increased 0 times and decreased 18 times for a total karma of -18. |
13:17 |
csharp |
marc-- |
13:18 |
Dyrcona |
marc-- # for an even -20 |
13:21 |
bshum |
A handful (less than a dozen I'm sure) bibs didn't export because they were too large to be handled with USMARC I guess. |
13:21 |
bshum |
So now I have to re-run it as MARCXML to see if it'll nab them this time around. |
13:22 |
csharp |
yeah - that happens here too |
13:23 |
csharp |
I'm going to investigate eeevil's suggestion to identify those records and export them piecemeal to stay under the size limit |
13:23 |
csharp |
identifying the records will be the hardest part of that |
13:26 |
egbuilder |
build #594 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/594 blamelist: Mike Rylander <mrylandergmail.com> |
13:26 |
Dyrcona |
I read that as "is complete failure" though guess it amounts to the same. |
13:29 |
csharp |
that's after upgrading to Fedora 20, FYI |
13:30 |
csharp |
looks like there are some deps that got tore up |
13:30 |
Dyrcona |
Perl 5.18? |
13:30 |
dbwells |
csharp: I'm double-checking the commit I just pushed. Are you saying that probably isn't the problem? |
13:30 |
Dyrcona |
My understanding is some tests and some CPAN modules's tests fail under Perl 5.18. |
13:30 |
bshum |
Yeah there's some bugs for that. |
13:30 |
csharp |
dbwells: I'm saying that it's likely an OS problem |
13:31 |
csharp |
I'm looking now |
13:31 |
* Dyrcona |
has a laugh at "modules's" expense. :) |
13:32 |
csharp |
Dyrcona: perl 5.18, yes |
13:33 |
|
bmills joined #evergreen |
13:35 |
dbwells |
csharp: Do you know when the Ubuntu build slave will be online again? |
13:36 |
pastebot |
"mrpeters" at 64.57.241.14 pasted "2.6.0 open-ils.circ.circ_modifier.retreieve_all 404" (6 lines) at http://paste.evergreen-ils.org/50 |
13:36 |
mrpeters |
anyone bump up against that when installing 2.6 |
13:36 |
csharp |
dbwells: oops - just a sec |
13:36 |
mrpeters |
we're trying to sort our debs for 2.6 at archive.georgialibraries.org...i figured Circ.pm was the most likely culprit but the deb installs the same version as the tarball |
13:37 |
dbwells |
csharp: (or Evergreen Master Debian, for that matter) |
13:37 |
mrpeters |
and open-ils.circ is definetly running with listener/drone, etc. |
13:37 |
csharp |
dbwells: I don't have control over the Debian VM |
13:38 |
csharp |
however, with mundungus up and running, creating one under everyone's control is easy ;-) |
13:38 |
dbwells |
csharp: that's fine, I'd just like to see one successful buildbot test before I package 2.6.1 today :) |
13:38 |
Dyrcona |
mrpeters: Not seen that one. |
13:38 |
csharp |
dbwells: ok, ubuntu 12.04 buildslave is back up |
13:39 |
dbwells |
csharp: sweet, thank you |
13:39 |
mrpeters |
isn't there an "introspect" command or something like that I can run in srfsh to see all of the api's for open-ils.circ that exist? |
13:40 |
Dyrcona |
mrpeters: Yes. introspect open-ils.circ |
13:41 |
mrpeters |
awesome, just wanted to make sure introspect was the right command |
13:41 |
mrpeters |
definetly not there |
13:42 |
mrpeters |
fwiw, i was still using the osrf_ctl.sh so perhaps that is the problem? |
13:42 |
|
vlewis joined #evergreen |
13:42 |
mrpeters |
we haven't programmed osrf_control into the debs yet |
13:42 |
Dyrcona |
mrpeters: I don't think so. You're probably missing something under Circ/ |
13:42 |
Dyrcona |
or, maybe action/publisher. |
13:43 |
mrpeters |
when you say under circ...do you mean the Circ.pm? |
13:43 |
mrpeters |
rootubuntu:/usr/local/share/perl/5.14.2/OpenILS/Application# rgrep "open-ils.circ.circ_modifier.retrieve.all" * |
13:43 |
mrpeters |
Circ.pm: api_name => 'open-ils.circ.circ_modifier.retrieve.all'); |
13:43 |
Dyrcona |
Nope. I mean under OpenILS/Application/Circ/ |
13:43 |
|
gsams joined #evergreen |
13:43 |
Dyrcona |
Well, there you go. |
13:44 |
mrpeters |
aha, awesome. i'll start diffing those |
13:44 |
mrpeters |
is there any way that one api would die, but the rest of open-ils.circ would still be running? |
13:45 |
jcamins |
Hey, does anyone happen to know why the EG project selected Dojo rather than jQuery? |
13:45 |
mrpeters |
it came up first in a google search, jcamins :P |
13:45 |
jcamins |
I'm having some trouble figuring out when to recommend Dojo instead of jQuery, and I thought someone here might have an answer. |
13:45 |
jcamins |
mrpeters: fair enough. |
13:45 |
Dyrcona |
mrpeters: I don't know. I've not seen that before. |
13:46 |
mrpeters |
im totally kidding jcamins |
13:46 |
Dyrcona |
mrpeters: Usually, what I see is I've made a typo in some code and the whole of open-ils.circ fails to load. |
13:46 |
jcamins |
mrpeters: oh. Well... that's still a perfectly legitimate reason to choose a JS framework. |
13:47 |
mrpeters |
Dyrcona: yeah, and i assume plenty have installed 2.6 from tarballs, so we just need to find our needle in the haystack :) |
13:48 |
Dyrcona |
mrpeters: Well, I don't make that assumption, but I've installed it from git. |
13:48 |
|
hbrennan joined #evergreen |
13:48 |
csharp |
dbwells: fedora buildslave was updated and is ready for testing... I don't know how to trigger a rebuild |
13:49 |
mrpeters |
yeah, ill fire up a new vm and install the old fashioned slow way :P |
13:49 |
Dyrcona |
I typically only see problems like that when I'm fooling around in development and have edited code. |
13:50 |
Dyrcona |
mrpeters: Try this: perl -c /usr/local/share/perl/5.14.2/OpenILS/Application/Circ.pm |
13:50 |
Dyrcona |
That'll report any syntax errors. |
13:51 |
mrpeters |
oh snap |
13:52 |
mrpeters |
http://pastie.org/9231545 |
13:52 |
mrpeters |
same on version of Circ.pm from tarball |
13:53 |
mrpeters |
i think i better do an install from the tarball and find out if there is actually a bug |
13:55 |
Dyrcona |
You're missing a dependency, mrpeters. |
13:55 |
mrpeters |
even better, thats an easy fix |
13:55 |
Dyrcona |
JSON::XS probably needs to be installed or one of those. |
13:55 |
mrpeters |
Stripe.pm? |
13:56 |
Dyrcona |
Well, make sure Stripe is installed, but it's complaining about JSON.pm. |
13:56 |
mrpeters |
does that come from cpan, or would libjson-perl take care of it? |
13:56 |
Dyrcona |
Ubuntu? |
13:56 |
mrpeters |
yeah, 12.04 |
13:56 |
jeff |
if you have an evergreen system and JSON::XS is not installed, you've probably missed a step. :P |
13:57 |
mrpeters |
oh, im sure we did. if its a new dependency we probably missed adding it to the debs |
13:57 |
Dyrcona |
I have libjson-xs-perl |
13:57 |
mrpeters |
we compiled Stripe, but i think we're missing libjson-xs-perl then |
13:57 |
Dyrcona |
libjson-xs-perl isn't a new requirement. |
13:58 |
mrpeters |
no? |
13:58 |
Dyrcona |
Probably any of the libjson-perl modules would work. |
13:58 |
Dyrcona |
No, not new. |
13:58 |
mrpeters |
interesting, wonder why we are just bumping into this |
13:58 |
mrpeters |
of course, we only built 2.5.2 debs and then jumped to 2.6.0 |
13:59 |
mrpeters |
weird thing is i have it already |
13:59 |
mrpeters |
opensrfubuntu:~$ dpkg -l | grep json |
13:59 |
mrpeters |
ii libjson-xs-perl 2.320-1build1 module for manipulating JSON-formatted data (C/XS-accelerated) |
13:59 |
mrpeters |
ii python-simplejson 2.3.2-1 simple, fast, extensible JSON encoder/decoder for Python |
14:00 |
Dyrcona |
Stripe is requiring JSON. |
14:01 |
jeff |
Evergreen typically does a "use JSON::XS;" and Business::Stripe does "use JSON;" |
14:01 |
Dyrcona |
Looks like I have a JSON-2.90 directory in .cpan/build |
14:01 |
mrpeters |
rootubuntu:/etc/ld.so.conf.d# dpkg -l|grep stripe |
14:01 |
mrpeters |
ii libbusiness-onlinepayment-stripe-perl 0.04-1 Interface for Stripe payment system. |
14:02 |
Dyrcona |
mrpeters: I installed Stripe via CPAN. |
14:02 |
mrpeters |
yeah, we built it into a deb |
14:02 |
mrpeters |
thats probably our problem |
14:02 |
dbwells |
csharp: I'm about to push in another commit, so that should trigger the build (I think). Either way, I'm not too worried about it. Thanks again. |
14:03 |
jeff |
when JSON > 2.mumble is installed, "use JSON;" actually uses JSON::XS -- but if you don't have JSON installed, and only have JSON::XS installed, "use JSON;" will fail like that. |
14:03 |
mrpeters |
Business::Stripe, correct? |
14:04 |
jeff |
mrpeters: if you built it into a deb and didn't set the deps right, then you'll end up with what you have now. |
14:04 |
Dyrcona |
mrpeters: installing libjson-perl might solve it for you. |
14:04 |
mrpeters |
yeah, i think we've got it narrowed down |
14:04 |
jeff |
I'd think that dh-make-perl should have handled that for you. |
14:04 |
jeff |
Or didn't you use dh-make-perl for some reason? |
14:04 |
mrpeters |
would have to defer to Andy on that...he built up the deb |
14:05 |
|
bshum joined #evergreen |
14:05 |
|
mceraso joined #evergreen |
14:08 |
mrpeters |
Dyrcona++ jeff++ much appreciated |
14:08 |
mrpeters |
you got us started down the right road now, we'll get this sorted |
14:08 |
mrpeters |
apt-get install libjson-perl did the trick! |
14:10 |
pinesol_green |
[evergreen|Mike Rylander] LP#1321017: Order constituent records by quality - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4897a05> |
14:15 |
egbuilder |
build #595 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/595 |
14:33 |
csharp |
yay! |
14:46 |
Dyrcona |
\o/ |
14:51 |
|
mmorgan1 joined #evergreen |
15:27 |
|
ericar joined #evergreen |
15:35 |
|
mmorgan1 joined #evergreen |
15:43 |
dbwells |
Last call for 2.6.1 and 2.5.5! Thanks. |
15:55 |
* jeff |
feels off by a day still |
16:02 |
jeff |
dbwells: do i have some time to sneak in bug 1296937? |
16:02 |
pinesol_green |
Launchpad bug 1296937 in Evergreen 2.5 "SIP2 Patron Information times out on too many checkouts/holds" (affected: 4, heat: 20) [Medium,Confirmed] https://launchpad.net/bugs/1296937 |
16:02 |
dbwells |
jeff: sure, just let me know when you are done. |
16:02 |
jeff |
thanks! |
16:17 |
|
edoceo joined #evergreen |
16:20 |
jboyer-isl |
mrpeters: just a quick note on that stripe deb, following the usual perl lib naming conventions it would be called libbusiness-stripe-perl, there's no stripe lib that works as a Business::OnlinePayment module. |
16:21 |
jboyer-isl |
It's not a big deal in either case though. |
16:28 |
pinesol_green |
[evergreen|Galen Charlton] LP#1296937: move the $force_bc parameter of ->charged_items() to an implementation method - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b5ddc81> |
16:31 |
jeff |
gmcharlt, tsbere: I seem to lack the ability to push to SIPServer's master branch. I'd like to push SIPServer working branch user/jeff/revert_charged_items_argument_position_change to finish off bug 1296937 |
16:31 |
pinesol_green |
Launchpad bug 1296937 in Evergreen 2.5 "SIP2 Patron Information times out on too many checkouts/holds" (affected: 4, heat: 20) [Medium,Confirmed] https://launchpad.net/bugs/1296937 - Assigned to Jeff Godin (jgodin) |
16:32 |
jeff |
oh. i might have access. |
16:32 |
tsbere |
jeff: You are on the access list |
16:33 |
jeff |
and there we go. |
16:33 |
jeff |
tsbere++ thanks for checking |
16:33 |
tsbere |
jeff: Figured I could either check, or change modes to "figure out why I can't get SIPServer to run on my dev machine right now". Checking was faster. |
16:34 |
jeff |
dbwells: I'm done. Thanks for your patience! |
16:34 |
dbwells |
jeff: thanks |
16:45 |
|
kbeswick joined #evergreen |
16:56 |
|
jwoodard joined #evergreen |
17:31 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
17:56 |
|
ktomita_ joined #evergreen |
18:41 |
|
timf joined #evergreen |
19:19 |
pastebot |
"gsams" at 64.57.241.14 pasted "How I solved the duplication of "Lost Materials", "Overdues", "Lost Materials Processing Fee" in that SQL Query" (61 lines) at http://paste.evergreen-ils.org/51 |
19:19 |
gsams |
Thought I'd share how I fixed the report I was asking about yesterday |
19:20 |
gsams |
I used a WITH statement and changed the original report to SELECT DISTINCT ON money.payment_view.id |
19:21 |
gsams |
Then basically select all from that cte and sort it like it originally was |
19:21 |
gsams |
then tack on the original union with the total row to that |
19:21 |
gsams |
bam, no more duplicated bills |
19:42 |
hbrennan |
gsams++ |
19:45 |
|
gsams joined #evergreen |
20:16 |
|
sseng joined #evergreen |
22:31 |
|
mmorgan1 joined #evergreen |
23:23 |
|
mmorgan1 joined #evergreen |
23:52 |
|
mmorgan1 joined #evergreen |