#ubuntu-unity 2012-12-17
<Mirv> can someone check if https://code.launchpad.net/~timo-jyrinki/compiz/blacklist_remove_double_escape_from_xml/+merge/140139 makes sense? seems to work for me, although radeon's natural tear-freeness made it a bit difficult to test for me (plus that I can't actually use the default string but need to modify it for AMD)
<Mirv> ok, it makes sense from setting point of view but apparently not from compiling point of view, unfortunately :(
<Mirv> solvable at least by using just a dot instead, even though of course it means "any character" instead of the actual dot
<mitya57> hi, can anybody please comment on lp:~mitya57/ubuntu-themes/remove-desktop?
<mitya57> more specifically, is (will) there any code that's still using those icons?
<mitya57> s/will/will be/
<mitya57> Laney: they don't reply, so I'll just request their review in the MP
<tuxskar> hello
<davmor2> tuxskar: hello
<tuxskar> someone has ever use "Mago" for test PyGTK apps?
<m000gle> Hi, I just wanted to contact the Unity Team to voice my concern regarding local Dash searches by default being sent to Canonical and/or Amazon for the purposes of returning online search results.
<m000gle> As a user currently living in a country with a less than democratic government, and fairly strong restrictions on the internet, this is a huge problem for me, even if these searches are finally SSL encrypted.  It is also a problem which will make me think twice about using the Unity DE and recommending it to less technically inclined users.
<m000gle> The problem is two-fold:  1. Any dash searches being sent unencrypted essentially become a keylogger and, even if I trust Canonical with my data, becomes a security issue when the "man-in-the-middle" is inevitably watching ... 2. The SSL encryption of searches is problematic if/when Canonical's SSL ports become blocked by government filters, as it could cause the network connection to be dropped for seconds/minutes at a time.
<m000gle> I am well aware of how to disable this "feature", and technical means to get around the government issues, but not all users are.  As such, you should really consider making this "feature" opt-in, as opposed to opt-out, and possibly ask users during installation if they would like in enabled.  Any user who declines would not see the packages/functionality installed in the first place.
<popey> m000gle, you'r better off adding this to a comment on bug 1070598
<ubot5> Launchpad bug 1070598 in unity-lens-shopping (Ubuntu) "Please make the shopping results in the Unity dash opt-in" [Undecided,Confirmed] https://launchpad.net/bugs/1070598
<jrr> how might I disable alpha effects? don't see it in CCSM
<jrr> (based on my experiments dragging windows around, I suspect alpha is responsible for much of the terrible performance I'm experiencing. intel i915.)
<bschaefer> jrr, what you want is blur
<bschaefer> in CCSM, under General -> Dash Blur
<bschaefer> change that to no blur, and you should see some improvements :)
<bschaefer> and if you change that to no blur you'll want to change the Background Color above that setting to have more opacity so things wont be super transparent
<jrr> I see no 'dash blur' (12.10)
<bschaefer> hmm im pretty sure its in 12.10...let me check
<bschaefer> jrr, o its under experimental in 12.10
<jrr> need I disable 'automatic plugin sorting' to get experimental things?
<bschaefer> no, it should be under Unityshell plugin
<jrr> I kind of like conflict handling
<bschaefer> forgot to mention that
<bschaefer> so in CCSM -> UnityShell Plugin -> Experimental -> Dash Blur
<jrr> ah! thanks!
<jrr> s/UnityShell Plugin/Ubuntu Unity Plugin/
<jrr> this seems slightly better
<bschaefer> opps
<bschaefer> Im using an xml file to figure out where it is :)
 * bschaefer is on 13.04
<jrr> although now without the blur it's hard to read text on dash
<jrr> opacity?
<bschaefer> jrr, yes, now look at Background Color
<bschaefer> it is set to 0% opacity
<bschaefer> which should also be under Experimental
<jrr> ah, wunderbar
<bschaefer> yay! it should be a lot faster now :)
<jrr> now, when I drag windows around, they actually track my cursor
<jrr> it was more of a leader-follower relationship before
<bschaefer> haha, that is not good!
<jrr> It's weird to me to see hardware requirements for a linux desktop.. I guess that's the cost of progress
<bschaefer> though you can blame the launcher blur for that, you might be able to get things to go faster if you set the launcher to auto hide as well
<bschaefer> so it doesn't have to keep redrawing it
#ubuntu-unity 2012-12-18
 * bschaefer smspillaz hey, are you around?
<bschaefer> opps
 * bschaefer ments msg haha
<smspillaz> jrr: might be worth giving my branch a try later today
 * smspillaz just got regional updates working again for unity
<sil2100> \o/
<smspillaz> sil2100: these numbers are basically meaningless, but I've seen a 1000fps boost in glxgears
<sil2100> Well, that makes sense, now it finally doesn't redraw everything as it goes meaninglessly again
<davidcalle> sil2100, hi
<larsu> sil2100, hi, sorry for not getting back to you on Friday - I was crazy busy
<larsu> I did try the package with my indicator-appmenu patch, and it works as expected
<larsu> can you tell me again how you're able to still reproduce this?
<larsu> I used this package: lp:ubuntu/raring-proposed/indicator-appmenu
<sil2100> larsu: hello!
<sil2100> larsu: hm, ok, let me try building this specific package - since I was testing on a locally compiled version of  indicator-appmenu  from the staging PPA
<davidcalle> sil2100, nevermind, found my answer :)
<sil2100> larsu: also, it seems to fail on the autopilot testing machines for raring, when using the latest package (i.e. 12.10.4daily12.12.14-0ubuntu1)
<sil2100> davidcalle: hello! Good :)
<larsu> sil2100, hm, that's exactly the one I built... which staging ppa do you mean? I can try the package from there as well
<sil2100> larsu: https://launchpad.net/~unity-team/+archive/staging
<sil2100> larsu: which is strange, since I remember it working before too!
<sil2100> larsu: btw. would you mind trying to run an autopilot tests with your package?
<sil2100> And tell me if it works or not?
<sil2100> larsu: could you add the ppa:autopilot/ppa, install python-autopilot from it, then, bzr branch lp:unity; cd unity/tests/autopilot
<larsu> sil2100, sure
<sil2100> larsu: and finally: autopilot run unity.tests.test_panel.PanelHoverTests.test_hovering_indicators_open_menus
<sil2100> And check if the test fails or not - since if with your package the cursor suddenly goes to some strange position while hovering over the menus, it means there have to still be some hidden indicator entries
<sil2100> larsu: thanks!
<larsu> sil2100, that ppa is not enough, apt-get complains about missing deps:  python-junitxml, python-testscenarios, python-testtools, python-xlib
<sil2100> larsu: hm, those should be in main I think?
<sil2100> In main and universe
<larsu> sil2100, ah sorry, I messed up earlier when force-install indicator-appmenu-tools. Nevermind :)
<sil2100> ;)
<larsu> sil2100, haha watching those tests is awesome!
<larsu> sil2100, it fails though
<larsu> sil2100, so gedit is opened and the cursor moves to open the File, Edit, View, Search, Tools menus, and then it suddenly goes to 0,0
<larsu> then it times out
<larsu> and considers the test failed
<larsu> is this the same failure you were talking about=
<larsu> ?
<sil2100> larsu: yes :|
<sil2100> larsu: when the mouse moves to 0,0, it means that it encountered an empty indicator in-between menu entries, which has some broken x,y coordinates
<sil2100> When you edit unity/tests/test_panel.py, go to test_hovering_indicators_open_menus and simply paste 'print entries' after the list of entries is fetched, you'll get a print-out of the indicators u-p-s is getting through DBus
<sil2100> And there are still those strange empty entries inbetween those proper menu indicators
<larsu> sil2100, ah, that's a different issue from the one I solved, though
<larsu> I mean, the reason those empty indicators are there is different
<sil2100> larsu: any idea why? Since when I dbus-monitor, I also see them being sent through DBus
<sil2100> By one of the libappmenu.so's ;p
<larsu> sil2100, I'm trying to find out right now, but it looks like gedit itself creates those empty menu items
<larsu> and indicator-appmenu doesn't filter those
<larsu> my patch only makes sure that indicator-appmenu doesn't create empty items by itself
<sil2100> larsu: charmap also suffers from this problem
<sil2100> Ah, ok ;)
<larsu> sil2100, really, I don't see empty items in charmap
<sil2100> larsu: since I remember browsing through the sources of gedit and gucharmap and didn't notice any of them adding such empty indicator/menu entries, but maybe those are not planned
<larsu> sil2100, how can I test gucharmap with autopilot?
<sil2100> larsu: uh oh! Wait!
<sil2100> larsu: you're right!
<sil2100> charmap is no longer affected!
<larsu> sil2100, and gedit is affected because it inserts a separator itself. WTF?
<sil2100> So maybe indeed gedit is doing something strange - but this means that your previous patch worked fine
<larsu> why would it do thaT?
<larsu> sil2100, so I could filter out GtkSeparatorMenuItems, but that still wouldn't fix all the cases because apps could still insert normal menu items with a "" label
<sil2100> larsu: anyway, if you would liek to see it in action for charmap, simply edit the test_panel.py I mentioned earlier, search for test_hovering_indicators_open_menus and simply replace "Text Editor" with "Character Map"
<larsu> I think the safest bet is to handle this case in autopilot
<sil2100> larsu: true, I think I will have to simply fix the autopilot tests to filter those out
<sil2100> Yes
<larsu> sil2100, okay, thanks. This won't be a problem anymore once all applications are using GMenuModel
<sil2100> Big thanks! At least now I know why it worked before, since it seems when I was testing your patch, I was using charmap instead of gedit for testing
<larsu> (which might take some time :P)
 * sil2100 feels a bit stupid now ;)
<larsu> sil2100, well, I honestly wouldn't have thought that any app puts separators in its menu bar...
<larsu> sil2100, I could watch those tests all day :)
<sil2100> larsu: just in case you know - is there a way in which the seperators are 'differenciated' from normal menu entries in DBus?
<sil2100> hehe
<larsu> sil2100, sadly not. I'd filter out everything that has a label with an empty string
<larsu> sil2100, and no icon!
<larsu> (otherwise you'll miss the indicators)
<sil2100> Indeed! Ok, thanks again, going to fix all those things now
<larsu> sil2100, very cool. Thanks for all the great testing work you guys are doing!
<MCR1> @all: Hi :)
<MCR1> Top job. Since ages I was suffering from bug 1047232. I do not know which commit exactly fixed it, but it is fixed since I updated Unity today. Great \o/
<ubot5> bug 745707 in Ayatana Design "duplicate for #1047232 Launcher - Launcher should never autohide when the cursor is positioned over the Launcher (e.g. When a spread ends)" [High,Fix released] https://launchpad.net/bugs/745707
<MCR1> https://bugs.launchpad.net/unity/+bug/1047232 -> this is a video showing the bug, which is now fixed, in action: https://bugs.launchpad.net/unity/+bug/1047232/+attachment/3297777/+files/launcherhide.mp4
<ubot5> Launchpad bug 745707 in Ayatana Design "duplicate for #1047232 Launcher - Launcher should never autohide when the cursor is positioned over the Launcher (e.g. When a spread ends)" [High,Fix released]
<MCR1> Also all click-through and minimize/restore bugs, which were recently introduced in lp:compiz (r3513) are fixed. Great !
<MCR1> Place plugin also worx perfectly.
<sil2100> \o/
<MCR1> sil2100: Many people (including myself) mostly come here to complain, but this time I am here to honor you and thank you 4 your top work. Keep it up that way ;)
<gatis> hello, i have this problem, when i use xcb_grab_keyboard on my client i still get Unity "run command" (on Alt) and  seach window (on Windows key)
<gatis> can somebody tell me more, how those parts are implemented in the unity?
<gatis> if i do xcb_grab_keyboard on the screen's root window then i dont get all those unity extras..
<fginther> Trevinho, bschaefer, Can you please take a look at http://paste.ubuntu.com/1447957/? It looks like recent bamf merge broke unity
 * bschaefer swore he compiled unity with that branch MP
<bschaefer> fginther, I can take a look
<fginther> bschaefer, thanks. found your name on the review :-)
<bschaefer> fginther, yup :)
<bschaefer> though it should have just been cleaning up dead code....maybe it wasn't completely dead
<bschaefer> fginther, hmm it looks like that function is used in unity ApplicationLauncherIcon....which im not sure if its needed... Trevinho would know more about this
<bschaefer> fginther, soo im thinking if unity needs it, then we might have to revert that change in bamf
<bschaefer> and re propose the correct fixes in bamf
<fginther> bschaefer, I'm glad to help if I can.
<fginther> bschaefer, thanks for investigating so quickly
<bschaefer> fginther, np, I just got on :)
<bschaefer> fginther, mostly im hoping for Trevinho to magically appear
<bschaefer> but he stayed up late
<bschaefer> fginther, let me prepare a branch to revert that change
<bschaefer> fginther, wait...it didn't merge
<bschaefer> fginther, sorry, I thought it was in trunk bamf merged, and unity was failing to build :)
<bschaefer> fginther, just let Trevinho fix his branch now :)
<fginther> bschaefer, my mistake. I thought the branch had merged also
<bschaefer> no worries :), jenkins caught it
<bschaefer> \o/
<Trevinho> bschaefer, fginther: sorry I was busy
<bschaefer> Trevinho, your branch needs a fixing!
<Trevinho> bschaefer: Oh, that functionality was added recently... I don't think that we need it in unity
<Trevinho> bschaefer: do we need indicators in unity?
<bschaefer> well its used in ApplicationLauncherIcon
<bschaefer> Trevinho, that is what I wanted to ask you :)
<fginther> bschaefer, Trevinho, I'll be afk for a bit. if you need me, just leave a message
<bschaefer> fginther, will do, thanks for pointing that out!
<bschaefer> Trevinho, I just built my unity with it removed and am about to test it
<Trevinho> bschaefer: I think that functionality is in libunity now
<Trevinho> bschaefer: I'll fix unity and all will be fine again
<bschaefer> Trevinho, o really? That would be nice, it just looked like ApplicationLauncherIcon was using that list for that array ...
<Trevinho> bschaefer: yeah... But that was to control the dynamic quicklist that are handled by libunity nowadays
<bschaefer> Trevinho, sweet, I haven't touched those things in a while :)
<bschaefer> ping me when you have a branch that needs a review, then we can get your bamf branch merged!
<Trevinho> bschaefer: ok
<Trevinho> bschaefer: sorry for breackage, I acually tought that the code in unity was removed
<bschaefer> Trevinho, no worries, and I thought I tested unity with that bamf branch!
<bschaefer> Trevinho, jenkins caught it :)
<Trevinho> bschaefer: yeah, nice thing
<Trevinho> bschaefer: https://code.launchpad.net/~3v1n0/unity/remove-bamf-indicators/+merge/140519 I'm also looking to remove something from indicator-application
<bschaefer> Trevinho, cool
 * bschaefer looks at branch
<bschaefer> Trevinho, also your working full time now?
<Trevinho> bschaefer: no, still part-time... But I've changed contract
<bschaefer> Trevinho, o, cool, I just saw you in that email
<bschaefer> Trevinho, well it seems andyrock beat me to the review
<bschaefer> but it compiled here :)
<andyrock> ;)
#ubuntu-unity 2012-12-19
<smspillaz> bregma: you around ?
<smspillaz> bregma: I'm not sure what your view is on encoding Interface/Impl names, if you could clarify that would be great
<smspillaz> Trevinho: ^ would be good to get your thoughts on that
<smspillaz> I know that the style guide document says "use -Interface" but I also know that lots of people hate -Interface
<Trevinho> smspillaz: I'm not sure I got what you mean...
<smspillaz> Trevinho: do you prefer interface classes to be named FooInterface or Foo
<smspillaz> and is that the general preference
<Trevinho> Ah... I'd prefer FooInterface... or AbstractInterface if that's the case
<Trevinho> sorry
<Trevinho> AstractFoo
<smspillaz> Trevinho: AbstractFoo ?
<smspillaz> okay :)
<Trevinho> yeah, sorry :P
<bregma> I prefer Foo as the interface and use the bridge pattern
<smspillaz> no problem, was just looking for what people preferred
<smspillaz> bregma: okay, so whats the verdict :)
<smspillaz> bregma: Foo/FooImpl or AbstractFoo/Foo ?
<smspillaz> (one of the things I don't like about code review is that reviewers almost always disagree on style :))
<bregma> I don't like having structure creep into names in APIs, so I dislike Abstract, and Impl implies a private implementation behind the interface so it should never leak out
<bregma> so I prefer Foo/Foo::Impl
<smspillaz> bregma: Trevinho: what's the verdict then, and can we get this written down somewhere ?
<bregma> yes, I'd like to get it written down
<Trevinho> smspillaz: we have the style docs... they probably should be updated with these things too
<smspillaz> bregma: btw, when you say Foo::Impl, do you mean a subclass? eg, Foo::Impl ?
<smspillaz> erm, class Foo::Impl
<bregma> yes, a nested class
<bregma> using the pimpl idom
<smspillaz> bregma: well, it wouldn't quite be nested
<smspillaz> erm , a pimpl
<smspillaz> bregma: but if you mean something like having the interface class with a static factory method which returns Foo::Impl through its interface then I guess that's okay
<bregma> is the goal not to separate interface from implementation, to allow the implementations and interfaces to vary independently (ie. a Nux implementation, a mock interface)?
<smspillaz> bregma: yes, Extract Interface
<bregma> I think the best approach is to use the pimpl idiom (the bridge pattern) and have the interface class constructor take a factory function that defaults to creating the usual Nux-based implementation
<bregma> a factory function that creates a mock implemntation can be used for the tests
<smspillaz> bregma: that's not a pattern I've seen before, but its somewhat workable (although I'm a bit skeptical of interfaces having constructors)
<bregma> I would really like to see as much nux as possible hidden behind facades
<smspillaz> bregma: actually that could get a little awkward
<smspillaz> if you wanted to create a MockFoo on the stack, that inherited from foo, you'd have to provide a "constructor" which returns a reference to the same thing in order to satisfy the interface constructor
<smspillaz> erm, a "factory function"
<smspillaz> bregma: do you want me to provide a sample of what I'm thinking of so I know we're both on the same page ?
<bregma> it could be a little awkward if it goes too far, but right now it makes testing and maintenance harder because it's almost impossible to reason about functionality when a class has a 10-level inheritance heirarchy, ober 100 member functions, and 50 public member variables
<smspillaz> bregma: I know :)
<smspillaz> bregma: what I'm suggesting is that your method of having the interface class take a factory function is the awkward part
<smspillaz> not the interface itself
<bregma> I disagree, I've used that design before without problems
<bregma> just not with nux and properties and introspection
<smspillaz> bregma: hmm, okay. I'll just hack something together to see if we're both on the same page here
<bregma> I've been playing wit hthe Switcher classes for the last few days for #824965, before I looked at your MP
<bschaefer> smspillaz, hey, when you get a chance, can you take a look at this: https://code.launchpad.net/~brandontschaefer/compiz/lp.1002246-check-valid-strut-windows/+merge/140569
<smspillaz> bschaefer: sure
<bregma> so I'm pretty certain we have the same goals
<smspillaz> bregma: ah, hence the review :)
<bschaefer> smspillaz, thanks, im not sure how I feel about it but its a tough problem to fix
<smspillaz> bschaefer: actually, what was the problem with using ~PlaceWindow ?
<bschaefer> smspillaz, the ~PlaceWindow gets called after the DestoryNotify event
<smspillaz> bschaefer: yep, its supposed to
<bschaefer> which the problem is the DestroyNotfiy is coming into compiz to later
<bschaefer> to late*
<smspillaz> does it come after the countdown timer ?
<bregma> smspillaz, the review was actually because I'm trying to get through the backlog of MPs, it's just a coincidence
<smspillaz> bregma: :)
<smspillaz> bregma: great to see you're doing that
<bschaefer> smspillaz, the count down is super late (The Fallback one)
<bschaefer> smspillaz, which happens after everything
<smspillaz> bschaefer: have you tried bumping up the timer ?
<smspillaz> oh
<bschaefer> hmm no I have not
<smspillaz> well in that case it shouldn't be a problem
<smspillaz> as long as we only ever hit the doHandleScreenSizeChangeFallback code after we get the DestroyNotify for the unity windows
<smspillaz> I mean what should happen is this:
<bschaefer> yeah that is what happens, the fall back is way after the DestroyNotify
<bschaefer> the problem is we collect these windows, then we destroy the window, leaving the destroyed windows in the list
<bschaefer> but the destoryed windows are still valid to compiz, but not the xserver
<bschaefer> until the DestroyNotify comes through
<smspillaz> ConfigureNotify on root window -> Place::handleScreenSizeChange -> strut windows collected -> Unity::handleScreenSizeChange -> unity struts destroyed -> Nondestroyed struts send a PropertyNotify (remove them from list) -> Destroyed struts send a DestroyNotify (-> ~PlaceWindow -> remove from list) -> mStrutWindows should now be zero, call doHandleScreenSizeChange
<smspillaz> bschaefer: right, what I'm trying to say is that you can remove the windows from mStrutWindows and call if (mStrutWindows.empty()) doHandlescreenSizeChange () from within ~PlaceWindow
<smspillaz> PlaceWindow has a private member variable "window", and you just call mStrutWindows.remove (window)
<bschaefer> i tried that and .... hmm
<bschaefer> now im wondering why it didn't work
<smspillaz> The only reason I can see it not working is if the non-destroyed strut windows don't update their struts
<smspillaz> in which case we just do the fallback anyways
<bschaefer> thats what happens, it is destroyed, but compiz holds the struts still, so to compiz the struts are still valid
<smspillaz> however if the DestroyNotify comes before the fallback, then there's really no problem
<bschaefer> until the the destroy
<smspillaz> bschaefer: ah
<bschaefer> I even tried updateStruts()
<bschaefer> but that didn't seem to work either which was odd
<smspillaz> right it will just error out
<bschaefer> yu[
<smspillaz> .. I think
<bschaefer> well
<smspillaz> actually
<bschaefer> it should set it to false if hasNew is false
 * bschaefer has to double check
<bschaefer> its a huge function
<smspillaz> bschaefer: src/window.cpp: after the second XGetWindowProperty
<smspillaz> add an else block after that first if () check
<smspillaz> that sets hasNew to true
<bschaefer> smspillaz, well I would still have to update the list...but instead of doing XGetGeometry
<smspillaz> if both properties fail to be read then we should assume that the window has no struts
<bschaefer> do update struts on each one
<smspillaz> bschaefer: okay, so two things
<bschaefer> smspillaz, is it setting it to false?
<smspillaz> bschaefer: yes
<bschaefer> o there it is
<smspillaz> bschaefer: so first you need to update the list on ~PlaceWindow
<bschaefer> alright
<smspillaz> and second you need to call w->updateStruts () before updating the list
<smspillaz> with that small fix applied
<bschaefer> smspillaz, the small fix being the w->updateStruts call?
<smspillaz> the small fix being the hasNew = false
<smspillaz> after
 * bschaefer still needs to change the indention for reading compiz files
<smspillaz> http://paste.ubuntu.com/1448984/
<bschaefer> it should be getting set to false on line 974
<bschaefer> oo right
<smspillaz> bschaefer: use qtcreator and go into tool -> editor settings -> c++, change "always use spaces" to off, change "indent width" to 4 and "tab width" to 8
<smspillaz> quickest way to get compiz style
<bschaefer> I use vim, and I have the compiz stuff commented out
<bschaefer> i've just been to lazy to go edit that haha
<bschaefer> smspillaz, hmm wont it still be false if this fails though? if (result == Success && data)
<bschaefer> overall it says if (!hasNew)
<bschaefer> so its false coming into this function
<bschaefer> or cond sorry
<smspillaz> yes, it is
<smspillaz> so the way that function works
<smspillaz> is that it checks _NET_WM_STRUT_PARTIAL
<smspillaz> and then if that fails it goes to _NET_WM_STRUT
<smspillaz> if either one succeeds, it sets the new strut values
<smspillaz> both calls to XGetWindowProperty are going to fail because the window does not exist
<smspillaz> so, in that case, we should reset its struts back to zero
<smspillaz> hence the hasNew = true
<bschaefer> yes, so result should not == Succes though
<smspillaz> correct
<bschaefer> but isn't it already false?
<smspillaz> result ?
<smspillaz> or hasNew ?
<bschaefer> result = XGetWindowProperty (screen->dpy (), priv->id,
<bschaefer> will get result != false
<bschaefer> i mean
<bschaefer> result will not equal success, but hasNew at this point is already fase
<bschaefer> false
<smspillaz> yes
<bschaefer> f (!hasNew)
<smspillaz> and you want to se it to true
<bschaefer> ooooo
<smspillaz> sorry, I typoed it in my pastebin
<bschaefer> that is what I got confused about :)
<smspillaz> http://paste.ubuntu.com/1448991/
<bschaefer> smspillaz, hmm but don't we want line 1145 to be ran?
<bschaefer>       priv->struts = NULL;
<bschaefer> smspillaz, ill play around with it, thanks!
<smspillaz> hmm
<smspillaz> okay, actually I'm wrong
<smspillaz> bschaefer: check that in its current implementation, priv->struts is indeed set to NULL when you call updateStruts
<bschaefer> it seems we need this to be true: hasOld != hasNew ||
<smspillaz> that should be the only thing that matters
<bschaefer> smspillaz, alright, ill check that because I tried this twice and it seemed to work when I was doing XGetProperty, but when I removed that it seemed to fail to set it to false
 * bschaefer might have been forgetting to flush X
<smspillaz> then on ~PlaceWindow you can do (window->updateStruts (); mStrutWindows.remove(window); if (mStrutWindow.empty ()) doHandleScreenSizeChange ());
<smspillaz> bschaefer: XGetWindowProperty is a sychronous operation there's no need
<smspillaz> gotta run bbl
<bschaefer> smspillaz, alright, thanks a lot!
<bschaefer> (i meant that XGetWindowProperty() was causing things to be flush, ie. why updateStruts() worked when that was there)
 * bschaefer is most likely wrong
<smspillaz> XGetWindowProperty calls _XReply which is an implicit flush-and-sync
<bschaefer> o cool, good to know
<smspillaz> bregma: yeah, no so sure about the default constructor. Here is what I think you're talking about
<smspillaz> bregma: http://paste.ubuntu.com/1449009/
<smspillaz> Foo.h has a depedency on FooImplFactory.h
<smspillaz> not really sure you want that
<smspillaz> bbl
<smspillaz> bregma: if I'm wrong, can you paste an example of what you're talking about ?
<bschaefer> well awesome, that worked....I must have been doing something horribly wrong haha
<bregma> smspillaz, I'm in and out, I'll try to post what I mean in a bit
<smspillaz> bschaefer: :)
<smspillaz> bregma: okay, no problem. I'll split up the proposals now while I'm waiting
<bregma> smspillaz, http://paste.ubuntu.com/1449232/ -- an example taken from another project with some global substitution of class names for clarity
<bregma> not in Unity code style
<smspillaz> bregma: thanks, I'll take a look
<bregma> I have no idea if it's clear or not, but it compiles and runs
<smspillaz> bregma: ah right
<smspillaz> bregma: see my issue there is that you've got a dependency on Controller::Impl within Controller
<smspillaz> this looks more like the pimpl idiom than it does the bridge pattern
<bregma> the pimpl idiom _is_ the bridge pattern
<smspillaz> bregma: well, in this implementation it is, yes
<smspillaz> bregma: it is clever though, no virtual functions in the interface
<bregma> virtual functions in the interface cause Fragile Base Class syndrome
<smspillaz> agreed
<smspillaz> bregma: I wanted to do something like this for compiz in fact :)
<smspillaz> bregma: that being said, the controller interface is internal. I'm not too worried about ABI stability there
<bregma> true, force of habit doing years of library API development on my part
<smspillaz> bregma: its a good habit
<smspillaz> bregma: anyways. I can do it like this if you want
<smspillaz> it would be quite different to most of the code in unity though
<bregma> but simple, solid interfaces make testing easier and reasoning about the code easier
<bregma> and we can modify the other faces gradually as we do other things
<smspillaz> I agree
<smspillaz> testing will be a bit more awkward though
<smspillaz> you'll have something like this:
<smspillaz> bregma: actually hmm
<smspillaz> bregma: see the thing with testing and google mock generally is that we need to have access to the underlying MockFoo in order to set expectations on it
<bregma> yes, which means the Impl will have to be a mock object
<smspillaz> right, but I need to have access to it
<smspillaz> which means either adding a getter to Controller to get a MockImpl (not gonna happen) or having this awkward "CreateImplFunction" which just returns a reference to the existing mock object
<smspillaz> so you'd have something like (just thinking aloud)
<smspillaz> MockFoo::Ptr p (new MockFoo);
<smspillaz> Controller::CreateImplFunction f ([&]{ return p; })
<smspillaz> Controller c (x, y, f);
<smspillaz> would that make sense ?
<bregma> why not just Controller c(x, y, [](){return Ptr(new MockImpl); });  ?
<bregma> oh, wait
<smspillaz> bregma: because I need to have access to the actual MockImpl
<bregma> yeah, I just realized
<smspillaz> unless you want to make an interface for MockImpl
<smspillaz> ;-)
<smspillaz> An interface for your interface!
<smspillaz> bregma: btw, some people don't like NVI, prepare for some disagreement on reviews :)
<bregma> no no, the Ptr type is a unique_ptr, you can use a unique_ptr on a stack-based object
<smspillaz> or it might just be the NV/P/I strain of NVI
<bregma> I'm not so worried about reviews, I have a big club I can weild if I have to
<smspillaz> bregma: you can use unique_ptr on the stack ?
<smspillaz> wouldn't that mean that CreateImplFunction would have to return a const unique_ptr <Controller> & >
<smspillaz> ?
<bregma> yes, the defaulted second argument is the deleter object, which can just do nothing
<smspillaz> (since unique_ptr is noncopyable iirc)
<smspillaz> or rather, it sets the old one to NULL
<smspillaz> which isn't really what you want
<smspillaz> impl would have to be shared
<bregma> it's better if it's unique and a special deleter is used for mock impls
<bregma> "there can be only one"
<smspillaz> bregma: yeah, just the issue is this:
<smspillaz> unique_ptr <MockImpl> mock (new MockImpl)
<smspillaz> controller (x, y, [&](){ return mock; } -> Impl::Ptr &)
<smspillaz> now mock is NULL
<smspillaz> (I'm sure that lambda syntax was not correct, just ignore it :))
<smspillaz> bregma: so can I make it shared ?
<bregma> unique_ptr only runs the deleter on the underlying pointer, it does not null it out, that's why you need to supply a null deleter
<bregma> I'm trying to find an example
<bregma> this one has an example: http://stackoverflow.com/questions/8274451/well-how-does-the-custom-deleter-of-stdunique-ptr-work
<smspillaz> bregma: ah, thanks. TIL
<bregma> I expect to see some hairy stuff from people like Alexandrescu when more people start experimenting with std::unique_ptr
<smspillaz> bregma: sadly there is no "one true style" for C++
<smspillaz> its all "my opinion is that"
<smspillaz> bregma: BTW, do you mind if I rename SwitcherView to View?
<smspillaz> I'll call the default implementation NuxView
<smspillaz> they both sit in unity::switcher
<bregma> it would be more consistent with switcher::controller
<smspillaz> :)
<smspillaz> bregma: BTW, I hope I don't come across as argumentative. I was just trying to work through the thought process. Thanks for the advice :)
<bregma> no problem, I've been ruminating on this for a while so it's good to hash it out
<smspillaz> :)
<bregma> it's nice to do something non-administrative, too...  too much management, not enough programming these days
<smspillaz> why is that a common theme?
<smspillaz> bregma: you know its awesome, since I've left, I can actually be productive now
<smspillaz> the great irony of employment
<bregma> yeah, like the irony or working from home:  less time commuting but much much more time working
<bregma> in fact, it's nearly midnight here and I have to get up in a few hours to start my day
<smspillaz> bregma: I always thought this would happen: http://theoatmeal.com/comics/working_home
<smspillaz> bregma: heh, get some sleep maybe. I figured it was late. Nice talking :)
<bregma> heh, comic nailed it
<smspillaz> I love the oatmeal. Frank and to the point
<Al562> Hello, does anyone know how to reset keyboard shortcuts back to default??
<smspillaz> hmm
<smspillaz> bschaefer: you around ?
<bschaefer> smspillaz, ish, whats up?
<smspillaz> bschaefer: can you check if the standalone switcher crashes on startup for you?
<bschaefer> smspillaz, sure
<smspillaz> I'm doing some refactoring and its crashhing in an odd place that I haven't touched but I don't want to recompile all of unity
<bschaefer> hmm nope doesn't seem to seg fault for me
<smspillaz> okay, thanks, I'll keep looking into this
<bschaefer> though its a bit odd...good luck!
<bschaefer> I should head off to bed...
<smspillaz> ah, FFS
<smspillaz> you have to install it to run the examples
<gatis> According to X11 specification XGrabKeyboard() should grab all keyboard events exclusively to my client, but its not the case for Super_L (windows key), Alt, which trigger Unity shortcuts
<gatis> any ideas why Unity doesn't respect GrabKeyboard ?
<smspillaz> gatis: I think GrabKeyboard does not override passive grabs
<gatis> smspillaz: i found this https://bugs.launchpad.net/unity-2d/+bug/964414
<ubot5> Launchpad bug 950160 in OEM Priority Project precise "duplicate for #964414 Unity blocks other programs from binding globally to Super+* (* = any key)" [Critical,In progress]
<gatis> i think that the culprit
<smspillaz> yeah if I remember correctly that was a lot more complicated than it seemed
<smspillaz> gatis: are you running precise or quantal ?
<sil2100> I thought that thing got finally resolved?
<sil2100> This bug I mean
<smspillaz> "resolved"
<smspillaz> if I remember correclty we added a workaround to not use the tap detection code on the super key
<gatis> smspillaz: precise
<smspillaz> gatis: yeah I dunno if we ever backported it
<gatis> ah, then i will need to install quantal one day to verify
<sil2100> hm, I think we had packages prepared for precise
<sil2100> But indeed those never got released I think
<sil2100> Since we were working on packaging the workaround on UDS
<Mirv> the fix is only in raring because there is a side-effect being investigated by brandon (dash pops up when display is switched)
<Mirv> if that can be tackled and also that fix backported, then we could finally move forward to releasing the fixes in 12.10 & 12.04. but it seems complicated.
<Mirv> btw, I now summarized the Compiz unredirection status at http://losca.blogspot.fi/2012/12/compiz-fullscreen-unredirection-update.html
<smspillaz> Mirv: what graphics hardware are you running ?
<Mirv> smspillaz: depends on machine... sandybridge quantal, radeon precise machines for example
<Mirv> smspillaz: if you refer to the display switch / dash pop up, that happens with the hardware key of at least dell xps 13 which is wired to output super+p
<smspillaz> Mirv: I was wondering if you had any machines with nvidia cards
<smspillaz> need testers for the buffer_age stuff
<smspillaz> though I guess it just generally needs testing
<Mirv> smspillaz: sil2100 now has one, running precise though
 * sil2100 has one
<smspillaz> ah
<sil2100> It's an old machine though
<sil2100> And it has precise only
<smspillaz> sil2100: <8300GT ?
<sil2100> smspillaz: yes, 7400Go if I remember correctly
<smspillaz> sil2100: yeah, they've moved it to -legacy now
<sil2100> Poor old laptop... :(
<smspillaz> sil2100: I couldn't get the newer version of osx my my desktop machine too (2006 iMac)
<popey> smspillaz, i have one running raring
<popey> smspillaz, GTX 460 if that's any use
<smspillaz> popey: go test ppa:smspillaz/compiz-experimental and file bugs/oddities/whatever with the compiz-experimental-ppa :)
<smspillaz> performance improvements inbound
<smspillaz> (with the compiz-experimental-ppa tag)
<smspillaz> I accidentally a word
<popey> smspillaz, ok
<smspillaz> popey: :)
<popey> smspillaz, anything in particular I should be looking for?
<smspillaz> flickery things
<popey> roger
<smspillaz> its basically a combination of recycling backbuffers (drawing less stuff) partial updates in nux (drawing less stuff)
<smspillaz> any time you get (drawing less stuff) wrong it usually means flickering, bleeding or trails
<smspillaz> popey: the ones I know about are a crash on dragging launcher icons, and flickering when using the workspace switcher
<popey> smspillaz, package in your ppa wants to remove loads of stuff
<popey> smspillaz, paste.ubuntu.com/1450079
<smspillaz> popey: great, I guess I'll have to refresh the version numbers
<smspillaz> I hate debian packages
<popey> :)
<smspillaz> let me go on the record as saying: debian is the worst distribution ever.
 * smspillaz quickly vacates the room
<popey>  /kickban smspillaz
<smspillaz> popey: hmm, I don't really care about the fact that its removing unity-2d ... 1) do you have the staging ppa enabled? 2) could you grab me the output of apt-cache policy unity ?
<smspillaz> popey: okay, so debian is the worst distribution I've ever used BUT
<popey> i have the daily desktop ppa enabled
<popey> i can remove it
<popey> revert to stock
<smspillaz> I've only ever used debian based distros so
<smspillaz> XD
<smspillaz> popey: this one at least depends on ppa:unity-team/staging
<popey> oh, ick
<popey> meh, my system is now in a mess
<smspillaz> its not in a mess until it doesn't boot
<smspillaz> even then its not /really/ in a mess until your kernel image is corrupt and you don't have any other kernel images
<smspillaz> then you're screwed
 * smspillaz has recovered a system from kernel and init=/bin/bash before, not fun
<popey> yeah, need to fiddle a bit
<Trevinho> mterry: ready for your review: https://code.launchpad.net/~3v1n0/bamf/soname-up/+merge/140695 ;)
<mterry> trevinho, thanks!
<Trevinho> mterry: I've updated it to 4, since it was never done before... And I'd like to keep it synced with major version... But if that's something too big, I'll move to just 1.0.0...
<mterry> synced with major version?
<mterry> oh is the version 4.x.x for bamf in general?
<Trevinho> mterry: yes
<mterry> Trevinho, well I guess the next question is when do you bump major versions?  :)  Since it doesn't seem to have been based on SONAMEs before
<mterry> Trevinho, so you might get in this same situation again of mismatched version/SONAME
<mterry> Trevinho, but regardless, there's no problem with bumping up to 4, I was just curious, and wanted to forstall confusion about the 3 in the libbamf3-0 name
<mterry> forestall even
<Trevinho> mterry: yes, that's a possibility I tought... I don't know which is the best approach... for unity (and libunitycore) for example.. we used to bump the soname at every new major version... And that's something we could do here too...
<bregma> that's just broken
<Trevinho> mterry: that name was added because of the gtk3/gtk2 thing (that was wrong, since libbamf never depended on gtk)
<Trevinho> mterry: I wanted to change that too... but I asked to didier and he preferred to stay with it
<mterry> Trevinho, yeah, now that the 3 is there...  I'd just as soon keep it too
<mterry> Trevinho, and bumping SONAME when we don't need to is bad.  I'd just say keep it de-coupled from major version number to resist the urge to bump it unnecessarily
<mterry> Trevinho, speaking of unnecessary...  why did we remove the API again?  :)
<mterry> Trevinho, one could always just make the API a no-op...
<Trevinho> mterry: these apis were totally unneeded...
<mterry> Trevinho, sure...  But everytime a SONAME is bumped, a kitten dies is all I'm saying  :)
<Trevinho> mterry: mh... I wanted to cleanup things that we have in and that were not needed anymore
<Trevinho> mterry: mh, I know... But we have to at some time
<mterry> Trevinho, I'm just being a punk.  Anyway.  I'd say go with 1 for SONAME and update the package names
<Trevinho> ok
<mterry> Trevinho, are there any other API cleanups you want to squeeze in while we're bumping anyway?
<Trevinho> mterry: mhmh... probably few additions, but not removal... Even if there's an ABI change in progress by andyrock (not sure because he probably could just use the padding space we have in structs)
<Trevinho> mterry: question: why the gir packaging is currently disabled for bamf?
<andyrock> Trevinho, mterry https://code.launchpad.net/~andyrock/bamf/bamf-window-tab-mockable/+merge/140704
<Trevinho> andyrock: since you're there please add some padding to the tab class (window one should already have it)
<mterry> Trevinho, not sure
<Trevinho> mterry: I've pushed the updates to the branch...
<Trevinho> mterry: it would be nice to get the gir packaged as well btw
<mterry> Trevinho, yeah...  Do we not have any python consumers now or are there static bindings for that?
<Trevinho> mterry: I think that who is using it with pyhton just uses the raw DBus API (but loosing some features)
<mterry> Trevinho, your last update added an empty chunk to the changelog
<Trevinho> mterry: autopilot does it for example (but also because it was not using gir at all due to some old dependency)
<mterry> Trevinho, also you correctly noted that the libglib2.0-dev needed to be updated, but you did 2.30 instead of 2.32 like the Build-Depend.  Should probably be same
<Trevinho> mterry: actually the library needs a lower version than bamfdaemon
<Trevinho> mterry: that's why I didn't put the same values
<mterry> Trevinho, ah OK
<mterry> Trevinho, so has bamf never needed libwnck or what?
<Trevinho> mterry: the daemon yes, the library never
<Trevinho> mterry: the library only depends on dbus and glib
<mterry> Trevinho, and does the daemon no longer need it?
<Trevinho> mterry: so... it depends on it since it depends on the daemon, but not strictly
<Trevinho> mterry: so you can link on libbamf even without having libwnck-dev installed
<mterry> Oh daemon still needs it, sure
<Trevinho> mterry: oh I forgot to move some debian files... (doing it now)
<Trevinho> mterry: do we really need Depends: ${shlibs:Depends} on libbamf3-dev?
<mterry> Trevinho, no I shouldn't think so
<Trevinho> mterry: everything pushed should be ok now
<mterry> Trevinho, it's not a big deal, but I do like the the trailing commas on the last item in a dep list
<mterry> Trevinho, keeps future diffs shorter and easier to read when we add one at the end
<Trevinho> mterry: i've removed some
<Trevinho> Ah, ok
<Trevinho> sorry... I read a "I don't"... Putting it back
<Trevinho> mterry: I've fixed the gir building, should I move it in another branch?
<mterry> Trevinho, yeah please
<Trevinho> mterry: it's already up: https://code.launchpad.net/~3v1n0/bamf/gir-package/+merge/140742 ;)
<mterry> will get to the other branch too but got distracted
<Trevinho> mterry: done
<Trevinho> mterry: I've update the gir branch too
<mterry> trevinho, awesome
<Trevinho> uff, few merge issue.. Fixing them now
<mterry> trevinho, ${shlibs:Depends} could be dropped yeah.  I thought it was used for gir's but guess not
<Trevinho> mterry: eh, no it uses ${gir:Depends}-.. clearing it
<mterry> trevinho, as for gir1.2-bamf-3-1, I'm reasonably sure that's not right
<mterry> trevinho, e.g. libsecret doesn't use SONAME
<mterry> trevinho, but...
<mterry> trevinho, gtk uses 3.0...  I wonder if that's 3.SONAME?
<Trevinho> mterry: I don't know... it could be, that's why I'm asking... I don't know if there are clear policies on these tasks
<Trevinho> mterry: libdbusmenu is using libdbusmenu.so.4 and gir gir1.2-dbusmenu-glib-0.4
<mterry> trevinho, this part I'm less clear on.  Let me see if there's docs anywhere
<Trevinho> mterry: other things are confusing as well... for example librest-0.7-0 has soname 0 and gir gir1.2-rest-0.7
<mterry> trevinho, yeah.  Many don't have the SONAME as part of it.  But I feel like they should...
<Trevinho> mterry: yeah i think too, also if they depends on a lib that has soname on the name itself...
<mterry> trevinho, they seem all over the place.  appindicator does gir1.2-appindicator3-0.1 (which is weird because it has SONAME 1 and I would expect gir1.2-appindicator3-1)
<mterry> trevinho, (though, to be fair, I think I named that one back in the day)
<mterry> Trevinho, I'd vote for gir1.2-bamf3-1  ...  for matching the other names (though really the other names should bamf-3-1 instead of bamf3-1)
<Trevinho> mterry: mh... not having clear policies on these things creates a little of confusion..
<mterry> Trevinho, I searched, but didn't see one
<Trevinho> mterry: yeah, me too
<mterry> Trevinho, couldn't even find where the original gir1.0 vs gir1.2 issue was settled
<mterry> I think that was just a post in debian's bug tracker
<Trevinho> mterry: so also the typelib name should be Bamf3-1.typelib instead of Bamf-3.typelib ?
<mterry> Trevinho, yeah, it should track the package name.
<mterry> Trevinho, but honestly I'd like to ask around first and see if anyone knows the real policy for these things before we go ahead
<mterry> Trevinho, most people that know are on holiday.  Maybe wait until the next year
<Trevinho> mterry: ok... So I'll keep it waiting
<Trevinho> mterry: please let me know when you have any info..
<fginther> bregma, ping
<bregma> fginther, pong
<fginther> bregma, do you happen to know anything about Jussi's precompiled header change for unity failing to build in the staging ppa?
<fginther> https://launchpadlibrarian.net/126181515/buildlog_ubuntu-raring-amd64.unity_6.12.0daily12.12.05bzr3003pkg0raring0_FAILEDTOBUILD.txt.gz
<fginther> bregma, I was unable to find him online
<bregma> only that, according to Jussi, "it broke the build because in Jenkins something is stripping compiler flags in unity-shared"
<bregma> then he said he'dlook into it tomorrow
<bregma> he's at, what UTC-2?
<fginther> ok, didn't know if he expanded on that to you. Thanks for checking.
<fginther> yeah, he should be online before too long
<bregma> my first guess is that Jenkins is pulling in a newew cmake and it does something different with the flags
<bregma> but he's the expert on cmake, so I trust he'll figure it out
<fginther> Ok, I'll just send him an message with my brain dump, hopefully it will get him the info he needs.
<fginther> bregma, thanks for the help
<bregma> pleasure
#ubuntu-unity 2012-12-20
<davidcalle> mhr3, ping?
<mhr3> pong
<davidcalle> mhr3, do you know when kenvandine or didrocks will be back from their holiday?
<mhr3> january
<mhr3> do you need like exact date?
<davidcalle> mhr3, thanks :) Nope, it's just to discuss naming/packaging scheme.
<mhr3> ok
<smspillaz> bregma: this NVI design is a little icky to use
<smspillaz> doesn't work well with nux objects
<bregma> hmm
<smspillaz> I can get around it by supplying custom deleters to unique_ptr but
<smspillaz> Obviously I don't want to have std::unique_ptr<Impl, NuxDeleter>
<bregma> let me experiment a bit with the ideas I had, they may not pan out in practice
<smspillaz> bregma: its a neat idea, but it might only be necessary where you care about ABI stability
<smspillaz> bregma: another potential problem is that especially because of the unique_ptr to Impl, it effectively means that implementing multiple interfaces is out
<bregma> I care about testability and ease of reasoning, it just happens that a clear, stable API is the best way to achieve that
<smspillaz> bregma: well, virtual interfaces get you testability and ease of reasoning
<smspillaz> nonvirtual interfaces will get you ABI stability
<smspillaz> bregma: in any case, do you want me to try and make it work with nux objects as the underlying impl ?
<smspillaz> we can see where it goes from there
<bregma> separating the client interface from the impementationo interface gets you clarity and testability
<bregma> go ahead and try to make it work;  I'll play with my alternate implementation, we'll see what works and what doesn;t....  we're not in a rush over the next couple of weeks
<bregma> what with everything being shut down and everyone on vacation
<smspillaz> bregma: I'd rather not block some refactoring which is making building unity a total pain on an experiment :(
<smspillaz> I
<smspillaz> erm
<smspillaz> I've seen the results of endless-iteration before, its not pretty
<bregma> we're not in such a rush to get stuff out the door that we need to further compromise an already tenuously maintainable codebase
<bregma> not this time, at least
<smspillaz> bregma: of course. At least what I'm trying to say is that
<smspillaz> the changes I'm making at the moment are about making the codebase more testable and less coupled
<smspillaz> and I worry that the longer we leave it the more likely it is that we're just going to live with 6 files recompiling every time you do a make, fragile sed scripts etc
<smspillaz> changing the switcher stuff especially is a total pain because you have to carefully update the sed scripts used for mocking every time
<smspillaz> so I think its kinda important that we get to that first and then look at how we can best do our interfaces
<bregma> I agree, that's why I was working on it in the first place
<smspillaz> bregma: oh heh
<smspillaz> bregma: I suggest you give lp:~smspillaz/unity/unity.gesture_tests_no_sed a try then :)
<smspillaz> no recompiles :)
<smspillaz> bregma: I'm not planning on proposing that branch btw, because the changes are massive, but I'm just cherry-picking things out of it
<smspillaz> (note that right now it crashes, but I'm trying to figure out how best to handle the nux::Object living in-its-own-world-along-side-std::-unique-ptr thing
<bregma> one of the goals I'm setting for ongoing maintenance is to try to reduce the learning curve for people not involved with its original development, which means improving the clarity of purpose for all entities, and adding documentation
<bregma> being able to read test cases does both in a useful and productive way
<smspillaz> ++
<bregma> reducing the invisible side effects that seem to cause a lot of problems is another, but that may not happen in my lifetime
<smspillaz> bregma: also agree on both points there :)
<bregma> when I started doing this, every singe standalone test tool crashed on startup, obviously none of the developers used them
<smspillaz> bregma: yep :(
<bregma> some days I get frustrated
<smspillaz> bregma: I know about the problems with unity
<smspillaz> its why I hardly ever worked on it back when I was at canonical
<smspillaz> bregma: anyways, I guess what I'm trying to say is that I've got a solution out there for one of the larger code-smells which makes testing and maintainance a pain. I hope we can work together on it :)
<bregma> I'm willing to take the time and do it right (but not too much time)
<smspillaz> bregma: likewise
<smspillaz> bregma: anyways, I'll keep looking at whether or not we can get nux objects working with your NVI pattern
<bregma> yep
<smspillaz> I suspect the first implementation will be quite fragile, but it will be a start
<bregma> I'm hoping aggregation instead of inheritance is the right solution
<smspillaz> bregma: by aggregation you mean composition right ?
<bregma> yeah, the difference is subtle and not always clear to me
<smspillaz> bregma: I guess I'm just curious as to why a non-virtual-interface is the best way to do it in your view
<bregma> in UMP, one is a solid diamond and one is a hollow diamond
<bregma> *UML
<bregma> because a non-virtual interface forces the client interface and the implemntation interface to be separate
<smspillaz> bregma: separate in form or substance ?
<bregma> virtual functions are meant for implemntations to doe their thing differently
<bregma> the client interface should be unchanging and solid
<smspillaz> (as in, does it allow the implementation interface to vary while the client interface stays the same ?)
<bregma> like a legal contract
<smspillaz> okay
<smspillaz> hmm
<smspillaz> bregma: yeah, so that form of NVI some people are very opposed to :)
<smspillaz> its basically Sutter v The World there
<bregma> well, they can complain to the guy running the Unity maintenance team if they don;t like it
<smspillaz> Well, Sutter. Webb. et al. v The World
<smspillaz> bregma: my suggestion at least if we want to go with nonvirtual interfaces (and honestly I don't care either way) is that instead of std::unique_ptr <Impl> we should have std::shared_ptr <Impl>
<smspillaz> and instead of taking a function to construct someone who implements Interface::Impl, it should just take std::shared_ptr <Interface::Impl> in its constructor
<bregma> unique_ptr make it clear there is only one possible implementation, and it belongs to the object of that class...  clarity of purpose and intent
<smspillaz> bregma: the problem is that it doesn't work when you want to implement multiple interfaces
<bregma> ugh, metting time
<smspillaz> bregma: chat later ?
<smspillaz> bregma: I'll draw up a UML diagram of what I mean
<Trevinho> smspillaz: have you seen https://bugs.launchpad.net/unity/+bug/1092550 ?
<ubot5> Launchpad bug 1092550 in Unity "Using bleeding edge Mesa drivers causes GL_INVALID_OPERATION error in glDrawBuffer / glReadBuffer" [Medium,Triaged]
<smspillaz> Trevinho: I don't watch the bug reports, so no
<Trevinho> smspillaz: :)
<smspillaz> Trevinho: do you know where the offending code is ?
<Trevinho> smspillaz: unityshell.cpp
<Trevinho> smspillaz: there are two calls in the nuxPrologue
<smspillaz> those aren't really invalid usages
<Trevinho> smspillaz: sorry, nuxEpilogue
<Trevinho> smspillaz: wondering why mesa is offended by them
<smspillaz> Trevinho: could be somewhere in nux
<Trevinho> smspillaz: you got three or four per second
<smspillaz> Trevinho: could be a bug in mesa's handling of GL_BACK. Try GL_BACK_LEFT
<Trevinho> smspillaz: I've removed these calls from unity and the errors stopped.. We have also a couple of these calls in nux but they are not running in this case I think
<smspillaz> in any case those functions are not really necessary
<Karoliina> Hello!
<smspillaz> as long as nux doesn't do anything like
<Trevinho> smspillaz: so we can just wipe them?
<smspillaz> glDrawBuffer (GL_COLOR_ATTACHMENT0+n)
<Trevinho> (I don't see regressions here, but who knows..)
<smspillaz> Trevinho: if I remember correctly calls to glDrawBuffer affect the currently bound framebuffer object anyways
<Trevinho> smspillaz: yes, but it's under #ifndef NUX_OPENGLES_20... while in unity we have them in USE_GLES
<Karoliina> I didn't know where to ask, and didn't find any relevant results in the web, so here's my question: After uninstalling LXDE in Ubuntu 12.04 (regular Ubuntu, not Lubuntu) Unity disappeared from the Login screen, and I'm only left with LXDE (which despite showing as uninstalled in Software Centre still works) and a handful of GNOME shells that don't start at all. Helps?
<smspillaz> Karoliina: sudo apt-get install unity
<smspillaz> that will bring in all the deps at least
<Karoliina> It said it's already installed. Actually modifying Unity-2D in /usr/share/xsessions/ brought Unity back, but all other settings and applications recognise it as Unity-2D
<Karoliina> (ubuntu-2d.desktop file)
<smspillaz> Trevinho: I'd say get rid of those two lines
<Trevinho> smspillaz: ok fine
<smspillaz> Trevinho: in fact, they are invalid operations
<smspillaz> the compiz fbo is still bound
<smspillaz> so setting the buffer to GL_BACK makes no sense anyways
<smspillaz> you can only change it to a color attachment
<smspillaz> and even then its pointless as the color attachment point never changes
<Trevinho> ok
<smspillaz> framebuffer objects are the worst documented part of opengl
<smspillaz> Karoliina: haven't really got any other ideas :( Purge and remove unity and unity-2d and re-install it ?
<Karoliina> Scary =(
<Trevinho> smspillaz: however giving a try to these drivers I get the games a lot faster, but unity and compiz are somewhat slower... The same happened moving from precise->quantal with radeon (open) drivers. It's very hard to use the dash here with a full-hd screen :/
<smspillaz> Trevinho: try my patches
<smspillaz> one of these days at least
<Karoliina> smspillaz: Would backing up /home/user and then reinstalling and restoring from the back up help?
<smspillaz> I'm seeing a 70% performance improvement here
<smspillaz> Karoliina: you could do that if you wanted
<Trevinho> smspillaz: which branch specifically?
<smspillaz> Trevinho: ppa:smspillaz/compiz-experimental
<Trevinho> smspillaz: ok fine  ;)
<smspillaz> Trevinho: My patches will probably never be accepted at this point, so I've effectively forked our stack because I'm sick of it being so slow
<smspillaz> the joys of not working for canonical - you can fork your own stack and ignore all political fallout
<Trevinho> smspillaz: why can't be accepted?
<smspillaz> Trevinho: the patches are massive and change APIs in nux and compiz
<Karoliina> smspillaz: Doing it atm, but not sure if that wouldn't bring broken LXDE back and cause the same problems. Unity is pretty and I like it too much to give it up, but I can't give up my files either. ):
<smspillaz> Trevinho: I really can't be bothered going through all the political drama to get them accepted
<smspillaz> Trevinho: the tl;dr version is that I basically re-introduced the regional-damage stuff, but pushed a lot of the logic up into compiz and nux
<mars> Hi all, I've noticed the dash takes a long time to open on my system (12.04).  Is there any way to profile it to find the bottleneck?
<smspillaz> mars: valgrind --tool=callgrind compiz --replace
<mars> smspillaz, anything less complicated I could try?  Perhaps some way to isolate bottlenecks at a higher system level, like 'lense loading', 'render', etc.?
<mars> a debug log with timing information might work - maybe strace or something?
<popey> mars, i found that switching off dash blur speeds up dash loading quite a bit
<mars> popey, thanks, I'll try it
<smspillaz> mars: well, I guess if you wanted to profile to contribute a fix then callgrind would be useful
#ubuntu-unity 2012-12-21
<hyperair> some of my compiz settings keep reverting to default, like focus-follows-mouse, and the move-to-workspace-N keybindings.
<hyperair> does anyone know what's going on there?
<hyperair> it's like there's something that reverts all my settings to default when i log out and log back in, and it seemingly happens at random if i just restart unity.
<hyperair> manually looking at the values after setting them with gsettings seems to show that things are okay
<sil2100> Morning!
<smspillaz> hyperair: ah, hmm, I've been looking for someone who can reproduce that
<smspillaz> hyperair: do you mind if we can look into that in the new year ?
<smspillaz> hyperair: are you running Q or R ?
<hyperair> smspillaz: sure. i'm running Q.
<hyperair> smspillaz: i don't usually notice it because my uptime usually spans ~30 days or so
<hyperair> but these days i've been getting some kernel panics
<JanC> a friend of me also had the issue with "move-to-workspace-N keybindings"
<fginther> tedg, ping
<tedg> Howdy fginther
<fginther> tedg, Is this ready to merge? https://code.launchpad.net/~ted/indicator-appmenu/hudectomy/+merge/131237
<tedg> fginther, Well we have to ask didrocks to merge anything apparently.
<tedg> It will be if the hud package is in raring.
<fginther> tedg, I see
<fginther> tedg, so, I attempted to update from ppa:unity-team/staging (which contains indicator-appmenu) and found that depends on a libbamf3-0 which has been replaced by libbamf3-1
<fginther> short story is indicator-appmenu no longer works from the pa
<fginther> s/pa/ppa/
<tedg> fginther, Hmm, cyphermox do you know the story there?
<fginther> tedg, I tried to just rebuild indicator-appmenu in the ppa and ran into build errors: https://launchpadlibrarian.net/126401256/buildlog_ubuntu-raring-amd64.indicator-appmenu_12.10.4daily12.12.14-0ubuntu1%2Bbzr226pkg0raring2_FAILEDTOBUILD.txt.gz
<fginther> so I was hopping your hud branch would take care of these and was just overlooked. sadly, that doesn't appear to be the case.
<tedg> fginther, Will it will as it removes those.  :-)
<fginther> tedg, ok. If that branch takes care of the build failures then I'll just sit tight until didrocks is ready.  Thanks
#ubuntu-unity 2012-12-22
<Bacta> Hi - I've noticed that for programmes like Chrome that I can "pin" the window to the left hand side of the screen but for programmes like Gedit I cannot. Are there limitations to what apps this will work with?
<smspillaz> There needs to be a new rule with nux
<smspillaz> if you don't understand what some of the code is doing, ask someone before refactoring it and removing all of its functionality -.-
 * smspillaz just spent the last 2 days fighting a completely broken nux::GpuDevice::CreateTexture2DFromID
<conscioususer> Cimi: ping
<conscioususer> hi, is there a way to detect during runtime if the overlay scrollbars are enabled?
<bobweaver> Is there anyone in this channel that was involded in Unity 2d? I am looking if there was already a glib settings changer wrote into it. I was going to add one to my Unity 2d. But if there is something in libunity2d-private already then no need to write more. Right :) thanks
<popey> bobweaver, kaleo may know
<bobweaver> thanks popey
<popey> if not greyback
<bobweaver> I was also wondering about all the resons that QX11info was used and what I can do to get rid of it. to port to qt5
<bobweaver> qx11info is not in qt5
<bobweaver> maybe xcb would be best
<bobweaver> << clueless :)
<popey> ditto
#ubuntu-unity 2012-12-23
<alo21> hi... is there a way to start a lens with terminal?
#ubuntu-unity 2013-12-16
<tsdgeos> oh man
<tsdgeos> can't get the dash test to fail anymore :D
<mhr3> sil2100, when auto-landing a project to distro, how is the changelog created?
<mhr3> sil2100, does it take commit msg of each rev *unless* that commit also changed debian/changelog?
<sil2100> mhr3: yes
<sil2100> mhr3: if a commit changed/touched the changelog, then the commit message for that revision is not added
<mhr3> good to know, thx
<mpt> tvoss, I vaguely remember hearing that Mirâs application awareness would fix bug 780776. Is that correct? And if so, how?
<ubot5> bug 780776 in unity (Ubuntu) "Launcher - No feedback when application launched elsewhere" [Medium,Triaged] https://launchpad.net/bugs/780776
<mpt> e.g. opening a document from the file manager, or a music player from the sound menu
<tvoss> mpt, right, although we haven't implemented user feedback, yet. But in theory, it would solve the issue
<mpt> tvoss, is the feedback design specified somewhere?
<tvoss> mpt, I don't think so, surely not for the desktop use-case
<mpt> tvoss, a job for katie then perhaps?
<tvoss> mpt, yup, I would think that you will be involved, too :)
<dednick> Cimi: ping
<dednick> Cimi: looks like that test issue with ubuntu-settings-components is a qt bug. I've filed a bug with them, skipped the test for now and added a TODO for when it is fixed.
<dandrader> Mirv, I'm at a loss on how to proceed with https://bugs.launchpad.net/bugs/1258057
<ubot5> Ubuntu bug 1258057 in Unity API "unity-api fails to build against Qt 5.2" [Critical,In progress]
<dandrader> Mirv, any suggestions?
<Mirv> dandrader: so qt5-beta2 PPA + git snapshot of qt declarative (and only qt declarative) works? then maybe the snapshot would be worth considering indeed. it just adds to the uncertainty, but if we already know there's a component that's broken in a sense (qt declarative), then I guess it wouldn't do more harm.
<Mirv> and yes it's a stable branch, but sometimes indeed the minor stable releases aren't that minor either
<dandrader> Mirv, yes (assuming qt5-beta2 PPA is essentially git tag v5.2.0)
<dandrader> Mirv, problem is: 1 - there isn't a single commit to cherry-pick that fixes it. we need to bring in a number of commits
<dandrader> Mirv, 2 - it fixes the testLauncher crash but causes testApplication to fail
<dandrader> Mirv, so, taking in the latest qtdeclarative stable branch improves our situation (moving from a crash to a failure) but doesn't completely solve it
<dandrader> Mirv, to a course of action could be taking qtdeclarative stable branch an filing a qtbug on that failure, which looks like a regression regarding qobject enums not visible on the qml side
<dandrader> s/to a/so a
<dandrader> but then, we don't know what other problems or regressions might come along that newer qtdeclarative, as you said...
<Mirv> dandrader: yeah or it's still ~rc since I'm rebuilding all final releases in qt5-daily at the moment. but yes I'd consider failure better than a crasher, so it's at least worth considering, but I'll concentrate on rebuilding all of final releases now first (and rebuilding everything against them, then)
<Mirv> there's of course a chance that unity-api would behave slightly differently also with the final release vs. the release candidate in rc2, so worth checking first
<greyback> hi ho
<tsdgeos> dednick|lunch: standup?
<tsdgeos> mzanetti: ââ
<tvoss> Saviq, ping
<mzanetti> tedg: sorry... trashed my PC
<mzanetti> will try to join asap
<mzanetti> tsdgeos: ^^
<tsdgeos> ok
<tsdgeos> tvoss: he's out today
<tvoss> tsdgeos, ack and thx
<tsdgeos> mzanetti: we're done i guess you can fill in your notes and just shout here if it's something that you need us to act on
<dednick|lunch> doh. missed it
<tsdgeos> dednick: same applies to you :-)
<dednick> tsdgeos: yep. wil do
<mzanetti> tsdgeos: yeah... nothing really. I've just been working on the right edge with unfortunately very little progress so far today.
<tsdgeos> ok :-)
<mzanetti> have been following the wrong approach and had to go back one step
<dednick> Is Cimi not in today?
<jn> anybody?
<jn> how to reinstall unity after installing gnome.
<jn> ?
<dandrader> tsdgeos, so VerticalJournal.horizontalSpacing is indeed different than Grid.columnSpacing?
<tsdgeos> is the horizontal spacing
<tsdgeos> both between columns and between the borders of the item
<tsdgeos> being a minimum bound at the right side of course
<dandrader> tsdgeos, that must be documented
<tsdgeos> what other thing can it be?
<dandrader> tsdgeos, I would expect it to be like Grid.columnSpacing
<tsdgeos> well, but it's not called columnSpacing :D
<dandrader> tsdgeos, so your horizontalSpacing is like a margin
<tsdgeos> dandrader: so you'd prefer stuff to start x=0 instead of x=horizontalSpacing
<tsdgeos> i understand?
<dandrader> tsdgeos, I prefer to have the meaning of that property documented to avoid ambiguities and misunderstandings
<tsdgeos> that's not the answer i want :D
<tsdgeos> i am asking API wise
<tsdgeos> do you think it makes more sense for it to be what i say or not
<tsdgeos> we're trying to make this good
<tsdgeos> so i'm asking what you think makes more sense
<dandrader> tsdgeos, I would prefer s/horizontalSpacing/columnSpacing
<dandrader> tsdgeos, that margin can be done via other means
<dandrader> tsdgeos, yield more flexibility to the layout
<dandrader> tsdgeos, you use Item's native margin properties to achieve that spacing between the edge columns and the item borders
<dandrader> tsdgeos, and also mimicking an existing API (Qt's Grid) has the added benefit of having the overall API more uniform and fit better together
<dandrader> tsdgeos, A developer used to work with Grid will have a much lower learning curve if his existing API expectations can be directly transfered when working with VerticalJournal
<tsdgeos> dandrader: ok, can you please add that comment to the review?
<tsdgeos> will need to change it for vSpacing too
<dandrader> tsdgeos, ok
<tsdgeos> thanks :-)
<tsdgeos> dandrader: as for the tryFoo
<tsdgeos> we dont' support what you envision :D
<tsdgeos> you can't remove items from the middle
<tsdgeos> this only works with static models
<tsdgeos> you can make it grow
<tsdgeos> because that's kind of static
<tsdgeos> but that's all
<tsdgeos> or shrink from the end
<tsdgeos> dandrader: that ok?
<dandrader> tsdgeos, didn't get the "static model" explanation but, anyway, you can still push and pop (like in a stack), right?
<dandrader> tsdgeos, if so, the tryVerticalJournal still makes sense
<tsdgeos> dandrader: basically we don't support removing from the model
<tsdgeos> errr
<tsdgeos> model/middle
<tsdgeos> you can add stuff at the end and remove from the end
<tsdgeos> and that's it
<tsdgeos> but sure i am not saying it does not make sense
<tsdgeos> i'm just setting your expectations
<tsdgeos> that said
<tsdgeos> EOD-time
<tsdgeos> tty tomorro
<tsdgeos> w
<tedg> greyback, Hey, so doing more timing tests.
<tedg> greyback, It seems that the observer for the starting signal is taking 63ms inside the unity codebase (dbus overhead stripped)
<tedg> greyback, Is that expected?  Seems like a while.
<kgunn> veebers: hey, hope you're well...just wanted to point out...this one is makin' the news
<kgunn> https://bugs.launchpad.net/unity8/+bug/1260860
<ubot5> Ubuntu bug 1260860 in Unity 8 "some autopilot tests don't use process_helpers" [High,Triaged]
<kgunn> causing random failures on maguro...can you treat with priority ?
<veebers> Hi kgunn, I'm currently on vacation so time in front of my laptop is spotty. I should be able to look at this morning if it's priority though. Should be easy enough to fix for any dev though
<kgunn> veebers: ack, are you off for christmas ?
<veebers> kgunn: aye, off until Jan 6th
#ubuntu-unity 2013-12-17
<dandrader> my indicators (in desktop unity 7) started vanishing from time to time. is there a single command to reload/restart them all?
<tsdgeos> dandrader: start unity8 :D
<tsdgeos> dandrader: and then ctrl+c it :D
<tsdgeos> that's how i get them back
<dandrader> tsdgeos, won't that wreak havoc over my open windows? will it kill and restart compiz?
<tsdgeos> dandrader: unity8?Â¿
<dandrader> ah, unity8
<dandrader> tsdgeos, you have unity8 installed on your desktop?
<tsdgeos> dandrader: just ./run in your unity8 self compiled thing
<dandrader> ah by "start" you mean running it, not the upstart "start" command :)
<tsdgeos> correct
<Saviq> morning folks
<dandrader> tsdgeos, that's crazy. if you close unity8 as opposed to hitting ctrl+c the indicators disappear again :)
<tsdgeos> yep
<tsdgeos> well it's unity8 taking them down
<tsdgeos> makes some kind of sense if you think about it
<Saviq> dandrader, the indicator backend is sending 'stop' to them
<Saviq> when closing
<dandrader> right
<tsdgeos> dandrader: about http://paste.ubuntu.com/6587933/ , sure i could do it, but there's any real benefit? that code pretty much isolated at the end of the function inside an if
<dandrader> tsdgeos, just to make VerticalJournal::updatePolish() smaller
<dandrader> tsdgeos, smaller functions (that roughly fit in a screen) are easier to read, IMHO
<tsdgeos> a function call be called from anywhere
<tsdgeos> if it's there
<tsdgeos> you don't have to think where it's called from
<tsdgeos> it's obvious only happens tehre
<tsdgeos> but whatever
<tsdgeos> you want a function
<tsdgeos> i'll give you a function
<tsdgeos> dandrader: any reason you did not make the same comment for the "if (m_needsRelayout) {" block?
<tsdgeos> dandrader: also i'd appreciate what is your suggestion to make "qreal columnToAddY = !m_columnVisibleItems[0].isEmpty() ? m_columnVisibleItems[0].last().y() + m_columnVisibleItems[0].last().height() : 0;" sorter since any variant i try looks much less readable in my mind
<tsdgeos> i'll add a column variable
<tsdgeos> but meh anyway
<dandrader> tsdgeos, no. since  updatePolish is back to a pretty reasonable size with the  calculateImplicitHeight() modification, doing the same there is not a must
<tsdgeos> dandrader: and any reason you chose calculateImplicitHeight instead of the other block? after all the other block is taller than the calculateImplicitHeight one
<dandrader> tsdgeos, no, the overall idea is just to split a big function into small chunks that do only one thing to make the formet big guy more readable
<dandrader> tsdgeos, calculateImplicitHeight was just simpler to name :)
<tsdgeos> the other one even had a name
<tsdgeos> i just never created the functio
<tsdgeos> but it was there in the .h
<tsdgeos> doRelayout();
<dandrader> tsdgeos, you're the victim of me having plenty of time to do code review :)
<dandrader> tsdgeos, what those delegateCreationBegin and delegateCreationEnd properties mean exactly (btw, s/Begin/Start as using "begin" as a noun is weird)?
<dandrader> seem to be some kind of vertical margin but I still didn't get it
<tsdgeos> you should have complained about the name before we distro-patched Qt
<tsdgeos> dandrader: it's the range of the height of the view where delegates will be created
<tsdgeos> dandrader: becuse your view is 100000 pixels height but inside of a listview that is only 700pixels height you don't need to create delegates for all your height, only for what's visible inside the listview
 * dandrader apt-get source qtdeclarative
<dandrader> tsdgeos, is there a code review branch to get it upstreamed in gerrit?
<tsdgeos> dandrader: not sure what you mean
<tsdgeos> ah
<tsdgeos> the range stuff?
<tsdgeos> no there is not
<tsdgeos> it's deemed as not appropiate for upstream
<tsdgeos> because upstream listview sucks and has to be rewrriten
<tsdgeos> well actually there is one probably
<tsdgeos> just rejected
 * tsdgeos looks
<tsdgeos> yep
<tsdgeos> https://codereview.qt-project.org/#change,60809
<tsdgeos> dandrader: ââ
<dandrader> thanks
<Saviq> oups... someone blinked with the power plant...
<dandrader> tsdgeos, so there's a new list view architecture on the way?
 * Saviq does food to save power in case it doesn't come back within the half hour my battery still has in it...
<tsdgeos> dandrader: nope
<dandrader> " The generic solution for this problem is the new list view architecture"
<tsdgeos> yes
<tsdgeos> doesn't mean anyone is writing it
<tsdgeos> basically he's blocking shit he doesn't want to maintain
<dandrader> :)
<dednick> mzanetti: howdy
<mzanetti> dednick: o/
<dednick> mzanetti: hi :) How do I get qmltests run as part of ci for a project?
<dednick> mzanetti: specifically ubuntu-settings-components
<mzanetti> dednick: they should be run as part of make check normally
<dednick> mzanetti: it has a jenkins job already, but the tests arent run automatically. https://jenkins.qa.ubuntu.com/job/ubuntu-settings-components-qmltests-saucy/
<dednick> mzanetti: that's only unit tests though no?
<mzanetti> dednick: what kind of qmltests are you talking about?
<mhr3> Saviq, could you re-look at json-defaults?
<dednick> mzanetti: unity8 style
<mzanetti> dednick: looking at the console output from here it would suggest the tests are actually running: https://jenkins.qa.ubuntu.com/job/ubuntu-settings-components-qmltests-saucy/6/console
<dednick> qmltestrunner
<dednick> mzanetti: those were manual starts
<mzanetti> what do you mean with manual starts?
<dednick> mzanetti: as in i started the job though jenkins, not through a ci job
<mzanetti> dednick: ahh... you have that job, but it's not executed as a child of the -ci job yet
<dednick> mzanetti: :) yes
<mzanetti> dednick: check out lp:cupstream2distro-config
<mzanetti> dednick: in there you'll find a config for your project where you can add this job
<mzanetti> dednick: stacks/head/sdk.cfg
<dandrader> how to I get the network indicator back in my desktop (unity7). indicator-network seems to be for the phone/unity8
<mzanetti> dednick: check out stacks/phablet/shell.cfg on how they are added to unity8
<dednick> mzanetti: cool. thanks
<mzanetti> dednick: once done, propose a merge and ask fginther to deploy the config to the jenkins instance
<dednick> Cimi: ping
<Saviq> mhr3, yes, on my list for today
<Cimi>  dednick pong
<dednick> Cimi: hi, can you check out the ubuntu-settings-como
<dednick> ponents merge again please?
<Cimi> dednick, was checking now
<dednick> Cimi: ah, thanks
<Cimi> dednick, ok they all pass for me now
<dednick> Cimi: awesome
<Saviq> tsdgeos, can't find it... what was the new thing that should be used instead of .toLocal8Bit?
<tsdgeos> hmmm
<tsdgeos> toUtf8() ?
<tsdgeos> Saviq: what you trying to do ?
<Saviq> tsdgeos, qWarning("Unable to parse category JSON: %s", parseError.errorString().toLocal8Bit().constData());
<tsdgeos> qWarning("Unable to parse category JSON: %s", parseError.errorString());
<tsdgeos> ?
<Saviq> tsdgeos, yeah, the docs aren't really clear on that
<tsdgeos> or use the new << form
<tsdgeos> qWarning() << "Unable to parse category JSON:" <<  parseError.errorString();
<Saviq> tsdgeos, yeah, probably better
<Saviq> tsdgeos, the docs for the former say "like printf()", so that indeed suggests you need a char*
<tsdgeos> true, i'd say they understand QString but maybe it doesn't
<tsdgeos> anyway << is better
<Saviq> yup
<nic-doffay> Saviq, got a minute to chat about the SF stuff?
<Saviq> nic-doffay, yeah, assuming my battery won't die (power outage)
<Saviq> nic-doffay, you got some 20 minutes ;)
<nic-doffay> Saviq, ok cool. So the stuff in qtubuntu.
<nic-doffay> What is reusable?
<Saviq> nic-doffay, what do you want to reuse it for?
<Saviq> nic-doffay, qtubuntu just needs stripping
<Saviq> nic-doffay, i.e. it just has to stop building / installing the Ubuntu.Application module
<Saviq> or whatever it's called
<nic-doffay> Saviq, ok so none of that code is reused. So nothing inside that qtubuntu folder would be used for the simple shell?
<Saviq> nic-doffay, the "simple shell" is just unity8, with its internal fake applications
<dandrader> Saviq, are getting internet through the cellular network?
<dandrader> are you
<Saviq> dandrader, yes
<Saviq> nic-doffay, "modules" from http://bazaar.launchpad.net/~phablet-team/qtubuntu/trunk/files/head:/src/ needs to go away
 * dandrader recalls the sim card slot in Saviq's laptop
<Saviq> dandrader, ha!
<nic-doffay> Saviq, so you just want to benchmark unity8 running on the sf?
<Saviq> nic-doffay, on either
<Saviq> nic-doffay, but benchmarking is somewhat unrelated
<Saviq> nic-doffay, there's basically two tasks here: a) drop SF support for app management and b) enable FPS display for *any* backend
<Saviq> be it sf, mir or X11
<nic-doffay> Saviq, ah ok.
<nic-doffay> Saviq, thanks. The latter was what I was in the dark about.
<Saviq> nic-doffay, cheers
<Saviq> oh there's the battery light blinking now!
<nic-doffay> Saviq, good luck with the power too. ;P
<Saviq> nic-doffay, bad timing!
<nic-doffay> Saviq, haha yeah just saw.
<nic-doffay> I'm a lucky charm.
<dednick> sil2100: howdy. i need to get a daily release for ubuntu-settings-components.
<sil2100> dednick: hello! Ok, does it include anything critical? Could you add it to the Landing Asks?
<dednick> sil2100: it's not even used by anything yet. But need to get some changes in before it is.
<dednick> sil2100: er, don't think i have write access to asks
<sil2100> dednick: ah, like that, so it's a safe upload then - normally your manager should add it to the Landing Asks, but I'll add it right now myself
<sil2100> dednick: I'll try to get it out today
<dednick> sil2100: thanks.
<Saviq> power back up, /me scoots back home
<tsdgeos> DBL_MIN is broken
<tsdgeos> or am i
<tsdgeos> ok
<tsdgeos> i am
<tsdgeos> DBL_MIN is not the smallest double
<tsdgeos> but the smallest double increment
<tsdgeos> sad that it is so close to INT_MIN
<tsdgeos> ::lowest to the rescue!
<dandrader> tsdgeos, I wonder if instead of having this delegateCreation[Begin|End] API you couldn'
<dandrader> have something like a "clipDelegatesToParentRect"
<dandrader> but I know it's too late to do anything about it
<Saviq> dandrader, think it time to move the DDA to UITK yet? toolbar is suffering from not having it: bug #1261719
<ubot5> bug 1261719 in ubuntu-ui-toolkit (Ubuntu) "Edge swipes triggered via touches, not swipes" [Undecided,Confirmed] https://launchpad.net/bugs/1261719
<dandrader> Saviq, hmm, maybe. but there will be quite many changes once the "touch ownership" scheme is in place, which depends on the "qml as mir compositor" work to land.
<dandrader> lp:~dandrader/unity8/touchOwnership
<Saviq> dandrader, shouldn't be many changes *inside* the gesture recognition itself?
<Saviq> tsdgeos, got anything out of more_logs?
<dandrader> Saviq, well, that's the diff for the DirectionalDragArea http://goo.gl/bBRvKT. Essentially moving things around
<Saviq> dandrader, couldn't that happen before?
<Saviq> dandrader, i.e. can we safely split that branch into smaller chunks?
<dandrader> Saviq,  technically yes, I could add the new classes but not make use of them. And therefore not update any code to make use of it (like DDA)
<dandrader> Saviq, but that intermediate state wouldn't make much sense
<Saviq> dandrader, yeah, no
<Cimi> mzanetti, where's the cause of the broken binding on tab? did you understand yesterday?
<mzanetti> Cimi: ??
<Cimi> mzanetti, the bug we were talking friday
<mzanetti> yeah. I don't understand the question
<mzanetti> I don't know more than you do on that
<Cimi> mzanetti, how you reckon to proceed?
<Cimi> or how would you debug the binding?
<mzanetti> ah
<mzanetti> hmm...
<Cimi> it's happening on qt 5.2 only iirc
<mzanetti> yeah
<mzanetti> Cimi: wasn't the issue that we load the tabs somehow delayed which sets width twice and causes the binding loop detection to jump in?
<mzanetti> I think the right fix is to change the code in the tabs to be able to deal with it
<Cimi> I cannot see any warning about loop
<greyback> anyone else tried the qt5.2 ppa on their phone recently? I'm unable to swipe away the greeter now, it's flickering badly
<mzanetti> greyback: I've seen this behavior when I just installed the ppa but didn't a clean recompile against qt 5.2
<Mirv> mzanetti: I wonder if you could glance what eg.  lp:~kubuntu-packagers/kubuntu-packaging/qtfeedback-opensource-src would require to recompile against Qt 5.2? all the snapshot modules seem to fail with some sort of header inclusion problems (inclusion of headers contained within the own sources), but I don't seem to find what sort of .pro file changes would be required
<mzanetti> Mirv: ok. checking it out
<greyback> mzanetti: clean compile of unity8?
<mzanetti> greyback: yeah
<greyback> mzanetti: ok will do that
<Mirv> mzanetti: thanks. just bzr branch that and bzr bd if you have 5.2 installed somewhere
<mzanetti> ah dammit... I don't
<mzanetti> meh...
<mzanetti> Mirv: I can't install the packages in parallel to 5.0, right?
<Mirv> mzanetti: no you can't, unless of course inside chroot or such (like I do)
<mzanetti> mhm
<mzanetti> Mirv: mind pasting me the error? if we're lucky it's easy enough so I don't have to go through that now
<Mirv> I started with qt3d and now I see I can't build qt3d, qtsystems, qtfeedback or qtpim, but yet again I don't find what upstream did to eg qtconnectivity (which is now officially released) that makes it work
<Mirv> mzanetti: I'm getting eg. http://pastebin.ubuntu.com/6588894/
<Mirv> mzanetti: the plot thickens in the way that if I get the qtconnectivity snapshot we have from 20130802 I get a similar problem there, so in all likelihood it would be fixed between that date and 5.2.0 in https://qt.gitorious.org/qt/qtconnectivity/commits/
<tsdgeos> Saviq: nope :-/
<tsdgeos> dandrader: too late and too hard i'd say
<Saviq> tsdgeos, :/
<tsdgeos> Saviq: i mean, didn't get it to fail
<Saviq> tsdgeos, right
<tsdgeos> failed once
<tsdgeos> but a different
<tsdgeos>  one
<Saviq> raacieeees, where are you?
<tsdgeos> damn now it failed in my verticalJournal one :D
<tsdgeos> grrr
<tsdgeos> let's trigger the more_logs
<Mirv> mzanetti: actually, it looks like the release tarballs would have a whole "include" directory with a lot of one line include files referring various sources in the source tree.. I wonder what generates that
<tsdgeos> Mirv: sync.profile i think
<Mirv> I really need to continue tomorrow, but maybe sync.profile/syncqt could be / should be used somehow with the snapshot modules unlike before
<greyback> Saviq: standup?
<Saviq> my mumble hangs
<Saviq> on startup..
<greyback> Saviq: we see you connect
<Saviq> greyback, yeah, and then it goes B&W
<Saviq> greyback, just go on without me
<greyback> Saviq: we are
 * greyback needs to reboot
<fginther> dednick_, pong ?
<mzanetti> fginther: hi.
 * mzanetti searches for dednick's branch
<dednick_> mzanetti: doesnt exist yet.
<mzanetti> ah ok
<dednick_> didnt know how. all a  bit confusing
<mzanetti> yeah well, I'm sure fginther is helpful there :)
<dednick_> fginther: trying to get ubuntu-settings-components qml tests to run during ci.
<fginther> dednick_, I can help, what needs doing?
<fginther> dednick_, can they run during the package build?
<mzanetti> fginther: its the same as the unity8-qmluitests job
<dednick_> fginther: they have mouse interaction, is that ok?
<dednick_> fginther, mzanetti: i know that ubuntu-ui-toolkit checks if the DISPLAY variable is set when doing package tests and runs qml tests if it is. But they are pretty simple tests, so i wasn't sure if it was the same
<mzanetti> fginther: it's just about hooking this one up into the settings-components-ci jobs: https://jenkins.qa.ubuntu.com/job/ubuntu-settings-components-qmltests-saucy/
<fginther> mzanetti, dednick_, ah, if there's already a job for this, then it's just a config change to add
<fginther> mzanetti, is that really a 'saucy' job or does it need to be updated to trusty?
<mzanetti> fginther: yeah... actually I though we'd have a c2d-config merge prepared already and you'd just need to deploy... but no. the config needs to be touched still
<mzanetti> I'd say upgrade to trusty
<fginther> mzanetti, I can help with that
<fginther> dednick_, mzanetti https://code.launchpad.net/~fginther/cupstream2distro-config/ubuntu-settings-components-qmltests/+merge/199302
<mzanetti> fginther: thanks a lot
<tedg> greyback, Did you see my ping last night?
<tsdgeos> dandrader: damn now that i see, we don't support adding/removing items from the model either :D
<tsdgeos> even if it's only at the end
<tsdgeos> dandrader: would you be satistied with something that creates a random number of items of random height?
<tsdgeos> dandrader: because i'm not sure it makes sense adding support to adding/removing items when it's not on scope
<tsdgeos> Saviq: it's not on scope, right?
<Saviq> tsdgeos, initially we can say the scopes will only fill the model from the beginning to the end
<Saviq> tsdgeos, I *thinkU
<Saviq> mhr3, ââ?
<Saviq> mhr3, can/will scopes fill the model non-linearly?
<sil2100> Saviq: hi! Is there a lot of risky changes in unity8 waiting for release?
<Saviq> sil2100, shouldn't be, no
<Saviq> sil2100, let me check
<mhr3> Saviq, well, when we do resultset diffs, it'll look like it's non-linear to the listview, right?
<sil2100> Saviq: since I would really love that AP-test change released, and maybe we could release everything
<Saviq> sil2100, is safe
<mhr3> Saviq, but without diffing, it's always append-only
<Saviq> mhr3, when is "when"?
<sil2100> Saviq: could you or kgunn add a landing asks if you have a moment related to this? :)
<mhr3> Saviq, when we'll decide we need it :)
<Saviq> sil2100, doing
<tsdgeos> ok, so append only?
<tsdgeos> mhr3: no modelReset()  either?
<dandrader> tsdgeos, you mean that after creation the number of items in the model cannot change, they can only grow or shrink in size?
<Saviq> sil2100, done
<mhr3> tsdgeos, no guarantees on reset, you should support it
<tsdgeos> well, that's more work that wasn't anticipated :D
<tsdgeos> i should support lots of stuff
<mhr3> tsdgeos, the only guarantee i'm giving is that there'll be no insert-in-middle
<tsdgeos> but there's the things that will happen and the ones that wont
<tsdgeos> ok then
<tsdgeos> dandrader: so it'll take a bit more :D
<mhr3> tsdgeos, well reset should be the easiest
<tsdgeos> mhr3: sure, but non caring is even easier ;-)
<mhr3> tsdgeos, and lazy :P
<tsdgeos> let's call it time efficient
<mhr3> right :)
<mhr3> tsdgeos, but the diffing is likely to happen in february
<mhr3> Saviq, so, annotations, how do you want them?
<mhr3> separate model in each category?
<dednick_> fginther: thanks
<greyback> tedg: back. I saw you found a 65ms delay for authorizing sessions in unity-mir. I've not profiled to see why it's slow, could you open a bug on it please?
<kgunn> greyback: so, once the shell attached show/hide...its the app A that actually "asks" for the shells' animation of that ?...or is app A actually doing all of the drawing within his own context ?
<tedg> greyback, Sure, can do.  I was more pinging to see if it was something that was "bug worthy" :-)
<greyback> kgunn: the shell will animate the app's surface (e.g. the split and open animation)
<greyback> kgunn: Shell may also in future need to pass a "animationProgress" value to the app, as it looks like the app's toolbar itself will visually change during this animation. But that's later
<kgunn> greyback: cool...makes sense
<kgunn> greyback: last one...so the cookie fmt, is that something that comes via papi ?
<tedg> greyback, bug 1261801
<ubot5> bug 1261801 in Unity 8 "unity-mir starting observer takes 65ms on an Galaxy Nexus" [Undecided,New] https://launchpad.net/bugs/1261801
<greyback> tedg: thanks
<greyback> kgunn: papi will gain a open_trusted_helper("contentPicker") function. Internally it will receive a cookie from the contentPicker and tags its surface with that cookie.
<kgunn> greyback: got it, so in reality the apps really aren't aware of the cookies or surface handling
<greyback> kgunn: yep, they'll have no idea
<kgunn> greyback: ok...me likie now
<Saviq> mhr3, hey, why ResultsModel::componentValueWithFallback?
<mhr3> Saviq, cause result->title() != result->metadata("title")
<Saviq> mhr3, why?
<Saviq> mhr3, neither are mandatory, why do we treat them differently?
<mhr3> cause it's "standard attribute"
<Saviq> mhr3, bleh, they're all standard ;P
<mhr3> the api is trying to do some basic stuff very easy for the devs
<mhr3> so title is kinda mandatory, but not really...
<mhr3> meh
<Saviq> mhr3, yeah exactly ;)
<mhr3> pstolowski, maybe that should be changed really
<mhr3> pstolowski, at least it'll be consistent with the [] operator
<Saviq> mhr3, pstolowski, that can suggest to people they can't get a result with no title or art
<mhr3> the exception that was thrown suggested that quite strongly :)
<mhr3> but we got rid of that
 * Saviq says: we shouldn't treat any of the fields in any special way
<Saviq> mhr3, especially since people may want to use a different "title" field
<Saviq> like "name" for contacts
<pstolowski> Saviq, we wanted to have an minimal api for at least "generic" uses cases
<mhr3> Saviq, yea, trust me things are already loosened up quite a lot :)
<Saviq> pstolowski, even so, that should not "pass through" to the shell side
<Saviq> pstolowski, and should not really be the default, I'd say
<fginther> dednick_, ubuntu-settings-components-qmltests-trusty is all ready to go now, the next MP should execute it
<dednick_> fginther: cool. thanks for that
<pstolowski> Saviq, mhr3 there is currently a discrepancy between the outcome of result.add_metadata("title", "foo") and results["title"] = "foo". I think this needs fixing. BUT the former would throw on scope side when passing it to the shell, so I'm not sure what's the error you see
<pstolowski> Saviq, what do you mean
<pstolowski> Saviq, 'should not really be the default' ?
<mhr3> pstolowski, result->title() != result->metadata("title")
<pstolowski> mhr3, yes, I know
<mhr3> that's what spawned the question in the first place
<pstolowski> mhr3, that boils down to the discrepancy I mentioned
<Saviq> yeah, let's get rid of result-> title :)
<Saviq> done
<Saviq> and result->art
<Saviq> pstolowski, I mean that there may be wrappers around the basic API
<mhr3> pstolowski, why do we even have the add_metadata() method?
<Saviq> pstolowski, that would simplify things in "the general case", but their impl detail should not leak to the shell side
<Saviq> mhr3, pstolowski, shouldn't metadata be something that's not actually the data that's displayed?
<pstolowski> mhr3, that was added in the beginning when we were thinking in terms of 'standard' attributes and any custom attributes
<mhr3> i hate doing changes to this, but let's finalize it
<mhr3> and break the api once again
<pstolowski> I'd say, let's leave title / art wrappers in the API for basic cases, but remove add_metadata or fix it to just do what [] does
<pstolowski> albeit "add_metadata" name is a bit misleading
<mhr3> +1 for removing add_metadata
<mhr3> and perhaps metadata() too
<mhr3> or at least renaming it
<mhr3> .value()
<Saviq> mhr3, https://code.launchpad.net/~mhr3/unity-scopes-shell/component-mapping/+merge/198807/comments/462713
<mhr3_> pstolowski, eh, internet blackout, any comments after .value()?
<pstolowski> <Saviq> mhr3, https://code.launchpad.net/~mhr3/unity-scopes-shell/component-mapping/+merge/198807/comments/462713
<pstolowski> mhr3_, i'm fine with it, will do the change
<Saviq> pstolowski, I think it makes perfect sense for you to provide convenience wrappers
<Saviq> pstolowski, like SongResult()
<Saviq> pstolowski, etc.
<Saviq> pstolowski, but that should not leak to shell side I think
<Saviq> especially since that would mean we need to start thinking about versioning the protocol
<pstolowski> ack
<kdub_> ls
<Saviq> robru, the unity8 flakiness already has a bug: #1260860
<ubot5> bug 1260860 in unity8 (Ubuntu) "some autopilot tests don't use process_helpers" [Undecided,Confirmed] https://launchpad.net/bugs/1260860
<robru> Saviq, it's ok, we can merge them later. right now I'm just trying to recreate the ugly spreadsheet as closely as possible, with fresh bugs
<Saviq> robru, ok
#ubuntu-unity 2013-12-18
<Saviq> robru, hey, if you still around - any word why u8 wasn't released overnight?
<Saviq> morning, all
<tsdgeos> moooornign
<Saviq> tsdgeos, wanna do a nasty review?
<Saviq> mzanetti, â or you?
<tsdgeos> Saviq: the cleanup one?
<Saviq> tsdgeos, yeah https://code.launchpad.net/~saviq/unity8/clean-root/+merge/199314
<Saviq> tsdgeos, it's basically moving stuff around
<tsdgeos> yeah that one i was refering to
<tsdgeos> Saviq: can do
<Saviq> tsdgeos, thanks
<Saviq> tsdgeos, the tests pass, so that's 95% confirmation it's fine
<Saviq> tsdgeos, but stuff like ./build, ./run, ./run_on_device would be good to verify
<tsdgeos> yep
<Saviq> tsdgeos, one other thing that I want to do, but not sure I want to do now... is make them all QML imports, so import Unity.UI.Dash or something, instead of "../Dash" or so
<tsdgeos> hmmm
<tsdgeos> now = in this MR
<tsdgeos> or
<tsdgeos> now = after this MR
<Saviq> tsdgeos, in
<Saviq> tsdgeos, will prolly wait for dednick's indicator refactoring, though
<tsdgeos> wouldn't do it in this one
<Saviq> tsdgeos, +1
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/regenerate_pot_file/+merge/199413
<tsdgeos> we need to get better at catching this stuff
<Saviq> tsdgeos, true
<Saviq> tsdgeos, but actually... that should not be our string to translat
<Saviq> e
<Saviq> tsdgeos, it should come from whoever asked for the SIM dialog
<Saviq> tsdgeos, so let's see to fix that instead
<tsdgeos> that i don't know D:
<tsdgeos> asac:
<tsdgeos> err
<tsdgeos> asac: sorry
<tsdgeos> Saviq: sure
<tsdgeos> damnit
<tsdgeos> run_on_device updated the libc7 of the phone
<tsdgeos> and is now stuck in that "do you want to restart serveices" ncurses window
<Saviq> tsdgeos, ouch... why would it upgrade it :?
<tsdgeos> libc6 i mean
<tsdgeos> Saviq: because there's a new version out :D
<Saviq> tsdgeos, yeah, but we're not doing upgrade
<Saviq> tsdgeos, well
<Saviq> tsdgeos, probably something we're installing as deps
<tsdgeos> something must depend on it i guess
<Saviq> got built against the new one, yeah
<tsdgeos> ok, let's reboot the phone and do this manuall
<tsdgeos> y
<Saviq> tsdgeos, no need to reboot
<Saviq> tsdgeos, can do second shell and kill the dialog
<tsdgeos> too late :D
<tsdgeos> rebooting was easier ;-)
<tsdgeos> Saviq: so you opening a bug for the "we should not have this text" thing?
<Saviq> tsdgeos, fixing it, even
<tsdgeos> cool
<Saviq> mzanetti, you get a slap on the wrist for the fullscreen notifications, there's reaching out of scope all over ;P
<mzanetti> Saviq: ?
<Saviq> mzanetti, NotificationMenuItemFactory reaches to notification and notificationsList objects directly
<mzanetti> ah
<mzanetti> Saviq: I'll fix it
<Saviq> mzanetti, almost there
<Saviq> mzanetti, you'll review / test
<mzanetti> ok
<tsdgeos> Saviq: btw almost everyone's going to get a nice conflict after your clean-root thing :D
<Saviq> tsdgeos, actually not really
<Saviq> tsdgeos, I was expecting it, but bzr seems to deal fine with renames when merging
<tsdgeos> nice thing
 * mzanetti is afraid of merging the appmanager rework with that
<mhr3_> the one feature that works well in bzr... renames
<tsdgeos> Saviq: can i complain against the src/include thing?
<Saviq> tsdgeos, yes you can
<tsdgeos> Saviq: at least you should move src/Panel/Indicators/client/indicatorsclient.h to include to make it equally painful everywhere :D
<tsdgeos> i'd prefer we'd do away with that artificial separation
<tsdgeos> but oh well
<tsdgeos> let's be artificual everywhere if we are going to be
<Saviq> tsdgeos, I just didn't want "src" to be in include paths by default
<Saviq> tsdgeos, while paths.h should be available virtually everywhere
<Saviq> tsdgeos, so can we say that stuff that's only a header (paths.h, ApplicationArguments.h) would remain in include/
<Saviq> tsdgeos, but h+cpp would go into src/ ?
<tsdgeos> ApplicationArguments.h is cheating
<tsdgeos> since i could split the code over to a .cpp and then you move it to src/ :D
<tsdgeos> and it's only used by main.cpp so it would not hurt either
<tsdgeos> if you want to leave paths.h.in in include, i'm fine with that
<tsdgeos> noone ever edits that file
<mhr3_> Saviq, ehm, any idea why https://code.launchpad.net/~unity-team/+archive/demo-stuff/+recipebuild/610784/+files/buildlog.txt.gz failed?
<Saviq> mhr3_, which one is that?
<mhr3_> scopes-api in demo-stuff
<Saviq> mhr3_, I only just built unity-api in there, restarted scopes-api builds now
<mhr3_> Saviq, i did that 5minutes ago, resulted in that error
<Saviq> mhr3_, hmm maybe unity-api wasn't published yet?
<mhr3_> it was
<mhr3_> at least that's what the ppa page said
<Saviq> mhr3_, in other words, no, no idea
<Saviq> mzanetti, here's my diff, can you please take over, then - http://paste.ubuntu.com/6593292/
<tsdgeos> Saviq: so what do you want to do with the include thing? leave it as it is? or rework?
<Saviq> tsdgeos, true, AppArgs should be .cpp really
<Saviq> tsdgeos, I'll fix those
<tsdgeos> ok
<mzanetti> Saviq: yes
<Saviq> mzanetti, I'll have another one, that one breaks something
<Saviq> mzanetti, http://paste.ubuntu.com/6593326/
<Saviq> Notification vs. Item made it not start at all, for some reason :?
<Saviq> mzanetti, are there no tests for the fullscreen notification btw? I don't even know how to trigger it?
<mzanetti> Saviq: there should be AP tests for it afaik
<dednick> Saviq: https://code.launchpad.net/~nick-dedekind/unity8/StrFTimeFormatter/+merge/192343 ?
<Saviq> dednick, on it
<mzanetti> Saviq: and there are qmltests for the content (tst_Lockscreen.qml)
<dednick> Saviq: ta
<Saviq> mhr3_, built now
<Saviq> mhr3_, so must've been too early
<mhr3_> Saviq, grrr....
<tsdgeos> dandrader: seen that i added the "try" thing
<tsdgeos> ?
<Saviq> mzanetti, no tests added in https://code.launchpad.net/~macslow/unity8/notification-fullscreen-support/+merge/196308 at least
<dandrader> tsdgeos, yep, will check it out now
<Saviq> mzanetti, so it doesn't look like there are any
<Saviq> dandrader, hey, re: the unity-api test crash... I got it on stable just as well
<Saviq> dandrader, unless I did something wrong when building, but I tried not to
<Saviq> dandrader, you made sure to test under i386?
<dandrader> Saviq, yes
<dandrader> Saviq, only if stable went sour since the last time I tried it
<Saviq> dandrader, no, I actually tried the day after you tried or so
<dandrader> Saviq, do you at least get the failure in testApplication?
 * Saviq will try again
<Saviq> dandrader, don't remember, let me rinse&repeat
<dandrader> Saviq, is there a command to reload all unity7 indicators
<dandrader> ?
<Saviq> dandrader, yeah, start unity8 and Ctrl+C it ;)
<dandrader> Saviq, no
<Saviq> dandrader, you might also want "restart unity-panel-service"
<dandrader> it does not bring all the original indicators back
<Saviq> dandrader, the only remaining one should be "start indicator-application" I think
<Saviq> dandrader, which one are you missing?
<dandrader> indicator-multiload and the network one
<Saviq> dandrader, start indicator-[TAB] will let you know which are not running and can be started
<Saviq> huh, what's indicator-multiload?
<Saviq> dandrader, network is nm-applet
<Saviq> dandrader, no upstart integration, so just Alt+F2, nm-applet
<dandrader> Saviq, "Graphical system load indicator for CPU, ram, etc."
<Saviq> dandrader, k
<dandrader> Saviq,  "start indicator-application" does the trick. thanks@
<dandrader> !
<Saviq> dandrader, cheers
<Mirv> tsdgeos: thanks btw for nudging towards syncqt, it has solved all but one of my snapshot module problems
<tsdgeos> cool
<Mirv> so I'm running syncqt and generating a patch out of it, which fixed qtfeedback + qtsystems + qt3d, but qtpim seems to have some additional problem
<Saviq> tsdgeos, pushed
<Saviq> /food
<tsdgeos> dandrader: noooo, i have a todo :D
<tsdgeos> dandrader: or maybe we can do it after the merge happens
<dandrader> tsdgeos, what todo?
<tsdgeos> dandrader: as a smaller review?
<tsdgeos>     // TODO Add support for additions/removals at end that are not reset calls
<dandrader> ah
<tsdgeos> maybe we can get this big chunk merged
<tsdgeos> and then iterate on this small thing?
<tsdgeos> it'll be an easier review too
<tsdgeos> since it'll be smaller
<dandrader> tsdgeos, yes, it won't break anything anyway
<tsdgeos> oka
<tsdgeos> thanks for the review :-)
<tsdgeos> dandrader: btw don't know if you realized you can write a number in the try thing
<tsdgeos> in the area below the add button
<tsdgeos> i did not make it too obvious :D
<dandrader> tsdgeos, it did. but just from reading the code
<tsdgeos> ok :D
<dandrader> tsdgeos, indeed looks almost like a hidden feature. I though about commenting about it but I concluded that I have already harassed you enough in this review
<dandrader> and the buttons also look like they are disabled because their colors are washed out (greyish
<dandrader> )
<greyback> mzanetti: I can fix your flicker by adding a longer delay to the grantFocusTimer. I tried 100ms
<mzanetti> greyback: yeah. but doesn't sound like a solution
<greyback> mzanetti: the flicker was that Mir had changed the focused app before you had even started animating
<mzanetti> greyback: yeah. and that's what I don't understand why
<mzanetti> greyback: as I set the image to be visible and everything, then start a timer and only when the timer timeout is done, I tell Mir to actually switch the apps
<mzanetti> greyback: so in theory there shouldn't be a timer needed at all. however I could understand that I have to trigger the event loop to reflect all the states. but for that an interval of 1 should be enough
<mzanetti> greyback: the fact that an interval of 100 works around it, makes it even more scary imo
<greyback> mzanetti: sure, I'm not saying it's the right thing to do, there's just some subtle timing issue cropping up
<mzanetti> greyback: so you'd vote for going with an interval of 100 for now and hoping this will just vanish when we use real surfaces instead of screenshots?
<mzanetti> (well, I'm sure this particular isse would go away using real surfaces...)
<greyback> mzanetti: am wondering if it's due to the 2 separate event loops, one for Mir and one for Qt. Calling ApplicationManager.focusApplication causes Mir to immediately switch focus. But Qt hasn't yet generated a frame, that Mir composites, where the screenshots are visible
<mzanetti> greyback: ahhh... yeah that would make sense
<mzanetti> so Qt's event loop is actually done, but the results not yet processed by Mir's event loop
<mzanetti> yeah, that would explain this behavior
<mzanetti> and also this sounds like a thing we'd run into more often as more animations are implemented :/
<greyback> mzanetti: when we switch to scenegraph, this won't be an issue, as there only 1 event loop will be managing all drawing
<mzanetti> +1 for that
<mzanetti> so it does sound indeed like I should go with the increased interval workaround for now
<mzanetti> with a big fat FIXME to drop it again once we use the scenegraph stuff
<greyback> switching focus at the end of the animation work maybe? Or at a preset stage during the animation?
<mzanetti> yeah... I thought about that too... I guess I can do it.
<mzanetti> greyback: but I really wanted to understand what's going on... thanks for the explanation.
<greyback> mzanetti: you're welcome
<nic-doffay> Saviq, who's a good person to talk to about CI issues?
<mzanetti> Saviq: hmm... for some reason unity8 doesn't seem to register the notification service any more with ./run. It used to work if I did export `dbus-launch` and ran it in that shell. has there been a change you're aware of?
<mzanetti> nic-doffay: what's the issue?
<nic-doffay> mzanetti, I'm not sure.
<mzanetti> nic-doffay: :) ok... so why do you want to talk to someone about CI then?
<nic-doffay> mzanetti, because I think it's an irregular issue.
<mzanetti> nic-doffay: any link or something?
<nic-doffay> mzanetti, https://code.launchpad.net/~nicolas-doffay/ubuntu-ui-toolkit/fix-1242647/+merge/197176
<nic-doffay> Not sure what's causing the two fails.
<mzanetti> nic-doffay: hmm... according to the logs it seems to be a real issue, not some flakyness....
<nic-doffay> mzanetti, yeah but I can't pin point what exactly it is...
<Saviq> mzanetti, there's no need for dbus-launch any more
<Saviq> mzanetti, it takes over the name from notify-osd
<mzanetti> right.... you see my problem :P
<mzanetti> Saviq: so it seems there is an issue if there is no notify-osd running before?
<Saviq> mzanetti, shouldn't be
<Saviq> mzanetti, /me tries
<mzanetti> so in theory the dbus-launch thing should still work, right?
<mzanetti> nic-doffay: building your branches... gimme a minunute
<Saviq> mzanetti, yeah it should, works here
<mzanetti> hmpf...
<Saviq> mzanetti, well, just don't do dbus-launch, it actually stops unity8 from launching here for me
<Saviq> mzanetti, and it makes sense, as it will wait for all the services that it expects on the dbus
<mzanetti> Saviq: it starts fine here on a new session bus. just doesn't register stuff any more
<mzanetti> Saviq: last time I tried it was starting too, but took like half a minute before it gave up connecting to the hud service
<mzanetti> now it starts up immediately, but not notifications
<Saviq> mzanetti, sounds like something weird in your env, any reason why you still want it under dbus-launch?
<mzanetti> Saviq: yeah, s/notify-osd/knotify4/
<Saviq> mzanetti, right, and knotify4 does not give up the name when asked politely...
<mzanetti> yep
<Saviq> mzanetti, kill it, then...
<mzanetti> it's respowned by kded4 immediately (which I think is new too)
<mzanetti> ok... I guess I can shut down the whole session for a bit
<mzanetti> nic-doffay: that AP test fails here too
<Saviq> mzanetti, or just switch to unity7 like a good employee ;)
<mzanetti> Saviq: yeah... did that for a while. but it really sucks on this screen
<Saviq> mzanetti, ah right - good thing is that bregma is working on it this cycle
<mzanetti> nic-doffay: can't you reproduce the failure locally?
<mzanetti> nic-doffay: http://paste.ubuntu.com/6593603
<mzanetti> Saviq: to make up for not using unity on the desktop yet I started dogfooding the phone with the MWC release :D
<Saviq> ;)
<nic-doffay> mzanetti, I didn't run them locally, I figured the logs would be the same?
<mzanetti> nic-doffay: yeah. but definitely easier to change to code and run the test again
<mzanetti> Saviq: ok. running unity7 now (it did improve a bit already) but notifications still showing up in the desktop. even if I kill notify-osd
<mzanetti> with unity8 latest trunk, doing a fresh ./build -c
<Saviq> mzanetti, I was suspecting something's weird with your setup...
<Saviq> mzanetti, can you see anything related in the log output?
<mzanetti> Saviq: no... all fine in there
<Saviq> mzanetti, sounds like you need to start looking into monitoring what happens on dbus
<mzanetti> mhm
<mzanetti> ok... got it... qtdeclarative5-unity-notifications-plugin was borked
<mzanetti> duuude :D you broke the fullscreen notifications completely :D
<Saviq> mzanetti, I'm sure I did :P
<Saviq> mzanetti, couldn't test them, remember? ;P
<mzanetti> noooo. qtcreator doesn't pick up fonts dpi inside unity7
<Saviq> mzanetti, ouch
<mzanetti> Saviq: can we merge this one now? https://code.launchpad.net/~mzanetti/unity8/lockscreen-default-variable-pinlength/+merge/197848
<Saviq> mzanetti, wasn't it merged already?
<Saviq> mzanetti, got it, ACK'ed
<mzanetti> cheers
<Saviq> biab
<tsdgeos> dandrader: https://code.launchpad.net/~aacid/unity8/verticalJournalImprovements/+merge/199446
<dandrader> tsdgeos, saw it. will wait for the original one to get merged before I review this one
<tsdgeos> ok
<tsdgeos> dandrader: there?
<dandrader> tsdgeos, ?
<tsdgeos> dandrader: just pinging ;-)
<tsdgeos> dandrader: so i am doing the horizontaljournal
<tsdgeos> that shares lots of code with the verticalone
<tsdgeos> how would you prefer to review
<tsdgeos> in two steps, horizontal journal is a "copy" of the verticla one and then introduce a class which both inherit from
<tsdgeos> in one step that introduces both the horizontal journal and the class they both inherit from?
<dandrader> tsdgeos, one step
<tsdgeos> oki
 * greyback having his half day, chat tomorrow
<Saviq> kgunn, humm, weren't you supposed to be on holidays already?
<kgunn> Saviq: not yet...
<kgunn> are you trying to send me a hint :)
<Saviq> kgunn, no, not really, but was convinced you were gone :)
<kgunn> only mentally
<Saviq> kgunn, we doing hangout today?
<kgunn> Saviq: yes, let's do hangout...it'll be quick one i think
<kgunn> let's do round robin first...then cover off 1/2 announcement + deeper dive on some topics
<kgunn> it'll be quick i promise
<Saviq> nic-doffay, hangout?
<Saviq> Cimi, hangout?
<nic-doffay> Saviq, one sec.
<Cimi> Saviq, I got stuck.. I'm in now
<Cimi> who can test ubuntu-ui-toolkit compilation on qt 5.2?
<tsdgeos> dandrader|lunch: https://code.launchpad.net/~aacid/unity8/verticalJournalImprovements/+merge/199446 the parent branch has been aprroved and CI passes
<kgunn> Cimi: i think you missed the part where we discussed some manual autopilot testing to dry run /pre-test side stage re-enabling
<kgunn> Cimi: i'm putting together a list to divide that effort amongst the team...just didn't want to confuse you :) since some items got assigned to you
<kgunn> Cimi: if you have questions feel free to hit me up
<sil2100> Saviq: hi! You have a mako/maguro, right?
<sil2100> Damn, what's wrong with my mako
<tsdgeos> Saviq: i don't understand why you have columns for with and without sidestage
<Saviq> sil2100, yes, I only don't have grouper
<Saviq> tsdgeos, for comparison
<tsdgeos> Saviq: but don't we have the official numbers for that?
<Saviq> tsdgeos, in case there are failures, we need to know whether it's regressed or not
<Saviq> tsdgeos, not for manta
<tsdgeos> right
<Saviq> kgunn, right ââ we don't need "without sidestage" for mako/maguro
<Saviq> kgunn, we have "official" results for that
<kgunn> Saviq: yeah...you're right
<kgunn> thanks....
<Saviq> kgunn, tsdgeos done - two columns less
<kgunn> that'll save some time
<sil2100> Saviq: hmm... since I am using 'almost-latest-trunk' and I can't run all the tests, suddenly after some tests unity8 goes black and unresponsive
<sil2100> Saviq: that happens relatively often
<sil2100> Saviq: but it might be my device...
<Saviq> sil2100, "black and unresponsive"?
<Saviq> sil2100, as in you see it or not at all?
<Saviq> sil2100, check if apport's not collecting .crashes for it maybe
<kgunn> Saviq: tsdgeos ...just added one note...if you do get a failure on mako w/ sidestage...might want to back it out and retest the image
<kgunn> but only in case of failure
<Saviq> kgunn, yup
<sil2100> Saviq: I see a black screen - no backlight, tests not moving - after pressing the power button first the backlight appears and after a few lazy seconds I see unity8 appearing
<sil2100> But tests don't move forward
<sil2100> Saviq: you guys didn't see symptoms like this, right?
<Saviq> sil2100, no
<sil2100> Let me try downgrading and seeing if I get the same, since as I said, I stopped trusting my device
<Saviq> kgunn, I made the branch "needs review" to get packages out of CI
<Saviq> kgunn, so that we don't have to build them ourselves
<kgunn> Saviq: another excellent idea
<Saviq> tsdgeos, how do you tell qt to not build qtwayland?
<tsdgeos> Saviq: don't know :D
<tsdgeos> never built it for me :D
<Saviq> lol
<tsdgeos> you're building the supercheckout thing?
<Saviq> tsdgeos, ah, qt.pro should do ;)
<Saviq> tsdgeos, yeah
<tsdgeos> Saviq: ok, i just build the modules one by one
<Saviq> dandrader, I take that back, indeed it seems like release fixes - and yeah am getting testApplication failure
<Saviq> dandrader, I'll do some bisecting, then
<dandrader> Saviq, reported a qt bug on the testApplication failure, btw
<Saviq> dandrader, cheers
<Saviq> dandrader, which QTBUG? make sure Mirv knows about it, please
<dandrader> Saviq, I wrote about it on https://bugs.launchpad.net/bugs/1258057
<ubot5> Ubuntu bug 1258057 in Unity API "unity-api fails to build against Qt 5.2" [Critical,In progress]
<Saviq> dandrader, ah great thanks
<dandrader> Saviq, but, discussing it on qt-quick, that question made me scratch my head "<jpnurmi> aalpert-thoth: is importing singletons to a "global" namespace a supported use case?"
<mhall119> Saviq: do we have a PPA that will let me build Unity 8 on Saucy yet/
<mhall119> ?
<Saviq> mhall119, there is a ppa, not one that will let you build unity8 on saucy I'm afraid, folks are looking into it, though
<mhall119> ok
<Saviq> mhall119, i.e. unity-scopes-api fails to build on saucy: https://launchpad.net/~phablet-team/+archive/desktop-deps/
<Saviq> dandrader, yeah, it shouldn't be asked ;)
<Saviq> dandrader, like WTH not?
<dednick> mhr3_: ping
<dednick> hm. so can't play videos on tablet yet?
<kgunn> Saviq: is there something i'm doing wrong? ....i can't seem to download output.zip from them mp ?
<kgunn> i'm on vpn
<Saviq> kgunn, trying
<Saviq> kgunn, the job failed to publish
<kgunn> how does one come to know that ?
<Saviq> kgunn, http://s-jenkins.ubuntu-ci:8080/job/unity-mir-trusty-armhf-ci/48/artifact/work/output/*zip*/output.zip
<Saviq> kgunn, jenkins.qa.ubuntu.com is only a public frontend - it doesn't execute any jobs
<kgunn> thanks...
<Saviq> kgunn, the results get published to it by the real jenkins
<Saviq> kgunn, but sometimes it fails
<Saviq> kgunn, so if you get 404 from jenkins.qa.u.c - that's most probably that
<kgunn> damn....jenkins and his evil twin not-so-public jenkins
<Saviq> kgunn, published now
<Saviq> kgunn, so the MP link works now, too
<kgunn> Saviq: i was just antsy i guess
<dednick> is anyone able to play a local video on device?
<kgunn> dednick: you mean manta/nexus10 right ?
<dednick> kgunn: yeah
<kgunn> dednick: i don't have a manta...
<kgunn> ricmm: ^ should we be able to play video on manta?
<kgunn> rsalveti: ^
<dednick> hm. I manually installed gstreamer1.0-libav so that mediascanner would pick up videos, but was crashing mediaplayer-app. I removed it and now I'm getting some audio, but no video...
<dednick> ....sigh
<giuseppe___> hello
<giuseppe___> Is it possible for me to inigrate unity api in my distro???
<giuseppe___> ???
<rsalveti> kgunn: no, there's no video support for manta yet
<rsalveti> dednick: ^
<dednick> rsalveti: ta
<kgunn> hmmm....anyone tried mako yet with sidestage ?
<kgunn> going to reflash in case its me
<mhall119> Saviq: how can I make an app respond to a user tapping one of the HUD's toolbar icons?
<Saviq> mhall119, that's the wrong side of the integration you're asking me for ;)
<Saviq> tedg, ââ?
<tedg> mhall119, Ask a QML guy like Saviq
<tedg> ;-)
<tedg> I'm not sure of the QML way to do it exactly, but you need a "hud-toolbar-item" property on the Unity Action.
<kgunn> ricmm: so i  just took latest trusty image on mako....dumped unity-mir deb in from jenkins build...installed it, but i don't get anything rendered onscreen
<kgunn> ricmm: i double checked, even used devel-proposed...same thing
<mhall119> tedg: so http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.Action/ needs to be expanded to include a hud-toolbar-item?
<kgunn> ricmm: running top i can see unity8 running...and the screen is auto blanking & turning on from power button...but just no rendering
<kgunn> ricmm: is this something you would have expected ??
<kgunn> or just a bug on mako that needs fixing?
<tedg> mhall119, I'm not sure what the property name is exactly, but something like that, yes.
<kgunn> ricmm: or...am i doing something wrong ?
<mhall119> tedg: is that a DBus property name?
<tedg> mhall119, No, gmenu property name.
<mhall119> tedg: Saviq: where can I find the source for Ubuntu.Unity.Action.Action?
<tedg> mhall119, I think this is it: https://launchpad.net/unity-action-api
<ricmm> kgunn: not sure, my mako is charging right now for that matter
<ricmm> I havent tested it yet
<mhall119> well, over my head
<mhall119> tedg: Saviq: do either of you know of plans to make this possible via QML, and who's behind it?
<tedg> mhall119, The action-api was done by Wellark_, he'd probably have more ideas there.
<kgunn> ricmm: curious what you find....i'm reflashing & going to build natively...
<kgunn> just in case
<mhall119> Wellark_: ping about unity-action-api, QML and HUD toolbuttons
#ubuntu-unity 2013-12-19
<tsdgeos> Mirv: i'm wondering if the 5.2 tag makes sense in https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1256999 since it's not new in 5.2 vs 5.0
<ubot5> Ubuntu bug 1256999 in Ubuntu UI Toolkit "QFontDatabase: Cannot find font directory spams logs" [Critical,New]
<tsdgeos> also marking this bug as critical is a bit of a joke i'd say
<Mirv> tsdgeos: sure not, I removed them all
<Mirv> yeah it spams logs, otherwise not affecting anything
<tsdgeos> whatthe
<tsdgeos> http://pastebin.kde.org/pjjbsztsv <-- crash in i965_dri.so Â¿Â¿??
<tsdgeos> horizontaljournaltestExec: ../../../../src/glsl/ralloc.c:81: get_header: assertion Â«info->canary == 0x5A1106Â» failed.
<tsdgeos> did we update the intel driver lately or my machine is starting to die?
<tsdgeos> And now i get http://pastebin.kde.org/pref7ap09 :-s
<mhr3_> sil2100, is ci dead?
<mhr3_> sil2100, seeing "Permission denied (publickey,password)." in logs
<dednick> sigh... what is the calendar-app package for the phone called these days? they keep changing!!! lp has calendar-app, but it's not on the phone...
<sil2100> uh
<sil2100> mhr3_: does the same happen during re-runs? Since they had it once, and it wasn't happening always
<dednick> I see that it's a click application, but i need to run AP tests for it. Anyone know how?
<sil2100> mhr3_: I'll poke the CI guys too
<mhr3_> dednick, you will need one sacrificial dagger and a goat
<sil2100> :D
<mhr3_> dednick, eh, and the phone of course
<dednick> mhr3_: yeah, that was my assumption as well
<sil2100> dednick: https://wiki.ubuntu.com/Touch/Testing <- go here, the click tests section
<dednick> sil2100: thanks
<mzanetti> dednick: you running those test suites now?
<dednick> mzanetti: just about to start one
<mzanetti> dednick: I've just installed that unity-mir package and unity8 doesn't start any more
<dednick> mzanetti: ah. I hadn't done that yet...
<dednick> mzanetti: was going to try without sidestage first.
<mzanetti> dednick: yeah. that's the next thing that confuses me
<mzanetti> dednick: what is mako with sidestage?
<mzanetti> or how would I disable the sidestage on manta?
<dednick> mzanetti: er, well i presume it's all the same code, so need to make sure it runs with the sidestage code.
<dednick> mzanetti: and i'm also assuming that w/o sidestage is just with trunk unity-mir
<dednick> mzanetti: as we have no tests running for manta atm.
<mzanetti> dednick: yeah, but the table lists Manta with and without sidestage
<dednick> mzanetti: sure. so test with trunk, and test with sidestage unity-mir...
<mzanetti> dednick: we don't have manta without sidestage. Well, without that branch it is badly broken, but still there
<dednick> mzanetti: right, it that that funky thing that pops open on the right half of screen when you open apps? :)
<mzanetti> ok, but yeah. it probably means without this branch and with this branch
<tsdgeos> yeah
<dednick> mzanetti: dandrader seems to have run ap tests ok with sidestage branch. although given that they're not unity8 tests...
<mzanetti> tsdgeos: does unity8 still come up for you after installing that libunity-mir1 package?
<tsdgeos> still flashing image 76
<tsdgeos> i'll tell you once i'm done
<mzanetti> dednick: well, I'd say unity8 needs to be running even for the other tests
<dednick> mzanetti: hm. not sure. I think autopilot starts them using command line shizzle doesnt it?
<mzanetti> dednick: sure. but without unity8 there is no display server
<dednick> mzanetti: but yeah, he probably would have complained to somebody if it unity8 wasnt working
<dednick> mzanetti: but you can kill unity8 and start apps still no?
<dednick> mir keeps running doesn tit?
<mzanetti> I don't think so
<dednick> i dont know how it all works anymore
<dednick> should really get up-to-date sometime
<tsdgeos> mzanetti: unity8 is running, but all i see is blackness
<greyback> hi all, can I lend a hand?
<mzanetti> tsdgeos: yeah... same here
<tsdgeos> greyback: if you install https://code.launchpad.net/~ricmm/unity-mir/sidestage-reenable/+merge/198489/comments/463221 in your phone
<mzanetti> greyback: hi. unity8 doesn't come up any more after installing that libunity-mir1 package from the MR
<tsdgeos> does unity8 give you something in screen?
<tsdgeos> mzanetti: did you compile yourself or use the deb from the output.zip above?
 * mzanetti is testing on make btw
<mzanetti> and using the output.zip from jenkins
<mzanetti> s/make/mako/ ^^
<greyback> I'll need a few minutes to clean my phone. But in mean time, is unity8 crashing or anything? (please run "stop unity8" so upstart stops running it, and then "GRID_UNIT_PX=18 unity8")
<tsdgeos> greyback: nope, it is running but not showing anything on screen
<greyback> tsdgeos: hit the power button, then tap the screen. Anything then?
<dednick> mzanetti: you testing on mako or manta?
<tsdgeos> greyback: nope
<mzanetti> dednick: mako
<tsdgeos> same here
<greyback> tsdgeos: would you mind pastebinning unity8's output somewhere so I can check?
<tsdgeos> dandrader: ping-o-matic
<mzanetti> greyback: http://paste.ubuntu.com/6599109
<dandrader> tsdgeos, improvedVerticalJournal review?
<tsdgeos> dandrader: no, read âââ
<mhr3_> Saviq, ping?
<tsdgeos> dandrader: do you have a mako?
<mzanetti> this one seems a bit odd "WARNING: QApplication was not created in the main() thread."
<dandrader> tsdgeos, no, I don't
<tsdgeos> mzanetti: that's been there for ages
<mzanetti> ah ok
<tsdgeos> dandrader: ah ok
<mzanetti> yeah... dandrader's test results are only for manta (mine is still charging before I can flash it)
<tsdgeos> greyback: shouldn't "stop unity8" stop the thing?
<greyback> tsdgeos: it should
<dandrader> just turned on my manta
<dandrader> and unity8 doesn't come up
<dandrader> all blackness
<tsdgeos> ah /sbin/stop
<dandrader> when I run it manually I get
<dandrader> QXcbConnection: Could not connect to display
<dandrader> Aborted (core dumped)
<tsdgeos> greyback: silly question but how do i get the logs :D
<dandrader> So I get my test results are bogus because I might have installed the sidetage unity-mir packages and run the tests
<mzanetti> tsdgeos: .cache/upstart/unity8.log
<dandrader> without rebooting the device or at least restarting unity8
<tsdgeos> dandrader: maybe
<dandrader> damn
<mzanetti> dandrader: yeah... happened to me too. :)
<tsdgeos> ahh
<tsdgeos> so i'm not the only one having this gl problems
<mzanetti> but then I realized in the middle of the test run and reboot => blackness
<tsdgeos> good!
<tsdgeos> http://paste.ubuntu.com/6599126/
<tsdgeos> QOpenGLShader: could not create shader
<tsdgeos> that is bad :D
<greyback> yeah, what the hell
<tsdgeos> i was getting this in my laptop
<tsdgeos> then rebooted and it was gone
<tsdgeos> but why is the phone getting this
<tsdgeos> let me reflash the image
<tsdgeos> and see if this are there or not
<mzanetti> tsdgeos: reinstalling libuntiy-mir1 from the repos makes it work again
<mzanetti> don't need to reflash
<tsdgeos> mzanetti: do you also get those opengl warnings?
<mzanetti> yeah
<mzanetti> tsdgeos: http://paste.ubuntu.com/6599109
<tsdgeos> yeah same here
<tsdgeos> try to recompile in the phone?
 * greyback needs to reboot
<dandrader> yeah, reinstalling libunity-mir1 from the repos solves the unity8 not starting issue
<dandrader> (and rebooting)
<mzanetti> yup
 * mzanetti is compiling the branch on the phone now
<dandrader> so, I say this sidestage branch of unity-mir is a dud
<mzanetti> although if that works it would confuse me even more
<greyback> oh guys, you probably need to install the platform-api and qtubuntu packages too.
<dandrader> greyback, from where?
<greyback> hmm, they're not built? Looking
<dandrader> greyback, I mean whate platform-api and qtubuntu branches do we need
<dandrader> what
<greyback> dandrader: https://code.launchpad.net/~ricmm/platform-api/set-dimensions/
<tsdgeos> greyback: well we were told that unity-mir is the only thing that was needed :D
<greyback> dandrader: https://code.launchpad.net/~ricmm/qtubuntu/papi-setdimensions
<greyback> tsdgeos: well unity-mir depends on qtubuntu, so I'm guessing a little :)
<greyback> if you give me 5 mins, I'll check it out
<dednick> weird, when testing the calendar click app, it's coming up white screen, but the tests are passing...
 * greyback really wished system-image-cli output some progress info
<dandrader> tsdgeos, hey, could you finish the review of https://code.launchpad.net/~dandrader/unity8/runningTestsDoc/+merge/199186
<dandrader> ?
<tsdgeos> dandrader: sure sorry
<tsdgeos> it did not show up in https://code.launchpad.net/~aacid/+activereviews because i did not "vote"
<tsdgeos> dandrader: "Tests can be run from the build directory." -> "Tests can be run from the build directory (which if you compiled using ./build will be called builddir)" ?
<dandrader> tsdgeos, done
<tsdgeos> mzanetti: greyback: any luck with those branches?
<mzanetti> not so far for me
<greyback> tsdgeos: system-image-cli not restoring a working phone for me, resorting to phablet-flash...
<mzanetti> installing the platform api packages too makes it crash with some uncaught exception. for the other branch there aren't any packages
<tsdgeos> ^_^
<greyback> My bandwidth sucks today, only getting ~300KB/s. Were big storms here yesterday, maybe some lines were broken
<greyback> Mirv: "libqt5core5a" <- the "a" at the end is desired?
<Mirv> greyback: yes, see the Debian bug report, it was added in Debian by request from Steve L.
<Mirv> to "help" our migration. help in the sense that it forces the rebuilds.
<greyback> Mirv: ok
<greyback> well I'm guessing none of you got this fail: http://pastebin.ubuntu.com/6599363/
<mzanetti> greyback: yeah. that's the one I got after installing platform-api
<greyback> mzanetti: ah really? Ok. I'm rebuilding papi to check
<dandrader> dear cmake gurus, if I call target_link_libraries() twice for the same executable, will the second call append its libraries to the ones from the first or will it replace them?
<greyback> dandrader: http://www.cmake.org/cmake/help/git-master/command/target_link_libraries.html "Repeated calls for the same <target> append items in the order called."
<dandrader> greyback, ah, cool. The documentation here (which is the one I use) lacks this sentence: http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:target_link_libraries
<dandrader> ah, v2.8.12 has it. have to update my bookmarks
<mzanetti> Saviq: tsdgeos: how about this? would get us rid of the qmlproject file: https://code.launchpad.net/~mzanetti/unity8/qml-in-cmake/+merge/199664
<mzanetti> dandrader: I'd say yes, it appends it, not overwrite
<mzanetti> dandrader: as I'm quite sure things like use_modules(QtXXX) does that too and if target_link_libraries would overwrite it, it would break that
<tsdgeos> mzanetti: not a Creator user so can't comment :D
<tsdgeos> globs are evil otoh
<mzanetti> why?
<tsdgeos> because they fail when you add a new file and don't touch the cmakelists
<dandrader> mzanetti, QtCreator is for wussies. real men use vim
<dandrader> :P
<tsdgeos> i.e. they don't get reeavaluated
<mzanetti> tsdgeos: ah, I see...
<mzanetti> tsdgeos: well. in this case the file wouldn't show up in the project tree...
<mzanetti> dandrader: yeah. I've never been a real man in that sense
<mzanetti> and I'd argue that from that point of view vi (without m) is the only real thing :P
<tsdgeos> mzanetti: greyback: did you guys get the thing working?
 * mzanetti stopped trying
<greyback> not yet
<greyback> am working on it
<mzanetti> is Saviq not in today?
<tsdgeos> dandrader: don't approve the verticalimprovements branch
<tsdgeos> mzanetti: i'd say no
<tsdgeos> dandrader: there's a bug in the assumption we remove the last item
<tsdgeos> it may happen the model has lots of items
<tsdgeos> so the index we are removing may not be created
<tsdgeos> i'll add a test for it
<dandrader> tsdgeos, you mean because of the delegateCreation[Begin|End] effect?
<tsdgeos> dandrader: no i mean because it's a view and we don't create all the items anyway
<dandrader> ok
<mzanetti> dednick: standup
<tsdgeos> dandrader: since the other got merged, i hereby present you with https://code.launchpad.net/~aacid/unity8/verticalJournalImprovementsV2/+merge/199671
<Saviq> mhr3_, pong
<mhr3_> Saviq, unping :)
<Saviq> mhr3_, unpont
<Saviq> mhr3_, unpong, even
<mhr3_> Saviq, but since you're here, there are some reviews in unity-scopes-shell :)
<Saviq> mhr3_, yeah, I've seen, will try and get to them tomorrow
<mhr3_> k
<sil2100> Saviq, kgunn, tsdgeos: https://bugs.launchpad.net/unity8/+bug/1262743
<ubot5> Ubuntu bug 1262743 in Unity 8 "Latest lp:unity8 trunk autopilot tests fail" [High,New]
<sil2100> Saviq, kgunn, tsdgeos: this is strange, since I remember you guys said that all tests pass for you guys - might be indeed something with my device, but cyphermox had also strange results yesterday
<sil2100> cyphermox: could you comment ^ ?
<cyphermox> just not always the same results
<cyphermox> that wasn't yesterday but on the 17 though
<cyphermox> so like, revision 568 or something IIRC
<tsdgeos> sil2100: CI disagrees with you
<cyphermox> 597 it was
<Saviq> sil2100, you sure that's not ~phablet/autopilot?
<Saviq> sil2100, http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/tests/autopilot/unity8/shell/tests/test_notifications.py#L65 doesn't look for "QQuickListView" any more
<Saviq> sil2100, but for "Notifications"
<sil2100> tsdgeos, Saviq: I'm only using what's in the image + an upgrade of unity8, unity8-autopilot and the -fake-env
<sil2100> Didn't upgrade anything else
<Saviq> sil2100, "Loading tests from: /home/phablet/autopilot"
<Saviq> sil2100, you got old tests in there
<sil2100> Saviq: ...I remember we once had this issue, let me check
<Saviq> sil2100, autopilot picks up tests from /home/phablet/autopilot if they're there
<Saviq> sil2100, just drop that folder altogether
<sil2100> Saviq: let me retry, damn
<sil2100> Saviq: maybe during click package testing this directory is created and propagated with unity8 tests?
<Saviq> sil2100, indeed it is
<sil2100> Saviq: then let me re-run the tests and close the bug - and take a note about this in the wiki
<Saviq> sil2100, thanks
<sil2100> Saviq: ok, it's down to one failure now
<sil2100> This time it's Loading tests from: /usr/lib/python2.7/dist-packages
<sil2100> But still, unity8.shell.tests.test_notifications.EphemeralNotificationsTests.test_summary_only(Native Device) seems to fail
<Saviq> sil2100, can you try running that test alone?
<Saviq> sil2100, i.e. does it repeatedly fail for you?
<Saviq> sil2100, /me does the same
 * sil2100 does that
<sil2100> Even if it doesn't, I would be grateful if you guys could assign someone to look at that one, due to Didiers no-re-run-policy
<sil2100> aka. death to all the flakeys
<Saviq> sil2100, of course, we will, just getting more data
<sil2100> Saviq: it passes, so it might just be flaky
<Saviq> sil2100, can you show me the output from the failed run?
<mhr3_> Saviq, need to bother you with https://code.launchpad.net/~mhr3/unity-scopes-shell/component-mapping/+merge/198807 could you re-look at it today, without it api and shell trunk are not compatible
<mhr3_> Saviq, plus you've already seen it :)
<mhr3_> and we a pending landing ask, will ftbfs
<Saviq> mhr3_, for rawTemplate, think pretty-printing may make more sense than actually putting what the scope sent?
<mhr3_> Saviq, ui's job :)
<Saviq> mhr3_, well, you have it parsed already - we don't
<Saviq> mhr3_, on that note...
<Saviq> mhr3_, do we really need rawTemplate? can't we just put it through JSON.stringify() UI-side?
<mhr3_> Saviq, it's really raw, it isn't parsed
<Saviq> mhr3_, I mean you have it parsed anyway in m_template
<mhr3_> Saviq, UI's actual json is filled with defaults
<mhr3_> scope author won't recognize it :)
<Saviq> mhr3_, right
<mhr3_> Saviq, it's really just for the tool, i don't expect it being used elsewhere
<Saviq> mhr3_, yeah, sure, can pretty-print in the tool indeed
<mhr3_> it's actually already doing it ;)
<sil2100> Saviq: sorry, had a meeting - pastebining it
<Saviq> sil2100, no worries
<sil2100> Saviq: http://paste.ubuntu.com/6600767/
<Saviq> mhr3_, 151	+ m_rendererTemplate = category_root.value(QString("template"));
<Saviq> 152	+ m_components = category_root.value(QString("components"));
<Saviq> mhr3_, should we not emit changed?
<Saviq> mhr3_, or use setComponents / setRendererTemplate, for that matter?
<Saviq> sil2100, ok, nothing interesting, need -v output, will get it myself
<mhr3_> Saviq, it is done in collectChangedAttributes
<mhr3_> Saviq, and my latest branch changes it a bit :)
<sil2100> Saviq: I modified https://bugs.launchpad.net/unity8/+bug/1262743 to point to this bit-flaky test
<ubot5> Ubuntu bug 1262743 in Unity 8 "Latest lp:unity8 trunk autopilot shell.tests.test_notifications.EphemeralNotificationsTests.test_summary_only is flaky" [High,New]
<Saviq> mhr3_, right ok
<sil2100> SO we can 'track' it
<Saviq> sil2100, cthanks
<sil2100> Thank YOU
<Saviq> mhr3_, new unity-scopes-api released yet?
<mhr3_> Saviq, no, but in ppa if you want it
<Saviq> mhr3_, yeah, I want it
<Saviq> mhr3_, demo-stuff?
<mhr3_> yep
<mhr3_> built 48minutes ago
<Saviq> mhr3_, btw, added a lot of text to comments on the preview jsons
<mhr3_> yep, seen a mail about that
<Saviq> mhr3_, ACK'ed
<mhr3_> thx
<Saviq> mhr3_, we still treating title and icon in a special way it seems? that's going away, right?
<mhr3_> Saviq, ehm, not really
<mhr3_> that has gone away with api 0.1.6
<mhr3_> well.. mostly
<mhr3_> there are still getters/setters for convenience
<Saviq> mhr3_, mhm
<mhr3_> Saviq, where do you see them treated specially?
<Saviq> mhr3_, /me looks
<mhr3_> 376?
<Saviq> mhr3_, I actually might've been looking at category name and icon
<Saviq> mhr3_, yeah, ignore me
<mhr3_> ok :)
<mhr3_> but you should have put expiry date on that request :P
<mhr3_> robru, ping?
<robru> mhr3_, hi
<mhr3_> robru, hey, quick thing, i see your name at the landing ask for unity-api et al, working on it already?
<mhr3_> robru, well, anyway, there was an api break, so if you started to build everything an hour ago, unity-scopes-shell would ftbfs, but branch fixing that just landed
<robru> mhr3_, nope, sorry, swamped with stuff. i'll do it soon
<mhr3_> robru, good then ^ :)
<robru> mhr3_, just landed now? so everything is fine now then?
<mhr3_> yep, should be
<robru> mhr3_, ok
<robru> mhr3_, thanks for the heads up
<mhr3_> we seem to have a flaky test on slow systems, will see if you manage to hit it :/
<mhr3_> but otherwise it should be fine
#ubuntu-unity 2013-12-20
<Saviq> sil2100, hey, did you see my comment on the bug: https://bugs.launchpad.net/unity8/+bug/1262743/comments/2 ?
<ubot5> Ubuntu bug 1262743 in Unity 8 "Latest lp:unity8 trunk autopilot shell.tests.test_notifications.EphemeralNotificationsTests.test_summary_only is flaky" [High,Invalid]
<Saviq> sil2100, filed a related bug on ci processes: https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1262879
<ubot5> Ubuntu bug 1262879 in Ubuntu CI Services "There should only be one, documented, way to run tests on devices" [Undecided,Confirmed]
<sil2100> Saviq: hi, just looking at it
<sil2100> Saviq: I wonder what happened that it failed that one time on my device - maybe unity8 couldn't properly got woken up by autopilot?
<sil2100> *get
<Saviq> sil2100, no, unity8 sometimes take quite some time to tear down everything
<Saviq> sil2100, in which time it might end up the screen suspends
<Saviq> sil2100, there's no way for unity8 to wake the screen
<Saviq> sil2100, when it's starting - I wrote all of that to ubuntu-phone ML
<sil2100> Saviq: ok, so what I'll do is run the test suite again and then try doing the release
<Saviq> sil2100, yes please, make sure to keep the screen on with the powerd-cli command
<Saviq> sil2100, FWIW this only happens in trunk for you due to https://code.launchpad.net/~nicolas-doffay/unity8/upstart-kill-fix/+merge/198931
<Saviq> sil2100, before, upstart would kill unity8 after 5s
<Saviq> now it only times out after 30s
<Saviq> so before it would never take long enough to blank the screen (but also not long enough to collect a .crash, hence the override)
<Saviq> dednick, hey, can you mark affect the respective indicators that have incorrect positions: https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1262611 ?
<ubot5> Ubuntu bug 1262611 in unity8 (Ubuntu) "Network indicator hidden when there is no cellular signal" [Undecided,Confirmed]
<dednick> Saviq: sure
<Saviq> dednick, positions come from indicators now, right?
<dednick> Saviq: yep, service files if i remember correctly
<Saviq> dednick, yup, please comment on the bug what the values are now and where they need to be fixed - and mark unity8 Invalid afterwards
<dednick> Saviq: ok
<dednick> Cimi: did you run the calendar test suite yesterday? the entry is there, but i had the same results (might have just entered in incorrect box)
<Cimi> dednick, no calendars
<dednick> Cimi: ok cool.
<Cimi> dednick, and battery of the tablet is dead :D
<Cimi> willl do in a bit
<dednick> Cimi: ok, all mine failed. calendar doesnt seem to work at all with sidestage
<mhr3_> Saviq, you probably got a bunch of emails about the json doc :)
<mhr3_> thostr_, you might want to re-look at well
<Saviq> mhr3_, not yet, but will have a look
<Saviq> mhr3_, ah, so by EarlyPreview you actually mean with no round-trip between the UI and the scope
<Saviq> mhr3_, that's something I wasn't thinking about
<mhr3_> Saviq, oh, that wasn't clear?
<mhr3_> :/
<Saviq> mhr3_, yeah, I always thought about a minimal round-trip, but now I get it - and yeah, probably nothing tragic happens to the JSON structure anyway
<mhr3_> right
<Saviq> sil2100, any luck?
<sil2100> Saviq: it's as you say, the tests seem to look fine - there's like one test that fails when the screen fades out
<sil2100> But rarely
<Saviq> sil2100, cool
<sil2100> Saviq: so I'll release it once cu2d says it's ok
<tsdgeos> have you guys tried greyback debs on the nexus10?
<tsdgeos> i'm getting a diying unity8 too
<tsdgeos> nexus4 was fine
<tsdgeos> but nexus10 unity8 keeps restarting
<Saviq> tsdgeos, not restarting here, works fine?
<tsdgeos> Saviq: extra ? in your sentence?
<Saviq> tsdgeos, yeah, probably ;)
<Saviq> tsdgeos, it does not restart here
<Saviq> tsdgeos, although what mzanetti reported happens - unity8 tests don't work (but they don't on mako, either)
<tsdgeos> well i get unity8 on screen on the nexus4
<tsdgeos> nexus10 all i have is blackness
<mzanetti> tsdgeos: with AP too?
<tsdgeos> mzanetti: why would i run autopilot if untiy8 doesn't even start
<mzanetti> tsdgeos: it works fine when running it manually. But with AP it fails
<mzanetti> for me at least
<mzanetti> on Nexus 4
<mzanetti> well, both. I see the same on 4 and 10
<mzanetti> the question was rather if it works on Nexus 4 with AP for you
<dednick> is qa vpn down?
<mzanetti> dednick: can't connect either
<tsdgeos> mzanetti: sure, nexus4 is all fine
<dednick> hm. i think all jenkins is down
<dednick> oh, no
<Saviq> dednick, your branch failed due to otto failure, but couldn't restart
<dednick> Saviq: otto?
<Saviq> dednick, the testrunner
<dednick> Saviq: ah, yeah. I was trying to restart, but cant get to it.;
<Saviq> dednick, otto is the project that actually runs the tests in s-jenkins and daily build
<Saviq> dednick, yup, me neither
<dandrader> tsdgeos, greyback's sidestage packages worked for me on nexus 10 as well
<tsdgeos> :/
<tsdgeos> dandrader: image 79 ?
<dandrader> tsdgeos, but I did have a terminal on with "powerd-cli display bright" during the tests to make sure I would see what's happening throughout
<tsdgeos> my unity8 is crashing constantly
<tsdgeos> that is not my problem
<mzanetti> didn't work for me... AP doesn't work neither on nexus 4 nor nexus 10 for me
<Saviq> hmm once Nexus10 sleeps here, I can't wake it up :/
<dandrader> tsdgeos, the image number I used I put on that spreadsheet
<mzanetti> starting it manually works fine on both for me
<greyback> hey, ricmm was working on fixing bugs with his sidestage stuff, here's his latest packages: http://people.canonical.com/~ricmm/sidestage-debs.tar.gz
<Saviq> tsdgeos, I'm on 79 and works fine
<tsdgeos> that is weird :_/
 * tsdgeos reflashes and reinstalls the debs
<dednick> tsdgeos: i think mine is crashing pretty often as well. Have you got the sidestage mods installed?
<Saviq> tsdgeos, hmm maybe it crashed just now...
 * Saviq clears /var/crash
<tsdgeos> dednick: mods?
<Saviq> and maybe that's why I can't resurrect it when it goes to sleep
<Saviq> tsdgeos, he meant the .debs
<dednick> tsdgeos: the packages for sidestage we are testing with
<tsdgeos> dednick: yes, with greyback's debs crashes a lot
<tsdgeos> otherwise it's fine
<Saviq> tsdgeos, check out ricmm's debs above ââ
<tsdgeos> Saviq: how much above? :D
<tsdgeos> ah
<tsdgeos> got them
<Saviq> tsdgeos, not a lot ;)
<Saviq> lol
<Saviq> anyone else getting upside-down screenshots from time to time?
<Saviq> in the side stage, when swiping through the launcher, I'm getting upside-down screenshots sometimes ;)
<Saviq> crash
<Saviq> tsdgeos, so yeah, it's pretty crashy, not as much as yours is, probably ;)
<Saviq> greyback, you going through the issues on mako? I'll go on manta then
<greyback> Saviq: yep
<Saviq> greyback, gallery was manta first
<Saviq> greyback, should be mako?
<greyback> Saviq: oh darn, fixing
<Saviq> greyback, right-edge switch, do you see a flicker when the apps get into place (so on focus change?)
<Saviq> greyback, think it's the same as mzanetti's flicker you discussed earlier this week?
<greyback> Saviq: no actually
<Saviq> greyback, I do, on manta, will report separate
<greyback> Saviq: I do get flicker if i activate running app from launcher
<Saviq> greyback, how about upside-down screenshots? ;)
<greyback> Saviq: you're holding it wrong :D
<Saviq> greyback, no, I just can't rotate it that fast
<Saviq> tsdgeos, crashes in the application plugin here, for you?
<tsdgeos> qtubuntu somewhere
<tsdgeos> already reflashed to try ric's packages in a clean environment
<Saviq> greyback, how about general jitter when doing transitions?
<Saviq> greyback, it looks like frames are delivered in wrong order or something...
<Saviq> greyback, whenever I launch apps or switch between them, the screenshots jump around like crazy
<greyback> Saviq: aside from white flickers where screenshots not loaded yet, most animations are smooth here. I'm on image 77 though (yesterdays). I need to update to today's
<tsdgeos> ric's packages also make it die
<greyback> tsdgeos: backtrace? New Mir release was made, maybe API/ABI break
<tsdgeos> greyback: http://paste.ubuntu.com/6605309/
<tsdgeos> greyback: but it is weird, since it worked on the Nexus4 :-S
<greyback> tsdgeos: ok, looks like qtubuntu fail for tablet
<tsdgeos> greyback: want me to try to compile something manually? or?
<greyback> tsdgeos: I'll be ~30 minutes before I can reproduce. If you'd like to dig, be my guest.
<greyback> tsdgeos: https://code.launchpad.net/~ricmm/qtubuntu/papi-setdimensions/+merge/198498 & https://code.launchpad.net/~ricmm/platform-api/set-dimensions are the branches
<Saviq> greyback, tsdgeos new mir not there in image 79 yet anyway
<tsdgeos> the look of http://s-jenkins.ubuntu-ci:8080/job/unity8-ci/ is quite sad -/
<tsdgeos> i am totally puzzled as why it works for Saviq and not for me :-(
<Saviq> tsdgeos, it's pretty crashy here, too, so...
<Saviq> dudes, we got a unity8 release, thanks sil2100!
<tsdgeos> ah ok
 * Saviq awaits the 100% for unity8 on maguro finally :)
<sil2100> \o/ (finally ;p)
<sil2100> Yeah sil2100! Why did that take so long, huh?!
<sil2100> Oh, right, that's me
<Saviq> tsdgeos, otto seems to get locked again... http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/1673/artifact/results/autopilot/artifacts/unity8.shell.tests.test_hud.TestHud.test_show_hud_appears%20%28Desktop%20Nexus%2010%29.ogv
<tsdgeos> :/
<Saviq> tsdgeos, not so for the last three runs, though, so hopefully an isolated issue
<mzanetti> greyback: will we get a possibility to know when an application actually starts painting after startup?
<greyback> mzanetti: when we use the scenegraph work, yes.
<mzanetti> ok. great.
<tsdgeos> greyback: lunch calling, didn't have time to compile anything, back layer
<greyback> ok
<greyback> Saviq: just testing manta, I see what you mean about jitteriness
<Saviq> greyback, yeah, it's rather bad
<greyback> yep
<tsdgeos> greyback: any luck? did you repro the crash?
<greyback> tsdgeos: what were you doing to make it crash? I've not crashed it yet on tablet
<greyback> (no I lie, I did once, but failed to do it again)
<tsdgeos> greyback: install, reboot -> done
<greyback> tsdgeos: nope, not getting that
 * tsdgeos shakes fist
<greyback> tsdgeos: I instlled image 79, installed ricmm's packages, it's ok
<tsdgeos> same i did
<tsdgeos> greyback: you did reboot, right?
<greyback> tsdgeos: yes
 * tsdgeos tries for the fourth time
<mhr3_> Saviq, gauge!
<Saviq> mhr3_, comments? ;)
<Saviq> mhr3_, aah rating?
 * Saviq probably connects "gauge" to "12-gauge" most... not sure that's a good connection to have in the scopes system ;)
<mhr3_> Saviq, lol, i thought you're asking me to add it as a comment
<mhr3_> anyway, i did :)
<mhr3_> had to google what 12-gauge is
<Saviq> mhr3_, now you now ;)
<mhr3_> yea, at least it's not as bad as last time when i was googling something about one cup
<Saviq> mhr3_, MAN, you don't mention that
<Saviq> you DO NOT MENTION THAT
 * Saviq goes to find gasoline to pour on his eyes
 * mzanetti is curios now
<tsdgeos> greyback: insatlling all of these, right? http://paste.ubuntu.com/6605904/
<tsdgeos> greyback: that's the sha1sum
<mhr3_> mzanetti, don't be, you'll regret it
<Saviq> mzanetti, DON'T
<dandrader> heheh, I remember that one cup craziness
<mzanetti> this doesn't help, Saviq :D
<greyback> tsdgeos: http://pastebin.ubuntu.com/6605912/
<Saviq> mzanetti, really, not before christmas
<mzanetti> lol
<mhr3_> Saviq, think it'll soon claim another victim
<Saviq> mzanetti, leave it for new years
<mzanetti> ok. remind me if I forget
<dandrader> mzanetti, just keep your webcam recording you as you find out what's that about
<dandrader> will make a good video
<Saviq> ;)
<Saviq> there's probably more "guy watches two girls one cup for the first time"-type video results when you google for it these days than the actual video ;)
<Saviq> s/guy/someone/
<mhr3_> uh oh
<mhr3_> now he knows what to google for
<mzanetti> hmm...
<mzanetti> it does sound like I should not use the canonical managed google account for it
<mhr3_> leave it after work hours at least
<mhr3_> nsfw
<mzanetti> ok
<mhr3_> nsfwaa
<mhr3_> as in "not safe for watching at all"
<mzanetti> :D
<tsdgeos> nope
<tsdgeos> nothing
 * kgunn really wonders what all this one cup thing is
<tsdgeos> somethins wrong with my nexus10
 * kgunn heeds advice he sees not look
<tsdgeos> or what?
 * tsdgeos confused
<greyback> tsdgeos: it's a mystery to me, sorry
<Saviq> kgunn, do not.
<kgunn> :)
<kgunn> taking the advice
<kgunn> woohoo....AP tests running on sidedstage mako for me now!
<mhr3_> Saviq, https://code.launchpad.net/~mhr3/unity-scopes-shell/json-overrides/+merge/199508 pls?
<kgunn> guessing i just did somethign stupid
<Cimi> Saviq, you mentioned some packages, but qtubuntu is not packaged
<kgunn> hmmm...i missed standup huh
<mhr3_> mzanetti, ^ or maybe you want to see some scopes code again :)
<Cimi> Saviq, you have a special link for it?
<mhr3_> mzanetti, this time with 100% fewer threads :)
<greyback> Cimi: http://people.canonical.com/~ricmm/sidestage-debs.tar.gz
<mzanetti> mhr3_: :D
<dednick> Saviq: also noticed that apps that are supposed to be running in sidestage, actually dont under autopilot. Is that expected?
<Cimi> thx
<mzanetti> mhr3_: yeah. I guess I can do that one
<Saviq> dednick, should be fine with the packages above
<Saviq> mzanetti, thanks
<dednick> ah, new ones..
<Saviq> dednick, new ones this morning, yeah
<dednick> Saviq: oh, no, i already have those
<Saviq> dednick, hmm so they run in sidestage manually, but not under ap?
<tsdgeos> and now it works
 * tsdgeos is even more confused
<dednick> Saviq: yeah
<Saviq> dednick, that sounds like we're not reading the hint from the .desktop file in that case
<tsdgeos> Saviq: greyback: so i did the phablet-flash with --boostrap instead of the regular one and now it's working, no clue why that would mean anything different
<Saviq> tsdgeos, interesting indeed
<Saviq> dednick, since they're not launched via upstart, maybe we're not taking the stage hint into account
<Saviq> greyback, WDYT â?
<Saviq> greyback, apps not going to sidestage under autopilot?
<dednick> Saviq: hm, let me check what happens when i start with cmdline
<dednick> Saviq: yeah, that's it
<Saviq> dednick, add bug to http://pad.ubuntu.com/qP0HD1BUn4 please
<greyback> there's the stage_hint command line switch. But ricmm added to platform-api code to read the APP_ID env var, and from there open the desktop file and read the stage. So APP_ID needs to be set
<kgunn> this is excellent work guys...
<greyback> does terminal app for for anyone?
<greyback> s/for for/work for/
<dednick> greyback: looks like starting it with stage_hint=SideStage is doing "something", but not the correct thing :) it get's the size right, but the it's on the left.
<kgunn> dednick: Cimi ...i'll do the mako runs for the tests you have
<kgunn> i don't think either of you have n4s
<Cimi> kgunn, thanks
<dednick> kgunn: thanks
<greyback> dednick: another bug, please report :)
<mzanetti> mhr3_: fails to build with http://paste.ubuntu.com/6606060
<mzanetti> heh... nice pastebin number
<mhr3_> mzanetti, old libunity-api?
<mhr3_> mzanetti, update && upgrade
<mzanetti> mhr3_: on it, yeah
<dednick> out for a bit. bbl
<dandrader> unity8 is crashing for me as well on manta...
<tsdgeos> dandrader: all the time or just sometimes?
<dandrader> tsdgeos, I left the device alone for some minutes, when I came back to use it unity8 was gone. restarting it doesn't help. screen remains black even with "powerd-cli display on bright"
<tsdgeos> dandrader: adb shell and ps -A | grep unity8
<tsdgeos> is it different pids all the time?
<greyback> dandrader: recent crash file for unity8 in /var/crash/ ?
<greyback> hmm, pulseaudio using 9% of CPU on tablet after fresh boot, wonder why
<dandrader> greyback, no
<greyback> shame
<kgunn> is it normal (or unheard of) to have an upstart app launch crash is screen blanks right before an AP test runs ?
<kgunn> just checking if the crash i just saw is junk (expected)
<greyback> kgunn: I'd argue that any crash is not normal :)
<greyback> but that's news to me
<kgunn> greyback: most people run the tests correctly ;)
<greyback> dammit powerd, stop reducing my default brightness to sod-all
<tsdgeos> well
<tsdgeos> the sidestage packages are broken
<kgunn> i'm gonna say that crash was crap
<tsdgeos> not really sure makes sense testing more :D
<tsdgeos> start calculator, works, close calculator, start calculator, doesn't work, close calcular, start calculator, doesn't work, close calcular, everything blows up
<kgunn> tsdgeos: assume you mean on n10 ?
<tsdgeos> yep
<greyback> tsdgeos: yep, am seeing similar, it's fragile
<kgunn> greyback: think we have enough bugs to halt...then we can repeat this effort in the new year with a new branch ?
<kgunn> or is it useful to complete at least the AP testing
<greyback> kgunn: yep, I think we can stop. ricmm & I will start fixing the obvious problems. Since app launch & stop isn't reliable, AP will just give us lots of false fails
<mhr3_> Saviq, did you have time to rebase the scope tool on trunk?
<kgunn> ok... dandrader dednick|lunch Cimi Saviq ^
<mhr3_> Saviq, if not i can do it
<Saviq> mhr3_, no, didn't get to it - please do
<Cimi> ok
<kgunn> greyback: you and ricmm need any help ?...or is 2 cooks already crowded ?
<mhr3_> Saviq, k, got anything unpushed for the branch?
<mhr3_> if so, pls push
<Saviq> mhr3_, don't think so, let me check
<greyback> ricmm what you think? I think 2 is enough
<Cimi> now I got 55 failures
<Cimi> :-\
<Saviq> mhr3_, ready for you
<mhr3_> Saviq, thx, on it
 * ricmm readsback
<ricmm> kgunn: 2 is enough
<ricmm> kgunn: a handful of these bugs are not new bugs, these are just bugs that came from MWC, so not really regressions
<ricmm> others are simple to squash
<ricmm> 2 is good, we might have something cool in a few hours
<kgunn> ricmm: love to hear that
<mzanetti> mhr3_: added one comment. let me know if I should approve or you want to change
 * mzanetti -> away for an hour
<mhr3_> mzanetti, pushed
<mhr3_> Saviq, https://code.launchpad.net/~unity-team/unity8/unity-scope-tool/+merge/199831
<Saviq> mhr3_, cheers
<dednick> can anyone start the music app on manta with sidestage? using the application scope, not a song.
<Cimi> dednick, me
<dednick> Cimi: hm, it's working now after a reboot
<Cimi> dednick, how are tests going for you?
<Cimi> dednick, for me it's like random
<Cimi> once 5 errors, once 11, once 20
<Cimi> I dunno if I do something wrong
<dednick> Cimi: it's a struggle
<dednick> sigh.... i want to go home now :(
<tsdgeos> dandrader: if you're in monday you can have a look at https://code.launchpad.net/~aacid/unity8/horizontalJournal/+merge/199834
<Cimi> dednick, you don't work from home?
<dednick> Cimi: I am home
<dandrader> tsdgeos, I won't, but I can get started on it today
<Cimi> dednick, so why yu want to go home? :)
<dednick> Cimi: :) because I'm tired of fighting with tests!
<Cimi> dednick, it's one of the easiest days... you run your command echoing to a log file,then you use grep :P
<dednick> Saviq: do you know where to find the logs of an app trying to be started by unity8?
<Saviq> dednick, ~/.cache/upstart/application-*.log
<dednick> Saviq: just says "Error"
<dednick> Saviq: it's using upstart right?
<dednick> where are the upstart logs? :)
<Saviq> dednick, yes, upstart-app-launch to be exact
<Saviq> dednick, they *are* the upstart logs
<Saviq> dednick, i.e. if anything's output by the job, it'd be there
<dednick> Saviq: yeah, but isn't there a log for the upstart daemon?
<dednick> as in the thing calling upstart-app-launch
<Saviq> dednick, not sure
<Saviq> dednick, maybe http://upstart.ubuntu.com/cookbook/ has some info
<tsdgeos> ok, guys, happy holidays, see you next year!
<mhr3_> mzanetti, https://code.launchpad.net/~mhr3/unity-scopes-shell/scopes-list-delay-envvar/+merge/199840
<mhr3_> quick workaround for the frickin qmlplugindump issue ^
<dednick> lol, wtf is that?!
<mhr3_> dednick, that's qmlplugindump being broken pile of ...
<dednick> ahha, because it creates the objects?
<mhr3_> yea, and doesn't delete them
<mhr3_> yet it does unload the module on exit
<mhr3_> very clever
<mhr3_> scratch that, if it did it on exit, it'd be fine, it unloads it after it's done with the introspection
<mhr3_> dednick, feel free to approve it since you've looked at it :)
<dednick> mhr3_: lol, eww. don't want my name next to that!
<dednick> mhr3_: should just remove plugindump until it's fixed.
<mhr3_> we all know noone will fix it for this usecase :P
<dednick> you could!
<mhr3_> first i'd have to convince them there's a problem
<mhr3_> don't want a fix next year, want it now! :P
<dednick> mhr3_: right, and until that time, remove it! :)
<mhr3_> but then you wouldn't have introspection in qtcreator
<mhr3_> that'd be terrible
<mhr3_> dednick, and the best part - it allows me to run the tests with lower delay, so they run 900ms faster!!!
<dednick> mhr3_: is the load always supposed to be async?
<mhr3_> and that's worth it! :P
<mhr3_> yes
<dednick> mhr3_: and presumably you mean 90ms faster?
<mhr3_> dednick, no, i mean 900ms
<dednick> or 95 rather. you changed from 100 to 5
<mhr3_> dednick, each test is standalone and recreates the whole thing
<dednick> mhr3_: oh, you mean in total
<dednick> ok
<dednick> marginal! :)
<mhr3_> right?!
<dednick> mhr3_: uuu, does adding a static to clas change ABI?
<mhr3_> dednick, doesn't matter, it's a plugin, not a library
<dednick> mhr3_: is scopes.h not an interface?
<mhr3_> no, it just defines the Scopes object for qml
<mhr3_> but fwiw i don't think static would change the abi
<dednick> mhr3_: ok. good enough for me then. except that it's pretty gross. :)
<mhr3_> dednick, meh, you need to close one eye from time to time :)
<mhr3_> rather ;)
<dednick> approved
<mhr3_> thx
<mhr3_> and with that i bid farewell, enjoy holidays everyone!
<mzanetti> dednick: thanks ... was eating
<mzanetti> mhr3_: is this that qmldump issue? https://jenkins.qa.ubuntu.com/job/unity-scopes-shell-trusty-i386-ci/34/console
<mzanetti> mhr3_: doesn't like... seems a real issue somewhere
 * greyback eow, will be here Monday
#ubuntu-unity 2013-12-21
<ice9> how to change the color of the top bar?
<ice9> and where to find complete unity themes?
<pc-world> I compiled Unity from apt-get source unity (13.10) with cmake and make as suggested in the INSTALL file. However, I can't seem to properly replace my running Unity with the one from /opt/unity. Is "compiz-unity-setup-env && compiz --replace cpp & ccsm" still the way to go?
<pc-world> ok, http://unity.ubuntu.com/getinvolved/development/unity/ has some better info regarding that
#ubuntu-unity 2014-12-15
<tsdgeos> mzanetti: https://code.launchpad.net/~aacid/unity8/scopeListPageHeaderScopeStyle
<tsdgeos> camako: https://code.launchpad.net/~aacid/unity8/moreAsyncDash/+merge/241524
<tsdgeos> err
<tsdgeos> camako: sorry
<tsdgeos> Cimi: https://code.launchpad.net/~aacid/unity8/moreAsyncDash/+merge/241524
<tsdgeos> Saviq: CI is stuck again?
<Saviq> tsdgeos, I think yeah, they have issues with the phones all the time
<tsdgeos> seems i broke the Navigation tests when the fix for departments landed :/
 * tsdgeos gets to fix them
 * tsdgeos wants CI back
<Saviq> tsdgeos, it should be back now
<Saviq> tsdgeos, any MP you'd like retried?
<tsdgeos> Saviq: with phones included?
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/autopilot_drag_more
<tsdgeos>  ubuntu-support-status --show-unsupported seems a bit confused by vivid
<tsdgeos> it's telling me that vlc is past support ?Â¿
<tsdgeos> :D
<Saviq> tsdgeos, isn't it that because it's from universe?
<tsdgeos> maybe
<Saviq> tsdgeos, restarted
<tsdgeos> what's interesting is the "Can't be downloaded anymore" packages
<tsdgeos> helps clean up cruft from upgrade to upgrade
<Saviq> true
<tsdgeos> like libupstart-app-launch2-dev
<pstolowski> mzanetti, ping
<mzanetti> pstolowski: pong
<pstolowski> mzanetti, hey, do you know when is silo 9 going to land? anyone testing it?
<Cimi> tsdgeos, I was meant to test this morning but I am in a terrible pain (worse in months), I cannot even lay in bed, will try to do later
<tsdgeos> oh :/
<tsdgeos> get better
<Cimi> I have enough of this :(
<mzanetti> popey: Saviq said he'll take over of friday. So I'm assuming he's testing it
<Cimi> it's a nightmare
<Saviq> mzanetti, I am
<mzanetti> pstolowski: that was for you, 3 lines above ^, not popey
<mzanetti> :)
<pstolowski> mzanetti, ok :) thanks
<pstolowski> Saviq, hmm, you were supposed to be off today?..
<pstolowski> tsdgeos, hey, can you prepare rtm branch for your department-jumping fix? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1343242
<ubot5> Launchpad bug 1343242 in unity8 (Ubuntu RTM) "Departments break if going to a subdepartment of Store" [High,Triaged]
<tsdgeos> pstolowski: i need to fix some qqmluitests that are failing because of it first
<tsdgeos> shouldn't take long
<Saviq> pstolowski, no, starting tomorrow
<Saviq> pstolowski, we don't do separate MPs for rtm, but a single "staging" branch, similar to https://code.launchpad.net/~unity-team/unity8/rtm-14.09-staging/+merge/244568
<Saviq> pstolowski, and department jumping will have to wait for our rtm silo 7 to land first
<pstolowski> Saviq, sure, it will wait, i'm just collecting / preparing branches
<Saviq> pstolowski, got it
<Cimi> tsdgeos, landing 009 right?
<tsdgeos> Cimi: do not know
<Cimi> found a not-so-painful position
<Cimi> iirc was 9, let's see
<Cimi> yeah
<Cimi> tsdgeos, Saviq might be unrelated, but in silo 9 the manage dash text colors are white on grey
<Saviq> Cimi, right, I was supposed to write to tsdgeos about this
<tsdgeos> pstolowski: ping
<pstolowski> tsdgeos, pong
<Cimi> mmm
<tsdgeos> pstolowski: the count property of navigations, is it *always* avaialble, or only after navigation.loaded is true?
<Cimi> tsdgeos, I see frame skips switching to/from the reddit scope
<tsdgeos> you have good eyes sir :)
<Cimi> tsdgeos, well they are many :D
<tsdgeos> many eyes!?
<tsdgeos> run to a doctor!
<Cimi> lol
<Cimi> skipped frames
<tsdgeos> yes
<tsdgeos> that is known, this branch just makes things better
<tsdgeos> noone said it makes things perfectly smooth
<Cimi> tsdgeos, yes, I mentioned reddit because it seems to be most affected
<Saviq> tsdgeos, so, white-on-grey in Manage Dash header, we'd need the scopes scope to fix that, right?
<Saviq> tsdgeos, also, ETA on the navigation fix? could include in the silo, as have to rebuild anyway
<tsdgeos> Saviq: i guess yes
<tsdgeos> Saviq: the navigation fix is waiting on pstolowski's answer
<Saviq> tsdgeos, k
<tsdgeos> i have a thing in the mock that makes the code not work, but not sure if the mock is doing what the real plugin does or not
<tsdgeos> because with the real plugin it seemed to work
 * Saviq will wait for that then
<pstolowski> tsdgeos, count is the number of child departments of given department model. i think loaded can be false in some cases - "m_loaded = !treeNode->isLeaf() && treeNode->childCount() > 0;" - this is what mhr3 put there, not sure what was the purpose of that property
<tsdgeos> pstolowski: that doesn't answer my question on if count will always be valid or just after loaded is true :D
<Saviq> tsdgeos, I'm not sure about https://code.launchpad.net/~aacid/unity8/scopeListPageHeaderScopeStyle/+merge/244578, do we really want the scope to control the visuals?
<tsdgeos> Saviq: well, that's what they do everywhere, no?
<Saviq> tsdgeos, yeah, but they don't, here
<Saviq> tsdgeos, I mean you overrode the delegates, not actually using CardCreator and such?
<tsdgeos> yes
<tsdgeos> i mean, i just did that because you wanted it :D
<Saviq> tsdgeos, so yeah, the customizations will only control the header colours, which I'm not sure should be the case
<tsdgeos> i can revert it again
<tsdgeos> and you'll complain the header color is not the same header color than in the other scopes
<Saviq> tsdgeos, well, I wanted for the page header to have the correct color, it didn't seem like it did
<tsdgeos> what is "the correct" color?
<Saviq> tsdgeos, the one from designs ;)
<tsdgeos> i.e. the one used by the scopes
<tsdgeos> by not putting it in the scopes we have it in two places which means that they will get off sync easier
<tsdgeos> but i'll discard it and hardcode the colors
<Saviq> tsdgeos, I agree that the default in ScopeStyle seems wrong, simply, as they changed it in, I think, every scope
<Saviq> tsdgeos, so maybe the default is what we should change
<pstolowski> tsdgeos, it looks like count() will only be valid if loaded is true. (however, if it's a leaf, loaded will be false)
<Saviq> pstolowski, yeah, because a leaf has no children, so there's no loading
<tsdgeos> Saviq: you got me lost there
<tsdgeos> Saviq: default of what?
<Saviq> tsdgeos, hardcode for now
<Saviq> tsdgeos, and we'll find out whether we should change the default in ScopeStyle
<pstolowski> Saviq, yeah
<Saviq> tsdgeos, and maybe use it then
<tsdgeos> pstolowski: so loaded will be always false for leaves?
<pstolowski> tsdgeos, looks to me that way, yes.
<tsdgeos> that's terrible :/
<dandrader> Saviq, could you show me the log with the test errors for https://code.launchpad.net/~dandrader/unity8/greeterRefactoring/+merge/243823
<tsdgeos> pstolowski: we started to use the count to know if on a "jump" i'm on a leaf or not, but i can't use the count until it's loaded and now you say for leaves loaded is never true, so can't basically use rowCount :/
<dandrader> Saviq, they pass on my machine
<tsdgeos> which means that fix doesn't work at all
<Saviq> dandrader, sure, sec
<pstolowski> tsdgeos, somehow it worked, i tested it...
<pstolowski> tsdgeos, but i hear you...
<tsdgeos> pstolowski: sure, because i'm ignoring loaded for now
<tsdgeos> but i should not
 * dandrader merges trunk and tries again
<Saviq> dandrader, it could, in theory, be related to one of the other MPs in the silo, but nothing springs to mind (and having reverted your MP the tests passed) http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-009
<dandrader> Saviq, so you're not getting these errors locally but on the silo?
<Saviq> dandrader, yes, locally
<Saviq> dandrader, just testing on trunk + your branch now
<tsdgeos> pstolowski: so either we decide that count will always be immediately available (as it seems to be in your plugin but not on my mock)
<pstolowski> tsdgeos, shall i report loaded=true for leaves then? we would need to think what happens when scope says 'no leaves' for deaprtment foo, and then changes its mind later with another search
<tsdgeos> of if we need to make count wait on loaded i need it to be true
<tsdgeos> pstolowski: loaded true for leaves would be nice
<pstolowski> tsdgeos, i cannot make count immediately available (well, it's always available, just 0 if not loaded ;))
<tsdgeos> pstolowski: honestly i'd replace
<tsdgeos>     m_loaded = !treeNode->isLeaf() && treeNode->childCount() > 0;
<tsdgeos> with
<tsdgeos> m_loaded = true;
<pstolowski> tsdgeos, hmm i would be more comfortable setting it true only if isLeaf() is true OR childCount > 0
<tsdgeos> pstolowski: ok
<Saviq> dandrader, huh, now they passed, as you were, then
<pstolowski> tsdgeos, ok, i'll create branch for that
<tsdgeos> tx
<dandrader> Saviq, \o/
<facundobatista> Hola!
<Saviq> o/
<Saviq> tsdgeos, looks like CI is back indeed
<tsdgeos> yep
<Saviq> greyback_, just noticed where `hash -d` beats jump or wd, it actually gets expanded by the shell, so you can use it in all commands and it will Just Workâ¢
<greyback_> Saviq: hmmm true
<greyback_> but I've never missed that before, so I'll stick with jump :)
<Saviq> greyback_, sure, just saying
<greyback_> Saviq: yep, good find tho
<Saviq> tsdgeos, please let me know when you have the test fix and the colour hardcoding, need to rebuild the silo then
<tsdgeos> yeah working on the test thing
<tsdgeos> it's not a test only change
<tsdgeos> needs reworkingg
<Saviq> tsdgeos, yeah I understand
<tsdgeos> and this think it's very fragile
<Saviq> tsdgeos, not trying to put pressure here, just asking for a ping when you're ready
<tsdgeos> broke it all on the rework
<dandrader> oh, it seems Jenkins has returned from the dead
<dandrader> tsdgeos, does that look familiar? https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/203/?#showFailuresLink
<tsdgeos> dandrader: yeah fixing them
<tsdgeos> they snuck while CI was ahving a sleep
<mzanetti> tsdgeos: hey, just accidentally flashed vivid to my dogfooding phone. and now that I see it with many installed apps, I noticed that the issue with disappearing icons on scrolling is back
<greyback> Saviq: could I get a +1 please? https://code.launchpad.net/~mir-team/qtubuntu/gles-sync/+merge/244621
<greyback> anyone seeing this with building unity8 http://pastebin.ubuntu.com/9528509/
<Saviq> greyback, no
<tsdgeos> mzanetti: yes
<tsdgeos> mzanetti: there's so much i can do between "don't load everything to not kill the phone" and "things are not there if i scroll fast"
<mzanetti> I see
<tsdgeos> mzanetti: https://code.launchpad.net/~aacid/unity8/moreAsyncDash/+merge/241524 may or may not help
<tsdgeos> Saviq: for the test fix, we need a unity-scopes-shell fix
<tsdgeos> Saviq: should it go into a separate silo or the same silo you're preparing?
<Saviq> tsdgeos, if there's an MP up, let's land it together, pstolowski?
<Saviq> ah it's already in a separate silo
<Saviq> tsdgeos, let's land separately then, I'm just waiting for the manage dash colors then
<tsdgeos> ok
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/scopeListPageHeaderScopeStyle/+merge/244737
<Saviq> tsdgeos, thank
<Saviq> s
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/autopilot_drag_more autopilot passed
<tsdgeos> maybe merge?
<tsdgeos> while we decide what to do with the qt code
<Saviq> tsdgeos, ok, you thinking it's better than before? apart from the backwards gesture?
<tsdgeos> Saviq: well it workarunds the backwards gesture thing
<Saviq> tsdgeos, think it would make sense to abstract to a function?
<Saviq> tsdgeos, the rate calculation at least
<tsdgeos> by making sure we just move in multiples of the move
<tsdgeos> Saviq: one line?
<Saviq> tsdgeos, hmm? 25-26 and 44-50 look the same?
<tsdgeos> they don't
<tsdgeos> one is forward and the other backward
<Saviq> hmm jump and width
<Saviq> ah ok
<Saviq> not like it couldn't be made work, but ok
<tsdgeos> sure, i can move rate, jump and divisions to a function that returns jump and divisions
<tsdgeos> the amount of code would be probably more than less
<tsdgeos> mzanetti: Saviq: one day, we need to code the ubuntushape to png cacher, i feel sad every time i think the billions of battery power we're wasting in shaping icons again and again and again and again
<Saviq> tsdgeos, bug #1311599 indeed
<ubot5> bug 1311599 in ubuntu-ui-toolkit (Ubuntu) "UbuntuShape should be available as an image provider" [Undecided,Confirmed] https://launchpad.net/bugs/1311599
<draven33> need some help with compiz in 14.04  i activatewd dual loghin compoz and metacity an can't align the 3d windows on the cube they form outside the cube
<Saviq> greyback, I must say the global history in zsh trips me up every time
<greyback> Saviq: yep
<greyback> I tried turning it off but didn't succeed somehow
<greyback> but I got more used to ^R to use old commands
<Saviq> indeed, which is probably better in the long run anyway
<greyback> that was my thinking, but I still miss up-up-enter being reliable
<greyback> one of those things I wanted to fix, but never got the time
<Saviq> pstolowski, is https://code.launchpad.net/~stolowski/unity-scopes-shell/manage-dash-rtm/+merge/244117 supposed to be WiP still?
<Saviq> pstolowski, and is anything beyond what's in http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-007 needed in this silo (apart from the unity8 changes which I'll take care of?
<Saviq> )
<om26er> rsalveti, this time after taking the photo, I got a crash again https://errors.ubuntu.com/oops/ca4ad358-846d-11e4-b78b-fa163e5bb1a2
<om26er> and now I am sure I have the right tarball and the silo.
<Saviq> cwayne, hey, question for you, as I saw you had a PPA with galileo (the fitbit sync thing), does it work reliably for you?
<cwayne> Saviq: it did until i got the new fitbit, but i think i may just need to update it
<Saviq> cwayne, my wife got a Flex and it's only really working once after the dongle's plugged in / galileo restarted
<Saviq> cwayne, could be
<cwayne> Saviq: hm, i do recall the dongle needs to be plugged in to start it, but it should also try to respawn if it failed to start
<cwayne> Saviq: but once it's plugged in and restarted, it works?
<Saviq> cwayne, I mean that unless I unplug and replug, it doesn't work, it only works the first time after I plug the dongle and restart the service
<Saviq> cwayne, at least that seems to be the case, did not dig in too much
<cwayne> ah, that is odd
<Saviq> and there's so many warnings/errors in the log it's unclear which are benign...
<tsdgeos> dednick: do you think you could add a second line in the commit message of https://code.launchpad.net/~nick-dedekind/unity8/lp1385331.led/+merge/241417 explaing a bit more what's going on? i mean it does what seems quite a bit of refactor in plugins/Unity/Indicators
<pstolowski> Saviq, no, it shouldn't be wip. unity-scopes-shell needs additional fix from the vivid silo you tested today
<rsalveti> om26er: can you always get that crash?
<rsalveti> it seems quite weird, not necessarily related with that silo
<rsalveti> let me flash again and re-test that silo
<om26er> rsalveti, first camera-app crashed for me, then next time gallery-app crashed
<rsalveti> that's weird, shouldn't be related
<om26er> this silo does not feel safe to me
<rsalveti> and victor didn't get any crash
<rsalveti> well, will try to reproduce first
<rsalveti> this is the first time you got the right setup it seems
<om26er> the thumbnailer works in gallery, so the gallery crashed at the stage when it was creating thumbnails, same for camera-app it crashed after it took the photo
<ChrisTownsend> mzanetti: Hey, question about the Unity 8 windows.  Is it possible to open a window already maximized, ie, no surface resize after the window is opened?
<mzanetti> ChrisTownsend: not yet
<tsdgeos> dednick: https://code.launchpad.net/~nick-dedekind/unity8/lp1385331.led/+merge/241417/comments/603644
<ChrisTownsend> mzanetti: Ok.  It would be very helpful for XMir apps to do this since resizing is not yet supported between XMir/Mir/Unity8 and opening maximized would be an easier short term solution.
<ChrisTownsend> mzanetti: Right now Xmir apps are basically useless in desktop mode.
<mzanetti> ChrisTownsend: noted. I'll see what I can do
<ChrisTownsend> mzanetti: Thank you!
<tsdgeos> dednick: how do i add/remove messages?
<dednick> tsdgeos: http://paste.ubuntu.com/9530101/
<dednick> tsdgeos: need to install libmessage-menu-dev python-gi
<tsdgeos> dednick: and how do i remove them?
<dednick> tsdgeos: stop the script running
<tsdgeos> ah, ok
<Saviq> greyback, still here? could you prep an MP with the sigstop raise in mock AppMan?
<Saviq> (in unity8 that is)
<greyback> Saviq: am here. Ok
<Saviq> greyback, otherwise AP tests hang
<greyback> ah feck yeah
<greyback> Saviq: https://code.launchpad.net/~gerboland/unity8/sigstop-emit-for-AP/+merge/244781 shoulddo, not tested yet tho
<Saviq> greyback, why not in AppMan's c'tor?
<Saviq> just asking, not saying it's wrong
<greyback> Saviq: mainly to match what I did in qtmir
<Saviq> kk
<greyback> don't think it's possible to copy AppMan
<dkessel> ChrisTownsend: good news. I cannot reproduce the freezing bug anymore with current unity8-in-lxc! i am actually currently using it
<ChrisTownsend> dkessel: Awesome, glad to hear it!
<dkessel> i cannot enable automatic crash reporting using the UI from lxc it seems
<ChrisTownsend> dkessel: I don't think there is automatic crash reporting yet in Unity 8.
<dkessel> ChrisTownsend: oh okay
#ubuntu-unity 2014-12-16
<tsdgeos> Cimi: how's the back?
<Mirv> Saviq: ok Qt 5.4.0 Unity8 problem is probably because Oxide fails to build, because of which webbrowser fails to build, and unity8 depends on those. now that the symbols and ABI bumps are there in the landing PPA, things like these become more visible.
<Mirv> unfortunately it means we still can't see how Unity8 would look with 5.4 :(
<facundobatista> v
<facundobatista> Holas
<bpierre_> Hello, I am trying to build UnityÂ 8 from 15.04, I ran ./build.sh -s without any issue, then ./build.sh, and I got these errors: http://paste.ubuntu.com/9538691/
<bpierre_> It looks like some dependencies are missing, but since everything should have been installed by ./build.sh -s, I am hesitant to try to install them manually. Does anyone has any idea of what is happening?
<vesar> mzanetti, any idea what's going wrong in pierre's setup^
<sil2100> mzanetti: hey, you around?
<sil2100> mzanetti: will you be taking care of silo 007 ubuntu-rtm in Saviq's stead?
<Cimi> tsdgeos, worse than yesterday
<tsdgeos> Cimi: dorg, :/
<Cimi> tsdgeos, I have to go for some therapies, will be back in 1h - on the silo with the async branch only issue I see is the manage dash header colors
<tsdgeos> Cimi: all that landed already :D
<Cimi> tsdgeos, cool :D
<mzanetti> sil2100: yes
<mzanetti> vesar: well, missing dependencies
<sil2100> mzanetti: so, silo 003 ubuntu-rtm has unity-scopes-shell in it and is ready to land (after QA sign-off), so probably you will have to rebuild it in silo 007 once that happens
<mzanetti> ok
<mzanetti> sil2100: actually there's an issue in that silo7...need to land something to vivid first
<sil2100> mzanetti: what's the problem?
<mzanetti> a bug found in testing the silo
<mzanetti> tsdgeos: is this the fix for the issue Saviq mentioned in his mail? https://code.launchpad.net/~aacid/unity8/ellideManageDash/+merge/244831
<tsdgeos> mzanetti: yep
<tsdgeos> mzanetti: pstolowski's landing it to vivid
<mzanetti> ack
<tsdgeos> i find the need of Layout.fillWidth: true disturbing
<pstolowski> tsdgeos, mzanetti currently building
<mzanetti> tsdgeos: why?
<mzanetti> pstolowski: nice, thank you. please keep me posted on this one
<tsdgeos> mzanetti: i'd expect the column layout to do that already, or at least use the width as a maximum
<mzanetti> tsdgeos: +1 for the width as a maximum... not so much for the fillWidth: true, as you might want to control which column stretches
<tsdgeos> sure
<tsdgeos> anyhow, it's just me complaining, the code should be fine :D
<mzanetti> ok :)
<sil2100> mzanetti, pstolowski: silo 007 is rather important to land for this milestone, so we'd really like it to be landable ;)
<sil2100> Thanks guys!
<pstolowski> sil2100, absolutely, i know
<pstolowski> sil2100, when does the window close?
<sil2100> pstolowski: by teh rules we should at least have all the fixes in silos by the end of today US TZ EOD
<tsdgeos> dednick: added comment to https://code.launchpad.net/~nick-dedekind/unity8/lp1385331.led/+merge/241417
<pstolowski> sil2100, what if we have another one in the queue (rtm landing 01). can we have multiple at eod?
<pstolowski> sil2100, and also another one is still in qa testing
<pstolowski> mzanetti, tsdgeos silo 10 has been built
<tsdgeos> cool
<mzanetti> pstolowski: is it already tested?
<pstolowski> mzanetti, no, just built
<tsdgeos> pstolowski: vivid right?
<pstolowski> tsdgeos, yes
 * tsdgeos flashes vivid and gives it a small deparments test
<pstolowski> tsdgeos, pls check ebay/amazon scopes, they're pretty department-heavy
<tsdgeos> ye
<pstolowski> im also reflashing to test
<vesar> mzanetti bpierre_ , Yeah I figured that out but shouldn't those dependencies be installed automatically when running the build setup. At least I can't recall I needed to manually install missing dependencies
<mzanetti> vesar: yeah, should work in theory
<mzanetti> haven't used it in a while
<vesar> mzanetti, ok we'll try installing those missing ones manually. Cheers.
<mzanetti> vesar: sudo apt-get build-dep unity8
<mzanetti> vesar: please pastebin the output of ./build.sh if you want me to have a look why it doesn't work
<mzanetti> ./build.sh -s
<dednick> tsdgeos: ta
<bpierre_> mzanetti: I am trying that now, thanks
<mzanetti> bpierre_: looks like "./build.sh -s" fails for some reason for you. please pastebin the output of it
<bpierre_> mzanetti: itâs compiling now, I think I just had to install these packages first
<bpierre_> ./build.sh -s was working before, and I launched it again after the packages installation
<Wellark> dednick: around?
<Wellark> could we have a hangout on couple of things today?
<Wellark> sim unlock dialog "blink" and dialog service
<bpierre_> mzanetti: thanks very much, everything is working now!
<mzanetti> bpierre_: great :)
<dednick> Wellark: dont know what those are, but yes, we can.
<Wellark> dednick: marvellous :)
<dednick> Wellark: actually, what dialog service?
<dednick> Wellark: i think you might be talking notifications?
<Wellark> dednick: the discussion of splitting notifications and actual dialogs
<Wellark> as in the dreaded pin unlock dialog
<dednick> Wellark: right. is MacSlow not your man on thaT?
<Wellark> dednick: sure. I just want to check something with you quickly that only affects unity8
<dednick> Wellark: ok. now?
<Wellark> but the primary topic is the "blink" you get with the pin unlock dialog on rtm
<Wellark> dednick: sure
<Wellark> let me just grab a cup of coffee
<pstolowski> tsdgeos, uhm, something breaks with that silo
<pstolowski> tsdgeos, go to amazon scope
<pstolowski> tsdgeos, then baby products -> categories -> baby & toddler toys
<pstolowski> tsdgeos, now, click '<Categories' to go back. no results  and no departments
<pstolowski> tsdgeos, correction: results are there, but departments are missing
<Wellark> dednick: https://plus.google.com/hangouts/_/g276vj2u5pydrnjbkxkovsjijia
<tsdgeos> pstolowski: hmm, that's right
<tsdgeos> let me see
<pstolowski> tsdgeos, hmm, perhaps the scope is buggy
<tsdgeos> why is it different on the phone than in the laptop?
<tsdgeos> i get different layout :S
<pstolowski> tsdgeos, yeah, no problems with ebay departments. the silo looks good to me
<tsdgeos> pstolowski: let me see if i can repro the problem with unpatched unity8
<Wellark> tsdgeos: did you still have the patch for compiling unity8 on utopic?
 * Wellark should allocate some time during the holidays to upgrade all of the machines to vivid
<pstolowski> tsdgeos, ok, great. i saw weird things before and i remember facundobatista told me about crazy stuff he needs to do to get stuff right there
<tsdgeos> Wellark: not really sorry :/
<Wellark> or! I could just grab utopic trunk for unity8
<Wellark> yeah.. will do that
<tsdgeos> pstolowski: yeah same error is in unpatched unity8
<tsdgeos> so it should be fixed either in unity8 or in the scopes
<tsdgeos> but is not a regression of this change
<Wellark> Saviq: where is lp:unity8/utopic?
<tsdgeos> Wellark: saviq's on holiday
<tsdgeos> i don't think there is tbh
<Wellark> lp:unity8/rtm-14.09 is probably what I want then
<pstolowski> tsdgeos, agreed. other scopes work fine
<pstolowski> tsdgeos, do you want to test anything else, or can i mark the silo as tested?
<tsdgeos> pstolowski: i tested all i could think that may break, mark it as tested
<tsdgeos> dandrader: wohoohho, summer holidays \o/
<dandrader> tsdgeos, :D
<facundobatista> pstolowski, tsdgeos, don't know what are you talking about, but if I can be of any help, just tell me!
<dandrader> on countdown mode now :)
<pstolowski> facundobatista: <pstolowski> tsdgeos, go to amazon scope
<pstolowski> <pstolowski> tsdgeos, then baby products -> categories -> baby & toddler toys
<pstolowski> <pstolowski> tsdgeos, now, click '<Categories' to go back. no results  and no departments
<pstolowski> <pstolowski> tsdgeos, correction: results are there, but departments are missing
<pstolowski> facundobatista, ^
 * facundobatista checks
<pstolowski> facundobatista, also, a couple of times while playing with amazon I got this in smart scopes proxy log:
<pstolowski> facundobatista, [2014-12-16 12:18:33.143046] ERROR: SSRegistry: SmartScopesClient.get_search_results(): Failed to retrieve search results for query 39: unity::ResourceException: Error downloading https://dash.ubuntu.com/smartscopes/v2/amazon/search?q=&session_id=a0926175-c194-459a-ac1b-e05541f14a3d&query_id=0&platform=phone&department=Books%3A51546011&locale=en_US&filters=%7B%22sorting_primary_filter%22%3A%5B%22__featured__
<pstolowski> %22%5D%7D%0A - server replied: Proxy Error
<pstolowski> sil2100, silo 10 tested, can we get published asap?
<pstolowski> mzanetti, ^
<sil2100> pstolowski: o/
<sil2100> pstolowski: https://code.launchpad.net/~stolowski/unity-scopes-shell/load-is-true-for-leaves/+merge/244731 unapproved!
<sil2100> btw. pstolowski your team doesn't normally use top-approvals?
<pstolowski> sil2100, uh, we do, an oversight
<sil2100> Because if there are projects that don't do top-approvals, maybe we'll have to change the process and checks
<dednick> tsdgeos: replied. not my fault! :)
<dednick> tsdgeos: try cycling the screen on/off after the restart.
<pstolowski> tsdgeos, can you top-approve that change^ ?
<mzanetti> pstolowski: done
<pstolowski> mzanetti, thanks!
<pstolowski> sil2100, it's approved now
<facundobatista> pstolowski, filed https://bugs.launchpad.net/ubuntu-rest-scopes/+bug/1403065 for the "proxy error" you mentioned, checking the other one
<ubot5> Launchpad bug 1403065 in Ubuntu Rest Scopes "Amazon scope hits backend too much for some department cases until it gets a 503" [High,Triaged]
<pstolowski> facundobatista, thanks
<tsdgeos> dednick: sure a power cycle fixes it, but... is there nothing you can do?
<facundobatista> pstolowski, and this is the bug for the other behaviour: https://bugs.launchpad.net/ubuntu-rest-scopes/+bug/1403072
<ubot5> Launchpad bug 1403072 in Ubuntu Rest Scopes "Amazon scope doesn't respect user navigation, returns a parent not where the user came from, but what Amazon backend indicates" [High,Triaged]
<pstolowski> facundobatista, ok, thanks
<pstolowski> tsdgeos, mzanetti can you prepare a rtm branch for unity8 once silo 10 lands in vivid?
<tsdgeos> i don't know how that works. mzanetti do you?
<mzanetti> pstolowski: just waiting for it to cherry-pick the commit
<pstolowski> ack
<mzanetti> tsdgeos: I fail to find the place where we miss the elide mode
<tsdgeos> whre?
<mzanetti> https://code.launchpad.net/~aacid/unity8/ellideManageDash/+merge/244831
<tsdgeos> mzanetti: remove "Layout.fillWidth: true" and run make tryDash
<tsdgeos> see how it looks
<tsdgeos> mzanetti: stuff merged
<tsdgeos> mterry: you there?
<mterry> tsdgeos, yup!
<tsdgeos> mterry: how "urgent" is https://code.launchpad.net/~mterry/unity8/cleanup-greeter-dbus-test/+merge/244460 ?
<tsdgeos> i'm a bit scared of those dbus-launch
<tsdgeos> more when i remember Saviq mentioned he was having trouble precisely because of that in the branch he's doing to merge the tests as autopackage test
<tsdgeos> or something
<tsdgeos> is it ok for me to abstain and wait for next year? or we need to land this?
<mterry> tsdgeos, it's just moving a dbus-launch call from one place to another (and adding it to the 2(?) existing tests that use that macro)
<mterry> tsdgeos, there is another branch that deps on this one... let me find it
<tsdgeos> mterry: you mean noone else is using add_binary_qml_test?
<mterry> tsdgeos, ah.  https://code.launchpad.net/~mterry/unity8/test-early-disable/+merge/244461 deps on it.  So not urgent no
<mterry> tsdgeos, one other test at least is.  Maybe two
<mterry> tsdgeos, it's not a common macro, no
<tsdgeos> mterry: right, 5 tests
<tsdgeos> but the others don't use it
<tsdgeos> i'm going to pass on this for the moment
<mzanetti> pstolowski|lunch: tsdgeos: FYI. silo 7 building
<tsdgeos> don't want to make it harder for Saviq than it is
<willcooke> hrm, I think I might well have been disconnected when I sent this (if not, sorry for the spam):
<willcooke> <willcooke> hey mzanetti - is there any way I can pass in an initial window size to an application running in u8 from the .desktop file?
<willcooke> <willcooke> or poke it via cli to achieve the same
<willcooke> <willcooke> (I'm happy with a hack)
<mzanetti> willcooke: no, not yet
<willcooke> mzanetti, no worries
<willcooke> thx
<mzanetti> willcooke: what's the use case?
<mzanetti> willcooke: I guess I could try to set something more meaningful by default until we support the real thing
<willcooke> mzanetti, it's a hacky one for xmit
<willcooke> xmir
<tsdgeos> kgunn: can you accept our invitation to bug control? or know who has to?
<mzanetti> willcooke: so tell me a number and I'll default windows to that for now
<kgunn> tsdgeos: lemme check, maybe there's a mail...
<willcooke> mzanetti, it's fine, I can work around it.  I just restart metacity once I've resized the window and that takes care of it
<mterry> tsdgeos, fair
<kgunn> reminder i'm in jury pool waiting room...might disconnect abruptly
<kgunn> and inet connection sucks
<pstolowski|lunch> mzanetti, wait... i also need my part of the fix from silo 10...
<mzanetti> oh
<mzanetti> pstolowski: gimme a link please
<mzanetti> albert's MP doesn't list it
<pstolowski> tsdgeos, are we going to land the fix for tests + loaded=true fix in rtm? I'd think so?
<tsdgeos> yes we should
<pstolowski> tsdgeos, mzanetti ok i'll prepare scopes-shell MP
<mzanetti> which one?
<mzanetti> pstolowski: no
<mzanetti> pstolowski: there's already everything
<mzanetti> I just need to add that one branch
<tsdgeos> https://code.launchpad.net/~stolowski/unity-scopes-shell/load-is-true-for-leaves/+merge/244731
<mzanetti> rtm silo 7
<tsdgeos> mzanetti: â
<pstolowski> this is trunk
<pstolowski> i need to cherry pick
<mzanetti> pstolowski: oh.. indeed. unity-scopes-shell doesn't have a staging branch
<mzanetti> so yes, need a new branch for it
<mzanetti> pstolowski: let me know when you filed it
<mzanetti> I've aborted the build
<dednick> tsdgeos: think its a bug with unity-system-compositor. it offers the display state change, but no persistent property.
<tsdgeos> dednick: i see
<tsdgeos> dednick: so we bascially think the display is on?
<pstolowski> mzanetti, tsdgeos actually, is it going to be approved for rtm if it's fixing test failure?
<dednick> tsdgeos: yup
<tsdgeos> pstolowski: don't understand the sentence
<mzanetti> pstolowski: I only need a rtm branch for that one: https://code.launchpad.net/~stolowski/unity-scopes-shell/load-is-true-for-leaves/+merge/244731
<mzanetti> nothing else
<pstolowski> tsdgeos, we're not fixing rtm critical bug with the loaded=true change
<mzanetti> exactly
<pstolowski> mzanetti, i know
<mzanetti> we can probably land that test fix I guess... but not with this silo
<tsdgeos> well we are fixing one with the fix this fixes
<tsdgeos> i.e. https://bugs.launchpad.net/ubuntu-rtm/+source/unity8/+bug/1343242
<ubot5> Launchpad bug 1343242 in unity8 (Ubuntu RTM) "Departments break if going to a subdepartment of Store" [High,Triaged]
<tsdgeos> if we're not landing that
<tsdgeos> no we shouldn't land that fix
<tsdgeos> mzanetti: which branches are we landing?
<mzanetti> tsdgeos: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-007
<pstolowski> mzanetti, right. we shouldn't land https://code.launchpad.net/~stolowski/unity-scopes-shell/load-is-true-for-leaves/+merge/244731 with this silo; this silo is just manage dash
<mzanetti> you guys told me that is required for that last fix :D
<pstolowski> sorry for confusion... too many silos in last ~3 days...
<mzanetti> ack
<tsdgeos> ok, so manage dash
<mzanetti> so I'm going to build that now without further changes
<tsdgeos> then it should not be in
<tsdgeos> sorry
<mzanetti> tsdgeos: yeah, manage dash and "loses focus when clicking on trusted session"
<tsdgeos> :)
<tsdgeos> go go
<mzanetti> ok. buiklding
<mzanetti> building
<mzanetti> given this was the only issue saviq found for that branch I'm confident
<pstolowski> mzanetti, + the fix for eliding child scopes, that's in, right?
<mzanetti> yeah
<mzanetti> well, that still counts as "new bottom edge"
<mzanetti> but yes, I've cherry picked it to the rtm-staging branch
<mzanetti> pstolowski: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-007-1-build/79/console
<pstolowski> mzanetti, uhm, fixing
<mzanetti> pstolowski: I guess it's this one: https://code.launchpad.net/~stolowski/unity-scopes-shell/manage-dash-rtm/+merge/244117
<mzanetti> maybe not :D
<mzanetti> sorry
<dandrader> mzanetti, got my bluetooth mouse. are you able to connect it to the N7 or N10?
<dandrader> s/it/yours
<pstolowski> mzanetti, conflict fixed
<mzanetti> pstolowski: thanks
<mzanetti> dandrader: yes
<dandrader> mzanetti, how do I do it?
<mzanetti> pstolowski: silo building again
<mzanetti> dandrader: so there are 3 ways atm :D
<mzanetti> a) use qdbus to talk to bluez and do it in cmdline
<mzanetti> b) compile my system-settings branch and install it on the device to do it graphically
<mzanetti> c) install silo vivid/7 which has that branch already built
<mzanetti> please make a selection for more details
<dandrader> mzanetti, c
<mzanetti> sudo apt-add-repository ppa:ci-train-ppa-service/landing-007
<mzanetti> dandrader: ^
<pstolowski> tsdgeos, so we also need to prepare silo for https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1343242
<ubot5> Launchpad bug 1343242 in unity8 (Ubuntu RTM) "Departments break if going to a subdepartment of Store" [High,Triaged]
<mzanetti> dandrader: then it should work with mice, however, BT keyboards will crash Bluez when connecting atm
<dandrader> mzanetti, thanks!
 * dandrader still doesn't have a bluetooh kbd
<tsdgeos> pstolowski: we do
<tsdgeos> pstolowski: i understand that what we do in unity8 land is have a bit rtm silo, so maybe wait for this silo to land and then prepare another one?
<tsdgeos> mzanetti: â ?
<pstolowski> tsdgeos, we need to wait yes, but we should prepare branches (as many of them as possible) and silo already
<pstolowski> tsdgeos, i realize you need to wait for *staging* branch to be freed for another silo
<tsdgeos> i don't know as said i've never handled anything rtm-ish :D
<tsdgeos> Saviq is a nice man that handles the pain for us
<mzanetti> tsdgeos, pstolowski: yeah, I'll do that in a minute
<mzanetti> pstolowski: we could always have a second staging branch :)
<mzanetti> but yeah, still need to figure what the most efficient workflow is...
<mzanetti> pstolowski: hmm... says it's still conflicting
<pstolowski> mzanetti, i just recently opted for ditching devel+staging in our scopes-api... not without resistance... was really hard to have a good overview what's in the landing queue when everything was packed into a single branch
<pstolowski> huh
<mzanetti> right
<mzanetti> pstolowski: now it's criss-cross
<mzanetti> pstolowski: you should have merged it into your branch, and then merge that into the unity-team one
<mzanetti> pstolowski: no problem though.. just merge yours too and we're good
<pstolowski> mzanetti, ok, i'm not sure i did the right thing.. i've created a temp branch from rtm, merged dont-unfavorite-apps into it (with no conflicts), then merged my temporary branch into dont-unfavorite-apps-rtm and pushed it
<mzanetti> pstolowski: I think what you'd have to do is to merge rtm into manage-dash-rtm, then push that to manage-dash-rtm
<mzanetti> pstolowski: then merge manage-dash-rtm into dont-unfavorite-apps and push that
<mzanetti> (because manage-dash-rtm is a prereq of dont-unfavorite-apps)
<pstolowski> mzanetti, ah, i forgot about the prereq
<pstolowski> mzanetti, i think you're right, got the same criss-cross error locally
<pstolowski> mzanetti, ok, pushed both
<mzanetti> cheers
<mzanetti> rebuilding
<mzanetti> tsdgeos: are you aware of any priorities on landing the other rtm branches?
<tsdgeos> mzanetti: you mean what should we land earlier?
<tsdgeos> not really
<tsdgeos> everything is critical, no? :D
<mzanetti> not in the bug tracker
<mzanetti> the new bottom edge is just "high"
<mzanetti> so...
<tsdgeos> lol
<mzanetti> tsdgeos: pstolowski: could you verify row 61 in the spreadsheet and tell me if the scope branches are good from your pov?
<tsdgeos> url to that?
<pstolowski> mzanetti, hey, you seem to be duplicating some of my row #58
<mzanetti> tsdgeos: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc&usp=drive_web&pli=1#gid=0
<mzanetti> pstolowski: ah ok, looking
<pstolowski> mzanetti, but i'm ok with that, feel free to merge
<pstolowski> mzanetti, just rememver about the limit of fixes for rtm silo
<mzanetti> pstolowski: yeah, I picked 3 bugs from unity8's list and added all the linked branches from those 3 bugs
<tsdgeos> mzanetti: for bug 1384393 you need much moooooooooooore branches
<ubot5> bug 1384393 in unity8 (Ubuntu RTM) "Photos in scope not visible until all loaded" [Critical,Triaged] https://launchpad.net/bugs/1384393
<tsdgeos> i'd leave that out tbh :D
<mzanetti> pstolowski: I can do other fixes (not scope related) and leave the scope related ones to you and help you testing your silos
<tsdgeos> well i mean you don't need them
<tsdgeos> but they should land together
<mzanetti> tsdgeos: I see
<tsdgeos> up to moreAsyncDash
<tsdgeos> it's all a big batch of dash changes
<tsdgeos> i'd delay that one until we have Saviq imho
<mzanetti> tsdgeos: which ones would you recommend?
<mzanetti> tsdgeos: this is the list to pick from
<mzanetti> the INPROGRESS ones are in the current silo already
<tsdgeos> this = https://bugs.launchpad.net/ubuntu-rtm/+source/unity8/+bugs?field.milestone%3Alist=68343 ?
<pstolowski> mzanetti, so Departments fixes go with my silo?
<mzanetti> pstolowski: I don't mind, we just have to agree on something :) did you start already with it?
<mzanetti> tsdgeos: those branches are all linked together :D
<pstolowski> mzanetti, i only prepared branches i owned for rtm. i need unity8 branches from you (staging2 or whatever ;))
<tsdgeos> mzanetti: yeah...
<tsdgeos> mzanetti: so yeah we can land moreAsyncDash and everything that goes below if you want, there's nothing much more to pick from tbh
<tsdgeos> there's AllTheDashChanges, ManageDash, CloseSpread and https://bugs.launchpad.net/ubuntu-rtm/+source/unity8/+bug/1394208
<ubot5> Launchpad bug 1394208 in unity8 (Ubuntu RTM) "Unity8 unable to find the dash, which is also running in the background" [High,Triaged]
<tsdgeos> from what i can see
<tsdgeos> so maybe we can just land ManageDash + CloseSpread and https://bugs.launchpad.net/ubuntu-rtm/+source/unity8/+bug/1394208 in one first
<tsdgeos> and then try our luck with AllTheDashChanges ?
<tsdgeos> what do you think?
<mzanetti> tsdgeos: yeah, just found gerrys branches to
<mzanetti> too
<mzanetti> tsdgeos: ManageDash is already in the pipeline
<pstolowski> mzanetti, tsdgeos guys, so how can we manage landing of departmens fix wrt unity8 branch?
<mzanetti> pstolowski: I go with a non-scope related silo now as all the scope related branches are really interconnected. you can land whatever you want and then we'll sync back for the next one
<tsdgeos> :)
<pstolowski> mzanetti, ok. i'll wait with departments fix then.
<tsdgeos> pstolowski: i think he said you land departments first (i think)
<tsdgeos> mzanetti: â
<pstolowski> tsdgeos, i can't without your unity8 fix.. can i?
<tsdgeos> i thought you were also includin it :D
 * tsdgeos is confused
<tsdgeos> ah but you can't because we have to land the other stuff
<mzanetti> pstolowski: ok... I guess I see what the issue is
<tsdgeos> i see
 * pstolowski 's mind is gonna blow
<mzanetti> +1
<mzanetti>  :D
<mzanetti> ok. I do have space for one more fix in the silo
<mzanetti> does that help?
<pstolowski> \o/ take me take me pls pretty pls! :)
<mzanetti> afaict if I pull in one of those dashes branch I'll pull in other fixes too somehow
<tsdgeos> guys i'm going to eod, i hope you either don't need me or we can fix it tomorrow ;)
<tsdgeos> right?
<mzanetti> tsdgeos: ok
 * tsdgeos waves
<mzanetti> pstolowski: but do the unity8 and unity-scopes branches need to land together?
<mzanetti> or just one before the other?
<pstolowski> mzanetti, the three changes that need to land together with unity8 fix for departments are in row #58
<mzanetti> pstolowski: down't we have to put the into the same silo then?
<pstolowski> mzanetti, that but be ideal, otherwise my #58 needs to wait for one more unity8 landing
<mzanetti> pstolowski: so you want to put lp:~aacid/unity8/deparment_jumping into 58, right?
<pstolowski> mzanetti, yes, plus the other fix tsdgeos made to fix test failure
<mzanetti> ok, works for me
<mzanetti> I'll prepare the staging branch asap with that then
<pstolowski> mzanetti, ok, cool
<mzanetti> not sure if or why Saviq wants that single staging branch... but as I'm only taking over a few days I'd prefer to keep it "his way"
<pstolowski> mzanetti, i guess because it reduces chances of conflicts to 0
<pstolowski> mzanetti, silo 7 built
<mzanetti> pstolowski: yeah, I'm testing already
<mzanetti> manual test looking good
<mzanetti> need to run automated ones still
<pstolowski> mzanetti, how do you plan to keep just one staging branch without landing that silo 7 almost immediately?
<mzanetti> pstolowski: afaict that's what saviq did
<pstolowski> mzanetti, hmmm. that needs to pass qa
<mzanetti> yeah... last time I did that it was rather quick (few hours)
<mzanetti> so if I manage to approve silo7 soon I guess we'd be ready tomorrow morning
<mzanetti> otherwise I'd start with a fresh branch
<pstolowski> mzanetti, hmm i think we need everything by eod today
<mzanetti> pstolowski: define "everything"
<pstolowski> mzanetti, whatever you want in ota1
<pstolowski> mzanetti, specifically, all the stuff we have pending in the spreadsheet already
<mzanetti> pstolowski: ok, that's not possible for me
<mzanetti> oh well
<mzanetti> in that case I guess I create another branch
<mzanetti> I have an ap test failing :/
<mzanetti> phew... it was a config issue
<hmsimha> I just noticed a UI issue that should probably be filed with launchpad, but I don't know the relevant names of the components it involves to check if it's already been filed.. can someone help me?
<hmsimha> It involves the bar at the top of the screen (and the icons that you can click to interact with open applications -- for example with xChat it's the envelope icon)
<hmsimha> and the applications icon list that appears when you move your mouse over to the left side of the screen
<greyback> hmsimha: that's the "unity" project, the areas you're referring to is the "indicators"
<hmsimha> greyback: yes, I was referring to unity's issue tracker on launchpad. The top bar and left area don't have their own names?
<greyback> hmsimha: the top bar is the "panel" or "menu bar". The left area? Is that the colourful bar with icons along the left of the screen? If so, that's the "launcher"
<hmsimha> yes, great! thanks
<greyback> http://askubuntu.com/questions/10228/whats-the-right-terminology-for-unitys-ui-elements/19166#19166 is handy
<hmsimha> greyback: excellent, thanks
<greyback> welcome
<pstolowski> mzanetti, hey, are you there?
<mzanetti> pstolowski: yeah
<mzanetti> pstolowski: I already merged the branch
<mzanetti> you can go ahead and rebuild I think
<pstolowski> mzanetti, cool
<pstolowski> mzanetti, can you get somebody from your team to approve it?
<mzanetti> pstolowski: saviq approves those himself usually (given it's just cherry picking) so I guess I can do so too
#ubuntu-unity 2014-12-17
<Cimi> tsdgeos, a little bit better this night :)
<tsdgeos> Cimi: :)
<pstolowski> mzanetti, morning! thanks for your help yesterday!
<tsdgeos> pstolowski: so we landed manage dash in rtm, right?
<tsdgeos> and by we i mean you :D
<pstolowski> tsdgeos, actually that was mzanetti :)
<tsdgeos> cool
<tsdgeos> for some reason the bugs didn't auto close
<tsdgeos> i closed them now
<tsdgeos> so it's good i didn't close them by mistake :D
<tsdgeos> pstolowski: so you're landing the navigation fixes then?
<pstolowski> tsdgeos, yes
<tsdgeos> greatz
<tsdgeos> pstolowski: do you need anything from me?
<pstolowski> tsdgeos, no, thanks!
<mzanetti> morning guys
<mzanetti> tsdgeos: yeah, noticed that too... the bugs weren't auto closed
<tsdgeos> some where
<tsdgeos> some where not
<tsdgeos> no idea why
<tsdgeos> Cimi: there?
<Cimi> tsdgeos, yes
<tsdgeos> Cimi: what's up with https://code.launchpad.net/~mterry/unity8/wizard-passphrase-osk/+merge/244358 ? seems you wanted to approve but then no?
<Cimi> tsdgeos, top approved
<tsdgeos> oki .)
<facundobatista> Holas
<greyback> o/
<Mirv> tsdgeos: Saviq: if you want to have a run, Qt 5.4.0 final is currently upgradeable to from vivid landing-005. I managed to see apport running for some time and now my device went into some sort of reboot loop (I barely have time to adb shell in before it boots).. debugging experiences welcome!
<Mirv> the packages now have proper symbol support so it's easier to see dependency problems, and I've hacked around Oxide + webbrowser + u-s-s-online-accounts to get them build with the API changes
<tsdgeos> Mirv: i see
<tsdgeos> will give it a go, see what crashes explodes
<tsdgeos> Mirv: that silo puts my phone in an endless reboot loop
<Mirv> tsdgeos: mine too. I went to the home partition in recovery mode and filed bug #1403511 - it's the same symbol error as with beta, but this time with better packaging it's surely not from some simple missing rebuild.
<ubot5> bug 1403511 in unity8 (Ubuntu) "unity8 fails to start on armhf with Qt 5.4.0" [Undecided,New] https://launchpad.net/bugs/1403511
<tsdgeos> Mirv: damn :D
<tsdgeos> Mirv: how do i recover it now, recovery mode?
<tsdgeos> i don't remember teh magic key combo
<tsdgeos> ok got it
<Mirv> tsdgeos: power + down, indeed
<Mirv> tsdgeos: on mako I found the user-data (home dir) from mounting /dev/block/platform/msm_sdcc.1/mmcblk0p23
<greyback> is very unusual for a failing unity8 to cause phone to reboot
<greyback> it would make me suspect graphics gl/gles too
<Mirv> it's probably something much more than just unity8, given the missing symbol is glGenVertexArrays
<tsdgeos> yeah
<greyback> Mirv: I think that's an opengl-only thing
<tsdgeos> Mirv: that sounds llike you lined to opengl vs opengles
<tsdgeos> i think it's the same problem i was having with the wrong build of qtmir, let me check
<Mirv> tsdgeos: it sounds like that, but https://launchpadlibrarian.net/192704349/buildlog_ubuntu-vivid-armhf.qtbase-opensource-src_5.4.0-0ubuntu1~vivid1~test7_UPLOADING.txt.gz is surely ES2 and the error claims libqt5gui5 itself would be the one missing the symbol
<Mirv> so more like possibly the gles build being broken or such
<Mirv> greyback: that's good to know
<tsdgeos> Mirv: it's not libQt5Gui.so.5 that has to have it, i understand that it's trying to use it and failing to find it in or any of the loaded/linked libs
<tsdgeos> but yeah the log says gles2
<tsdgeos> ah
<tsdgeos> https://www.khronos.org/opengles/sdk/docs/man3/html/glGenVertexArrays.xhtml is part of gles3, not gles2
<tsdgeos> guess if that's what byting us?
<tsdgeos> qt seems to have lots of glGenVertexArrays related code
<tsdgeos> :/
<Mirv> maybe they've made a mistake when adding gles3 support, making wrong changes wrt gles2 support?
<tsdgeos> i think they kind of implemented their own for when not available
<tsdgeos> but it may defenitely be weird to get to work
<tsdgeos> i'll try to see if i can get it to work, ok?
<Mirv> by all means, "go!" :) it would be really nice to see unity8 in action on qt 5.4
<tsdgeos> now compiling in the phone will take a while :D
<tsdgeos> but oh well
<tsdgeos> i can multi task
<Mirv> we need the arm64 8-core phones for stuff like this..
<tsdgeos> :D
<tsdgeos> don't one of those odroid things have 8 cores?
<tsdgeos> yeah
<tsdgeos> http://www.hardkernel.com/main/products/prdt_info.php?g_code=G140448267127
<tsdgeos> Samsung Exynos5422 ARMÂ® Cortexâ¢-A15 Quad 2.0GHz/Cortexâ¢-A7 Quad 1.4GHz
<tsdgeos> Mirv: can you please try https://codereview.qt-project.org/#/c/102257/ ?
<Mirv> (a build with ^ building in landing-005)
<greyback> /usr/bin/unity8 (deleted): No such file or directory.
<greyback> strange thing to see when attaching gdb to the unity8 process...
#ubuntu-unity 2014-12-18
<tsdgeos> Mirv: did you get time to rebuild the packages?
<tsdgeos> ah you did
<tsdgeos> didn't read my emails yet
<Mirv> tsdgeos: yeah, so no crash anymore, unity8 runs, but just black screen. bug #1403758
<ubot5> bug 1403758 in unity8 (Ubuntu) "Unity8 shows black screen with Qt 5.4.0" [Undecided,New] https://launchpad.net/bugs/1403758
<tsdgeos> :D
<tsdgeos> well i guess it's progress
<Mirv> yes I can like completely use it via adb shell :)
<tsdgeos> k will give it a try and see why i can find stuff is black
<Mirv> k!
<tsdgeos> yesterday it was very funny since at the same time i was complaining about how gles was broken there was a discussion about that patch itself :D
<facundobatista> Holas
<tsdgeos> interesting unity8 needs stuff from universe
<tsdgeos> i thoought it was all main alrady
<om26er> Saviq, hey! will Manage Dash have search in it ?
<cwayne_> i really wish renderers could be result-specific instead of category specific :/
<mzanetti> om26er: it's already there in the code, but design wanted to deactivate it for now
<om26er> mzanetti, strange, search would have helped in long lists
<cwayne_> do we expect the store button on the manage dash to ever take you to a scopes department or anything like that?
<cwayne_> it seems weird to have a bunch of apps listed, would kind of expect scopes
<mzanetti> cwayne_: not sure I understand what you mean
<mzanetti> ah, now I do
<mzanetti> hm... fair point.
<mzanetti> dunno about the plans
<cwayne_> im pretty sure its not in the plans, just wishing :)
<tsdgeos> om26er: there's no "scopes deparment" afaik
<tsdgeos> and i think people are against it since they don't want to promote stuff as being a scope or not, but as doing something (i.e. accessing twitter) or not
<tsdgeos> but i can be totally wrong :D
<om26er> cwayne_, that one for you ^
<cwayne_> tsdgeos, that is a fair point, it just seems odd that in manage dash it gives you a special button to download apps that won't show up there
<tsdgeos> cwayne_: agreed
<om26er> mzanetti, btw are we not using the bottom edge component from the uitoolkit ?
<om26er> the animation with which 'Manage Dash' comes up is different from whats in the apps
<mzanetti> om26er: no, I don't think we're using that
<om26er> would have helped with a consistent experience
#ubuntu-unity 2014-12-19
<facundobatista> Hola
<virtuald> has the unityfox firefox extension been discontinued?
<virtuald> guess i came here the wrong day
#ubuntu-unity 2015-12-14
<tsdgeos> larsu: who do i ping to get https://code.launchpad.net/~aacid/gsettings-qt/disconnect_signal_handler/+merge/278947 and https://code.launchpad.net/~aacid/qmenumodel/clazy_run/+merge/272788 landed?
<larsu> tsdgeos: Saviq or seb128
<seb128> Saviq! :-)
<Saviq> sure, /me takes
<seb128> thanks
<larsu> hehe
<zzarr> hello! Is there a way to try unity8 on a computer with a nVidia card?
<dandrader> zzarr, hi, that's more like a question of whether Mir works with nVidia. ask in #ubuntu-mir
<zzarr> okey, dandrader thanks, I will
<tsdgeos> Saviq: maybe you can review https://code.launchpad.net/~aacid/unity8/dash_backgroud_source_size_rework/+merge/276157 ?
<tsdgeos> gerry seems to have forgotten about it
<tsdgeos> cimi: you were reviewing https://code.launchpad.net/~aacid/unity8/thread_warning/+merge/279276 ?
<tsdgeos> mzanetti_: can you have a look at https://code.launchpad.net/~aacid/unity8/testIndicatorsMenuFix since i think you could also reproduce the problem?
<dandrader> Saviq, so what was the end of that black frame issue you were seeing with qtmir/surfaceItemFillMode branch?
<tsdgeos> Saviq: what was the fix for the black screen because gst got stuck?
<tsdgeos> gst-inspect-1.0
<tsdgeos> it seems
<tsdgeos> it's funny because if you run that from a tty it also blocks
<tsdgeos> maybe similar problem we have in unity8?
<Saviq> tsdgeos, yes, see bug #1525285
<ubot5> bug 1525285 in clutter-gst-3.0 (Ubuntu) "inspecting clutter plugin hangs outside X11" [High,Confirmed] https://launchpad.net/bugs/1525285
<tsdgeos> ah cool
<Saviq> dandrader, every once in a while the focused app showed a black frame until I interacted with the phone
<Saviq> dandrader, we've decided to just merge the fillMode bits until we find out what's wrong with the rest
<Saviq> dandrader, the immediate cause was that in your changed code you bound 0 to the surface if hasBuffer() was false, which in itself is probably correct, but has a detrimental user-facing effect, and also suggests something's wrong in lower levels (mir?)
<dandrader> Saviq, hmm.. so the theory is that the fillMode change just exposed a preexisting issue?
<Saviq> dandrader, yes
<Saviq> dandrader, well, not fillMode itself
<Saviq> dandrader, this hunk https://code.launchpad.net/~dandrader/qtmir/surfaceItemFillMode/+merge/274750#diff-line-389
<Saviq> dandrader, this is the extent of reverts we decided to go with from your branch
<Saviq> http://bazaar.launchpad.net/~unity-team/qtmir/surfaceItemFillMode/revision/426
<dandrader> Saviq, so this revision 426 reverts pretty much the whole thing
<dandrader> Saviq, maybe only left the new API
<Saviq> dandrader, https://code.launchpad.net/~unity-team/qtmir/surfaceItemFillMode/+merge/279757 is what landed
<Saviq> dandrader, so as far as we understood implemented the actual PadOrCrop feature
<Saviq> I didn't notice behavioural differences when resizing between that and your whole branch
<dandrader> Saviq, the difference is that QML items will lag behind, will work with outdated surface geometry
<dandrader> Saviq, eg, the window decorations will lag behind the surface size during resizes
<dandrader> Saviq, but yes, the PadOrCrop feature remained
<Saviq> dandrader, so yeah, resizing got improved, but we erred on the safe side with the remaining changes
<Saviq> dandrader, we do want them, sure, just we couldn't have landed as it was
<dandrader> right
<tsdgeos> cimi: remember https://code.launchpad.net/~aacid/ubuntu-settings-components/standarizeImports/+merge/280303 too ;)
<cimi> ok ok, that is a quick approve :)
<Saviq> dandrader, btw, as far as I can tell, with or without those changes, when resizing vertically, I could see surfaces going up/down, as if they were anchored to bottom-left corner instead of top-left, that expected still?
<Saviq> or would this actually be artifact of the reverts that we did?
<dandrader> Saviq, expected. seems like a "problem" in qt redraw/relaying logic. like on the very first frame after a resize it would still paint the same layout but just fill the extra surface area with white. then on the next frame the relayouting would be done and the whole surface area would be covered. that was my understanding at least
<dandrader> Saviq, the case that gone perfect was resizing by dragging the right border
<Saviq> dandrader, ack
<dandrader> Saviq, with the settings app for instance
<Saviq> dandrader, yup, that was my test
<cimi> tsdgeos, managed to need fixing it :D
<tsdgeos> cimi: that code was only written in 2013, but whatever, i'm not sure we even have a copyright year policy
<cimi> tsdgeos, really? ok leave it then
<tsdgeos> cimi: so changed & pushed
<cimi> tsdgeos, I was wondering why we put years anyway, since it doesnt make much sense we update every year...
<tsdgeos> cimi: afaik it's how copyright works, you need to specify the last year you did something so that in X years your copyright can properly expire
<tsdgeos> that if Disney ever lets copyrights expire again
<cimi> :D
<cimi> gonna add the year to my pasta recipe so it doesnt expire :D
<tsdgeos> Saviq: can you add https://code.launchpad.net/~aacid/ubuntu-settings-components/standarizeImports/+merge/280303 to the next unity8 landing too?
<Saviq> tsdgeos, ack
<tsdgeos> greyback: have a sec?
<greyback> tsdgeos: sure
<tsdgeos> greyback: any idea where could i start with https://bugs.launchpad.net/ubuntu/+source/qtmir/+bug/1524488 ?
<ubot5> Ubuntu bug 1524488 in qtmir (Ubuntu) "Manually setting the time into the past makes flickables misbehave" [Undecided,New]
<tsdgeos> greyback: basically if you change the time flickables stop working
<tsdgeos> i guess there's a timestamp stored somewhere that breaks stuff
<tsdgeos> any guess of where i start having a look?
<greyback> tsdgeos: hmmm, a mad guess might be the implementation of the QAbstractAnimationTimer
<greyback> QTickAnimationProxy I think
<tsdgeos> k
<greyback> but I think it is monotonically increasing ticker, so currentTime shouldn't matter
<tsdgeos> i wonder if we should worry much about this otoh
<Saviq> tsdgeos, it would be good
<greyback> QML_ANIMATION_TICK_DUMP is an env var to play with
<Saviq> tsdgeos, there have been reports of people's RTC resetting to epoch
<Saviq> tsdgeos, at which point the phone dies
<Saviq> while the RTC reset is a problem in itself, it'd be good if the UI worked regardless :)
<tsdgeos> ok, i'll have a look after food
<tsdgeos> food!
<Saviq> greyback, you need to bump changelog for -gles if upstream version changed
<greyback> Saviq: ok, I thought train does that automagically
<Saviq> greyback, not for upstream version, not yet
<Saviq> greyback, it mangles everything past it
<greyback> eeh, ok
<greyback> I'm testing locally anyway first
<Saviq> that's mostly because there's very little train does special about -gles
<Saviq> the only thing, really, is requiring -gles automagically where it's meant to be there
<corn_field> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1525893
<ubot5> Ubuntu bug 1525893 in Canonical System Image "camera app, header under indicators bar" [Undecided,New]
<corn_field> http://i.imgur.com/ExNbNHF.jpg
<Saviq> then it treats it as any other thing, we're just relying on the fact that qtmir will always be built first (alphabetically)
<Saviq> corn_field, thanks, I've noticed that briefly
<corn_field> o/
<Saviq> greyback, any idea what we broke â? /me worried qtubuntu/qtmir wrt. panel height
<greyback> Saviq: grr, fullscreen state of camera app broken
<Saviq> greyback, gallery behaves slightly different - panel goes away, but bottom, panel-high is white
<Saviq> so http://bazaar.launchpad.net/~phablet-team/qtubuntu/trunk/revision/300 most likely
<greyback> Saviq: yeah
<ltinkl> it was working with "my" panel hack :)
<Saviq> yeah it's Daniel's patch on top most likely, /me confirms
<ltinkl> with this https://code.launchpad.net/~lukas-kde/qtubuntu/panelHeight/+merge/278718 I'm pretty sure it was OK
<Saviq> yeah this couldn't have resulted in the breakage
<ltinkl> dednick, heyo, could you pls review https://code.launchpad.net/~lukas-kde/unity8/fixWifiAPIndicatorIcons/+merge/280442 when you get a chance? thx
<tsdgeos> dandrader: i have no clue what FloatingFlickableHelper does :D
<tsdgeos> it does what your code used to do, i just refactored it around, maybe you can help me with the documentation?
<dandrader> tsdgeos, "FloatingFlickableHelper contains the CPP remnants of the previous pure-CPP implementation of FloatingFlickable" :)
<tsdgeos> looks like a bad documentation
<dandrader> tsdgeos, kidding
<dandrader> tsdgeos, it synthesizes mouse events
<dandrader> tsdgeos, sending them to the given qquickitem
<dandrader> tsdgeos, could even rename the methods
<Saviq> dandrader, this bug is looking at you sideways :/ bug #1525893
<ubot5> bug 1525893 in Canonical System Image "[regression] camera app, header under indicators bar" [Critical,Triaged] https://launchpad.net/bugs/1525893
 * Saviq just building qtubuntu to confirm
<dandrader> tsdgeos, let's do it that way then: I come up with a patch and send/propose it to your branch
<dandrader> Saviq, so that's top priority?
<tsdgeos> dandrader: that works for me :)
<Saviq> dandrader, yeah, this is breakage
<Saviq> dandrader, I'm just confirming with qtubuntu without r300
<Saviq> dandrader, seems same without r300, or I did something wrong when testing... trying to find a working image then
<Saviq> greyback, â
<greyback> Saviq: tbh I suspect camera app problem unrelated to qtubuntu
<Saviq> greyback, not just camera... gallery doesn't behave well either
<greyback> I know
<Saviq> in a weirder way though
<Saviq> greyback, honestly, panel not going away but app thinking it did, that doesn't seem like should be possible by app itself
<greyback> dandrader: if you want my help, let me know
<Saviq> u8, qtmir, qtubuntu landed in the most recent image, just flashing the one prior to that
<Saviq> dandrader, greyback, it's between unity8 and qtmir, qtubuntu innocent
<dandrader> Saviq, ack
<ltinkl> dednick, got my latest msg?
<dednick> ltinkl: sorry, missed it after reboot.
<ltinkl> dednick, could you pls review https://code.launchpad.net/~lukas-kde/unity8/fixWifiAPIndicatorIcons/+merge/280442 when you get a chance? thx
<dednick> ltinkl: uchar?
<dednick> for what state?
<Saviq> no idea which commit could be the problem :(
<ltinkl> dednick, the AP signal strength
<ltinkl> dednick, it's a difference between network-indicator (on phone) and nm-applet (on desktop)
<ltinkl> dednick, quite nasty to pass the percentage integer as a single char (ASCII code really)
<dandrader> Saviq, my bet is the multiple-surfaces branches
<ltinkl> dednick, but that's what nm-applet does
<Saviq> dandrader, think the fullscreen prop isn't picked up from lastSurface or something?
<dandrader> Saviq, something of the kind. Application.fullscreen property doesn't make much sense in a multi-surface world
<cimi> pstolowski, can we kick a rebuild of https://requests.ci-train.ubuntu.com/#/ticket/506 ?
<Saviq> dandrader, true
<dednick> ltinkl: u8 desktop going to  be using indicator-network no?
<dandrader> Saviq, I though I had it covered/converted, but maybe not so
<pstolowski> cimi, sure, doing
<ltinkl> dednick, no idea but for the time being, this fixes both cases
<Saviq> dandrader, ok, shall I be digging more or are you on it (obv. let me know when you need me)?
<dednick> ltinkl: but there is no nm-applet for desktop :/
<Saviq> dednick, there is, unity7 still uses nm-applet
<ltinkl> dednick, ?
<dednick> Saviq: yes, but unity7 doesnt use qml code
<ltinkl> dednick, well it is the backend provider
<dandrader> Saviq, I'm on it
<dednick> which is what ltinkl is changing
<Saviq> dednick, but they back the desktop network menu
<dednick> Saviq: in u8?
<Saviq> dednick, yes
<Saviq> dednick, when in unity8-desktop-session-mir
<ltinkl> dednick, not changing u7 :)
<dednick> Saviq: i c. that's what my question was.
<Saviq> dandrader, ack
<dednick> why we have desktop profile then? shouldnt we just be using indicator-network? sigh... whatever.
<Saviq> basically, outside of ubuntu-touch, since indicator-network does not have all the features nm-applet had, yet
<dednick> yeah. ok. features.
<Saviq> but yeah, we want to converge on indicator-network at some point
<ltinkl> esp, since nm-applet is deprecated imo
<cimi> mzanetti_, can you merge here? https://code.launchpad.net/~mzanetti/unity8/launcher-updates/+merge/278567
<ltinkl> cimi, he on vacation :)
<cimi> lucky :)
<Saviq> back tomorrow
<Saviq> when you're on vacation ;P
<dednick> ltinkl: i'm interested. in u7 we get the indicators from the /usr/share/unity/indicators file list. how do we get the nm-applet in our indicators?
<dednick> *in u8 we get
<ltinkl> dednick, that's a good question :) dunno, let me find out
<dednick> ltinkl: does it show up?
<ltinkl> dednick, oh yes
<ltinkl> dednick, start the u8 session and you'll see
<cimi> Saviq, my vacation is buying xmas presents before is too late xD
<dednick> eh. u8 being painful.
<greyback> tsdgeos: actually, just had a thought: check the times of the input events. they could be screwed up, which would cause this
<tsdgeos> greyback: as said, the events don't reach the flickable, need to go high enough to find where the mistake happens
<greyback> tsdgeos: ok (I hadn't read up)
<tsdgeos> greyback: what sends the touch events to a given app, is it qtmir? qtubuntu?
<greyback> tsdgeos: events come from mir, are converted from MirEvent to QTouchEvent in qtmir, then converted back to MirEvent to be sent to client. Then Qtubuntu gets that MirEvent, and converts back to QTouchEvent
<tsdgeos> k, tx
<greyback> tsdgeos: qtmir uses category logging, QT_LOGGING_RULES="qtmir.*.debug=true" will enable all
<greyback> that will print input events, but don't recall how detailed
<greyback> if qtmir's initial conversion step has an error, that will screw up all Qt instances from then on
<tsdgeos> oh noes, i need to wait 464967 to be able to unlock my phone
<tsdgeos> i guess moving back the time was not a good idea while having the phone locked
<tsdgeos> 464967 *minutes*
<tsdgeos> :D
<greyback> how convenient: just over 5 days
<greyback> you're not getting early Xmas holidays like that! :D
<tsdgeos> greyback: more like a year :D
<greyback> oh minutes
<greyback> heh, I thought it was seconds
<Saviq> mterry, ââ
<Saviq> tsdgeos, there's a thread on ubuntu-phone about that exactly (someone got reset to epoch)
<tsdgeos> Saviq: welll i did the change myself, i'm to blame
<Saviq> tsdgeos, you can use "date" in adb/recovery to put it back in the present
<tsdgeos> but it's a bit of a pita i guess
<mterry> Saviq, I have a branch that is a partial fix -- https://code.launchpad.net/~unity-team/unity8/lockout-time-travel/+merge/280206
<mterry> tsdgeos, ^
<tsdgeos> if you don't have devel access
<mterry> meant to send to you
<tsdgeos> mterry: i fixed it with date :D
<mterry> tsdgeos, ok cool
<Saviq> tsdgeos, yeah well, you always have devel access if you have the phone in your hands ;)
<tsdgeos> Saviq: but you need to know it :D
<Saviq> oh sure :)
<tsdgeos> greyback: so the qtmir.mir.input output looks good, at least looks the same with "good date" and "bad date"
 * tsdgeos keeps digging
<greyback> tsdgeos: ok. Are the flickables are broken in the indicators/launcher?
<tsdgeos> greyback: too many are
<tsdgeos> greyback: the launcher/indicators seem to work fine
<greyback> tsdgeos: ok, I would suspect the event conversion from unity8->qtmir->client->qtubuntu could be the culprit then
<greyback> tsdgeos: please try MIR_CLIENT_INPUT_RECEIVER_REPORT=log
<greyback> that enables mir's logging of input events to console
<greyback> run an app with that set, and see if the input events times make sense
<tsdgeos> greyback: i need that in the app or in unity8?
<greyback> tsdgeos: I think app.
<tsdgeos> k
<tsdgeos> Received event:touch_event(when=1452933799600760000 (10.-540462 ms ago)
<tsdgeos> what does "10.-540462 ms ago" mean :D
<greyback> something bad I'd imagine
<tsdgeos> in the "good" case it says
<tsdgeos> Received event:touch_event(when=1450110049426985408 (3.013062 ms ago)
<tsdgeos> i'm weirded by the - after the . :D
<greyback> ok, then I'd encourage you to dig into qtmir, in src/common/timestamp *
<greyback> overall story: MirEvents use 64bit timestamps. QEvents use 32bit timestamps
<greyback> so some trickery is done in qtmir to try convert between the two without loosing data
<greyback> trickery which involves currentTime
<tsdgeos> k
<mterry> @unity, if anyone has some time, I'd appreciate a quick review of (tiny) https://code.launchpad.net/~mterry/unity8/briefly-inactive/+merge/280492
<mterry> It fixes a security-sensitive bug
<mterry> Saviq, filling out the checklist for an MP once more made me wonder -- have we seen tags come back in a while?  Did we finally cure that disease?
<Saviq> mterry, doubt it ;)
<mterry> heh
<Saviq> mterry, I'm considering adding a step after .pot update in the train
<mterry> Saviq, ah that's smart
<Saviq> mterry, but am worried that might not be enough, as ci train reuses branches per-silo
<Saviq> I think it only --overwrites
<Saviq> but that does not get rid of tags :D
<mterry> Saviq, well maybe with a further 3 years of no tags, we can be confident
<mterry> Saviq, we need a little "X days since a tags incident" whiteboard
<Saviq> mterry, FWIW, unity8 is relatively free, but we've managed to contract them on UITK. qtmir...
<mterry> Saviq, oh no really?  hah
<Saviq> yeah it's fun
<Saviq> time to move to git ;P
<mterry> ...
<mterry> I love bzr so much, but if that's what it takes...
<Saviq> if only bzr was maintained...
<mterry> ltinkl, looks like there's a new geonames timezone-completion kid on the block: https://bugs.launchpad.net/ubuntu/+source/geonames/+bug/1525156
<ubot5> Ubuntu bug 1525156 in geonames (Ubuntu) "[MIR] geonames" [Wishlist,Fix released]
<mterry> ltinkl, seems to be what the desktop team wants to support going forward, although as I comment in that bug, I'm annoyed that they didn't seem to be aware of prior art that they obstensibly maintain...
<ltinkl> mterry, yeah, good points raised, at least the dependency on the data package should be added
<mterry> ltinkl, digging further, it appears libtimezonemap does use cities15000.txt for its initial database when doing completion, and then hits the network for more.  So I don't even get the motivation for the geonames package
 * mterry awaits their reply
<ltinkl> mterry, perhaps they want to avoid the network completely?
<mterry> ltinkl, sure but then comment out like one line in libtimezonemap, don't make a new library  :)
<ltinkl> mterry, NIH syndrome hitting hard? :)
<mterry> ltinkl, we made both packages  :)
<ltinkl> NIH^2
<mterry> heh
<ltinkl> mterry, the original one is a gnome thing right?
<mterry> ltinkl, it's a copy of GNOME code that we made so we could share it among several components.  We tried to get GNOME to use it, but NIH stopped that
<ltinkl> mterry, https://code.launchpad.net/~mterry/unity8/briefly-inactive/+merge/280492
<mterry> ltinkl, ?
<ltinkl> mterry, interesting, I think I've seen it today... quickly got access to the MTP drive window (nautilus) which I closed but it disconnected my phablet-shell session
<ltinkl> mterry, could that fix it?
<mterry> ltinkl, closing the window disconnecting your adb shell would be a different thing
 * ltinkl tries again
<pmcgowan> josharenson, I just figured out the root symptom of bug #1489323 if you want to check it
<ubot5> bug 1489323 in unity8 (Ubuntu) "MX4 button sometimes remains active with the screen off" [High,Confirmed] https://launchpad.net/bugs/1489323
<josharenson> pmcgowan: will take a look, thanks
<mterry> mzanetti_, just saw your comment on lockout-time-travel MP about trusting ntp clock
<Saviq> mterry, he's off today
<mterry> curses.  Will reply in MP
<Saviq> as in, the whole day
<mterry> Saviq, thanks, forgot that
<ljp> anyone here know what is listening to proximity sensor when dialer-app is on a call?
<McintireEvan> Hi, I was wondering if someone could help me. I'm adding a shortcut to the overlay through CompizShortcutModeller.cpp, but it doesn't show up either due to a wrong plugin name or a wrong keybinding name. I'm really not sure where to go from here, I've tried several values for the shortcut names (from looking at the plugin in compiz) but I haven't had much luck. anyone got any ideas? The plugin in question is screenshot
#ubuntu-unity 2015-12-15
<Saviq> tsdgeos, ah, it was xenial that had the aborts
<Saviq> and still does
<tsdgeos> somethings up with that xenial CI probably
<Saviq> indeed
<Saviq> https://requests.ci-train.ubuntu.com/static/error.gif
<tsdgeos> can't branch qtmir from my chroot :S
<tsdgeos> http://paste.ubuntu.com/14025322/
<tsdgeos> any idea ?
<tsdgeos> actually adding -Ossl.cert_reqs=none after branch worked :D
<duflu> Saviq: Is there a bug for the black screen on login? Because I'm finding the same problem with pure Mir demos
<Saviq> duflu, don't think I know the problem at all
<duflu> Saviq: Tried Unity8 on xenial desktop lately?
<Saviq> duflu, ah that
<Saviq> duflu, bug #1525285
<ubot5> bug 1525285 in clutter-gst-3.0 (Ubuntu) "inspecting clutter plugin hangs outside X11" [High,Confirmed] https://launchpad.net/bugs/1525285
<Saviq> duflu, run gst-inspect-1.0 under X11
<Saviq> tsdgeos, date issues?
<tsdgeos> ah right :D
<tsdgeos> that's what you get for changing your clock back one year
<tsdgeos> stupid me
<Saviq> yup, certificate not valid yet
<Saviq> wait, I didn't mean to say "yup" to your "stupid me" :P
 * duflu hopes bug 1526209 is related to that somehow
<ubot5> bug 1526209 in mir (Ubuntu) "[regression] Clients of nested Mir servers silently crash/exit instantly" [Critical,Incomplete] https://launchpad.net/bugs/1526209
<duflu> Saviq: Oh I think there are two different black screen bugs. Do you see any part of the shell?
<corn_field> duflu, i see the launcher and the notifications bar
<duflu> corn_field: On xenial desktop?
<corn_field> duflu, yes
<duflu> corn_field: Fully updated?
<corn_field> duflu, well... updated yesterday i think upgrade & dist-upgrade
<duflu> Hurrah. Multiple bugs.
<duflu> So the rest of today will be bisection
<corn_field> fun fun fun!
<Saviq> duflu, that clutter one is just deadlock on startup, nothing on screen
<Saviq> except for u-s-c's cursor
<duflu> Saviq: Yeah multiple bugs. I see the shell bits at the top but no dash. Looks like that's part of bug 1526209
<ubot5> bug 1526209 in mir (Ubuntu) "[regression] Clients of nested Mir servers silently crash/exit instantly" [Critical,Incomplete] https://launchpad.net/bugs/1526209
<duflu> Although different Mir version
<duflu> *shruf*
<duflu> shrug
<Saviq> duflu, here, after I got rid of the gst deadlock, everything's fine'n'dandy
<tsdgeos> dandrader: morning, have a second to help me?
<dandrader> tsdgeos, yes
<tsdgeos> dandrader: so Gerry yesterday said "events come from mir, are converted from MirEvent to QTouchEvent in qtmir, then converted back to MirEvent to be sent to client."
<tsdgeos> i'm trying to find out the place where " converted back to MirEvent to be sent to client" happens
<tsdgeos> and i thought it'd be MirSurface::mousePressEvent & friends
<tsdgeos> but i've added debugs and breakpoints in there and i can't see them triggering
<tsdgeos> so maybe it's not there?
<dandrader> tsdgeos, yes, MirSurface is doing that. let me check
<tsdgeos> dandrader: if i understand correctly those debugs should be in unity8's log, rigiht?
<dandrader> tsdgeos, you're looking for mouse or touch event generation?
<tsdgeos> dandrader: i guess touch maybe?
<dandrader> tsdgeos, no, they're disabled by default as they're too verbose
<tsdgeos> dandrader: yes, but they should be in unity8's log not in the client, right?
<dandrader> tsdgeos, there's the makeMirEvent family of functions in src/modules/Unity/Application/mirsurface.cpp
<tsdgeos> yes
<dandrader> tsdgeos, right
<dandrader> but client side also takes the mir events coming from the server and translate into qt ones, naturally
<tsdgeos> yes
<tsdgeos> ok, understood then, tx
<dandrader> tsdgeos, ah, actually there's qtmir logging for mirserver -> unity8's qml scene, but not for unity8's qml scene -> mir client
<tsdgeos> yes, that's what i am adding
<dandrader> tsdgeos, guess there as never a need for it
<dandrader> tsdgeos, iirc, I usually added them in qml code when needed
<Saviq> greyback, when I said you need to bump qtubuntu-gles, I meant http://bazaar.launchpad.net/~mir-team/qtubuntu/gles-sync/revision/45/debian/changelog
<Saviq> now why this whole thing went apeshit in the PPA is another question, partly answered by https://requests.ci-train.ubuntu.com/static/error.gif probably
<tsdgeos> dednick: greyback: https://code.launchpad.net/~aacid/qtmir/timestampsInPast/+merge/280567
<tsdgeos> and https://code.launchpad.net/~aacid/qtmir/unlikelyResetStartTime/+merge/280569 if you're in the mood of micro-optimizations :D
<greyback> tsdgeos: nice work. dednick can you review plz, since you know it better?
<greyback> tsdgeos: Q_UNLIKELY exists
<tsdgeos> ah right, forgot that code already had Qt includes
<dandrader> @unity looks like the touch emulation from mouse events is broken in trunk. eg. can't drag down the indicators panel or swipe away the lockscreen in "make tryShell". Can you guys reproduce it?
<cimi> hey pstolowski, did it build?
<dandrader> @unity wonder if it's because I installed latest ubuntu-ui-toolkit which has it's own UbuntuGestures....
<Saviq> dandrader, can confirm
<pstolowski> cimi, no, unity8 failed, you probably need to bump debian/control dependencies as it now needs 'unity-shell-application=12
<pstolowski> or tsdgeos ^
<Saviq> pstolowski, that's in trunk
<dednick> tsdgeos: , greyback: sure
<tsdgeos> pstolowski: ok
<tsdgeos> dandrader: but are we loading it? or it loads automagically?
<tsdgeos> pstolowski: filters, right?
<pstolowski> Saviq, tsdgeos ah i see what happened, you bumped unity-api to 7.104 in trunk, so now we need to bump to 7.105 in the silo
<pstolowski> tsdgeos, yes; we need 7.105 now, i'm bumping shell plugin and unity-api, pls bump in unity8
<pstolowski> (in the filters branch)
<dandrader> tsdgeos, since uitk qml plugin
<dandrader> tsdgeos, depends on it, I think that lib will be loaded
<dandrader> Saviq, by "can confirm" you mean you can reproduce the issue or you mean you will check?
<tsdgeos> pstolowski: ok, pushed
<pstolowski> thx
<Saviq> dandrader, I reproduced, yes, sorry
<Saviq> dandrader, you need to bump unity-api dependency in lp:~dandrader/qtmir/sizeHints
<dandrader> Saviq, done
<Saviq> dandrader, tx
<Saviq> dandrader|afk, merge trunk, too
<dandrader> Saviq, done
<Saviq> tx
<maikeul> hello folks, i'm getting these errors when running any X application with Xmir: http://pastie.org/private/evaqzjyuvhwtudi4li5yhw i know there is no support for this, but maybe you might have an idea what could be the problem, or where to start looking at ? thanks in advance
<greyback_> maikeul: I suggest you ask in #ubuntu-mir
<maikeul> ha thanks, my bad
<dandrader> Saviq, do you know when we changed from qt 5.4 to 5.5?
<Saviq> dandrader, it migrated last week
<Saviq> dandrader, on 10.12
<Saviq> and UITK on 11.12
<tsdgeos> ltinkl: it's the same diff as before it was approved, but ok
<ltinkl> tsdgeos, yeah but we found new issues
<dandrader> Saviq, the problem is that MouseTouchAdaptor is no longer working because the xcb event types have changed with qt 5.5 it seems
<dandrader> Saviq, thus the "make tryFoo" stuff no longer getting touch emulation
<tsdgeos> ltinkl: i see
<ltinkl> dandrader, how can the xcb types change, that's not related to Qt
<dandrader> ltinkl, qt's 5.5 xcb  platform plugin changed the handling of xcb events, so MouseTouchAdaptor should mimic that change
<mcinitreevan> Hey, I'm trying to add a shortcut to the help overlay with Unity 7, but it isn't working, and I'm not 100% sure why. My best guess is that I have to go into compiz-profile-unity.convert in both compiz and unity and add the relevant shortcut, but I still have yet to try that. Anyone have any insights into this?
<dandrader> ltinkl, maybe qt's registers itself differently now on the X11 side, causing xserver to send it a different range of events
<dandrader> ltinkl, seems to be related to Xinput2 events
<ltinkl> dandrader, aha
<tsdgeos> hmmm
<tsdgeos> make xvfbtestDragHandle fails in xenial
<tsdgeos> can anyone reproduce? dandrader|lunch: mzanetti_: ?
<Saviq> tsdgeos, there's a bunch of tests failing in X
<Saviq> checking
<Saviq> yeah "Received a fatal error"
<Saviq> tsdgeos, â
<tsdgeos> that didn't use to fail locally (i think)
<Saviq> tsdgeos, could very well be Qt 5.5
<tsdgeos> i guess
<Saviq> although QMetaProperty::read: Unable to handle unregistered datatype 'PaletteValues_QMLTYPE_21*' for property 'Palette_QMLTYPE_22::selected' looks bad
<tsdgeos> i don't have that
<tsdgeos> http://paste.ubuntu.com/14027904/
<tsdgeos> is that i have with xvfbtestDragHandle
<tsdgeos> oh, the one without xvfb behaves better
<tsdgeos> and has the metaproperty things you mention
<pstolowski> cimi, silo 54 rebuilt
<tsdgeos> Saviq: something's bad with that metaproperty error, really suspecting a Qt regression or something since if you run the tests one by one them all work, but all together gets us that + crash :/
<tsdgeos> investigating
<Saviq> :(
<pstolowski> cimi, ping
<dandrader> tsdgeos, "make tryDragHandle" doesn't work as well
<tsdgeos> did that use to work?
<dandrader> tsdgeos, right now I'm working on making the touch emulation work again
<dandrader> tsdgeos, sure
<tsdgeos> dandrader: module "Unity.Test" is not installed
<tsdgeos> is that what you get?
<dandrader> tsdgeos, yes
<dandrader> tsdgeos, I was specially interested in DragHandle as your nodda changed it quite a bit
<tsdgeos> i think that's just the import paths being somehow broken
<tsdgeos> don't think it's the same as that weird "unregistered datatype 'PaletteValues_QMLTYPE_21*' for property 'Palette_QMLTYPE_22::selected' " error
<dandrader> tsdgeos, yes
<tsdgeos> dandrader: it's a shame because that nodda branch worked fine on friday, i guess it's all exploded by now :D
<dandrader> :)
<mterry> ltinkl, yeah I hadn't considered the whole customization aspect of the wizard yet -- we can probably keep compatibility there?  Or did we change how pages work that much that it just won't work at all?
<mterry> ltinkl, we probably want to keep that first page named the same on disk, as low-hanging compatibility fruit
<ltinkl> mterry, we changed... esp. with the language (and SIM) detection that's needed subsequently for the new  timezone  page
<mterry> ltinkl, it's a big pain to break that for them -- especially imagine if we had more different kind of phones shipping.  If we're going to break it, let's also throw in future-proofing so we don't break them again
<mterry> ltinkl, I am still confused on why it was necessary, but I trust ya
<mterry> ltinkl, how can we change the interface so that we are less likely to break them upon future redesigns?
<ltinkl> mterry, I'll think about it, gtg now, later today
<dandrader> Saviq, around?
<Saviq> dandrader, wassup?
<Saviq> dandrader, just noticed dialer app with a white bar at the bottom, worried it might be us after all
<Saviq> not telling the client the right surface dimensions
<dandrader> Saviq, hmm
<dandrader> Saviq, before or after that fullscreen property fix?
<dandrader> Saviq, dialer is not fullscreen...
<dandrader> Saviq, looks normal here in arale. post-fix though
<dandrader> Saviq, hmm, when over the greeter (emergency call). got t
<dandrader> Saviq, so unrelated to the Session.fullscreen fix, but still a bug somewhere, maybe this one is indeed in qtubuntu
<Saviq> dandrader, before fix
<dandrader> Saviq, and after fix as well, just checked
#ubuntu-unity 2015-12-16
<tsdgeos> Saviq: that metatype error is weird :D I can reproduce with this simple code http://paste.ubuntu.com/14047921/ http://paste.ubuntu.com/14047922/
<tsdgeos> still digging
<Saviq> kk
<corn_field> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1526591
<ubot5> Ubuntu bug 1526591 in unity8 (Ubuntu) "Camera app in blank after power off/on" [Undecided,Confirmed]
<Saviq> corn_field, can you confirm it's back after a few seconds? (like under 10s)
<corn_field> Saviq, nope, i've waited 2 minutes and nothing, also the UI is in a strange state, if i tap on the video it does nothing, if i tap the screen i see the focus animation but still on a black screen
<Saviq> corn_field, k, recovered fine here after a few seconds - anyway, not a unity8 issue, reassigned to camera-app (might get reassigned to the media backends in the end)
<corn_field> Saviq, if i swipe from the right i get into the photo roll, that works but i i go back it;s still the black screen
<corn_field> Saviq, yep, probably not unity8 bug :D
<corn_field> btw, i'm on arale/mx4 not bq
<Saviq> dandrader, need to bump unity-shell-application CMake req in lp:~dandrader/qtmir/sizeHints
<Saviq> should be =13, is =12
<dandrader> Saviq, done
<Saviq> tx
<tsdgeos> Saviq: so i "fixed" the ugly warning but testDragHandle still crashes :/
<Saviq> tsdgeos, you'll get there, I'm sure
<cimi> tsdgeos, if I add a department then I cancel it, the text in the search box is not aligned, silo 54
<tsdgeos> cimi: do you have a screenshot?
<cimi> tsdgeos, telegram :)
<tsdgeos> hmm
<tsdgeos> ok
<tsdgeos> pstolowski was seeing this too
<tsdgeos> but i wasn't i was hoping it was because things
<pstolowski> yes, i've seen this many times
<tsdgeos> but it is not i guess
<tsdgeos> i'll have to have a look now :D
<pstolowski> i still should have screenshots if that helps
<cimi> :D
<tsdgeos> pstolowski: what unity-api branch am i supposed to use value-slider-iface ?
<pstolowski> tsdgeos, https://code.launchpad.net/~stolowski/unity-api/value-slider-iface/+merge/278428
<tsdgeos> cimi: how do you do that exactly?
<tsdgeos> pstolowski: â
<tsdgeos> it works fine in make tryDash here
<pstolowski> tsdgeos, o
<pstolowski> tsdgeos, i'll let you know later after installing filters silo again (currently investigating something else)
<pstolowski> tsdgeos, btw is the fix for the textfiled regression on the image yet?
<tsdgeos> pstolowski: what textfield regression? the click thing?
<tsdgeos> yes
<pstolowski> tsdgeos, k, cool
<greyback> Saviq: dandrader: https://code.launchpad.net/~gerboland/qtubuntu/fix-max-full-switch-size/+merge/280699
<cimi> tsdgeos, I select a department, I delete it
<tsdgeos> cimi: how do you delete it?
<cimi> the cancel?
<cimi> iir
<tsdgeos> can you please try to give me the exact steps?
<Saviq> greyback, tx
<tsdgeos> cimi: ok i can reproduce, interestingly doesn't happen on the desktop :S
<dandrader> @unity any of you guys run unity8 or unity8-dash on your desktop (as an X11 application) and use the touch emulation from mouse events feature?
<dandrader> @unity note that I'm not counting the "make tryFoo" case
<tsdgeos> cimi: fixed
<tsdgeos> pstolowski: can you trigger a silo rebuild
<pstolowski> tsdgeos, ok, build started
<dandrader> Saviq, mzanetti_, do we care about x86 vivid builds?
<mzanetti_> depends :D
<mzanetti> dandrader, have more context?
<dandrader> mzanetti, so I'm updating MouseTouchAdaptor to work with Qt. 5.5
<dandrader> mzanetti, and in doing so it requires yet more libs besides xcb: x11 and xi2
<dandrader> mzanetti, so I'm changing the CMakefiles so that we don't build touch emulation from mouse events on arm
<dandrader> mzanetti, to get rid of those "legacy" dependencies on the phone
<dandrader> mzanetti, and it doesn't make sense to emulate touches on the phone anyway
<dandrader> mzanetti, but new MouseTouchAdaptor code might have something Qt 5.5 specific there
<dandrader> mzanetti, ie, something that wouldn't work on Qt 5.4, which is what we have in Vivid+overlay
<mzanetti> ah, I see
<mzanetti> hmm... we do have 5.4 in the vivid-overlay?
<mzanetti> erm, 5.5
<mzanetti> no
<dandrader> mzanetti, qt 5.5 is a xenial-only thing I think
<mzanetti> ah, so you'd ifdef it away for armhf builds
<dandrader> mzanetti, yes
<mzanetti> mhm... if you're adding those ifdefs anyways, can't you just add "&& QT_VERSION >= 5.5" or so?
<dandrader> mzanetti, so the question is whether it's worth the trouble of checking if MouseTouchAdaptor also builds in Qt 5.4 (vivid)
<dandrader> mzanetti, and works
<mzanetti> well, I would think it shouldn't be much efforts given you do the stuff for armhf already
<mzanetti> but if I'm wrong with that, I guess we can give up vivid&x86 support in trunk...
<dandrader> mzanetti, and the second question is whether I should keep the MouseTouchAdaptor code in unity8 and unity8-dash "main.cpp"s
<dandrader> mzanetti, as it's only useful if you run them directly as an app in your desktop and pass "--mousetouch"
<dandrader> mzanetti, the make tryTests do it in another way
<mzanetti> I for one haven't used ./run.sh in ages
<mzanetti> and also the whole shell can now be operated with mouse too
<mzanetti> so I guess it can go away if it's a maintainance effort
<dandrader> mzanetti, well, run "make tryShell" in trunk and try to move away the greeter :-D
<mzanetti> didn't you say the make try stuff wouldn't be affected?
<mzanetti> but yeah, I guess the issue that the small greeter version is not mouse friendly
<dandrader> mzanetti, hmmm looks like autopilot uses it:
<dandrader> mzanetti, tests/autopilot/unity8/shell/tests/__init__.py:152:                '-mousetouch'
<dandrader> mzanetti, that's what I'm fixing now
<mzanetti> which is probably a bad idea
<dandrader> mzanetti, the touch emulation is broken in xenial now that it has qt 5.5
<mzanetti> autopilot should not use mousetouch but instad tap() and mouseClick() when needed
<dandrader> mzanetti, absolutely
<dandrader> mzanetti, but I'm not touching that can of worms :-)
<mzanetti> haha
<mzanetti> well, I guess it's indeed easier to fix mousetouch then :D
<dandrader> mzanetti, yes :D
<mzanetti> however, we should at least a trello card for that can of worms
<dandrader> mzanetti, yes
<dandrader> mzanetti, shall I create one?
<mzanetti> please
<dandrader> mzanetti, https://trello.com/c/TyEoxwAj
<mzanetti> dandrader, turns out this is ours after all: https://bugs.launchpad.net/mir/+bug/1517133
<ubot5> Ubuntu bug 1517133 in unity8 (Ubuntu) "[regression] Mouse speed in Unity8 is much lower than elsewhere (to the point of useless)" [High,Incomplete]
<Saviq> dandrader, mzanetti, agreed we should do away with --mousetouch completely, if we can, small greeter version should probably react to click (change text to "... or click your mouse" when it discovers mouse hover over itself?)
<mzanetti> yeah... sounds reasonable
<dandrader> mzanetti, about the mouse speed bug. will check once mir 0.18 lands
<dandrader> mzanetti, I would take duflu's observations with a grain of salt.
<tsdgeos> Saviq: greyback: can you guys have a look at https://code.launchpad.net/~aacid/unity8/dash_backgroud_source_size_rework/+merge/276157 ?
<dandrader> tsdgeos, would you have some time to review this one? https://code.launchpad.net/~dandrader/unity8/updateMouseTouchAdaptor/+merge/280718
<tsdgeos> dandrader: sure
<dandrader> tsdgeos, thanks
<Saviq> tsdgeos, ack
<greyback> tsdgeos: ack, looking
<greyback> wow that's a high resolution image
<greyback> is it literally just 2 triangles?
<greyback> or are there gradients I cannot see
<Saviq> greyback, not worth it to make them into anything smarter, it's only loaded and scaled once on startup, and the next time we get an updated background we'd have to yank it out anyway
<greyback> Saviq: sure, it's just a lot of scaling to do at startup
<greyback> I'm not suggesting doing anything fancy
<Saviq> greyback, ideas welcome
<Saviq> we could in theory ship 5 different sizes of the background... but I'd have to see numbers that it's actually worth it
<greyback> Saviq: surely 1080p is the highest resolution realistically we support
<Saviq> and ultimately we should generate and ship one that's exactly right for the device
<Saviq> greyback, desktop
<Saviq> greyback, fullscreen dash
<greyback> Saviq: sure, but that's still max 1920 pixels
<Saviq> greyback, 4K
<Saviq> ask mzanetti
<greyback> ok
<Saviq> greyback, not like there are no phones with 4K screens already
<mzanetti> ?
<greyback> such a simple image might be more efficient saved and uncompressed with svg
<greyback> but would require some research to prove
<Saviq> greyback, you need to generate a bitmap from the svg first anyway
<greyback> sure, but it doesnt have to read loads of pixels from uncompressed png
<greyback> efficient cpu time I mean
<Saviq> it's not compressed?
<greyback> it needs to uncompress portions of the png before sampling
<Saviq> greyback, so yeah, we'd need numbers to prove that anything else can get us substantial startup improvements
<greyback> right
<tsdgeos> Saviq: i've pushed a new change to https://code.launchpad.net/~aacid/unity8/fixQmlTestsNewSDK/+merge/280260 since another _action_button sneaked, do you need to re-top approve or it's ok?
<greyback> Saviq: startup plus hotplug monitor events
<Saviq> tsdgeos, it's ok
<tsdgeos> dandrader: so we're good asuming we will never support arm+x11?
<Saviq> greyback, in theory moves across monitor boundaries, too, but that we can avoid
<dandrader> tsdgeos, I don't see any use case for arm+x11
<tsdgeos> dandrader: it's the same use as x86+x11, just less common :D
<Saviq> dandrader, please sort alphabetically, though
<Saviq> in debian/*
<dandrader> Saviq, done
<tsdgeos> dandrader: could you add in the commit what this actually fixes besides whta ti does?
<tsdgeos> something like "make tryFoo works again"
<tsdgeos> if that is what it does :D
<dandrader> tsdgeos, done
<dandrader> tsdgeos, and this https://code.launchpad.net/~dandrader/unity8/fixDragHandleTest/+merge/280733
<dandrader> tsdgeos, with those two branches, now I can finally continue the nodda review :)
<tsdgeos> dandrader: don't workaround the crashes :D (j/k)
<mterry> Saviq, can we fit https://code.launchpad.net/~mterry/unity8/briefly-inactive/+merge/280492 in?
<mterry> Saviq, that's a CVE bug
<Saviq> mterry, right, totally
<mterry> mzanetti, if you can give https://code.launchpad.net/~unity-team/unity8/lockout-time-travel/+merge/280206 another look, maybe I can squeeze it into the next silo
<mzanetti> kk
<mterry> thanks!  :)
<mzanetti> mterry, question:
<mzanetti> doesn't this still suffer from the issue that guy on the mailing list had=
<mzanetti> ?
<mzanetti> ah no... tooEarly is working again now :)
<Saviq> dandrader|lunch, looks like loggingCategory has a conflict with trunk? https://ci-train.ubuntu.com/job/ubuntu-landing-031-1-build/lastBuild/console
<greyback> yep
<mterry> mzanetti, the fix that solved the mailing list guy's issue was not re-using the now pointer for delayTarget
<mzanetti> yeah... I figured
<tsdgeos> dandrader|lunch: one of the test segfaults, see the MR
<Saviq> josharenson, can you please rebase slim_greeter branch on top of lp:~lukas-kde/unity8/cursorHiding, there's a conflict in Shell.qml
<josharenson> Saviq: sure
<Saviq> ah there wouldn't be a conflict if not for ltinkl's OCD about missing newlines ;)
<Saviq> josharenson, that might be a better solution, gimme a sec to verify if that's it
<ltinkl> Saviq, uh where what
<josharenson> Saviq: ha ok, I like pretty code, so no worries
<Saviq> ltinkl, https://code.launchpad.net/~lukas-kde/unity8/cursorHiding/+merge/279198#diff-line-272
<ltinkl> grmbl ye, sorry :/
<ltinkl> but it looks tidy, doesn't it? ;)
<Saviq> ltinkl, yeah please undo that newline
<Saviq> ltinkl, then we don't need to rebase anything around
<ltinkl> Saviq, ok, in the same MP?
<ltinkl> anyways, done
<Saviq> ltinkl, yeah, just a revert of that line
<Saviq> ltinkl, in a case like that (typo you had to push), it's ok to --overwrite
<ltinkl> Saviq, ok, always forget those bzr pecularities :)
<Saviq> ltinkl, not like that's specific to bzr :)
<Saviq> you --force in git if you rewrote history, too
<mzanetti> Saviq, this *is* approved. could be considered too if not too late :)
<mzanetti> https://code.launchpad.net/~unity-team/unity8/lockout-time-travel/+merge/280206
<Saviq> mzanetti, already added
<Saviq> or is it...
<Saviq> thought I added it
<davmor2> Saviq: I blame you :P
<Saviq> davmor2, oh what happened, was there an earthquake?
#ubuntu-unity 2015-12-17
<mine_field> welp, is unity8 in a broken state on 16.04 or is something wrong with my install. using unity8 desktop session mir, (just updated everything), unity8 loads, i can see the launcher and the top bar but instead of the wallpaper all i see is black, deep black :'( and when launching apps from the launcher, apps don't load X-( :'(
<vila> df
<Saviq> vila, some 20GB
<Saviq> mine_field, any chance you got some PPAs enabled?
<vila> Saviq: lol, damn focus ;)
<tsdgeos> mzanetti: would you do https://code.launchpad.net/~aacid/unity8/testIndicatorsMenuFix/+merge/280165 ? or want me to find someone else?
<mzanetti> tsdgeos, ack, will do
<tsdgeos> tx
<mine_field> Saviq, yep, i have libertine
<Saviq> mine_field, if that's silo 19, move to silo 21 instead
<Saviq> should be no need for silos soon
<mine_field> Saviq, uuuu nice :D thanks
<dandrader> hmmm... unity-files-daemon decided to eat half of my CPU time
<dandrader> Saviq, is there still time to add more branches to the current silo?
<Saviq> dandrader, yeah, still waiting for mir 0.18 to release
<dandrader> Saviq, https://code.launchpad.net/~dandrader/unity8/fixDragHandleTest/+merge/280733 and https://code.launchpad.net/~dandrader/unity8/updateMouseTouchAdaptor/+merge/280718
<Saviq> dandrader, both there already :)
<dandrader> Saviq, oh, ok. what's the silo number btw?
<Saviq> dandrader, https://requests.ci-train.ubuntu.com/#/ticket/784 - silo 31
 * Saviq thinks maybe should skip sizeHints while we're blocked with Mir...
<dandrader> Saviq, what's the problem with sizeHints?
<mzanetti> tsdgeos, that test passes for me without your patch too
<tsdgeos> mzanetti: i have an irc log saying it failed for you :D
<tsdgeos> mzanetti: xenial?
<Saviq> dandrader, no problem with sizeHints, but it's the only thing that makes us wait for mir 0.18
<dandrader> Saviq, and why is that?
<Saviq> dandrader, because mir 0.18 needs to land qtmir
<Saviq> dandrader, and you need to land qtmir
<Saviq> for sizeHints
<tsdgeos> dandrader: about "package 'UbuntuGestures' not found", do you have it installed?
<tsdgeos> or did you use dpkg-buildpackage?
<dandrader> tsdgeos, I "apt-get dist-upgrade"d it
<tsdgeos> dandrader: that's weird, the .pc pacakge is still called UbuntuGestures
<dandrader> tsdgeos, is has a .pc package?
<dandrader> s/is/it
<tsdgeos> ah wait
<tsdgeos> i think i have shit in my pc
<davmor2> tsdgeos: man just use a toilet like the rest of  us :P
<tsdgeos> davmor2: nobody told me i could leave my chair whjile working!
<davmor2> :D
<davmor2> commode chairs ftw
<tsdgeos> dandrader: yeah it's /usr/lib/x86_64-linux-gnu/pkgconfig/UbuntuGestures.pc provided by libubuntugestures5-dev 1.3.1761+16.04.20151216.1-0ubuntu1
<tsdgeos> dandrader: which version of libubuntugestures5-dev do you have installed?
<dandrader> tsdgeos, none :D
<tsdgeos> dandrader: :?
<dandrader> tsdgeos, gotta update debian/control btw
<tsdgeos> dandrader: i did
<tsdgeos> like 5 mins ago :D
<tsdgeos> dandrader: the floatingflickable tests work :/
<dandrader> tsdgeos, I installed nodda on my nexus 7 and paired it with a bluetooth mouse
<tsdgeos> dandrader: i'm not saying floatingflickable works
<tsdgeos> just saying that the tests do
<dandrader> tsdgeos, ok. bad sign indeed
<tsdgeos> i'm not sure i have a way to test the floatingflickable as you say
<tsdgeos> i do not have a nexus 7
<dandrader> tsdgeos, a nexus 4 would do
<tsdgeos> dandrader: a nexus11?
<dandrader> tsdgeos, have you been drinking? :)
<tsdgeos> nexus10 i mean
<tsdgeos> dandrader: do i have to answer that?
<dandrader> tsdgeos, I think it's no longer supported. but if it flashes correctly it should be ok
<tsdgeos> i'll tackle that after fixing the disable timers thing
<tsdgeos> dandrader: though ideally we'd "fix" the unittests to fail
<dandrader> tsdgeos, definitely
<mcinitreevan> ping Trevinho, when you say to wrap the variables in a blank namespace, like this? http://pastebin.ubuntu.com/14073473/ or should the whole rest of everything be wrapped in that namespace too?
<Trevinho> mcinitreevan: hi
<Trevinho> mcinitreevan: only the const global variables
<Trevinho> so logger and gnome_media_Settings..
<Trevinho> See the patch I sent you
<Trevinho> basically you get the whole thing by applying that :-)
<Trevinho> mcinitreevan: ^
<mcinitreevan> Trevinho: Oh, I didn't see any patch, I was just fixing it all by hand based on the comments - I should have it ready in just a minute :)
<Trevinho> mcinitreevan: fine, ping me when you need the final review...
<mcinitreevan> Trevinho: Pushed, thanks for all the help!
<Trevinho> mcinitreevan: thank you for the contribution!
<mcinitreevan> Happy to help :)
<mterry> mzanetti, thanks for the lockout-time-travel review.  Glad to see that's going to make OTA8
<mterry> mzanetti, I want to try out your input branch, looks like it still needs a review itself
<tsdgeos> mterry: you mean OTA9 ;)
<mterry> tsdgeos, heh.  I was thinking too much about time travel I guess  :)
<tsdgeos> D_:
<Saviq> @unity, dednick: standup
<kgunn> wil
<kgunn> oops ww
<tsdgeos> dandrader: https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/removeTimeConstraintsFromSwipeArea/+merge/280868 exposes removeTimeConstraintsFromSwipeArea so i can use it in http://bazaar.launchpad.net/~aacid/unity8/nodda/revision/2108
<tsdgeos> let's see what zsombi says :)
<dandrader> tsdgeos, skimmed through it. looks ok
<dandrader> mzanetti, ping
<mzanetti> dandrader, hey
<dandrader> mzanetti, should I be able to flick through the windows in the desktop spread using my finger (touch input)?
<mzanetti> dandrader, yes
<dandrader> mzanetti, tried that in "make tryDesktopStage" and it doesn't work. Don't know why...
<mzanetti> used to work
<mzanetti> dandrader, also there needs to be a minimum amount of apps in there
<mzanetti> or it will be non-interactive
<dandrader> hmmm
<mzanetti> some 8 or so I think
<dandrader> mzanetti, right, that was it! thanks!
<mzanetti> don't know the number. it's calculated by the width they require and the width it provides
<dandrader> mzanetti, btw, tsdgeos's nodda branch broke that but DesktopStage tests still passed
<mzanetti> oh
<dandrader> mzanetti, is that feature tested?
<mzanetti> the flicking... not sure tbh... I definitely have put more focus on mouse/kbd interaction on that so far
<mzanetti> dandrader, it's not entirely feature complete when it comes to touch interaction yet
<mzanetti> but well, I guess I should add a test for that
<mzanetti> thanks for letting me know
<dandrader> mzanetti, or, actually, maybe the more correct thing would be a FloatingFlickable test....
<dandrader> mzanetti, and then it lies on me
<mzanetti> works for me :D
<tsdgeos> dandrader: there's a FloatingFlickable it just that it passes
<cimi> pstolowski, tsdgeos in which scope I test the optionselector filter?
<cimi> silo 54
<tsdgeos> i don't think there's any scope exposing those yet?
<pstolowski> cimi, use mine lp:~stolowski/+junk/scope-filters ; in the click/ dir you will find armhf package
<cimi> ok
<Trevinho> mcinitreevan: hey, still here?
<Trevinho> mcinitreevan: I've commented the MP, please fix that var name :)
 * greyback_ signs off for the holidays
<greyback_> o/
<mterry>  mzanetti, "He's a nice guy" :)  (mail from Rob Schroll in ubuntu-phone)
<mterry> Internet approved
<mzanetti> hah
<mcinitreevan> Trevinho: Blah, I was going to compile it on my server to test, but I didn't because I didnt have the build deps. I'll do it once I get home and can make sure it compiles :)
<Trevinho> mcinitreevan: if you can just rename the variable I can test-build it...
<Trevinho> So we can try to land this before xmas :)
#ubuntu-unity 2015-12-18
<Saviq> tsdgeos, hey, I thought of something re: huge background, could we put it through the thumbnailer so it caches the scaled down version?
<tsdgeos> Saviq: we could, but that would not help with smooth resizing i guess
<Saviq> tsdgeos, yeah it would, I'm only after not resizing from the 4K bitmap every time we load
<Saviq> tsdgeos, like you did in the branch, just instead of loading directly, put it through thumbnailer
<Saviq> this way the next time we load it, we should have a cached, scaled down version
<tsdgeos> Saviq: ok, i was still waking up :D
<Saviq> nw :)
<tsdgeos> Saviq: i guess it wold work yes
<tsdgeos> Saviq: want me to alter the MR or stack it on top in a different MR?
<Saviq> tsdgeos, same MR is fine
<tsdgeos> k
<tsdgeos> Saviq: pushed, please make sure the commit log i made makes sense :D
<Saviq> tsdgeos, tak
<Saviq> tsdgeos, hmm thumbnailer can't deal with file:// urls?
<Saviq> tsdgeos, according to https://developer.ubuntu.com/en/apps/qml/tutorials/use-ubuntu-thumbnailer/ you shouldn't need the .substr()
<tsdgeos> hmmm
<tsdgeos> it didn't work i think last time i tried
<tsdgeos> let me see
<tsdgeos> oh it does work
<tsdgeos> weird i must have been doing something wrong
<Saviq> yay
<tsdgeos> good catch
<tsdgeos> it did indeed look ugly
<dkessel> how could i try the new "ubuntu personal" unity8 desktop? using an iso or using a lxd session?
<Saviq> dkessel, you need to install unity8-desktop-session-mir and select the "Unity 8" session in greeter
<Saviq> no other way today I'm afraid
<dkessel> ok thanks Saviq
<tsdgeos> lol
<tsdgeos> QWARN  : tst_DragHandle::dragThreshold_horizontal(rotated 90) file:///usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/Themes/Ambiance/1.3/ButtonStyle.qml:45: TypeError: Property 'gu' of object function() { [code] } is not a function
<tsdgeos> the line is
<tsdgeos>     implicitHeight: units.gu(4)
<Saviq> what is "units"?
<tsdgeos> you know the typical units.gu thing we use everywhere
<Saviq> yeah I know, but what it is in this case
<Saviq> sounds like the context property didn't get set proper (/me hates context properties btw, they're too "magically there" :P)
<tsdgeos> Saviq: it's the problem we're finding with Qt 5.5 and the SDK having statics
<tsdgeos> i'm refining the problem to give zsombi a reproducible case and stumbled upon it
<tsdgeos> more fun than something that i wanted really to fix
<Saviq> ack
<tsdgeos> :D
<tsdgeos> https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1527546 is the crash/bg
<ubot5> Ubuntu bug 1527546 in ubuntu-ui-toolkit (Ubuntu) "Crash when having multiple QQuickViews in a row" [Undecided,New]
<tsdgeos> dednick: you here?
<tsdgeos> Saviq: are our xenial silos building fine?
<tsdgeos> xavigarcia is having a trouble with one giving him https://launchpadlibrarian.net/230433259/buildlog_ubuntu-xenial-armhf.unity8_8.11%2B16.04.20151218.1-0ubuntu1_BUILDING.txt.gz
<Saviq> tsdgeos, just finding out now, yesterday there was a problem with some other migration
<tsdgeos> that if i read correclty seems a dependncy problem?
<Saviq> tsdgeos, yeah, if that's current then we're stuck, proposed has some migration issues
 * Saviq will investigate in a mo
<tsdgeos> oka
<Saviq> was hoping it'd be gone by now
<tsdgeos> not sure how recent it is, let me ask
<tsdgeos> Saviq: seems it's from today :/
<tsdgeos> but yeah if you can push some buttons it'd be great
<dednick> tsdgeos: i am
<tsdgeos> dednick: k, xavigarcia was looking for you and you don't seem to be on the canonical irc
<dednick> tsdgeos: i can't get on either
<dednick> not for like 2 days now.
<tsdgeos> oh
<dednick> tsdgeos: ah. removing dns got me back on
<Saviq> tsdgeos, hah, http://pastebin.ubuntu.com/14087111/
<tsdgeos> boooo
<tsdgeos> so we did not rebuild that?
<tsdgeos> i mean how did that happen?
<tsdgeos> we had a landing after 5.5.1, no?
<Saviq> yeah, I think it's an explicit dep
<Saviq> tsdgeos, bug #1527544
<ubot5> bug 1527544 in oxide-qt (Ubuntu) "liboxideqt-qmlplugin 1.11.3-0ubuntu1 in xenial-proposed not installable" [Critical,In progress] https://launchpad.net/bugs/1527544
<Saviq> wonder how did that happen
<Saviq> ah that's not going through silos
<cimi> tsdgeos, pstolowski did you try pawel scope with silo 54? crashes for me when clicking filters
<pstolowski> cimi, what crashes? the shell?
<cimi> the scope
<cimi> on desktop too
<cimi> when I click on the filters
<tsdgeos> yaeh the scope doesn't work
<pstolowski> cimi, hmm apparently something broke since i last checked. will take a look
<tsdgeos> i think it needs a rebuild or something
<tsdgeos> it has that behaviour of blocking the dash
<tsdgeos> becaue it takes too much to start/crashes
<cimi> terminate called after throwing an instance of 'unity::LogicException'
<cimi>   what():  unity::LogicException: Variant does not contain a double value:
<cimi>     boost::bad_get: failed value get using boost::get
<cimi> oh ok then other stuff...
<cimi> noticed now the log continues
<pstolowski> tsdgeos, re the crash of filters test scope - do you has hasStartValue() before calling startValue() on rangeinput filters as agreed before?
<pstolowski> s/has/call/
<pstolowski> in any case i'm changing it to issue a warning and return 0 instead of throwing. not ideal, but better than aborting
<tsdgeos> pstolowski: let me check
<tsdgeos> pstolowski: but anyway, yeah never throw :D
<tsdgeos> pstolowski: that'd be in the slider value, no?
<pstolowski> tsdgeos, no, it's the simple range input filter with to input boxes
<tsdgeos> ah right
<pstolowski> tsdgeos, so no value is perfectly correct
<tsdgeos> yeah
<tsdgeos> so i do use it and do not use it
<pstolowski> :)
<tsdgeos> you better change it
<tsdgeos> it makes the qml/js life easier
<pstolowski> ok, just make sure you don't show the value if has*Value is false
<tsdgeos> pstolowski: so what i was saying
<tsdgeos> is that i have code that does http://paste.ubuntu.com/14087668/
<tsdgeos> so it is not used, but it is accessed
<tsdgeos> since it makes it easier to have a function that does the check
<tsdgeos> instead of copying the code 4 times
<pstolowski> tsdgeos, ah, i see
<tsdgeos> cimi: you're doing https://code.launchpad.net/~stolowski/unity8/shareData-rename/+merge/280056, right?
<dandrader> mzanetti, revision 2094 broke some code. you removed priv.foregroundMaximizedAppIdIndex but it's still being referenced in a couple of places
<dandrader> mzanetti, in DesktopStage.qml
<mzanetti> uh
<mzanetti> kk, will fix
<pstolowski> cimi, tsdgeos i fixed the crash in silo 54
<tsdgeos> :)
<cimi> tsdgeos, yes
<Saviq> ltinkl, re: when to update .po/.pot files, I realized that you might if you're aware of one more thing in Ubuntu - langpacks - which are generated out-of-band from the normal release process and updated periodically
<ltinkl> Saviq, I see, thx
<Saviq> ltinkl, as you can see unity8 packages don't actually ship the .mo files, they're stripped off of the packages and langpacks are generated as needed: http://packages.ubuntu.com/search?searchon=contents&keywords=unity8.mo&mode=exactfilename&suite=xenial&arch=any
<Saviq> ltinkl, https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/Packaging#Language_Packs
<Saviq> actually now I look at it am not so sure langpacks are updated outside of package releases :P
<ltinkl> Saviq, ye it doesn't mention that; how does it fit with our different release process?
<Saviq> ltinkl, at the very least langpacks are generated before every OTA
<ltinkl> Saviq, yea, at least that :) so rc-proposed is likely left out, right?
<Saviq> ltinkl, oh yeah, that's for sure ;)
<Saviq> OTOH the latest langpack is from 1216
<ltinkl> Saviq, ugh that doesn't look good
<ltinkl> Saviq, 2014-08-27 really?
<Saviq> ltinkl, 12.16
<Saviq> 2015.12.16
<ltinkl> ah :) I thought revision number
<ltinkl> or 1216, the true medieval language pack
<Saviq> ltinkl, they seem to be updated every week for "in-flight" archives https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=language-pack-touch-pl&field.status_filter=&field.series_filter=vivid
<ltinkl> Saviq, in-flight?
<Saviq> ltinkl, vivid overlay, xenial (not released)
<Saviq> tsdgeos, have two failures in silo 31 http://pastebin.ubuntu.com/14088316/, anything springs to mind?
<Saviq> that's on vivid
<tsdgeos> hmmm
<cimi> tsdgeos, pstolowski the range filter makes it crash
<cimi> when you set min and max
<tsdgeos> cimi: i think pstolowski was fixing that?
<cimi> that's another one then i wasnt aware
<pstolowski> no, looks like something else
<cimi> try setting a min and max value, it crashes
<pstolowski> cimi, ignore range filter for now. it's the first time i actually see it on the screen after implementing it. my test scope doesn't even honor it yet
<cimi> ok so I will just review the optionselector of albert
<tsdgeos> Saviq: can't see anything in silo 31 that would cause these tbh
<tsdgeos> Saviq: is there a branch with all the branches merged or do i create one for myself?
<Saviq> tsdgeos, lp:~ci-train-bot/unity8/ has them all
<Saviq> tsdgeos, lp:~ci-train-bot/unity8/unity8-ubuntu-xenial-landing-031 in particular
<Saviq> tsdgeos, could be flaky, is all, I will run adt again
<Saviq> will try a local build as well
<tsdgeos> Saviq: also adt has different/more failures than qmluitests sometimes because we don't "split/organize" things for it (as we seldom run it)
<tsdgeos> so that may be a reason too
<Saviq> tsdgeos, might be indeed
<cimi> tsdgeos, refine your results doesnt work for me too
<cimi> tsdgeos, did you try the test scope by pawel?
<tsdgeos> cimi: i did, like 3 months ago
<cimi> cooool :D
<tsdgeos> cimi: what "doesn't work2?
<cimi> I set two optionselector filters, I press "refine your result" reset button
<cimi> and nothing happens
<tsdgeos> "Refine results" is a label
<tsdgeos> the "Reset" button is not linked to it
<cimi> but the reset next to it?
<tsdgeos> it's a UI fail if you think they are :D
<tsdgeos> yes there's a reset button next to it
<cimi> yeah is UI fail indeed
<cimi> but the reset button, that looks like a label and not a button, doesnt click
<tsdgeos> i'mk not sure if he has implement the restet function
<tsdgeos> it does, when running make tryDash and clicking on it i can clearly see the debug line printed
<cimi> ah ok
<tsdgeos> so the bug can be
<tsdgeos> a) reset is not implement on his side
<cimi> I see your code just does scopeView.scope.resetFilters()
<cimi> so it belongs to pawel
<tsdgeos> b) the reset implementation on his side breaks on the UI level when propagating the changes
<cimi> anchors seems fine too
<cimi> the AButton is on top of the label so...
<cimi> ok
<tsdgeos> Saviq: i've looped dashheadertest on that branch and doesn't seem to fail
<cimi> tsdgeos, I'm gonna approve those two optionselector branches, they seem to work apart this unimplemented reset
<cimi> tsdgeos, the ranges one are not testable on a real scope, they crash, so I'd hold on on them
<tsdgeos> yeah, well he's away for the next week
<tsdgeos> so i guess we can continue next year :)
<cimi> tsdgeos, it's not a good reason not to approve option selector :)
<tsdgeos> right
<tsdgeos> that would be nice
<tsdgeos> lands 4 branches
<tsdgeos> not sure how doable it is though
<tsdgeos> otoh we can land all the branches too
<tsdgeos> since no scope uses those filters
<tsdgeos> so even if there's some issues it won't matter
<tsdgeos> and the tests on our side "kind of prove" they "kind of work"
<cimi> well, option selector works and I tested, I would not approve the ranges or you would too?
<tsdgeos> not that we can't land anything yet anyway since the oxide-qml thing :D
 * tsdgeos gets a cookie
<Saviq> tsdgeos, ack
<cimi> tsdgeos, approved \o/
<tsdgeos> :)
<tsdgeos> cimi: you approving the 2 parents?
<cimi> yeah
<cimi> big xmas sales!
<cimi> :D
<cimi> approving branches like santa is giving away gifts
<tsdgeos> :)
<davidcalle> tsdgeos: what's wrong with oxide-qml? I've discovered that I couldn't start webbrowser-app on xenial anymore, does it just need a rebuild against latest qt or is it something else?
<davidcalle> (since you are meintionning it...)
<tsdgeos> davidcalle: yeah needs a rebuild it seems
<davidcalle> ok, ty
<tsdgeos> davidcalle: https://bugs.launchpad.net/ubuntu/+source/oxide-qt/+bug/1527544
<ubot5> Ubuntu bug 1527544 in oxide-qt (Ubuntu) "liboxideqt-qmlplugin 1.11.3-0ubuntu1 in xenial-proposed not installable" [Critical,In progress]
<Saviq> davidcalle, note this problem's only in proposed, so if you don't have proposed enabled, your issue's something else
<balloons> ChrisTownsend, still need that update on the best way to run Unity8 atm. Can you spread some love on https://wiki.ubuntu.com/Unity8inLXC and https://wiki.ubuntu.com/Unity8Desktop ?
<ChrisTownsend> balloons: Oh, right, sorry, forgot about those.
<ChrisTownsend> balloons: Ok, I've updated those pages.
<balloons> ChrisTownsend, lovely thank you! :-)
<ChrisTownsend> balloons: You're welcome.
#ubuntu-unity 2016-12-19
<KristijanZic> Guys, anyone here? I was writing the comment on the omgubuntu about new scopes mockups and was brainstorming how to make them more useful and attractive for the user and I think I just came up with the idea that could save the scopes! And make both users and developers/publishers happy!
<KristijanZic> Ok, so I outlined a very crude general idea in this document and some reasoning behind it, you are welcome to edit it, give your opinions, comments, everything https://docs.google.com/document/d/1BKGQFQuWQn7rG74Zi3APt2wNtu0mC11J2Iadxa48sHE/edit?usp=sharing
<mterry> @unity it *appears* that our issues with mesa in proposed causing autopkg tests to fail is resolved.  Can anyone confirm seeing LP pass those?
<tsdgeos> mterry: CI doesn't run against proposed afair
<tsdgeos> *our* CI
<mterry> tsdgeos: not CI, but brittany does
<mterry> tsdgeos: that's what we were blocking
<tsdgeos> ah, then i don't know where i have to look at :D
<mterry> tsdgeos: a page like http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html shows migration status for ubuntu -- but I was just curious if anyone was aware of a package there being held up that did land after all
<mterry> All the unity8 lines there seem to be green
<tsdgeos> mterry: sure i know of that, but since we landed we won't be there even if we still failed i thought you meant somewhere else
<mterry> So I guess we're good
<tsdgeos> ah right, other packages
<mterry> tsdgeos: well we'd be holding up others
<mterry> yay
<mterry> I'm guessing it was the new gcc, since the crash I saw was in libgcc
<mterry> But who konws
<mzanetti> mterry, can you log into jenkins?
<mzanetti> I managed like 20 mins ago, but now I can't any more
<mzanetti> pff, now it worked again
<mterry> mzanetti: yeah just did
<mterry> must be flaky
<mterry> Is anyone using the unity8-greeter?  I tried turning it on for my xenial system, but it doesn't come up (just stays black)  :(
<dmj_s76> andyrock: I tested your scaling patch.
<dmj_s76> Would recommend against it because it has really counterintuitive behavior and doesn't solve the intended issues.
<dmj_s76> andyrock: did you see my patch in https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1649736
<ubot5`> Ubuntu bug 1649736 in unity (Ubuntu) "unity picks poor hidpi scale factor defaults" [Undecided,New]
#ubuntu-unity 2016-12-20
<dmj_s76> andyrock: thanks for helping with the hidpi scaling issue.  Let me know when it lands and there's test packages.  Looking forward to the SRU for xenial/yakkety.
#ubuntu-unity 2016-12-21
<chatter> hey guys
<chatter> allah is doing
<chatter> sun is not doing allah is doing
<chatter> to accept islam say that i bear witness that there is no deity worthy of worship except allah and muhammad peace be upon him is his slave and messenger
#ubuntu-unity 2016-12-25
<ukernyanz>  hi everyone, i have some problems with applications which uses Breeze icons or other kde icons sets under unity. Even if a choose another icons, after an application restart, icons are still in "Adwaita" icon set. When I log to the plasma desktop, everything works fine. Can you help me to solve the problem?
