| 04:08 |
|
pmurray` joined #evergreen |
| 04:18 |
|
_bott_ joined #evergreen |
| 04:57 |
|
wsmoak joined #evergreen |
| 05:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:52 |
|
krvmga joined #evergreen |
| 08:12 |
|
akilsdonk_ joined #evergreen |
| 08:13 |
|
collum joined #evergreen |
| 10:03 |
krvmga |
collum++ |
| 10:08 |
|
berick joined #evergreen |
| 10:16 |
|
mllewellyn joined #evergreen |
| 10:43 |
* tsbere |
runs one last set of tests before responding to questions on launchpad |
| 10:43 |
tsbere |
Just dawned on me that some of the things I am seeing issues with I didn't test without the code in question loaded. |
| 10:45 |
bshum |
berick: Fwiw, I had problems with the bookbags too when websockets weren't working right on my test server. What I saw was two things: |
| 10:45 |
bshum |
1) if websockets was not turned on, then I got internal server errors when trying to add bibs to bookbags |
| 10:46 |
bshum |
2) if websockets was not accessible (like if it was port blocked or not running properly), then I also found myself being taken to a page where it would stop/break eventually with some popup in XUL client about too many redirects or something |
| 10:48 |
berick |
bshum: interesting... OK |
| 10:48 |
berick |
thanks |
| 10:48 |
bshum |
It was not clear to me that the intent was for these existing parts of the XUL client to remain working without websockets installed and functional. Given this criteria, I'll curiously follow along and see what else we can find before we move forward. |
| 10:50 |
berick |
bshum: yeah, the hope was websockets would only be needed if you wanted to experiment w/ the browser client |
| 10:52 |
* tsbere |
apparently deleted one thing too many and has to do a much deeper clean install than he originally intended. Whoops. |
| 10:52 |
* dbs |
guesses he should probably open a bug for the Makefile install branch |
| 10:52 |
bshum |
dbs: Ack, I knew I forgot to merge something last night |
| 10:53 |
bshum |
dbs: It was on my list, I just got distracted with so many tasty "signedoff" bugs |
| 10:55 |
bshum |
dbs: If you have time to open an LP, that'd be swell, but if you have other matters to attend to, I can finish testing and push your commit later this afternoon. |
| 10:57 |
|
jboyer-isl left #evergreen |
| 10:57 |
|
jboyer-isl joined #evergreen |
| 10:59 |
jboyer-isl |
I know I missed this yesterday, but does anyone have time to look at lp 1241644 ? It's a pretty basic change that we've been running with just fine since October. |
| 11:18 |
mmorgan |
ok, so the claimed returned item with 0 fines has a xact_finish date? that's why it's not showing in items out? |
| 11:18 |
jboyer-isl |
mmorgan, yes. |
| 11:18 |
|
tsbere joined #evergreen |
| 11:19 |
mmorgan |
eeevil: gotcha |
| 11:19 |
mmorgan |
jboyer-isl: I'd be interested in testing this one. |
| 11:19 |
mmorgan |
I think I can get kmlussier to load a sandbox |
| 11:21 |
mmorgan |
but this problem have any relation to lp 793550 ? Should these claimed returned items have an xact_finish? |
| 11:21 |
pinesol_green |
Launchpad bug 793550 in Evergreen 2.3 "xact_finish (prematurely?) set on claimed returned item if transaction balance reaches zero" (affected: 7, heat: 38) [Medium,Fix released] https://launchpad.net/bugs/793550 |
| 11:22 |
jboyer-isl |
eeevil: sure, I don't mean the number associated with an actor.usr. |
| 11:22 |
|
DPearl1 joined #evergreen |
| 11:45 |
|
tsbere joined #evergreen |
| 11:46 |
eeevil |
berick_: unless you were depending on the "last lvalue gets returned" behavior of subs there? (but that seems a bit too magical to me) |
| 11:50 |
* bshum |
doesn't know what that commit references to, so will take eeevil's word for it :) |
| 11:51 |
eeevil |
bshum: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=9e8a245ff181e3b837e1e60ef60c8eb3d8b0f190 |
| 12:05 |
|
berick joined #evergreen |
| 12:05 |
eeevil |
well, magic last lval does work in a simple test... but I'm still going to offer a branch bringing back the returns |
| 12:09 |
|
akilsdonk joined #evergreen |
| 12:13 |
|
jwoodard joined #evergreen |
| 12:14 |
eeevil |
hold pull list was only changed (AFAICT) in that commit above. The substantive change to the pre-websockets code was the lack of 'return's, so if you have a test env handy: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/web-staff-phase1-squash-with-returns |
| 12:15 |
eeevil |
note that http://paste.evergreen-ils.org/22 suggests it should work, but the sub is much more complicated than that test |
| 12:25 |
bshum |
eeevil: Hmm, what was the problem with the holds pull list in the client? Or is this a web client issue we're troubleshooting? |
| 12:28 |
eeevil |
bshum: I'm sorry ... I thought you were saying (up there) that the entry point for the current one broke until you set up (and un-firewalled) websockets. did I misunderstand? |
| 12:28 |
* bshum |
didn't notice any breakage in the XUL clients |
| 12:44 |
jeff |
I'm tempted to find out how much Nick Offerman would charge for some "custom Carl Kassell answering machine message" style audio or video of suitable variations on his Eggs and Bacon bit. |
| 12:45 |
jeff |
``Just give me all the ILS data you have. Wait, wait. I'm worried what you just heard was, "Give me a lot of data." What I said was, "Give me all the ILS data you have". Do you understand?'' |
| 12:46 |
eeevil |
tsbere: do you want to amend your comment on the ticket, WRT having to set up websockets to get the normal (xul staff client, normal tpac) stuff working? I think we've agree that that's not true, bshum? |
| 12:47 |
bshum |
eeevil: I have to test further as far as turning off my websockets. I got mine to work and didn't look back to see what wasn't working with them on. |
| 12:48 |
jeff |
the followup is a bit more of a mouthful, though: |
| 12:48 |
jeff |
``Just give me all the details on your authentication options. Wait, wait. I'm worried what you just heard was, "Give me a one page summary of your authentication options." What I said was, "Give all of the details on your authentication options" Do you understand?'' |
| 12:48 |
bshum |
eeevil: aka, my testing assumption was (get websockets working), find out if anything else was broken. Not so much, install it all, and see what's just plain broken. |
| 12:49 |
bshum |
But I'm getting there. Have to start a fresh VM. |
| 12:49 |
gmcharlt |
bshum: speaking of fresh VMs -- Debian testing no longer includes libemail-send-perl |
| 12:50 |
gmcharlt |
deprecated in favor of libemail-sender-perl |
| 12:50 |
gmcharlt |
wheee! |
| 12:51 |
bshum |
o.O |
| 12:53 |
|
geoffsams joined #evergreen |
| 12:53 |
eeevil |
bshum: gotcha. I think the low water mark for merging is "does this branch break anything if none if its new features are turned on" ... the high water mark is probably "its features work and so do the ones from outside this branch". in between those, it's a judgement call about the tradeoff between getting it out for user testing (and bug finding, of all varieties, of course!) vs pure bug-free code (regardless of whether it's in use or not) in a |
| 12:53 |
eeevil |
release. |
| 12:54 |
gmcharlt |
bug 1362260 |
| 12:54 |
pinesol_green |
Launchpad bug 1362260 in Evergreen "Email::Send is deprecated" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1362260 |
| 12:55 |
|
ericar joined #evergreen |
| 12:56 |
eeevil |
IOW, and IMHO, if simple inclusion (without websockets turned on) does not break existing functionality, I think it should go in. If turning them on breaks something in either xul or web staff client, then we should loudly explain that, and say "really, not for production yet!". if it does not break anything (that we can find) then it should go in and broad testing should be encouraged. my $0.02 |
| 12:57 |
eeevil |
(and IIUC the testing so far bookbags inside the web staff client, but not in the xul or tpac modes, are having issues ... but nothing else?) |
| 12:57 |
dbs |
Of course, determining if existing functionality is broken is tough without a comprehensive walkthrough of system features etc. |
| 12:57 |
dbs |
See historical effort to test big XUL staff client changes and we still didn't catch everything |
| 12:57 |
eeevil |
dbs: absolutely |
| 12:58 |
dbs |
Maybe we could at least reuse that list of manual tests as a starting point :) |
| 12:58 |
eeevil |
see also: acq "preview" |
| 12:59 |
eeevil |
(granted, this is 99.9% new front-end code only, with almost no backend logic that hasn't seen real use) |
| 13:05 |
|
jihpringle joined #evergreen |
| 16:49 |
csharp |
and it takes a long time, even on SSD |
| 16:51 |
|
buzzy joined #evergreen |
| 16:53 |
tsbere |
csharp: Well, I assume it takes a long time when the "merge from" user(s) have a lot of circs/holds. Probably faster when they don't. ;) |
| 17:00 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:09 |
|
mdriscoll left #evergreen |
| 17:20 |
csharp |
yeah - we're going to be processing a large dupe file this weekend. I guess it's just going to take a while ;-) |
| 17:24 |
|
mmorgan left #evergreen |
| 18:18 |
bshum |
gmcharlt++ # pointing out to me what I've been doing wrong testing holds this whole week :( |
| 18:19 |
bshum |
I've updated bug 1350042 with my findings this afternoon. So far I'm not seeing any further problems with my test system running OpenSRF master + Evergreen web client branch. |
| 18:19 |
pinesol_green |
Launchpad bug 1350042 in Evergreen "Browser staff client / merge prep" (affected: 1, heat: 6) [Wishlist,Confirmed] https://launchpad.net/bugs/1350042 |
| 19:54 |
|
kmlussier joined #evergreen |
| 20:40 |
pinesol_green |
[evergreen|Dan Scott] LP#1362210: Install PostgreSQL packages where we can - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=57f390e> |
| 00:20 |
|
dbwells_ joined #evergreen |
| 00:21 |
|
remingtron_ joined #evergreen |
| 03:15 |
|
artunit_ joined #evergreen |
| 05:01 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:56 |
|
kmlussier joined #evergreen |
| 06:56 |
|
wsmoak joined #evergreen |
| 06:56 |
|
wsmoak joined #evergreen |
| 08:23 |
|
Shae joined #evergreen |
| 08:34 |
|
ericar joined #evergreen |
| 08:38 |
|
krvmga joined #evergreen |
| 08:39 |
csharp |
it has only taken over 3 years, but I'm finally testing tsbere's fix for bug 778989 |
| 08:39 |
pinesol_green |
Launchpad bug 778989 in Evergreen "Owning lib of asset.copy_location not visible in Item Attributes Editor UI" (affected: 2, heat: 12) [Undecided,In progress] https://launchpad.net/bugs/778989 - Assigned to Thomas Berezansky (tsbere) |
| 08:40 |
kmlussier |
csharp++ |
| 08:43 |
|
mdriscoll joined #evergreen |
| 10:09 |
csharp |
ok - this is why I'm asking :-) |
| 10:10 |
tsbere |
csharp: The IF (TG_OP = 'UPDATE') THEN block is "if this is an update, skip if the location and call number haven't changed" (though adding in circ lib may be a good potential idea) |
| 10:11 |
tsbere |
csharp: If the location has changed, the call number has changed, or TG_OP is not UPDATE (like, say, it is INSERT) then it should move onto the SELECT statement and beyond |
| 10:11 |
csharp |
ah - gotcha |
| 10:11 |
csharp |
okay - then let me keep testing with that in mind |
| 10:12 |
tsbere |
csharp: Adding in "AND NEW.circ_lib = OLD.circ_lib" into the location/call number IF check would be enough for that part. |
| 10:14 |
csharp |
got it |
| 10:15 |
jeff |
csharp: phew. i'm glad you didn't execute @developer more than twice in a row a few minutes ago. three times in a row summons either Steve Ballmer or Beetlejuice -- I'm not sure which. |
| 14:55 |
kmlussier |
jihpringle: I would leave it and let the developer decide if it should be removed or not. |
| 14:55 |
kmlussier |
jihpringle: But post a comment on the bug letting them know how it worked. |
| 14:55 |
jihpringle |
I'm posting the comment now |
| 14:56 |
kmlussier |
jihpringle++ #testing |
| 15:02 |
jihpringle |
kmlussier: would you load the fix for 1010027 when you have a moment? |
| 15:04 |
kmlussier |
jihpringle: Absolutely! |
| 15:04 |
jihpringle |
thanks :) |
| 16:13 |
yboston |
Is Leam Whalen on IRC now by any chance? does anyone know his IRC nickname? |
| 16:14 |
yboston |
*Liam (sorry) |
| 16:14 |
kmlussier |
ldw ^ ^ |
| 16:14 |
yboston |
kmlussier: thanks! |
| 16:15 |
yboston |
ldw: do you have time for me to ask you a couple of quesiotns? |
| 16:15 |
yboston |
ldw: it concerns a bug I am testing today that you wrote code for https://bugs.launchpad.net/evergreen/+bug/1282286 |
| 16:15 |
pinesol_green |
Launchpad bug 1282286 in Evergreen 2.6 "Pressing Shift-F3 in the MARC editor results in invalid lose data warning" (affected: 2, heat: 14) [Undecided,New] |
| 16:19 |
tsbere |
DPearl: Your img branch seems to rename the images, but that is all it does. Did you forget to commit the changes to the references to the images? |
| 16:21 |
* collum |
didn't get to play in Evergreen as much as he wanted to today |
| 16:23 |
dbs |
tsbere: that's the same message I put in the bug :) |
| 16:24 |
tsbere |
dbs: I noticed when I went to add to the bug myself. |
| 17:02 |
kmlussier |
jihpringle: Are you ready for the next one? |
| 17:03 |
jihpringle |
I am, though a fix has since been committed for it |
| 17:03 |
jihpringle |
I'd like to test it though to see what's in master since I think we have further fixes on our system |
| 17:04 |
kmlussier |
Ah, I hadn't even noticed which one it was. We also had another request for that one to be loaded on a Sandbox. I'll load it now. |
| 17:04 |
jihpringle |
thanks |
| 17:09 |
kmlussier |
jihpringle: Ha ha. I clearly wasn't thinking. Since it's in master now, I didn't need to reload things. It would have been there the last time I updated your VM. Unfortunately, I didn't realize it until after I blew away your VM. It should be ready again in about 15 minutes. |
| 17:09 |
jihpringle |
didn't occur to me either, thanks :) |
| 17:13 |
kmlussier |
Just a note that we do have a handful of bugs with signedoff tags if anyone is looking for already-tested code to push into masters. http://bit.ly/1takjv9 |
| 17:13 |
* kmlussier |
should probably feed her children. |
| 17:16 |
* mmorgan |
is tired from bug squashing. |
| 17:17 |
mmorgan |
kmlussier: I am finished testing 1012308, if you need to know about that (before or after you feed your children) ;-) |
| 17:20 |
kmlussier |
mmorgan: OK, thanks for your squashing efforts today! |
| 17:20 |
|
mdriscoll left #evergreen |
| 17:21 |
mmorgan |
and thanks for yours!! |
| 17:26 |
yboston |
OK |
| 17:26 |
kmlussier |
MassLNC is planning to keep theirs up for a while. |
| 17:27 |
kmlussier |
That is, ours. |
| 17:27 |
jihpringle |
kmlussier: I know the focus of today was squashing bugs but I also created a few new bug reports for minor issues I came across setting up serials testing |
| 17:28 |
jihpringle |
I noticed that you've reported a bunch of the serials bugs |
| 17:28 |
jihpringle |
when you have time could you confirm my new bugs? |
| 17:28 |
kmlussier |
jihpringle: Yup. Reporting bugs is good too. They can't get fixed if nobody knows about them. :) |
| 17:28 |
jihpringle |
https://bugs.launchpad.net/evergreen/+bug/1361786 |
| 17:28 |
pinesol_green |
Launchpad bug 1361786 in Evergreen "Copy Template Editor Summary Displays Database IDs Rather Than Helpful Information" (affected: 1, heat: 6) [Undecided,New] |
| 17:30 |
jihpringle |
it's the perfect time to report bugs :) |
| 17:32 |
|
mmorgan joined #evergreen |
| 17:32 |
|
mmorgan left #evergreen |
| 17:34 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:50 |
|
serflog joined #evergreen |
| 18:50 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 20:18 |
kmlussier1 |
It would be nice to see bug 1189556 go in since it just fixes a small typo and has had a sign-off for more than a year. |
| 13:46 |
pinesol_green |
[evergreen|Mike Rylander] LP#800478: Stamping upgrade script for fund transfer fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4e40c88> |
| 13:57 |
bshum |
Hmm |
| 13:58 |
dbs |
Uh oh. bshum's a-thinking |
| 13:58 |
bshum |
I'm just testing to see what happens if the websockets portion isn't deployed right and it looks like bits of the XUL staff client die off (the stuff that was changed) |
| 13:59 |
bshum |
At some point today, I'd like to commit the first phase web client code to master, but I just wanted to see what other potential ramifications there are to having it |
| 14:15 |
|
mnsri joined #evergreen |
| 14:17 |
bshum |
So yeah, without websockets running, it's an unhappy internal server error using the catalog for things like holds/lists. |
| 14:17 |
bshum |
So it's definitely required once we add it in |
| 14:22 |
|
RBecker joined #evergreen |
| 14:25 |
* dbs |
throws an (untested!) branch at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/db_server_packages |
| 14:37 |
bshum |
Hmm |
| 14:55 |
bshum |
Otherwise, I was thinking to commit what he has so far for ease of use and then fix squeeze later on. |
| 14:55 |
dbs |
gmcharlt: also, I didn't actually touch the debian-squeeze stuff because the databse server requirements for squeeze weren't listed in the README |
| 14:55 |
eeevil |
kmlussier: I'll see if there's any drift that would stop it. I suspect 2.6 is fine, though. I'll look... |
| 14:56 |
kmlussier |
eeevil: We may also have somebody who can test it on 2.6 if it's needed. |
| 14:57 |
jeff |
but one thing that stands out to me is that as currently planned, the number of Debian LTS releases with "current support" would be fewer than the number of Ubuntu LTS releases with "current support" |
| 14:58 |
jeff |
...or perhaps about the same. nevermind me. |
| 14:59 |
dbs |
bshum: don't commit yet, there's some extra quoting in the packages that won't work |
| 14:59 |
dbs |
yum -y install "gcc perl-Business-ISBN ..." postgresql postgresql-contrib ... |
| 15:00 |
bshum |
dbs: Ah okay, no problem. I was going to try it on a test server first, but I appreciate the warning. |
| 15:00 |
dbs |
it treats the double-quoted string as a single package name :) |
| 15:00 |
bshum |
Heh |
| 15:00 |
* dbs |
will tweak |
| 16:51 |
Bmagic |
kmlussier++ |
| 17:00 |
kmlussier |
tsbere++ #Extracting Concerto login information for me. http://wiki.evergreen-ils.org/doku.php?id=qa:concerto_logins |
| 17:11 |
|
mmorgan left #evergreen |
| 17:19 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:57 |
|
remingtron__ joined #evergreen |
| 17:58 |
|
DPearl1 joined #evergreen |
| 17:58 |
|
vlewis_ joined #evergreen |
| 07:43 |
bshum |
For the apache 2.4 websockets config |
| 07:44 |
|
mrpeters joined #evergreen |
| 07:44 |
csharp |
bshum: nope - let me apply those too |
| 07:44 |
bshum |
And srfsh passes the math test? |
| 07:45 |
csharp |
actually... no |
| 07:45 |
bshum |
I didn't get any errors on start, but I got no response error from srfsh |
| 07:46 |
bshum |
I bet if you look at osrfsys.log you'll see some sort of 500 error |
| 09:39 |
|
sarabee joined #evergreen |
| 10:04 |
|
Dyrcona joined #evergreen |
| 10:08 |
|
krvmga joined #evergreen |
| 10:08 |
* tsbere |
spins up a trusty VM on masslnc's server to do a test of clean install of opensrf/evergreen master there |
| 10:09 |
krvmga |
in browse search (eg 2.5) , is there a global option somewhere to tell the system to ignore initial articles? |
| 10:09 |
krvmga |
(a, an, the) |
| 10:09 |
krvmga |
for example |
| 11:14 |
gmcharlt |
tsbere: I've only just started looking at it, but thus far my assumption is that it's the patch for 1350457 that's triggering it |
| 11:15 |
tsbere |
gmcharlt: Want file and line number? |
| 11:15 |
gmcharlt |
yeah |
| 11:16 |
tsbere |
gmcharlt: Application.pm line 562 (I search for "caller's" to grab the comment on the end of the line) - the $self->session looks to be the problem. My tests seem to show that $self isn't actually a ref at all, but I could have written that wrong. |
| 11:16 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 11:17 |
* tsbere |
isn't sure how that ends up working |
| 11:18 |
|
asimon joined #evergreen |
| 11:18 |
gmcharlt |
tsbere: my plan is to poke at that for a bit, but just revert if necessary |
| 11:43 |
mrpeters |
just trying to decide if i should roll with current opensrf on 14.04 for 2.7 or wait it out, thanks! |
| 11:43 |
gmcharlt |
mrpeters: yeah, it will basically be out just before 2.7.0 |
| 11:43 |
gmcharlt |
as far as what version to use, 2.3.0 is fine *unless* you want to try out the web-based staff client bits that are targetedf for 2.7-beta2 |
| 11:43 |
mrpeters |
cool, its mostly for testing our GenaSYS stuff so I'll await the alpha, since we're using beta2 for Evergreen |
| 11:44 |
|
phasefx_ joined #evergreen |
| 11:44 |
bshum |
Hmm |
| 11:45 |
bshum |
gmcharlt: So the changes in opensrf_core.xml for things like the loglength and msg_size_warn need to be reflected in the copy for Evergreen too I guess? |
| 12:09 |
gmcharlt |
moving on... my next steps for OpenSRF today are seeing if the CORS support patch works, then writing some release notes and releasing the alph |
| 12:09 |
gmcharlt |
a |
| 12:10 |
|
akilsdonk joined #evergreen |
| 12:10 |
bshum |
I just finished getting the web client squash branch on my test server |
| 12:11 |
bshum |
I'm trying to figure out what I missed to get it actually functional |
| 12:11 |
bshum |
And I think whatever I missed is leaving me with broken hold placement / bookbags in the staff client's catalog view. |
| 12:11 |
bshum |
The main client |
| 12:11 |
bshum |
*XUL |
| 12:11 |
gmcharlt |
bshum: I set up a web-based staff client demo server the other day (independent of berick), and I can compare notes if you want |
| 12:12 |
bshum |
Those were two areas berick specifically mentioned to test and both are not functioning. |
| 12:12 |
bshum |
gmcharlt: Thanks, I'm definitely in uncharted territory |
| 12:12 |
bshum |
There's comments on the ticket about installing dependencies for the web client |
| 12:13 |
bshum |
But I'm not seeing those reflected in the README or any associated files in the root level |
| 12:13 |
bshum |
I'm checking around to see what I might have missed |
| 12:14 |
gmcharlt |
bshum: ./Open-ILS/web/js/ui/default/staff/README.install |
| 12:14 |
bshum |
gmcharlt: Ahh, there we are. |
| 12:14 |
bshum |
Thanks! |
| 14:43 |
gmcharlt |
having multiple mentors would be good, based on GSoC experience |
| 14:45 |
graced |
kmlussier: I think I'd feel better if we worked backwards - ID some projects that need doing and are accessible and get committed mentors who know that area and then ask for the funding? |
| 14:45 |
bbqben |
kmlussier re: the $6250 ... |
| 14:45 |
yboston |
For the record, I have used three seperate MLS students as interns. I ended up spending a huge amount of time training them for what I needed them to do (build test servers, AciiDoc, etc.). Luckily I have saved some of my trainign materials, and would be willing to help mentor |
| 14:45 |
bbqben |
...is there flexibility in how the funds are applied? |
| 14:45 |
kmlussier |
Flexibility in what sense? |
| 14:46 |
graced |
The sponsorship per intern includes $5,500 (USD) stipend, $500 travel allowance, and a $250-500 administrative fee for the GNOME Foundation. |
| 15:06 |
RoganH |
montgoc1: great! |
| 15:06 |
pmurray |
Any reason not to use an RSS feed from http://jobs.code4lib.org/jobs/Evergreen/ |
| 15:07 |
* pmurray |
goes back into lurking mode. |
| 15:07 |
bshum |
#info Ben Shum wrote a blog post about 2.7.0-beta1 at http://evergreen-ils.org/evergreen-2-7-0-beta1-released/ |
| 15:07 |
bshum |
Big thanks to everyone who participated in development, testing, writing release notes |
| 15:07 |
bshum |
I think it's the first time we've had such comprehensive coverage of all new features in the notes on first pass. |
| 15:08 |
bshum |
Later today/tomorrow, we'll make a final call on the web client preview going in (pending further testing) |
| 15:08 |
csharp |
pmurray: nice - I didn't know about that |
| 15:08 |
bbqben |
bshum ++ |
| 15:08 |
bshum |
I expect that we'll get some more work done during the Bug Squashing Day (see http://evergreen-ils.org/evergreen-bug-squashing-day/) |
| 15:08 |
kmlussier |
bshum++ |
| 15:08 |
csharp |
bshum++ |
| 15:08 |
bshum |
And that'll lead us to a better 2.7.0-RC1 if all goes according to timeline |
| 15:09 |
graced |
As an aside, Equinox will have the public test/demo server for the web based client up by tomorrow. |
| 15:09 |
yboston |
bshum++ |
| 15:09 |
RoganH |
graced: yay! |
| 15:10 |
bbqben |
Wahoo, thanks for the update bshum and graced |
| 15:22 |
pinesol_green |
kmlussier: Karma for "bbqben" has been increased 24 times and decreased 0 times for a total karma of 24. |
| 15:22 |
gmcharlt |
bshum: I have a lead on that error you were getting bringing up the patron search form |
| 15:26 |
gmcharlt |
bshum: this both explains and solves the problem - http://paste.lisp.org/display/143457 |
| 15:26 |
bshum |
gmcharlt: Aha! |
| 15:26 |
* bshum |
tests |
| 15:26 |
gmcharlt |
upshot is that JSON2js in OpenSRF is now also stricter as a result of berick's change |
| 15:27 |
Dyrcona |
bbqben++ :p |
| 15:46 |
gmcharlt |
bshum: bug 1359934 |
| 15:55 |
bbqben |
pmurray no worries at all! gmcharlt can be distracting for all of us ;) |
| 15:56 |
kmlussier |
pmurray: Ha ha. Maybe we can have gmcharlt tweet at every meeting to get more people to poke their heads in. |
| 15:56 |
pmurray |
In case it was missed, the tweet was https://twitter.com/gmcharlt/status/502524970052771840 |
| 16:00 |
bshum |
gmcharlt: Patch looks good and my test server's XUL patron search is happier now. |
| 16:03 |
bshum |
I'll get it signed and into master as a bug fix |
| 16:07 |
bshum |
So far, not encountering other errors in the XUL client |
| 16:11 |
pinesol_green |
[evergreen|Galen Charlton] LP#1359934: prevent error opening patron search form - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=646d132> |
| 16:29 |
|
tspindler left #evergreen |
| 16:43 |
kmlussier |
Weeee! I just set up my first Sandbox with a working branch loaded. |
| 16:43 |
bshum |
tsbere++ |
| 16:45 |
kmlussier |
Bmagic++ #Setting up Sandboxes from MOBIUS |
| 16:46 |
kmlussier |
Now we just need more people to request them. :) |
| 17:08 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:11 |
|
mmorgan left #evergreen |
| 17:14 |
kmlussier |
Hmmm...is there an easy way to figure out what staff/user logins can be used with Concerto? It might be nice to provide that info on a wiki page somewhere. |
| 17:17 |
|
mdriscoll left #evergreen |
| 17:24 |
* kmlussier |
should stop testing bug fixes and save it for Bug Squashing Day. |
| 17:24 |
kmlussier |
Have a nice night everyone! |
| 18:08 |
|
remingtron_ joined #evergreen |
| 18:08 |
|
dbwells_ joined #evergreen |
| 18:21 |
ktomita |
Is the fact that a user is also an OverDrive user stored somewhere in the Evergreen database? |
| 04:46 |
|
dbwells__ joined #evergreen |
| 05:10 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:44 |
|
wsmoak joined #evergreen |
| 05:44 |
|
wsmoak joined #evergreen |
| 06:26 |
|
pmurray joined #evergreen |
| 13:30 |
|
ericar_ left #evergreen |
| 13:31 |
gmcharlt |
kmlussier: sure; since you'll be following the EOB discussions tomorrow, may I task you with putting out that call for volunteers? |
| 13:31 |
kmlussier |
Sure |
| 13:32 |
gmcharlt |
#action kmlussier will put out a call for a volunteer for somebody to curate the job listings |
| 13:32 |
gmcharlt |
#action gmcharlt will install the WP Job Manager plugging for testing |
| 13:33 |
gmcharlt |
any other discussion regarding the jobs listing service? |
| 13:34 |
RoganH |
I'm willing to work on the job listings. |
| 13:35 |
kmlussier |
RoganH++ |
| 13:35 |
gmcharlt |
#info Rogan Hamby has volunteered to assist with the job listings |
| 14:44 |
bshum |
kmlussier: Yeah well, I hate those being there too ;) |
| 14:44 |
bshum |
As being generally intrusive to my screen real estate |
| 14:45 |
Dyrcona |
See, I just don't use my phone for the web unless I really have to. |
| 14:45 |
collum |
I tested on a clean install. I don't find it intrusive, but it is green links on a green background. Another option would be a drop-down with the 3 search options on the same line as the 'Go to' drop-down. |
| 14:46 |
Dyrcona |
My phone's main purpose seems to be the playing of Candy Crush. |
| 14:46 |
Dyrcona |
collum++ |
| 14:46 |
kmlussier |
I used to use my phone for the library catalog all the time (when I had a smarter phone). Easier to use than looking something up on a public workstation. |
| 14:46 |
Dyrcona |
collum: I followed up with a muddled message that I think the ids of the added links should be used. |
| 14:47 |
kmlussier |
collum: Yes, thanks for the comment and testing! I saw that. I think she can probably fix that up. |
| 14:47 |
bshum |
Oh, so is that why I can't see the links on the clean master :) |
| 14:47 |
Dyrcona |
I got distracted while editing the comment and it didn't come out quite perfect. |
| 14:48 |
Dyrcona |
You can see them just fine at http://jasondev.mvlcstaff.org/, but then I'd need to give you an account. |
| 14:49 |
bshum |
Switched to responsive view on Firefox to see the box spaces |
| 14:50 |
Dyrcona |
collum: We use ids a lot in the existing css, and since the ids are in the new html, why not? |
| 14:50 |
Dyrcona |
But I get the point, classes can be more flexible, since ids are supposed to be unique per document. |
| 14:50 |
kmlussier |
collum++ #testing |
| 14:51 |
bshum |
I guess it depends on how prominently you want search to be made to end users :) |
| 14:51 |
* bshum |
supposes it could work this way |
| 14:52 |
* berick |
just pulled a Kendall Square walking map from his bag |
| 14:55 |
berick |
i don't doubt it |
| 15:00 |
bshum |
The "search:" label in strong is tough to read with the green background too. Black on dark green is a bit hard to make out. |
| 15:17 |
kmlussier |
bshum: I'm guessing that when she's working to address the issues collum reported, she'll use colors that work best with the green background. But I would recommend adding that kind of feedback to the LP bug since she's not here. |
| 15:17 |
* dbs |
recommends wave.webaim.org for accessibility testing for things like contrast |
| 15:18 |
dbs |
(but then again, not sure that's going to help for mobile stylesheet. hrm.) |
| 16:29 |
|
tspindler left #evergreen |
| 16:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:00 |
pinesol_green |
[opensrf|Bill Erickson] LP#1316245: JS now uses browser-native JSON routines - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=6c3b100> |
| 17:10 |
pinesol_green |
[opensrf|Mike Rylander] LP#1343578: Add support for log tagging - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=512f77b> |
| 17:10 |
pinesol_green |
[opensrf|Bill Erickson] LP#1343578: Perl/C syslog "logtag" additions. - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=2f4ed86> |
| 17:10 |
pinesol_green |
[opensrf|Galen Charlton] LP#1343578: document <logtag> in the example opensrf_core.xml - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=54da75b> |
| 17:12 |
kmlussier |
Have a nice night everyone! |
| 17:13 |
|
mmorgan left #evergreen |
| 17:16 |
pinesol_green |
[opensrf|Bill Erickson] LP#1341687 listeners log/drop XMPP error msgs - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=6cdd525> |
| 00:47 |
|
mnsri joined #evergreen |
| 05:31 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:29 |
|
ktomita joined #evergreen |
| 06:29 |
|
chatley joined #evergreen |
| 06:47 |
|
wsmoak joined #evergreen |
| 10:18 |
|
Dyrcona joined #evergreen |
| 10:36 |
|
Shae joined #evergreen |
| 10:38 |
|
mdriscoll joined #evergreen |
| 11:11 |
kmlussier |
I'm about to add a post to the community blog re: bug squashing day, but want to share this link again to make sure everything fits in with community procedures on testing/wrangling bugs. http://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing:2014-08-26 |
| 11:14 |
kmlussier |
Also, I'll probably do a quick video on how to sign off on bugs with Git GUI, but I had also floated an idea on the list last month about allowing people to sign off via a comment on LP. gmcharlt was the only person to respond to that question. http://markmail.org/message/ndjxvc7po4rpn3cg |
| 11:42 |
bshum |
kmlussier: I'm generally fine with gmcharlt's suggestion as long as we know that the person who says they've tested it comes from a site where we have some previously known presence (i.e. someone who actually loaded the patch to a server for testing) |
| 11:42 |
bshum |
Assuming a non-developer person is to the one giving the nod to signoff via LP. |
| 11:43 |
bshum |
I generally assume this to be true anyways, but it's one of those things we'll eyeball I guess. |
| 11:43 |
gmcharlt |
bshum: I think we are more likely to get more testers if we assume good faith until proven otherwise |
| 11:44 |
bshum |
gmcharlt: Sure, I've generally committed based on whichever signoffs I can get anyways :) |
| 11:45 |
bshum |
But it's good to be clear on that upfront, thanks. |
| 11:46 |
kmlussier |
Do we want to ask that they use specific language when adding the comment to the LP bug? |
| 11:47 |
kmlussier |
Using the language gmcharlt used in his e-mail: "I have tested this code and consent to signing off on it."? |
| 11:48 |
bshum |
Some variant of "We tested this and it looks good to us, please add our signoff" seems fine to me. As long as they generally understand what it means to signoff on code. (aka, the DCO) |
| 11:48 |
gmcharlt |
... "with my email address and name or consistent alias" |
| 11:48 |
bshum |
Ah good addition, gmcharlt++ |
| 11:48 |
* Dyrcona |
wonders if anyone would notice opensrf.settings and open-ils.cat restarting in the middle of the day. |
| 11:50 |
gmcharlt |
well, it /is/ the meaning -- for patch authors |
| 11:50 |
bshum |
Ahh, authors, gotcha. |
| 11:51 |
bshum |
Got it now. |
| 11:51 |
gmcharlt |
"Tested-by" would be more clear, but until git has a convenient --add-tested-by switch... |
| 11:52 |
bshum |
Hehe |
| 12:06 |
Dyrcona |
Signed-off-by means, "I approve this commit," which implies, "I tested this commit." |
| 12:14 |
kmlussier |
gmcharlt: I added the sign-off text here. http://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing:2014-08-26&#testing_bugs Is this what you had in mind? |
| 12:15 |
gmcharlt |
kmlussier: +1 |
| 12:15 |
bshum |
+1 |
| 16:49 |
sseng_ |
yboston: =) |
| 17:04 |
|
mmorgan left #evergreen |
| 17:06 |
dbs |
@later tell kmlussier you are cryptic :) |
| 17:06 |
pinesol_green |
dbs: The operation succeeded. |
| 17:14 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:33 |
mllewellyn |
sseng_: my understanding is that 151 would not control 710. Tag 110 should control a 710 |
| 17:35 |
sseng_ |
mllewellyn: got it. that was my understanding as well. It's just, we have a bib that was in an export to backstage, and it has a 710 tag. It appears to be the only bib that could possibly generate an authority record, except that authority record heading is a 151 main heading. |
| 17:38 |
mllewellyn |
sseng: I've seen headings for the United States that would appear to be treating as a corporate body, but was a 151 instead. Maybe your original 710 was improperly tagged? |
| 09:15 |
pinesol_green |
csharp: Obviously. |
| 09:16 |
berick |
heh |
| 09:21 |
|
DPearl joined #evergreen |
| 09:21 |
csharp |
wow - SSDs, where have you been all my (Evergreen-administering) life? |
| 09:22 |
csharp |
based on my initial tests, our upgrades will cease to need multiple day-long downtimes |
| 09:24 |
bradl |
ssd++ |
| 09:25 |
bradl |
csharp: what's your setup? /me gets a coke and a moonpie and sits in the rocking chair, awaiting |
| 09:25 |
csharp |
heh |
| 09:26 |
csharp |
we have 3 Dell R815s with 512 GB RAM and 4 480 GB SLC SSDs in RAID5 (I think) |
| 09:27 |
csharp |
with a 4th identical server for prototyping and testing |
| 09:27 |
|
kmlussier joined #evergreen |
| 09:27 |
csharp |
oh, and 64 cores |
| 09:28 |
csharp |
it's really kind of crazy |
| 09:28 |
bradl |
hmm, even with RAID-5, which is probably one of the worst I/O performant schemes |
| 09:28 |
csharp |
it may be another scheme - awitter set it up |
| 09:29 |
bradl |
well, that's awesome |
| 15:29 |
kmlussier |
It could be help in specing out the goals. Coding. And funding may need to come into play too. |
| 15:30 |
kmlussier |
kakes: Yes, I think doing it offline makes sense. |
| 15:31 |
kakes |
Ok. Being new to the community does it sound reasonable that this could be rated by the end of August? |
| 15:31 |
jihpringle |
do we want institutions to be saying what they can contribue? coding, funding, testing etc. |
| 15:31 |
|
hthepas joined #evergreen |
| 15:31 |
kmlussier |
jihpringle: Yes, that's what I was thinking. |
| 15:31 |
yboston |
jihpringle: I would like to see that |
| 17:00 |
Dyrcona |
Nope. Take that back. |
| 17:01 |
Dyrcona |
credit card payments inherit from bnm_desk_payment, so they'll be there. |
| 17:01 |
Dyrcona |
Anyway, time for me to go home. |
| 17:06 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:06 |
|
mdriscoll left #evergreen |
| 17:09 |
phasefx |
I think another one of those startup race conditions ^ |
| 17:09 |
|
mmorgan left #evergreen |
| 05:08 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:24 |
|
dbwells_ joined #evergreen |
| 05:26 |
|
dreuther joined #evergreen |
| 05:35 |
|
csharp_ joined #evergreen |
| 16:03 |
tsbere |
jeff: Well, I don't use different templates. I feed the one template set information that causes it to act differently. |
| 16:04 |
* tsbere |
hasn't actually figured out how to safely do the hostname trick with perl variable changes |
| 16:04 |
* tsbere |
also has no reason to figure that out, which is probably why he hasn't |
| 16:05 |
jeff |
in testing, i've just ripped the /eg location out of eg_vhost.conf and included it in each different virtualhost with different template PerlAddVar statements |
| 16:06 |
tsbere |
I use rewritemaps |
| 16:06 |
jeff |
also pulled the non-virtualhost bits out of the sites-available/eg.conf file and placed it in a conf.d/evergreen_common.conf file |
| 16:06 |
tsbere |
and rewriterules to set the env variables based on the rewritemaps |
| 16:16 |
jeff |
i'm not a huge fan of how we currently configure apache, but i'm not yet fully ready to propose a change. |
| 16:28 |
dbs |
jeff: fwiw, that (ripping <Location /eg> out of eg_vhost.conf and putting it into each vhost with different template PerAddVar stmts) is what we've done |
| 16:28 |
dbs |
broke the SSL stuff out into it's own conf too so that we could just include eg_vhost.conf and eg_vhost_ssl.conf as appropriate |
| 16:28 |
jeff |
ah! i'm not alone! hooray! |
| 16:29 |
jeff |
juggling three hostnames for two organizations. |
| 16:34 |
jeff |
dbs: i can test, but if you know offhand or can look without too much trouble -- are you including your site-specific <Location /eg> before the eg_vhost.conf include? |
| 16:39 |
dbs |
jeff: nope, I'm not |
| 16:39 |
jeff |
including it after? |
| 16:39 |
jeff |
(i'm going to be impressed if you're including it neither before nor after) |
| 16:45 |
csharp |
@quote add < eeevil> Now I am become Death, the destroyer of SIP2. |
| 16:45 |
pinesol_green |
csharp: The operation succeeded. Quote #88 added. |
| 16:50 |
dbs |
Let's kickstart that movie |
| 16:51 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:59 |
jeff |
dbs: finally looking at your paste shared above... so it appears your eg_vhost.conf still has the default <Location /eg> declaration, but you supplement it in the VirtualHost after including it? |
| 17:07 |
|
yboston_ joined #evergreen |
| 17:09 |
kmlussier |
@karma authorities |
| 17:16 |
dbs |
jeff: because that way was the least duplication |
| 17:17 |
jeff |
yes. I'm happy to see confirmation that that's possible. it simplifies things greatly. |
| 17:17 |
dbs |
That, or we're horribly broken and just haven't realized it yet :) |
| 17:31 |
jeff |
poking at test again (this time with a KCL-registered workstation -- bah), i'm seeing stat cats, but without populated values for "pick from the drop-down". looking at my document for things like demographic stat cats, i see i didn't actually share it outside of tadl. :P |
| 17:31 |
jeff |
and bah. |
| 17:31 |
jeff |
wrong channel. apologies. :-) |
| 17:47 |
|
mtate joined #evergreen |
| 23:50 |
|
gmcharlt_ joined #evergreen |
| 23:52 |
|
jcamins_ joined #evergreen |
| 00:28 |
|
dcook joined #evergreen |
| 04:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:56 |
|
eby__ joined #evergreen |
| 07:17 |
|
jboyer-isl joined #evergreen |
| 07:55 |
|
ericar joined #evergreen |
| 10:35 |
kmlussier |
Ah, that's right. I don't think it's important that DIG have the web based staff client preview for this particular project, but we'll want to dive into it soon. But if beta2 is out by the time you can update the community demo server, then it's probably best to go with it. |
| 10:36 |
kmlussier |
eeevil: No, I haven't signed off on the latest fixes. |
| 10:36 |
eeevil |
bshum: if you need someone's on the bug fixes in the followup, I'll do it |
| 10:37 |
kmlussier |
I can confirm that those fixes worked well for me on the ESI test server, but I usually don't do a sign-off until I've tested it on Dyrcona's server. But I don't think I"ll have time to look at it today. |
| 10:38 |
eeevil |
recall, beta is for bug fixing. if we believe the bugs are fixed and the features are signed off, and would otherwise go in, they should go in. IMHO |
| 10:39 |
eeevil |
but I'll step away from it now |
| 10:50 |
eeevil |
kmlussier: just to be sure, you're not planning to retest those last two commits today, right? |
| 14:07 |
bshum |
I think, if I grabbed the right string |
| 14:08 |
bshum |
So I guess they look similar. |
| 14:08 |
jeff |
yup. '20140812 140034' and '20140812 140034' are the two dates in the string you pasted. |
| 14:08 |
bshum |
Gotcha |
| 14:09 |
bshum |
jeff: So would it be as simple as wrapping the block for return date testing to only do the backdate if $trans_date != $return_date ? |
| 14:09 |
bshum |
Is that "!=" or "ne" ? |
| 14:10 |
* bshum |
should really learn perl |
| 14:10 |
berick |
then the question is will the dates ever match, but be, say, 2 days old. (maybe that's what jeff was aluding to re: offline?) |
| 14:11 |
jeff |
that's what i was alluding to. i can investigate at some time in the near future. |
| 14:12 |
jeff |
bshum: != is a numeric comparison, ne is a string comparison. |
| 15:59 |
pinesol_green |
Launchpad bug 949101 in Evergreen "Item Details->Alt View->Hold/Transit tab is showing two transit lists rather than a hold list and a transit list" (affected: 3, heat: 24) [Undecided,Confirmed] |
| 15:59 |
pinesol_green |
Launchpad bug 949101 in Evergreen "duplicate for #1234235 Item Details->Alt View->Hold/Transit tab is showing two transit lists rather than a hold list and a transit list" (affected: 3, heat: 24) [Undecided,Confirmed] |
| 16:01 |
kmlussier |
It actually looks like https://bugs.launchpad.net/evergreen/+bug/1312837 should be marked as the duplicate. Maybe it was marked on the wrong bug. |
| 16:01 |
pinesol_green |
Launchpad bug 1312837 in Evergreen "Item Status - Alternate View - Holds/Transit tab: Transit and Hold information does not refresh" (affected: 2, heat: 12) [Medium,Confirmed] |
| 16:22 |
|
ningalls joined #evergreen |
| 16:26 |
|
mtate joined #evergreen |
| 16:34 |
|
tspindler left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 17:26 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:03 |
ktomita |
Has anyone worked with Overdrive API's and checkout from TPAC? |
| 18:05 |
jeff |
I worked for months to get access to those APIs and by the time they granted me access the time I had allocated to the project was past. |
| 18:06 |
jeff |
So, "kinda"? :P |
| 10:11 |
|
berick joined #evergreen |
| 10:15 |
|
remingtron joined #evergreen |
| 10:51 |
|
tspindler joined #evergreen |
| 11:39 |
remingtron |
bshum: I'm testing a fresh 2.7 beta db and getting "ERROR: function evergreen.rank_cp(bigint) does not exist" |
| 11:39 |
remingtron |
is rank_cp a normal Evergreen function, or is it likely to be something custom on my end? |
| 11:39 |
remingtron |
we have done some postgres hacking on this server |
| 11:43 |
tsbere |
I think rank_cp is normal, but apparently missing |
| 11:43 |
kmlussier |
I'm guessing it's something that might have been impacted by bug 1234845? |
| 11:43 |
pinesol_green |
Launchpad bug 1234845 in Evergreen "possible optimization for evergreen.ranked_volumes database function" (affected: 2, heat: 12) [Medium,Fix committed] https://launchpad.net/bugs/1234845 |
| 13:03 |
mmorgan |
ok, i see that function. So all the data in the opac comes via those functions? |
| 13:03 |
* mmorgan |
is still trying to learn how the data gets from one place to the other ... |
| 13:05 |
|
RoganH joined #evergreen |
| 13:05 |
tsbere |
mmorgan: I believe a large percentage of the information in the opac comes from there. I haven't actually traced everything. Adding to the XMLATTRIBUTES list and the GROUP BY (at opposite ends of the functions) should hopefully let you add new fields like active_date. I would test in a dev system first though. |
| 13:07 |
mmorgan |
ok, thanks. We'll take a look at that. |
| 13:07 |
mmorgan |
tsbere++ |
| 13:08 |
berick |
beware the record details page is different. See Record::mk_copy_query, which calls AppUtils::basic_opac_copy_query |
| 13:08 |
berick |
which uses a json_query instead of unapi |
| 13:12 |
mmorgan |
berick: ok, thanks. We will proceed with caution - on our test server. |
| 13:15 |
|
hbrennan joined #evergreen |
| 13:17 |
|
mtate joined #evergreen |
| 13:35 |
dbs |
Some day maybe those two will be reconciled :/ |
| 13:42 |
eeevil |
bug 1355319 |
| 13:42 |
pinesol_green |
Launchpad bug 1355319 in Evergreen "Missing Dependency: Parse::RecDescent" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1355319 |
| 13:43 |
Dyrcona |
I thought it worked with lp and the number. |
| 13:44 |
Dyrcona |
Anyway.... about to test the Makefile.install fix on Ubuntu Trusty. |
| 13:44 |
Dyrcona |
If someone could test Fedora, that would be great. |
| 13:49 |
dbs |
If only we had a live build tester for Fedora |
| 13:50 |
Dyrcona |
dbs: I can't tell if you're being sarcastic or not. ;) |
| 13:51 |
bshum |
Dyrcona: I think the lp didn't work for pinesol_green without the space between LP and # |
| 13:51 |
Dyrcona |
I thought there was a space. |
| 13:51 |
dbs |
Not sarcastic. The live build tester started failing a day or two ago because of the Parse::RecDescent missing problem |
| 13:52 |
Dyrcona |
Whatever....Machines don't like me, and I don't like them either. ;) |
| 13:52 |
dbs |
05:16 < pinesol_green> Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 13:52 |
dbs |
I noticed it over the weekend, and it does a very good job of highlighting the problem |
| 13:52 |
Dyrcona |
Yep. I noticed it Friday, and had forgotten about it when I built my latest VMs, until they didn't work of course. |
| 13:53 |
bshum |
I didn't get to build anything new yet, but that makes me feel a little better that I haven't actually rolled the beta1 tarball yet then. |
| 13:53 |
bshum |
Dyrcona++ for following up on that dependency issue |
| 14:15 |
Dyrcona |
bshum: You want me to target the bug at beta1? |
| 14:15 |
bshum |
Dyrcona: Yeah we should put it in |
| 14:15 |
Dyrcona |
I did originally and then waffled. |
| 14:21 |
Dyrcona |
I have tested it on Ubuntu Trusty, and I presume the Debian and Ubuntu Precise targets will work, since they all name the package the same way. |
| 14:22 |
Dyrcona |
I put in the name of the package as I found it for Fedora 20, so hope Fedora works. ;) |
| 14:48 |
|
csharp joined #evergreen |
| 14:57 |
bshum |
Dyrcona++ |
| 16:50 |
eeevil |
right |
| 17:08 |
|
mmorgan left #evergreen |
| 17:09 |
|
mdriscoll left #evergreen |
| 17:11 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:23 |
phasefx |
Dyrcona++ bshum++ |
