[08:32] <tsdgeos> mzanetti: Saviq: so do we have the green light on SDK 1.3? should someone actually review/approve the branch?
[08:35] <mzanetti> I don't know... haven't got any update on the mail thread I asked this a couple of times
[08:41] <tsdgeos> :/
[08:41] <tsdgeos> once they decide it'll be urgent
[08:41] <tsdgeos> i'm seeing it
[08:42] <tsdgeos> Saviq: mzanetti: Mirv: i guess there's decision on what to do with the audio role patches either, right'
[08:42] <Saviq> tsdgeos, I'll talk to Pat today re: 1.3
[08:43] <Saviq> tsdgeos, but yeah, no word on the audio roles yet, mzanetti do you have an idea how public the audioRole property got?
[08:43] <mzanetti> no, not really
[08:44] <mzanetti> well, I've seen the patch is being worked on in akerselva.
[08:44] <mzanetti> but the last status meeting for that was during my holidays.
[08:44] <mzanetti> Mirv, do you know something? ^
[08:44] <Saviq> mzanetti, I meant in Ubuntu
[08:44] <Saviq> as we introduced it before it was upstream
[08:44]  * Saviq fwds thread
[08:45] <mzanetti> right, what's the problem with that?
[08:45] <Saviq> greyback, I wasn't able to reproduce https://code.launchpad.net/~gerboland/qtmir/multimonitor/+merge/272912/comments/694792 with my finger, but it's quite reliable with autopilot, will you have a look?
[08:45] <greyback> Saviq: ack
[08:46] <Saviq> greyback, if I'd have to guess, it's as if it gets tricked on window boundary or some such
[08:47] <Saviq> so when the touch ends exactly on window edge, the event is lost
[08:47] <Saviq> greyback, did you guys talk with alan_g about the protobuf crash?
[08:48] <tsdgeos> mzanetti: the problem is the api is not the same
[08:49] <tsdgeos> and QML not having ifdefs makes our live interestin
[08:49] <tsdgeos> g
[08:49] <mzanetti> ack
[08:49] <greyback> Saviq: not yet. qtmir with simpler shell doesn't exhibit that crash, and the dbus error should be fixed first imo
[08:51] <Saviq> greyback, do we have a plan of attack (mostly asking if we're trying to fix for silo 22 or not)
[08:51] <Saviq> ?
[08:52] <greyback> Saviq: well I am trying to fix it, but it can wait until after silo22. the AP fail will be fixed first
[08:53] <Saviq> ack
[09:01] <Mirv> tsdgeos: Saviq mzanetti: no decision, I'd appreciate a decision though... but it doesn't seem anyone can define what's "public" or not. I doubt bzoltan_ knows that "SDK" has a audio role API in the first place, but I don't know how it'd be marked as "private" either. if we download all store apps we'd know if anything besides clock uses it though.
[09:02] <Mirv> mzanetti: so the problem is that we first patched qtmultimedia in June before submitting it upstream, and it wasn't accepted as is - a good example why upstreaming first should be a priority, but the feature was I guess OTA targeted at the time
[09:02] <Mirv> mzanetti: so now we have the upstream API but current vivid-overlay using our obsolete API
[09:02] <mzanetti> yes, I know that stuff
[09:03] <Saviq> Mirv, I think popey could help us with finding out, popey, could you `grep -r audioRole` on all your installed clicks? :)
[09:03] <Mirv> Saviq: ah :)
[09:04] <mzanetti> but if I read saviq's mail correctly, the problem is already happening in unity alone
[09:04] <mzanetti> and the clock app
[09:04] <mzanetti> as wily and vivid wouldn't switch at the same time
[09:04] <Saviq> mzanetti, yes, but how we deal with it depends on whether it's public or not
[09:04] <Saviq> mzanetti, because if it's not, we can make the switch quietly, in one go, when going to new framework
[09:05] <mzanetti> right.. it's not documented at least...
[09:05] <Saviq> indeed
[09:05] <Saviq> mzanetti, otherwise we need to support both for a period of time and go through a full deprecation process
[09:06] <mzanetti> ok. right... so we'd backport the official upstream patch and change unity and clock if noone else uses it
[09:06] <mzanetti> ok, yes. popey to the rescue here!
[09:07] <Saviq> mzanetti, yeah, and when 5.5 is in a framework, we'd transition there and could drop the 5.4 patch if we still cared about it
[09:07] <mzanetti> yep
[09:08] <mzanetti> yeah, let's see if our assumption is correct (that noone else uses it) and do the switch quietly if so
[09:08] <Saviq> unfortunately unless we get a framework with the 5.4-backported patch, we should support enums both old and new
[09:08] <Saviq> otherwise clock will break for people
[09:08] <popey> wat
[09:09] <popey> okay
[09:09] <mzanetti> popey, can you please grep through apps and see if someone uses the role property on Audio or SoundEffect elements
[09:09] <Saviq> grep -r audioRole
[09:10] <Saviq> mzanetti, you've a commented out line in MvM btw ;)
[09:10] <mzanetti> I'm sure there are
[09:10] <Saviq> mzanetti, tsdgeos, zbenjamin bug #1508363
[09:11] <tsdgeos> k
[09:11] <mzanetti> Saviq, yeah... I think I've tried that roles stuff as an outcome of the bug reports but as you know, don't think it makes sense to use in apps
[09:12] <mzanetti> unless it's the alarm app
[09:12] <mzanetti> curios how I ended up using the enum... back then it should've been the string version, no?
[09:13] <popey> Saviq: mzanetti running now, takes a while
[09:13] <mzanetti> popey, cool, thanks a lot
[09:14] <Saviq> mzanetti, we have enums, too, just different ones
[09:18] <Saviq> popey, could also use your input on bug #1508363 - whether I've missed an app we should take care of
[09:19] <popey> haha, you're going to incur the wrath of s eb128 :)
[09:20] <Mirv> mzanetti: old patch http://anonscm.debian.org/cgit/pkg-kde/qt/qtmultimedia.git/patch/?id=d5149eefcd093d96be3191d5f8a7f622f788e1f4 new patch http://anonscm.debian.org/cgit/pkg-kde/qt/qtmultimedia.git/plain/debian/patches/Add-audio-role-API-to-QMediaPlayer.patch?h=ubuntu
[09:21] <zbenjamin> Saviq: thx
[09:22] <Mirv> Saviq: mzanetti: jhodapp mentioned something about "as long as it maps to same pulseaudio role" (or something), is there something that needs to be takent into account for mapping from old role to new role? I mapped AlertRole -> NotificationRole in my qtubuntu-camera and qtubuntu-media MP:s
[09:22] <popey> Saviq: mzanetti only 3 apps use audioRole, mvm, clock, dropping letters.
[09:22] <mzanetti> popey, mvm has it commented out...
[09:22] <Mirv> popey: thanks! and isn't mvm's commented out?
[09:23] <popey> I didn't grep for that
[09:23] <popey> just for the existence of audioRole anywhere in the source
[09:23] <Mirv> dropping letters does use it, as does clock
[09:24] <Mirv> dropping letters might be erronous I think
[09:24] <mzanetti> yes
[09:24] <mzanetti> popey, is dropping letters in your lordship?
[09:24] <popey> yeah
[09:24] <Mirv> mzanetti: so I could offer an MP to remove the audio role usage?
[09:25] <popey> yeah, if there's a merge for dl I can deal with it
[09:25] <mzanetti> ack, we'll drop it from there...
[09:25] <Saviq> ok so looks like we've a plan
[09:25]  * Saviq replies to thread
[09:28] <Mirv> popey: https://code.launchpad.net/~timo-jyrinki/dropping-letters/drop_audiorole_usage/+merge/275150
[09:30] <popey> that was quick :)
[09:31] <mzanetti> so that means we've to land unity8, clock and qt in one silo soon. Mirv, are you preparing that too?
[09:31] <popey> bad timing
[09:31] <popey> we literally uploaded clock to the store yesterday
[09:32] <Saviq> mzanetti, not *that* easy
[09:32] <mzanetti> heh... popey not happening really soon
[09:33] <Saviq> mzanetti, clock is a click, there's no fwork for it to depend on
[09:33] <mzanetti> oh right... clock is a click
[09:33] <popey> ok
[09:33]  * Saviq types an email right now
[09:33] <Mirv> mzanetti: regarding silo, also qtubuntu-media and qtubuntu-camera. the clock is the problem.
[09:34] <mzanetti> I'm actually wondering where the clock uses this role... I thought it uses the Alarms api which would then set the role implicitly...
[09:34] <Mirv> I wonder if we could bypass the problem by doing some special trick in Clock where it _does_ detect the API version at runtime
[09:34] <Mirv> even thought QML per se doesn't have #ifdef
[09:34] <mzanetti> yeah... should be possible with a loader I'd think
[09:35] <mzanetti> ah, it uses it for demoing the alarm ringtone
[09:35] <Mirv> because that would skip the need for supporting two API:s at the same time and _still_ not being 100% sure everyone has upgraded to OTA+2 before updating the clock
[09:35] <mzanetti> fair enough I guess...
[09:35] <Mirv> mzanetti: but Alarm api apparently doesn't use the Qt role api anyway?
[09:36] <Mirv> mzanetti: hmm.. yeah, I guess it's fair enough if one has phone muted but wants to preview alarm sounds anyway
[09:36] <mzanetti> actually... thinking of it... I'm not so sure...
[09:36] <Saviq> mzanetti, don't think it's possible
[09:37] <Saviq> mzanetti, or well, we could try to create a component with 5.5 import
[09:37] <mzanetti> if I have my phone in silent mode, the preview probably shouldn't ring, while the actual alarm should... but maybe that's just me... there's a discussion on this on the ML
[09:37] <Saviq> and fall back to the 5.4 component
[09:37] <Saviq> as the new import should fail
[09:37] <mzanetti> would need to try
[09:37] <Saviq> mzanetti, please have a look, that would simplify our lives a lot
[09:38] <mzanetti> as it's an enum we might could make it might fail compilation
[09:38] <mzanetti> and catch that with a loader's error state
[09:38] <mzanetti> will do
[09:39] <Saviq> mzanetti, yeah, but one enum is in 5.0/5.4 import, the other on 5.5
[09:39] <Saviq> so this is what we need to hinge on
[09:39] <Saviq> whether 5.5 import succeeds
[09:42] <Mirv> Saviq: my first thoughts are always a shell script that sed:s the qml file before starting qmlscene :) (not sure if click allows a shell script as the file to execute)
[09:43] <Saviq> Mirv, it does, but let's not ;)
[09:43] <mzanetti> :D
[09:57] <Mirv> Saviq: hmm, what about the backport of the patch to qtmultimedia 5.4.2/5.4.1, doesn't the import stay at 5.4 by default?
[09:58] <Saviq> Mirv, doesn't really help because clock needs to be able to depend on an appropriate framework
[09:58] <Mirv> there's also #define QAudioRoleControl_iid "org.qt-project.qt.audiorolecontrol/5.5" in the new patch
[09:58] <Mirv> Saviq: yes, I just mean regarding the detection on which one is in use
[09:58] <Mirv> (and Q_MEDIA_DECLARE_CONTROL(QAudioRoleControl, QAudioRoleControl_iid))
[09:59] <Saviq> Mirv, let's see what we can do
[09:59] <Saviq> Mirv, but anyway, unless it's in both 5.4 and 5.5 on the same import, doesn't really help us
[10:22] <greyback> Saviq: on the qtmir breaking AP thing, it appears AP is sending input events which are physically impossible: on my arale, it sends x=1048.09,y=1920.35 at the bottom of the gesture. QtMir used to pass that to Qt anyway, and I'll make it do that again. But that would need fixing in the AP test
[10:23] <greyback> s/I'll make it/I can make it/
[10:23] <Saviq> greyback, oh interesting
[10:23] <greyback> I think fixing the AP test would be most correct
[10:24] <Saviq> greyback, I actually wonder if that should be "fixing AP", rather than the test
[10:24] <greyback> Saviq: well if you're on desktop, it's ok to drag outside the window.
[10:25] <Saviq> greyback, AP deals with screen, not window
[10:25] <greyback> yeah, good point
[10:25] <Saviq> greyback, not sure it should ever send events outside the screen
[10:26] <Saviq> to emulate the finger better, it should send TouchEnd at screen boundary
[10:26] <greyback> no use comes to mind
[10:27] <greyback> Saviq: I'm going to fix the test and log an AP bug, unless you have objections?
[10:27] <Saviq> greyback, +1
[10:27] <greyback> was that the only AP test I broke?
[10:27] <Saviq> greyback, yeah, didn't see any other
[10:28] <greyback> cool
[10:35] <Saviq> mzanetti, Mirv, http://pastebin.ubuntu.com/12884817/ seems to work
[10:36] <mzanetti> ack
[10:37] <Saviq> mzanetti, we'd need something like this in u8 too, then
[10:37] <Saviq> tsdgeos, #ifdef in QML: http://pastebin.ubuntu.com/12884817/ ;)
[10:37] <tsdgeos> Saviq: he he
[10:38] <tsdgeos> my internet is borked again today :/
[10:38] <Saviq> if something looks stupid but works, it's not stupid
[10:38] <tsdgeos> it just failed when i was donating at https://www.michaeljfox.org/get-involved/donation2.php and then it seems they don't accept spanish cards (or at least i had errors with the three of them)
[10:40] <Saviq> mzanetti, it should probably try 5.5 first, as 5.4 import will work in 5.5 too, just not have the audioRole property
[10:42] <tsdgeos> or should actaully assign the role
[10:46] <cimi> tsdgeos, ping
[10:46] <tsdgeos> cimi: hi
[10:46] <cimi> tsdgeos, so I started doing what you said about the toolbar, then I realised why I didn't share the toolbar code at first sight :)
[10:47] <cimi> tsdgeos, I believe we will add other content there, not just sharing
[10:47] <tsdgeos> right
[10:47] <tsdgeos> so more reason to share it?
[10:47] <cimi> tsdgeos, so what I can do is creating a small toolbar, black
[10:47] <cimi> tsdgeos, and then add the sharing button inside
[10:47] <cimi> it will look quite the same of Rect { black } but under a Toolbar name
[10:48] <tsdgeos> cimi: but why not with the button inside?
[10:49] <cimi> tsdgeos, mmm we can do that too
[10:49] <cimi> tsdgeos, indeed
[10:49] <tsdgeos> cimi: also is really the design "always toolbar on overlapping the content"?
[10:49] <tsdgeos> seems a bit intrusive to me
[10:50] <cimi> tsdgeos, designs are changing.. but so far it seems
[10:54] <tsdgeos> ok
[10:59] <greyback> Saviq: ok so technically AP not at fault here, somehow some floating point noise appears between AP requesting an event, and it appearing to qtmir
[11:00] <greyback> Saviq: how about I make quick workaround in qtmir, and allow time to investigate it properly after?
[11:03] <Saviq> greyback, wfm
[11:11] <Mirv> Saviq: tsdgeos: mzanetti: I went ahead and built qtmultimedia 5.4.2 & 5.4.1 in silo 059 after rebasing the patch to them. I can soon build the qtubuntu-camera and qtubuntu-media MP:s in there, after which it should be testable (by commenting out the two audio role:s in unity8 qml:s) in theory on both wily and vivid. please instruct what needs to be done if you want "5.5" import to work on the 5.4 or som
[11:11] <Mirv> ething.
[11:12] <Mirv> like, if the backports are just backported to 5.4, then they're available via QtMultimedia 5.4 if I'm not incorrect (although I still don't know what needs to be done to use those "revision: 1" properties)
[11:14] <mzanetti> ack, thanks
[11:14] <Saviq> Mirv, I don't think we should change 5.4 at all in this case
[11:15] <Saviq> Mirv, because there's no way for clock app to depend on pre-rebase or post-rebase 5.4
[11:15] <Saviq> Mirv, we should leave 5.4 be, but make all projects work with 5.5 as well
[11:15] <Mirv> Saviq: right, I was wondering about this - so you'd mean we'd actually ship the old API until the rebase on 16.04?
[11:16] <Mirv> I'll keep the silo there in case you change your mind, but ok :)
[11:16] <Saviq> Mirv, until we have a framework for clock app to depend on
[11:16] <Mirv> Saviq: 5.5 is unlikely to land in vivid-overlay (not impossible though, I'll provide a PPA once wily+1 landing of 5.5 is done)
[11:17] <Saviq> Mirv, yeah, that means it won't ever provide a framework higher than 15.04 IIUC
[11:17] <Saviq> Mirv, so yeah, until we have a framework with 5.5, we need to leave 5.4 be
[11:18] <Saviq> Mirv, we *could* rebase 5.4 if we publish a new framework with 5.4 at some point
[11:18] <Saviq> but that wouldn't change much in the "import 5.4 or 5.5" situation, just the enum renames
[11:24] <Mirv> Saviq: right, so those are the options. I guess there's no other downside to waiting for 5.5 than the possibility of some new app(s) starting to use the undocumented API
[11:25] <Mirv> so, we need just patched Unity 8 and Clock before 5.5.1 lands to wily+1
[11:25] <Mirv> and it'd be nice if someone could review https://code.launchpad.net/~timo-jyrinki/qtubuntu-camera/support_new_audiorole_api/+merge/273791 + https://code.launchpad.net/~timo-jyrinki/qtubuntu-media/port_to_new_audio_role_api/+merge/273392 so those could be landed too
[11:25] <Mirv> probably together with the Unity 8
[11:27] <Saviq> Mirv, yup, I think Jim should do the reviews there, no?
[11:28] <Mirv> Saviq: yeah I asked him last week, he said to be doing them "later today" back then :)
[11:28] <Mirv> I need to re-ping him
[11:28] <Saviq> :)
[11:28] <mzanetti> hmm... now there's something odd...
[11:28] <mzanetti> Saviq, so there is "alarm" role and "alert" role
[11:28] <mzanetti> I would think the actual alarm uses the alarm role
[11:28] <mzanetti> so why does the preview then use the alert?
[11:29] <Saviq> I'd say a bug
[11:29] <mzanetti> if so, it's not representative for the actual alarm anyways and probably should just use the multimedia role
[11:29] <Saviq> alert, alarm, close enough to confuse the two
[11:29] <Saviq> mzanetti, I'd say it should use the alarm role
[11:29] <mzanetti> the new api doesn't even seem to have Alert any more
[11:30] <Mirv> mzanetti: I thought the NotificationRole would be the new alert, kind of
[11:30] <Saviq> yeah that's == notification or so
[11:30] <mzanetti> I'm still not sure the preview should actually use the alarm role...
[11:31] <Saviq> bzr qblame and see who added it
[11:32] <mzanetti> nik90
[11:32] <mzanetti> who seems to be mostly away nowadays
[11:33] <Mirv> so, I removed the qtmultimedia again from 059 and building qtubuntu-camera and qtubuntu-media MP:s there instead... and unity8 can be added.
[11:33] <mzanetti> Mirv, I think i'd be easiest if we do the switch with 5.4 -> 5.5
[11:33] <mzanetti> not backporting the new api to 5.4
[11:33] <Saviq> yeah, we discussed this
[11:34] <Saviq> just above
[11:34] <Saviq> no change to 5.4
[11:34] <Mirv> mzanetti: it's the easiest, just need runtime detection for Unity 8 + Clock in addition to those qtubuntu-camera/media landings.
[11:34] <Mirv> I modified the 059 description accordingly
[11:34] <Saviq> mzanetti, the alarm volume is set in the clock app, I'd say it should use that volume when previewing the alarm
[11:35] <Saviq> mzanetti, huh, doesn't alert == ringtone?
[11:36] <Saviq> is anything using the alert role for real?
[11:37] <Saviq> ah
[11:37] <Saviq> ok alert == ringtone
[11:37] <Saviq> but when previewing, somehow ignores silent mode
[11:37] <mzanetti> ...
[11:37] <mzanetti> I tell you...
[11:37] <mzanetti> :)
[11:38] <Saviq> any case, it *should* use the alarm role IMO
[11:41] <greyback> Saviq: https://code.launchpad.net/~gerboland/qtmir/multimonitorAPfix/+merge/275170 - works locally
[11:41] <Saviq> greyback, conflicts?
[11:41] <Saviq> or at least LP got weird
[11:42] <greyback> Saviq: LP confused
[11:42] <greyback> merges locally just fine
[11:42] <Saviq> ugh for the workaround
[11:42] <greyback> I know
[11:43] <Saviq> but ok
[11:43] <greyback> it's emulating previous behaviour
[11:43] <ltinkl> greyback, try the suggestion I posted as a comment, to see if it fixes the test
[11:43]  * ltinkl is curious about the whole method
[11:46] <greyback> ltinkl: nice idea, but the bug is that the QPoint going in is physically outside the window
[11:46] <greyback> the input coordinates that AP injects comes out to QtMir different
[11:47] <greyback> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1508415 the bug I logged
[12:50] <Mirv> jhodapp: hey! could you review/top-approve the qtvideo-node, qtubuntu-camera and qtubuntu-media branches that we talked about last week? I'd like to land the last two before-hand already (they have #ifdef:s so nothing changes for 5.4)
[12:51] <Mirv> I just updated the qtubuntu-media since there were new changes in trunk
[12:52] <jhodapp> Mirv, sure thing...been meaning to do that, apologies for the delay. I'll take a look my afternoon today
[12:52] <Mirv> ok!
[13:13] <cimi> tsdgeos, fixed both issues btw
[13:17] <Mirv> tsdgeos: Saviq: mzanetti: in other news, ok look that beauty https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+packages (while LP hasn't updated yet the published ones). that is, I got Qt 5.5.1 far enough to run on the phone (with audio role hand edited out) so I'm getting rid of the temporary 5.5.1 PPA - 012 will be 5.5.1 from now on.
[13:17] <Saviq> ETOOMANYBUILDS
[13:17] <Mirv> oh f*ck, 22.5GB out of 20.0GB used
[13:18] <Mirv> that means next builds will fail. hmm, I should either reach out or wait for the old ones to be deleted.
[13:25] <greyback> Saviq: consulting with alan_g, suspect that protobuf crash due to mir & mesa on desktop. It's not happening on phone.
[13:25] <Saviq> greyback, oh good
[13:25] <Saviq> greyback, you mentioned a dbus error though?
[13:26] <greyback> Saviq: it's non fatal
[13:26] <Saviq> greyback, silo 22 is rebuilding right now, unless something else big jumps out at us, I wanna make ready for QA this evening
[13:26] <greyback> Saviq: sounds good to me
[13:31] <tsdgeos> the dependent branches link in launcphad has been fixed \o/
[13:31] <tsdgeos> and then unfixed :?
[13:32] <tsdgeos> i guess they found a regression :/
[13:37] <Saviq> ok I need food
[14:28] <greyback> tsdgeos: did you ask once where the "QThread: Destroyed while thread still running" log message was coming from? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1508485
[14:33] <tsdgeos> greyback: didn't ask, i know where it comes, just saying we should fix it :D
[14:33] <greyback> tsdgeos: lol ok
[14:33] <greyback> well we have a bug now!
[14:33] <greyback> so it's as good as fixed :D
[14:33] <tsdgeos> \o/
[14:34] <bloomandivy> how do i find unity on my ubuntu desktop computer by chance?
[14:35] <greyback> bloomandivy: what do you mean "by chance"?  Had you removed unity, and it was re-installed?
[14:35] <bloomandivy> i don't know, i got the computer from someone and don't know where it would even be located
[14:36] <greyback> bloomandivy: "unity" is the name of the default desktop shell, which is the thing you see after you log in.
[14:36] <greyback> unless your computer was customized to use a different one
[14:37] <bloomandivy> oh that isn't pulling up, maybe it was uninstalled....hmm
[14:37] <bloomandivy> let me see if i can download it from ubuntu software center
[14:41] <greyback> it's possible to have several desktop shells installed (like gnome3, kde...). You get to choose which one at the log-in screen - see here: http://www.linuxnov.com/wp-content/uploads/2012/02/Unity-Greeter-0.2.1-LightDM-Ubuntu-12.04-LTS-Precise-Pangolin.jpg
[14:42] <bloomandivy> thanks
[14:52] <tsdgeos> hmmm, guys what's your opinion on this? https://code.launchpad.net/~aacid/unity8/fix_cropped_image_binding_loop/+merge/275199
[14:52] <tsdgeos> it fixes the binding loop by removing the binding :D
[14:53] <tsdgeos> i guess it's a bit more performant since it doesn't need to print out stuff
[14:53] <tsdgeos> mzanetti: Saviq: cimi: ↑↑↑
[14:54] <mzanetti> well, +1 for removing a warning... not so much for the verbosity of the code... but if it works, I guess I'm ok with it
[15:09] <Saviq> tsdgeos, it's a shame, QML should just deal with that
[15:09] <tsdgeos> actaully the old code had a loop indeed
[15:10] <tsdgeos> in which changing one value had the effect of changing that value
[15:10] <tsdgeos> but then i changed the code to
[15:10] <tsdgeos> readonly property bool useHeight: (implicitWidth / implicitHeight) > (width / height)
[15:10] <tsdgeos> which doesn't really loo
[15:10] <tsdgeos> p
[15:10] <tsdgeos> and still complained
[15:10] <tsdgeos> but oh well
[15:11] <Saviq> indeed
[15:12] <Saviq> dandrader, greyback, I still see a hang on exit in silo 22, maybe not as reproducible, and I think limited to krillin atm, but still happens
[15:13] <greyback> Saviq: logs and a backtrace would be good
[15:13] <Saviq> greyback, yeah, as soon as ap completes
[15:18] <tsdgeos> basically this also has the binding loop warning
[15:18] <tsdgeos> http://paste.ubuntu.com/12886275/
[15:18] <tsdgeos> which is "true"
[15:18] <tsdgeos> looks like a loop
[15:18] <tsdgeos> but it isn't
[15:19] <Saviq> well, yeah, QML treats everything that means it has to recalculate itself as a loop
[15:20] <Saviq> so iHeight changes → useHeight changes → iHeight changes →...
[15:20] <Saviq> even if not all of those actually changes
[15:20] <tsdgeos> right, i think it should only complain on the actual "it changes"
[15:27] <tsdgeos> greyback: not sure which explanation to add "don't do this it'll create warnings about a binding loop"
[15:27] <tsdgeos> seems kind of weird
[15:29] <greyback> tsdgeos: it is a bit odd, but you see where I'm coming from.
[15:29] <tsdgeos> i do
[15:29] <tsdgeos> but we have logs
[15:29] <tsdgeos> bzr blame and then read the log
[15:29] <tsdgeos> it'll explain the same as the comment
[15:31] <greyback> sure, is a way to see it. I just like non-obvious code to be explained in the code, not in the history.
[15:31] <ltinkl> Saviq, is it ok when unity8 still wants to remove qtubuntu-sensors when doing ./build.sh?
[15:35] <Saviq> ltinkl, not usually
[15:35] <Saviq> ltinkl, is that with trunk?
[15:35] <ltinkl> Saviq, yup
[15:35] <Saviq> ltinkl, can you paste apt output?
[15:36] <ltinkl> Saviq, haha do you really want it? :) (warning, Czech incoming)
[15:36] <Saviq> ltinkl, I need a laugh today, hit me ;)
[15:36] <Saviq> ltinkl, you can always go $ LANGUAGE=en ./build.sh ;)
[15:44] <Saviq> greyback, dandrader|afk, as you were, can't reproduce of course
[15:45] <greyback> Saviq: don't do this shit to me man!
[15:45] <Saviq> greyback, wait!
[15:46] <Saviq> aaah
[15:46] <Saviq> didn't manage to catch it
[15:46] <Saviq> stupid upstart
[15:46] <Saviq> wonder how am I supposed to prevent upstart from killing it after the timeotu
[15:46] <Saviq> timeout, even
[15:47] <Saviq> here's hoping apport-cli --hanging will do
[15:57] <Saviq> greyback, http://pastebin.ubuntu.com/12886536/
[15:58]  * Saviq gets more symbols
[15:59] <greyback> /usr/lib/arm-linux-gnueabihf/libubuntu_application_api_test.so.3.0.0 <- test mock at fault. Dunno how it's only silo22 that's exposed that
[15:59] <Saviq> greyback, how about http://pastebin.ubuntu.com/12886548/
[16:00] <greyback> a totally different BT. In dbus, ick
[16:01] <Saviq> greyback, might very well be it's a AP-only issue
[16:02]  * Saviq starts u8 normally and sends SIGTERMS
[16:02] <greyback> possibly
[16:03] <greyback> for instance, this could cause a crash, if it's a timing thing: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1508485
[16:03] <greyback> but it's been around for a long while
[16:03] <greyback> it may be qtmir shutting down more correctly is exposing these issues now
[16:10] <Saviq> yeah, can't get it to hang on normal run, calling it test-only issue
[16:46] <Saviq> @unity, please look through your votes and potential missing top-acks on silo 22 https://requests.ci-train.ubuntu.com/#/ticket/445
[16:49] <greyback> Saviq: all branches approved capt'n
[16:49] <Saviq> this thing is looking good
[16:49] <Saviq> *and* it's awesome on an external screen :)
[16:51] <greyback> just mark it ready for QA already!
[16:51] <ltinkl> yes! :)
[16:51]  * greyback has bottle opener hovering over beer
[16:51] <dandrader> ltinkl, https://code.launchpad.net/~lukas-kde/unity8/liveCaption/+merge/273792/comments/695191
[16:51] <ltinkl> argl
[16:52] <ltinkl> dandrader, meaning, I can remove the property and it would still work?
[16:52] <ltinkl> dandrader, or, is it broken now?
[16:52] <dandrader> ltinkl, I mean that it looks this property is not being used. so you can just remove this change
[16:52] <Saviq> yeah, not today though
[16:53] <Saviq> ltinkl, dandrader, please MP with the cleanup, won't rebuild/test again due to that
[16:53] <dandrader> Saviq, well, you asked for us to check our votes on all MPs, right? :)
[16:54] <Saviq> dandrader, sure, I'm just saying what the "fix" is going to be ;)
[16:55] <Saviq> mzanetti, care to change your vote https://code.launchpad.net/~unity-team/unity8/mousePointer/+merge/273369/comments/691465 ?
[16:56] <Saviq> ltinkl, https://code.launchpad.net/~nick-dedekind/unity8/lp1378821.time-translation/+merge/271452/comments/683878 you're Needs fixin' here
[16:57] <Saviq> dandrader, https://code.launchpad.net/~aacid/qtmir/no_double_search/+merge/272707 approve after all? ;)
[16:58] <dandrader> Saviq, just abstained
[16:58] <Saviq> ack
[17:02] <ltinkl> Saviq, done, the issue seems to be resolved
[17:06] <ltinkl> dandrader, also the "property var surface: null" in SurfaceContainer.qml seems unused then
[17:07] <dandrader> ltinkl, maybe
[17:08] <ltinkl> dandrader, well it's used in SessonContainer.qml only, not in SurfaceContainer.qml itself
[17:13] <ltinkl> dandrader, MP updated
[17:14] <ltinkl> dandrader, looking at it again, this could be simplified too: "title: window.title !== "" ? window.title : model.name"
[17:15] <ltinkl> dandrader, window.title has already everything we need
[17:15] <ltinkl> dandrader, ah no, scratch that
[17:16] <ltinkl> dandrader, if the surface name is empty, it will take the name from the app's .desktop file
[17:22] <Saviq> ltinkl, `bzr push -r1953 --overwrite lp:~lukas-kde/unity8/liveCaption`
[17:22] <Saviq> ltinkl, and a separate MP for the cleanup, please
[17:22] <ltinkl> Saviq, ah, ok
[17:22] <Saviq> ltinkl, otherwise I need to rebuild unity8 in silo 22, and I really don't wanna
[17:22] <Saviq> because
[17:22] <Saviq> @unity: silo 22 is a wrap!
[17:23] <ltinkl> yay \o/
[17:23] <ltinkl> Saviq, pushed the revert
[17:23] <ltinkl> Saviq, will file the cleanup tomorrow, feel like EOD today
[17:24] <Saviq> ltinkl, is there an app changing window title, or shall I provide a snippet for testing?
[17:24] <Saviq> ltinkl, sure, cleanup tomorrow's fine
[17:24] <ltinkl> Saviq, browser or system settings
[17:24] <Saviq> ack
[17:24] <ltinkl> Saviq, the latter should change the title when entering a specific module
[17:43] <mzanetti> Saviq, nice!
[17:50] <reverse> hey guys, i was just asking this question in #ubuntu-touch but it seems it's more appropriate here, so i'll ask again: I'm trying to port the multitouch gestures in unity like 3-finger drag + pinch etc. to gnome3/gentoo. So far i have the grail and frame working, but i don't know where to go from here. The launchpad / wiki say that a compiz plugin interacts with the utouch stack to enable the gestures in unity, but the information
[17:50] <reverse> / code on launchpad seems way outdated
[17:51] <reverse> so my question is: how do the gestures actually work in unity currently, and where is the code for it? there doesn't seem to be any up-to-date information on the net
[17:56] <Saviq> Trevinho, if you're around, you'll probably know best ↑
[17:58] <Saviq> andyrock, or you ↑
[17:58] <Saviq> reverse, it might be easier if you post to ubuntu-devel mailing list, most of the folk here are in EU timezones, so EOD by now
[17:59] <greyback> wooo
[17:59] <reverse> reverse, alright, I'll just stick around for a while longer though, maybe someone sees it :) thank's for the heads up though
[17:59] <greyback> Saviq: thanks for all your testing
[18:01] <Saviq> wasn't useless, that's a plus
[18:01] <Saviq> whenever I find an issue after having spent days testing... it's actually a good feeling, to know the time wasn't wasted :P
[18:02] <Saviq> kgunn, if you're not highlighting @, silo 22 is QA-ready
[18:02] <Saviq> and it's aaaaawesoooome
[18:27] <kgunn> Saviq: :)
[18:28] <kgunn> and i like the sdk1.3 tracking bug...great idea
[18:28] <Saviq> seb128, ↑
[18:28] <Saviq> :D
[18:28] <Saviq> kgunn, seb's unhappy about the format (a single bug for many projects == mail spam)
[18:28] <Saviq> but I think it's warranted in this case, and there won't be much discussion on the bug so
[18:29] <kgunn> yeah. if everyone just does there duty...it'll go quiet quickly
[18:34] <Saviq> but we agreed LP needs a better feature for this kind of thing
[18:34] <Saviq> sub-bugs or so
[19:43] <seb128> kgunn, it's still going to send email to every subscriber to any of the source for any of the change to any of the components, it's likely that it's going to be big spamming for devs and that's the sort of spam that leads people to send launchpad emails to a spam folder and not deal with code defect, but of well...