[08:45] <mzanetti> pstolowski, hey ho
[08:45] <pstolowski> mzanetti, hi!
[08:46] <mzanetti> pstolowski, before our holidays, alecu said something that you were reworking some bits in the scopes middleware
[08:46] <mzanetti> pstolowski, to allow updating single entries, or add/remove stuff without doing a full refresh
[08:46] <mzanetti> did I understand that correctly?
[08:48] <pstolowski> mzanetti, yes. i've a rotting branch to do that for results (for in-card +1 actions that were paused for a while); i've fresh branch that does that for preview widgets - it's MP'ed
[08:49] <mzanetti> pstolowski, cool. just saw a mail on the ubuntu-phone list. people asking if we could update the calendar/clock icons to reflect current date/time
[08:49] <mzanetti> wondering what else is missing
[08:49] <pstolowski> mzanetti, what calendar/clock icons?
[08:49] <mzanetti> in the apps scope
[08:50] <pstolowski> mzanetti, what i implemented is meant for updates triggered by user activity
[08:51] <pstolowski> mzanetti, e.g. user hits a button in the preview, scope does something and updates that button or another widget in the preview
[08:51] <pstolowski> mzanetti, or user taps a small +1 button in the card (result), and we update this result
[08:52] <pstolowski> mzanetti, for continuous updates we would need some sort of backend that triggers them
[08:54] <mzanetti> yeah...
[08:54] <mzanetti> pstolowski, can we then also remove a single app when uninstalling (without refreshing the whole scope)?
[08:55] <pstolowski> mzanetti, nope, the protocol for this enhancement allows updates only. should be relatively easy to support delete, but is it worth it?
[08:56] <mzanetti> pstolowski, definitely... also for adding
[08:56] <mzanetti> the fact that the full scope refreshes all the time is hugely annoying
[08:57] <pstolowski> mzanetti, i think adding is a bit tricky for scope author. he would need to specify where to insert the new item
[08:57] <mzanetti> we should try to diff the content as much as possible and only do full refreshes when there's really no other way out
[08:58] <pstolowski> mzanetti, you're right.. update/add should be handled by model diffs
[08:58] <pstolowski> mzanetti, sorry - del/add
[08:59] <pstolowski> mzanetti, update too though. the update mechanism i implemented is for very specific use case (actions), not for general search
[12:35] <ChrisTownsend> greyback_: Hey!  Is qtmir-desktop a part of the gcc5 transition?  I ask because the Unity 8 desktop is crashing when trying to start with the following: http://pastebin.ubuntu.com/12107481/
[12:35] <ChrisTownsend> greyback_: And qtmir-desktop looks like the only package that has not been updated.
[12:55] <yecril71pl> Nautilus caches the user name that it displays in Permissions.
[12:56] <yecril71pl> The cache is not cleared after I have deleted the user.
[15:20] <Saviq> andyrock, hey, do you remember if there's a bug filed about changing screens when suspended? very often when I resume after having connected my external screen, the lockscreen seems to get stuck mid-way when applying the change and I can't unlock
[15:20] <Saviq> it doesn't crash, but it deadlocks
[15:27] <ChrisTownsend> greyback_: I updated that bug with the requested info:)
[15:27] <greyback_> ChrisTownsend: thanks
[15:28] <ChrisTownsend> greyback_: Sure and thank you
[15:42] <andyrock> Saviq: please fill a bug
[15:43] <Saviq> andyrock, think SIGABRTing it in that case might get you anything useful?
[15:43] <Saviq> through apport?
[15:44] <andyrock> nope
[15:52] <ChrisTownsend> greyback_: I'm pretty sure qtmir needs rebuilding due to the recent gcc5 rebuild for Mir.
[15:53] <greyback_> ChrisTownsend: I thought it was already done tho
[15:54] <ChrisTownsend> greyback_: This is what is on my system:
[15:54] <ChrisTownsend> $ dpkg -l | grep qtmir
[15:54] <ChrisTownsend> ii  qtdeclarative5-qtmir-plugin:amd64                    0.4.5+15.10.20150728-0ubuntu1                         amd64        Qt plugin for Unity specific Mir APIs
[15:54] <ChrisTownsend> ii  qtmir-desktop:amd64                                  0.4.5+15.10.20150728-0ubuntu1                         amd64        Qt platform abstraction (QPA) plugin for a Mir server (desktop)
[15:54] <ChrisTownsend> Old versions.  And I looked at wily-proposed and did not see any qtmir packages there, although I might have overlooked it.
[15:56] <greyback_> ChrisTownsend: I see a newer version of qtmir released in wily:  0.4.5+15.10.20150804.1-0ubuntu1
[15:56] <greyback_> https://launchpad.net/qtmir/+packages
[15:57] <greyback_> sure you've updated? Is something holding back qtmir update maybe?
[15:58] <ChrisTownsend> greyback_: wtf?  I updated a few hours ago.  I'll try it again right now.
[15:59] <ChrisTownsend> greyback_: Ok, still no update to it.  It must be something holding it back.  I wonder what though...
[15:59] <Saviq> andyrock, fyi: bug #1485662
[15:59] <greyback_> ChrisTownsend: you tried dist-upgrade?
[15:59] <ChrisTownsend> greyback_: Yep:)
[16:00] <greyback_> ChrisTownsend: apt install qtmir-desktop=0.4.5+15.10.20150804.1-0ubuntu1
[16:00] <ChrisTownsend> greyback_: It doesn't find that version.
[16:01] <greyback_> ChrisTownsend: well LP thinks there's a newer version available. Lemme try my wily box
[16:01] <ChrisTownsend> greyback_: Ok.
[16:02] <ChrisTownsend> greyback_: It's still stuck in the proposed pocket for some reason: https://launchpad.net/ubuntu/+source/qtmir/0.4.5+15.10.20150804.1-0ubuntu1
[16:02] <greyback_> aha
[16:03] <ChrisTownsend> greyback_: I wonder what's keeping it there though?
[16:03] <greyback_> ChrisTownsend: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtmir
[16:04] <greyback_> boottest fail
[16:04] <ChrisTownsend> greyback_: Great, so how it that get fixed/addressed?
[16:05] <andyrock> Saviq: maybe you can try to debug it using gdb
[16:05] <greyback_> ChrisTownsend: dunno, will have to poke train people
[16:06] <andyrock> just attach gdb to compiz
[16:06] <andyrock> then try to reproduce the bug
[16:06] <andyrock> and see what's going on more or less
[16:06] <greyback_> ChrisTownsend: if wily phone failing to boot, that'll hold qtmir up
[16:06] <andyrock> should be better than SIGABRTing compiz
[16:07] <ChrisTownsend> greyback_: Ok, thanks.  So you'll follow up on that>
[16:07] <ChrisTownsend> greyback_: If you haven't guessed already, I'm kind of needing a Unity 8 desktop session:)
[16:08] <greyback_> ChrisTownsend: sure, but I'm not really focused on wily these days
[16:08] <greyback_> I'll try get things moving there
[16:08] <ChrisTownsend> greyback_: Ok.  I guess Vivid+overlay is not affected by this.
[16:08] <greyback_> ChrisTownsend: correct
[16:09] <ChrisTownsend> greyback_: Ok.  The thing is, I need to test some ubuntu-app-launch changes in a silo that are going to be needed for Vivid+overlay.
[16:10] <ChrisTownsend> And the silo is wily based of course.
[16:10] <greyback_> ChrisTownsend: I imagine this will happen again & again! My solution: 2 machines :)
[16:11] <ChrisTownsend> greyback_: So any help you can give to get the wily qtmir unblocked would be great.
[16:11] <ChrisTownsend> greyback_: Thanks again for looking at this.
[17:00] <dandrader> mzanetti, what's Qt::Key_Backtab?
[17:00] <mzanetti> dandrader, shift+tab
[17:00] <dandrader> mzanetti, weird. is this documented anywhere?
[17:01] <dandrader> don't go!
[17:01] <mzanetti> why is that weird?
[17:02] <dandrader> mzanetti, I find it weird that a key is actually a key combination
[17:02] <mzanetti> dandrader, I think there have been typewriters with this key some 20 years ago :D
[17:03] <mzanetti> and some keyboards actually still print the icon for backtab
[17:03] <mzanetti> http://doc.qt.io/qt-5/qt.html#Key-enum
[17:03] <mzanetti> if you search for backtab in that page it is mentioned quite often (focus-reason etc)
[17:04] <davmor2> dandrader: alt+ ` is the key that flick between instances of applications just press the windows key and view the keyboard layout for documentation ;)
[17:06] <mzanetti> dandrader, also, if you watch "xev" while pressing keys, you'll notice that for instance "ctrl+tab" prints "Control_L and Tab"
[17:06] <mzanetti> dandrader, while pressing shift+tab prints "ISO_Left_Tab" instead of Tab
[17:06] <dandrader> mzanetti, interesting.
[18:54] <dandrader> mzanetti, slight change of channel
[18:54] <dandrader> mzanetti, do you think we should be fowarding key events to the app while you're on the desktop spread?
[18:54] <mzanetti> hmm... probably not...
[18:54] <dandrader> mzanetti, eg: tab key presses, arrow presses
[18:55] <mzanetti> dandrader, are they forwarded right now?
[18:55] <mzanetti> I don't think that makes sense
[18:55] <dandrader> mzanetti, yeah. doing a bigger clean up / refactoring in https://code.launchpad.net/~dandrader/unity8/removeForceActiveFocus/+merge/267020
[18:55] <dandrader> mzanetti, will poke you for a review once it's updated
[18:56] <mzanetti> dandrader, thanks a lot
[19:35] <dandrader> mzanetti, https://code.launchpad.net/~dandrader/unity8/removeForceActiveFocus/+merge/267020 should be good to go now. will give it final look tomorrow morning to make sure
[20:30] <kgunn> ted: hey i was just reading thru bug 1478853 again
[20:30] <kgunn> ted: is gerry correct in that we use "default kernel OOM killer"
[20:31] <ted> kgunn, I believe that it is the "android default" which is slightly different than "linux kernel default" bug generally yes.
[20:31] <ted> kgunn, I think that ogra had some tuning ideas for that though.
[20:32] <kgunn> ted: ok, i think gerry's question/statement isn't quite accurate then
[20:33] <ted> kgunn, So I think that we can make it better, but what we probably need is to look at finding someone to build our own OOM killer that understands our apps.
[20:33] <kgunn> :) sounds simple
[20:33] <ted> kgunn, As we move to systemd they'll be very much the same as systemd apps, so we might find friends there.
[20:33] <ted> kgunn, I'm sure they'll want the same thing.
[20:35] <ted> It isn't generally hard, it's just all heuristic based. So it'll never be perfect. Tests for the cases you care about and be happy :-)
[20:37] <greyback> well my source was https://lwn.net/Articles/317814/ which says android has a "lowmemory" driver. Since the usual oom knobs work, I assumed we weren't using lowmemory
[20:43] <ted> Wonder if it's different based on the different kernels as well.
[20:45] <ted> For instance krillin vs. arale is 3.4 vs. 3.10. Probably wildly different.
[20:45] <greyback> this immediate line of questioninng justifies my comments on the bug! We need somebody to understand this
[20:46] <greyback> I think rumour had it that ricmm or rsalveti was looking into the custom oom killer
[20:46] <greyback> but I do think something wrong with our current OOM killing technique
[20:47] <greyback> if I set something compiling on the device, when memory runs low, dash (foreground app) gets killed first! Why not my thing being compiled? Then unity8 gets killed. My compile continues
[20:48] <ted> Silly greyback phones are not for compiling ;-)
[20:48] <ted> That's because the thing being compiled is a 0
[20:48] <ted> If we want to worry about that we should really pull unity and others < 0
[20:49] <greyback> and we don't do that because?
[20:49] <ted> No reason. Apps on the command line haven't really been a use-case.
[20:49] <ted> But as we go for personal that could make more sense.
[20:50] <ted> Shift everything so that the focused app is 0
[21:02] <greyback> ted: so that means, if any background process (i.e. not in container) has a memory leak, apps & shell are the first to die
[21:04] <greyback> ted: it does appear that the android lowmemory oom killer is on the arale at least, I see it in /sys/module/lowmemorykiller
[21:05] <greyback> I wonder if that's "helping"
[21:11] <ted> greyback, It won't kill the shell as it is zero, it's that their memory sizes will be ranked the same. So if it leaked less memory than the size of the shell but was causing OOM killer to reach the shell could be killed. So it'd have to be a very specific leak. If they went crazy that process would get killed.
[21:12] <ted> greyback, I see the bug on arale, not sure if it is better or worse than on krillin.
[23:57] <a1fa> hello, is there a way to rotate the launcher to the bottom?