| === om26er is now known as om26er|afk | ||
| === om26er|afk is now known as om26er | ||
| === om26er is now known as om26er|doc | ||
| balloons | veebers, ronru asked me to wrap and sort the packaging for https://code.launchpad.net/~nskaggs/autopilot/fix-1328600/+merge/227399 so I did. Should be all set and all yours now | 22:00 |
|---|---|---|
| veebers | balloons: sweetbix, I'm taking a look now. Did you see my query from earlier? (re: how does this effect current tests, do they need changes, have you tested it against, say, the cal. app) | 22:01 |
| balloons | veebers, no I didn't see your query. So this should allow the calendar app and clock app to actually run tests against the datepicker | 22:09 |
| balloons | I tried my original changes long ago against them, but haven't tried them since. Umm.. It would be useful to run the UITK tests without the qml tests to workaround the bug. | 22:10 |
| balloons | I would say that's the best way to confirm things | 22:10 |
| veebers | balloons: hmm, those are quite some packaging changes there :-P but if robru approves it that's ok by me. Normally I would ask that un-related changes like that are in a different pre-req branch | 22:12 |
| balloons | veebers, yea I agree it muddle the water on packaging, but he requested it, so :-) | 22:14 |
| veebers | balloons: ack, fair enough. Can you get his 'ok stamp' on that MP please | 22:14 |
| balloons | veebers, yes I'll ask him to do so | 22:14 |
| veebers | thomi: do you know why python3-autopilot relies on libjs-jquery & libjs-underscore? I can imagine it being a build dep for the docs, but not the python3-autopilot package | 22:18 |
| thomi | veebers: it's a build-dep, is it not? | 22:19 |
| veebers | thomi: it's both | 22:19 |
| veebers | well, it's in the buld-deps | 22:19 |
| thomi | veebers: it's for coverage docs | 22:19 |
| thomi | the kbd shgortcuts | 22:19 |
| veebers | thomi: ah ok, that makes sense | 22:19 |
| thomi | no idea why it's a dependency of ap tho | 22:19 |
| veebers | (well after decoding that sentence ;-) ) | 22:19 |
| veebers | oh, I got confused. So we don't know why it's a dep for the python3-autopilot package? | 22:20 |
| veebers | balloons: I get a test error: http://pastebin.ubuntu.com/8294055/ | 22:24 |
| balloons | veebers, hmmm... | 22:26 |
| veebers | I pulled, built packages, installed and ran that one test (autopilot.tests.functional.test_types) | 22:26 |
| balloons | veebers, is DateTime(2013-12-31 23:00:00) coming from autopilot then? that would seem interesting. | 22:28 |
| veebers | balloons: that datetime aka reference will be coming from item.foo, right? | 22:30 |
| thomi | veebers: I don't know why it's a dependency, no - sorry | 22:32 |
| veebers | thomi: ack, I'll investigate further | 22:33 |
| balloons | veebers, my expectation is you would get 2014-01-01 in your local time from the qml, and we then compare it to the datetime object we create. I expect both to be 2014-01-01. the only diff between your run and my local run should be the local timezone that is assigned | 22:33 |
| balloons | do you agree? If so, it would seem something isn't quite right. | 22:34 |
| veebers | balloons: let me read what the test is doing | 22:36 |
| veebers | balloons: hmm, the DateTime init is receiving timestamp: 1388487600 which seems fine (think), but poking around with the debugger I see these: http://pastebin.ubuntu.com/8294235/ | 22:50 |
| veebers | am I confused or is something not right happening there | 22:50 |
| balloons | veebers, ohh I get it | 22:51 |
| thomi | veebers: one method applies DST, the other does not | 22:51 |
| veebers | ah right | 22:52 |
| balloons | veebers, at least jenkins loves me :-) green is green | 23:09 |
| veebers | balloons: heh :-) it's just that pesky NZTZ | 23:09 |
| balloons | veebers, what concerns me I guess is the property is read from the qml and converted to local time for you, so it's not 2014-01-01. | 23:15 |
| balloons | which is fine, it just means my reference date needs to expect that | 23:15 |
| balloons | which is what we said we wanted.. so I think it's ok to tweak the ref object | 23:16 |
| balloons | veebers, do you agree with this? http://paste.ubuntu.com/8294466/ | 23:30 |
| balloons | mmm.. I suppose I should derive the timestamp from the date | 23:32 |
| veebers | balloons: no, that's effectively just going to test that an objects value is the same as a copy of that object (using the references timestamp) | 23:32 |
| balloons | yep yep | 23:32 |
| veebers | what if the timestamp has been changed or whatever | 23:32 |
| veebers | balloons: also, seeing that code I'm a little concerned that existing autopilot tests will need to change to reflect the changes within autopilot | 23:33 |
| balloons | veebers, http://paste.ubuntu.com/8294543/? | 23:38 |
| balloons | little crazy.. | 23:39 |
| veebers | that seems a little heavy handed. Perhaps there needs to be a change in autopilot-qt (and -gtk)? | 23:42 |
| balloons | does it work locally for you? | 23:42 |
| balloons | veebers, the goal of this silliness was to replicate current behavoir | 23:42 |
| balloons | the idea was not to break anything and continue with the local timezone idea | 23:43 |
| veebers | balloons: ah ok, so not suggested as a fix? | 23:43 |
| veebers | sorry I'm a little confused onw :_\ | 23:43 |
| balloons | veebers, the paste? sorry I was jumping back to your thoughts about " also, seeing that code I'm a little concerned that existing autopilot tests will need to change to reflect the changes within autopilot" | 23:43 |
| balloons | on the overall changes, I was attempting to not break anything, which became painful at times | 23:44 |
| balloons | we could simply assume everything is in UTC and store things in utc etc.. a bit saner | 23:45 |
| veebers | balloons: ah ok, I asked that because this test is effectively doing what one would do in a test (i.e. compare the date against what was returned from the dbus procy object) | 23:45 |
| veebers | if you're having to do a bunch of code to produce an object to compare against we might have a problem | 23:45 |
| balloons | right.. I'm struggling with what I want this functional test to be.. and also a bit sad to see it fails for you.. But we understand why | 23:45 |
| veebers | right ok, I think I'm back up to speed now :-) I'll try your paste and make sure it works for me | 23:46 |
| veebers | balloons: that latest paste of yours passes on my machine | 23:47 |
| balloons | veebers, right excellent. It passes because I'm replicating exactly what I expect that object to be after being read by autopilot | 23:48 |
| balloons | the question I suppose now is, are you happy with how autopilot treats the date/ | 23:50 |
| balloons | veebers, I suppose we should simply run uitk tests and see what happens | 23:52 |
| balloons | minus the datepicker workaround changes I made | 23:52 |
| veebers | balloons: that would be a good start, are you able to make that so? | 23:53 |
| veebers | heh 'make it so'. balloons: put a hamburger on an intercept course with my mouth, make it so | 23:53 |
| balloons | veebers, I'm hungry.. no dinner yet for me! | 23:54 |
| * balloons running | 23:54 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!