Time |
Nick |
Message |
00:29 |
pinesol_green |
[evergreen|Liam Whalen] LP1084269, LP1050043 Expert Search Fixes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=085ab00> |
00:35 |
pinesol_green |
[evergreen|Blake Henderson] LP1277556 Fast Item Add no longer opens record after copy is created - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dcc5475> |
00:39 |
pinesol_green |
[evergreen|Ben Shum] LP#1314370: Enable dojo all the time in the catalog - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=92e84a3> |
00:43 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#1277551: Limit simplified pull list to available copies - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ce45d4c> |
00:45 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#1322341: Count part holds on records - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4b88afd> |
00:47 |
bshum |
Calling 0891 |
00:53 |
pinesol_green |
[evergreen|Chris Sharp] LP#1189556: Fix typo in URL_VERIFY permission description - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=293103d> |
00:53 |
pinesol_green |
[evergreen|Ben Shum] LP#1189556: stamping upgrade script for URL_VERIFY description typo fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6116739> |
01:09 |
pinesol_green |
[evergreen|Jason Etheridge] LP#1010027: more internal options for xul lists - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5ebaf74> |
01:09 |
pinesol_green |
[evergreen|Jason Etheridge] LP#1010027: tweak patron columns in patron search interface - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b844a3c> |
01:15 |
pinesol_green |
[evergreen|Elliot Voris] LP#1233757 Correct Spelling Error in Checkout Override Exception - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4f3f43e> |
01:17 |
pinesol_green |
[evergreen|Bill Erickson] LP#1306675 TPAC maketext default handler - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1d1a431> |
01:17 |
bshum |
Okay, time for bed. |
01:18 |
bshum |
Later today, I plan to merge in the work from https://bugs.launchpad.net/evergreen/+bug/1350042 |
01:18 |
pinesol_green |
Launchpad bug 1350042 in Evergreen "Browser staff client / merge prep" (affected: 1, heat: 6) [Wishlist,Confirmed] |
01:19 |
* bshum |
wanders off. |
04:00 |
|
jboyer__isl joined #evergreen |
04:00 |
|
sseng joined #evergreen |
04:07 |
|
mmorgan joined #evergreen |
04:08 |
|
rangi` joined #evergreen |
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 |
08:25 |
|
jboyer-isl joined #evergreen |
08:44 |
|
ericar joined #evergreen |
08:47 |
|
sarabee joined #evergreen |
08:49 |
|
Dyrcona joined #evergreen |
09:00 |
|
rjackson-isl joined #evergreen |
09:08 |
* csharp |
puts the autoreply person on moderation |
09:08 |
|
tspindler joined #evergreen |
09:08 |
mmorgan |
csharp++ |
09:09 |
csharp |
mailman's pretty good about catching those |
09:12 |
* tsbere |
dislikes that entire mail server's vacation module |
09:13 |
|
Shae joined #evergreen |
09:14 |
|
mdriscoll joined #evergreen |
09:34 |
|
yboston joined #evergreen |
09:58 |
bshum |
csharp++ |
09:58 |
krvmga |
i don't know if anyone's mentioned it before but Adblock can prevent the X images in Advanced Search from showing up. |
09:59 |
krvmga |
it's probably picking up on the ad at the beginning of the image name adv_row_close_btn.png |
09:59 |
krvmga |
we ran across this yesterday here |
10:00 |
tsbere |
krvmga: There is a launchpad bug on that topic, with a branch attached that was incomplete the last time I looked at it |
10:00 |
collum |
https://bugs.launchpad.net/evergreen/+bug/1190508 |
10:00 |
pinesol_green |
Launchpad bug 1190508 in Evergreen "Ad Block Plus EasyList blocks advanced search images" (affected: 1, heat: 6) [Medium,Confirmed] - Assigned to Dan Pearl (dpearl) |
10:00 |
|
krvmga joined #evergreen |
10:01 |
tsbere |
krvmga: Repeating because you disconnected right as I said it: There is a launchpad bug on that topic, with a branch attached that was incomplete the last time I looked at it |
10:01 |
tsbere |
krvmga: Also collum dug up the actual bug: https://bugs.launchpad.net/evergreen/+bug/1190508 |
10:01 |
pinesol_green |
Launchpad bug 1190508 in Evergreen "Ad Block Plus EasyList blocks advanced search images" (affected: 1, heat: 6) [Medium,Confirmed] - Assigned to Dan Pearl (dpearl) |
10:02 |
|
jwoodard joined #evergreen |
10:02 |
krvmga |
tsbere: thanks. don't know what happened. my x-chat suddenly crashed. |
10:02 |
krvmga |
thanks for the info |
10:03 |
krvmga |
tsbere++ |
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:49 |
tsbere |
That covers most of what I was going to say on launchpad, though I am doing a clean reinstall of things to see what the results are on a clean master. <_< |
10:49 |
berick |
tsbere: gotcha |
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:00 |
pinesol_green |
Launchpad bug 1241644 in Evergreen "claims_returned and longoverdue counts differ between open-ils.actor.user.checked_out(.count) and open-ils.storage.actor.user.checked_out(.count)" (affected: 2, heat: 12) [Medium,Triaged] https://launchpad.net/bugs/1241644 |
11:01 |
dbs |
bshum: I'm opening the bugggggggg |
11:06 |
dbs |
et voila bug 1362210 |
11:06 |
pinesol_green |
Launchpad bug 1362210 in Evergreen "Makefile prerequisite installer should install database server prerequisites too" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1362210 |
11:07 |
mmorgan |
jboyer-isl: where do the different counts show up to users? |
11:09 |
jboyer-isl |
It's not only the counts. A simple way to see it is if a patron has a claims returned item with 0 fines, the patron summary will show 1, but the Items out window (at the bottom, lost, claimed, etc.) will show nothing. |
11:12 |
|
berick joined #evergreen |
11:12 |
|
ningalls joined #evergreen |
11:13 |
eeevil |
the claims-returned count is /just/ a count of how many times staff have recorded that happening |
11:13 |
eeevil |
it is not a count of the circs with that fine-stop reason |
11:13 |
eeevil |
just for clarification |
11:16 |
|
gmcharlt_ joined #evergreen |
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:22 |
|
csharp joined #evergreen |
11:24 |
eeevil |
jboyer-isl: ah, you know, I did not read enough context. sorry for the noise |
11:24 |
|
vlewis joined #evergreen |
11:26 |
|
gmcharlt joined #evergreen |
11:27 |
|
mnsri joined #evergreen |
11:28 |
jboyer-isl |
mmorgan, it looks like it should be related (and our database has claims returned items with and without xact_finish set, of course) but we're running 2.5.2 and the latest claims returned with a null checkin_date and not null xact_finish is last week. |
11:41 |
jboyer-isl |
Uh. The title of that bug refers to claimed returned items, but the only code referenced deals only with lost items. That is a little confusing. |
11:45 |
eeevil |
bshum / berick_: the holds pull list looks easy to fix. some "return"s got dropped in 9e8a245ff181e3b837e1e60ef60c8eb3d8b0f190 and they need to be put back. I'll push a (potential) fix branch |
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:28 |
bshum |
eeevil: Oh, we were talking about bookbags |
12:28 |
eeevil |
oh, well... then what is the complaint about? |
12:28 |
eeevil |
well, yes, but there was something about holds, I thought |
12:28 |
bshum |
In the XUL client, trying to add a bib from the catalog to a bookbag (book list, list, whatever) |
12:28 |
tsbere |
There was a (supposed) issue with placing holds, but I never saw that one personally. |
12:28 |
bshum |
For me, I noted a quirk with placing holds via the catalog |
12:29 |
bshum |
But others didn't see that |
12:30 |
* eeevil |
rereads the ticket ... yeah, I'm not sure where the claim of "holds don't work" originated, then |
12:31 |
eeevil |
so, either tsbere, bshum and myself all ate the same wAcKy mushrooms, or ... someone said it at some point? |
12:31 |
* bshum |
blames it on the mushrooms |
12:31 |
gmcharlt |
eeevil: I must have had that same meal |
12:32 |
gmcharlt |
but since I was the last one to say the word "holds" to you, apologies for leading you down the (mushroom-lined) garden path |
12:33 |
eeevil |
gmcharlt: I was going to ask something, but then you started fading away, leaving just a smile floating in the air |
12:33 |
eeevil |
odd, that... |
12:33 |
* gmcharlt |
meows |
12:33 |
jeff |
Jeff: Could you provide me with details (as much detail as you can) on what authentication options [vendor] currently supports? |
12:33 |
jeff |
Vendor: Please see the attached [single page summary] [...] I'd be happy to provide more information about any of our authentication methods. [...] |
12:34 |
jeff |
I feel like I'm stuck inside of a TCP joke. |
12:37 |
gmcharlt |
@quote add <jeff> I feel like I'm stuck inside of a TCP joke. |
12:37 |
pinesol_green |
gmcharlt: The operation succeeded. Quote #90 added. |
12:40 |
jeff |
I would like details on your product. |
12:41 |
jeff |
Hi! I can provide you with details on our product. Would you like details on our product? |
12:41 |
jeff |
YES! |
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 |
13:23 |
tsbere |
eeevil: In regards to websockets, I haven't actually gotten websockets obviously working, to fix issues in the XUL client or otherwise. I also haven't even attempted to get the web client itself working beyond "try and make websockets work because I was told they fix some of the other issues seen post-merge". |
13:26 |
eeevil |
tsbere: right ... what I mean is, you claimed that simply merging the branch broke the xul client and/or the tpac (or, that's how berick_ and I both read the last part of your comment) ... but, it seems that's not true? or, it's not actually the reported issue. bshum was just saying he didn't find anything broken in the existing stuff, just in the web-client (and only one thing -- bookbags -- not 2). unless I'm still misunderstanding bshum, which |
13:26 |
eeevil |
is entirely possible |
13:29 |
tsbere |
eeevil: At this point I can say that with the code merged, but websockets not working, I could not add things to bookbags from the catalog interface of the xul client. Other discussion with bshum indicates that instead of being an Evergreen issue that may, in fact, be due to an OpenSRF master change that I loaded that bshum had not. |
13:29 |
bshum |
We're not sure of that though. |
13:29 |
eeevil |
ah! well, that's good info |
13:30 |
tsbere |
eeevil: I also can't anything for "with websockets working" as I can't actually confirm I have had websockets working. In general. |
13:30 |
|
ericar_ joined #evergreen |
13:39 |
|
_bott_ joined #evergreen |
13:40 |
|
kmlussier joined #evergreen |
13:41 |
|
ericar joined #evergreen |
13:55 |
kmlussier |
bshum++ #overnight merging of signedoff bugs |
13:56 |
|
ericar left #evergreen |
13:56 |
kmlussier |
bshum: Technically, it was August 27 in your time zone, but I fgured it was still Bug Squashing Day in someone else' |
13:56 |
kmlussier |
ugh |
13:56 |
kmlussier |
Anyway, I gave you credit for the signoffs in the tally. :) |
13:57 |
tsbere |
kmlussier: What time did the 24 hours that comprise a "day" officially start? If we go for, say, 7 AM EST then he was good by any clock ;) |
13:57 |
kmlussier |
12 a.m. is what I was thinking. |
14:03 |
tsbere |
kmlussier: Stop shooting down my attempts to justify you going past mightnight for counting bshum's work :P |
14:03 |
* kmlussier |
is also going to count a patch from Terran where the git branch was created yesterday, even though it wasn't posted to LP until today. |
14:04 |
gmcharlt |
+1 :) |
14:05 |
Bmagic |
Which funciton in the staff client would cause a row to be deleted from action.transit_copy? Abort transit? We have a scenario where an item was transited for another library. They received it, and checked it in, the row indicating it was transited no longer exists in transit_copy. I see the row from an earlier copy of the database |
14:05 |
kmlussier |
I'll include this information in my blog post, but I thought it worthy to mention that 2 of the patches bshum pushed last night came from new contributors and 1 of the new patches came from a new contributor. |
14:07 |
tsbere |
Bmagic: Aborted transits do, in fact, delete those rows, at least as far as I know. Makes it hard to see where the aborted transit was supposed to have started and ended.... |
14:43 |
jeff |
hrm. "obj.active_services is undefined" in Z39.50 import. This seems familiar. |
14:43 |
bshum |
jeff: Yes |
14:43 |
bshum |
That was a bug for awhile |
14:43 |
bshum |
I thought we fixed that |
14:43 |
jeff |
bug 1243280 |
14:43 |
pinesol_green |
Launchpad bug 1243280 in Evergreen 2.5 "'TypeError: obj.active_services is undefined' error when entering z39.50 MARC import UI" (affected: 3, heat: 16) [Medium,Fix released] https://launchpad.net/bugs/1243280 |
14:44 |
bshum |
That was it |
15:01 |
|
pmurray joined #evergreen |
15:29 |
|
ericar joined #evergreen |
15:55 |
|
_bott_ joined #evergreen |
16:01 |
|
ericar joined #evergreen |
16:08 |
jeff |
Interesting. Seems like selecting OCLC and another Z39.50 target causes there to be zero results (presumably due to a failure related to having no credentials for OCLC). Unchecking OCLC allows the other target to return results. |
16:13 |
|
ericar left #evergreen |
16:23 |
|
tspindler left #evergreen |
16:39 |
csharp |
does anyone use the actor.usr_merge function and if so, are there any gotchas to know about? |
16:40 |
csharp |
looks pretty straightforward, but didnt' want to assume |
16:48 |
tsbere |
csharp: is that what the staff client uses in the background to merge users? |
16:48 |
csharp |
I guess so |
16:49 |
csharp |
it's definitely thorough from my reading of the code |
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> |
21:46 |
pinesol_green |
[evergreen|Michele Morgan] lp949101 Hold Columns for Item Status - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=39503e3> |
22:00 |
pinesol_green |
[evergreen|Terran McCanna] LP#1282783: Use patron hold notification defaults for KPAC - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2f25263> |
22:26 |
bshum |
Okay, completed one more fresh install of OpenSRF master and Evergreen master (as of a few minutes ago) plus the web client stuff. |
22:26 |
bshum |
No breakage for hold placement or bookbag adding |
22:27 |
bshum |
Didn't configure or turn on web client / websockets stuff. |
22:30 |
jeff |
bshum++ |
22:33 |
bshum |
So far, so good. |
22:57 |
gmcharlt |
dbs++ # quickest draw in the north east! |
22:58 |
bshum |
dbs++ # thanks! |
23:03 |
dbs |
A pleasure to serve in some small way |
23:15 |
bshum |
kmlussier++ # bug wrapup blog post |
23:15 |
bshum |
And general wrangling awesomeness |
23:15 |
bshum |
And karma for everyone who helped, the next time I see them all |
23:35 |
|
kmlussier left #evergreen |