[00:06] <mterry> mzanetti: for tomorrow, with cjwatson's help, I fixed the ppa issue
[05:32] <Mirv> mterry: they seemingly weren't there anymore, the 8.13 packages. so I deleted the published and superseded packages, plus removed unity8 from train data too temporarily
[08:34] <pstolowski> mzanetti, hey, i missed your message yesterday evening
[08:35] <pstolowski> mzanetti, the fix for filters i talked about is not critical and it's for Music scope. i'm working on it in my other silo, when ready and it's not too late i'll add it to silo 41; if not, i'll land a bugfix asap separately
[09:27] <mzanetti> tsdgeos, hey, not gonna block on this, but I guess this needs addressing in upcoming branches:
[09:27] <mzanetti> tsdgeos, set your phone to german language:
[09:27] <mzanetti> then go to the dash, enter search and select "Entwicklungswerkzeuge" (developer tools that is)
[09:27] <mzanetti> now type something
[09:28] <mzanetti> the deparment thing in the textfield takes all the space, it is not possible to see what you type, nor a way to scroll
[09:32] <tsdgeos> mzanetti: right, that's going to need input from UX on how they want that fixed
[09:32] <tsdgeos> mzanetti:  could you send paty_ a screenshot? want me to?
[09:32] <mzanetti> ack
[11:58] <pstolowski> mzanetti, hey, i'm going to add fix for music scope to silo 41
[11:59] <mzanetti> ok then...
[11:59] <pstolowski> mzanetti, what about the OSK issue
[11:59] <pstolowski> ?
[11:59] <mzanetti> currently I'm doing a unity8 rebuild... but I plan to close the door after that rebuild if it turns out to be good
[11:59] <mzanetti> OSK issue fixed
[11:59] <mzanetti> found another one by now, fix in the build queue tho
[12:00] <mzanetti> pstolowski, ^
[12:02] <pstolowski> mzanetti, ack. if I start build of just music scope in the silo, will it interrupt your build or something?
[12:41] <mterry> tsdgeos: re: listitemworkaround...  I did follow the instructions (press and hold an item, then drag) in the bug.  But maybe I was doing them in the wrong place?  I started a search in the dash, then did it on the category items.  Is there somewhere else that's affected?
[12:41] <tsdgeos> what are "category items" for you?
[12:42] <tsdgeos> mterry: this is what we're talking about
[12:42] <tsdgeos> http://imgur.com/BOGFJ2G
[12:43] <tsdgeos> app scope or store scope for example
[12:43] <tsdgeos> food!
[12:44] <mterry> tsdgeos: yeah exactly.  The "departments" is what I meant
[12:45] <mterry> tsdgeos: those didn't exhibit the bug when I commented out your patch from silo 41.  I'll reflash and try again now that the silo is presumably sane.  Maybe I built something wrong
[12:45] <mterry> tsdgeos: (you wouldn't call those categories?)
[13:16] <mterry> mzanetti: the silo still doesn't install well from citrain I notice (tries to uninstall parts of unity8).  Is that a known issue?
[13:18] <mzanetti> mterry no
[13:18] <mzanetti> was working for me
[13:19] <tsdgeos> mterry: the problem is that categories in scopes are each of the blocks of a scope
[13:26] <mterry> mzanetti: regarding xenial FF and silo 41.  The geonames expose-more branch adds API.  So would break FF.  And it's in main.  So it's not covered by the blanket xenial FFe for touch, right?  (that's for universe?)  Maaaaybe it's covered by silo 41's FFe, but that was for OTA 10, not xenial, right?
[13:27] <mzanetti> I've no clue
[13:27] <seb128> mterry, you should probably ask for the FFe, I'm sure it's an easy one to get
[13:27] <mzanetti> ltinkl, can we change the string "about this device" only for Mir based environments?
[13:28] <mzanetti> seb128, we have a FFE, saviq asked for it
[13:28] <mzanetti> however he is out this week and I don't have details
[13:28] <mterry> mzanetti: but thats' for OTA 10, right?
[13:28] <mzanetti> dunno
[13:28] <seb128> mterry, well ffe are ubuntu process no? if you got one you can land to xenial...
[13:30] <mterry> seb128: yeah I'll look at it
[13:30] <ltinkl> mzanetti, why you want to change the string only for u8?
[13:30] <seb128> mterry, you can probably nag Laney to get it review/approved if you need to
[13:31] <mzanetti> ltinkl, I don't but seb wants to *not* change it for unity7
[13:31] <seb128> ltinkl, I think it's going to confuse desktop users on the traditional unity7
[13:31] <mzanetti> various reasons... one is a string freeze, the other is he doesn't like it
[13:31] <ltinkl> mzanetti, seb128: sure I can but that's not what the design wanted
[13:31] <mzanetti> seb128, you gotta think more convergence :)
[13:31] <seb128> ltinkl, well, then you need a UIFe bug with a design comment saying it's right for unity7/Xenial
[13:32] <mzanetti> but yeah, the string freeze thing is a good reason
[13:32] <ltinkl> agreed
[13:32] <seb128> I also think we are going get to traditional users comment on "wth, now my desktop tower is a device"
[13:33] <seb128> I don't see much point going through those arguments for unity7
[13:33] <seb128> it's fine to do for unity8 though
[13:33] <seb128> well, just my opinion
[13:33] <mzanetti> seb128, thing is, we have 1 code base
[13:33] <ltinkl> seb128, not that I disagree...
[13:33] <seb128> as said if you have a UIFe with a comment from design it's fine to change
[13:33] <mzanetti> and well... everything is a "device"
[13:33] <seb128> mzanetti, right, but the same diff has
[13:33] <seb128> +
[13:33] <seb128> +  if (g_getenv ("MIR_SOCKET") != NULL) // only under unity8
[13:33] <seb128> +  {
[13:34] <ltinkl> seb128, mzanetti: I'll revert the "about" string change and we can adjust it later, agree?
[13:34] <seb128> ltinkl, or put it under ^
[13:34] <ltinkl> seb128, yeah, I'll do it only for u8
[13:35] <mzanetti> ltinkl, no... having "about this computer" on a phone is definitely even more wrong
[13:35] <mzanetti> but yeah... if/else for unity8/unity7 works for me
[13:35] <ltinkl> mzanetti, yup, I said for u8
[13:35] <mzanetti> kk
[13:37] <seb128> thanks
[13:39] <ltinkl> seb128, mzanetti: quick "review": https://pastebin.kde.org/pm7rviobx
[13:39] <seb128> +1
[13:41] <tsdgeos> mterry: still no able to reproduce?
[13:46] <mzanetti> dednick, how's it going with the side stage stuff?
[13:46] <dednick> mzanetti: working on it. just managed to get u8 built.
[13:46] <dednick> from silo
[13:47] <dednick> can confirm it's not working in tryTabletStage
[13:59] <mterry> tsdgeos: sorry, ran into another issue elsewhere, haven't tested
[14:16] <dednick> mzanetti: think i've found it. spreadView
[14:16] <dednick> spreadView.sideStageWidth was moved to the stage root.
[14:16] <dednick> but it's used out of context in the transformed delegate.
[14:17] <mzanetti> dednick, nice. let me know when you pushed it so I can rebuild
[14:32] <mterry> mzanetti: do you know when we start forking xenial for landings?  we did that for wily, right?
[14:33] <mzanetti> mterry, I think we will, yes
[14:33] <mzanetti> I just talked to Saviq, he didn't know we're in xenial FF (I didn't either)
[14:33] <mzanetti> but yeah, this will become an issue soon, at lastest when we open the phone-overlay for OTA-11 features again
[14:34] <mzanetti> so I expect after OTA-10 we'll get a stable-phone-overlay ppa for xenial too
[14:47] <tsdgeos> or ignore and carry on ! :D
[14:48] <tsdgeos> if we're not going to have a phone based on xenail (big if) what's the point of having a stable-phone-overlay for it
[14:49] <mzanetti> tsdgeos, to be able to continue landings without being affected by teh xenial feature freeze
[14:49] <tsdgeos> ah
[14:49] <tsdgeos> you mean why there's no yo yoyo
[14:50] <tsdgeos> s/why/while
[14:50] <mzanetti> yep
[14:50] <mzanetti> yo yoyo is not the final name, is it?
[14:50] <mzanetti> (one never knows)
[14:51] <sil2100> Well, we already have xenial overlay-ppa support
[14:52] <sil2100> Our devel-proposed images build with stable-phone-overlay enabled, the same as for vivid
[14:52] <sil2100> We had some packages that we needed 'locking down' and not pulling in from the xenial archives
[14:52] <sil2100> pkcon and click IIRC
[14:56] <mterry> sil2100: but it's not turned on by default for xenial landings, right?
[14:56] <sil2100> mterry: no, not yet
[14:57] <ltinkl> mterry, sil2100: while I have you here, can we change the seed to install "indicator-session" on $devices with OTA 10?
[14:57] <mzanetti> ltinkl, we need ot land silo 41 first
[14:57] <mzanetti> sil2100, ^
[14:57] <sil2100> ltinkl: hm, sure
[14:58] <ltinkl> sil2100, yeah, ideally with silo 41
[14:58] <sil2100> Ok, I'll add it to the seed once that happens
[14:58] <mterry> ltinkl: I thought we fixed that by the recommends?
[14:58] <sil2100> I'll have to confirm with Pat as always :)
[14:58] <mterry> sil2100: hold up, we added a recommends for it
[14:58] <ltinkl> mterry, oh right... does it install the recommends automatically?
[14:58] <mterry> ltinkl: yes
[14:58] <mzanetti> it doesn't with the citrain tool at least
[14:58] <ltinkl> ok then, sorry for the noise
[14:58] <mzanetti> not sure if the image bootstrap thing would do
[14:58]  * ltinkl still a newb wrt debian stuff
[14:59] <mzanetti> ltinkl, well, fwiw, debian does not auto-install recommends, ubuntu does
[14:59] <mterry> mzanetti: it should, that's how we always make ubuntu images...
[14:59] <mterry> we have other recommends that get installed, like the scope stuff
[14:59] <sil2100> I think it should pull it in
[14:59] <ltinkl> I see
[14:59] <mzanetti> kk then, all good I think
[14:59] <sil2100> Let's see once it lands and we can react accordingly
[14:59] <mterry> mzanetti: interesting that citrain doesn't
[15:00] <mzanetti> yeah
[15:00] <mzanetti> it probably should in that case
[15:00] <sil2100> btw. FF is this Friday, right?
[15:00] <ltinkl> bug bug bug, it should behave the same right?
[15:00] <mzanetti> sil2100, last friday, but silo 41 has an exception
[15:00] <sil2100> I mean, xenial FF ;)
[15:00] <mzanetti> ah ok
[15:00] <mzanetti> dunno
[15:01] <sil2100> Ah, yeah, we're in FF already
[15:01] <sil2100> nvm me
[15:02] <ltinkl> mzanetti, pushed an update to indicator-session
[15:02] <mzanetti> again? :D
[15:02] <ltinkl> mzanetti, mterry wanted me to :) http://bazaar.launchpad.net/~lukas-kde/indicator-session/desktopModeSwitch/revision/477
[15:02]  * ltinkl looks innocent
[15:02] <mterry> mzanetti: this is a good one!  prevents us from having to MIR unity8
[15:04] <mzanetti> mterry, can you review the diff please
[15:04] <mzanetti> looks ok to me, but then all the g_stuff
[15:04] <mterry> mzanetti: ?  that's my diff
[15:04] <mzanetti> oh is it
[15:05] <mterry> mzanetti: I can review it too...  :)
[15:06] <mzanetti> yeah man. also please release it, I'm going for a break :D
[15:06] <mzanetti> j/k, checking it out atm
[15:07] <mzanetti> can't build the silo atm
[15:07] <ltinkl> mzanetti, lp down for me
[15:11] <mterry> mzanetti: btw, I filed bug 1557557 as an FFe
[15:17] <mzanetti> mterry, what's happening with this now?
[15:18] <mterry> mzanetti: with the FFe?  I poked Laney.  We wait for someone in ~ubuntu-release to approve
[15:18] <mzanetti> ah ok
[15:19] <mterry> mzanetti: in better-windowed-logic, when we reboot, I assume the state gets reset by onPointerInputDevicesChanged on startup?
[15:19] <mterry> mzanetti: in which case, we don't really need gsettings at all?  Except as a way to communicate with the indicator
[15:19] <mterry> mzanetti: which we usually use dbus for
[15:20] <mzanetti> mterry, yeah... atm it's mostly just for communication
[15:21] <mzanetti> mterry, I figure we might come up with something more minimalistic
[15:21] <greyback> mzanetti: hey, I need to run, will miss the standup
[15:21] <mzanetti> mterry, but then I'm really not sure if design doesn't chagne their mind again and wants it to persist eventually
[15:21] <mterry> mzanetti: fair...
[15:21] <mzanetti> mterry, all those decisions seemed very ad-hoc to me and not properly thought through if you ask me
[15:22] <mzanetti> mainly they came up with something that works for the M10 for MWC and then told me to land it as is
[15:22] <mterry> mzanetti: we'll land it and they'll revise
[15:24] <mzanetti> mterry, that was my thought...
[15:24] <mzanetti> mterry, same for the 50gu limit etc
[15:24] <mterry> mzanetti: I don't like silo 41 squeezing into ota10
[15:24] <mzanetti> mterry, we have to
[15:25] <mterry> mzanetti: I understand that.  I just think it's ill advised
[15:25] <mzanetti> mterry, we *really* need the new side stage for the M10
[15:25] <mzanetti> mterry, also the new OOBE for turbo (I'm still very sad we missed the frieza factory image for that)
[15:48] <mterry> mzanetti: pushed dednick's patch to tutorial-redesign
[15:52] <mzanetti> kk
[15:52]  * mzanetti rebuilds
[15:53] <mterry> mzanetti: another thing with better-windowed-logic.  It doesn't seem to factor in changes in screen size.  That is, let's say I have one mouse attached to my phone.  Then dock my phone.  I don't think this code would pick it up
[15:53] <mzanetti> why not?
[15:53] <mterry> It wouldn't trigger on root.width changing (that I can see), and it doesn't save oldScreenSize like it saves oldPointerCount
[15:53] <mterry> mzanetti: ^
[15:54] <mzanetti> mterry, well, so far, pluggin an external screen equals plugging a mouse (virtualtouchpad)
[15:54] <mterry> mzanetti: an external touch screen, maybe
[15:55] <mzanetti> mterry, no
[15:55] <mterry> mzanetti: really, any?
[15:55] <mzanetti> you plug an external screen, the internal morphes to a touchpad
[15:55] <mzanetti> => that adds a mouse on kernel level
[15:55] <mterry> mzanetti: what the heck.  So touchPadModel.count would get updated?  (or miceModel?)
[15:55] <mzanetti> yes
[15:55] <mzanetti> mterry, that's what it has been so far all along
[15:55] <mterry> mzanetti: is that behavior we can rely on going forward, or is that just some mwc hack?
[15:56] <mzanetti> well, it's like this already since earlier
[15:56] <mzanetti> mterry, I agree we need to change that eventually, at lastest when the virtualkeybarod is not always on any more
[15:56] <mzanetti> but again, I'd like to have design properly think it through before coming up with more new stuff
[15:56] <mterry> mzanetti: oh....  you mean not that we treat the new screen as a touchpad, but that the phone morphs into a touchpad
[15:58] <mzanetti> yes
[15:58] <mterry> mzanetti: ok...  so fine.  I plug my phone into a tiny (<90gu) screen.  Then add a second monitor that's bigger.  In that case, we wouldn't re-evalutate.  I know that can't happen now, I'm just saying.  This code doesn't re-evaluate at the right times, afaict
[15:58] <mterry> mzanetti: but maybe that's fine for ota10
[15:58] <mzanetti> yes you're right
[15:58] <mterry> mzanetti: maybe just add a FIXME?
[15:59] <mterry> mzanetti: but the MP seems fine besides.  I don't have a tablet to test on, but this branch appears to be well-tested
[15:59] <mzanetti> mterry, yes, this has been tested on MWC devices
[16:03] <mzanetti> mterry, I just kicked a rebuild before this conversation... do you really want me to add the FIXME comment? to me it's quite obvious that this needs to evolve into *much* more than what it curretnly is
[16:03] <mterry> mzanetti: fine
[16:04] <mterry> mzanetti: you really think that'll be the last rebuild?  :)
[16:04] <mterry> mzanetti: tutorial-redesign has never yet had a proper review, I don't think
[16:05] <mterry> dednick: were you reviewing tutorial-redesign, is that why you had the patch for me?
[16:18] <mterry> ltinkl, mzanetti: now that indicator-session doesn't depend on unity8-schemas anymore...  we could probably drop the unity8-schemas package again.  But maybe it will be useful in future, so it doesn't hurt.  Just a little annoying for installing on command line
[16:19] <ltinkl> mterry, why annoying on cmd line?
[16:19] <mterry> ltinkl: one more package to "dpkg -i" (along with the standard 3 of unity8, unity8-common, and unity8-private)
[16:20] <ltinkl> mterry, yeah but how many times you do that? or users
[16:20] <mterry> ltinkl: *I* do it a lot, when building locally
[16:21] <mterry> ltinkl: what's with the autopilot and qmltest failure in sessionIndicatorForDevices?
[16:22] <mterry> autopilot one was indicator-related, so it might be due to your MP
[16:22] <mterry> I didn't know why the qmltest failure would happen though
[16:22]  * ltinkl looks
[16:24] <ltinkl> mterry, the qmltest failure seems Dash related?
[16:25] <ltinkl> mterry, as for the AP failure, I see this error there: 13:32:28.623 ERROR content:48 - Could not add content object 'None' due to IO Error: [Errno 2] No such file or directory: '/var/log/syslog'
[16:26] <mterry> ltinkl: sure, but I'm not sure that's related to the test failure...
[16:29] <mzanetti> dednick, mterry: https://ci-train.ubuntu.com/job/ubuntu-landing-041-1-build/71/console
[16:29] <mzanetti> there's a conflict
[16:30] <mterry> for the love of...
[16:30] <dednick> :)
[16:31] <mterry> dednick: looks like you added appId and isDash?
[16:32] <dednick> mterry: um, maybe. but i think they already exist.
[16:32] <dednick> i might have moved them
[16:32] <dednick> or someone did
[16:32] <mterry> dednick: your patch you gave me dropped isDash
[16:33] <mzanetti> not the isDash. that has been there
[16:33] <dednick> mterry: it was a duplicate.
[16:33] <mzanetti> in dednicks branch it was there twice
[16:33] <mterry> ...  not that I can see
[16:33] <mzanetti> I dropped one occurance
[16:33] <mterry> ah hm
[16:33] <mterry> i hadn't merged when I applied, that's probably the issue.  OK
[16:34] <mterry> mzanetti, dednick: pushed
[16:37] <mzanetti> tsdgeos, hey, I seem to be getting test failures on the silo
[16:37] <mzanetti> https://unity8-jenkins.ubuntu.com/job/test-ppa-autopkgtest/label=amd64,release=vivid+overlay,testname=qmluitests.sh/lastBuild/
[16:39] <tsdgeos> mzanetti: something is very wrong
[16:39] <tsdgeos> https://unity8-jenkins.ubuntu.com/job/test-ppa-autopkgtest/label=amd64,release=vivid+overlay,testname=qmluitests.sh/lastBuild/testReport/junit/%28root%29/qmltestrunner/tst_TabletStage__compile/
[16:39] <mzanetti> tsdgeos, yes, that's known, we're fixing
[16:40] <mzanetti> tsdgeos, but think that should affect the DashContent ones?
[16:41] <tsdgeos> mzanetti: seems unlikely, let me see
[16:42] <mterry> ltinkl: is "zh" a valid keyboard layout?  I think I got a crash when setting that  manually on command line (see my latest comment in MP)
[16:42] <mterry> ltinkl: (crashed when I tried to switch to it, not when setting via gdbus)
[16:43] <ltinkl> mterry, crash in mir?
[16:43] <ltinkl> mterry, can you get a BT?
[16:43] <mterry> ltinkl: I can work on that, but can you confirm?
[16:43] <ltinkl> mterry, looking up
[16:43] <ltinkl> a sec
[16:43] <mterry> ltinkl: I don't know what crashed, u8 just stopped responding, I assumed it was apport work
[16:44] <ltinkl> mterry, "zh" isn't valid
[16:44] <ltinkl> mterry, see /usr/share/X11/xkb/symbols
[16:45] <mterry> ltinkl: ah, should have used 'cn'
[16:45] <ltinkl> mterry, but setting the keymaps to arbitrary values isn't really a valid usecase either
[16:45] <mterry> ltinkl: ok, so crash isn't blocker, but we probably shouldn't be so brittle
[16:45] <ltinkl> mterry, yea, it shouldn't crash (and I bet it does in Mir)
[16:45] <mterry> ltinkl: yeah, but we shouldn't crash either  :)   not blocker for now though
[16:47] <ltinkl> mterry, you can try testing with "jp+dvorak" ;) good luck getting your keyboard back
[16:47] <mterry> ltinkl: yes, crash in libmirclient
[16:49] <ltinkl> mterry, I remember anpok adding a crash guard exactly for this case (of invalid layouts)
[16:49] <mterry> ltinkl: bug 1557634
[16:50] <mterry> ltinkl: my usual is "fr" and I see what the 4 button does  :)
[16:51] <ltinkl> mterry, yeah, that's a safe testcase (azerty vs qwerty)
[16:52] <mterry> ltinkl: keymapSwitching was infected with tags!  I cleaned them, but be careful if you push to it again
[16:53] <ltinkl> mterry, uh thx, pretty sure I cleaned them up but I noticed trunk had them too
[16:54] <ltinkl> mterry, wonder if we could remedy that by having some sort of "pre push hooks"
[16:54] <ltinkl> mterry, that would strip them
[16:55] <mterry> ltinkl: oh, did you ever get a chance to look at https://code.launchpad.net/~mterry/phablet-tools/tutorial-redesign/+merge/277764 ?
[16:55]  * mterry is about to go to lunch
[16:56] <ltinkl> mterry, nope, not yet but I can do now
[16:56] <mterry> ltinkl: cool.  We're down to just 8 unapproved branches in silo 41 now  :)
[16:57] <ltinkl> mterry, how to invoke/test it manually?
[16:58] <mterry> ltinkl: it's "phablet-config edges-intro --enable" and --disable on your laptop
[16:58] <mterry> ltinkl: this is a package not for your phone, but your dev machine
[16:59] <ltinkl> mterry, kk thx
[16:59] <mzanetti> uh... the new flashing animation landed apparently
[17:00] <mzanetti> "animation" is not the word tho :D
[17:00] <ltinkl> mzanetti, yeah, I just had it on N4 now
[17:00] <mterry> mzanetti: you don't like it?
[17:00] <mzanetti> I do
[17:00] <ltinkl> mzanetti, I like the progress bar
[17:00] <mterry> mzanetti: it animates!
[17:01] <mzanetti> the progress bar, it moves a bit yeah, it jumped from 0 to 50% in one jump tho
[17:01] <mterry> mzanetti: that is by design!
[17:01] <mterry> mzanetti: and it also doesn't do the last 5%
[17:01] <mterry> mzanetti: the first 50% are supposed to be filled out by the system settings upgrade side before the reboot
[17:01] <ltinkl> mterry, that is by design? O_o
[17:01] <mterry> mzanetti: and the last 5% are after boot
[17:02] <mzanetti> hah. fancy
[17:02] <mterry> mzanetti: but those aren't done yet, and design figured we might as well start somewhere
[17:02] <ltinkl> yeah, I just saw the Google logo after reboot, no further progress bar
[17:03] <tsdgeos> mzanetti: yeah the dashcontent tests are a bit borked because the sdk changed the nameing from X_action_button to X_button so my findChild fail
[17:03] <tsdgeos> mzanetti: is this somtehing i can fix tomorrow morning or we need it *now* ?
[17:04] <mzanetti> tsdgeos, ok... tomorrow, but please first thing
[17:04] <tsdgeos> mzanetti: i can do it now if everything else is going to be fixed today
[17:04] <mzanetti> I can't promise everything will, I certainly still hope so
[17:04] <tsdgeos> ok, will do now then
[17:27] <mzanetti> mterry, how's the conflict going?
[17:29] <tsdgeos> mzanetti: there's a test failure it's actually taking a bit more than expected :/
[17:30] <tsdgeos> mzanetti: anybody fixing qmltestrunner.ScopeStyle::test_headerBackground ?
[17:37] <mzanetti> tsdgeos, I'm not aware of someone doing so no...
[17:37] <mzanetti> tsdgeos, but if it's more, feel free to move it to tomorrow morning
[17:37] <tsdgeos> mzanetti: that has nothing to do with me, it's color related
[17:38] <mzanetti> color related
[17:38] <mzanetti> cimi perhaps can look into it?
[17:38] <tsdgeos> whoever changed that color should fix it :D
[17:39] <tsdgeos> who changed colors?
[17:39] <tsdgeos> you! :D
[17:39] <mzanetti> haha
[17:39] <mzanetti> I changed a color in the dash?
[17:39] <tsdgeos> i don't know
[17:39] <tsdgeos> :D
[17:40] <mzanetti> didn't you just say it was me? :D
[17:40] <tsdgeos> yeah but i realized those changes already landed
[17:41] <tsdgeos> the changes i was thinking about i mean
[17:43] <ltinkl> mterry, tested the "phablet-config edges-intro" change but the tutorial isn't complete... I just get the left edge part and after opening the launcher, nothing else
[17:44] <mzanetti> ltinkl, if you discover the right edge yourself before the tutorial starts, it won't ever happen
[17:44] <mzanetti> ltinkl, same for the others basically
[17:44] <ltinkl> mzanetti, aha
[17:44] <mzanetti> ltinkl, open the dialoer-app etc for the bottom edge
[17:44] <mzanetti> it was working fine when I tested the silo today
[17:44] <ltinkl> mzanetti, I'm sure I discovered the left one too before :)
[17:45] <mzanetti> ltinkl, unlikely... doesn't it appear first thing after the wizard has ended?
[17:45] <ltinkl> mzanetti, not sure, haven't run the wizard (yet), just enabled it using the phablet-config tool
[17:46] <tsdgeos> oh no! it was me!
[17:46]  * tsdgeos hides from mzanetti
[17:46] <ltinkl> mzanetti, but it seems to work fine, I got the bottom edge part now when opening dialer
[17:46]  * mzanetti hunts down tsdgeos
[17:46] <mzanetti> :D
[17:46] <mzanetti> what up?
[17:47] <tsdgeos> mzanetti: i did the color changes
[17:47] <mzanetti> :)
[17:50] <ltinkl> mterry, edges-intro approved; anything else to do on https://code.launchpad.net/~unity-team/unity8/sessionIndicatorForDevices/+merge/288940?
[17:52] <tsdgeos> mzanetti: ok, so i fixed http://paste.ubuntu.com/15393725/
[17:53] <mzanetti> tsdgeos, awesome. I hope the otehrs are because of the tablet stage being broken
[17:53] <tsdgeos> qmltestrunner.PreviewRatingDisplayTest::test_creation_speed
[17:53] <tsdgeos> qmltestrunner.PreviewView::test_title
[17:54] <tsdgeos> looks fishy
[17:55] <mzanetti> right
[17:55] <tsdgeos> are we including cimi's rework of the rating stuff?
[17:55] <tsdgeos> seems not
[17:55] <dandrader> I hate the world. Spent 1.5 days making stages mockable for the tutorial only to find out that tutorial-redesign no longer feeds a fake ApplicationManager into a PhoneStage
[17:56] <dandrader> at least the code is better now
[18:02] <tsdgeos> mzanetti: https://code.launchpad.net/~unity-team/unity8/fix_ticket_1105_tests/+merge/289080
[18:02] <mzanetti> thanks a lot tsdgeos!
[18:02] <tsdgeos> mzanetti: going to go now, need to do some shopping, ping me on telegram if you need me for something
[18:02] <mzanetti> ok, cool
[18:02] <mzanetti> o/
[19:05] <mterry> mzanetti: heyo, sorry was lunch + gym.  You asked how the conflict was going, I thought I said I pushed the fix, should be fine
[19:06] <mzanetti> mterry, yes, builds fine now
[19:06] <mzanetti> actually, it just finished building in the silo
[19:06] <mzanetti> mterry, mind giving the silo a test? I'm at dinner atm
[19:07] <mzanetti> mterry, or actually, I think you've been getting down the unapproved-count. keep on doing that
[19:07] <mzanetti> I'll do the testing in a bit
[19:10] <mterry> sure
[19:25] <dednick> mzanetti: "Read inputMethod surface from the new property int QtMir" - that ring a bell?
[19:25] <mzanetti> dednick, yes
[19:25] <dednick> mzanetti: it's crashing tryShell/OrientedShell
[19:25] <mzanetti> dednick, there's a fix for that in silo 41
[19:26] <dednick> creating a surface before there is a window
[19:26] <dednick> mzanetti: ah. ok
[19:32] <mzanetti> dednick, mterry, thanks for the fixes. confirming silo 41 works fine again (for the side stage at least - testing OOBE stuff now)
[19:36] <mterry> mzanetti: cool.  we're thinking of removing unity8-schemas again, since it's not needed anymore.  Which would mean we can drop the version number down again, which means we might drop and add unity8 from silo again
[19:36] <mterry> mzanetti: I assume we aren't minutes from publishing the silo and that wouldn't be problematic?
[19:46] <ltinkl> dednick, Build failed: Merge conflict in ~unity-team unity8 shell chrome.
[19:46] <dednick> mmm
[19:47] <mzanetti> where?
[19:47] <mzanetti> how did that happen
[19:47] <mzanetti> it built like a minute ago
[19:47] <ltinkl> mzanetti, dednick: Text conflict in qml/Stages/TabletStage.qml
[19:47] <ltinkl> mzanetti, isn't it caused by my resubmitted tsdgeos' branch?
[19:48] <ltinkl> mzanetti, yeah I wonder how it built before when there was that conflict
[19:48] <mzanetti> dednick, you just merged with trunk, didn't you?
[19:48] <dednick> mzanetti: seconds ago.
[19:48] <mzanetti> at least the commit message says so
[19:48] <ltinkl> aha
[19:48] <mzanetti> dednick, revert please, merge in your prereq
[19:49] <mzanetti> well, I can try to build
[19:49] <mzanetti> but it will probably criss-cross
[19:51] <ltinkl> mzanetti, shall I revert https://code.launchpad.net/~unity-team/unity8/fix_ticket_1105_tests/+merge/289087 or is it fine like this?
[19:51] <mterry> dednick: unity8/shell-chrome has merge conflicts
[19:51] <dednick> mterry: yes.
[19:51] <mterry> dednick: oh I see above  :)
[19:51]  * mterry is late to the party
[19:52] <ltinkl> mterry, I guess he knows already ;)
[19:53] <mzanetti> ltinkl, don't know. need to test if it builds
[19:53] <mzanetti> looks ok I'd say
[19:53] <ltinkl> mzanetti, ok, won't touch it again :)
[20:02] <mzanetti> dednick, yeah, failed with criss-cross merge
[20:03] <dednick> mzanetti: :/ seems to merge fine with trunk...
[20:03] <dednick> it's the changes from unity8-ubuntu-xenial-landing-064
[20:03] <dednick> seemingly.
[20:05] <mzanetti> dednick, yeah, but merges need to happen through the chain
[20:05] <mterry> dednick: you can rebase on tutorial-redesign, I think that's near the top of the current tower-of-MPs
[20:06] <mzanetti> oh dear...
[20:06] <dednick> mterry: no, then i would depend on you.
[20:07] <mzanetti> it's based on side stage redesign, which in turn is based on oobe
[20:07] <mzanetti> but it was building before
[20:07] <dednick> although might be ablt to only get your merge.
[20:07] <mterry> dednick: what's wrong with depending on me?  what do you mean
[20:07] <dednick> mterry: your branch already depends on mine down the chain.
[20:08] <mterry> dednick: right, on side-stage-redesign.  I thought we were talking about rebasing shell-chrome
[20:08] <dednick> or not
[20:08] <mzanetti> sorry guys... need to leave you for a bit... the baby acts like it would die
[20:08] <dednick> or right. i thought it was on shell chrome.
[20:08] <mzanetti> bbiab
[20:09] <dednick> lol. ok!
[20:09] <dednick> i got to go for a bit as well. need to go pick up gf from train station.
[20:09] <mterry> dednick: maybe I should have based on shell-chrome when I put tutorial-redesign on top of stack, but didn't know it was placed like it was
[20:09] <mterry> dednick: OK, if you're heading out I can rebase tutorial-redesign
[20:09] <dednick> mterry: meh.
[20:10] <dednick> you can rebase sidestage as well if you like ;)
[20:10] <mterry> ?
[20:10] <mterry> maybe I don't understand the problem
[20:10] <dednick> just getting you to do my work for me. nvm :)
[20:10] <mterry> I assumed shell-chrome and tutorial-redesign were conflicting
[20:10] <mterry> Is there something else conflicting?
[20:12] <mterry> haha, it's those two stupid isDash & appId properties again
[20:12] <mterry> dednick: ok I'm rebasing on top of shell-chrome
[20:14]  * mterry kicks off build
[20:22] <mzanetti> ok. here again...
[20:22] <mzanetti> mterry, can I help?
[20:24] <mzanetti> ah ok. I see it should in theory be solved
[20:35] <ltinkl> mzanetti, mterry: meh, conflict again
[20:35] <mzanetti> still the shell chrome one
[20:35] <mzanetti> Warning: criss-cross merge encountered.  See bzr help criss-cross.
[20:38] <mzanetti> ok, I'm gonna fix, don't touch :)
[20:38] <mzanetti> I hope :D
[20:42] <mzanetti> ok... should work now
[20:43] <mterry> mzanetti: I didn't think it would be criss-cross, since there weren't any new merges in between
[20:43] <mterry> mzanetti: ah well
[20:43] <mzanetti> mterry, the criss cross was in shell_chrome
[20:43] <mterry> mzanetti: ah
[20:43] <mzanetti> mterry, it had sidestage redesign as prereq
[20:43] <mterry> right
[20:43] <mzanetti> I fixed the duplicate property there
[20:43] <mzanetti> dednick merged the chrome one with trunk instead of the rereq
[20:43] <mzanetti> lets see if it builds now
[20:44] <mzanetti> mterry, I'm a bit puzzled what you merged then before :)
[20:44] <dednick> hm? i'm merging sidestage into shell chrome now.
[20:45] <mzanetti> dednick, no
[20:45] <mzanetti> don't
[20:45] <mzanetti> I did
[20:45] <mterry> mzanetti: I got a conflict between shell-chrome and tutorial-redesign, so I figured I'd rebase
[20:45] <dednick> mzanetti: oh. k
[20:45] <mzanetti> mterry, lets see if bzr can digest that
[20:46] <mzanetti> but worst case we just gotta merge that one thing down the chain now and it should be ok
[20:46] <dednick> i've gota run in a minute.
[20:46] <mzanetti> I'm still a bit worried about test failures... the last runs didn't look so great
[20:46] <mzanetti> dednick, I guess I'll take it from here...
[20:46] <mzanetti> nope. still conflicting
[20:46] <mzanetti> dammit
[20:46] <dednick> shell chrome?
[20:46] <mzanetti> oh... overwrite would help
[20:46] <mzanetti> my bad
[20:47] <dednick> yeah. didnt see any changes :) was wondering.
[20:47] <mzanetti> yeah, i reverted the trunk-merge, then did the other
[20:47] <mzanetti> didn't pay attention to the push failing :/
[20:47] <dednick> mzanetti: i'll stay online. just busy getting dinner together/eating/etc...
[20:48] <dednick> i got loads of conflicts merging sidestage..
[20:57] <mterry> mzanetti: gosh dang it
[20:58] <mterry> fixing
[21:00] <mterry> mzanetti: fixed
[21:00] <mterry> mzanetti: had to uncommit, remerge, and overwrite, so I think it's clean now
[21:00]  * mterry rebuilds
[21:00]  * mterry just rebuilt unity8, hope that's all we expected to change
[21:12] <mterry> seems to have all merged
[21:14] <ltinkl> mterry, not sure about the latest version of ubuntu-system-settings/hwKeyboardMinimal
[21:14]  * ltinkl checking
[21:14] <mterry> ltinkl: you mean it might need a rebuild too?
[21:15] <ltinkl> mterry, guess not, latest version from 16.04.20160315, latest commit from yesterday
[21:32] <mzanetti> whitespace test
[21:41] <mterry> mzanetti: just saw that  :(
[21:42] <mterry> mzanetti: I don't think it's anywhere in the tutorial-redesign stack
[21:42] <mzanetti> the whitesoace?
[21:42] <mzanetti> already fixed it
[21:42] <mterry> mzanetti: nice
[22:10] <mzanetti> finally... uploading build