[08:28] <mzanetti> Saviq: you around yet?
[08:31] <Saviq> mzanetti, yup
[08:33] <mzanetti> Saviq: any hints on how to clip something to an Ubuntu Shape while still allowing mouse interaction?
[08:34] <mzanetti> couldn't really understand why it works in the popover's code tbh.
[08:34] <Saviq> mzanetti, UbuntuShape { source: ShaderEffectSource { sourceItem: foo } }
[08:34] <Saviq> rm
[08:35] <Saviq> image: ShaderEffectSource
[08:35] <mzanetti> right... that's what UbuntuShapeForItem does
[08:35] <Saviq> yeah
[08:35] <mzanetti> however, it does also "hideSource: true"
[08:35] <mzanetti> whcih is obviously needed for clipping
[08:35] <Saviq> mzanetti, yeah, but that's only visual hiding, not for input
[08:35] <mzanetti> oh really... I wonder why my code doesn't work then
[08:35] <mzanetti> because that's what I do
[08:35] <Saviq> mzanetti, it's not same as visible: false AFAICT
[08:36] <mzanetti> I had the same impression when doing the Launcher. but somehow it doesn't pick up input right now
[08:36] <mzanetti> well, I'll figure it
[08:36] <mzanetti> thanks
[08:36] <om26er> unity8 crashes for me whenever I open a music preview :/ bug 1240408
[08:42] <dednick> MacSlow, Saviq: https://bugs.launchpad.net/unity8/+bug/1237752 what's going on there?
[08:43] <Saviq> dednick, dunno :D
[08:43] <MacSlow> dednick, that's me having picked bugs to work on...
[08:43] <dednick> Why has it been set to ubuntu-settings-components ?
[08:43] <Saviq> MacSlow, dednick please sync, then :)
[08:44] <MacSlow> dednick, Saviq: I'm just trying to figure out what/where stuff is missing
[08:44] <dednick> :)
[08:44] <dednick> MacSlow: ubuntu-settings-components not in archive and not used by unity8 yet
[08:45] <MacSlow> dednick, I rather pick high/critical bugs in components I know... but there are none :)
[08:45] <dednick> sil2100: what is the status of ubuntu-settings-components landing in archive?
[08:45] <MacSlow> dednick, so this "bug" is rather a missing / unimplemented feature?!
[08:45] <Saviq> greyback, on https://code.launchpad.net/~gerboland/unity-mir/listen-for-server-start-stop-ready/+merge/191224
[08:45] <dednick> MacSlow: it's "half implemented", the impl is there, but it's not available yet.
[08:46] <Saviq> greyback, think we could post a custom event on the loop instead?
[08:46] <Saviq> greyback, maybe not now - but ultimately
[08:46] <Saviq> greyback, would rather not have unity-mir tied to unity8 that closely
[08:46] <greyback> Saviq: do-able I think yes
[08:46] <MacSlow> dednick, ok... removed myself then... and look for something else...
[08:47] <Saviq> greyback, feels like that'd be the cleanest?
[08:47] <dednick> MacSlow: ok. sorry about the confusion
[08:47] <dednick> i'll assign myself
[08:47] <greyback> Saviq: well if we drop SF support, is not thing something only unity-mir should worry about?
[08:47] <greyback> s/thing/this/
[08:47] <MacSlow> dednick, np... not your fault... the bug-description could be a bit more detailed :)
[08:48] <Saviq> greyback, I don't think unity-mir should "know" about what upstart requires of unity8
[08:48] <MacSlow> dednick, would be good if you could add some info there to avoid anyone else running into this assuming it's a plain bug
[08:48] <Saviq> greyback, after all we don't want unity-mir to be tied to unity8, if possible
[08:49] <Saviq> greyback, and unity-mir shouldn't just raise SIGSTOP 'cause unity8 needs it
[08:49] <dednick> MacSlow: well, now that i'm assigned hopefully nobody will try pick it up :)
[08:49] <MacSlow> dednick, crap... I can't get the bug-status back to "Triaged"
[08:49] <Saviq> greyback, sure, the $UPSTART_JOB check helps us there
[08:49] <greyback> Saviq: depends on who you should should be responsible for talking to upstart. Technically it is Mir who is notifying upstart, not unity
[08:49] <dednick> MacSlow: i've updated it.
[08:50] <MacSlow> dednick, ah ok... even better that way
[08:50] <Saviq> greyback, IMO technically it's unity
[08:50] <Saviq> greyback, it's a unity8 job, after all
[08:50] <dednick> just leaving it in progess so nobody steals
[08:50] <Saviq> greyback, unity just listens to Mir/unity-mir to know *when* to raise that
[08:50] <Saviq> greyback, ah wait
[08:50] <Saviq> greyback, stupid, we've not yet exec()'d
[08:51] <Saviq> greyback, so we won't get that event until then
[08:51] <Saviq> OTOH that's probably not such a big problem
[08:52] <greyback> Saviq: ok, thinking about it, it is upstart-specific, so shouldn't always be in unity-mir.
[08:52] <Saviq> greyback, yup
[08:53] <Saviq> greyback, aaaanyway
[08:53] <Saviq> greyback, 'tis good for now
[08:53] <greyback> yarp
[08:53] <Saviq> greyback, we need to bump the build dep on mirserver when we know what to bump it to
[08:53] <greyback> Saviq: actually, must test it with lightdm...
[08:53] <Saviq> greyback, how so?
[08:53] <greyback> Saviq: think lightdm using unity-mir.
[08:54] <greyback> though since I check the job name it'll probably be fine
[08:54] <Saviq> greyback, yeah
[08:54] <Saviq> greyback, it would actually make sense for lightdm to expect stop, too
[08:55] <Saviq> greyback, since we'll have maliit as a client there, too
[08:55] <Saviq> at some point at least
[08:56] <greyback> indeed
[09:04] <veebers> Saviq: ping
[09:07] <Saviq> veebers, pong
[09:08] <veebers> Saviq: hey re: your question in the MR for unlocking greeter, wanted it catch you before i was off for the night. Are you suggesting that the unity8 tests should use the same functions for unlocking the greeter/starting unity?
[09:08] <veebers> (to clarify)
[09:09] <Saviq> veebers, yes
[09:09] <Saviq> veebers, so that there's only one breaking point - that we'll know of 'cause our tests will fail if we break it
[09:10] <veebers> Saviq: yeah that's a good thought I like it. Right now the unity tests would need re-jigging (I'm not to sure how much off the top of my head) we could always have a single test that 'tests unlocking greeter' which uses those methods etc.
[09:11] <Saviq> veebers, shouldn't be huge I don't think
[09:11] <veebers> Saviq: but will hit that tomorrow and see if I can work it in
[09:11] <Saviq> veebers, yeah, cool o/
[09:13] <veebers> Saviq: but that shouldn't hold back that specific MR if doanac needs it right(unless you see any issues w/ it)? We/I can update the tests to use them after it's been merged
[09:15] <Saviq> veebers, ah no, yeah, not a prerequisite
[09:16] <veebers> Saviq: sweet, if I could bother you to comment approve if you're happy and I'll hit up doanac tomorrow and top approve if he's sorted too
[09:18] <Saviq> veebers, yeah, still need to read through
[09:20] <veebers> Saviq: understood. Thanks, I'm off for the night have a good one
[09:43] <Saviq> mzanetti, ping
[09:44] <mzanetti> Saviq: pong
[09:44] <Saviq> mzanetti, hey, can you please have a look at https://code.launchpad.net/~diegosarmentero/unity8/disable-ui-on-actions/+merge/190145 and confirm what I wrote in the comment
[09:44] <mzanetti> ack
[09:45] <Saviq> mzanetti, and if that's correct, let's just yank out the "block input" part from it
[09:45] <Saviq> to avoid breaking scopes and stuff
[09:51] <mzanetti> Saviq: hmm... not so sure you're right there
[09:51] <Saviq> mzanetti, if I'm not, then even better
[09:52] <mzanetti> Saviq: well... I'm not sure either. would need to see how it looks like on top of switching-previews
[09:52] <Saviq> mzanetti, didn't have time to do it proper
[09:52] <Saviq> mzanetti, it would conflict with switching-previews
[09:52] <Saviq> mzanetti, but that's ~ok
[09:52] <mzanetti> Saviq: as this one only wants to disable one preview, not all of them
[09:52] <Saviq> mzanetti, and then there's bug #1235430
[09:52] <mzanetti> there is no real overlay in switching-previews
[09:53] <Saviq> mzanetti, right, it's replaced on preview loaded?
[09:53] <mzanetti> not really, it's a underlay so to say
[09:53] <mzanetti> actually it's only the spinner as the dakened background is supposed to be there all the time
[09:54] <mzanetti> yeah... the variable height is another one... the openEffect won't do as it is
[09:54] <mzanetti> as the openEffect splits the background
[09:55] <mzanetti> hmm... might still look good
[10:04] <Saviq> mzanetti, no, it will look fine
[10:04] <Saviq> mzanetti, only there's a lot that needs to be answere d around dynamic height of the preview
[10:05] <mzanetti> first question: is it really dynamic or is it just another fixed height?
[10:05] <mzanetti> well, I'll take care about it. probably not today tho
[10:07] <Saviq> mzanetti, yeah no, of course
[10:07] <Saviq> mzanetti, I'd say dynamic - even if just because we don't know the height beforehand
[10:08] <Saviq> mzanetti, we don't know what preview will we get
[10:08] <mzanetti> Saviq: hmm.. we kinda do. i.e. the previewDelegateMapper will give us some preview that has some fixed height
[10:09] <Saviq> mzanetti, that's too late
[10:09] <Saviq> mzanetti, that's when the preview is already back
[10:09] <Saviq> mzanetti, not when we open the dash
[10:09] <Saviq> mzanetti, say if a preview takes 2s to generate
[10:09] <mzanetti> oh, is it
[10:09] <mzanetti> no...
[10:09] <Saviq> mzanetti, we open the dash straight away
[10:09] <Saviq> mzanetti, and wait for the preview to come back
[10:10] <Saviq> without knowing what type it's going to be
[10:10] <Saviq> and only then the mapper goes into play
[10:10] <mzanetti> hmm... but the type is mapped according to the filtergrid we're in, not according to the actual content response iirc
[10:11] <mzanetti> Saviq: yep, just checked, it queries the delegateMapper immediately
[10:11] <Saviq> mzanetti, that's wrong then
[10:11] <mzanetti> don't see why
[10:11] <Cimi> Saviq, on the issue with the inversemousearea for application grid
[10:12] <Cimi> Saviq, it might be that other mouse area are on top of it
[10:12] <Saviq> mzanetti, because we don't know what type of a preview the scope comes back with
[10:12] <mzanetti> Saviq: oh right... it uses previewData.rendererName
[10:12] <Cimi> Saviq, I did a test app and indeed mouse area can overlap and stop the inversemousearea to work
[10:12] <Saviq> Cimi, that's broken then
[10:12] <Cimi> Saviq, are you aware of a way of detecting, from inspector or so, that mouse areas are overlapping?
[10:13] <Saviq> Cimi, IMA should be the first to take any input - that's its whole purpose
[10:13] <Saviq> Cimi, please file a bug with your testcase
[10:13] <Cimi> Saviq, that should explain nic-doffay issue on search box dismiss kbd?
[10:14] <Saviq> mzanetti, wait
[10:14] <Saviq> mzanetti, we don't want Diego's branch on top of switching previews yet
[10:14] <Saviq> mzanetti, we need it for v1, we won't get switching previews in
[10:14]  * greyback bbiab
[10:14] <mzanetti> hmm... ok
[10:14] <Saviq> mzanetti, would've loved to, but it's just too late :/
[10:14] <mzanetti> I agree
[10:15] <Saviq> mzanetti, we might SRU it ;)
[10:16] <Saviq> mhr3_, should we be seeing "publisher" in app previews yet?
[10:16] <mzanetti> I probably should know what SRU means. but I don't
[10:16] <Saviq> mzanetti, Stable Release Update
[10:16] <mzanetti> ah
[10:17] <Saviq> mzanetti, but yeah, it's mostly for security fixes ;)
[10:17] <Cimi> Saviq, maybe we should start using prevent stealing more often?
[10:18] <Saviq> Cimi, why?
[10:18] <mhr3_> Saviq, no such field in our schemas, "copyright" is the closest i guess, still don't think it's filled in by click
[10:18] <Cimi> Saviq, because our shell is populated by mouse areas
[10:19] <Saviq> Cimi, so you don't want to be able to flick the shell any more?
[10:19] <Saviq> mhr3_, hmm bug #1226265 ?
[10:20] <Cimi> Saviq, come on, we don't need flicking
[10:20] <Cimi> Saviq, all results should stay in the window frame :)
[10:20] <Saviq> Cimi, file an ubuntu-ux bug! ;)
[10:21] <Saviq> oh jeez click previews are slow today :/
[10:21] <mhr3_> Saviq, ah, they're passing it as generic info hint, in that case it should work
[10:22] <Saviq> mhr3_, k
[10:22] <mhr3_> Saviq, i mean, if app previews display those :)
[10:22] <Saviq> mhr3_, that bug says it would
[10:24] <mhr3_> Saviq, i don't see it in single preview though
[10:31] <Saviq> mhr3_, me neither
[10:33] <mhr3_> Saviq, my guess is that it's cause app preview is misusing info hints and passes super-special-click-scope-only variants that are used to build the ui
[10:35] <Cimi> Saviq, actually
[10:35] <Cimi> Saviq, z index works in my testcase
[10:36] <Cimi> Saviq, I can put the inversemousearea on top
[10:36] <Cimi> Saviq, I can't in the dash
[10:36] <Saviq> Cimi, shouldn't happen anyway
[10:36] <Cimi> Saviq, you know how can I debug this in the dash?
[10:37] <Saviq> Cimi, IMA should be z: ∞
[10:37] <Cimi> Saviq, what about when you have two?
[10:37] <Cimi> two of them?
[10:37] <Cimi> (ima)
[10:37] <Saviq> Cimi, two of IMAs? dunno
[10:38] <Cimi> indeed
[10:38] <Cimi> we might have two in the dash
[10:38] <Saviq> Cimi, Cimi but only one active at any given time, afaik
[10:38] <Saviq> Cimi, either way, z-order shouldn't matter for them
[10:38] <Saviq> Cimi, please file a bug against uitk
[10:38] <Cimi> Saviq, I will but doesn't help to fix my bug
[10:39] <Saviq> Cimi, it does - 'cause people that know IMA will look at it
[10:39] <Cimi> Saviq, I can look at ima too
[10:39] <Cimi> Saviq, I can read c++, just cannot write it :P
[10:40] <Saviq> Cimi, please talk to Zsombor first
[10:50] <Saviq> mhr3_, grr you broke our autopilot tests on desktop ;P
[10:51] <mhr3_> Saviq, oh haven't you heard? ap-test-breaker is my job title now :P
[10:51] <mhr3_> also, you're welcome :P
[10:52] <mhr3_> Saviq, anyway, what did i do this time?
[10:55] <Saviq> mhr3_, we can't launch the fake apps
[10:55] <Saviq> mhr3_, so no Hud tests
[10:55] <Saviq> mhr3_, 'cause you "fixed" application:/// to not have full path
[10:55] <Saviq> mhr3_, granted, all that's broken anyway ;P
[10:56] <mhr3_> Saviq, so i guess ap reads the uris directly?
[10:56] <mhr3_> why doesn't it go via the regular shell.activateApplication route?
[10:57] <mhr3_> Saviq, also, if you revert it back you'll break the previews ;)
[10:57] <Saviq> mhr3_, because the desktop files don't exist on desktop
[10:58] <Saviq> mhr3_, and Scope::fallbackActivate bails at that point
[10:58] <Saviq> mhr3_, nah, I'm seeing if I can find an actual fix
[10:59] <mhr3_> actual fix is to have proper test environment
[10:59] <Saviq> mhr3_, care to enable mir on desktop? kthxbai
[11:01] <mhr3_> Saviq, i meant dropping a few .desktops in test data dir and pointing a few envvars to it
[11:01] <Saviq> mhr3_, ah well, except they're not really required
[11:01] <Saviq> mhr3_, but yeah, I get what you mean
[11:05] <Saviq> mhr3_, and maybe it's the safest bet now...
[11:06] <mhr3_> Saviq, need pointers how to set it up?
[11:06] <Saviq> mhr3_, nah
[11:06] <Saviq> we only really need the camera for now
[11:06] <mhr3_> k
[11:06] <Saviq> mhr3_, and it's really only about it _being_ there, not about the contents
[11:13] <Cimi> Saviq, we can enable disbar bottomswipe
[11:13] <Cimi> Saviq, line 62 of dashbar.qml
[11:17] <Saviq> Cimi, probably won't happen - we're getting rid of dash bar anyway
[11:17] <Cimi> Saviq, I know, but it's one liner :P
[11:18] <Saviq> Cimi, post v1, k?
[11:18] <Cimi> ok
[11:24] <Saviq> mhr3_, huh, actually it was as easy as fixing application:// → application:/// ;)
[11:25] <mhr3_> Saviq, you mean in the model?
[11:25] <Saviq> mhr3_, yeah
[11:25] <mhr3_> Saviq, then you broke the preview
[11:25] <Saviq> mhr3_, why? application:// is wrong
[11:25] <Saviq> mhr3_, application:/// is correct
[11:26] <mhr3_> Saviq, /// is correct if it continues with full path
[11:26] <Saviq> mhr3_, no
[11:26] <mhr3_> Saviq, yes
[11:26] <Saviq> mhr3_, NO
[11:26] <mhr3_> Saviq, YES
[11:26] <Saviq> mhr3_, no, because it doesn't support uppercase
[11:27] <Saviq> mhr3_, hostname part needs to be always empty
[11:27] <Saviq> mhr3_, bug #1231444
[11:27] <mhr3_> Saviq, ehm? application schema isn't defined to have any hostname
[11:28] <Saviq> mhr3_, it's not a correct url then
[11:29] <Saviq> mhr3_, when parsed with QUrl, the hostname part is downcased
[11:29] <Saviq> which is correct
[11:29] <Saviq> you can't just "omit" the / to say there's no hostname part
[11:29] <Saviq> the part after :// is always hostname
[11:32] <mhr3_> Saviq, in that case the app id should be considered the hostname, no?
[11:32] <Saviq> mhr3_, no it can't be
[11:32] <Saviq> mhr3_, 'cause it's meant to be case sensitive
[11:32] <Saviq> mhr3_, and hostname is not
[11:33] <mhr3_> you're making me read the rfc
[11:33] <Saviq> mhr3_, hostname is case insensitive, that I guarantee you
[11:33] <Saviq> mhr3_, but ok, fixing with XDG_DATA_HOME now
[11:39] <mhr3_> Saviq, ok, the application schema isn't exactly well defined according to the URI rfc, and that's why we introduced the appid schema, right?
[11:39] <mhr3_> but that doesn't change the fact how application schema is used
[11:40] <mhr3_> it's either application://[app_id] or applications://[/full/path/to/.desktop]
[11:56] <tsdgeos> lunch!
[11:57] <Saviq> mhr3_, https://code.launchpad.net/~saviq/unity8/add-ap-data/+merge/191382
[11:58] <mhr3_> Saviq, prepending to XDG_DATA_DIRS would be better
[11:59] <Saviq> mhr3_, hmm ok
[12:00] <mhr3_> Saviq, reason being that home is just one dir, you're likely to break something by changing it, data_dirs is a set of dirs
[12:00] <Saviq> mhr3_, mhm
[12:04] <Saviq> mhr3_, pushed
[12:05] <mhr3_> Saviq, sure you don't want to put something inside the .desktop?
[12:05] <Saviq> mhr3_, not needed atm
[12:05] <mhr3_> ok
[12:05] <Saviq> mhr3_, so don't want to
[12:06] <Saviq> mhr3_, it's just to trick Scope::fallbackActivate
[12:06] <mhr3_> approved
[12:08] <Saviq> mhr3_, I'll wait for ci to be happy
[12:08] <mhr3_> k
[12:09] <Cimi> Saviq, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1238763
[12:10] <Cimi> Saviq, my nexus cannot handle 2560x … images
[12:10] <Cimi> can someone try this with nexus 10?
[12:10] <Saviq> Cimi, https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1227783
[12:11] <Cimi> Saviq, ok, marking duplicate then
[12:16] <Saviq> Cimi, already done
[13:05] <tsdgeos> Saviq: why does it break append_hint ?
[13:06] <Saviq> tsdgeos, it breaks more I'm afraid
[13:06] <Saviq> tsdgeos, must be the lookup is broken somehow
[13:06] <Saviq> tsdgeos, anything that updates notifications
[13:06] <Saviq> tsdgeos, this is as far as I got http://paste.ubuntu.com/6245541/
[13:07] <tsdgeos> this is just fixing the autopulot, no?
[13:07] <tsdgeos> how did you find the append_hint is broken?
[13:08] <Saviq> tsdgeos, I ran the tests
[13:08] <Saviq> tsdgeos, but I can also see
[13:08] <tsdgeos> and they worked?
[13:08] <Saviq> tsdgeos, no they didn't
[13:08] <tsdgeos> the tests still don't pass here with that chang
[13:08] <tsdgeos> but because it can't find notification1
[13:09] <tsdgeos> not because anything else
[13:09] <Saviq> tsdgeos, did you install the modified unity-notifications?
[13:10] <tsdgeos> why would i need that for the notification1 to be found?
[13:10] <Saviq> tsdgeos, notification1 *are* all the notifications that are displayed - 0 is the placeholder
[13:10] <tsdgeos> ah
[13:10] <tsdgeos> obviously i do
[13:10] <tsdgeos> silly me
[13:10] <Saviq> tsdgeos, we're down to http://pastebin.ubuntu.com/6245556/
[13:10] <Saviq> 4 failures that I don't think are ap issues
[13:11] <Saviq> tsdgeos, scratch that, the urgency_order is fine, as I'd expect it
[13:12] <Saviq> tsdgeos, but none of the ones that *update* a notification are good
[13:13] <Saviq> tsdgeos, I expect the backend to be updating the wrong notification object
[13:13] <tsdgeos> ok
[13:13] <tsdgeos> i'll check
[13:14] <Saviq> or something like htat
[13:14] <Saviq> tsdgeos, you can use "examples" from unity-notifications to see what happens
[13:15] <Saviq> tsdgeos, but well, ap tests are probably even better, 'cause they'll tell you if stuff's fine
[13:15] <tsdgeos> sre
[13:16] <dednick> Saviq: my device keeps asking for ssh password lately. any way to get it to stop?
[13:16] <Saviq> dednick, ssh-copy-id
[13:17] <Saviq> dednick, probably ssh key failed to copy for some reason
[13:17] <pstolowski> charles, ping
[13:17] <tsdgeos> i hate autopilot
[13:18] <tsdgeos> why is it not using my compiled unity8 and instead using the system one
[13:18] <tsdgeos> don't we have code exclusively for that?
[13:18] <dednick> Saviq: thanks. worked
[13:19] <tsdgeos> ../../../builddir/install/bin/%s :_S ¿
[13:19] <charles> pstolowski, pong
[13:20] <tsdgeos> weird
[13:20] <dandrader> greyback, updated https://code.launchpad.net/~dandrader/ubuntu-keyboard/osk_rotation_lp1236489/+merge/190946
[13:20] <greyback> dandrader: cool, will take a look in 30mins or so
[13:22] <pstolowski> charles, hey! indicator-datetime-service crashes quite often for me on the desktop (almost daily); today it was https://bugs.launchpad.net/indicator-datetime/+bug/864530 but I'm not sure if it's the same every time. can I collect any more info to help fix it?
[13:22] <charles> pstolowski: !
[13:22]  * charles clicks
[13:22] <pstolowski> charles, sometimes it results in ~5 apport windows open in one session, but perhaps it's a separate issue with apport
[13:26] <Saviq> yeah, the weird "StateNotFoundError" is basically the same
[13:26] <Saviq> tsdgeos, ↑ as the notification times out due to not being updated
[13:26] <mzanetti> you know what's cool: with 3 fingers you can swipe the launcher, greeter and indicators simultaneously :)
[13:26] <tsdgeos> looking at it :)
[13:27] <tsdgeos> mzanetti: you have 3 fingers? that's what's cool
[13:27] <tsdgeos> ...
[13:27] <mzanetti> I have 10. believe it or not
[13:28] <tsdgeos> :O
[13:30] <dednick> sil2100: ping
[13:31] <sil2100> dednick: pong
[13:32] <mzanetti> MacSlow: git://anongit.kde.org/marble.git
[13:32] <dednick> sil2100: hi. just wanted to check on the landing status for ubuntu-settings-components. Is it in the pipeline?
[13:32] <mzanetti> MacSlow: branch qt5
[13:33] <MacSlow> mzanetti, thx
[13:34] <mzanetti> MacSlow: compile with "cmake <srcdir> -DQTONLY=1 -DQT5BUILD=1"
[13:34] <sil2100> dednick: didn't see any plans for it - is it required by anything right now? I can poke the landing guys if we can maybe prioritize it if needed
[13:34] <MacSlow> mzanetti, k
[13:36] <Saviq> greyback, standup?
[13:36] <charles> pstolowski|brb: that ticket is way too old, the backtrace is in code that doesn't exist anymore. Was that the link you intended to share, or do you have a newer crash report?
[13:36] <dednick> sil2100: it's not a major priority yet. Just didnt want it to be forgotten; will need it soonish.
[13:40] <Cimi> free karma https://code.launchpad.net/~cimi/unity8/fix-1231731/+merge/191414
[13:44] <Cimi> Saviq, I can spend some hours digging into this if you don0t have other high prio https://bugs.launchpad.net/unity8/+bug/1195349
[13:44] <Saviq> Cimi, sure, we're past high prio bugs, really
[13:45] <Cimi> Saviq, we still have a good list of unassigned https://bugs.launchpad.net/unity8/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field
[13:45] <Cimi> .has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search
[13:45] <Cimi> ops
[13:45] <Cimi> needs to shorten than
[13:45] <Saviq> Cimi, unassigned is fine, New is worse
[13:46] <Cimi> http://goo.gl/nd3NLw
[13:48] <Saviq> Cimi, that's ok, *we* are assigned by default
[13:48] <Cimi> https://bugs.launchpad.net/unity8/+bug/1238232
[13:48] <Saviq> Cimi, but we need to triage
[13:48] <Saviq> Cimi, yeah, that one's interesting :)
[13:48] <Cimi> quite funny :)
[13:51] <pstolowski> charles, hmm, right.. looking, I still have a crash file around
[13:53] <pstolowski> charles, this is my backtrace http://pastebin.ubuntu.com/6245754/
[13:54] <pstolowski> charles, I think ffi_call there made me think it was the same bt
[13:56] <charles> pstolowski: what a happy coincidence, seb128 and larsu and I were just talking about that bug
[13:57] <charles> that's been filed already, bug #1238737
[13:57] <charles> seb128 figured out the fix
[13:57] <pstolowski> charles, awesomeness! thanks
[14:01] <mzanetti> dandrader: ping
[14:01] <dandrader> mzanetti, pong
[14:01] <mzanetti> dandrader: I can reproduce the edge drag crash and have some findings. looks like a bug in DDA
[14:02] <mzanetti> dandrader:  http://paste.ubuntu.com/6245792
[14:02] <mzanetti> dandrader: now, I'm not sure how m_touchId works
[14:03] <mzanetti> dandrader: afaics you're only setting that in touchEvent_absent(). I assume when a new gesture starts
[14:03] <mzanetti> dandrader: but for some reason it can happen that the m_touchId is 0, while there is only one available touch point with id 1
[14:05] <dandrader> mzanetti, m_touchId is the id of the touch that is performing (or that we expect to perform) the gesture
[14:06] <dandrader> mzanetti, did you happen to have two fingers at the same time on the screen at any given moment?
[14:07] <nic-doffay> Saviq, ping
[14:08] <Saviq> nic-doffay, pong
[14:08] <dandrader> mzanetti, but in any case, we should get a "touch 0 ended" notice before it disappears from subsequent TouchEvents
[14:08] <dandrader> mzanetti, and that's what the code asusmes
[14:08] <dandrader> assumes
[14:09] <nic-doffay> Saviq, so I've moved the searchHistory ListModel to be a shared asset, however it appears that queries are not being added correctly because the search count never increase above 0. Any inclination what might be causing this?
[14:09] <nic-doffay> They are definitely being added to the same searchHistory.
[14:09] <dandrader> mzanetti, to make sure we are missing events you would have to log all touch events received
[14:10] <Saviq> nic-doffay, console.log() agrees with you?
[14:12] <mzanetti> dandrader: that's what I do
[14:13] <mzanetti> dandrader: got a touch event ...
[14:13] <mzanetti> dandrader: thats the first line touchEvent()
[14:13] <mzanetti> dandrader: oh... actually it's not... it's after the check for visible && enabled
[14:13] <mzanetti> so we _could_ miss something in there I guess
[14:15] <nic-doffay> Saviq, yeah.
[14:16] <Saviq> nic-doffay, and you're not getting any onCountChanged in the ListView?
[14:19] <nic-doffay> Saviq, negative.
[14:19] <Saviq> nic-doffay, so what changed between them working per-scope, and not working shared?
[14:20] <nic-doffay> Saviq, I moved the initialisation to Dash.qml.
[14:20] <nic-doffay> And passed it through to the page header.
[14:21] <mzanetti> dandrader: here's all: http://paste.ubuntu.com/6245873
[14:21] <mzanetti> dandrader: doesn't seem we're missing a touch event. more like the m_touchId gets confused when there are multiple touch es ongoing
[14:23] <Saviq> nic-doffay, I've no ready-made answer, if you show some code and tell me how it's not working, we can see
[14:23] <dandrader> mzanetti, so looks like we have a unit test already :)
[14:24] <dandrader> mzanetti, just feeding those events to DirectionalDragArea and seeing it crash
[14:24] <mzanetti> dammit... doorbell 3rd time in 10 mins
[14:24] <Saviq> kgunn, sorry, tab-based navigation in dash is TODO
[14:24] <dandrader> mzanetti, although your log doesn't say anything about the contents of those events, which is the interesting part
[14:24] <Saviq> kgunn, sorry if I made it confusing
[14:26] <Saviq> mhr3_, had to fix https://code.launchpad.net/~saviq/unity8/add-ap-data/+merge/191382
[14:26] <nic-doffay> Saviq, I figured as much. :/
[14:28] <Cimi> Saviq, https://code.launchpad.net/~unity-team/unity8/fix-1238232/+merge/191424
[14:29] <Saviq> Cimi, request a review from mterry please
[14:29] <Cimi> Saviq, done
[14:29] <mhr3_> Saviq, k, waiting for another ci run, or want me to re-approve?
[14:30] <Saviq> mhr3_, let's wait it out
[14:30] <mzanetti> dandrader|afk: I think I got it. there is touch event of type TouchEnd coming in as first thing for touch id 1. that's where you start a new gesture for touch id 1. but as it as a TouchEnd, it's not contained in the list of available touch points any more in the next run and boom
[14:30] <Saviq> mhr3_, or well, you can approve, I won't merge before the CI run anyway
[14:31] <mhr3_> Saviq, eek, still manual merging? :)
[14:31] <nic-doffay> Saviq, here's the branch, the diff is pretty small. https://code.launchpad.net/~nicolas-doffay/unity8/scope-search-refactor
[14:31] <Saviq> mhr3_, indeed
[14:43] <dandrader> mzanetti, awesome!
[14:43] <mzanetti> dandrader: https://code.launchpad.net/~unity-team/unity8/fix-1228336/+merge/191427
[14:47] <mzanetti> dandrader: hmm... that's really shitty to test
[14:47] <mzanetti> dandrader: as QTest::touchEvent doesn't let me generate a release only
[14:47] <mzanetti> and afaics I can't modify the QTouchEventSequence to remove the TouchBegin event
[14:48] <Saviq> tsdgeos, btw, file a QTBUG so we don't forget about ListView stealing focus?
[14:48] <mzanetti> wait... I might understood something wrong
[14:48] <tsdgeos> Saviq: ok, will do
[14:51] <Saviq> mzanetti, hey, so what's the status of https://code.launchpad.net/~diegosarmentero/unity8/disable-ui-on-actions/+merge/190145
[14:51] <Saviq> mzanetti, are we getting a MouseArea overlay or?
[14:52] <mzanetti> Saviq: well... what should I say... it won't work with switching-previews. but as we need to get this in before the other... just get it merged and I'll remove it again when merging the switching-previews
[14:52] <Saviq> mzanetti, ugh... can we get the overlay animating or not?
[14:53] <mzanetti> what do you mean with animating?
[14:53] <Saviq> mzanetti, fade in/out
[14:54] <Saviq> mzanetti, it was just blinking here for me, and AFAICT it couldn't be otherwise, 'cause it was created / destroyed with the preview itself
[14:54] <Saviq> mzanetti, that's what I wanted yo to confirm
[14:54] <Saviq> mzanetti, anyway, I got some time now, will look
[14:54] <mzanetti> Saviq: oh ok... got you wrong there
[14:55] <mzanetti> Saviq: right... the backend sends us a new preview object when something changes
[14:55] <Saviq> mzanetti, and that recreates the overlay as well
[14:55] <mzanetti> yes
[14:56] <mzanetti> Saviq: so I guess what you can do is to make this overlay opacity: 0 by default, and change that in component.onCompleted
[14:57] <Saviq> mzanetti, sure, but as soon as the new preview comes in
[14:57] <Saviq> mzanetti, it will disappear in one frame
[14:57] <mzanetti> true
[14:57] <Saviq> mzanetti, so yeah, we can fade in, but not out
[14:58] <mzanetti> but actually imho having such an overlay would look bad anyways. why not just disable the buttons?
[14:58] <Saviq> I'm fine with not showing it at all and just prevent people from causing mayhem in the backends
[14:58] <Saviq> mzanetti, we need to show that stuff is happening
[14:58] <mzanetti> +1
[14:58] <Saviq> mzanetti, but yeah, there's no design for long-running tasks while in preview
[14:59] <mzanetti> the action button that is causing the wait could have a spinner on it :)
[14:59] <mhr3_> ui fixes for bugs in scope :(
[15:00] <mzanetti> mhr3_: right..... fix the scope :P
[15:00] <mhr3_> wish it were that simple
[15:10] <Saviq> mzanetti, did you notice, btw, that LazyImage does not display the X on broken_image on the phone?
[15:10] <mzanetti> Saviq: nope didn't notice
[15:10] <Saviq> mzanetti, I think the SDK bails out on rescaling that image for some reason
[15:17] <Saviq> /food
[15:25] <mzanetti> dandrader: hmm... have a problem
[15:25] <mzanetti> dandrader: if I just enject a release in a test, it never ends up in the actual code
[15:32] <dandrader> mzanetti, install an event filter on the DDA and filter out the press
[15:48] <Saviq> mzanetti, you filed a bug about the private / no number issues?
[15:48] <Saviq> mzanetti, there's a mention of it on ubuntu-phone
[15:48] <Saviq> would be good to link a bug report
[15:53] <mzanetti> Saviq: done
[15:54] <Saviq> mzanetti, thanks
[15:58] <tsdgeos> Saviq: can't file the bug about LV and focus, since can't create a testcase :-/
[15:58] <tsdgeos> Saviq: http://pastebin.kde.org/pk7031r0r "works"
[15:58] <tsdgeos> i.e. doesn't shuffle the focus
[15:58] <Saviq> tsdgeos, put it in a FocusCope
[15:58] <Saviq> S
[15:58] <tsdgeos> just thhought that
[15:58] <tsdgeos> let me see
[15:59] <tsdgeos> nope
[15:59] <tsdgeos> http://pastebin.kde.org/p9gvvm4fz
[15:59]  * tsdgeos headdesks
[15:59] <tsdgeos> :(
[16:22] <mzanetti> dandrader: found another issue with this so I added a check that only the starting finger is processed and other fingers are rejected.
[16:22] <Cimi> is there a way to get the minimum real value available per platform?
[16:22] <mzanetti> dandrader: also updated tests
[16:22] <dandrader> mzanetti, if a second finger lands, you've to reject the gesture
[16:22] <mzanetti> dandrader: why is that?
[16:23] <mzanetti> I would not say so
[16:23] <dandrader> mzanetti, becuase it's a single-finger drag gesture
[16:23] <mzanetti> dandrader: sure... but why shouldn
[16:23] <dandrader> mzanetti, if you use two-fingers it's not a single-finger drag gesture anymore
[16:23] <mzanetti> dandrader: sure... but why shouldn't I be able to use one finger to swipe the left edge and another to swipe the right edge?
[16:24] <mzanetti> dandrader: I'm voting against that
[16:24] <Cimi> like Math.minium valid Real
[16:24] <Cimi> crap like that
[16:25] <dandrader> mzanetti, if you have one finger on the left edge, and one finger on the right edge. each DDA will get only one finger
[16:25] <mzanetti> dandrader: one DDA only works with one finger at a time
[16:25] <mzanetti> dandrader: yeah
[16:25] <dandrader> mzanetti, so there's no problem there
[16:25] <mzanetti> but prior to my branch one DDA can get confused by another
[16:25] <dandrader> mzanetti, but if you lay two fingers on the same edge, they both have to be rejected
[16:26] <mzanetti> dandrader: I wouldn't say so
[16:26] <mzanetti> dandrader: makes it harder to work with, for example if you accidentally touch something with your palm
[16:26] <mzanetti> dandrader: it's only the first finger that is used for the gesture detection anyways
[16:27] <dandrader> mzanetti, wanna join mumble. I'm tired of typing
[16:27] <mzanetti> dandrader: actually I don't want to discuss that either right now
[16:28] <mzanetti> this branch fixes the crash. I don't want to change something else in there
[16:28] <dandrader> mzanetti, ok
[16:40] <Cimi> Saviq, I'm on fire these days https://code.launchpad.net/~cimi/unity8/fix-1195349/+merge/191460
[16:40] <Saviq> lol
[16:42] <greyback> Saviq: I need a review, asap: https://code.launchpad.net/~gerboland/unity-mir/fix-leaks/+merge/191449
[16:43] <Saviq> greyback, yes sir
[16:44] <Saviq> greyback, so setting session to nullptr makes sure Mir does the right thing?
[16:44] <Saviq> or well, shared_ptr does
[16:44] <greyback> Saviq: yes, the shared pointer releases it's hold on the object, probably deleting it as it is last to hold it
[16:44] <Saviq> greyback, shall I test?
[16:44] <Saviq> greyback, i.e. should I see a difference
[16:45] <greyback> Saviq: alf_ has already in #ubuntu-mir
[16:45] <greyback> Saviq: <alf_> greyback: tvoss: verified ubuntuuitoolkit tests run fine, system fluid after tests
[16:45] <greyback> Saviq: but don't let that stop you
[16:45] <Saviq> will
[16:45] <Saviq> do
[16:45] <Saviq> greyback, anything in mir needed?
[16:45] <greyback> Saviq: nope
[16:46] <Saviq> cool beanz
[16:48] <bjsnider> i'm wondering if this still looks relevant: http://paste.debian.net/58424/
[16:48] <bjsnider> it's the patch that makes empathy work with unity's progress bar
[16:50] <Saviq> greyback, wow, we're down to below 100MBs RSS
[16:50] <Saviq> Albert did good with LVWPH :)
[16:50] <greyback> Saviq: yeah, we've done well
[16:51] <Saviq> 200MB already :D
[16:51] <Saviq> and counting ;)
[16:51] <Saviq> (before the fix)
[16:52] <tvoss> greyback, alan_g \o/
[16:54] <Saviq> shite, 600MB already
[16:54] <Saviq> and died
[16:55] <mzanetti> dandrader: actually you're right I guess...
[16:55] <Saviq> let's see - 90.3MB to start with
[16:56] <Saviq> yeah this is looking much better
[16:57] <Saviq> greyback, happroved!
[16:57] <greyback> Saviq: thank you
[16:57] <Cimi> Saviq, I finished my list of assigned bugs (apart the applications grid but it's on hold for now). Tomorrow I'm going to the office to see if there is feedback on something not reported that we want to fix, otherwise I can start pickup unassigned bugs
[16:58] <Saviq> greyback, hmm seems like we're still leaking somewhere now and again
[16:58] <Saviq> greyback, been going down to 87MB in between tests, ~10MB for a launched app
[16:58] <Saviq> after a few tests it's 99MB low, 110MB high
[16:59] <Saviq> so it seems like we've leaked one at some point
[16:59] <Saviq> greyback, but yeah, let's see where it settles
[16:59] <Saviq> greyback, still a huge improvement
[16:59] <greyback> Saviq: yep. The 2 screenshots may be held onto at times when they're not needed. Want to profile to see what else could be to blame tho
[17:00] <Saviq> we're still leaking smaller amounts constantly it seems
[17:00] <Saviq> but yeah, that's much appreciated all in all :)
[17:00] <Saviq> freakin' smart pointers :P
[17:00] <Saviq> not so smart anymore, are ya!
[17:01] <Saviq> 60 tests OK
[17:01] <Saviq> and we've leaked some 10MBs
[17:01] <Saviq> yeah!
[17:19] <mzanetti> Saviq: where is the code for the sim pin stuff?
[17:19] <mzanetti> the UI, that is
[17:34] <Saviq> mzanetti, Panel
[17:34] <Saviq> mzanetti, NotificationMenuItemFactory and start from there
[17:35] <Saviq> or well, that's it
[17:35] <Saviq> mzanetti, so not Panel - Notifications
[17:36] <mzanetti> me actually needs to enable the sim pin
[17:36] <mzanetti> :D
[17:37] <mzanetti> nooooo. qtbus not preinstalled :D
[19:33] <seb128> just as a warning, if some people have the unity8 saucy package installed, it might make your boot hang after today's update
[19:33] <seb128> if it does, remove /etc/init/boot-hook
[19:33] <seb128> boot-hooks
[19:42] <kenvandine> seb128, that makes me want to install unity8 on my desktop :)
[19:44] <seb128> kenvandine, lots of fun to debug boot hanging on plymouth, I'm glad stgraber helps
[20:24] <tedg> bregma, Okay, I can't build Unity.  I think it's because of my nvidia driver.
[20:24] <tedg> bregma, Can I disable the headless tests for the build?
[20:24] <tedg> bregma, Using bzr bd currently.
[20:24] <bregma> I know I usually do
[20:24] <tedg> bregma, How does one do that?
[20:25] <bregma> I just manually edit them out of the CMakeLists.txt and check that in temporarily
[20:25]  * bregma is a dirty cheater
[21:10] <tedg> bregma, Okay, this builds and works on my machine: https://code.launchpad.net/~ted/unity/nih-signals-complete/+merge/191457
[21:12] <bregma> tedg, if you stop the session dbus server, does it still cause unity-panel-service to call abort()?
[21:14] <tedg> bregma, Sure, wrong bug?
[21:14] <bregma> not necessarily
[21:14] <tedg> bregma, That's normal behavior for dbus clients.
[21:15] <bregma> the biggest problem is u-p-s emitting "(unity-panel-service:1686): Indicator-Appmenu-CRITICAL **: OMG! Unable to get a connection to DBus" on shutdown, which calls abort()
[21:16] <bregma> because the dbus daemon is shut down by upstart before yu-p-s is
[21:17] <bregma> however, it'sways near "(null):dbus_error.c:69: Unhandled error from nih_dbus_error_raise: Connection was disconnected before a reply was received" in the log
[21:18] <bregma> which comes at process startup
[21:21] <bregma> either way, tedg, your proposed change is still correct and does the right thing, I just don't think it will fix the bug
[21:23] <tedg> bregma, That does seem odd considering dbus dies last.
[21:24] <tedg> bregma, Is that still happening?  It could be that it was starting too fast for dbus.  That was an issue in the dbus job.
[21:27] <bregma> I haven't see it duped since last week
[21:28] <bregma> MP approved anyway
[21:28] <tedg> Hopefully they're both fixed :-)
[21:31] <bregma> let's hope


[06:13] <jibel> karni, Ok, rvr will do the verification
[08:20] <sil2100> alecu: hey!
[08:21] <sil2100> alecu: I forgot to ping you yesterday with the bug number of the unity-notifications regression
[08:21] <sil2100> alecu: https://bugs.launchpad.net/ubuntu-rtm/+source/unity-notifications/+bug/1470031
[08:54] <davmor2> bfiller I don't see an update to the testplan https://wiki.ubuntu.com/Process/Merges/TestPlan/address-book-app for the new code I assume it is just testing that I can search for unicode characters right or is it a Chinese specific fix silo18 I'll carry on with the rest of the plan while I wait.
[09:07] <abeato> trainguards, can I have a silo for line 66?
[09:21] <ogra_> bah, i got a duplicated update notification again ... second day in a row :/
[09:22] <ogra_> http://i.imgur.com/B1bX5SO.png
[09:30] <sil2100> abeato: on it
[09:30] <abeato> sil2100, ogra_ I want to land lxc-android-config syncing it from a ppa for vivid&wily, is that possible? what would be the right thing to put on the spreadsheet cell?
[09:31] <sil2100> abeato: synces and dual landings do not really go in pair sadly
[09:31] <abeato> sil2100, hmm, I feared that
[09:31] <abeato> sil2100, ok, I would change the landing to do it just for vivid
[09:31] <abeato> for the moment
[09:31] <sil2100> Well, I would prefer it first to happen for wily and then vivid
[09:32] <sil2100> Or two landings at once
[09:32] <abeato> sil2100, ok, changing to wily
[09:32] <sil2100> Like, two requests with the same sync line, but one for wily and one for vivid
[09:32] <sil2100> Since too many times we then had landings that we forgot to release to the devel release
[09:32] <abeato> sil2100, wily for the moment, I'll sync later
[09:33] <abeato> I need to do some testing
[09:33] <sil2100> ACK, assigning
[09:33] <abeato> sil2100, great, thanks
[09:46] <Laney> AlbertA: hi, what's the status of silo 013?
[10:30] <abeato> sil2100, any idea how can I fix that ? ^^
[10:31] <abeato> sil2100, should I keep version as 226? or is it because I used wily instead of UNRELEASED in the changelog?
[10:31] <sil2100> abeato: ah, uh, we'll have to do it manually - the sync that is
[10:32] <sil2100> abeato: syncing only works for CI Train packages, as we need to mangle the version number
[10:32] <sil2100> abeato: let me prepare that for you in a minute
[10:32] <abeato> sil2100, ok, I see, thanks
[10:33] <abeato> sil2100, how can I know which packages are from the CI train?
[10:33] <ogra_> hey, you guys removed my manually installed calendar with the last update !
[10:34] <ogra_> sil2100, popey, jibel ^^
[10:34] <popey> not me :)
[10:34]  * ogra_ checks the krillin
[10:34] <popey> my calendar is still installed
[10:34] <popey> on both
[10:35] <ogra_> also gone on krillin
[10:35] <sil2100> abeato: by the package version usually :)
[10:36] <sil2100> abeato: CI Train packages follow a specific versioning, upstream+series.date-0ubuntu1
[10:37] <sil2100> ogra_: uh, that was not intended, but we removed it from the images, yes
[10:37] <abeato> sil2100, ah, interesting, good to know that :) ... is there around any good read on that stuff?
[10:37] <sil2100> abeato: https://wiki.ubuntu.com/citrain/LandingProcess#Syncing_from_and_to_the_Stable_Overlay_PPA
[10:37] <sil2100> And the SyncSilo related stuff too
[10:37] <ogra_> sil2100, right .. i wonder if i uninstalled the manually installed version at some point or if the switching to the rc-proposed channel automatically gave me the version from the custom tarball
[10:38] <abeato> sil2100, cool, thx
[10:39] <ogra_> hmm, i cant search for it in german in the click scope
[10:39] <ogra_> dont we have localized search keywoards ?
[10:39] <ogra_> *words
[10:46] <sil2100> abeato: hm, thinking how to deal with lxc-android-config
[10:47] <sil2100> abeato: I think I'll simply do a binary copy
[10:47] <sil2100> abeato: since otherwise I would have to change the version number, while I see it's the same for overlay and wily already
[10:47] <sil2100> So it seems it has been binary synced
[10:47] <abeato> sil2100, it's all configuration files so that should be fine
[10:47] <sil2100> And it's just a config, I suppose it's safe
[10:47] <abeato> yep
[10:51] <sil2100> abeato: hm, let me change your silo to a dual silo then
[10:51] <sil2100> abeato: since lxc-android-config is the only thing you wanted to sync, right?
[10:51] <sil2100> The rest were merges
[10:52] <abeato> sil2100, correct
[10:52] <sil2100> So I'll simply copy lxc-android-config for both vivid and wily and the rest you'll build as a dual landing
[10:52] <abeato> sil2100, nice, that will make things easier :)
[10:57] <sil2100> Grrr, Robert added some stupid checks
[10:59] <sil2100> abeato: ok, it seems due to dual-landing implementation issues I can't do it this way ;/
[11:00] <sil2100> eh
[11:00] <abeato> sil2100, oh...
[11:00] <sil2100> abeato: let's do it traditionally... wily then vivid
[11:00] <abeato> sil2100, ack
[11:03] <sil2100> abeato: ok, copied the lxc-android-config package
[11:04] <sil2100> abeato: I'll also assign a silo for the sync from wily once you release silo 006
[11:04] <abeato> sil2100, great
[11:04] <sil2100> abeato: once 006 lands in the archive, you'll have to press build on it
[11:12]  * sil2100 stares on ogra_, pressuring him on you-know-what
[11:23] <Laney> Is there a standard version suffix for the overlay?
[11:24] <rvr> karni: ping
[11:25] <rvr> karni: "Could not retrieve your telegram data" Did you update the scope? com.canonical.scopes.dashboard_1.8.1_armhf.click
[11:25] <rvr> karni: That message is not shown in Spanish
[11:32] <sil2100> Off to prepare lunch
[11:33] <sil2100> Laney: hey, no... we're using vivid versioning
[11:33] <sil2100> Laney: as the idea is to SRU each of those packages to the main archive (as a binary copy)
[11:34] <Laney> sil2100: and just fix it if there is a collision?
[11:34] <Laney> sil2100: Not sure that mir 0.14 is going to ever be SRUed, is it?
[11:48] <davmor2> rvr: is the scope not cwaynes team? or does it get the text from telegram itself?  karni  do you happen to know
[11:49] <rvr> davmor2: Not sure. It appears in Today's scope, but the text comes from the Telegram scope.
[12:06] <abeato> sil2100, silo 6 shows status "Silo ready to build" although all packages are there, should I take any action?
[12:06] <sil2100> abeato: I think a watch_only build would do the job
[12:07] <abeato> sil2100, ok
[12:29] <abeato> sil2100, yet another issue with silo 6... we have a new dependency for ofono on package libc-ares2 , I guess I need to add that to "additional source packages"?
[12:36] <jibel> bzoltan_, Hey, when do you plan to land silo 3?
[12:42] <sil2100> abeato: is libc-ares2 missing in wily?
[12:42] <abeato> sil2100, yes
[12:43] <abeato> sil2100, it's in the archive
[12:44] <sil2100> You need a new version in silo 006 or something?
[12:45] <abeato> sil2100, no, should it be installed automatically? citrain did not install ofono, just nuntium
[12:46] <sil2100> abeato: by citrain you mean the citrain console tool?
[12:46] <abeato> sil2100, yes
[12:47] <sil2100> abeato: hm, don't know much about that tool, I don't use it or maintain it, but I suppose it should install everything from the silo PPA
[12:47] <sil2100> If it's a dependency of ofono it should auto-install it along with it
[12:47] <sil2100> (if it's available in the archive)
[12:47] <abeato> sil2100, right
[12:48] <abeato> sil2100, ok, I guess is some bug in citrain, nm
[12:49] <sil2100> I hope that's the case ;)
[12:50] <abeato> sil2100, :)
[13:11] <mzanetti> trainguards, please reconfig 17. I had to restructure it
[13:25] <jgdx> jibel, Victor not on irc?
[13:26] <brendand> jgdx, he's rvr here
[13:26] <rvr> jgdx: Me or victorp? :)
[13:27] <jgdx> rvr, vrruiz :)
[13:27] <jgdx> rvr, so that wpa2-ep silo, are you close to such a network?
[13:27] <rvr> jgdx: I just moved silo 40 card to ready for testing, but I don't have a WPA2 Enterprise network
[13:28] <jgdx> brendand, thanks!
[13:28] <rvr> jgdx: I've asked who has in the team, to test it
[13:29] <jgdx> rvr, thanks. I just tested the silo today with and without a certificate to connect to eduroam. Joerg has tested eduroam as well, and Pete Woods has tested his own wpa-ep network. All good.
[13:29] <rvr> jgdx: Ack
[13:30] <jgdx> rvr, I've raised concerns about getting this testes to my manager, maybe your team could do this as well? :) It's a serious problem.
[13:30] <jgdx> s/testes/tested
[13:30] <rvr> jgdx: Surely we want it tested, davmor2 may be doing it
[13:31] <kenvandine> jgdx, one of many things that's tricky to get tested
[13:31] <kenvandine> similar to all the things that may be carrier specific
[13:32] <jgdx> kenvandine, yup.
[13:33] <kenvandine> jgdx, my head is still spinning over your call forwarding branch passing CI... without the fix for the search tests
[13:33] <kenvandine> it's actually got me a little freaked out... how could that have possibly only returned 1 result, unless there is a bug in the code that provides the dynamic keywords
[13:34] <kenvandine> and sometimes it takes to long or something
[13:35] <sil2100> mzanetti: on it
[13:37] <mzanetti> sil2100, thanks
[13:41] <jgdx> kenvandine, I willed it.. :s
[13:41] <kenvandine> :)
[13:44] <jgdx> kenvandine, I don't really know, but let me know if you need an extra pair of test devices
[13:48] <kenvandine> jgdx, nah... i tried it a few times without my fix on mako and it did fail each time
[13:56] <mzanetti> sil2100, can you drop unity-api from the ppa for silo 17 please
[13:57] <sil2100> mzanetti: from the PPA? On it
[13:59] <mzanetti> ta
[13:59] <sil2100> Should be done
[13:59] <mzanetti> perfect
[13:59] <boiko> trainguards: could someone please remove telepathy-qt5 from silo 39's ppa and get the silo reconfigured?
[14:00] <boiko> the source landing of telepathy-qt5 was already done somewhere else and now only the other packages are needed
[14:00] <sil2100> boiko: on it!
[14:00] <boiko> sil2100: thanks!
[14:06] <sil2100> boiko: reconfigured, package deleted
[14:07] <boiko> sil2100: great! thanks!
[14:07] <jgdx> davmor2, for silo 40, please note that the way to connect to a wpa2 enteprise network is by going to System Settings -> Wifi -> Connect to hidden network.
[14:08] <jgdx> rvr, ^
[14:09] <pmcgowan> jgdx, is that required or just a temporary thing
[14:11] <jgdx> pmcgowan, that's temporary
[14:11] <pmcgowan> ok
[14:12] <pmcgowan> jgdx, whats left to do then?
[14:15] <jgdx> pmcgowan, when the user clicks a new WPA-EP network in the indicator, the indicator will spawn a dialog coming from System Settings.
[14:15] <sil2100> alecu, davmor2: hey guys, did Pete pick up the laptop already?
[14:15] <pmcgowan> jgdx, so we need code to display that network type and settings shares that code?
[14:16] <sil2100> alecu: did you have a moment to check that unity-notification regression we had to revert?
[14:17] <jgdx> pmcgowan, we need code in the indicator redirecting to settings and code for settings that handles the redirect. No sharing at this time..
[14:17] <jgdx> s/code for settings/code in settings
[14:17] <pmcgowan> jgdx, my question really is why doesnt a wpa network show up in the list in settings today
[14:17] <alecu> sil2100: I've not seen pete yet, I guess he might be setting it up now
[14:17] <pmcgowan> in silo 40
[14:17] <jgdx> pmcgowan, it does?
[14:17] <alecu> sil2100: I'll take a look now
[14:17] <jgdx> pmcgowan, I'm pretty sure
[14:17] <jgdx> pmcgowan, but you can't configure it
[14:18] <pmcgowan> jgdx, sorry, I am butting in based on your comment above that hidden network must be used, not understanding why
[14:21] <jgdx> pmcgowan, oh right. System Settings is the only program that can configure WPAEnterprise networks right now, and that's the way to do it. System settings has no other Wifi dialog, except the "Connect to hidden network" one
[14:22] <jgdx> pmcgowan, a silo coming shortly (as soon as indicator network stuffs is done, should be trivial) that will allow the user to configure WPAEnterprise networks tapping networks in the indicator, or System Settings network list.
[14:22] <pmcgowan> jgdx, ok, and what needs configuring
[14:22] <pmcgowan> I never used that tye of AP
[14:22] <jgdx> tons of things :)
[14:22] <sil2100> alecu: thanks!
[14:22] <jgdx> pmcgowan, outer auth, inner auth, certs, auth versions, private keys, user name, passwords...
[14:22] <kenvandine> pmcgowan, of which the settings provides a UI for, so the indicator will take you right to the interface
[14:23] <jgdx> list goes on
[14:23] <dbarth> sil2100: hiya; quick question, is there still an overlay ppa for vivid?
[14:23] <kenvandine> so the settings landing is still useful, you just have to access it through connect to hidden
[14:23] <kenvandine> until the indicator end lands
[14:24] <sil2100> dbarth: hey! Yes, it's possible we'll stay with the overlay even
[14:24] <sil2100> dbarth: anyway, for OTA-5 we stick to the overlay
[14:24] <sil2100> And the discussion and analysis continues ;)
[14:24] <dbarth> sil2100: i'm wondering if we could have oxide 1.8 a bit before it's in the security pocket for regular vivid
[14:24] <dbarth> having it in the overlay ppa
[14:24] <sil2100> hm
[14:25] <sil2100> dbarth: when is the planned security release? Do you know/
[14:25] <dbarth> to test something before rolling that out to actual vivid users, when it becomes an official stable update
[14:25] <dbarth> around 2nd week of july
[14:25] <dbarth> so a bit short for ota-5
[14:25] <sil2100> Does it fix any of the targeted OTA-5 bugs?
[14:25] <dbarth> wily should be fine already, but since we're trying to stay in sync
[14:26] <dbarth> good question; i don't think there are any criticals there mostly extra features
[14:26] <dbarth> find in page, in the browser, for example
[14:26] <jibel> sil2100, dbarth it's needed for the find in page feature
[14:26] <dbarth> right
[14:27] <sil2100> hm, ok
[14:27] <sil2100> dbarth: anyway, would be nice to have it in a silo first
[14:27] <dbarth> ah well, bugs - features; sorry, there are some on the ota-5 list actually
[14:27] <dbarth> not just issues
[14:27] <sil2100> Then QA can sign it off (and make sure that the security upload won't break anything) - and also consider landing it for OTA-5
[14:27] <dbarth> ok, with that path mapped out, we can start doing some uploads and test
[14:28] <dbarth> sounds good
[14:28] <sil2100> Excellent then :)
[14:47] <AlbertA> Laney: I have to rebuild qtubuntu camera....yesterday the silo was approved by QA but I have to rebuild now....I hate it when that happens
[14:47] <AlbertA> Laney: in regards to landing-013 I mean
[14:49] <Laney> AlbertA: I don't see gst in there though?
[14:49] <Laney> and does that mean it has to be re-QAed
[14:53] <AlbertA> Laney: gst is out of tree isn't it?
[14:53] <Laney> AlbertA: It's not train managed but you can land it in sync via the silo
[14:54] <AlbertA> And the branch that is there is out of sync with the source package
[14:54] <AlbertA> so I'm not sure what I'm supposed to do there
[14:56] <davmor2> jgdx: I'll come back to you in a minute once I setup this router
[15:01] <jgdx> davmor2, I'm eod, but will check in in about 6 hours.
[15:02] <davmor2> jgdx: no worries I think I have everything I need anyway
[15:03] <jgdx> davmor2, wonderschön. Just wanna stress that tapping a WPA Enterprise network in either the indicator list or System Settings list will not work right now. _just_ the "Connect to hidden network…" :))
[15:06] <davmor2> jgdx: Yeap I got that one earlier fingers crossed I hit no issues :)
[15:24] <anpok_> trainguards: ping
[15:24] <sil2100> anpok_: pong
[15:25] <anpok_> in silo-004 .. the vivid version of gtk+3.0 still fails to buil
[15:25] <anpok_> d
[15:25] <anpok_> not sure whats wrong
[15:26] <Laney> anpok_: looks built to me... what are you seeing?
[15:26] <anpok_> https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/240/console
[15:27] <anpok_> ah
[15:27] <anpok_> Laney: I thought you only uploaded a source package - and it still needs building
[15:27] <Laney> did you reconfigure the silo after you removed the MP from it?
[15:27] <anpok_> yes
[15:27] <Laney> it shouldn't try to build it
[15:28] <anpok_> so for those packages I cannot rebuild them within the silo?
[15:28] <Laney> sil2100: can you help please?
[15:28] <sil2100> On it
[15:28] <Laney> thanks!
[15:29] <Laney> AlbertA: should I upload a gst-bad package to the silo?
[15:29] <Laney> the MP was probably made before I hacked around it in the archive
[15:29] <Laney> (can you link me to it?)
[15:31] <sil2100> btw. I don't see glmark in the silo, was it already uploaded?
[15:31] <anpok_> sil2100: not yet..
[15:31] <sil2100> Ok
[15:32] <anpok_> it only needs rebuilding
[15:32] <anpok_> (glmark2 - no source changes are needed for 0.14.0)
[15:32] <AlbertA> Laney: I'll prepare one... so I just base it on top of this branch? https://code.launchpad.net/~ubuntu-branches/ubuntu/wily/gst-plugins-bad1.0/wily
[15:35] <Laney> AlbertA: No need to use bzr, I think that you should be able to download gst-plugins-bad1.0 and revert my changes from ubuntu6 (except the changelog), then get it uploaded to the silo.
[15:35] <sil2100> anpok_, Laney: we should be good once this watch_only build finishes, had to change some parameters
[15:35] <Laney> nice, thanks
[15:36] <anpok_> great
[15:40] <sil2100> Ouch
[15:40] <sil2100> Ok, on it again
[15:42] <sil2100> anpok_: you know that qtmir and platform-api fail to build on the PPA currently?
[15:42] <anpok_> sil2100: I wam waiting for silo-13 with platform-api
[15:43] <anpok_> hm qtmir should build
[15:43] <sil2100> anpok_: ok, anyway, the silo is good, it just will fail since there are failed packages in it
[15:44] <sil2100> And qtmir-gles didn't get built (which makes sense as qtmir didn't build)
[15:44] <anpok_> ok .. will after qtmir
[16:00] <Laney> AlbertA: Ah, just tried that - it needs code changes too. Over to you, then. A debdiff will be fine at the end. :)
[16:00] <Laney> AlbertA: If you want to file a bug and subscribe me I'll put it in the silo when you come up with it.
[16:01] <Laney> (or if that's the branch you were referring to then give it to me once it's rebased on wily)
[16:02] <AlbertA> Laney: ok will do
[16:02] <Laney> thanks!
[16:09] <sil2100> ^ silo 002 needs QA sign-off still
[16:09] <dbarth> yes, for the vivid leg
[16:19] <mzanetti> traiguards, can I please get a silo for request 5 (in the new tool)
[16:21] <mzanetti> meh... typo. trainguards ^
[16:21] <sil2100> mzanetti: wow
[16:21] <mzanetti> ?
[16:22] <sil2100> mzanetti: ok, so try maybe assigning it by your own :)
[16:22] <mzanetti> ah ok.
[16:22] <mzanetti> wasn't sure if I should...
[16:22] <sil2100> mzanetti: one of the recent changes was that if there's a lot of free silos, you can assign yourself
[16:22] <mzanetti> just figured I should read the whole mail
[16:22] <mzanetti> ah
[16:23] <mzanetti> sil2100, sorry for the noise :/
[16:23] <sil2100> No worries ;)
[16:23] <sil2100> By the 'wow' I meant 'wow, someone is testing the new thing!'
[16:23] <mzanetti> ah :) totally
[16:32] <Laney> AlbertA: ^^^ published, so I'll just upload to wily-proposed direct once ready
[16:33] <AlbertA> Laney: awesome thanks...
[16:50] <ogra_> did we have a new oxide in one of the recent images ?
[16:51] <ogra_> G+ is so slow for me on arale that it sites there with a half drawn screen for 1-2 seconds when scrolling
[16:51] <ogra_> (other webapps too)
[16:57] <sil2100> hm, no, we shouldn't have
[16:57] <sil2100> We'll have one soon though
[16:58] <ogra_> hmm, then it si perhaps something else
[16:58] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/vivid/20150701.changes
[16:58] <ogra_> hmm, looks like oxide though
[17:00] <sil2100> huh?
[17:00] <sil2100> Had to go through security then
[17:00] <sil2100> Yeah, security indeed
[17:00] <ogra_> yeah, i remember brendand asking for it
[17:01] <ogra_> now that i talk about it :P
[17:01] <ogra_> well, it seems a lot slower on arale to me
[17:45] <bzoltan_> jibel:  kalikiana needs to fix the API checker for the i386 gles package and then after it should be OK.  :D
[18:14] <mzanetti> trainguards, please assigne me a silo for row 67
[18:15] <robru> mzanetti: hey, I changed things up so you can assign yourself. try it out ;-)
[18:15] <mzanetti> for that too
[18:15] <mzanetti> I thought only for staging. will try :)
[18:15] <mzanetti> robru, btw, I tried that silo in the staging... seems it didn't build
[18:15] <mzanetti> robru, other then that, seems fine (after you fix the copy/paste things in the form)
[18:16] <robru> mzanetti: staging as the spreadsheet replacement but production already has the "users can assign their own silos" now
[18:16] <mzanetti> also, it doesn't fit on my screen :)
[18:16] <mzanetti> would be nice if that webform would elide labels
[18:16] <robru> mzanetti: what doesn't fit? can you send me a screenshot?
[18:16] <robru> mzanetti: it fits on my screen but then i have ultra-wide hd screen
[18:17] <robru> mzanetti: the only time I've seen it not fit on my screen is when the list of manual sources is huge, makes the page super wide.
[18:17] <mzanetti> robru, http://i.imgur.com/7L6kRVR.png
[18:18] <robru> mzanetti: oh, that status message is really long, I see
[18:19] <robru> mzanetti: yeah for some reason the second row of info I set to forcibly never wrap text. I can't remember why I thought that was a good idea. If I take that out it should fit way better on screen.
[18:20] <mzanetti> robru, not sure if the staging silos are meant to produce proper results... but seems it doesn't build unity. haven't investigated though after I found out it wouldn't give me arm packages anyways
[18:20] <mzanetti> just as feedback for testing that thing
[18:20] <AlbertA> cihelp: looks like landing-013 is stuck in migration. I just see testbed failures on some platform-api rdeps (powerd, qtubuntu-sensors, qtubuntu-gles, location-service2)
[18:21] <AlbertA> cihelp: any ideas?
[18:21] <mzanetti> robru, also, distribution, series etc could perhaps be drop down lists :) I was unsure what to put there tbh
[18:22] <josepht> AlbertA: is that a ci-train silo?
[18:22] <robru> mzanetti: yeah I wouldn't worry about the build to much, the staging ppas are indeed limited compared to production
[18:22] <mzanetti> I figured, but would be nice to minimize room for mistakes
[18:22] <robru> mzanetti: there is a drop-down if you click a second time.
[18:22] <mzanetti> indeed :D
[18:22] <mzanetti> anyhow. the self assigning silos works fine
[18:22] <mzanetti> thanks for that
[18:22] <mzanetti> will be afk for a bit now
[18:22] <robru> mzanetti: thanks for the feedback, I'll be incorporating this & others this week.
[18:23] <mzanetti> yw
[18:23] <AlbertA> josepht: yeah silo 013, published, stuck in migration
[18:23] <josepht> robru: is AlbertA's query above a trainguard thing?
[18:24] <AlbertA> josepht: boottest failures
[18:24] <robru> josepht: nope, it's boottest: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#location-service
[18:24] <josepht> AlbertA: ah, boottest is us
[18:24] <AlbertA> josepht: I'm not exactly sure what is failing (for example: https://jenkins.qa.ubuntu.com/job/wily-boottest-powerd/lastBuild/)
[18:25] <renatu> hey guys I got this error on jenkins: https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/2794/console
[18:25] <renatu> Ursinha, ^^
[18:26] <josepht> AlbertA: I've re-kicked the boottest job
[18:29] <fginther> renatu, Ursinha, looking
[18:29] <renatu> fginther, thanks
[18:31] <dobey> trainguards: ^^ please :)
[18:31] <robru> dobey: try assigning yourself ;-)
[18:31] <dobey> robru: i can do that?
[18:32] <robru> dobey: yeah I made some changes recently, still a little experimental
[18:32] <fginther> josepht, there are a few other boottests for packages in that silo that might need a re-run. Also qtubuntu-gles needs to be manually passed as it's uninstallable on the phone (it produces no armhf binaries, see https://wiki.canonical.com/UbuntuEngineering/CI/Playbook#Boottest:_Generating_a_passing_.result_file)
[18:32] <dobey> robru: what do i need to type into DEST?
[18:32] <robru> dobey: it's ci-train-ppa-service/ubuntu/stable-phone-overlay for the overlay ppa
[18:33] <dobey> ok
[18:34] <dobey> neat it worked
[18:34] <josepht> fginther: is that done on the jenkins slave?
[18:34] <fginther> renatu, the mako that test executed on was in a bad state. I've off-lined the device to recover it and will restart your test request
[18:34] <dobey> thanks robru
[18:35] <fginther> josepht, generating the passing .result file is done from d-jenkins
[18:37] <renatu> fginther, thanks
[18:37] <robru> dobey: you're welcome!
[18:50] <jgdx> davmor2, how's it going?
[18:50] <josepht> AlbertA: the boottest passed on the second run
[18:56] <AlbertA> josepht: ack, though the excuses pages still shows powerd, qtubuntu-sensors, qtubuntu-gles, location-service2 as having failed the boottest
[18:56] <josepht> AlbertA: yeah, we're working through the rest now
[18:56] <AlbertA> josepht: ack thanks!
[19:01] <davmor2> jgdx: meh so I tested a basic setup and that was okay be now I really need to test against a key authenticated system and setting that up has been less than enjoyable but I think I'm getting there now
[19:01] <jgdx> davmor2, key as in private key or cert?
[19:02] <davmor2> jgdx: setting up freeradius for the authentication server and key system so it is like it would be at the unis etc
[19:03] <jgdx> davmor2, righto, thanks.
[21:12] <dobey> trainguards: uhm, why is the changelog message here so messed up? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-021/+sourcepub/5179892/+listing-archive-extra
[21:13] <robru> dobey: uh
[21:13] <dobey> trainguards: do i need to manually tweak debian/changelog to work around some bug?
[21:14] <robru> dobey: yes if you write your own debian/changelog the train will honor it
[21:14] <dobey> robru: right, i'm just wondering if i *need* to do that here, or what
[21:15] <dobey> i guess "yes, and file a bug somewhere" ?
[21:15] <robru> dobey: yeah I'm not going to be able to fix that soon, that's a giant mess. wow
[21:15] <robru> dobey: two things going on there
[21:16] <robru> dobey: the diff goes all the way back to the beginning because it's the first release targetting stable overlay ppa, that's a known bug
[21:16] <robru> dobey: as for the changelog entry being a giant paragraph of gibberish in a single bullet point, holy crap, I have no idea
[21:16] <dobey> sure i'm not worried about the huge diff
[21:16] <dobey> i'm worried about the bzr info in the one entry
[21:17] <robru> dobey: yeah unfortunately the changelog generation code is some of the least-tested code in the train (part of the last 1% that doesn't have test coverage)
[21:17] <dobey> robru: ok, i'll twaek the changelog manually and rebuild and hopefully that will work around whatever bug this is hitting
[21:18] <robru> dobey: yeah should do. just put the series as UNRELEASED and then the train can still mangle your version numbers (otherwise you're likely to hit the opposite bug where it adds a new changelog entry which is an empty bullet point)
[21:18] <dobey> ok
[21:26] <dobey> robru: btw, does publishing happen automatically when a silo is ready to land, or do i need to run a jenkins job for that?
[21:27] <robru> dobey: no you need me to publish, and it has to go through qa before hitting overlay ppa
[21:27] <dobey> ok
[21:27] <dobey> yeah i know it needs qa. i meant after that stage obviously :)
[21:32] <dobey> robru: ok, the huge diff is annoying, but it looks like tweaking the changelog manually got around the weirdness thankfully.
[21:39] <robru> dobey: yeah that's to do with the overlay ppa. next time you do a release there that'll fix itself.
[21:56] <boiko> robru: couldn't find time today to check the spreadsheet replacement, sorry, I might have some time tomorrow  to check it out
[21:57] <robru> boiko: no worries, I've got lots of feedback already, will be glad to hear yours when you're ready
[21:58] <boiko> robru: in any case, I am glad we are closer to get rid of the spreadsheet already :D
[21:58] <robru> boiko: sooooooo cloooooooose
[21:58] <robru> ;-)
[21:58] <boiko> hehe
[22:07] <boiko> robru: I need your help with vivid silo 44: I did a dual landing of telephony-service already, so the changelog in bzr already has 15.10 stuff
[22:08] <robru> boiko: yeah you can't take something that was landed to wily (either just wily or as a dual) and then land it to vivid.
[22:08] <robru> boiko: you need to either do another dual landing, or do a sync from wily to vivid, or branch trunk for vivid and start a new landing from there
[22:08] <boiko> robru: point is: telephony-service building is currently broken on wily due to a new telepathy-qt5 that has landed there
[22:10] <boiko> robru: but we need to land those critical bugfixes ASAP, even before landing silol 39 (which fixes telephony-service building on wily)
[22:11] <boiko> robru: maybe do a source-only land on vivid and then when telephony-service fixed on wily land the fix on wily too and sync everything back to vivid?
[22:12] <robru> boiko: I don't really understand what the problem is. if your last landing was a dual why not just do another dual? that's the easiest way to get your fix in both places.
[22:12] <boiko> robru: because telephony-service building is broken on wily until silo 39 lands
[22:12] <boiko> robru: but that requires quite some testing time (which we can't afford right now as we need to land the critical fixes for OTA5)
[22:13] <robru> boiko: well if you're really in a hurry, the fastest thing you can do is just do another dual, let the wily build fail, but then you'll have a silo with vivid packages that can be released.
[22:13] <boiko> robru: if we had enough time, I would land silo 39, sync everything back to vivid (including the latest telepathy-qt5), and only then land the critical bugfixes
[22:13] <boiko> robru: oh, can it be done this way?
[22:14] <boiko> robru: question: would the changes be merged back to trunk once the vivid packages get published?
[22:14] <robru> boiko: well yeah we'd have to fudge the silo a bit and delete the wily packages, but it's the only way to trick the train into building vivid packages. it won't let you build vivid packages from a wily trunk, on purpose.
[22:14] <robru> boiko: then once 39 lands properly you can do another dual again to make sure the trunk fixes get to wily.
[22:15] <boiko> robru: well, if changes get merged to trunk, silo 29 will already make sure everything from trunk is on wily
[22:15] <robru> boiko: yep, sounds good
[22:15] <boiko> robru: ok, so could you please change silo 44 to be a dual landing one?
[22:16] <robru> boiko: ok
[22:16] <boiko> robru: thanks :)
[22:17] <robru> boiko: you're welcome, should be ready
[22:22] <jgdx> davmor2, hi, saw you were blocked on config
[22:23] <jgdx> robru, hey, you on duty? :)
[22:23] <jgdx> it's train related
[22:23] <robru> jgdx: yeah officially it's a holiday but I'm around for train stuff
[22:25] <jgdx> robru, okay, so a quick question. davmor2 is testing silo 40, but deferred it to tomorrow to get something set up in the mean time. Silo 40 is a branch from a community member, and he just pushed a couple of trivial fixes.
[22:26] <jgdx> question: is it okay to do another approve and rebuild the silo for dave tomorrow, or should I ask him to uncommit?
[22:26] <robru> jgdx: yeah absolutely you can rebuild...
[22:26] <jgdx> robru, great stuff, thank you.
[22:26] <robru> jgdx: it's entirely up to you, if you want those new commits or not. if they're good fixes then rebuild.
[22:26] <robru> jgdx: you're welcome
[22:33] <jgdx> davmor2, ^ sorry for the noise, but if you upgrade silo 40 on your device tomorrow morning, that'll fix a translation issue in the dialog. :)
[23:24] <greyback> trainguards: could someone please hit reconfigure on vivid+overlay silo0, I needed to change the qtmir branch there
[23:26] <robru> greyback: should work if you do it.
[23:27] <greyback> trying...
[23:29] <robru> greyback: let me know how it goes. I made some changes to the train recently
[23:30] <greyback> robru: worked a treat, nice :)
[23:31] <robru> greyback: you're welcome!
[23:32] <robru> Hmmm
[23:32] <greyback> robru: that error my bad. All is good :)
[23:32] <greyback> or is it
[23:32] <greyback> New version specified (0.4.5+15.04.20150701-0ubuntu1) is less than
[23:32] <greyback> the current version number (0.4.5+15.10.20150617-0ubuntu1)!  Use -b to force.
[23:33] <greyback> think the comparison is the wrong way around
[23:33] <robru> greyback: nope, that error happens when you try to release a wily trunk to vivid.
[23:34] <greyback> robru: aha
[23:34] <greyback> thanks
[23:34] <robru> greyback: you need to either do a dual, or sync from wily to vivid
[23:34] <robru> greyback: you're welcome.
[23:34] <robru> greyback: or branch for vivid
[23:35] <greyback> robru: will keep it vivid only for now. That silo more a demo silo atm