[09:13] <tsdgeos> Mirv: https://code.launchpad.net/~aacid/qtubuntu-media/noprivate/+merge/202708 now passes CI
[09:16] <Mirv> tsdgeos: thanks
[09:16] <Mirv> funny that it failed only on i386
[09:17] <tsdgeos> yeah
[09:17] <tsdgeos> Mirv: should https://bugs.launchpad.net/qtubuntu-sensors/+bug/1271034 be marked as done/invalid ?
[09:18] <Mirv> tsdgeos: it needs that proposed merge included. I just added the note to above since I wrongly linked to that bug in the e-mail and the other bug is now which happens even after my branch would be merged.
[09:18] <tsdgeos> does it?
[09:18] <tsdgeos> i can compile it fine without that one
[09:18] <tsdgeos> with the current qt ppa packages
[09:18] <tsdgeos> well, can't compile it because of the other bug
[09:18] <Mirv> tsdgeos: you might have qtdeclarative-dev installed on your computer otherwise, but nothing in the build deps pulls it in so it fails in cleaner oen
[09:18] <tsdgeos> ahhh
[09:18] <tsdgeos> right
[09:19] <Mirv> and again I'm missing links, hmph. adding some
[09:19] <Mirv> too hasty, too hasty
[09:24] <Mirv> I'm not sure what has changed regarding the location plugin, but I think I can make a temporary build of qtubuntu-sensors without the ubuntu positioning plugin.
[09:24] <tsdgeos> Mirv: ok, added my comment to https://bugs.launchpad.net/qtubuntu-sensors/+bug/1271034 then, not sure i'm really the one to have much opinion on it, but seems logical to me
[09:25] <tsdgeos> Mirv: they added a new virtual you have to implement, i can try returning null in that new virtual, actually we aare already doing that in one of the virtuals so it should "be fine"
[09:25] <tsdgeos> let me make a quick MR
[09:25] <Mirv> tsdgeos: you're probably right. I think Debian started even removing some references from CMake files.
[09:25] <Mirv> tsdgeos: ah just that kind of stuff, I fixed a similar thing somewhere once even.
[09:26] <Mirv> returning null was enough in that some other case too :)
[09:26] <Mirv> thank you
[09:26] <Mirv> tsdgeos: does it need to be #ifdef 5.2/5.0:d?
[09:26] <tsdgeos> i'd say so
[09:27] <tsdgeos> but let me check
[09:27] <tsdgeos> yep it does
[09:34] <tsdgeos> Mirv: https://code.launchpad.net/~aacid/qtubuntu-sensors/newvirtual/+merge/202811 should be it
[09:38] <Mirv> tsdgeos: \o/ in a hangout, will test soonish
[09:38] <seb128> MacSlow, hey, how are you? Could you have a look to https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/1092905 when you have some spare cycle (that's an old bug but it's quite visible since we change the default focus config)
[10:06] <MacSlow> seb128, taking a look
[10:08] <seb128> MacSlow, thanks
[10:32] <MacSlow> seb128, updated the bug with my estimation on what's possibly causing the issue.
[10:32] <seb128> MacSlow, danke
[10:33] <seb128> MacSlow, but the panel has the same size on all screens no?
[10:35] <MacSlow> seb128, sometimes the strut is initially calculated before the panel is visible right after login... best solution would be to always calculate the strut per screen before each notification is put on screen.
[10:38] <MacSlow> seb128, since I'm out of that kind of stuff for some cycles now, I can't easily predict how much effort this is to fix... I want to say maybe have a half a day... but there's something I'm missing I'm sure. Otherwise I would have implemented it back then.
[10:39] <tsdgeos> pete-woods: ping
[10:40] <seb128> MacSlow, can't we just hardcode the high of the panel under Unity sessions? it's a hack but should just work...
[10:41] <MacSlow> seb128, well then we'll get bug-reports from people using non-default font-sizes and people who place their panel not on top etc.
[10:42] <MacSlow> seb128, but despite that... hard-coding would of course work to some extend
[10:42] <seb128> MacSlow, well, I said "in Unity sessions"
[10:43] <MacSlow> seb128, I know :)
[10:43] <seb128> there is no way to changing the panel position there
[10:43] <seb128> well, in any case, do you think you can look at it this cycle?
[10:43] <seb128> if not maybe bregma's team can help?
[10:44] <seb128> MacSlow, but there is probably another bug than the one you describe there
[10:44] <MacSlow> seb128, I'll ask kgunn when he let's me slot this in... hard-coding should not take that much time... compared to the full/robust solution
[10:44] <seb128> MacSlow, I'm using my laptop atm, booted it this morning undocked (so 1 screen) and the volume bubbles go over the panel
[10:45] <seb128> MacSlow, so it's not a "by screen strut" issue
[10:45] <MacSlow> seb128, the desktop-strut is determined upon notify-osd startup... and if notify-osd is started before the panel was visible... that causes the overlap
[10:46] <MacSlow> seb128, and that's the partly-related other bug with desktop-struts
[10:46] <seb128> MacSlow, no, I just restarted notify-osd in my session, still behaving buggy
[10:46] <seb128> so it's not a start order issue
[10:46] <seb128> unity is well in place for some hours and didn't move there :p
[10:47] <MacSlow> seb128, hm... that's new then... odd
[10:48] <seb128> MacSlow, it also works fine if "gsettings set com.canonical.notify-osd multihead-mode no-focus-follow
[10:48] <seb128> "
[10:48] <seb128> MacSlow, it bugs only if I set "focus-follow"
[10:48] <seb128> MacSlow, so seems a bug in the "focus-follow" codepath
[10:49] <seb128> the strut doesn't change by changing the key
[10:49] <seb128> (I'm with 1 screen atm, both config should be equivalent)
[10:49] <MacSlow> seb128, the strut needs to be grabbed dynamically, which is not the case right now iirc
[10:50] <seb128> MacSlow, why?
[10:50] <seb128> that case is "start notify-osd in a started session, with 1 screen"
[10:50] <seb128> the 2 focus cases shouldn't behave differently
[10:51] <MacSlow> seb128, I need to look at the code... I really can't recall the details
[10:51] <seb128> MacSlow, ok, anyway we need to fix it this cycle, we can't release the LTS with the bubbles displayed over the panel
[11:13] <karni> tsdgeos: regarding this [1] - I have no clue, I branched clean and still segfault. [1] https://code.launchpad.net/~unity-team/unity8/new-scopes-vj-integration/+merge/201932
[11:14] <karni> tsdgeos: No other changes, no uncommited changes.
[11:14] <tsdgeos> :S
[11:14] <tsdgeos> karni: what's the backtrace?
[11:14] <karni> tsdgeos: I change to "vertical-journal", click apply, and unity-scope-tool says good bye
[11:14] <karni> tsdgeos: I don't have it. The terminal just spits "Segmentation fault (core dumped)"
[11:15] <karni> where are the core dumps?
[11:16] <tsdgeos> run -g
[11:18] <karni> tsdgeos: excuse me?
[11:18] <tsdgeos> ah
[11:18] <tsdgeos> that's the scope-tool
[11:18] <tsdgeos> not unity8 that is crashing, no?
[11:18] <tsdgeos> or?
[11:18] <karni> unity-scope-tool, yes
[11:19] <tsdgeos> just run it with gdb then
[11:19] <karni> tsdgeos: I can try, but I haven't used it much in my life haha
[11:20] <tsdgeos> just
[11:20] <tsdgeos> gdb binary
[11:20] <tsdgeos> run
[11:20] <tsdgeos> bt
[11:20] <tsdgeos> once it crashes
[11:20] <karni> ok
[11:22] <karni> tsdgeos: hrm. http://paste.ubuntu.com/6802371/
[11:24] <tsdgeos> that is veeeeeeeery weird
[11:24] <karni> tsdgeos: indeed. line 38 of qlimitproxymodelqml.cpp looks fine to me
[11:24] <tsdgeos> karni: do you have a LimitProxyModel whose inner model is itself?
[11:25] <tsdgeos> karni: can you continue the bactkrace to see what's below #13
[11:27] <karni> wtf.. now it doesn't segfault?
[11:27]  * karni retries
[11:29] <karni> to answer your question - no, I don't have limitproxymodel whose inner model is itself
[11:29] <karni> tsdgeos: Well. This is very strange indeed. It no longer segfaults...
[11:30] <tsdgeos> that's the only reason i can find of that the limit model was calling itself
[11:30] <karni> and that's the first time I've seen it _not_ seg fault
[11:32] <karni> tsdgeos: maybe the reason it doesn't segfault is it doesn't seem to be trying to switch to vertical-journal in fact any more.
[11:35] <pete-woods> tsdgeos: hi
[11:35] <tsdgeos> pete-woods: has your branch for the hud stuff landed?
[11:36] <pete-woods> tsdgeos: the changes will actually be to the unity-action-api project, but no, they've not landed yet
[11:36] <didrocks> mzanetti: FYI, I'm going to disable the automerger for unity8 (didn't have a chance to do it before)
[11:36] <didrocks> mzanetti: you will still get feedback on the MP
[11:36] <mzanetti> ah ok
[11:37] <tsdgeos> pete-woods: do you have a link so i can have a look? or still not ready?
[11:37] <pete-woods> tsdgeos: it's all being track here https://bugs.launchpad.net/hud/+bug/1269409
[11:38] <pete-woods> *ed
[11:38] <tsdgeos> pete-woods: so i won't get something like HUD_CLIENT_QUERY_TOOLBAR_UNDO: ?
[11:39] <pete-woods> tsdgeos: it should add the quit entry, just like it used to
[11:40] <didrocks> mzanetti: do not forget to file https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c#gid=1 btw :)
[11:40] <tsdgeos> pete-woods: but what i do for the rest of toolbar icons
[11:40] <tsdgeos> is call hud_client_query_execute_toolbar_item
[11:40] <didrocks> mzanetti: so that I know which components you are looking at
[11:40] <pete-woods> tsdgeos: hmm, it looks like quit was never in that list..
[11:40] <didrocks> (and disable the merge job)
[11:41] <tsdgeos> so i need something like pete-woods: so i won't get something like HUD_CLIENT_QUERY_TOOLBAR_QUIT, no ?
[11:41] <tsdgeos> you sure?
[11:41]  * tsdgeos logs the file
[11:41] <pete-woods> tsdgeos: I will add it, as that's a mistake
[11:42] <pete-woods> tsdgeos: http://bazaar.launchpad.net/~indicator-applet-developers/hud/trunk.14.04/view/head:/libhud-client/toolbar-items.h and http://bazaar.launchpad.net/~indicator-applet-developers/hud/trunk.14.04/view/head:/libhud-client/HudToolbarModel.cpp
[11:43] <tsdgeos> pete-woods: sure, but maybe it was removed?
[11:44] <tsdgeos> yeah
[11:44] <tsdgeos> see https://code.launchpad.net/~aacid/unity/hud_remove_quit_button/+merge/162220
[11:44] <tsdgeos> there used to be a  HUD_CLIENT_QUERY_TOOLBAR_QUIT
[11:45] <pete-woods> tsdgeos: okay, that makes sense
[11:47] <pete-woods> tsdgeos: I've re-added the quit stuff into the HUD client library now, will add an MR to that bug
[11:48] <tsdgeos> oki
[11:52] <karni> tsdgeos: I'm not feeling well, Cc'ed you on an e-mail to my manager.
[11:53] <tsdgeos> karni: take care then :-)
[11:54] <karni> thanks, tsdgeos
[12:45] <Mirv> tsdgeos: ok qtsensors-ubuntu built now in the PPA with the tests disabled, otherwise trunk. the tests failing has a new number bug #1271886
[12:46] <tsdgeos> Mirv: okidoki
[12:47] <tsdgeos> Mirv: fwiw i think i may have a fix for those intel only crashers at https://codereview.qt-project.org/#change,76374 but don't add it to our code yet, want to get more feedback from upstream
[12:47] <Mirv> zsombi also had progress with fixing UI Toolkit problems (I think this, not sure if everything there https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/singletonFix) but had to leave before submitting a merge proposal
[12:47] <Mirv> ok, interesting
[12:48] <Mirv> or well, there is a merge proposal but I guess it's not final one from the looks of it https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/singletonFix/+merge/202610
[12:48] <tsdgeos> yeah
[12:48] <tsdgeos> lots of commented out stuff :D
[13:33] <Mirv> tsdgeos: Saviq: if you want you can upgrade the device to Qt 5.2 using these simple instructions ;) http://pastebin.ubuntu.com/6802938/ (and get a unity8 crasher I think)
[13:34] <Mirv> unity8 seemed to respawning so I stopped it with initctl and saw it crashing when started with 'unity8' as phablet user
[13:35] <Mirv> but that's starting to be it for me for today. lots of nice progress.
[14:00] <tsdgeos> lol
[14:00] <tsdgeos> "simple"
[14:34] <mzanetti> elopio: this is the notes document btw: https://docs.google.com/a/canonical.com/document/d/1fbGNXRQ_tpiprdz2qe3Fk9L_zR-D1SEMCU3rcD-D70U/edit#
[15:08] <cwayne> davidcalle, bon anniversaire!
[15:10] <davidcalle> cwayne, hey, merci ! :)
[15:46] <kgunn> mterry: ping
[15:48] <mterry> kgunn, hi
[15:56] <karni> Mirv: FYI Saviq is on holiday this week.
[15:57] <tsdgeos> Mirv: i tried following those instructions
[15:57] <tsdgeos> died
[15:58] <mhr3> mhall119, btw unity deps finally built in the ppa
[15:58] <mhr3> mhall119, not sure if you noticed
[16:08] <mhall119> \o/
[16:08] <mhall119> thanks mhr3
[16:11] <kgunn> Cimi: ping
[16:11] <Cimi> kgunn, pong
[16:23] <mhall119> mhr3: is everything needed in the ~unity-team PPA now?
[16:23] <mhr3> mhall119, needed for what?
[16:23] <mhall119> to build Unity8 on Saucy
[16:24] <mhr3> should be
[16:24] <mhr3> try :)
[16:24] <mhall119> thanks, I'll update the instructions on unity.u.c
[16:24]  * mhall119 is 70% done with the build already
[16:24] <mhall119> but I have a lot of PPAs too, so I'm not sure if the SDK team PPA is needed or not, for example
[16:25] <mhr3> yea, sdk is needed too
[16:25] <mhr3> unity8 uses components that weren't in saucy
[16:25] <mhall119> ah ha, see, that's the kind of thing that I wouldn't have discovered since I already had it
[16:26] <mhr3> i know only cause i couldn't run unity8 and that was the reason :)
[16:28] <mhall119> works!
[16:28] <mhall119> well, mostly
[16:28] <mhall119> but it builds and runs, and that's what matters most :)
[16:44] <mhall119> now I can finally upgrade to trust :)
[16:45] <mhall119> mhr3: I assume the packages in this PPA will continue getting updated when new revs land in trunk?
[16:51] <mhr3> mhall119, when stuff lands in distro, yes
[17:14] <sil2100> jamesh: hi!
[17:14] <sil2100> jamesh: are you still around?
[17:18] <sil2100> mhr3: hi!
[17:19] <sil2100> mhr3: how can I check through the console if a scope is running?
[17:22] <mhr3> sil2100, which scope?
[17:23] <mhr3> sil2100, but simple answer - query it
[17:24] <sil2100> mhr3: in this case the mediascanner scope
[17:25] <sil2100> mhr3: since again I try releasing it, but after updating the unity-scope-mediascanner, I don't see it working on the dash...
[17:27] <mhr3> sil2100, ls /usr/share/unity/scopes/music/ ?
[17:29] <sil2100> hm, don't see it there
[17:30] <sil2100> mhr3: there's /usr/share/unity/scopes/mediascanner-music
[17:30] <mhr3> sil2100, what extension does it have?
[17:31] <sil2100> mhr3: it's a directory, two files are in there: libmediascanner-music.so  mediascanner-music.ini
[17:31] <mhr3> sil2100, wait, can you do listing of the scope pkg?
[17:31] <mhr3> sil2100, yea, that's "new" scope, that won't show up in the dash now
[17:32] <sil2100> mhr3: but like, it won't work at all?
[17:32] <sil2100> mhr3: since it doesn't seem to work anymore now
[17:32] <mhr3> sil2100, no, the pkg is supposed to have both
[17:32] <mhr3> but maybe something got lost somewhere
[17:32] <mhr3> i'll bring it up on the standup tomorrow
[17:32] <sil2100> mhr3: here it only has the new one, i.e I only see mediascanner-music/ and mediascanner-video/ installed in the package
[17:32] <mhr3> sil2100, proclaim it not working then
[17:34] <sil2100> mhr3: boo... I thought that with the new unity-scopes-api and unity-scopes-shell, the new ones will work fine
[17:35] <sil2100> mhr3: at least that's what I understood when talking with Jussi and Thomas?
[17:35]  * sil2100 could have misunderstood
[17:37] <mhr3> sil2100, they do work fine probably, but we can't switch to new scopes yet... no apps scope etc
[17:38] <sil2100> mhr3: ah, then hm... I wonder why this got marked as 'ready for release'
[17:38] <mhr3> that's why we need to keep the old ones too for now
[17:38] <mhr3> because it was supposed to have both the old and the new
[17:40] <mhr3> i was specifically asking if they are parallely installable and got told that they are
[22:18] <honeybuntu> If I am running ubuntu 12.04.3LTS should I downgrade from 0.9? Compiz keeps crashing inadvertently right after a clean install (3 re-installs generates same scenario; Compiz closed unexpectedly due to error)?