| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:52 |
|
rlefaive joined #evergreen |
| 07:22 |
|
Dyrcona joined #evergreen |
| 08:48 |
bshum |
That commit notes about PG versions makes me wonder if we ought to have a discussion about using the newer PG versions with Evergreen. While saying min 9.4 is necessary, maybe we should make 9.6 the default for the installers if we plan to make it a better tested target? |
| 08:49 |
bshum |
Stretch comes with 9.6 anyways, and 18.04 next year, I suspect will ship with something newer too |
| 08:49 |
bshum |
Though I also have been thinking we could switch to using the PostgreSQL apt repos like we do now for Wheezy/Trusty and come up with a more consistent version across distro installers |
| 08:50 |
Dyrcona |
Well, I'd like to see 9.6 tested more before we make it the recommended version. |
| 08:50 |
bshum |
For sure, for variations of "tested more" too :) |
| 08:50 |
Dyrcona |
I'm using the PostgreSQL apt repositories for production. |
| 08:51 |
Dyrcona |
I don't think there will be any issues with 9.6. |
| 08:51 |
bshum |
Yeah I used PG apt repos too |
| 09:34 |
|
HTTP_____GK1wmSU joined #evergreen |
| 09:36 |
|
HTTP_____GK1wmSU left #evergreen |
| 14:10 |
Dyrcona |
Whee! Fun with pgtap and typoed usernames and wrong databases and..... |
| 14:10 |
Dyrcona |
Anyway, you'll be happy to know that all pgtap tests succeed when I get it right, including the new test that I added. |
| 14:22 |
Dyrcona |
Hmm... I think the code to make sure that the hold notification info is filled in messes with thing, at least on Firefox. |
| 14:23 |
Dyrcona |
yep, and some of the behavior looks familiar.... :) |
| 14:24 |
Dyrcona |
Guess I'll make a bug on Lp. |
| 05:01 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:32 |
|
Dyrcona joined #evergreen |
| 08:49 |
|
bos20k joined #evergreen |
| 14:31 |
* miker |
looks |
| 14:32 |
berick |
i suppose we could turn 'now' into an iso string easy enough |
| 14:32 |
miker |
hrm... are you getting that from artisinal objects used in rows without round-tripping to the db? |
| 14:33 |
* berick |
chuckles at artisinal objects |
| 14:33 |
berick |
good question. |
| 14:33 |
berick |
just testing precat checkout |
| 14:33 |
miker |
ah, ok |
| 14:34 |
miker |
so, how about "if (date == 'now') date = new Date().toLocaleString();" |
| 14:35 |
miker |
or something like that? |
| 15:21 |
berick |
gmcharlt: i am not in the middle of it, thanks |
| 15:23 |
pinesol_green |
[evergreen|Galen Charlton] LP#1705524: fix a quoting issue in the DB update scripts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=46b5253> |
| 15:24 |
|
yboston joined #evergreen |
| 15:25 |
csharp |
hmm - trying to test the problem reported in bug 1624443, but I can't seem to find a way to add the same title again - I just get "Remove from my list" |
| 15:25 |
pinesol_green |
Launchpad bug 1624443 in Evergreen "Adding a duplicate title to a Temporary List causes an "Internal Server Error"" [Medium,Confirmed] https://launchpad.net/bugs/1624443 |
| 15:30 |
kmlussier |
@coin |
| 15:30 |
pinesol_green |
kmlussier: tails |
| 16:55 |
berick |
jeffdavis: do you see a reason not to make the move? |
| 16:56 |
jeffdavis |
Oh no, not at all. |
| 16:59 |
jeffdavis |
I wasn't sure if there were particular problems with selfcheck (someone here was saying just the other day that it's been working pretty well at our libraries). Getting off Dojo seems like a great motivation to me. |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:13 |
pinesol_green |
[evergreen|Mike Rylander] LP#1710010: Fix item status file upload - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2015799> |
| 17:26 |
Bmagic |
Did you all know that Showbiz Pizza closed in 1992? |
| 17:33 |
kmlussier |
Huh? |
| 17:34 |
berick |
don't know, but now i'm hungry |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 04:34 |
|
abowling1 joined #evergreen |
| 05:31 |
|
jeff___ joined #evergreen |
| 05:31 |
|
dbs joined #evergreen |
| 09:21 |
bos20k |
Debian has a nice text interface that lets you change it when you do 'dpkg-reconfigure locales'. The same command in Ubuntu seems to just regenerate locale files. |
| 09:22 |
Dyrcona |
Yeap. You can also set it per user, which is what I typically do. |
| 09:23 |
* Dyrcona |
waits for gitlab-ce to update. |
| 09:23 |
bos20k |
Yeah, if you're testing something you might want to try setting environment variables. The locale files for the particular locale would need to exist on the system I would think though. |
| 09:24 |
Dyrcona |
yeah, that goes without saying. |
| 09:24 |
* Dyrcona |
considers setting his environment to Esperanto when going through customs. :) |
| 09:33 |
|
jvwoolf joined #evergreen |
| 09:36 |
* pinesol_green |
You don't want to get mixed up with someone like kmlussier. kmlussier is a loner, Dottie. A rebel. for her LP skills |
| 09:36 |
kmlussier |
:) |
| 09:37 |
mmorgan |
kmlussier++ |
| 09:37 |
csharp |
kmlussier: heh - your solution was going to be my next step to test |
| 09:37 |
mmorgan |
pinesol_green is in a bad mood this morning. |
| 09:37 |
pinesol_green |
mmorgan: Leave me alone, I'm busy right now. |
| 09:37 |
mmorgan |
see? |
| 09:56 |
pinesol_green |
Dyrcona: Have you confirmed your ISBN SPIDs with your service provider? |
| 10:12 |
terran |
Bmagic++ for work on bug 1655158 - our staff have wanted this for years! |
| 10:12 |
pinesol_green |
Launchpad bug 1655158 in Evergreen "Patron Search by date of birth" [Wishlist,Confirmed] https://launchpad.net/bugs/1655158 |
| 10:13 |
remingtron |
Dyrcona: a SIP testing tool tells me my server "actively refused" the connection. I think I have opened port 6001 already. Advice? |
| 10:15 |
Dyrcona |
remingtron: Can you connect from the localhost? I'd try with both the name and 127.0.0.1 as well as ::1 if IP6 is configured. |
| 10:15 |
remingtron |
thanks, I'll give that a try |
| 10:15 |
Bmagic |
terran++ for checking it out |
| 11:19 |
terran |
Or bug 1708485 even |
| 11:19 |
pinesol_green |
Launchpad bug 1708485 in Evergreen "Web Staff Client: Missing courier code on transit slip print templates" [Undecided,New] https://launchpad.net/bugs/1708485 |
| 11:34 |
|
DPearl joined #evergreen |
| 11:38 |
JBoyer |
terran, I'm assuming courier_code is a field on actor.org_unit, but is in defined in the IDL where you're testing? It also looks to me like it will have to be accessed as 'dest_location.courier_code' or similar. (I haven't looked at web client printing that much yet, but I think should work) |
| 11:38 |
csharp |
shortname is the same thing |
| 11:38 |
csharp |
wait - no it's not |
| 11:38 |
csharp |
@blame csharp |
| 14:34 |
berick |
Dyrcona: +1 to context-sensitive error messages. i thought you were suggesting something else. |
| 14:34 |
csharp |
berick++ |
| 14:39 |
kmlussier |
berick++ |
| 14:40 |
berick |
csharp++ # it's fun making code you don't have to test :) |
| 14:53 |
|
Jillianne joined #evergreen |
| 15:07 |
|
Dyrcona joined #evergreen |
| 15:28 |
* Dyrcona |
decides to look at something for feedback fest.... |
| 15:33 |
gmcharlt |
Dyrcona++ |
| 15:34 |
Dyrcona |
Lp 1411422 since it bit us today. :) |
| 15:34 |
pinesol_green |
Launchpad bug 1411422 in Evergreen 2.12 "Copy details repeated in search results when item/volume moved with parts attached" [Medium,Confirmed] https://launchpad.net/bugs/1411422 |
| 15:34 |
Dyrcona |
Looks like it mainly needs a test and maybe a little additional code. |
| 15:36 |
miker |
grabbing 1051 for great justice |
| 15:38 |
pinesol_green |
[evergreen|Bill Erickson] LP#1695007 All-circulations slim DB VIEW - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4a24441> |
| 15:38 |
pinesol_green |
[evergreen|Bill Erickson] LP#1695007 Webstafff circ group summary display fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4105f8d> |
| 16:03 |
JBoyer |
Further infos and links on the site: https://wiki.evergreen-ils.org/doku.php?id=hack-a-way-2017 |
| 16:03 |
berick |
JBoyer++ |
| 16:06 |
Dyrcona |
JBoyer++ agoben++ |
| 16:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:08 |
kmlussier |
berick++ bug 1709476 |
| 17:08 |
pinesol_green |
Launchpad bug 1709476 in Evergreen "web client: item status recent circ history tab does not correctly display aged circulations" [Medium,Confirmed] https://launchpad.net/bugs/1709476 |
| 03:52 |
|
Jillianne joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:20 |
|
tsadok joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:12 |
|
agoben joined #evergreen |
| 09:25 |
|
Dyrcona joined #evergreen |
| 09:25 |
|
jvwoolf1 joined #evergreen |
| 09:33 |
|
yboston joined #evergreen |
| 09:46 |
pinesol_green |
[evergreen|Cesar Velez] LP#1669534 - OPAC hold request should not default to first SMS carrier - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f7deb92> |
| 10:11 |
|
bos20k joined #evergreen |
| 10:33 |
gmcharlt |
csharp: I've made an updated branch for bug 1098685 if you'd care to test again |
| 10:33 |
pinesol_green |
Launchpad bug 1098685 in Evergreen "User can select SMS notify without providing a valid address" [Medium,Confirmed] https://launchpad.net/bugs/1098685 |
| 10:47 |
|
gsams joined #evergreen |
| 10:51 |
csharp |
gmcharlt: trying to test - I think I'm fighting cache but it's still not working for me |
| 10:52 |
csharp |
I copied the files from your last commit into place and started testing - if there's something else I need, let me know |
| 10:52 |
gmcharlt |
csharp: does view source show holds-validation.js being linked? |
| 10:53 |
csharp |
hmm - no |
| 10:53 |
csharp |
lemme verify that the files are actually there |
| 11:50 |
|
khuckins joined #evergreen |
| 12:27 |
miker |
berick: are you handy? |
| 12:27 |
berick |
miker: i am |
| 12:27 |
miker |
and have time to maybe look at why some karma tests hate me? |
| 12:27 |
miker |
:) |
| 12:29 |
kmlussier |
Gee, I wonder what prompted that question. :) |
| 12:29 |
berick |
heh |
| 12:29 |
berick |
miker: point me at it |
| 12:33 |
miker |
ok, np |
| 12:37 |
|
jihpringle joined #evergreen |
| 12:57 |
pastebot |
"berick" at 64.57.241.14 pasted "for miker -- karma config update for lovefield" (12 lines) at http://paste.evergreen-ils.org/596 |
| 12:57 |
berick |
that fixes the tests for me |
| 12:58 |
berick |
fyi, the services have to be loaded in a certain order, that's why it's not a simple services/*.js import |
| 13:09 |
miker |
berick: bah ... thanks... I fixed a different test problem a week or so ago with that same thing. I should'a known |
| 13:13 |
miker |
kmlussier: so, berick's fix is pushed to the offline branch |
| 13:13 |
kmlussier |
miker: OK, I'll take a look when I have a moment. |
| 13:19 |
kmlussier |
It would be nice if there were a way to identify words that should never be stemmed. Like 'kissinger.' |
| 13:26 |
|
rlefaive joined #evergreen |
| 14:59 |
Dyrcona |
sure |
| 14:59 |
remingtron |
what value should I put in the "institution" variable? |
| 14:59 |
Dyrcona |
Whatever you want. It isn't really used, IIRC. |
| 15:00 |
remingtron |
I have two successful tests from 00sc_status.t, but test 3 fails with "Unable to connect to ILS..." |
| 15:00 |
Dyrcona |
I never run those tests... |
| 15:00 |
remingtron |
ha |
| 15:00 |
Dyrcona |
And, I'm not sure that they work with a real ILS, just the dummy one that comes with SIPServer. |
| 15:01 |
Dyrcona |
These are the SIPServer tests, right? |
| 15:01 |
remingtron |
yes |
| 15:01 |
remingtron |
so basically, a failure of those tests shouldn't concern me? |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:03 |
Dyrcona |
Not in the least if you're talking to a real ILS. |
| 15:03 |
Dyrcona |
The test that's failing uses a username of sip_01. |
| 15:04 |
remingtron |
cool, thanks for calming my fears. |
| 15:06 |
Dyrcona |
heh. it might even fail with the ILS.pm supposed to be used for testing. |
| 15:09 |
Dyrcona |
Yeah, looks like it will just plain fail. |
| 15:12 |
JBoyer |
remingtron, While you can use just about anything for an institution, it is (can be?) used to select different options for some SIPServer backend options in oils_sip.conf. We have one institution that needs that msg_64_barcode_something_something turned off and another where it's turned on. |
| 15:13 |
Dyrcona |
Yeah. It will match up in the configs. I guess I sort of assumed..... |
| 15:19 |
Dyrcona |
The SIPServer will attempt to correct the client, but most clients ignore the server. :) |
| 15:20 |
remingtron |
good to know |
| 15:22 |
|
ohiojoe joined #evergreen |
| 15:28 |
berick |
remingtron: if you're planning to create more tests, this may be of value https://github.com/berick/pysip2 |
| 15:29 |
remingtron |
berick: thanks for sharing. I'm just scratching the surface at the moment, but I'll keep that in mind. |
| 15:30 |
rhamby |
berick++ : I've used pysip2 before and it's handy |
| 15:33 |
* Dyrcona |
usually uses phpsip2 but has used pysip2 |
| 15:41 |
|
abowling joined #evergreen |
| 15:50 |
|
kmlussier joined #evergreen |
| 16:14 |
|
mmorgan joined #evergreen |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:49 |
|
ningalls joined #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 17:11 |
gsams |
Anyone have advice for completely overhauling permission groups? |
| 17:12 |
* gmcharlt |
claims 1050 in the name of miners everywhere! |
| 17:16 |
pinesol_green |
[evergreen|Cesar Velez] LP#1480432 - Added tests for permission.usr_perms() change - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1f02799> |
| 17:16 |
pinesol_green |
[evergreen|Michele Morgan] LP#1480432: choose broadest depth if staff has same perm multiple times - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2790b6e> |
| 17:16 |
pinesol_green |
[evergreen|Galen Charlton] LP#1480432: stamp DB update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=db7b67a> |
| 17:16 |
kmlussier |
Yay! mmorgan++ cesardv++ gmcharlt++ |
| 18:13 |
csharp |
gsams: been planning something like that in PINES for some time, but it hasn't risen to the top - I would do it on a test server and work incrementally |
| 18:15 |
gsams |
csharp: Seems wise for sure. We've not really adjusted well over the years and I think sooner would be better than later for this process. |
| 18:17 |
jihpringle |
gsams: we overhauled one of our permission group sets a while ago (we have different groups for different library types) |
| 18:17 |
jihpringle |
we set up the new permission groups on a test server and then copied them over to our production server when we were ready |
| 18:18 |
jihpringle |
and then updated the users to use the new groups |
| 18:18 |
jihpringle |
we didn't remove the old groups until we have confirmation that everything was working as expected |
| 18:19 |
jihpringle |
it worked well for us, but it was just our K-12 perms we overhauled so only 15 or 16 libraries affected |
| 18:21 |
gsams |
jihpringle: awesome, thanks for sharing. We are only 14 public libraries, so I think we could make that work really well. |
| 18:22 |
jihpringle |
gsams: you' |
| 18:22 |
jihpringle |
you're welcome :) |
| 00:16 |
|
Jillianne joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:06 |
|
JBoyer joined #evergreen |
| 07:19 |
|
rjackson_isl joined #evergreen |
| 09:25 |
|
jvwoolf left #evergreen |
| 09:28 |
|
jvwoolf joined #evergreen |
| 10:02 |
|
mmorgan1 joined #evergreen |
| 10:04 |
pinesol_green |
[opensrf|Graham Billiau] LP#1704090: ensure make install respects DESTDIR - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=e88891b> |
| 10:51 |
pastebot |
"gmcharlt" at 64.57.241.14 pasted "for feedback - is this in fact easier to understand?" (12 lines) at http://paste.evergreen-ils.org/579 |
| 10:51 |
bshum |
gmcharlt: were not or may not? |
| 10:51 |
gmcharlt |
bshum: in this context, definitely were not |
| 15:32 |
* JBoyer |
feels a dufus because he forgot to disable transparent_hugepages on the db, explaining all manner of "random" slowdowns in otherwise simple Qs. |
| 15:32 |
JBoyer |
Looked at an email csharp sent to the lists ages ago and was reminded. |
| 16:09 |
csharp |
JBoyer: glad it was helpful :-) |
| 16:24 |
Dyrcona |
jeff: Thought you might like to know that after I installed my branches for Lp 1542495 and Lp 1463943 my phpsip2 test script runs great. It was apparently a UTF-8 character causing it to crash. |
| 16:24 |
pinesol_green |
Launchpad bug 1542495 in SIPServer "OpenILS::SIP::clean_text() can crash" [Undecided,Confirmed] https://launchpad.net/bugs/1542495 |
| 16:24 |
pinesol_green |
Launchpad bug 1463943 in SIPServer "Non-ascii Unicode characters in messages cause SIP client problems" [Undecided,Confirmed] https://launchpad.net/bugs/1463943 |
| 16:25 |
gmcharlt |
Dyrcona: coordinates of that test script? |
| 16:26 |
Dyrcona |
gmcharlt: It's not a test script that one could integrate into Evergreen, but I put it on pastebin. Let me check my logs. |
| 16:26 |
gmcharlt |
Dyrcona: thanks! |
| 16:27 |
Dyrcona |
gmcharlt: https://pastebin.com/5jm9m2h3 |
| 16:28 |
* gmcharlt |
claims 1049 in the name of the too few journal publishers who never, ever, ever change their titles everywhere! |
| 16:29 |
Dyrcona |
It was written to test some SIP2 fine item details changes, but incidentally tests those branches as well. :) |
| 16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 16:32 |
gmcharlt |
*cough* |
| 16:32 |
gmcharlt |
I'll deal with that test failure |
| 16:33 |
Dyrcona |
:) |
| 16:33 |
Dyrcona |
It doesn't look too bad. |
| 16:33 |
gmcharlt |
yeah, easy-peasy |
| 01:12 |
|
ericar joined #evergreen |
| 03:41 |
|
StomproJ joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 07:32 |
|
agoben joined #evergreen |
| 14:35 |
ohiojoe |
and it looks like Jane and I will follow on the in-progress then? |
| 14:37 |
ohiojoe |
#action sandbergja and ohiojoe will follow-up with assigned "in-progress" users to try to preserve any progress made but not submitted |
| 14:38 |
ohiojoe |
#topic Progress on Docs Reorganization project |
| 14:38 |
sandbergja |
I would love some guidance here! |
| 14:39 |
sandbergja |
I'd like to gather some feedback on the reorganized manuals on the test server |
| 14:39 |
sandbergja |
What's the best way of going about the feedback gathering, do you think? |
| 14:42 |
kmlussier |
sandbergja: Have you sent out anything to one of the lists (docs or general) showing the changes you've made? |
| 14:42 |
kmlussier |
I feel like you have, but I'm not finding it. |
| 14:43 |
sandbergja |
kmlussier: I thought so too, but it looks like I haven't |
| 14:43 |
sandbergja |
ohiojoe: could you put that down as an action item for me, please? |
| 14:44 |
ohiojoe |
#action sandbergja will email one or more lists seeking feedback on reorganized manuals on the test server |
| 14:44 |
kmlussier |
sandbergja: If you don't get much feedback via the list, it might be worth scheduling another meeting focused on the reorg project. |
| 14:44 |
kmlussier |
But it would be good to see if you can get good discussion on the list first. |
| 14:45 |
sandbergja |
sounds like a plan |
| 14:45 |
kmlussier |
For reference: |
| 14:45 |
kmlussier |
#link http://docs-testing.evergreen-ils.org/ |
| 14:45 |
ohiojoe |
any other thoughts here before we move on? |
| 14:46 |
ohiojoe |
#topic Progress on documentation launchpad bugs |
| 14:48 |
kmlussier |
#link https://bugs.launchpad.net/evergreen/+bugs?field.tag=documentation |
| 16:06 |
jeffdavis |
Dyrcona: do you mean having generic (rather than Sitka specific) access to that environment for EG devs? |
| 16:06 |
jeffdavis |
Or just in general? |
| 16:13 |
Dyrcona |
I'm not sure. I requested Patron Authentication API and they responded about using their integration envoronment. |
| 16:14 |
Dyrcona |
They said, "We are currently speaking with an Evergreen contributor and have not been able to set up a test environment." |
| 16:14 |
Dyrcona |
Among other things. |
| 16:30 |
jeffdavis |
They must mean me. I requested access to their integration environment for Sitka (not for the broader EG community) - looks like they didn't receive part of my request and followed up while I was on vacation. |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:40 |
|
jvwoolf joined #evergreen |
| 16:47 |
jeffdavis |
Dyrcona: I sent them a follow up attempting to explain that my access to their API doesn't preclude others'. |
| 16:55 |
Dyrcona |
jeffdavis: OK. I'm going to discuss it with others here to see where our priorities are. I don't think i really have time for it right now. |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:20 |
|
JBoyer joined #evergreen |
| 10:18 |
Dyrcona |
berick: How do you top it after the duration without losing the transaction? I should probably look that up, instead.... ;) |
| 10:19 |
berick |
Dyrcona: each chunk of months is its own transaction. the sql runs to completion each time, then the calling script checks to see if it should start another one. |
| 10:19 |
Dyrcona |
Oh. I see. Thanks. |
| 10:20 |
Dyrcona |
I should test this on my new hardware, but we're putting it in production on the 20th, so it may not finish by then. |
| 10:20 |
|
bwicksall joined #evergreen |
| 10:23 |
berick |
hm, so we have a custom circ purge script. it has less (unused locally) logic. it's diverged enough from stock I don't have a functional diff to share. but the gist is only work on circs whose xact_finish value falls between start_time and end_time, those being new function params. |
| 10:25 |
|
terran joined #evergreen |
| 15:49 |
jeffdavis |
I'm a bit hesitant about that change. |
| 15:49 |
miker |
gmcharlt: how about, "a NEW security issue" |
| 15:49 |
JBoyer |
It would also allow some older bugs to age out with an official WontFix status rather than a defacto one. |
| 15:50 |
jeffdavis |
Just because we've been testing the web client and finding things that are showstoppers for us in 2.12ish. So making 3.0 the cutoff seems a bit short. |
| 15:50 |
berick |
miker: heh, good point, "xul is old, needs update" ;) |
| 15:50 |
Dyrcona |
"Xul's dead." |
| 15:50 |
gmcharlt |
jeffdavis: yeah, those are things that need to be addressed, hopefully in time for 3.0.0 |
| 16:07 |
JBoyer |
How far is less close? |
| 16:07 |
miker |
(pros: better support, more consistent UIs; cons: more JS to download) |
| 16:07 |
JBoyer |
(for those of us only now seeing it) |
| 16:07 |
Dyrcona |
No. I assume you're also looking for willing victims...er test subjects. |
| 16:07 |
miker |
JBoyer: zero-padding differences |
| 16:08 |
miker |
mainly |
| 16:08 |
JBoyer |
Hmm. |
| 16:13 |
berick |
this should be simple, do we want to wait until after 3.0 to update from angular 1.5 to 1.6 (bug #1680140) ? |
| 16:13 |
pinesol_green |
Launchpad bug 1680140 in Evergreen "Update staff JS dependencies for Angular 1.6" [Wishlist,Confirmed] https://launchpad.net/bugs/1680140 |
| 16:14 |
gmcharlt |
berick: I'm inclined to defer that decision to the week of 28 August |
| 16:14 |
berick |
i ask becuase any time we muck about in the js, espeically the deps it means re-testing, rebasing, etc. |
| 16:14 |
Dyrcona |
Given your comments from today, I'd say wait. |
| 16:14 |
gmcharlt |
i.e., give a try before the beta gets cut |
| 16:15 |
gmcharlt |
not that I'm particuarly opposed to waiting until after 3.0... but given our experience with Dojo, I think there's a strong argument to be made that we should get used to biting the version treadmill bullet |
| 16:16 |
berick |
i'll add a note to the bug about revisiting |
| 16:16 |
gmcharlt |
ok |
| 16:16 |
gmcharlt |
so then, finally, back to miker about offline |
| 16:17 |
miker |
Really, I just want to get input on the serviceworker setup in use, and ask for testing |
| 16:17 |
csharp |
@band add The Version Treadmill Bullet |
| 16:17 |
pinesol_green |
csharp: Band 'The Version Treadmill Bullet' added to list |
| 16:17 |
miker |
we're using UpUp currently |
| 16:19 |
miker |
the branch is at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1706107-offline-mode |
| 16:19 |
miker |
LP at https://bugs.launchpad.net/evergreen/+bug/1706107 |
| 16:19 |
pinesol_green |
Launchpad bug 1706107 in Evergreen "Offline mode for the Web Client" [Undecided,New] |
| 16:20 |
kmlussier |
I've already done a fair amount of testing and could probably add a signoff sometime soon. I probably would want to load it on a local test server just to make sure it still works as I remember. |
| 16:20 |
JBoyer |
I'm +1 to using the simplest thing that will work, though I've not been able to test that branch yet. |
| 16:20 |
kmlussier |
miker: Are we losing anything by not using the whole serviceworker framework? |
| 16:20 |
miker |
kmlussier: complication? ;) |
| 16:21 |
miker |
seriously, not that I can see |
| 16:21 |
miker |
that is /all/ upup tries to do |
| 16:21 |
miker |
and, now that it's all set up, it seems to do well |
| 16:22 |
berick |
ditto JBoyer |
| 16:22 |
miker |
kmlussier: when testing the new separate branch (was embedded in serials before) we'll need to watch for new 404s during offline mode |
| 16:23 |
miker |
one key thing is that upup has to know about (and cache) every single resource that the offline interface references, either directly or indirectily, via css include or xhr also |
| 16:24 |
miker |
for instance, I had to install the woff2 version of the bootstrap font because, even though we don't use it, it's requested by the css |
| 16:24 |
miker |
and causes a load failure in the offline UI if it can't be cached by the service worker |
| 16:26 |
miker |
to sum up: this is a call for testing, and secondarily, a call for critique of the implementation |
| 16:26 |
kmlussier |
ok, I'll try to carve time out for testing it. I think I know what to look for and how to break it if there are issues. :) |
| 16:26 |
gmcharlt |
ok, and with that, we've reached the end |
| 16:26 |
miker |
kmlussier: if anyone does ... ;) |
| 16:26 |
miker |
thanks all |
| 16:30 |
|
DPearl left #evergreen |
| 16:32 |
berick |
miker: k, yeah, that's another one that would benefit from a quick merge once it's updated. |
| 17:00 |
|
https_GK1wmSU joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:01 |
|
https_GK1wmSU left #evergreen |
| 17:05 |
|
mmorgan1 left #evergreen |
| 17:37 |
Bmagic |
gmcharlt++ |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:00 |
|
Jillianne joined #evergreen |
| 06:41 |
|
rlefaive joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 11:15 |
bshum |
Yes |
| 11:16 |
bshum |
I'll check Debian docs to see if something's changed in this area... |
| 11:16 |
Dyrcona |
I certainly hope not. |
| 11:18 |
berick |
wonder if it would work after a reboot. could also test by manually exporting LD_LIBRARY_PATH to see what happens. |
| 11:19 |
Dyrcona |
I've been meaning to build a Debian 9 vm to kick the tires. |
| 11:19 |
Dyrcona |
I may do that sooner rather than later. |
| 11:20 |
bshum |
I'll try a reboot now |
| 13:35 |
francisco_ |
Hi all, I have a question, Does the receipt template aditor are saved in an especific table in EG? or are saved locally on each machine? This because I upgraded from 2.8.4 to 2.12.3 and the templates looks like they were set to the default ones |
| 13:36 |
Dyrcona |
francisco_: Receipts are stored in the staff client preferences. If you have the old staff client hanging around, you can export them. It has to be the staff client where they were created or imported, though. |
| 13:39 |
|
collum joined #evergreen |
| 13:46 |
* bshum |
grumbles something about systemd ruining our lives |
| 13:46 |
bshum |
systemctl start apache2 websockets.service |
| 13:47 |
bshum |
(more notes to self) |
| 13:48 |
bshum |
miker++ # your fix for perl 5.24 works for me on Debian 9 ; I'll let Graham eyeball it too, but I'll go pick it on later once I get to re-test it on lower versions |
| 13:51 |
Dyrcona |
bshum: You see where sytemd won the pwnie award for "worst vendor?" Mainly 'cause Lennaert. |
| 13:52 |
|
mmorgan joined #evergreen |
| 13:54 |
|
sergio_ joined #evergreen |
| 15:57 |
|
jvwoolf joined #evergreen |
| 15:59 |
|
pgardella joined #evergreen |
| 16:17 |
|
pgardella joined #evergreen |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:33 |
gsams_ |
A little while back I had an issue regarding not being able to pull up the patron editor properly for a handful of patrons, which was fixed by removing some incorrect information in those patrons' sms notify fields. |
| 16:33 |
gsams_ |
I'm having a slightly different issue with the same set of patrons, in which we can't seem to place holds for them. |
| 16:34 |
gsams_ |
It doesn't fill in their information when attempting to place a hold through the staff client, and the box that should contain their barcode is empty. |
| 02:03 |
|
_GK1wmSU joined #evergreen |
| 02:06 |
|
_GK1wmSU left #evergreen |
| 03:20 |
|
rlefaive joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:20 |
|
rlefaive joined #evergreen |
| 05:28 |
|
umarzuki joined #evergreen |
| 05:34 |
umarzuki |
after docker container running, how do I access demo page? |
| 12:48 |
|
Dyrcona joined #evergreen |
| 12:50 |
miker |
arg |
| 12:50 |
gmcharlt |
parameter! |
| 12:51 |
miker |
so, dbwells, looks like I'll need to roll back at least the opensrf side of the interval_to_seconds change. after adding 2 unit tests covering month addition across DST boundary, we have a problem |
| 12:52 |
miker |
it's not matching the PG calculation for interval math |
| 12:52 |
miker |
it's better than "1 yr/12", but it's not giving the expected results... |
| 12:56 |
pinesol_green |
[opensrf|Mike Rylander] LP#1635737: Unit tests for DST and date math - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=316f583> |
| 13:04 |
egbuilder |
build #64 of osrf-master-debian-6.00-x86_64 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/osrf-master-debian-6.00-x86_64/builds/64 blamelist: Mike Rylander <mrylandergmail.com> |
| 13:12 |
|
mmorgan joined #evergreen |
| 14:06 |
dbwells |
miker: Thanks for testing and agressively pushing! Unfortunately, I think you hit a limitation of the date parser, or more accurately, ISO dates in general. Bare offsets don't have DST rules, as areas with the same offset may or may not participate in DST. To get the right DST math, you have to specify an actual region. Let me cook up an example, one moment... |
| 14:07 |
|
Dyrcona joined #evergreen |
| 14:07 |
dbwells |
miker: So, I think a test like this will return the expected number: interval_to_seconds("1 month", DateTime::Format::ISO8601->new->parse_datetime("2017-02-14T23:59:59-04")->set_time_zone("America/New_York")) |
| 14:13 |
Dyrcona |
@blame tlp |
| 14:13 |
pinesol_green |
Dyrcona: tlp stole bshum's tux doll! |
| 14:16 |
dbwells |
I haven't thought through exactly how this plays out in practice, other than some annoying degree of vigilance. For example, turns out my branch's current casual use of "DateTime-now()" isn't sufficient; it ends up as UTC :( |
| 14:45 |
kmlussier |
Yes, I agree |
| 14:46 |
miker |
dbwells: right. and, specifically, that branch sets the timezone for $due_date to the circulating org's TZ, rather than "local" |
| 14:46 |
miker |
(well, when specified) |
| 14:46 |
dbwells |
miker: Do you think it makes sense to push a change to the test, or do you still think it needs to be rolled back? |
| 14:48 |
miker |
let me try your suggested test change... |
| 14:49 |
miker |
yeah ... that does fix the test, actually |
| 14:52 |
miker |
hrm... fake news. it does not do that at due-date calc time. instead it uses "local" which, with opensrf 2.5 is the client TZ ... it does set the tz properly when generating billings, which is what I was confused with |
| 14:52 |
gmcharlt |
miker: wanting to double-check something - opensrf.persist is not actually used by Evergreen, correct? |
| 14:53 |
gmcharlt |
(asking because it appears to be the only user within OpenSRF itself of of the interval-handing stuff in OpenSRF::Utils |
| 14:53 |
miker |
however... just setting the tz to "local" in the test (which we should not do, because it's server-dependent) does let the tests pass. meaning it's pulling from the env, wihich is correct, short of looking up the circ lib tz |
| 14:53 |
miker |
gmcharlt: correct, it's not in active use |
| 14:54 |
miker |
so, to recap, I think the test was at fault, not the app code or the interval code. here's why: |
| 14:54 |
gmcharlt |
in that case, sort out the one use within opensrf.persist... and the time-handing stuff might be reasonably movable into Evergreen |
| 14:56 |
miker |
the app code, in the the rule needs to be "set the timezone of the context date to a dst-aware value, lest the math not be dst aware" |
| 14:57 |
miker |
we're doing that in the common case of apply_modified_due_date (no $start_time) |
| 14:58 |
miker |
if we follow that rule, even using 'local' (aka, client TZ or server TZ if not sent) then the math works |
| 14:58 |
miker |
ok... I'm feeling better about it now |
| 15:00 |
miker |
gmcharlt: my pref, for the moment would be to leave the code where it is and address the functional issues. once addressed (if proven addressable, that is) then maybe move |
| 15:02 |
gmcharlt |
"where it is" meaning reseting to the status quo ante by reverting, then allowing a bit more time for considered testing? we've got time prior to the next 2.12.x release |
| 15:03 |
miker |
"where it is" meaning which project holds the interval_to_seconds code ;) |
| 15:03 |
miker |
sorry |
| 15:03 |
miker |
that wasn't clear |
| 15:03 |
gmcharlt |
miker: right, I think we're talking about orthogonal things |
| 15:04 |
miker |
anyway, there are 4 scenarios we need to test. with and without DST crossing, and for each, with and without DST-aware TZ |
| 15:04 |
gmcharlt |
moving the time utility functions to Evergreen is something I have a mild preference for, but it's not a showstopper for anythign whatsoever |
| 15:04 |
gmcharlt |
resetting things to the status quo ante is something I feel more strongly about |
| 15:04 |
miker |
(btw, I was looking at the in-PG version also ... the reason it "works" there is that there's a hidden variable: the DB's (effective) timezone setting) |
| 15:06 |
miker |
well, I have passing tests on the opensrf side now. how about we revert the EG side |
| 15:09 |
gmcharlt |
I'd really prefer that the whole thing be tested as a unit, just in case we run into other issues |
| 15:10 |
dbwells |
While I was a little surprised to see it pushed quickly, I guess I am not sure why we would revert code without any known problems. |
| 15:10 |
miker |
dbwells: well, it didn't have tests (which I should have added) |
| 15:11 |
miker |
and my first tests showed the EG side lacking (no tz set in 2 of 3 cases)... though, that's only now explicitly diagnosed |
| 15:11 |
miker |
IOW, I should have known the rule we need (and made it so) before pushing |
| 15:12 |
miker |
anyway, I'll go look up git-revert and do that, then push updated branches |
| 15:12 |
gmcharlt |
miker: thanks |
| 15:13 |
gmcharlt |
and generally speaking, I don't expect that there will be any problem getting this buttoned up prior to the next maintenance release |
| 15:14 |
gmcharlt |
but code that involves time is an area where the more test coverage, the better |
| 15:16 |
dbwells |
definitely agree |
| 15:17 |
pinesol_green |
[evergreen|Mike Rylander] Revert "LP#1635737 Use new OpenSRF interval_to_seconds() context" - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a54b18e> |
| 15:17 |
pinesol_green |
[opensrf|Mike Rylander] Revert "LP#1635737: Unit tests for DST and date math" - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=0484c67> |
| 15:17 |
pinesol_green |
[opensrf|Mike Rylander] Revert "LP#1635737 Add optional context to interval_to_seconds" - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=716b674> |
| 15:24 |
egbuilder |
build #65 of osrf-master-debian-6.00-x86_64 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/osrf-master-debian-6.00-x86_64/builds/65 |
| 15:45 |
miker |
dbwells: hrm... is there a reason you removed the hh:mm:ss interval parsing from the evergreen-side patch? |
| 15:45 |
miker |
fwiw, I'm tempted to /add/ that to the opensrf side |
| 15:50 |
dbwells |
miker: It was already in the OpenSRF side. |
| 15:50 |
miker |
dbwells: it sure was :) |
| 15:50 |
* miker |
looked right past it |
| 16:04 |
miker |
dbwells / gmcharlt: branches added |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:31 |
|
jvwoolf left #evergreen |
| 16:52 |
gmcharlt |
the branch for patron search from the place holds form is now available for review - bug 1701001 |
| 16:52 |
pinesol_green |
Launchpad bug 1701001 in Evergreen "Allow searching for a patron from place holds page in embedded OPAC" [Wishlist,New] https://launchpad.net/bugs/1701001 |
| 02:15 |
|
ahelten joined #evergreen |
| 02:52 |
|
Jillianne joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:27 |
|
rlefaive joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 08:02 |
|
Dyrcona joined #evergreen |
| 09:55 |
Dyrcona |
Well, it gets complicated when you start dealing with money. |
| 09:55 |
Dyrcona |
You might think "it's only math," but you'd be mistaken. :) |
| 09:56 |
Dyrcona |
It's easy to mess up, and boy, don't people get mad when you do. :) |
| 09:56 |
rjackson_isl |
test plans and reviews are your friend in this case |
| 09:57 |
berick |
rjackson_isl: there are 2 parts, the collection agency tracker (money.collections_tracker IIRC) and penalty. the penalty can be locally cleared when the threshold goes back down, but the agency has to clear the collection_tracker entry |
| 09:58 |
rjackson_isl |
berick: in the instance currently being reviewed there is a note on the account showing it going into collections and then back out when I did the oops |
| 09:58 |
rjackson_isl |
it doesn't show going back into collections in the note when I corrected (or partially corrected) |
| 10:20 |
miker |
rjackson_isl: yeah ... there are a ton of things that could be stopping patrons from falling back into collections, if that's the goal. if it's UMS you're working with, they'll be as helpful with diagnostics as they can be, I'm sure |
| 10:20 |
rjackson_isl |
mikre: I think the library is in direct contact on their side so I am going to stay out of this fight unless forced to join! |
| 10:20 |
rjackson_isl |
miker: that is... |
| 10:20 |
* Dyrcona |
shuts up and goes back to checking if his test db server has finished rebooting. |
| 10:30 |
Dyrcona |
On a somewhat related note, I've been having trouble finding patrons that return fine item details with SIP2. |
| 10:30 |
jeff |
Oh? |
| 10:30 |
Dyrcona |
I'll have to look into because apparently the code isn't doing what I think it does. |
| 10:32 |
Dyrcona |
Having a million other things to do and a vacation in between doesn't help. |
| 10:35 |
Dyrcona |
It supposedly works with contrived examples in the Concerto data, i.e. after adding a fine to a patron. |
| 10:35 |
|
jvwoolf joined #evergreen |
| 10:37 |
jeff |
there have been issues in the past with regard to some SIP code using a different mat view (old money owed summaries, iirc), and there were gotchas with auth tokens and/or multiplex personality, but i think most of the ones that would affect this have been addressed. |
| 10:38 |
jeff |
Dyrcona: i'm interested in what you find and might be able to help troubleshoot, but nothing immediately comes to mind for you to try. |
| 10:38 |
jeff |
Dyrcona: what client are you testing with, and have you checked the raw sip message either over the wire or in the server logs to verify that the client isn't obscuring / mis-parsing the fixed field in question? |
| 10:39 |
Dyrcona |
I'm using branches based on Evergreen 2.12.3 and SIPServer master with a copy of production data. |
| 10:39 |
Dyrcona |
jeff: PHPSIP2, and yes, I've dumped the raw messages. I'm not getting the results that I expect. |
| 10:40 |
Dyrcona |
If I ask for 10 fine item details, I get 10 empty fields on every patron. |
| 10:43 |
Dyrcona |
I get 0 for every patron. |
| 10:43 |
jeff |
and at that point, they were all 0? ah. |
| 10:43 |
Dyrcona |
Even after running the fine generator. |
| 10:44 |
Dyrcona |
Since I haven't tested with unmodified code, I don't know what's broke. :) |
| 10:44 |
jeff |
if you reduce it to one patron with bills that is showing a count of 0 fine items via SIP2, if you open the patron in the staff client and Refresh them, does that then change the fine items count in SIP2? |
| 10:45 |
Dyrcona |
I haven't tried that. |
| 10:48 |
jeff |
Does the Evergreen user that the SIPServer is authenticating as have VIEW_USER_TRANSACTIONS permission at the proper ou/depth? |
| 10:53 |
jeff |
...even if you get the facts such so that the patrons will match the criteria to be submitted, starting the submission / collections process fresh is likely a Bad Idea. There isn't a way to put them "back where they were" in the collections process without involving your collections vendor and having careful coordination. |
| 10:54 |
rjackson_isl |
messing with money is a bad idea - but I was out-voted! |
| 10:54 |
jeff |
rjackson_isl: you're welcome :-) |
| 10:55 |
Dyrcona |
jeff thanks for the suggestions, I'm going to rebuild my test vm and give i another whirl. |
| 10:55 |
Dyrcona |
s/i/it/ |
| 10:56 |
jeff |
Dyrcona: it could be as simple as that, then. |
| 10:56 |
* jeff |
finds things he wants to change |
| 16:20 |
mmorgan |
jeff: this happens a lot in our consortium. |
| 16:20 |
mmorgan |
Similarly, if all copies become long overdue when there are still holds to be filled. |
| 16:22 |
mmorgan |
We generate and post a "Hopeless Holds" report daily. |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:44 |
abneiman |
jeff: when I was at KCPL we did a weekly "Hopeless Holds" report -- based on a version that NC Cardinal did. It let us know when the amount of targetable copies dropped to 0 (lost, missing, claimed returned, etc) on titles with holds. Interacted a little wonkily with metarecord holds, IIRC, but it got the job done. |
| 16:46 |
mmorgan |
Ours only looks at title holds, so, not perfect, but also gets the job done (mostly). |
| 16:46 |
abneiman |
jeff: see slide 22 of this presentation: https://evergreen-ils.org/wp-content/uploads/2015/11/eg16-Oops-I-accidentally-deleted-something-and-other-small-problems-bite-sized-reports-to-help-you-find-and-fix-problems-in-your-ILS.compressed.pdf |
| 13:47 |
kmlussier |
One reason we started to link the two problems (if they are indeed linked) is because mmorgan was also noticing in the logs for the one-hit problems that it seemed to be running through mr routines even though they weren't mr searches. |
| 13:48 |
miker |
yeah, that's strange ... looking for the one-hit entry now |
| 13:48 |
* kmlussier |
runs out for a bit to grab lunch. |
| 13:57 |
miker |
hrm ... the timelog on the LP ticket does not seem to match what's actually in the rel_2_12 codebase... the strings are different |
| 14:10 |
miker |
scratch that... the log is from the record loading page, not the search loading page |
| 14:11 |
miker |
slowdown seems to happen in open-ils.search.multi_home.bib_ids.by_barcode |
| 14:12 |
miker |
which, in this case, makes to cstore calls: one to look up the copy by barcode, and a followup to retrieve the peer bibs for the copy |
| 14:18 |
miker |
if, for some reason, there was an error in the first cstore call (say, no barcode passed because of a failure in a preceding call, returning an error or "0" instead of a list of copies) I could see something like this happening |
| 14:18 |
* miker |
looks at mk_copy_query |
| 14:34 |
|
Jillianne joined #evergreen |
| 14:37 |
miker |
kmlussier: btw, the reason the bottom of the timelog on the test has the unapi.mmr stuff is for linking to other constituent records |
| 14:42 |
kmlussier |
miker: That makes sense. I'm beginning the think they may be different issues after all. |
| 14:43 |
miker |
well... we don't have a log for the metarecord 1-hit issue, but I bet it's essentially the same. and all signs in that timelog point to open-ils.search.multi_home.bib_ids.by_barcode |
| 14:47 |
* kmlussier |
could easily supply a log for that issue if it's helpful. |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:04 |
miker |
happy to :) |
| 16:42 |
|
mmorgan joined #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:18 |
|
jvwoolf left #evergreen |
| 17:23 |
pinesol_green |
[evergreen|Dan Wells] Forward port 2.11.7 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=df5b68d> |
| 18:40 |
|
sallyf joined #evergreen |
| 18:40 |
|
drigney joined #evergreen |
| 18:40 |
|
abneiman_ joined #evergreen |
