[07:30] <tsdgeos> autopilot still not passing when it's not hanging :/
[07:31] <tsdgeos> seems the card dednick and me did last sprint may need resurrection
[07:41] <Saviq> tsdgeos, FWIW two of those are new from dednick
[07:41] <tsdgeos> so we kind of fixed the olds and sneaked new wrong ones?
[07:41] <tsdgeos> :D
[07:41] <Saviq> yeah
[07:43] <Saviq> tsdgeos, so yeah, "good" news confirmed, got it to crash with NO_REGALLOC
[07:44] <Saviq> I *think*, although the .crash's ProcEnviron doesn't list it :/
[07:44] <Saviq> ah but apport actually strips the environ
[07:45] <Saviq> yup, job still has it
[07:47] <tsdgeos> :)
[07:48] <tsdgeos> tsdgeos_work@xps:~$ du -hs /home/tsdgeos_work/.cache/ubuntuimages/
[07:48] <tsdgeos> 14G     /home/tsdgeos_work/.cache/ubuntuimages/
[07:48] <tsdgeos> lol
[07:49]  * tsdgeos recovers some easy space
[07:50] <Saviq> tsdgeos, `ubuntu-device-flash --clean-cache touch` FTW
[07:50] <tsdgeos> ubuntu-device-flash is too obnoxious over the command line arguments order
[07:51] <tsdgeos> couldn't get it to work
[07:51] <tsdgeos> tsdgeos_work@xps:~$ ubuntu-device-flash --clean-cache
[07:51] <tsdgeos> DEPRECATED: Implicit 'touch' subcommand assumed
[07:51] <tsdgeos> unknown flag `clean-cache'
[07:51] <tsdgeos> tsdgeos_work@xps:~$ ubuntu-device-flash touch --clean-cache
[07:51] <tsdgeos> unknown flag `clean-cache'
[07:53] <Saviq> tsdgeos, yeah, you need "touch" at the end
[07:54] <Saviq> tsdgeos, some args are pre-subcommand, others ar post-subcommand,  and the implicit "touch" subcommand is, as stated ↑ deprecated (even though in this case it should work)
[08:32] <tsdgeos> Saviq: so you basically start & stop until it crashes?
[08:34] <tsdgeos> i'm also a bit confused as to what the shellRotation branch does
[08:34] <tsdgeos> should it actually rotate the shell
[08:34] <tsdgeos> ?
[08:35] <tsdgeos> because i can't get the dash nor the launcher to rotate
[08:35] <tsdgeos> or this is only for N7?
[08:44] <Saviq> tsdgeos, launch an app
[08:44] <Saviq> tsdgeos, dash is portrait
[08:44] <Saviq> tsdgeos, and yeah, it just dies on start 50% of the time or so
[08:46] <tsdgeos> it dies on stop here
[08:47] <tsdgeos> but not on start :/
[08:55] <Saviq> tsdgeos, yeah, on stop reliably, on start less so
[08:55] <Saviq> tsdgeos, how you launching? upstart or trying to get it under gdb?
[08:56] <tsdgeos> i was trying upstart
[08:56] <tsdgeos> but if you have better suggestions
[08:56] <tsdgeos> i just want it to crash once :D
[08:56] <Saviq> upstart's fine, but "kill -9 `pidof unity8`" instead of initctl stop
[08:56] <Saviq> tsdgeos, this way you won't need to fight with apport/whoopsie
[08:57] <Saviq> and probably stop unity8-dash and maliit-server to not crash
[09:11] <tsdgeos> Saviq: which phone are you using?
[09:11] <Saviq> tsdgeos, mako
[09:11] <tsdgeos> i can't still reproduce it not even once :/
[09:11] <tsdgeos> same here
[09:12] <Saviq> tsdgeos, you got unity8 from demo-stuff?
[09:12] <tsdgeos> yeah
[09:12] <Saviq> hmf
[09:12] <tsdgeos> i checked that the shell rotates when rotating the webbrowser
[09:12] <tsdgeos> that's it, no?
[09:12] <Saviq> yeah
[09:13] <Saviq> you could try running the ap tests in a loop until it fails (but it also rarely fails without unity8 crashing)
[09:13] <tsdgeos> my problem is
[09:13] <tsdgeos> i can get it to enter the "dbus deadlock" quite easily
[09:13] <tsdgeos> so any kind of looping is useless
[09:13] <tsdgeos> since it will get stuck in there
[09:14] <Saviq> tsdgeos, interesting, I'm not getting that so often ;)
[09:16] <Saviq> tsdgeos, maybe try with my screen+gdb upstart hack, gdb should be enough I think to kick the dbus lock away, and then when it happens you got it under gdb already
[09:17] <Saviq> see my big comment in https://trello.com/c/lAudAZVp/40-13-shell-rotation-mp-review-iteration-on-feature-and-autopilot-tests
[09:28] <tsdgeos> and now suddenly i'm getting it more
[09:28] <tsdgeos> :D
[10:31] <Cimi> mzanetti, I'm having a look at recency for the spread, how would you recommend storing the list of apps and storing screenshots?
[10:31] <mzanetti> Cimi, in qtmir
[10:31] <mzanetti> Cimi, ApplicationManager.cpp
[10:31] <Cimi> ok
[10:32] <mzanetti> Cimi, basically what needs to happen is that on startup the ApplicationInfo objects are stuffed into the ApplicationManage again
[10:33] <Cimi> mzanetti, ApplicationInfo is stored on the disk?
[10:33] <mzanetti> Cimi, but with status "suspended" (or stopped - can't recall which one is for "not running" but still running)
[10:33] <mzanetti> Cimi, no. they are not yet...
[10:34] <mzanetti> Cimi, on shutdown you'd need to store the appids for all the existing applicationinfo objects
[10:34] <mzanetti> Cimi, and on startup create new objects for each stored appid
[10:34] <Cimi> ok
[10:34] <mzanetti> Cimi, there is already a branch that adds gsettings to the applicationmanager
[10:34] <mzanetti> Cimi, in case you are going to use gsettings, you might want to build on top of that
[10:35] <Cimi> mzanetti, want to use gsettings?
[10:35] <Cimi> i'm fine with that
[10:35] <mzanetti> my first guess would be yes. I think Saviq said we should talk to cwayne if he's fine with that
[10:35] <mzanetti> in regard to customization
[10:36] <Cimi> launcher uses gsettings, right?
[10:36] <mzanetti> yes
[10:36] <mzanetti> yeah, seems to be our standard mean of storing things... so...
[10:36] <Cimi> mzanetti, I used it with gtk in the past too
[10:37] <Cimi> so is there probably for legacy, not sure the alternative qt has
[10:37] <Cimi> mzanetti, btw, which is that branch? :)
[10:38] <Cimi> mzanetti, https://code.launchpad.net/~mzanetti/qtmir/exception-settings/+merge/252921 ?
[10:38] <mzanetti> Cimi, yep
[10:39] <Saviq> mzanetti, Cimi, I'm only worried gsettings could be too heavy, or that it can't store enough data when someone has 100 apps open
[10:39] <mzanetti> Saviq, are there limits?
[10:39] <Saviq> mzanetti, that's what I don't know :)
[10:39] <mzanetti> right...
[10:39] <Cimi> Saviq, we can limit those 100 anyway
[10:40] <Saviq> Cimi, what if the limit is 10? :P
[10:40] <Cimi> lol
[10:40] <mzanetti> well, it isn't 10
[10:40] <mzanetti> otherwise the launcher wouldn't work
[10:40] <Saviq> I know, shh!
[10:40] <mzanetti> :D
[10:40] <mzanetti> but ok... Cimi I guess you'd need to find out if there are limits, and what they are
[10:41] <Cimi> mzanetti, I was googling already
[10:41] <mzanetti> also some load test with storing/reading some 100 appids or so
[10:42] <Saviq> yeah, that's what I'm most worried
[10:43] <Saviq> having to construct/store a list on every focus change
[10:43] <mzanetti> Cimi, ^
[10:45] <Saviq> Cimi, mzanetti, and then there's looking forward towards desktop, this is basically a "restore session" feature, will we need to store more details, like window state/geometry, or do we rely on the current window geometry restore (or on Mir, for that matter?)
[10:45] <Saviq> greyback_, FYI ↑ (this is about storing spread)
[10:45] <Cimi> "Reads and writes can be considered to be non-blocking. Reading settings with GSettings is typically extremely fast: on approximately the same order of magnitude (but slower than) a GHashTable lookup. Writing settings is also extremely fast in terms of time to return to your application, but can be extremely expensive for other threads and other processes. Many settings backends (including dconf) have lazy initialisation whi
[10:45] <Cimi> ch means in the common case of the user using their computer without modifying any settings a lot of work can be avoided. For dconf, the D-Bus service doesn't even need to be started in this case. For this reason, you should only ever modify GSettings keys in response to explicit user action."
[10:46] <Cimi> https://developer.gnome.org/gio/stable/GSettings.html
[10:46] <mzanetti> Cimi, I don't think the geometry settings should be in this place
[10:46] <Saviq> yeah, so gsettings/dconf is optimized for reading, not writing
[10:46] <Cimi> exactly
[10:47] <Saviq> which is why I'm not totally sure this is the right thing to do
[10:47] <Saviq> we can still read the default set from gsettings, but that's it
[10:47] <greyback_> Saviq: why save for every focus change? Why not just on shutdown?
[10:47] <Cimi> greyback_, if the phone dies/crashes
[10:47] <Saviq> greyback_, yeah, ↑
[10:47] <Cimi> maybe not on focus change, maybe on app load/quit
[10:48] <Cimi> but then we want the ordering...
[10:48] <Saviq> well, if we lose ordering then maybe that's not as bad
[10:48] <Saviq> if we at least have the correct set
[10:49] <Saviq> MacSlow, so... tsdgeos to the rescue... `rm -R ~/.cache/QML` and no crash any more...
[10:49] <Saviq> bug #1444937
[10:49] <MacSlow> Saviq, oh ha...
[10:50] <MacSlow> tsdgeos, how did you figure out that one?
[10:50]  * MacSlow tries right away
[10:50] <tsdgeos> MacSlow: actually i didn't, the Qt guys kind of did
[10:50] <tsdgeos> saying "this is impossible to happen"
[10:51] <tsdgeos> and then i thought, "oh noes, the cache is making the impossible possible"
[10:51] <MacSlow> tsdgeos, haha... nothing is impossible :)
[10:51] <Cimi> Saviq, what else can we use to store? remember we also want to store the application screenshots
[10:52] <Mirv> that's why my script always clears QML cache before starting to test a PPA
[10:52] <MacSlow> Mirv, tsdgeos: I'll put that in my ~/.bashrc or something like that
[10:53] <Saviq> Mirv, please comment on bug above ↑ if you have something to add, I really think we need something that just does it, we'll be forgetting it otherwise
[10:53] <greyback_> Saviq: Cimi: well saving to gsettings for every focus change sounds heavy-handed to me, writing to a file might be just as good
[10:53] <Saviq> MacSlow, so yeah, 8 successful runs of the rotation tests in a row, but I did get http://pastebin.ubuntu.com/10832212/ at some point
[10:54] <Mirv> Saviq: commented
[10:54] <MacSlow> Saviq, ah... that's new
[10:54] <Saviq> greyback_, I'm thinking DB, updating just a focus timestamp
[10:54] <Saviq> greyback_, we already have a DB for the geometry
[10:54] <Mirv> my guess is that app upgrades are being taken care of, but better be sure
[10:55] <Cimi> how will the images be stored? hard drive?
[10:55] <Saviq> Cimi, where else? printouts? :P
[10:55] <Cimi> Saviq, in a db
[10:55] <mzanetti> Saviq, https://code.launchpad.net/~mzanetti/unity8/fix-dnd-cancelling/+merge/256462
[10:55] <Saviq> Cimi, db not on hard drive? ;)
[10:55] <Cimi> Saviq, at that point, we can use a naming conversion to store appId, screenshot, timestamp
[10:55] <Cimi> Saviq, ouch, I meant file :D
[10:56] <Mirv> tsdgeos: FYI I'm doing another qtbase landing with arale workaround for black browser tabs, while waiting for the DBus one. after it has landed, we can start considering whether to land the current pile of patches to vivid-rtm PPA only. but we need the final upstream solution anyway sooner or later to w.
[10:56] <Cimi> if we save the images as files, we can name them in a way that we don't need anything else
[10:57] <Saviq> Cimi, but you'd then have to rename them on focus changes
[10:58] <Saviq> Cimi, and then either finding the file for display or sorting would be weird, because you either have to slap a timestamp at the front or the back
[10:58] <mzanetti> geez. all my launchers in a bad state right now :D
[11:00] <Saviq> mzanetti, let's just hope that's really the only reason this happens
[11:01] <mzanetti> yeah
[11:01] <greyback_> Saviq: sure, that works, but that db lives in unity8 atm, and I don't think it belongs in qtmir
[11:02] <Cimi> Saviq, at the front, they are ordered, no?
[11:02] <Cimi> ah but removing them is complicated, yeah
[11:02] <Cimi> Saviq, but we care less about removing apps, if is slower
[11:03] <Saviq> Cimi, well, unlinking a file isn't complicated
[11:03] <Cimi> Saviq, is good to have fast app loading, less app killin
[11:03] <Saviq> Cimi, the only bit that'd be weird is finding the screenshot file for an app, you'd need to glob it
[11:03] <Cimi> we load an app, we store a screenshot with timestamp-appId.png
[11:04] <tsdgeos> Mirv: yeah, at some point thiago convinced himself to try to install KDE Frameworks 5 on his heavily patched Qt and reproduce the problem directly instead of using me as a proxy
[11:04] <Cimi> when we close the appId, spread will remove *appId.png, no?
[11:04] <tsdgeos> so it may happen sooner than later
[11:04] <Saviq> greyback_, did I say anything about qtmir? :)
[11:05] <greyback_> Saviq: ok so
[11:06] <Saviq> Cimi, yeah, the * part is what worries me
[11:06] <Saviq> Cimi, but more for loading than for removing
[11:08] <Saviq> like I can imagine we'll be destroying the app delegates (if we're not already), would we then not lose the filename when we need to bring it back?
[11:08] <Saviq> mzanetti, greyback_, where are we storing the half-res screenshots now, for apps that got OOM-killed? in mem?
[11:09] <mzanetti> yes
[11:09] <greyback_> Saviq: in memory
[11:09] <Saviq> ok we need to offload those to disk too
[11:09] <mzanetti> and also on top of the surface. imo that should be baked into the mirsurfaceitem and be transparent to the shell
[11:10] <Saviq> Gerry disagrees ↑ ;)
[11:10] <mzanetti> yeah :D
[11:10] <mzanetti> well, don't think so
[11:11] <Saviq> MacSlow, some 20 successful runs now
[11:11] <mzanetti> at least some few weeks back he didn't
[11:11] <greyback_> darn ctrl+d and multimonitor
[11:11] <mzanetti> :)
[11:11] <Saviq> MacSlow, (or my loop isn't doing a good job at detecting failures)
[11:12] <davmor2> Saviq: kgunn: we seem to be getting file:///usr/lib/arm-linux-gnueabihf/unity8/qml/Dash/createCardComponent:132:1: QML Label: Binding loop detected for property "height" on arale is this just because of the drivers or is it something else?
[11:12] <Saviq> davmor2, we're getting this outisde of arale just as well
[11:12] <Saviq> davmor2, has nothing to do with graphics
[11:12] <Saviq> MacSlow, in any case, it's time to give this all up for review
[11:12] <davmor2> Saviq: I've not seen it on krillin for a while
[11:13] <Saviq> davmor2, it's just a warning
[11:13] <Saviq> davmor2, and is timing-related, which might be why you're not seeing it always
[11:13] <Saviq> MacSlow, and you try and see if you can fix http://pastebin.ubuntu.com/10832212/
[11:13] <davmor2> Saviq: fair enough we have a regerssion test for it and it failed on arale is all
[11:14] <Saviq> davmor2, you have a regression test for a warning line? :D
[11:14] <MacSlow> Saviq, +1
[11:14] <Saviq> davmor2, or is there an actual visual artefact of this?
[11:14] <davmor2> Saviq: it's more that it appears when the screen stutters between scopes
[11:14] <Saviq> MacSlow, just to be clear: you don't need silo 004, just demo-stuff
[11:14] <davmor2> swiping between scopes even
[11:14] <MacSlow> Saviq, sure... I'll MP it before lunch
[11:15] <Saviq> davmor2, just to be clear: not a regression :)
[11:15] <Saviq> davmor2, we've never "fixed" all the reasons for the stutter
[11:16] <davmor2> Saviq: that's fine then
[11:20] <MacSlow> Saviq, will the demo-stuff bits also be moved into proper MPs, thus these can be states as prerequisites for the shellRotation MP?
[11:20] <Saviq> MacSlow, everything in there is MP'd afaict
[11:22] <Saviq> https://code.launchpad.net/~dandrader/qtmir/supportedOrientations/+merge/242213
[11:22] <Saviq> MacSlow, see description ↑
[11:24] <MacSlow> Saviq, ok
[11:24] <Saviq> ok not everything is MP'd, will talk to dandrader when he shows up
[11:24] <tsdgeos> :D i did so many "wrong" patches to qt quick text item that the reviewer actually wrote the correct patch himself :D
[11:24] <tsdgeos> guess it's not that bad that my prodding got him to write it
[11:24] <MacSlow> tsdgeos, :)
[11:25] <Saviq> MacSlow, do you know where "unsupported orientation TOP-DOWN. skipped." comes from?
[11:26] <Saviq> we should get rid of that print
[11:26] <Saviq> /food
[11:27] <MacSlow> Saviq, from the test itself... the fake-sensor/device does not allow the "top-down" orientation.
[11:28] <MacSlow> and I wanted that to show... so whoever happens to watch the test and wonders why only 3 of 4 possible cases were exercised sees at least some info
[11:28] <Saviq> MacSlow, interesting, anyway, it should not be a print() or whatever it is, but a log instead (see process_helpers.py for example of how to use the logger)
[11:28] <MacSlow> Saviq, ok... will change that
[12:10] <Saviq> Cimi, mzanetti, so, since the screenshot bit should be disconnected from the spread memory bit, I'd say screenshots should be saved to $cacheDir/app_shots/$app_id.png, with the shell not knowing whether it's showing a harddrive screenshot, an in-memory one, or the app surface
[12:11] <mzanetti> IMO, yes
[12:11] <Saviq> Cimi, mzanetti, spread set we should store in the shell's window geometry Db, as a {focus_timestamp, app_id} tuple
[12:11] <mzanetti> basicall the MirSurfaceItem paints a surface... wherever that comes from, it shouldn't care
[12:12] <Saviq> falling back to a gsetting if Db is empty, for customization purposes
[12:12] <Saviq> mzanetti, will that work fine with splash screens though?
[12:13] <mzanetti> Saviq, doesn't really matter, does it?
[12:13] <mzanetti> hmm...
[12:13] <Saviq> mzanetti, I'm just asking - as long as qtmir handles the screenshots (i.e. deletes them when user closes an app)
[12:14] <mzanetti> Saviq, well, the splash is a bit different anyways
[12:14] <Saviq> then the first app frame might come from either shot or app for real
[12:14] <Saviq> and that will hide splash screen
[12:14] <mzanetti> yep
[12:17] <mzanetti> Saviq, if the phone is rebooted, then you're saying the shell should look up it's settings and call ApplicationManager.startApplicationStopped(appId) for each one?
[12:17] <mzanetti> its, even
[12:18] <Saviq> mzanetti, I think we should add API to tell AppMan all of them at once
[12:18] <mzanetti> why not just keeping this inside the appmanager?
[12:19] <Saviq> mzanetti, I don't think greyback_ wants that in qtmir
[12:19] <mzanetti> but all the rest in this regard is in qtmir too
[12:19] <mzanetti> well, in the applicationmanager model
[12:20] <mzanetti> i.e. the shell says startApplication and qtmir transparently stops it. why should the shell then suddenly care about stopped/vs running?
[12:20] <Saviq> mzanetti, oh no, sure it shouldn't
[12:21] <Saviq> mzanetti, that's why I'm saying AppMan.restoreApps(list_of_apps) or something
[12:21] <Saviq> mzanetti, then appman will *really* only launch the topmost app, or even none, until it's focused
[12:21] <Saviq> but it will populate the app model
[12:22] <mzanetti> mhm... worksforme
[12:23] <Saviq> it's the list_of_apps I don't think greyback_ wants in qtmir, and I'm fine with that
[12:24] <Saviq> and we can relatively easily do AppMan.restoreApps(db.count > 0 ? db.list_of_apps : gsettings.default_list_of_apps)
[12:24] <mzanetti> yeah... fine with that too I guess...
[12:28] <Cimi> ok
[12:29]  * Saviq writes down in description
[12:30] <MacSlow> Saviq, I've changed the shell-rotaion test to use logger instead of print and added description and commit-message. Before flipping the switch to "needs review" I'm now looking into the assertion-mismatch issue.
[12:33] <Saviq> MacSlow|lunch, tx
[12:44] <Saviq> Cimi, mzanetti, so the only remaining question, I think, is first boot screenshots
[13:39] <Saviq> MacSlow, I wonder, could the failure just be a timing thing? you're using assertThat, you don't give any time for things to settle maybe?
[13:40] <Saviq> dandrader, hey, could you please make sure all shellRotation-related branches are MP'd and in Needs Review (and trunks merged for good measure)
[13:50] <dandrader> Saviq, ok. So cleaning the QML cache solves the crashes afterall?
[13:50] <Saviq> dandrader, yeah
[13:50] <dandrader> Saviq, is that ricmm's QML cache thingy?
[13:51] <Saviq> dandrader, yeah, it doesn't know when plugin ABI changes so doesn't invalidate atm
[13:52] <dandrader> hmm
[13:56] <dandrader> Saviq, mzanetti, MacSlow, anything against squashing shellRotation's commit history?
[13:57] <dandrader> MacSlow, can I already merge you AP work into ~unity-team/shellRotation?
[13:57] <Saviq> dandrader, rebasing never a nice thing to do in bzr ;)
[13:57] <mzanetti> I don't see a reason *for* it
[13:57] <Saviq> dandrader, I just added it as a separate MP o top of yours
[13:57] <Saviq> https://code.launchpad.net/~macslow/unity8/shellRotation/+merge/256493
[13:58] <Saviq> dandrader, and thought it could remain like that
[13:59] <dandrader> mzanetti, Saviq, ok, I will keep the history then.... For the record: I squashed shellRotation's history many times already. Otherwise it would be loooong and confusing list of commits and merges
[14:00] <mzanetti> I know you did that
[14:00] <dandrader> mzanetti, :)
[14:00] <mzanetti> I was spending half an hour merging each time
[14:02] <dandrader> mzanetti, it's fun, right? :)
[14:02] <mzanetti> totally :)
[14:03] <dandrader> history gets particularly messy every time a split part of shellRotation's diff onto a separate MP that gets merged to trunk
[14:07] <MacSlow> dandrader, basically yes...
[14:07] <MacSlow> dandrader, there's assert-mismatch failure still (happening ~ 1/15 times)
[14:08] <MacSlow> dandrader, which I'm currently looking into
[14:08] <MacSlow> dandrader, but I can do that against ~unity-team/shellRotation too
[14:08] <MacSlow> dandrader, cleaning up branches is always a good idea
[14:11] <Saviq> MacSlow, any reason why http://paste.ubuntu.com/10833276/ would be wrong?
[14:12] <Saviq> I'm up to 24 successful runs in a row of those two tests now
[14:13] <MacSlow> Saviq, nope... looks acceptable to me
[14:13] <MacSlow> Saviq, I'll add that to my branch for both tests...
[14:14] <MacSlow> Saviq, I got the mismatch for test_fake_sensor too
[14:14] <dandrader> this patch improves readability that's for sure
[14:14] <Saviq> yeah not sure why the tmp_a, tmp_o...
[14:14] <mzanetti> dandrader, btw. I was reading through the shellrotation branch today
[14:14] <mzanetti> dandrader, only question I had was: is the Commandlineparser changes supposed to show up in there?
[14:14] <mzanetti> or is that just a prereq missing to the other commandlineparser branch?
[14:15] <dandrader> mzanetti, yes, working on it at this very moment
[14:15] <MacSlow> Saviq, dandrader: missing code-clean up
[14:16] <mzanetti> dandrader, perfect. I think I'm good with the code then
[14:17] <dandrader> mzanetti, just resubmitted. it now has lp:~dandrader/unity8/unityCommandLineParser as a prereq
[14:18] <mzanetti> cool
[14:26] <dandrader> mzanetti, tsdgeos, https://code.launchpad.net/~dandrader/unity8/ddaImprovements/+merge/255896 has been upated as well. The remaining Launcher jumpiness and the failing qmltests have been fixed
[14:26] <MacSlow> Saviq, current issue... http://pastebin.ubuntu.com/10833349
[14:26] <mzanetti> dandrader, awesomes
[14:27] <tsdgeos> dandrader: k, i think i'll get to it later today
[14:28] <Saviq> MacSlow, not a problem in your branch, this happens from time to time still
[14:28] <MacSlow> Saviq, it's not a direct issue of the shell-rotation test itself, but...
[14:28] <MacSlow> ah ok
[14:29] <Saviq> MacSlow, after 38 runs I got http://pastebin.ubuntu.com/10833372/ here, but wouldn't exclude some PEBKAC error like I touched the phone or something
[14:38] <MacSlow> Saviq, I've seen that once too today
[14:49] <Saviq> MacSlow, so basically IIUC that means the fake sensor data didn't cause it to switch orientations?
[14:50] <MacSlow> Saviq, I can take some time... sometimes...
[14:50] <MacSlow> but the 15 sec timeout is already nasty
[14:51] <MacSlow> I don't think we should up that even more.
[14:53] <MacSlow> Saviq, at some point I wondered if we should even keep the isolated fake_sensor_test... it is used/exercised in the app-rotation test anyway
[14:53] <MacSlow> Saviq, and never seen it (fake-sensor) fail there yet
[15:04] <dandrader> greyback_, can you top-approve https://code.launchpad.net/~dandrader/qtmir/supportedOrientations/+merge/242213 ?
[15:06] <greyback_> dandrader:  - g++-4.9:native,    + g++-4.9,   <- why that change?
[15:06] <Saviq> because recipes hate it ;)
[15:11] <tsdgeos> dednick: there's a very weeeeeeeeeeeird thing
[15:11] <tsdgeos> the first QDBusPendingCallWatcher of your branch seem to never be deleted
[15:11] <tsdgeos> even if the subsequent ones are
[15:11] <tsdgeos> and deleteLater is just called fine on them
[15:12] <tsdgeos> dednick: is it possible that those are run before we have a qapplication ?
[15:12] <tsdgeos> or a loop running
[15:12] <tsdgeos> ?
[15:12] <tsdgeos> probably
[15:13]  * tsdgeos checks
[15:14] <tsdgeos> yeah
[15:16] <dandrader> greyback_, where?
[15:16] <dandrader> greyback_, it's a debug leftover
[15:17] <dandrader> greyback_, so I could build it in a PPA
[15:17] <dandrader> greyback_, but nowadays in the PPA recipe I merge a separate branch that does just that. So I don't have to pollute the main branch with this
[15:28] <greyback_> dandrader: I see it in the LP diff in https://code.launchpad.net/~dandrader/qtmir/supportedOrientations/+merge/242213
[15:28] <greyback_> it'll break my schroot builds
[15:30] <Saviq> dandrader|afk, you don't have a separate qtmir branch for that, just a unity8 one
[15:31] <dednick> tsdgeos: hm
[15:33] <dednick> tsdgeos: delete watcher?
[15:33] <tsdgeos> yeah
[15:38] <dednick> tsdgeos: actually, can just call delete at that point i guess. If it's finished we won't be needing it anymore.
[15:38] <tsdgeos> dednick: sure
[15:38] <tsdgeos> dednick: isn't that what youwere saying?
[15:38] <tsdgeos> it's what i suggested in the MR
[15:39] <dednick> tsdgeos: you said add a "delete watcher" inside...
[15:39] <dednick> not sure what that meant :)
[15:40] <tsdgeos>     if (!async) {
[15:40] <tsdgeos>         watcher->waitForFinished();
[15:40] <tsdgeos>         delete watcher;
[15:40] <tsdgeos>     }
[15:40] <tsdgeos> dednick: ↑
[15:41] <dednick> tsdgeos: yup. that's what i just added :)
[15:41] <tsdgeos> k
[16:06] <dandrader> greyback_, fixed
[16:06] <greyback_> dandrader: ta
[16:19] <dandrader> greyback_, https://code.launchpad.net/~dandrader/unity-api/shellRotation/+merge/242212 should be ok now as well
[16:20] <greyback_> dandrader: another thought on https://code.launchpad.net/~dandrader/qtmir/supportedOrientations/+merge/242213 - the date in the debian/changelog is 2014
[16:21] <greyback_> can you update that please
[16:22] <dandrader> heh, it's showing its age
[16:25] <greyback_> yep
[16:26] <dandrader> greyback_, done
[16:26] <greyback_> ta
[16:43] <greyback_> dandrader: same issue with unity-api branch, the datetime in debian/changelog needs bumping
[16:44] <greyback_> dandrader: any reason you don't declare copyright for 2014? :)
[16:45] <dandrader> greyback_, it wasn't changed in that year, I guess
[16:45] <greyback_> dandrader: only kidding, it's no big deal
[16:47] <dandrader> greyback_, update the changelog date&time
[16:47] <dandrader> *updated
[16:47] <greyback_> TAed
[16:52] <dandrader> Saviq, https://code.launchpad.net/~dandrader/qtmir/supportedOrientations/+merge/242213/comments/638911
[16:55] <dandrader> inline comments are terrible when you have a big diff
[16:56] <dandrader> Saviq, so you want to have lp:~saviq/qtmir/fix-application-api-deps as a prereq of lp:~dandrader/qtmir/supportedOrientations
[16:56] <dandrader> ?
[17:21] <Saviq> dandrader, Ctrl+F, Saviq ;)
[17:22] <Saviq> dandrader, I'll tweak my branch then
[17:23] <Saviq> dandrader, and yeah, please resubmit based on mine
[17:39] <dandrader> Saviq, don't need to merge lp:~saviq/qtmir/fix-application-api-deps again into lp:~dandrader/qtmir/supportedOrientations. It applies cleanly now (no diff at all even)
[17:39] <dandrader> Saviq, can remove the "Needs Fixing"
[17:39] <Saviq> dandrader, right, prolly because it's the same ;)
[17:39] <dandrader> Saviq, yes