=== rangerpbzzzz is now known as rangerpb [15:39] hehe "AssertionError: 'HST' not found in 'HDT\n'" silly daylight savings messing with my integration tests [15:43] lol [17:13] powersj, i put a comment on your mp... i may be over thinking things. [17:28] smoser: hmm but won't that change between -0900 and -0800 depending on day light savings? [17:28] it should not. [17:29] and that command depends on what timezone you are in [17:29] which is ok, since we are setting [17:29] no... we specify the full time with offset -0400 [17:29] yes, but the output changes... here is mine: "Wed, 02 Nov 2016 22:47:00 -0600" [17:29] Thu, 03 Nov 2016 00:47:00 -0400 == Wed, 02 Nov 2016 19:47:00 -0900 [17:30] oh... maybe that's what I'm not getting [17:30] the output changes based on the default time zone of the system. [17:30] (your default time zone is 0600) [17:30] but the test is testing that we can set the default time zone to US/wierd-timezone [17:30] that must be hawaii ? [17:30] it is Hawaii [17:32] so .. if we correctly set the timezone [17:32] date will always convert the '--date' to the default timezone of the system. [17:32] and so we're checking that dates output was converted to the time zone that we expect to have set the system to [17:32] right? [17:33] yeah, let me change it and play with it a bit. Never used date like that before, so still grawking it. [17:33] :) [17:33] alternatively can't we check that /etc/localtime points to the right tz we specified? [17:36] ah that might be good too, check that symlink [17:37] http://paste.ubuntu.com/24171815/ [17:37] maybe that helps ? [17:39] well, the symlink could work, but that is somewhat of an implementation detail. [17:39] smoser: it does, thanks :) [17:39] where as the other way depends on 'date' behaviing correclty. [18:35] powersj, did you open a bug ? [18:35] for the timezone? [18:35] smoser: no [18:35] k [18:35] I did wrt the new password change (a 2nd one) [18:36] I'll get the timezone merge fixed up here in a bit [18:38] http://paste.ubuntu.com/24172068/ [18:39] lol [18:39] thank you :) [18:39] i'll just take that now. i think the comnments there make it more clear than my explanation before. [18:40] smoser: yes they do and wfm thanks [18:40] early november is probably a really bad time to pick [18:40] why? [18:40] as someone might think that is on the cusp of a time change. [18:41] ah [18:41] but i'm using it anyway [18:41] :) [20:31] powersj, you mentioned something about cloud-init tags and buildilng ? [20:31] in your qa report [20:31] more info ? [20:31] I was trying to understand why we needed the tags when setup.py runs. I had not looked at that file enough to understand how it gets packaged up [20:32] So looked into how you specify an init system and the check that occurs when building cloud-init via tag + version in __init__ [20:32] yeah, the check can be annoying for sure, but you should always have some tag to base it off of. [20:33] I've been played with snap'ing cloud-init as well and the python plugin doesn't take an option so I couldn't specify an init system [20:33] Even if it doesn't quite make sense too, it was an interesting lesson :) [20:36] powersj, python plugin doesnt take an option [20:36] ? [20:37] you mean tryin to get the init system into setup.py ? [20:37] yes [20:38] so your part would look like this: https://paste.ubuntu.com/24172666/ [20:38] and we would want a "options: ['--systemd']" or something like that [20:40] This all started because I was looking at https://build.snapcraft.io/ === rangerpb is now known as rangerpbzzzz