[00:03] <a1fa> hello, where are mouse settings stored for unity?
[07:16] <Saviq> moin
[07:18] <tsdgeos> Saviq: nice bluetooth
[07:20] <Saviq> tsdgeos, yeah, with that (once we migrate) we'll actually be green in CI
[07:20] <Saviq> but
[07:20] <Saviq> tsdgeos, does testSessionBackend pass for you? and for that matter, am I daft or is testLogin1Capabilities there dumb
[07:20] <tsdgeos> Saviq: you have tags in lp:~saviq/unity8/wily-skip-bluetooth
[07:20] <Saviq> tsdgeos, d'oh
[07:20] <tsdgeos> plz ./strip-tags.py lp:~saviq/unity8/wily-skip-bluetooth
[07:21] <tsdgeos> Saviq: code not merged upstream yet, is that because we have not migrated yet?
[07:22] <Saviq> tsdgeos, yeah, KDE (hint hint) clogged our armhf autopkgtest queue
[07:22] <Saviq> tsdgeos, and also boottest unreliable, need someone to kick those
[07:22] <tsdgeos> hmm ok
[07:23] <tsdgeos> it feels weird to have the .deb available but the code not upstream :D
[07:24] <Saviq> well, yeah, that's because migration only happens to wily, vivid just publishes in the ppa
[07:24] <davidcalle> Morning o/
[07:25] <Saviq> tsdgeos, re testSessionBackend ↑, testLogin1Capabilities has a condition to even test anything (dbus iface .isValid()), which seems wrong in the first place
[07:25] <Saviq> but on top of that
[07:26] <Saviq> it talks to the real login1 interface afaict
[07:26] <Saviq> (this test fails for me and failed in migration)
[07:31] <Saviq> yeah I'm declaring these tests broken
[07:33] <Saviq> they only pass on jenkins becuase of the isValid()s
[07:34] <tsdgeos> there's a fire on my street
[07:35] <tsdgeos> if i disconnect is because i've been told to evacuate
[07:35] <tsdgeos> but it's like 4 buildings right, so should be ok
[07:35] <Saviq> yikes
[07:35] <cimi> :D
[07:35] <cimi> only if they as you to evacuate? :D
[07:38] <tsdgeos> well it doesnt' look like at the moment it'll jump to other buildings
[07:46] <tsdgeos_> internet cut for a minute
[07:50] <tsdgeos> Saviq: so, yes testSessionBackend passes here locally
[07:52] <tsdgeos> and the isvalid() returns true to me
[07:52] <tsdgeos> it doesn't for you?
[08:03] <tsdgeos> Saviq: ↑
[08:36] <Saviq> tsdgeos, it does, but I can't hibernate
[08:38] <tsdgeos> Saviq: you mean "in real life"?
[08:42] <Saviq> tsdgeos, which shouldn't make the test fail, but does, but regardless, the test should never talk to my real login1 on the system bus
[08:42] <tsdgeos> agreed
[08:42] <tsdgeos> i mean
[08:42] <tsdgeos> it has it's own bus
[08:42] <tsdgeos> since it's run with dbus-test-runner
[08:43] <tsdgeos> or at least should have, no?
[08:43] <Saviq> but that's only session
[08:43] <Saviq> not system bus
[08:43] <tsdgeos> ah
[08:43] <tsdgeos> ok
[08:43] <tsdgeos> makes sense
[08:43] <tsdgeos> since if not who would be answering those calls :D
[08:43] <tsdgeos> yeah we need a mock
[08:43] <Saviq> yup
[09:32] <Saviq> ltinkl, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1498825
[09:32] <Saviq> morning, btw
[09:38] <duflu> tsdgeos: surfaceItem.surface = null in QML, does that equate to a NULL assignment in the C++ object?
[09:39] <duflu> It looks like we're leaking because of bad QML logic, maybe. Which is something I've never experienced
[09:39] <duflu> Also Mir is buggy too
[09:40] <Saviq> duflu, http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/modules/Unity/Application/mirsurfaceitem.cpp#L570
[09:41] <duflu> Saviq: Thanks
[09:41] <Saviq> duflu, it's the setter that decides what to do with a null passed to it
[09:42] <duflu> Argh. I was fooled by ::MirSurface != qtmir::MirSurface
[09:42] <duflu> They're different things
[09:43] <Saviq> duflu, FWIW null passed from QML is QObject(0x0) in C++
[09:44] <tsdgeos> duflu: surfaceItem.surface = null means  qtmir::MirSurface.setSurface(nullptr)
[09:45] <Saviq> ah right, it's cast before it's printed, hence the QObject(0x0) in the log
[09:45] <Silentlord>  hi how come i don't have com.canonical.Unity.panel, because i have trayicon and it doesn't show and for the google chrome it shows
[09:46] <tsdgeos> actually i think it's mirsurfaceitem
[09:46] <tsdgeos> not mirsurface
[09:46] <tsdgeos>    Q_PROPERTY(unity::shell::application::MirSurfaceInterface* surface READ surface WRITE setSurface NOTIFY surfaceChanged)
[09:46] <tsdgeos> defines the property and the functions backing it up
[09:46] <tsdgeos> in /usr/include/unity/shell/application/MirSurfaceItemInterface.h
[09:46] <tsdgeos> duflu: ↑
[09:47] <Silentlord> i dont have directory shell
[09:48] <Silentlord> sry unity dir i dont have
[09:50] <Silentlord> hi how come i don't have com.canonical.Unity.panel, because i have trayicon and it doesn't show and for the google chrome it shows
[09:51] <Saviq> Silentlord, where are you looking for this?
[09:51] <Silentlord> gsettings get
[09:52] <Saviq> how about 'gsettings list-recursively com.canonical.Unity' ?
[09:52] <Silentlord> com.canonical.Unity integrated-menus false
[09:52] <Silentlord> com.canonical.Unity double-click-activate true
[09:52] <Silentlord> com.canonical.Unity minimize-slow-duration 800
[09:52] <Silentlord> com.canonical.Unity minimize-fast-duration 300
[09:52] <Silentlord> com.canonical.Unity form-factor 'Automatic'
[09:52] <Silentlord> com.canonical.Unity always-show-menus false
[09:52] <Silentlord> com.canonical.Unity home-expanded 'Expanded'
[09:52] <Silentlord> com.canonical.Unity minimize-count 100
[09:52] <Silentlord> com.canonical.Unity minimize-speed-threshold 100
[09:52] <Saviq> Silentlord, use pastebin next time, also, I believe the panel schema is gone these days
[09:53] <Saviq> it was only systray-whitelist there, and that setting's deprecated
[09:53] <Silentlord> so why only my trayicon is not showing
[09:53] <Silentlord> i am using qt
[09:54] <Saviq> I think the new tray protocol wasn't ported to Qt yet
[09:55] <Saviq> sil2100, you were looking into this some time in the past ↑?
[09:55] <Silentlord> no i have just search to try and change the whitelist
[09:55] <Saviq> Silentlord, the whitelist is deprecated
[09:56] <Saviq> it was only there temporarily
[09:56] <Silentlord> so qt applications cannot work with trayicon
[09:56] <Silentlord> ?
[09:57] <sil2100> hmmm, my memory is a bit weary
[09:57] <sil2100> They should, I remember even some recent commits from mitya57 on those
[09:58] <sil2100> Silentlord: works for me here
[09:59] <Silentlord> works for on what app?
[10:00] <sil2100> I have an example Qt app from one of the developers that adds an app indicator to the systray, although I see it's using actually GTK to create the tray menu
[10:02] <Silentlord> no i am using qsystemtrayicon
[10:03] <sil2100> Silentlord: on what series are you right now?
[10:04] <Silentlord> serie?
[10:04] <Silentlord> series?
[10:04] <sil2100> Silentlord: vivid? wily? saucy? etc. ;)
[10:04] <Silentlord> 14.04
[10:05] <sil2100> Ok, that explains it
[10:05] <Silentlord> why?
[10:05] <sil2100> The support for Qt5 systrayicons was added by mitya in wily...
[10:06] <sil2100> Might be a good thing to backport
[10:06] <sil2100> Let me look into SRUing it to 14.04 and 15.04
[10:06] <Silentlord> but i am not using qt5
[10:06] <Silentlord> i am using 4.6
[10:06] <Silentlord> 4.6.1 to be exactly
[10:07] <sil2100> Ah, ok, then it's not my code in that case - but from what I remember in the old appmenu-qt (used for Qt4) systrays weren't really supported
[10:08] <Silentlord> so in qt5 works fine?
[10:09] <sil2100> Silentlord: in Qt5 it only works currently for 15.10 IIRC, but I'll try to SRU the change to the previous series
[10:09] <Silentlord> ok thanks
[12:51] <dandrader> tsdgeos, had a miserable day yesterday trying to have a working setup with a  qt built by myself
[12:51] <dandrader> tsdgeos, have you recently built your own qt?
[12:52] <dandrader> tsdgeos, it used to be a breeze when I did it last year. but now it's pretty broken
[12:53] <dandrader> tsdgeos, by that I mean running apps in a qtbase built with -debug -developer-build
[12:54] <dandrader> ltinkl, replied to you qtmir/mousePointer comments
[12:55] <tsdgeos> dandrader: hmmm, qtbase or declarative?
[12:55] <tsdgeos> dandrader: i built declarative this month, base maybe 2 months ago
[12:55] <dandrader> tsdgeos, both
[12:55] <tsdgeos> didn't have any specially hard
[12:56] <tsdgeos> dandrader: but for base make sure you pass all the long list of options we have in debian/rules
[12:56] <tsdgeos> since otherwise the plugins and stuff won't be found
[12:56] <tsdgeos> dandrader: what problem do you have?
[12:56] <dandrader> tsdgeos, qtbase builds fine with  -debug -developer-build if you keep it in the dir where you built it, which is fine until you try to build a qtdeclarative against it
[12:56] <tsdgeos> sure
[12:56] <dandrader> tsdgeos, qtdeclarative include paths will be fucked up
[12:56] <tsdgeos> but then you don't get the include paths
[12:56] <tsdgeos> correct
[12:57] <tsdgeos> you can try doing some symlinks
[12:57] <tsdgeos> it did work for some of the stuff i tried a while back
[12:57] <dandrader> tsdgeos, but then if I built qtbase with prefix=/usr etc and install it on trunk, its cmake files will miss some things
[12:58] <dandrader> tsdgeos, so you won't be able to build untiy8 with it, for instance
[12:58] <tsdgeos> yeah i'd go with the symlinks first probably
[12:58] <tsdgeos> build with prefix /myhomedir/something
[12:58] <dandrader> tsdgeos, then I resorted to build the package. then it's stream of endless pain
[12:58] <tsdgeos> yeah don't do that, that's very painful
[12:59] <tsdgeos> we can try to figure out what's wrong after the call if you want
[12:59] <dandrader> tsdgeos, symlinks to workaround the wrong include paths is a good idea
[13:00] <dandrader> tsdgeos, at first I was manually changing the header files themselves. but gave up because there are way too many of them to fix :)
[13:48] <Guest2454> uh, webbrowser-app dies with nouveau_pushbuf_data: Asertion `kref' failed. (wily/unity8)
[13:52] <Guest2454> nouveau: kernel rejected pushbuf: no such file or directory
[14:01] <dandrader> Guest2454, I think we all here run it in integrated intel graphics
[14:01] <Guest2454> http://paste.ubuntu.com/12530985/
[14:01] <Guest2454> dandrader: ah, ok :( this started to happen after the last mesa update 0.11 something
[14:01] <Guest2454> today
[14:02] <dandrader> Guest2454, don't think nvidia driver support for mir is in a good shape. might ask in #ubuntu-mir what's the situation
[14:03] <Guest2454> dandrader: ok, thanks for help :P
[15:03] <Saviq> yay it migrated
[15:07] <tsdgeos_> hmmm
[15:07] <tsdgeos_> bad tags?
[15:07] <tsdgeos_> yep
[15:07] <tsdgeos_> cleaning them
[15:07] <tsdgeos_> http://paste.ubuntu.com/12531652/
[15:08] <Saviq> I think that's my fault
[15:08] <Saviq> need to nuke my repo, 'cause it thinks those are fine locally
[15:08] <tsdgeos_> ah you have one of those collocated repos?
[15:08] <tsdgeos_> may confuse it?
[15:12] <Saviq> yeah
[15:18] <Saviq> seb128, is desktop-next preview image/seed a thing still? I seem to recall someone speaking a eulogy to it?
[15:20] <seb128> Saviq, yes, though it's not actively being worked on/changed
[15:23] <Saviq> seb128, is that by design? we could have a good addition to it (proper greeter)
[15:23] <seb128> Saviq, not by design, snappy desktop isn't just a focus atm
[15:23] <seb128> there is too much to do so need to work in priority order
[15:23] <seb128> if you want to pick it up feel free
[15:25] <Saviq> oh there's snappy involved already
[15:26] <seb128> Saviq, oh, right, yes that image is a snappy based one
[15:26] <seb128> we replaced the old desktop-next deb based iso by it
[15:26] <Saviq> josharenson, ↑ so for now that task is moot
[15:26] <seb128> if you just want to target the unity8 desktop session I guess just add a depends/recommends to unity8-desktop-session-mir
[15:26] <josharenson> Saviq: ok, thought so
[15:26] <seb128> https://launchpad.net/ubuntu/+source/unity8-desktop-session
[15:48] <pstolowski> tsdgeos_, mzanetti hey, i've rebuilt silo 4 with inline music playback and everything is now dual-landable
[15:48] <mzanetti> pstolowski, nice!
[15:48] <mzanetti> thanks
[15:48] <pstolowski> yw
[15:49] <tsdgeos_> awesomeness
[15:51] <tsdgeos_> there's so many media-hub & friend silos
[15:51] <tsdgeos_> that i don't even know anymore with what to test silo 4
[15:52] <tsdgeos_> silo 47 supposedly
[15:53] <tsdgeos_> let me see if i can get both of them and then reproduce https://bugs.launchpad.net/ubuntu/+source/qtubuntu-media/+bug/1496736
[16:28] <pmcgowan> tsdgeos_, isnt it 55 you want ?
[16:29] <tsdgeos_> pmcgowan: 47 is what jim said fixes https://bugs.launchpad.net/ubuntu/+source/qtubuntu-media/+bug/1491732
[16:29] <tsdgeos_> i've no idea what 55 does
[16:30] <tsdgeos_> 55 seems to be more about the mpris indicator
[16:30] <tsdgeos_> that is not what i really want to test here
[16:30] <pmcgowan> right ok nm
[16:49] <tsdgeos_> silo 4 doesn't really work
[16:49] <tsdgeos_> will talk with pawel tomorrow
[16:49]  * tsdgeos_ waves
[18:06] <Saviq> dandrader, hey, can you confirm for me that unity8's dependency on qtmir should be > 0.4.6 now?
[18:06] <Saviq> >= I mean
[18:06]  * dandrader checks
[18:07] <Saviq> or should current unity8 work with qtmir pre-0.4.6 (so pre-multi-surface)?
[18:08] <dandrader> Saviq, it's >= 0.4.6 indeed
[18:08] <Saviq> ok so the real problem is that unity-api application is 8
[18:08] <Saviq> but both qtmir and unity8 still are at 6
[18:09]  * Saviq notes to make those automagic
[18:10] <dandrader> Saviq, in debian/control. yeah. The cmake files are updated though
[18:13] <Saviq> where are they even stored in cmake files?
[18:13] <dandrader> Saviq, pkg_check_modules(APPLICATION_API REQUIRED unity-shell-application=8)
[18:13] <dandrader> Saviq, in the root CMake file
[18:14] <Saviq> right
[18:21] <Saviq> dandrader, https://code.launchpad.net/~saviq/qtmir/bump-application-api/+merge/272155 and https://code.launchpad.net/~saviq/unity8/bump-application-api/+merge/272156 please
[18:23] <dandrader> Saviq, done
[18:24] <Saviq> tx, we really need to make those automagic
[18:32] <dandrader> yeah