=== biot` is now known as biot
[07:35] <davidcalle> Morning o/
=== _morphis is now known as morphis
[09:14] <tsdgeos> mzanetti: if i loop test launcher i can get qmltestrunner::Launcher::test_quickListMenuOnRMB to fail
[09:14] <tsdgeos> FAIL!  : qmltestrunner::Launcher::test_quickListMenuOnRMB() property visible
[09:14] <tsdgeos>    Actual   (): false
[09:14] <tsdgeos>    Expected (): true
[09:14] <tsdgeos>    Loc: [/home/tsdgeos_work/phablet/unity8/unity8/tests/qmltests/Launcher/tst_Launcher.qml(730)]
[09:14] <tsdgeos> want me to open a bug? try to fix it?
[09:16] <mzanetti> tsdgeos, I can look at it, no prob
[09:17] <tsdgeos> k, i'll open a bug and assign it to you
=== larsu_ is now known as larsu
[10:04] <cimi> pstolowski, did something change recently with scopes dev files? I cannot compile my scope anymore :D missing PreviewQueryBase.h, but the header is still under /usr/include/unity-scopes-3/unity/scopes/
[10:05] <pstolowski> cimi, wily?
[10:05] <cimi> pstolowski, vivid + overlay
[10:07] <pstolowski> cimi, hmm, try a clean build? we did change some packaging stuff
[10:09] <cimi> pstolowski, yeah works after bzr clean-tree, should have done it first
[10:09] <cimi> I just removed some cmake cache files it wasn't enough apparently
[10:10] <pstolowski> cimi, cool
[10:10] <cimi> thanks
[10:11] <pstolowski> yw
[10:14] <cimi> pstolowski, for this dictionary shareUris, what shall I use? QvariantBuilder?
[10:23] <pstolowski> cimi, are you talking about scope impl?
[10:24] <cimi> pstolowski, yeah
[10:24] <cimi> pstolowski, so far I only added strings to a result
[10:24] <cimi> pstolowski, so I was doing like res["myProperty"] = "czesc";
[10:25] <biot> hi all
[10:25] <cimi> pstolowski, but i guess we want to assign a dictionary like a QVariantMap now to myProperty
[10:25] <biot> I'm having some trouble running a custom built unity: "Settings schema 'org.compiz.unityshell' does not contain a key named 'low-graphics-mode'"
[10:25] <biot> is there something I'm forgetting to install?
[10:28] <pstolowski> cimi, i thought you were going to add this shareable dict to a preview widget, no?
[10:33] <pstolowski> cimi, or were cards meant to be shared?
[10:34] <pstolowski> cimi, for cards, just user VariantMap mymap; mymap["prop"]=Variant("ciao"); result["sharable"] = Variant(mymap);
[10:37] <cimi> pstolowski, maybe i was doing something wrong: in the query.cpp file of my test scope, I was adding a shareUris property to the categorisedresult
[10:37] <cimi> pstolowski, then in preview.cpp I had that property mapped
[10:37] <cimi> is there a better way of doing it?
[10:44] <pstolowski> cimi, ah, sure, you can totally do this. nothing wrong with it. i was interested where you want this property at the end (where shell expects it, i.e. if it's a new attribute of an 'image' widget etc)
[10:46] <cimi> pstolowski, maybe inside the image
[10:51] <Saviq> greyback_, hey, you mentioned we have dbus mocking done somewhere, can you point me at the code?
[10:52] <pstolowski> cimi, okay. yeah, so either stuff it in the result and then remap in the preview onto respective attribute of 'image' widget, or populate the attribute when you construct the preview. i think VariantBuilder will only make sens if you want an array of dict tuples, such as with 'audio' widget -see http://bazaar.launchpad.net/~unity-team/unity-scopes-api/trunk/view/head:/src/scopes/PreviewWidget.cpp
[10:52] <pstolowski> cimi, (see the doxygen doc there)
[10:52] <cimi> ok
[10:52] <greyback_> Saviq: hey, I do a tiny bit of it in qtmir, using libqtdbusmock
[10:53]  * Saviq has a look
[10:53] <greyback_> Saviq: petewoods would be able to point you to better users
[10:54] <Saviq> tx
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
=== Guest62641 is now known as balloons
=== ralsina_ is now known as ralsina
[14:54] <mterry> Saviq, is there a bug for the xapps-out-of-lifecycle issue?
=== dandrader is now known as dandrader|afk
[14:57] <Saviq> mterry, don't think so, greyback, kgunn ↑?
[14:57] <Saviq> if not on the card, likely doesn't exist
[14:57] <kgunn> mterry: correct, no bug, just a card
[14:57] <greyback> not that I know of
[14:57] <kgunn> mterry: we did write down some rationale...need to find that
[14:57] <mterry> kgunn, can I have a bit of background for this then?  why is qtcreator called out separately?  it's an xapp right?
[14:59] <kgunn> mterry: https://docs.google.com/document/d/11GWzlGtSzLQcWVnIhwHWjjv5E0KEMtHD4HWkHkhDMrA/edit
[15:07] <mterry> What is the upstream project name for Qt in launchpad?
[15:08] <Saviq> mterry, don't think there is one?
[15:08] <mterry> Saviq, how do we link upstream bugs to LP bugs?
[15:09] <Saviq> mterry, we just put them on package bugs and add a link to qt.io
[15:09] <mterry> Saviq, so we don't have a separation between upstream resolution and package resolution?  odd.  But ok, can do
[15:09] <Saviq> don't think there's more, Mirv ↑?
[15:10] <mterry> Saviq, hrm, package bugs don't let you have external links
[15:11] <Saviq> mterry, by "add a link"... I mean in the description...
[15:11] <mterry> Saviq, ah...  I for sure thought I've seen QTBUG links before
[15:11] <Saviq> mterry, don't get me wrong, we could do much better
[15:11] <mterry> but will do that for now
[15:12] <mterry> tsdgeos, ^ ?
[15:12] <Saviq> but somehow we never cared enough to make it work proper with LP's facilities for external projects
[15:12] <tsdgeos> mterry: qtbase-opensource-src
[15:12] <tsdgeos> https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/
[15:13] <mterry> tsdgeos, that's the package name.  What about the upstream "fake project" name we use to link LP bugs and the upstream bugs?
[15:13] <mterry> tsdgeos, Saviq, if we don't have one, I'll make one.  Super easy  :)
[15:13] <tsdgeos> i open all my upstream bugs there and just put a link :D
[15:13] <tsdgeos> mterry: ask Mirv he's the Qt man
[15:13] <mterry> guh
[15:14] <mterry> tsdgeos, will do
[15:14] <mterry> Mirv, ^ when you get a chance, thanks
[15:28] <Saviq> tsdgeos, dednick, can you have another look at bug #1493530 please
[15:28] <ubot5> bug 1493530 in Canonical System Image "/usr/bin/unity8-dash:6:qt_message_print:qt_message:QMessageLogger::fatal:deallocate:~QString" [Critical,Confirmed] https://launchpad.net/bugs/1493530
[15:29] <Saviq> tsdgeos, it seems as if the stacktrace changed after your comment (at least I can't see the line you commented about)
[15:32] <tsdgeos> Saviq: yeah different stacktrace
[15:32] <tsdgeos> or i commented on the wrong bug
[15:32] <tsdgeos> it could also be :D
[15:33] <tsdgeos> i mean there's still a 0x2
[15:33] <tsdgeos> data (this=0x2) at /usr/include/arm-linux-gnueabihf/qt5/QtCore/qbytearray.h:451
[15:33] <tsdgeos> in #7
[15:33] <tsdgeos> so maybe the stacktrace was bogus and recreated?
[15:34] <Saviq> could be
[15:34] <Saviq> now it just looks like something bassed a 0x0 to UbuntuClipboard
[15:35] <Saviq> but yeah, 0x2...
[15:37] <tsdgeos> well passing a 0x0 to QByteArray UbuntuClipboard::serializeMimeData(QMimeData *mimeData) const
[15:37] <tsdgeos> means instant crash
[15:37] <tsdgeos>     const QStringList formats = mimeData->formats();
[15:37] <tsdgeos> is the first thing
[15:37] <tsdgeos> so yeah
[15:37] <dednick> the this is the bytearray
[15:37] <tsdgeos> it'd be cool to know who called serializeMimeData with a nullptr
[15:37] <dednick> i think the byte array from toLatin1() may have gone out of scope?
[15:37] <tsdgeos> and probably that needs a nice if to not crash
[15:38] <tsdgeos> nah can't be deleted until the memcpy ends
[15:39] <tsdgeos> it's just that this formats comes from calling formats() on a 0x0 mimedata
[15:39] <tsdgeos> so yeah
[15:41] <dednick> tsdgeos: you wanna add the check?
[15:41] <dednick> or want me to?
[15:41] <tsdgeos> i mean the empty data is "valid"
[15:41] <tsdgeos> all the other platforms check for it
[15:41] <tsdgeos>     if (data == 0) {
[15:41] <tsdgeos>         emitChanged(QClipboard::Clipboard);
[15:41] <tsdgeos>         return;
[15:41] <tsdgeos>     }
[15:42] <tsdgeos> inthe qnx one
[15:42] <tsdgeos> xcb has the same
[15:42] <tsdgeos> dednick: whatever you prefer
[15:42] <dednick> tsdgeos: meh. i can add it quick.
[15:42] <tsdgeos> dednick: yours then :)
=== dandrader|afk is now known as dandrader
[16:26] <mhall119> kgunn: so I went and bought myself a bluetooth mouse. It connects easily to my Nexus 4, but it doesn't kick it into windowed mode nor does it show a mouse cursor. I can enabled windowed mode manually with a tweak tool, but is there any way to get the cursor?
[16:26]  * mhall119 is on rc-proposed channel with mir 0.16
[16:40] <greyback> mhall119: mouse cursor not done yet. silo15 should make it visible for you at least
[16:44] <mterry> greyback, so how does qtmir handle xapps today?
[16:44] <greyback> mterry: currently, qtmir doesn't distinguish xmir for any other mir client
[16:45] <mterry> greyback, I see.  Does mir expose the difference and qtmir doesn't do anything with that info, or do they look the same even to Mir?
[16:45] <greyback> mterry: they look the same, even to mir
[16:45] <mterry> hmph
[16:45] <greyback> so I had a chat with ted about this, and here was his suggestion:
[16:46] <greyback> an application's id (appId) is always of the form: app_containerName_versionString
[16:46] <greyback> For legacy app, check it finishes with "0.0" version string.
[16:46] <greyback> Then using liblibertine, check the containerName matches a container.
[16:46] <greyback> Then can assume it a legacy app.
[16:47] <mterry> greyback, OK that's helpful.  Thank you
[16:47]  * mterry goes and plays with some code
[16:47] <greyback> mterry: thing is, I really dislike that approach
[16:47] <mterry> greyback, heh
[16:47] <mhall119> greyback: thanks
[16:48] <mterry> greyback, relying on heuristics rather than a clear metadata tag?
[16:48] <greyback> mterry: I think ubuntu-app-launch library should have a way to tell qtmir (this app is legacy)
[16:49] <greyback> mterry: well UAL launched the xmir app, so presumably it knows the app is an xmir app. It could just tell us that, without us resrting to guesswork
[16:49] <mterry> greyback, yeah.  that feels less magic
[16:50] <greyback> tedg: what say you?
[16:50] <greyback> please read up
[16:51]  * tedg reads backlog
[16:52] <tedg> mterry: greyback: Why do we care wheter it is an X app or not?
[16:52] <mterry> tedg, we want different app lifecycle policies
[16:52] <mterry> tedg, i.e. we want to let X apps run in the background
[16:52] <tedg> So what about apps that use the GTK Mir background but are desktop apps?
[16:52] <mhall119> mterry: are we not going to allow confined apps to run in the background on desktops?
[16:53] <mterry> mhall119, I don't know about that specifically -- I imagine we could allow that just fine.  But the upper layer would know if we're on desktop or not and apply different policies
[16:53] <mterry> mhall119, I'm looking at pocket desktop right now
[16:54] <greyback> tedg: would be good to know things like: is an app click/confined, confined mir native, confined xmir, unconfined..
[16:54] <tedg> mterry: I guess my feeling is that we don't care whether it's "an X app" specifically. We should have a better metric.
[16:55] <tedg> Exactly, we should figure out the types we care about.
[16:55] <tedg> And I'd have no problem putting that funciton into UAL.
[16:55] <greyback> tedg: yeah, I agree just xmir is not a good enough metric
[16:55] <mterry> tedg, I guess by xapps we mean containerized apps, right?
[16:56] <tedg> I guess, I'm curious if we mean that or not. We could, for instance, care about Click apps that are marked for desktop?
[16:57] <greyback> tedg: by xmir we're really meaning desktop apps - irrespective of if they are native mir (like GTK/Qt on Mir) or on XMir
[16:57] <tedg> Not sure if such a thing does/will exist.
[16:57] <mterry> greyback, tedg: so anything that's not a click?
[16:57] <tedg> Well, that would then be browser and system settings as well :-)
[16:58] <greyback> mterry: let's not tie packaging format in to the application type
[16:58] <mterry> tedg, greyback: anything without X-Ubuntu-Touch=true in its desktop file?
[16:59] <mhall119> so non-convergence, non-mobile
[16:59] <mterry> mhall119, right -- both those categories should expect lifecycle management in pocket desktop
[17:00] <mhall119> greyback: well....I may have bricked my phone :(
[17:00] <tedg> mterry: I think this might be worth a mail to a mailing list. I'm guessing more people are gonna weigh in on it.
[17:01] <greyback> mterry: main thing I'm concerned with: if OOM killer kills the app, could it be resumed? We have to assume anything built with our UITK can support that.
[17:01] <tedg> mterry: But, generally, I'm fine putting a function or parameter on a signal for helping Unity make a destinction, we just need to decide what that is.
[17:02] <greyback> tedg: what sort of info can you give us?
[17:02] <tedg> We'd probably also make kenvandine happy if that list of "types" included a scope. For recognizing their appids as well.
[17:03] <tedg> greyback: Depends on requirements. We throw away a lot of metadata right now, but we could keep more if we wanted to.
[17:03] <mterry> tedg, greyback: I assumed that X-Ubuntu-Touch=true was the flag that opts-into our platform -- accepting lifecycle constraints and state saving and all that.  Do you know the origins of that flag and/or if my understanding is wrong?
=== dandrader is now known as dandrader|lunch
=== alan_g is now known as alan_g|EOD
[17:03] <tedg> greyback: For instance when running we only know click/legacy, but that's just because we never need more data. We could track click/legacy/libertine for instance if that was useful.
[17:03] <greyback> mhall119: because of silo15?
[17:04] <tedg> mterry: It was more that we'd list it in the phone scope at first. Not sure why a ShowIn wasn't used.
[17:04] <tedg> mterry: I think it was "has Mir" :-P
[17:04] <mhall119> greyback: likely, I ran the citrain tool to install silo 15, and when it rebooted it wouldn't get past the google splash
[17:05] <greyback> mhall119: ok, silo probably needs rebuild. Sorry about that
[17:06] <mterry> tedg, well if we could trigger off that flag, this test would be easy -- and qtmir would already have the info it needs...  though interpreting that flag that way definitely deserves a mailing list thread to confirm that makes sense
[17:08] <greyback> mterry: on pondering a bit, we may need more granularity than just native mir vs xmir. The term "curated" is in the doc. That sounds more like whitelisting to me
[17:10] <mterry> greyback, well for a pocket desktop focus, there is a curated list of apps that we allow on the image, yes.  But I think the feature is more general -- knowing which apps expect a Touch lifecycle and which don't isn't restricted to a curated list
[17:10] <mterry> We could whitelist and call it a day
[17:10] <mterry> But I imagine scope will grow in future
[17:11] <greyback> mterry: sure, I did say "more granularity" :) The more info the shell gets, the better a decision it can make.
[17:12] <greyback> odds are we'll need to go through all the X apps, and say which is good to be lifecycled, and which is not
[17:12] <mterry> greyback, what's your opinion on interpreting X-Ubuntu-Touch=true as "expects Touch lifecycle"?
[17:12] <greyback> mterry: that's not what it was originally for. It was for filtering the desktop files for ones pointing to touch-supported apps
[17:13] <mterry> greyback, isn't that exactly the test we want?  Touch-supported apps?
[17:14] <mterry> greyback, or are you saying that you expect the desktop files for libreoffice on pocket desktop will have that flag so that they show up?
[17:15] <mterry> i.e. it's a hack to emulate OnlyShowIn
[17:15] <greyback> mterry: well there is that yeah
[17:15] <greyback> but frankly, nothing right now is terribly clear to me
[17:16] <greyback> let's start from the top. We want to exclude certain desktop apps (which may, and may not run via xmir) from lifecycle
[17:16] <greyback> so we need shell to distinguish those
[17:17] <greyback> UAL can probably tell us if app is xmir or not
[17:17] <greyback> and if confined or not
[17:18] <greyback> but that leaves us unable to detect native mir desktop apps (using gtk-mir or qtubuntu_
[17:18] <mterry> Yeah
[17:18] <greyback> and I see no way of doing so, as things currently stand
[17:19] <mterry> Plus, there's the issue of protocol vs platform
[17:19] <mterry> I *could* imagine an app that is Mir-native, but not written for the Ubuntu phone platform
[17:19] <greyback> right
[17:20] <mterry> So I'm back to the need for a piece of metadata that opts into the Ubuntu phone platform
[17:20] <greyback> right
[17:20] <greyback> flag in desktop file, plus UAL reporting xmir or not, is probably all we can do
[17:21] <mterry> greyback, if we have a flag, do we even need xmir detection?
[17:21] <greyback> mterry: I thought of it only to avoid having to edit all desktop files in the world
[17:22] <greyback> but maybe it can be simple opt-in
[17:22] <mterry> greyback, well depends on which flag we pick
[17:22] <mterry> greyback, if we *can* re-use X-Ubuntu-Touch, we get all the desktop edits for free
[17:22] <greyback> mterry: yeah. Who reads that? apps scope?
[17:23] <greyback> would be good to be clear on what it's purpose is
[17:23] <mterry> greyback, I don't know who consumes it or expects it.  I bet the apps scope does.  I can dig a little bit.  And maybe send an email out to ubuntu-phone to ask as well
[17:23] <greyback> that's a plan, yeah
[17:23] <greyback> if we just use desktop file, this task won't take too long
[17:24] <mterry> greyback, yeah that would be nice -- qtmir already reads desktop file right?
[17:24] <greyback> yep
=== dandrader|lunch is now known as dandrader
[17:24] <mterry> sweet
[17:24] <greyback> I guess I'd just prefer all x apps being opted in to lifecycle, and we selectively exclude
[17:25] <mterry> greyback, oh weird.  I wouldn't expect that preference  :)  Why?
[17:26] <mterry> Battery savings I guess?  And you expect breakages to be less common?
[17:26] <greyback> mterry: it's not a well defined opinion yet. But for CPU/responsiveness
[17:26] <greyback> perhaps I'm being too strict tho
[17:26] <greyback> most likely we'll build it and see
[17:26] <mterry> greyback, I guess I just worry that state-saving is not at all standard in X apps like we want
[17:27] <greyback> mterry: sure, but they'll be killed either way :)
[17:27] <mterry> greyback, well I guess a bool flag in the desktop file gives us the choice of being more explicit down the road
[17:27] <mterry> and swapping the default for X apps
[17:27] <greyback> mterry: yeah. We'll expose that info up into unity8, and let it make the call
[17:27] <mterry> greyback, I think we plan to warn in such cases?
[17:28] <mterry> anyway.  First have to see about current flag options
[17:28] <greyback> mterry: one side thing: in UAL, suspend/resume and setting of the OOM score are one operation
[17:29] <mterry> Right.  We were talking in hangout this morning about maybe wanting to separate them
[17:29] <greyback> I would like it
[17:29] <mterry> I don't see any mention in this x-apps-for-pocket-desktop doc about OOM.  Just lifecycle
[17:29] <greyback> so shell could let an app run, but be the first one to die if memory runs low
[17:30] <mterry> I feel like it assumes they are the same and it wants to opt out of OOM too
[17:30] <greyback> mterry: in my book, they're related. You can clarify/make new card if you prefer
[17:30] <greyback> but yeah, one at a time
[17:30] <mterry> I'm all for killing them via OOM too, but I think design would want an opinion on how that's presented to user
[17:32] <greyback> mterry: giant skull & cross-bones on top of the sucker
[17:32] <mhall119> yay, restored my phone, going to use a demo phone for silo experimenting from now on :)
[17:32] <mterry> mhall119, :)
[17:33] <mterry> Maybe just kill Touch apps preferentially, and display a dialog about killing x-apps if it must
[17:34] <greyback> mterry: we can't stop the kernel killing apps
[17:34] <greyback> well, we can influence it's decision with OOM score
[17:34] <mterry> greyback, oh, we can't set a fine-grained policy?
[17:34] <mterry> that's something
[17:34] <greyback> but if it strikes, we can only fix up things afterwards
[17:35] <mterry> I see
[17:35] <mterry> Then yeah, opting out of OOM makes sense for legacy apps
[17:35] <greyback> OOM score is a weighting that the kernel takes into consideration when deciding which process to kill.
[17:36] <greyback> if your app has a high score (i.e. avoid killing it) but is sucking up all memory, the kernel may kill it anyway
[17:37] <greyback> we won't totally opt out processes from OOM (if kernel can't free memory when there's none free, then it'll hang), it's just something we need to try deal with.
[17:37] <greyback> so OOM score is most influence we have on it
[17:38] <mterry> greyback, sure.  "opt out as much as possible"  :)
[17:38] <greyback> yep
[17:47] <mhall119> greyback: yeah, silo15 is pretty busted
[17:47] <mhall119> The following packages will be REMOVED: ubuntu-touch ubuntu-touch-session unity8 unity8-common
[17:48] <greyback> mhall119: ok, thanks. Will try rebuild
[18:14] <mterry> kgunn, bug 1500444 is a data loss bug with patch.  I'd like to squeeze it into OTA7 if possible.  Just saw that freeze got a little delayed.  Wanted to put this on your radar
[18:14] <ubot5> bug 1500444 in qtbase-opensource-src (Ubuntu RTM) "QLockFile won't notice if the lock pid is re-used by an unrelated process" [Undecided,New] https://launchpad.net/bugs/1500444
[18:14] <mterry> kgunn, (data loss in the sense that you can lose your webbrowser-app session)
[18:15] <mterry> I don't know if that's really data or not...  But I believe it saves form content, so I think it would count
[18:23] <mhall119> greyback: strange, my personal phone won't switch to window mode when connected to a mouse, but another Nexus4 with teh same channel and build # does...
[18:25] <greyback> mhall119: oh joy :) Well, let us land the proper mouse support first, then we can investigate
[18:27] <mhall119> greyback: thanks
[18:27] <mhall119> greyback: my first guess would be that it has something to do with the tweak app I used on my personal phone to force it into windowed/staged mode
[18:31] <mhall119> greyback_: I was right, got it working on my personal device with:
[18:31] <mhall119> phablet@ubuntu-phablet:~$ gsettings set com.canonical.Unity8 usage-mode 'Automatic'
[18:32] <greyback_> mhall119: ah, you had it at non-automatic?
[18:34] <mhall119> greyback_: it seems TweakGeek/Ubuntu Touch Tweak Tool will set it to 'Staged' or 'Windowed', and not back to 'Automatic'
[18:34] <mhall119> so anybody who's forced it manually into windowed mode, either using one of those apps or gsettings directly, will need to change it back
[18:34]  * greyback_ shakes fist at mzanetti
[18:35] <greyback_> mhall119: sounds wrong, can you log bug please?
[18:35] <mhall119> anyway, now all I need is that cursor, and I will be a happy camper :)
[18:35] <mhall119> greyback_: log where?
[18:36] <greyback_> mhall119: against qtmir, we'll blame mzanetti and he'll fix his stuff
[18:36] <mhall119> greyback_: it seems like qtmir is just doing what it's told
[18:37] <greyback_> mhall119: sure, but where else can we log it?
[18:37] <greyback_> does tweakgeek have a bugzilla of some kind?
[18:37] <mhall119> greyback_: I'm not sure it's actually a bug, just the fact that I used unsupported methods ot set it to "always be staged"
[18:38] <greyback_> mhall119: you're not wrong, but I'd rather get it fixed than say "unsupported"
[18:38] <mhall119> greyback_: ok, I'm happy to file it as a bug somewhere, just tell me where
[18:38] <greyback_> mhall119: qtmir, and I can follow up
[18:43] <mhall119> greyback_: https://bugs.launchpad.net/ubuntu/+source/qtmir/+bug/1500561
[18:43] <ubot5> Ubuntu bug 1500561 in qtmir (Ubuntu) "Mode switching not automatic if previously set" [Undecided,New]
=== pixel_ is now known as Guest53123
[18:45] <greyback_> mhall119: thanks
=== Guest53123 is now known as pixel_
[18:47] <greyback_> mhall119: I think I misunderstood you, it sounded like tweakgeek was setting that gsetting behind your back. Since you set it yourself, then you're right, there's not much we can do
[18:53] <mhall119> greyback_: that's not true, we can still blame mzanetti
[18:53] <greyback_> oh I fully intend to
=== dandrader is now known as dandrader|afk
[19:28] <kgunn> mterry: is there a patch against vivid+stablephone ppa for that same bug ?
[19:28] <kgunn> the Qlockfile
[19:30] <mterry> kgunn, the wily one should apply
[19:31] <mterry> kgunn, but both wily and overlay have qtbase updates in flight already.  I emailed Mirv to find out the situation
[19:31] <kgunn> mterry: k, i actually assigned to mirv
[19:31] <mterry> kgunn, I filled out a silo request for it (with QA steps), but didn't actually apply for the silo yet
[19:31] <mterry> kgunn, sounds good
[19:32] <mterry> kgunn, I don't know how common it is in practice.  But I hit it today on desktop which made me investigate
[19:32] <mterry> kgunn, and I've felt like I've lost sessions on phone in past
[19:32] <mterry> kgunn, which maybe were this bug
[19:32] <kgunn> yep, annoying enough
[19:34]  * pixel_ ping facebook o_O
[19:34]  * pixel_ he dead?
[19:37] <mterry> pixel_, dead for me too
[19:37] <pixel_> yeah :/
[20:01] <tedg> popey: Facebook is down!
=== dandrader|afk is now known as dandrader