| josharenson | the scopes crash is interesting... I haven't tried unity8 + xenial yet, I'll install it and try to reproduce (w/ and w/o the branch ^^) | 00:01 |
|---|---|---|
| === nudtrobert1 is now known as nudtrobert | ||
| === maclin1 is now known as maclin | ||
| === TheMuso` is now known as TheMuso | ||
| === nudtrobert1 is now known as nudtrobert | ||
| pstolowski | mzanetti, cimi hey, can take a look at https://code.launchpad.net/~unity-team/unity8/audioCardSupport/+merge/271605 ? | 11:35 |
| mzanetti | pstolowski, you mean merging with trunk etc? | 11:36 |
| mzanetti | ah I see you approved | 11:36 |
| mzanetti | cool, thank | 11:36 |
| mzanetti | cimi, can you do finalizing touches on it and get it landed then? | 11:36 |
| pstolowski | mzanetti, i mean a review from somebody from unity8 team, would like to land it soon | 11:36 |
| mzanetti | pstolowski, ack | 11:36 |
| Saviq | pstolowski, we'll need a unity8 silo soon, too, is there anything from you needing to land with it or can we just take care in our usual process? | 11:41 |
| cimi | mzanetti, I am mostly done | 11:41 |
| mzanetti | perfect | 11:41 |
| cimi | just minor comments I will comment soon | 11:41 |
| pstolowski | Saviq, this branch news new unity-api & shell plugin impl, so it needs to land alltogether (it's in silo 4) | 11:48 |
| Saviq | pstolowski, ah, ok, are you waiting to get another silo for shell plugin, or can I just take over silo 4 for a bigger unity8 landing? | 11:51 |
| Saviq | as it will probably take longer than just what you have there | 11:51 |
| pstolowski | Saviq, what if silo 4 is ready for qa today? would that be ok? | 11:53 |
| Saviq | pstolowski, hmm, not sure we can without waiting for Qt migration... | 11:55 |
| Saviq | pstolowski, would mean testing needed to install two silos (Qt 5.5 and silo 4) or enable proposed | 11:56 |
| Saviq | Mirv, wdyt ↑, we won't need a unity8 rebuild after Qt migrates? | 11:56 |
| pstolowski | oh | 11:57 |
| Saviq | pstolowski, https://requests.ci-train.ubuntu.com/#/ticket/20 FYI | 11:57 |
| pstolowski | Saviq, if it makes things simpler, then combine silo 4 stuff with yours; we have been blocked with this stuff for months, another week will not make a difference ;) | 12:06 |
| Mirv | Saviq: no, unity8 rebuild is already there and lp:unity8 is updated | 12:07 |
| Saviq | pstolowski, I just want to make things faster overall, but if that would mean blocking some other shell plugin landings, I can wait | 12:07 |
| Mirv | Saviq: and all silos build against proposed already too | 12:07 |
| Saviq | Mirv, right, but actually testing it after a rebuild would require using both the tested silo and the Qt one (or proposed), until it migrates? | 12:08 |
| Mirv | Saviq: right, that's true, it's easiest to use silo 012 until it migrates so that you don't get whatever else is in proposed | 12:09 |
| Mirv | Saviq: ah damn actually it's 012 + 059, maybe proposed actually is easier.. I checked recently and there were nothing super suspicious there | 12:09 |
| Mirv | since I don't core dev rights I moved UITK and oxide to 059 before publishing | 12:10 |
| Saviq | pstolowski, so, all in all, your call, you need a rebuild anyway, if you have further shell plugin landings you need, go for it, otherwise I just steal your silo 4 and make it mine :) | 12:18 |
| pstolowski | Saviq, no, that's the only shell plugin landing i've in the queue (filters are still WIP), so feel free to take it over | 12:19 |
| Saviq | pstolowski, ack, doing so | 12:19 |
| Saviq | @unity: please let me know if you have branches to land that are not yet top-acked | 12:19 |
| mzanetti | Saviq, what was the outcome on the uinput related branches then? | 12:20 |
| Saviq | mzanetti, there was none, yet, so we'll skip them for now | 12:20 |
| mzanetti | ack | 12:21 |
| mzanetti | Saviq, that one will be top-acked when jenkins is done with it: lp:~aacid/unity8/drag_with_quicklist | 12:21 |
| Saviq | mzanetti, ack | 12:21 |
| mzanetti | Saviq, noone looked at it yet, but you might as well just approve it right now :) https://code.launchpad.net/~mzanetti/unity8/inputinfo-debug/+merge/279117 | 12:21 |
| mzanetti | Saviq, this one is not reviewed yet, but IMO quite critical. We're losing windows atm: https://code.launchpad.net/~mzanetti/unity8/fix-occlusion-detection/+merge/278637 | 12:23 |
| mzanetti | dednick, btw, seems dandrader abstained from this one, so I guess it's for you again ^ | 12:23 |
| dednick | mzanetti: ok :) | 12:24 |
| ltinkl | dednick, left some comments in the size hints branch for you :p | 12:26 |
| ltinkl | meh, sry | 12:26 |
| ltinkl | dandrader, ^^ | 12:26 |
| dandrader | mzanetti, well, you told me dednick was on it. that | 12:27 |
| dandrader | s why I moved away | 12:27 |
| mzanetti | no prob... you guys fight for it :) | 12:27 |
| mzanetti | I don't mind who... but the issue is fixes is rather bad (if one uses windowed mode) | 12:28 |
| davmor2 | Man so much hostility in this channel since mzanetti became a tech lead the power has gone to his head | 12:31 |
| mzanetti | davmor2, huh? | 12:31 |
| davmor2 | mzanetti: most people don't recommend fighting for it ;) | 12:32 |
| mzanetti | oh, in our team we always fight over who gets the privilege to review branches :D | 12:33 |
| * davmor2 just pictures mzanetti sat on a throne in black leather issuing the "Finish Him" command :D | 12:33 | |
| mzanetti | ok... stick to that picture. it's probably better than the reality | 12:34 |
| cimi | tsdgeos, reviewed the audiocard | 12:34 |
| tsdgeos | cimi: cool, tx, heading off for lunch now, will read later | 12:35 |
| Saviq | cimi, https://code.launchpad.net/~cimi/unity8/shadow-ubuntu-store-icon/+merge/278172 | 12:37 |
| Saviq | cimi, * If you changed the UI, has there been a design review? | 12:37 |
| Saviq | noy yet | 12:37 |
| cimi | Saviq, yeah, no review | 12:38 |
| Saviq | cimi, +needed, or not done yet? | 12:38 |
| cimi | well, it feels obvious it's nice with the shadow, but I guess we need to ask a confirmation anyway | 12:38 |
| cimi | doing in a sec | 12:39 |
| Saviq | ltinkl, can we land https://code.launchpad.net/~lukas-kde/unity8/convergedIndicators/+merge/278170 without the corresponding indicator changes? | 12:39 |
| cimi | nope, tiheum is not online now | 12:39 |
| cimi | will ask as soon as he is back | 12:39 |
| ltinkl | Saviq, yea I guess so, the datetime indicator stuff is approved already, worst thing that could happen is that you get no calendar and no timezone list | 12:40 |
| Saviq | ltinkl, ack | 12:40 |
| Saviq | greyback, shall we land https://code.launchpad.net/~nick-dedekind/qtmir/polite-close/+merge/262188 ? | 12:44 |
| Saviq | seems to be the only qtmir MP, so might leave it to you to land, especially since it has no unity8 dependency | 12:44 |
| greyback | Saviq: I have it in silo 22 | 12:45 |
| Saviq | greyback, ah right | 12:47 |
| dandrader | Saviq, greyback, mzanetti https://code.launchpad.net/~dandrader/unity8/multiSurfaceApp/+merge/279112 nees to land. Who's going to review it | 12:47 |
| greyback | Saviq: I could do with a hand trying to land that. It built fine before qt5.5 | 12:47 |
| Saviq | greyback, ok, gimme a sec | 12:47 |
| Saviq | attente, hey, re: https://code.launchpad.net/~attente/unity8/gtk-qt-im-module/+merge/278522 | 12:48 |
| Saviq | attente, I removed it from /etc/environment and at least `initctl get-env QT_IM_MODULE` reports it fine | 12:48 |
| mzanetti | code wise it looks ok to me | 12:49 |
| Saviq | it's not there on adb shell / phablet-shell, but that's another issue, and setting it in unity8 job won't make it happen either | 12:49 |
| attente | Saviq: is that on the mako? | 12:50 |
| Saviq | attente, krillin | 12:50 |
| attente | Saviq: i'm not sure what the disparity is here, but i'm guessing /etc/profile.d/maliit-framework.sh isn't being run on the mako | 12:50 |
| Saviq | attente, checking on mako in a sec | 12:51 |
| attente | Saviq: in any case, i feel like that file shouldn't exist in the maliit source package | 12:51 |
| Saviq | attente, that does mean, however, that you won't get OSK in apps run from the shell | 12:51 |
| Saviq | attente, that I agree with, but I agree with tsdgeos unity8 shouldn't be the place for it either, rather the unity8 session | 12:52 |
| attente | Saviq: it also means that with /etc/environment, we're polluting the environment for other non u8 desktops and shells | 12:52 |
| Saviq | attente, sure, I agree having it in /etc/env isn't ideal either | 12:52 |
| attente | Saviq: sure, i could try moving it to u8 session instead | 12:53 |
| Saviq | attente, finding out why it's not working on mako, and/or why it's not there on ssh would be a good exercise, too | 12:54 |
| Saviq | @unity: if your branch isn't in https://requests.ci-train.ubuntu.com/#/ticket/29, it won't land in the next silo, so shout :) | 12:55 |
| mzanetti | I love that train pic | 12:55 |
| Saviq | damn comma | 12:56 |
| Saviq | greyback, ah, you have unity8 in there as well, it'd have to wait for ↑, or we merge the two? | 12:56 |
| Saviq | /food | 12:59 |
| * dandrader shouts https://code.launchpad.net/~dandrader/unity8/multiSurfaceApp/+merge/279112 to Saviq | 13:00 | |
| attente | ^ that isn't what i think it is, is it? | 13:01 |
| dandrader | attente, a step towards it | 13:03 |
| === alan_g is now known as alan_g|lunch | ||
| attente | :) | 13:04 |
| ltinkl | dandrader, Saviq: I guess the sizeHints branches could go into the silo as well (fixing the dialer bug - #1511530) | 13:10 |
| Saviq | tsdgeos, huh, trunk conflict in sectionUpdateDelegates?? https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/lastBuild/console | 13:36 |
| tsdgeos | ?¿ | 13:37 |
| tsdgeos | uh oh | 13:38 |
| tsdgeos | i think i have the merge unpushed :D | 13:38 |
| tsdgeos | Saviq: pushed | 13:39 |
| Saviq | tsdgeos, tx | 13:52 |
| Saviq | attente, FWIW I just flashed rc-proposed on my mako and removed the line from /etc/environment, still initctl shows it in the session env | 14:07 |
| attente | Saviq: were you able to unlock your device with the OSK still? | 14:07 |
| Saviq | attente, yes, everything works | 14:08 |
| Saviq | attente, in theory the maliit upstart job could set it instead, as when maliit's starting, it goes to reason that it could set the environment as appropriate | 14:08 |
| Saviq | attente, that still means if you ssh/phablet-shell into the device, you won't get that in your env, which means manually ran apps won't get OSK | 14:08 |
| attente | Saviq: any user who's launching apps in that way should be able to easily set those variables manually as well | 14:11 |
| mterry | greyback, heyo! Looks like I caused a regression (bug 1518764) with https://code.launchpad.net/~mterry/qtmir/no-touch-no-lifecycle/+merge/272791 by removing the RunningInBackground state (which had different wakelock semantics) | 14:11 |
| ubot5 | bug 1518764 in qtmir (Ubuntu) "Music app high power consumption when paused" [High,Confirmed] https://launchpad.net/bugs/1518764 | 14:11 |
| Saviq | attente, yes, agreed, just need to make sure the SDK team knows that, not sure how they're launching apps from the SDK in the end | 14:12 |
| attente | Saviq: i also thought that launching apps in this way is mostly discouraged and requires the use of the --desktop_file_hint argument | 14:12 |
| Saviq | attente, it is indeed, and we want to get rid of that at some point, wrapping every app launch in a proper upstart job | 14:12 |
| mterry | greyback, as I recall, you didn't like the state (wanted to keep qtmir as dumb as possible about lifecycle policy). But we may need something similar -- or can we fake it by saying any running app that isn't focused shouldn't have a wakelock? | 14:13 |
| Saviq | mterry, the wakelock's there to add the grace time for apps to suspend | 14:13 |
| Saviq | mterry, so whatever we do, we still need to keep those | 14:14 |
| Saviq | which is why it was held/released when any app wasn't suspended | 14:14 |
| mterry | Saviq, right but lifecycle-exempt apps don't care about that, so didn't need a wakelock eh? | 14:14 |
| Saviq | mterry, or they need one, just behaving as-if they were not exempt | 14:15 |
| mterry | Saviq, we stopped qtmir from knowing what a lifecycle exempt app was, so created this regression :( | 14:15 |
| mterry | Saviq, didn't understand "or they need one, just behaving as-if they were not exempt" | 14:16 |
| Saviq | mterry, I mean that exempt apps could still cause a wakelock, that would get released as if the app was suspended, even if it isn't | 14:18 |
| Saviq | mterry, that would still give the app time to react to an unfocus event before the device goes ~dead | 14:18 |
| mterry | Saviq, right -- so you're saying if we removed wakelock when unfocused, that wouldn't give any time to the app? /me reads up on focus vs suspend semantics in unity8 | 14:25 |
| Saviq | mterry, yes, the device would go to deep sleep immediately | 14:25 |
| mterry | Saviq, I'm just trying to see how that was any different before -- we'd suspend the app immediately if the greeter showed without any transition time | 14:27 |
| mterry | I mean, deep sleep immediately | 14:27 |
| mterry | (i.e. release the wakelock) | 14:27 |
| mterry | Was there a delay between focus lost and greeter show? | 14:28 |
| Saviq | mterry, there is | 14:28 |
| Saviq | mterry, well, wait, no | 14:28 |
| Saviq | mterry, there is a delay between focus lost and suspend | 14:28 |
| Saviq | mterry, that's the grace time the app gets for storing its state | 14:28 |
| mterry | Saviq, huh OK that's what I was trying to find. I don't see it in the qml -- looks like onGreeterShown, we set stage.suspended. Trying to find where we lose focus on the app. (I'm not doubting you, just trying to figure the code for whatever fix we apply) | 14:30 |
| greyback | mterry: aha boo, that is the issue | 14:30 |
| Saviq | mterry, that might be we lost the delay then | 14:30 |
| greyback | mterry: ok, then that state is necessary. My error | 14:30 |
| Saviq | unless qtmir applies the delay | 14:30 |
| mterry | Saviq, didn't seem to before anyway | 14:31 |
| Saviq | mterry, "before" as in before no-lifecycle... that would've been a bug, we need the delay | 14:31 |
| mterry | greyback, I can add the state back -- but for it to mean anything, it probably also means qtmir needs a "isLifecycleExempt" / "canSuspend" app property? | 14:32 |
| mterry | Saviq, I also might just not be seeing the delay -- I don't know where we unfocus the app exactly | 14:33 |
| greyback | mterry: lemme refresh my memory, 1 sec | 14:33 |
| Saviq | greyback, watch -n 0,1 "ps aux | grep dialer-app" | 14:35 |
| Saviq | mterry, ↑ rather | 14:35 |
| Saviq | and switch between dash and dialer-app, you'll see that dialer gets like 2s before it goes T | 14:36 |
| greyback | (should be 1.5 sec) | 14:36 |
| === marcusto_ is now known as marcustomlinson_ | ||
| mterry | Saviq, so good there isn't a bug... I'm just not sure who is introducing that delay. Might be powerd at this point, doesn't seem like unity8 or qtmir do it | 14:37 |
| mterry | Saviq, wait you are talking about suspending the executable, not the system wakelock | 14:38 |
| mterry | Which are related granted | 14:38 |
| === marcustomlinson_ is now known as marcustomlinson | ||
| mterry | Saviq, it took me a bit to figure out what -n 0,1 meant :) Silly Americans and our decimals | 14:40 |
| mterry | Ah... SuspendingWaitProcess is the delay | 14:41 |
| tsdgeos | cimi: there? | 14:44 |
| cimi | tsdgeos, yeah | 14:44 |
| tsdgeos | cimi: "we can probably use alias for this" | 14:44 |
| tsdgeos | is this for source or for color? | 14:45 |
| cimi | property url source, source: root.source in audioprogressbar | 14:45 |
| cimi | property alias source: progress.source | 14:45 |
| cimi | unless we need elsewhere | 14:46 |
| mterry | greyback, you would probably know -- where is that 1.5s delay from? SuspendingWaitProcess seems to indicate the delay, but I don't see the delay (I'm just trying to determine if qtmir treats non-focused running apps as suspended -- as a cheap fix for this regression -- if we would still be keeping that delay). I'm guessing that would lose the delay, I'm just trying to confirm | 14:47 |
| greyback | mterry: see qtmir::Session::suspend() and m_suspendTimer->start(1500); | 14:51 |
| mterry | greyback, ah very good. So qtmir could add a similar delay to releasing the wakelock when a app loses focus... But that wouldn't cover when an app is on top of the stack -- I suspect it doesn't lose focus when we show the greeter | 14:54 |
| mterry | In which case u8 needs to tell qtmir what's going on, indeed | 14:55 |
| === pat_ is now known as Guest71267 | ||
| === Guest71267 is now known as pmcgowan | ||
| mterry | greyback, why is there a wakelock per-app instead of a wakelock across the whole stage? | 14:58 |
| === alan_g|lunch is now known as alan_g | ||
| greyback | mterry: there is not a wakelock per-app, there is a single one for whole shell | 15:00 |
| mterry | greyback, I see... I guess I meant why is there a shared wakelock per-app instead of a wakelock across the whole stage :) (controlled by u8) Seems like qtmir is guessing at what u8 wants here (i.e. "is the greeter showing or no apps open") | 15:02 |
| mterry | greyback, but no matter | 15:03 |
| greyback | mterry: it is possible it is lacking info to make the right choice. Perhaps better for unity8 to manage the wakelock, and not qtmir | 15:03 |
| mterry | greyback, looks like priority of this regression is very high, possible OTA 8.5 fix. So quick fix would be basically reverting that MP from a while ago. Is there another reasonable quick fix that doesn't change API? (on the assumption that API changes wouldn't be quick) | 15:05 |
| mterry | I guess even the revert would need u8 changes / revert as well | 15:06 |
| greyback | mterry: if it does the job, I have no objection to that | 15:06 |
| greyback | presumably it worked well before that | 15:06 |
| mterry | greyback, well I'd like to avoid reverting -- or at least, if we revert, have qtmir pay attention to isTouchApp state so we don't regress that side of things | 15:07 |
| greyback | mterry: can we have a quick mumble about it? | 15:08 |
| mterry | greyback, sure | 15:08 |
| mterry | greyback, another solution mzanetti just proposed | 15:17 |
| mterry | greyback, mzanetti: u-s-c has a wakelock when the screen is on, eh? | 15:17 |
| mterry | greyback, mzanetti: so qtmir doesn't need to be as vigilant? | 15:17 |
| greyback | a display wakelock, which isn't the same I believe | 15:18 |
| mterry | greyback, mzanetti: mzanetti said maybe just hold it while an app is in starting state | 15:18 |
| mzanetti | when the screen is on, I have this: Name: com.canonical.Unity.Screen, Owner: :1.13, State: 1 | 15:18 |
| mzanetti | greyback, why would qtmir require the wakelock at all? | 15:18 |
| greyback | mzanetti: yeah, you're right | 15:18 |
| mterry | mzanetti, greyback: oh, but what about that 1.5s delay | 15:19 |
| greyback | mzanetti: it's needed for app suspend to be able to proceed, after you've blanked the screen (and dropped that screen wakelock) | 15:19 |
| mzanetti | I think the original wakelock in qtmir was just to make sure that an app can start up. but it would release it again once the app has started | 15:19 |
| mzanetti | right.. | 15:19 |
| mzanetti | for it's own sake... so qtmir can do what it needs to do. but it should not hold a wakelock *for* an app | 15:20 |
| mzanetti | ever | 15:20 |
| mzanetti | which makes me believe the fix is to remove the last line here: | 15:21 |
| mzanetti | void Application::setInternalState(Application::InternalState state) | 15:21 |
| mzanetti | case InternalState::Running: | 15:21 |
| mzanetti | acquireWakelock(); | 15:21 |
| mzanetti | (obviously also cleaning up the releases that were added for this etc) | 15:21 |
| greyback | mzanetti: as i said, original wakelock in qtmir was so that apps would get CPU time to suspend correctly on display blank. Without wakelock, the CPU immediately went into low-power mode, and app cleanup didn't complete. | 15:27 |
| mzanetti | ahh, right | 15:27 |
| greyback | so yeah, wakelock isn't really needed while screen is on, if I remember correctly | 15:27 |
| mzanetti | so we'd need to acquireWakeLock() when requestedState goes to suspended | 15:27 |
| mzanetti | and release it again when actual state goes to suspemded | 15:27 |
| greyback | sure | 15:28 |
| mzanetti | kk | 15:28 |
| mzanetti | ta | 15:28 |
| mzanetti | @unity & dednick: standup | 15:31 |
| mzanetti | dednick, I've pushed something that hopefully stabilizes that test... | 15:31 |
| mzanetti | not related to the actual code of the branch... but oh well, jenkins seems to want it there | 15:31 |
| Saviq | dandrader, standup, too, if you're able | 15:32 |
| dandrader | Saviq, gonna have to skip. see #unity | 15:33 |
| mterry | greyback, mzanetti: I was away from IRC for a bit -- looks like we can go down the route of removing wakelock handling a bit? | 15:36 |
| mterry | That would mean we wouldn't keep wakelocks ever for lifecycle-exempt apps, but I don't think that would change anything | 15:36 |
| mzanetti | mterry, why would'nt that change anything? | 15:39 |
| mterry | mzanetti, because lifecycle exempt apps don't need the 1.5s spin down (they never suspend) | 15:39 |
| Saviq | mterry, but they might react to unfocus | 15:40 |
| Saviq | mterry, but whatever's easier, really | 15:40 |
| mzanetti | they might indeed | 15:40 |
| mzanetti | but they will get some cpu time when push helper polls next time :D | 15:40 |
| mzanetti | just make sure to not break the 1.5 secs of wakelock for apps that *do* suspend | 15:40 |
| Saviq | indeed | 15:40 |
| Saviq | tests, pleaseee | 15:41 |
| mzanetti | (btw, I'd argue 1.5 secs is not enough) | 15:41 |
| mzanetti | when there's network connection involved at least | 15:41 |
| mterry | Saviq, but they can't rely on unfocus -- could be top app in stack and turn off screen | 15:41 |
| Saviq | mterry, wdym? | 15:41 |
| mterry | Saviq, we no longer unfocus the top app when we turn off the screen, eh? | 15:42 |
| Saviq | mterry, dunno, do we not? | 15:42 |
| mzanetti | afaict that would still get the application.state to != active | 15:42 |
| mterry | Saviq, I think there was a bug that caused so we stopped doing it | 15:42 |
| mzanetti | at least it should | 15:42 |
| Saviq | yeah, maybe that's what I meant | 15:42 |
| Saviq | !active | 15:42 |
| Saviq | not necessarily unfocused | 15:42 |
| mterry | Saviq, does the app see that? | 15:42 |
| mzanetti | Qt.application.state | 15:43 |
| mterry | Oh you mean Qt.application.active | 15:43 |
| mterry | or .state | 15:43 |
| Saviq | d'oh, ubot5 just PM'd me about !active | 15:43 |
| mzanetti | active is deprecated now, state is the new one yes, but it's the same | 15:43 |
| mterry | OK... maybe it sees that. I'm not sure | 15:43 |
| Saviq | it does | 15:43 |
| mterry | k | 15:43 |
| mterry | Saviq, mzanetti: but my point remains -- lifecycle exempt apps didn't get the 1.5 grace period before, so continuing to not have it isn't a regression | 15:44 |
| mzanetti | I'd be ok with that | 15:44 |
| mzanetti | I think | 15:44 |
| Saviq | mterry, oh ok, didn't know what was the state before, it could be very well that qtmir goes suspend? yeah, that one doesn't suspend, meh, but still does everything else re: wakelock | 15:45 |
| mzanetti | as they are not suspended, they don't need to hurry with saving state | 15:45 |
| Saviq | fine by me | 15:45 |
| Saviq | tesssttsss pleassee, though :) | 15:45 |
| mzanetti | if it's easy to do, add them a 1.5 grace period, but not a hard requirement I'd say | 15:46 |
| mzanetti | the tests are, I totally agree with Saviq | 15:46 |
| Saviq | pstolowski, hmm hmm any idea about " Destination version 0.2+15.10.20150922.1-0ubuntu2 is missing from changelog (unity-scope-mediascanner/xenial)."? | 15:46 |
| Saviq | also, jamesh, could we hide lp:unity-scope-mediascanner/vivid if it's not used any more? (is it?) | 15:46 |
| mterry | mzanetti, to add that grace period, we'd probably need the proposed application flag (controlled by u8) that I was going to use to fix this regression: exemptFromLifecycle. But... instead for the short term, I could rejigger the wakelock handling in qtmir to ignore running apps, which wouldn't (in theory) regress and still achieve the wakelock cleanup you wanted | 15:47 |
| mterry | Would only need "exemptFromLifecycle" if we wanted to add a grace period to exempt apps... | 15:47 |
| mterry | greyback, ^ what do you think? | 15:47 |
| pstolowski | Saviq, yes, I checked that already with laney, they made a no-change build in xenial, it can safely be ignored and overwritten | 15:48 |
| Saviq | pstolowski, ack | 15:48 |
| cimi | Saviq, ok to use the shadow in that ubuntu store icon/card | 15:50 |
| Saviq | cimi, ack | 15:50 |
| Saviq | greyback, so, shall I fold silo 22 into silo 4, or shall I do 4 first, then work on 22? | 15:51 |
| mzanetti | mterry, wfm | 15:51 |
| mterry | greyback, I'm leaning towards still doing exemptFromLifecycle since we can see utility for it anyway in other use cases (allowing grace time for exempt apps) | 15:51 |
| mzanetti | mterry, as I said, if it's easy. apparently it isn't so... | 15:52 |
| mterry | greyback, makes me less nervous than futzing with wakelocks in haste | 15:52 |
| greyback | Saviq: as you please. I don't have a strong opinion on it | 15:52 |
| greyback | I didn't get to testing silo22, so ok to dump it | 15:52 |
| greyback | mterry: sounds good | 15:52 |
| greyback | mterry: question: does music app even function if display is blanked & there is no wakelock? | 15:53 |
| greyback | ah, probably if music playing, it'll grab its own wakelock | 15:53 |
| mterry | greyback, yeah I think there is a separate wake lock for that | 15:54 |
| Saviq | greyback, ok, will tackle it next, don't want 15 projects in one silo | 15:54 |
| greyback | Saviq: okies | 15:54 |
| Saviq | mterry, greyback, yes, media hub takes care | 15:54 |
| Saviq | ltinkl, dandrader, I'll do sizeHints in next silo, don't have qtmir in this one | 15:57 |
| tsdgeos | cimi: i'll just remove the borderSource, i can't appreciate any different tbh :D | 16:00 |
| dandrader | Saviq, what about multiSurfaceApp? | 16:00 |
| Saviq | dandrader, next silo, too, ok? will start it maybe today, even, but will land after silo 4 lands | 16:01 |
| dandrader | Saviq, ok | 16:02 |
| cimi | tsdgeos, cool :) | 16:03 |
| Saviq | greyback, zsh top tip: http://www.zsh.org/mla/users/2005/msg00298.html ;) | 16:05 |
| mterry | mzanetti, who reviews qtmir stuff when greyback isn't online? | 17:31 |
| mterry | mzanetti, also, do you know if there are any other unity-api changes planned in this hotfix? | 17:32 |
| mterry | Saviq, ^ | 17:32 |
| Saviq | mterry, dandrader can review I'd say, I don't think there's a plan for a hotfix already, just "if there is a hotfix" | 17:33 |
| mterry | Saviq, cool | 17:33 |
| mterry | dandrader, feel up for some reviewing? | 17:33 |
| dandrader | mterry, sure | 17:35 |
| mterry | dandrader, haven't finished all the paperwork, but I don't expect changes to https://code.launchpad.net/~mterry/unity-api/fix-wakelocks/+merge/279476 or https://code.launchpad.net/~mterry/qtmir/fix-wakelocks/+merge/279481 -- unity8 companion on its way | 17:35 |
| mterry | dandrader, thanks! | 17:36 |
| mterry | dandrader, for the qtmir one, it may be instructive to compare with the older MP linked in the description | 17:47 |
| mterry | dandrader, large parts of my MP are merely the reverse of the old diff | 17:47 |
| dandrader | mterry, ok | 17:47 |
| mterry | dandrader, notably, all the RunningInBackground bits | 17:48 |
| dandrader | back in a bit | 17:49 |
| === dandrader is now known as dandrader|afk | ||
| === alan_g is now known as alan_g|EOD | ||
| mterry | Saviq, about the hotfix, I had assumed we were doing one for wifi-dbus problem. I'm going to make a silo for this fix, since it's hard to test otherwise. But we can fold it into whatever other silo exists for a hotfix if we have one | 18:18 |
| Saviq | mterry, I'll find out | 18:19 |
| Saviq | mterry, looks like there is a hotfix happening https://launchpad.net/canonical-devices-system-image/+milestone/ww50-2015 | 18:20 |
| mterry | k | 18:21 |
| Saviq | not sure what the process there is, though... | 18:21 |
| Saviq | like we've already got code post-ota8 in lp:unity8 I believe | 18:21 |
| mterry | Saviq, doesn't look like any other u8 changes ther | 18:21 |
| mterry | Saviq, right... | 18:21 |
| mterry | Saviq, maybe I should prepare backports | 18:22 |
| mterry | pmcgowan, ^ what's the process here, do we have a place to put fixes for 8.5? | 18:23 |
| mterry | like a silo target that makes sense (rather than xenial+vivid) | 18:24 |
| pmcgowan | mterry, land it to the vivid overlay then we will cherry pick it | 18:24 |
| Saviq | pmcgowan, even with post-ota8 code in there? | 18:24 |
| pmcgowan | Saviq, so I mistaked | 18:24 |
| pmcgowan | land it like its going to ota9 | 18:24 |
| Saviq | ah | 18:24 |
| mterry | pmcgowan, can do | 18:25 |
| pmcgowan | then sil2100 can grab it | 18:25 |
| mterry | pmcgowan, and we don't care about the other post-ota8 fixes being bundled in? | 18:25 |
| pmcgowan | mterry, we might yes | 18:25 |
| mterry | :) | 18:25 |
| Saviq | yehikes | 18:25 |
| mterry | Saviq, anything you can remember that is high risk there? | 18:25 |
| * Saviq checks when is latest stable | 18:26 | |
| mterry | I think we've had two or three u8 releases since then | 18:26 |
| Saviq | "ubuntu=20150713" whaa? | 18:26 |
| * pmcgowan braces | 18:27 | |
| Saviq | ubuntu=20151118.2 | 18:28 |
| Saviq | better | 18:28 |
| mterry | :) | 18:28 |
| === dandrader|afk is now known as dandrader | ||
| Saviq | mterry, I only worry it'll pull in new qtmir... new unity-api... new everything | 18:29 |
| mterry | dandrader, I put up u8 branch, linked to from others. I'm working on a silo for all of them | 18:29 |
| Saviq | just one release since | 18:29 |
| mterry | Saviq, well the fix I have needs new unity-api and new qtmir. So that's not unexpected. But yes, we have all the changes there too | 18:30 |
| pmcgowan | mterry, Saviq so I assume no way to just get this one fix? | 18:31 |
| Saviq | pmcgowan, there is, if we had a different landing target than vivid overlay | 18:31 |
| mterry | pmcgowan, we can -- I can do a backport... | 18:31 |
| mterry | right, but we need a new pocket to place the fixes | 18:32 |
| pmcgowan | hmm maybe we can need to ask sil2100 | 18:32 |
| Saviq | and even then, we don't really have where to build against | 18:32 |
| pmcgowan | he has a snapshot ppa | 18:32 |
| Saviq | oh | 18:32 |
| Saviq | that would be best | 18:32 |
| mterry | yeah that can work | 18:32 |
| pmcgowan | sounds like, not sure the logistics there | 18:32 |
| * mterry starts looking at backport feasability | 18:32 | |
| Saviq | but we've no PPA that builds against it... | 18:33 |
| Saviq | no silo I mean | 18:33 |
| pmcgowan | right I think not | 18:33 |
| pmcgowan | unless they have some magic | 18:33 |
| Saviq | but we (aka sil2100) could just upload to that silo directly | 18:33 |
| pmcgowan | yes | 18:33 |
| Saviq | if we provide hotfixed pkgs | 18:33 |
| Saviq | s/silo/ppa/ | 18:33 |
| mterry | Saviq, if I were to backport unity-api changes... is it best to just skip all the versioning bits then? Like not bother bumping api versions, since that would mean forked version meanings? | 18:34 |
| mterry | That seems like a hell we don't want to enter | 18:34 |
| Saviq | mterry, it's just a string, add a minor | 18:34 |
| Saviq | think that works... | 18:35 |
| mterry | Saviq, ah perfect :) | 18:35 |
| mterry | Saviq, even if it is treated somewhere as a number, presumably they can handle dots | 18:35 |
| mterry | Saviq, if I'm putting qtmir in a silo, the silo complains about missing qtmir-gles. Fair enough. But what's the standard way to get a suitable qtmir-gles branch in there? Same branch with a new MP against lp:qtmir/gles? | 18:38 |
| mterry | Or I guess new branch with same diff... | 18:39 |
| Saviq | mterry, just an MP with --unchanged commit these days | 18:45 |
| Saviq | mterry, you can use this one https://code.launchpad.net/~mir-team/qtmir/gles-sync/+merge/279108 | 18:45 |
| Saviq | mterry, we hope to get rid of that requirement soon | 18:46 |
| mterry | Saviq, yeah feels a bit wonky :) | 18:46 |
| Saviq | mterry, it's just to let train know where to get the gles from | 18:47 |
| mterry | Saviq, I have 8.5 versions of all the branches (~mterry/*/fix-wakelocks-8.5) but no where to build them I guess. But they are available when needed | 19:12 |
| Saviq | mterry, ack, thx | 19:13 |
| mterry | Saviq, dandrader: also, I've prepped silo 41 for the wakelock fix, but due to ci-eng issues (not enough space), I'm waiting to build it | 19:28 |
| Saviq | mterry, might as well fold it into silo 22, that will be the next qtmir-and-friends silo | 19:29 |
| mterry | Saviq, oh hm, ok. Probably means I need to rebase. will check that out | 19:29 |
| balloons | hey ChrisTownsend. Did jcastro reach out to you about running Unity8? It might be useful to update the old wiki pages with some current info for this cycle: https://wiki.ubuntu.com/Unity8Desktop and https://wiki.ubuntu.com/Unity8inLXC | 19:34 |
| ChrisTownsend | balloons: No, he didn't, but I can look in to updating those pages. I've meant to update the Unity8inLXC one for some time:) | 19:36 |
| balloons | ChrisTownsend, lovely. Probably better coming from you than me anyway. Thanks! | 19:37 |
| ChrisTownsend | balloons: Sure, I'll add it to my todo list. | 19:37 |
| balloons | but in short; using the lxc container is still the recommended way to try things right? | 19:38 |
| mterry | Saviq, dandrader: OK, abandoned silo 41 and moved my branches into silo 22, after rebasing them on dandrader's surfaceItemFillMode branches | 19:40 |
| Saviq | mterry, tx, should start taking care of that silo tomorrow | 19:40 |
| dandrader | mterry, in https://code.launchpad.net/~mterry/unity8/fix-wakelocks/+merge/279489 what about splitting that long sentence in two? | 19:47 |
| mterry | dandrader, which long sentence? | 20:09 |
| dandrader | mterry, commit message | 20:09 |
| mterry | dandrader, done | 20:10 |
| mterry | dandrader, oh whoops, that link is the superceded merge | 20:10 |
| mterry | dandrader, will do so on real merge too | 20:10 |
| dandrader | mterry, did you see the comment I made on the qtmir branch? | 20:17 |
| mterry | dandrader, yeah responding now | 20:17 |
| dandrader | mterry, replied | 20:30 |
| mterry | dandrader, oh sorry didn't know you wrote that code :) | 20:31 |
| mterry | dandrader, my point stands that this is merely reverting the code back to a previous state. But sure, I can throw some clean up in there | 20:31 |
| dandrader | mterry, about the test | 20:32 |
| dandrader | mterry, the point is to make intent clear | 20:32 |
| dandrader | mterry, as the applications were not chosen at randon | 20:32 |
| dandrader | mterry, that would prevent some other dev from reverting your change | 20:32 |
| mterry | dandrader, right. And I think the intent is clear with the check on requesting suspended state. But since there's disagreement about how clear it is, I will add a comment and more checks | 20:33 |
| dandrader | mterry, like in your original patch your app change looks random. I don't think anyone but you would know the reason behind it just from looking at the diff | 20:35 |
| dandrader | mterry, about the switch. I get your point. but since this is not git, bzr doesn't know you're reverting anything | 20:36 |
| dandrader | mterry, so I see no drawback in adding improvements here and there | 20:37 |
| dandrader | mterry, specially since this is effectively a coding style change/fix | 20:37 |
| mterry | dandrader, oh for sure the change looks random -- it's not clear from a diff perspective -- but I was talking about clarity of the test itself | 20:38 |
| mterry | Diffs are often obtuse. Maybe I should have added a clarifying line in the MP description. But that's a different beast from code changes | 20:38 |
| mterry | dandrader, fixed switch, am working on u8 test | 20:38 |
| dandrader | mterry, but I agree those tests are not the best... | 20:38 |
| mterry | dandrader, I think tests are OK now | 20:39 |
| dandrader | mterry, for instance the sole reason the second app is launched is to unfocus the first one. and that intent is not obvious | 20:39 |
| dandrader | mterry, patches look good (there were just those very minor comments) | 20:40 |
| dandrader | mterry, but I'm afraid I don't have to test it today | 20:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!