| === aaron is now known as Guest69666 | ||
| === aaron is now known as Guest32030 | ||
| === shuduo_ is now known as shuduo | ||
| === aaron is now known as Guest90122 | ||
| === chihchun_afk is now known as chihchun | ||
| === oSoMoN_ is now known as oSoMoN | ||
| sturmflut2 | mcphail: No, you've got "the" libprotobuf error, that was the error I got in the very beginning. If you look closely at my bug report you'll see that I built libSDL2 manually on the device with " --disable-mir-shared", did you disable the shared lib too? | 07:04 |
|---|---|---|
| sturmflut2 | mcphail, popey: The GBA emulator in the store works because it uses Qt, if that was the question. It doesn't use libSDL2. That was one of the first things I checked back then. | 07:10 |
| davidcalle | Good morning | 07:25 |
| seb128 | hey davidcalle | 07:31 |
| davidcalle | seb128, hey, comment ça va ? | 07:32 |
| seb128 | davidcalle, bien ! et toi ? | 07:32 |
| davidcalle | seb128, pareil :) | 07:32 |
| mcphail | sturmflut2: thanks. bschaefer also gave me the tip about --disable-mir-shared last night, so hopefully I can begin to make some progress. I see what you mean about the GBA emulator. I hope Qt isn't the only way way can get things running | 07:45 |
| sturmflut2 | mcphail: No, the Mir demo clients also work, which means direct access via libmirclient works, so the problem must be in libSDL2 somewhere. | 07:47 |
| sturmflut2 | mcphail: I also read something about libSDL1.2 supporting Mir now (?), maybe you could look at that | 07:48 |
| mcphail | sturmflut2: bschaefer also mentioned you have to explicitly disable opengl is the sdl build. I can't remember: does your build do that? | 07:50 |
| popey | sturmflut2: mcphail ah, I hadn't used --disable-mir-shared when I built it on my nexus 7 the other day. will try that | 07:58 |
| popey | thanks for the tips | 07:59 |
| mcphail | popey: --disable-video-opengl as well, apparently | 08:01 |
| === shuduo is now known as shuduo_afk | ||
| popey | for sdl2? | 08:04 |
| ogra_ | sturmflut2, looks like only x86 arches https://code.launchpad.net/~brandontschaefer/libsdl/add-mir-support-patch-sdl1.2/+merge/259423 | 08:08 |
| === oSoMoN__ is now known as oSoMoN | ||
| === chriadam is now known as chriadam|away | ||
| popey | Anyone know much about ubuntu-html5-app-launcher? I have an html5 app which works with 14.10-html framework, but with 15.04-html framework I get an apparmor denial.. | 09:53 |
| popey | [M#f?[ 1209.474884] type=1400 audit(1432201895.125:70): apparmor="DENIED" operation="exec" profile="dontcrash.popey_dontcrash_0.7" name="/usr/bin/ubuntu-html5-app-launcher" pid=23440 comm="exec-line-exec" requested_mask="x" denied_mask="x" fsuid=32011 ouid=0 | 09:53 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| kalikiana | t1mp: review? https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/dropGuDefaultTest/+merge/259740 | 10:13 |
| kalikiana | t1mp: updated https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/textDocument/+merge/252798 now taking advantage if the version split | 10:14 |
| t1mp | kalikiana: doesn't that test only check the default value if no env. var is set? And on the devices different values are set by means of an environment variable? | 10:16 |
| kalikiana | t1mp: no, it checks the default which is set by the env var | 10:17 |
| t1mp | hmm | 10:17 |
| t1mp | do we have a separate test for that then? | 10:17 |
| t1mp | I thought we have | 10:17 |
| kalikiana | lemme double-check | 10:18 |
| kalikiana | t1mp: yes. we have one that sets GRID_UNIT_PX and checks that the value is used | 10:19 |
| kalikiana | t1mp: I don't see the value in any default value tests... but I could, if somehow considered useful, make it unset the env var and then test iut | 10:21 |
| kalikiana | t1mp: https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/unsetGuBeforeDefaultCheck/+merge/259743 | 10:24 |
| sturmflut2 | popey: Does your .desktop file call "/usr/bin/ubuntu-html5-app-launcher" with the full path or just with "ubuntu-html5-app-launcher" | 10:28 |
| popey | sturmflut2: Exec=ubuntu-html5-app-launcher $@ --www=www | 10:34 |
| sturmflut2 | popey: Okay, probably a büg. My phone is not on 15.04 yet, so I can't check it :/ | 10:35 |
| kalikiana | better file a bügrepört then ;-) | 10:36 |
| sturmflut2 | popey: either I'm blind or the version of your game that's in the store (0.6) doesn't come with a "*.apparmor" file | 10:44 |
| popey | sturmflut2: it does.. app.json | 10:47 |
| sturmflut2 | popey: is that the correct filename? If I create a new HTML5 project for 15.04 with Qt Creator, it seems to call the file "app.apparmor" | 10:48 |
| popey | [M#cB "apparmor": "app.json", | 10:49 |
| popey | from my manifest.json | 10:49 |
| popey | to be clear, it works _fine_ if I use ubuntu-sdk-14.10-html and 1.2 | 10:49 |
| sturmflut2 | Ah, you tricked me | 10:50 |
| popey | \o/ | 10:55 |
| nik90 | mivoligo: ping | 10:59 |
| mivoligo | nik90: pong | 11:00 |
| nik90 | mivoligo: I tested timer with UC 1.2, and the first timer I created correctly generates an alarm as expected. Its the timers after that don't work. And I may have an idea why that might be. | 11:01 |
| mivoligo | nik90: great :) | 11:01 |
| nik90 | mivoligo: IIRC you're using reusing the same alarm object and calling alarm.reset() or alarm.cancel() whenever you want to destroy it and create a new timer. I think that's where things break. | 11:02 |
| nik90 | mivoligo: there is a sample alarm app created by zsombi in the ubuntu sdk that we could use for reference. | 11:02 |
| mivoligo | nik90: hmm... why is it working in 14.10 then? | 11:02 |
| nik90 | mivoligo: during the alarms backend improvements from 14.10 to 15.04 could have changed that behavior. I recall zsombi warning me of those, but they didnt apply to clock since we have a multi-page layout where a new alarm object is created whenever creating/editing an alarm | 11:03 |
| nik90 | s/clock/clock-app | 11:03 |
| nik90 | but it just struck me now when testing the timers app and noticing that only the first timer worked as expected in 15.05 | 11:04 |
| nik90 | s/15.05/15.04 | 11:04 |
| mivoligo | nik90: ok, that would explain it | 11:04 |
| mivoligo | nik90: how about wrong date? | 11:05 |
| nik90 | mivoligo: the wrong date is still a mystery. That said let's ping zombi together | 11:05 |
| nik90 | zsombi: ping | 11:05 |
| mivoligo | zsombi: ping ping | 11:05 |
| nik90 | mivoligo: https://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging/files/head:/tests/resources/alarm/ | 11:06 |
| nik90 | sample alarm app ^^ | 11:06 |
| mivoligo | nik90: thanks, I'll look into that | 11:08 |
| nik90 | yw | 11:11 |
| nik90 | mivoligo: ping me when you want to test the modifications you make on vivid | 11:12 |
| mivoligo | nik90: I will, but probably not today :) | 11:13 |
| nik90 | ok | 11:13 |
| mivoligo | nik90: I wonder if it is because I use only "alarm.cancel()". Maybe I should use alarm.reset() as well? | 11:14 |
| mivoligo | nik90: anyway I'm afk now | 11:15 |
| Mirv | bfiller: can you put gallery-app MP https://code.launchpad.net/~timo-jyrinki/gallery-app/allow_translating_date_strings/+merge/259755 to some queue of yours, or tell me if you want me to handle landing it? | 11:29 |
| === rickspencer3_ is now known as rickspencer3 | ||
| === aaron is now known as Guest25522 | ||
| === Guest25522 is now known as ahoneybun | ||
| === rmescandon is now known as rmescandon|lunch | ||
| === _salem is now known as salem_ | ||
| bfiller | Mirv: I added it to silo 7 and rebuilding now | 12:45 |
| Mirv | bfiller: thanks, it's not in a hurry but my personal pet bug on Bq :) | 12:58 |
| bfiller | Mirv: np | 12:59 |
| * seb128 looks angrily at popey | 13:03 | |
| seb128 | wth man | 13:03 |
| popey | uhoh | 13:03 |
| popey | wassup? | 13:03 |
| seb128 | opening a bug dumping 15 components in it | 13:03 |
| seb128 | generating spam for every subscriber to any of the component every time any of the other things they don't care about get an update | 13:04 |
| seb128 | launchpad should forbid such things :p | 13:04 |
| popey | oh. okay. | 13:04 |
| seb128 | I deleted u-s-s from the list to stop the spam btw | 13:04 |
| popey | from one bug? | 13:04 |
| t1mp | kalikiana: happroved https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/unsetGuBeforeDefaultCheck/+merge/259743 | 13:04 |
| popey | you don't get enough bug mail if you're bothered by one bug | 13:04 |
| seb128 | popey, best practice is "use a bug with several components" when those components are involved in the same issue and need to land work together | 13:05 |
| seb128 | popey, if you have similar change to different sources, open different bugs and use a tag | 13:05 |
| popey | Noted. | 13:05 |
| seb128 | like we don't open a bug "things that don't build" and go adding half the archive to it ;-) | 13:05 |
| seb128 | popey, thanks | 13:05 |
| popey | Thanks for the friendly advice. | 13:05 |
| seb128 | yw! :-) | 13:05 |
| t1mp | kalikiana: https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/textDocument/+merge/252798 has components.api failures | 13:06 |
| kalikiana | t1mp: gah... what ever made me invent that tool to haunt me now :-P | 13:15 |
| zsombi | nik90: pong, sorry for late reaction | 13:37 |
| nik90 | zsombi: hey, no worries. I am here actually on behalf of mivoligo who is hitting a bug with the alarms API that I am puzzled with as well | 13:39 |
| zsombi | nik90: shoot | 13:39 |
| nik90 | zsombi: he created a 3rd party "Timer" app by using the Alarms API..and when he creates a timer for 10 hours, the actual alarm is created 7 days later! Looking at the console output, alarm.date shows the correct time before alarm.save() is called. | 13:40 |
| nik90 | short term timers like 10 minutes, 50 minutes etc work as expected | 13:40 |
| zsombi | nik90: wow.... | 13:40 |
| nik90 | zsombi: one sec, let me grab the link to the code | 13:41 |
| nik90 | https://bazaar.launchpad.net/~mpredotka/timer/trunk/view/head:/Main.qml#L280 | 13:41 |
| nik90 | tempEndTime() is a function which basically takes the current time and adds the timer duration to it. It is then saved to alarm.date and then alarm.save() is called. Console output at alarm.date before save() is called shows the correct alarm time | 13:42 |
| nik90 | but actual alarm is created 7 days later | 13:42 |
| nik90 | he doesnt set dayOfAlarms since it is autodetected based on the alarm.date | 13:42 |
| zsombi | nik90: I do not see alarm.reset() being called | 13:43 |
| nik90 | zsombi: this bug is reproducible on rtm and vivid. | 13:43 |
| nik90 | true, he calls alarm.cancel() instead | 13:43 |
| zsombi | nik90: that deletes the alarm | 13:43 |
| nik90 | yeah he doesn't seem to call alarm.reset() | 13:44 |
| nik90 | zsombi: although that should only affect the 2nd timer created..not the very first time the alarm object is used though | 13:44 |
| zsombi | nik90: so, is this happening on the first alarm created at the app launch as well? | 13:44 |
| nik90 | zsombi: yup ;) | 13:44 |
| zsombi | nik90: ahham, now that's weird! | 13:45 |
| nik90 | zsombi: yeah that's what i told him...considering we do this in clock app everyday | 13:45 |
| zsombi | uuuuuuhjhjhhhhh! | 13:46 |
| zsombi | nik90: the tempEndTime() is a bit weeeeeeiiiiiiird | 13:46 |
| zsombi | nik90: I'm not sure it does calculate properly... | 13:46 |
| zsombi | it could be though | 13:46 |
| zsombi | nik90: it would be nice to see what is the dayOfWeek value | 13:47 |
| nik90 | zsombi: ok, I will play around with it and also check with mivoligo to double check his tempEndTime() function. But you're the right, the bug is most likely present there | 13:48 |
| nik90 | zsombi: btw you said something about not calling alarm.reset() and alarm.cancel() on the same alarm object? | 13:48 |
| nik90 | or something related to that | 13:48 |
| zsombi | nik90: I mean it doesn't matter if the time is 10 hours later set, it shouldn't move to 7 days later, unless the daysOfWeek is f*ed up | 13:49 |
| zsombi | nik90: yes, when you use AlarmModel.get() function returned one | 13:49 |
| zsombi | nik90: as that one destroys the alarm cache | 13:49 |
| nik90 | ah ok | 13:50 |
| nik90 | zsombi: we'll do more investigations and let you know what's causing this issue. | 13:50 |
| === aaron is now known as Guest71030 | ||
| === chihchun is now known as chihchun_afk | ||
| seb128 | hum | 14:47 |
| seb128 | are those warnings a known issue? | 14:47 |
| seb128 | QML Button: Theme.createStyleComponent() is deprecated. Use ThemeSettings instead. | 14:47 |
| nik90 | seb128: on vivid I presume? | 14:49 |
| seb128 | nik90, wily | 14:49 |
| seb128 | desktop | 14:49 |
| seb128 | but seems vivid device have similar warnings | 14:49 |
| nik90 | seb128: yeah something I have observed as well. I think this should be fixed once the SDK properly separates out Ubuntu.Components 1.2 and 1.1 versions..at the moment they share code. I believe the fix should have landed in staging. | 14:50 |
| seb128 | shrug | 14:50 |
| nik90 | and since in UC 1.3, it is recommended to use ThemeSettings we get the warning despite regardless of whether we use UC 1.1 or 1.2 | 14:51 |
| nik90 | yeah we have already complained about this before :P .. and the fix is on its way. | 14:51 |
| t1mp | nik90: we have the <=1.2 and 1.3 versions split in UITK now | 15:05 |
| t1mp | nik90: there are technical issues in printing that warning only for 1.3 when using old properties.. so with <= 1.2 it is being printed too although in those versions there is no alternative | 15:06 |
| t1mp | nik90: no fix for those warnings is planned now | 15:06 |
| nik90 | t1mp: ah okay. ack. | 15:06 |
| nik90 | seb128: ^^ | 15:06 |
| t1mp | nik90: we split up the qml code, but all versions have the same cpp code | 15:08 |
| nik90 | t1mp: wouldn't that mean API changes in 1.3 can leak back to 1.2 which is why the qml code was split up in the first place? Is it planned to split the cpp code as well? | 15:09 |
| nik90 | although I can imagine this is a hercules task and so can understand the difficult | 15:10 |
| nik90 | s/difficult/difficulty | 15:10 |
| t1mp | nik90: in cpp we can control which properties to expose in which versions | 15:10 |
| t1mp | nik90: I'm not sure how much work it would be to split the cpp as well | 15:10 |
| t1mp | zsombi can probably comment on that | 15:10 |
| popey | balloons: got some time to help me debug a failing AP test? | 15:22 |
| popey | balloons: https://code.launchpad.net/~pkunal-parmar/ubuntu-calendar-app/DefReminderTime/+merge/257743 | 15:23 |
| popey | balloons: Given i can not trust the AP tests i run locally, and we spoke yesterday about relying on jenkins ones running, these fail. | 15:24 |
| balloons | popey, give me 10 mins, I'll look | 15:26 |
| popey | thanks | 15:26 |
| mzanetti | popey, is there something we need to discuss in terms of reminders? | 15:30 |
| mzanetti | popey, I'm at the unity sprint, so again not really progress here :/ | 15:30 |
| popey | mzanetti: no worries, i expected that | 15:30 |
| mzanetti | popey, I'm aware of the icon update thing | 15:30 |
| mzanetti | sergiusens, speaking of reminders... | 15:31 |
| mzanetti | sergiusens, you left a comment that you can't access your evernote notes when offline... that should work | 15:31 |
| mzanetti | it doesn't for you? | 15:31 |
| balloons | popey, ok, going to pull and have a look | 15:34 |
| popey | balloons: whole bunch of calendar merges failing | 15:35 |
| popey | balloons: thats just the first | 15:35 |
| popey | (probably failing in the same way) | 15:35 |
| balloons | ok, jenkins failures can be dealt with | 15:36 |
| balloons | ohh popey I forget. It seems we're still running on utopic for core apps. Is there a reason for that? it seems for instance shorts is only running on utopic | 15:37 |
| balloons | rtm concerns? | 15:37 |
| popey | users are still on utopic | 15:39 |
| balloons | popey, so looking at that it seems the build timed out. i don't see issues with tests, although they re-ran jenkins after it failed once | 15:39 |
| popey | ok, I'll re-run that one. others are failing in other ways. | 15:39 |
| popey | hence why i tried running them locally and they failed differently | 15:40 |
| balloons | popey, yes, and I have no good news to share on that. We can only gate on the test runs at build | 15:41 |
| balloons | so long as that environment isn't even close to a device we'll have issues like this | 15:41 |
| popey | https://code.launchpad.net/~pkunal-parmar/ubuntu-calendar-app/EventColorOnMonth/+merge/259321 | 15:42 |
| popey | like that for example | 15:42 |
| balloons | for instance, why on earth are we still building and testing them as debs :-( | 15:42 |
| popey | We can discuss wishlist items for testing another time IMO. Right now I have branches which won't land because they're failing AP. | 15:44 |
| popey | balloons: suggestions of a way forward welcome. I'm beating my head against the desk here. | 15:53 |
| balloons | popey, jenkins is the only gatekeeper; broken as it is. I see the one change is basically a color change so no way it should cause breakage. I wonder how the tests get landed in a broken state. | 15:55 |
| balloons | the only "fix" is to make a new mp, fixing the issues we see in other test runs, landing it, then re-running the existing mps | 15:56 |
| popey | which I have no resource to do. | 15:56 |
| balloons | it's the fact this isn't the first time we've fixed calendar in this way that I find more concerning | 15:57 |
| balloons | anyways, I'm looking at the tests now | 16:00 |
| popey | it fails here looking for 17 but gets 18. like it thinks the week starts on sunday | 16:02 |
| popey | but it actually starts on monday | 16:02 |
| ogra_ | thats what you think :P | 16:02 |
| popey | balloons: test_selecting_a_day_switches_to_day_view looks like it's looking for days[0]? | 16:05 |
| balloons | popey, we do have another option though. If we are finding tests are not running properly, we should simply disable them | 16:05 |
| balloons | popey, ahh yes, I believe carla was working with kunal on that. There was concern it was an application bug | 16:05 |
| balloons | sorry, was working on getting depends installed and env setup to run | 16:09 |
| popey | self.week_view.firstDay is 17th, days[0] is 18th | 16:09 |
| popey | which clearly aren't the same | 16:09 |
| balloons | popey, that issue is a locale one. I remember carla pushing a fix for it, but also talk about if there was an application bug or not | 16:11 |
| balloons | I'm looking at the first one you linked, so test_selecting_a_day_switches_to_day_view | 16:11 |
| popey | test_selecting_a_day_switches_to_day_view is indeed the one I am looking at | 16:12 |
| popey | the one I just ran on my pc and observed the above | 16:12 |
| balloons | I've no idea what this testcase is | 16:12 |
| balloons | insanity | 16:12 |
| balloons | just re-write it sanely | 16:12 |
| popey | balloons: short term? | 16:16 |
| balloons | popey, that is the short term. gut it | 16:23 |
| balloons | popey, k next | 16:24 |
| popey | balloons: gut as in skip? | 16:25 |
| balloons | popey, no, as in I rewrote it sanely | 16:25 |
| balloons | so what other tests? | 16:25 |
| popey | balloons: https://code.launchpad.net/~pkunal-parmar/ubuntu-calendar-app/WeekViewHighlight/+merge/259111 fails in the same way | 16:27 |
| popey | balloons: https://code.launchpad.net/~pkunal-parmar/ubuntu-calendar-app/MonthHighlight/+merge/259323 fails differently | 16:28 |
| balloons | ok, so let's see which test fails there | 16:29 |
| balloons | we'll land this in one mp | 16:30 |
| popey | hmm, that one fails oddly | 16:32 |
| popey | left a comment on it [M#O9http://i.imgur.com/FAfLe7R.png | 16:35 |
| sergiusens | mzanetti: it didn't atm, I can try again. Maybe I was on a slow connection and it froze the thread waiting for updates (like telegram) instead of showing the cached view first (although that brings in a lot of sync logic as well) | 16:35 |
| popey | balloons: thanks for the help. I'm getting a better understanding of these. | 16:36 |
| balloons | popey, so what I did to fix was simply have the test tap a visible date on weekview, and ensure the dayview is loaded with the proper date | 16:37 |
| balloons | not worrying about trying to ensure the test calculates first day of the week the same as the app in every locale | 16:37 |
| popey | right | 16:39 |
| balloons | test_selecting_a_month_switch_to_month_view is a legit fail, the feature change apparently | 16:40 |
| balloons | tapping a month doesn't load month view now | 16:40 |
| balloons | I'm 10 mins late for lunch, I have to run :-( | 16:40 |
| popey | o/ | 16:41 |
| mzanetti | sergiusens, there is a known issue that the connection establishment is blocking, yes... but for example if you are completely offline, it should work | 16:57 |
| === oSoMoN__ is now known as oSoMoN | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === Guest71030 is now known as ahoneybun | ||
| === aaron is now known as Guest7210 | ||
| === Guest7210 is now known as ahoneybun | ||
| pretec | hi | 19:11 |
| === aaron__ is now known as ahoneybun | ||
| balloons | popey, if you are about: https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/fix-illogical-tests/+merge/259841 | 19:34 |
| balloons | if there's any other test, let me know | 19:34 |
| === dobey_ is now known as dobey | ||
| popey | balloons: i am about! | 19:46 |
| balloons | popey, excellent. So any other testcases causing you heartache within calendar? | 19:48 |
| balloons | I fixed the 2 I found in the mp's you sent | 19:48 |
| mzanetti | popey, hmm... seems the reminders-app jenkins got lost | 19:48 |
| popey | eh? | 19:48 |
| mzanetti | your icon branch failed because it was "killed" | 19:48 |
| mzanetti | I restarted it, it never came back | 19:49 |
| mzanetti | then I approved the branch, jenkins doesn't care | 19:49 |
| popey | nice | 19:49 |
| popey | balloons: i think those cover the worst offenders | 19:50 |
| popey | balloons: thank you | 19:50 |
| balloons | popey, you are welcome.. I hope it's a small relief from the pain | 19:50 |
| balloons | feel free to reach out if things spiral again | 19:50 |
| popey | thanks balloons | 19:51 |
| * popey asks about mzanetti issue in -ci-eng | 19:51 | |
| mivoligo | nik90: thanks for speaking with zsombi in my name. Just seen the backlog. | 21:16 |
| === aaron is now known as Guest8727 | ||
| mivoligo | nik90: I've pushed new version with added alarm.reset() Can you check if it works on 15.04, please? | 21:17 |
| === Guest8727 is now known as ahoneybun | ||
| nik90 | mivoligo: pushed to trunk? | 21:34 |
| mivoligo | nik90: yes, also haptic feedback | 21:34 |
| nik90 | mivoligo: sure, sec | 21:34 |
| mivoligo | nik90: thanks :) | 21:35 |
| nik90 | mivoligo: it works! one stone 2 birds | 21:37 |
| nik90 | mivoligo: it also fixed the 10 hours issue | 21:38 |
| mivoligo | nik90: I don't think so | 21:38 |
| mivoligo | nik90: not on my phone at least :) | 21:38 |
| mivoligo | nik90: it doesn't have to be 10 hours, just a long enough to end after midnight | 21:39 |
| mivoligo | nik90: http://paste.ubuntu.com/11271581/ | 21:39 |
| nik90 | mivoligo: it does for me on wily (devel-proposed) | 21:39 |
| nik90 | mivoligo: I set it to 11 hrs, 10 hrs, 3 hrs etc...local time now is 11:40 PM | 21:39 |
| nik90 | timer ends correctly tomorrow | 21:40 |
| nik90 | as per indicator-datetime | 21:40 |
| mivoligo | nik90: hmm... can you show the log? | 21:40 |
| nik90 | sure, 1 sec | 21:40 |
| nik90 | mivoligo: http://paste.ubuntu.com/11271633/ | 21:42 |
| mivoligo | nik90: I think the Alarm takes only time into account and thinks it's set to time before current time so it schedule the alarm for the next week | 21:42 |
| nik90 | mivoligo: well the logs says otherwise | 21:42 |
| nik90 | although the alarms.daysOfWeek before and after save looks different | 21:43 |
| nik90 | mivoligo: actually before save it is 16 (friday) and after save it is 128 (auto-detect). So its actually correct | 21:44 |
| mivoligo | nik90: so it's something wrong in Alarm code for 14.10 then? | 21:45 |
| nik90 | mivoligo: I tested this on UC 1.2 + wily (devel-proposed). Let me try with UC 1.1 and see if I can reproduce the bug | 21:46 |
| nik90 | that should give us the answer to your question | 21:46 |
| mivoligo | nik90: ok | 21:46 |
| nik90 | mivoligo: both bugs seems fixed even with UC 1.1...http://paste.ubuntu.com/11271689/ | 21:48 |
| nik90 | mivoligo: I am not sure what the answer is ;P...it seems fixed in UC 1.1 and 1.2 but yet reproducible on RTM according to you | 21:49 |
| mivoligo | nik90: strange | 21:49 |
| nik90 | mivoligo: either way I think its fine since OTA-4 should solve your problems | 21:50 |
| mivoligo | nik90: do you have RTM device to test? | 21:50 |
| nik90 | but I will report back to zsombi about this | 21:50 |
| nik90 | mivoligo: I do have a BQ RTM device, but I am currently in the process of testing it from the perspective of a ordinary user .. so side loading of apps | 21:51 |
| nik90 | sry I meant *no* side loading of apps | 21:52 |
| mivoligo | nik90: ok | 21:52 |
| mivoligo | nik90: many thanks for your help :) | 21:52 |
| nik90 | yeah no problem..btw are you going to wait for OTA-4 for the next update? | 21:53 |
| mivoligo | nik90: probably not :D | 21:53 |
| nik90 | mivoligo: actually could you share your app log when reproducing the bug? I want to check the daysOfWeek value as asked by zsombi | 21:53 |
| === aaron__ is now known as ahoneybun | ||
| mivoligo | nik90: http://paste.ubuntu.com/11271581/ | 21:54 |
| nik90 | mivoligo: thnx. the date alone seems messed up. | 21:55 |
| mivoligo | nik90: ? | 21:55 |
| nik90 | mivoligo: in your log, the date may 22 and may 28 seems wrong somehow | 21:56 |
| mivoligo | nik90: today is may 21 here (yet) | 21:57 |
| mivoligo | nik90: as I said my theory is Alarm checks the time only | 21:59 |
| nik90 | yeah yeah I understand | 22:00 |
| nik90 | I was just confirming your theory | 22:00 |
| mivoligo | nik90: ah ok, I thought you see something wrong with the date format :) | 22:00 |
| mivoligo | nik90: btw, as you're in different time zone, I guess you experiencing bug 1457021 as well? | 22:02 |
| ubot5 | bug 1457021 in Timer "Timer finished x:y:z ago - 1 hour too much" [Medium,Confirmed] https://launchpad.net/bugs/1457021 | 22:02 |
| nik90 | mivoligo: hmm I can check...usually once I stop the timer in the notification, I forget to back to the timer app until like few hrs later. Let me try now to confirm it | 22:05 |
| nik90 | mivoligo: yup it seems that the timer does start at 1hr instead of 00:00 | 22:08 |
| mivoligo | nik90: thanks again for your time ;) | 22:08 |
| mivoligo | nik90: have a good night :) | 22:09 |
| nik90 | gud nite | 22:09 |
| === salem_ is now known as _salem | ||
| === aaron is now known as ahoneybun | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
