| Time |
Nick |
Message |
| 01:50 |
|
GK1wmSU joined #evergreen |
| 01:51 |
|
GK1wmSU left #evergreen |
| 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? |
| 05:34 |
umarzuki |
docker container downloaded from https://hub.docker.com/r/mobiusoffice/evergreen-ils/ |
| 06:41 |
|
rlefaive joined #evergreen |
| 06:46 |
|
JBoyer joined #evergreen |
| 06:54 |
|
rlefaive joined #evergreen |
| 07:08 |
|
umarzuki joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:21 |
umarzuki |
hi |
| 07:28 |
|
agoben joined #evergreen |
| 07:36 |
|
rlefaive joined #evergreen |
| 08:10 |
umarzuki |
how to access container web from container? https://hub.docker.com/r/mobiusoffice/evergreen-ils/ |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:43 |
remingtron |
umarzuki: Have you seen these basic instructions? They might help. http://markmail.org/message/y5ir2fh3rs7ne4jo |
| 08:46 |
|
Dyrcona joined #evergreen |
| 08:51 |
|
jvwoolf joined #evergreen |
| 08:52 |
|
bos20k joined #evergreen |
| 08:53 |
|
collum joined #evergreen |
| 09:43 |
|
kmlussier joined #evergreen |
| 10:04 |
|
mmorgan1 joined #evergreen |
| 10:06 |
|
maryj joined #evergreen |
| 10:22 |
|
jeffdavis joined #evergreen |
| 10:44 |
|
collum_ joined #evergreen |
| 10:44 |
pinesol_green |
[opensrf|Graham Billiau] LP#1704116: fix intermittant failure of parallel building - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=740e725> |
| 10:45 |
|
Jillianne joined #evergreen |
| 11:13 |
berick |
kmlussier++ # i was just about to send the same email |
| 11:14 |
berick |
re: missing pieces |
| 11:14 |
pinesol_green |
[opensrf|Jason Stephenson] LP 1703958: Update Websockets Intructions for Debian Jessie - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=66acf02> |
| 11:28 |
kmlussier |
Yay! A new addition to https://wiki.evergreen-ils.org/doku.php?id=contributing:contributors! |
| 11:42 |
|
_adb joined #evergreen |
| 11:45 |
umarzuki |
remingtron: thanks |
| 11:47 |
remingtron |
umarzuki: you're welcome |
| 12:00 |
Bmagic |
umarzuki: did you get it to work? |
| 12:00 |
umarzuki |
yes |
| 12:00 |
Bmagic |
I saw your comment on dockerhub, I responded in comment |
| 12:08 |
pinesol_green |
[evergreen|Dan Wells] LP#1635737 Use new OpenSRF interval_to_seconds() context - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=04a1013> |
| 12:08 |
pinesol_green |
[opensrf|Dan Wells] LP#1635737 Add optional context to interval_to_seconds - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a481100> |
| 12:10 |
|
alynn26 joined #evergreen |
| 12:41 |
|
sandbergja joined #evergreen |
| 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 <mrylander gmail.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:17 |
dbwells |
Looks like adding, timezone => local will get at least the basic behavior I was expecting in that case, though the module warns about that being slow. I will add some of this to the bug as well, so it isn't all lost to IRC history. |
| 14:18 |
Dyrcona |
dbwells: I've noticed that DateTime before, you pretty much always have to specify the timezone. |
| 14:18 |
Dyrcona |
words comprehension difficult. :) |
| 14:19 |
* Dyrcona |
has been fighting with powersaving mode killing bluetooth and bluetooth not coming back. :( |
| 14:20 |
csharp |
comcast-- |
| 14:20 |
csharp |
comcast-- |
| 14:20 |
csharp |
comcast-- |
| 14:20 |
csharp |
comcast-- |
| 14:20 |
kmlussier |
comcast-- |
| 14:20 |
kmlussier |
@karma comcast |
| 14:20 |
pinesol_green |
kmlussier: Karma for "comcast" has been increased 0 times and decreased 10 times for a total karma of -10. |
| 14:21 |
csharp |
they arranged for me to have fiber at my new house this past Friday - learned today that they have to get permits and dig the line (estimating 10-15 days) |
| 14:21 |
csharp |
but on the bright side, new house! yay! |
| 14:22 |
kmlussier |
csharp: Congrats! |
| 14:22 |
csharp |
kmlussier: thanks! |
| 14:23 |
berick |
csharp: nice! still in Decatur area? |
| 14:23 |
csharp |
berick: Tucker, about 5 miles from my former place |
| 14:25 |
berick |
cool, my grandfather lived around there. |
| 14:32 |
|
mtcarlson left #evergreen |
| 14:39 |
miker |
dbwells: I'll look at it more closely as well. https://bugs.launchpad.net/evergreen/+bug/1705524 will bring org unit timezones in the form we need, so that may be part of a solution, too |
| 14:39 |
pinesol_green |
Launchpad bug 1705524 in Evergreen "Honor timezone of the acting library where appropriate" [Wishlist,New] |
| 14:40 |
kmlussier |
abneiman: Hmmm...I might find a silentfailures tag to be useful. |
| 14:40 |
|
kmlussier joined #evergreen |
| 14:41 |
kmlussier |
Or maybe it should be singular - silentfailure |
| 14:44 |
dbwells |
miker: yes, and on second look, I am now recalling I didn't change the default behavior, so there is no default context to fix (i.e. I didn't add any "now()"s at the OpenSRF level). The code just passes through whatever timezone the surrounding code uses, which I do imagine will be helped by the bug you referenced. |
| 14:44 |
abneiman |
kmlussier: I can see that being useful. I would vote for the sigular usage 'silentfailure' |
| 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:57 |
dbwells |
miker: yea verily |
| 14:57 |
miker |
we need to also do that when there is a $start_time |
| 14:57 |
miker |
and, in noncat_due_date |
| 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 |
| 16:52 |
kmlussier |
gmcharlt++ |
| 17:02 |
mmorgan |
gmcharlt++ |
| 17:04 |
|
mmorgan left #evergreen |
| 17:35 |
pinesol_green |
[evergreen|Josh Stompro] LP#1706148 - Hide "Hold is behind Circ Desk" checkbox in XUL patron registration. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=97dda31> |
| 19:49 |
|
https_GK1wmSU joined #evergreen |
| 19:52 |
|
https_GK1wmSU left #evergreen |
| 20:26 |
|
eady joined #evergreen |
| 20:29 |
|
rlefaive joined #evergreen |
| 22:15 |
|
https_GK1wmSU joined #evergreen |
| 22:17 |
|
https_GK1wmSU left #evergreen |
