#ubuntu-unity 2013-01-07
<smspillaz> duflu: howdy, when do you want to cut 0.9.0 ?
<smspillaz> erm
<smspillaz> 0.9.9
<smspillaz> 0.9.0 was a long time ago ;-)
<duflu> smspillaz: Not sure now. Needs time to settle again :P
<smspillaz> duflu: I have some large-ish fixes in the pipeline, so I'm wondering when I should hold them to
<duflu> smspillaz: Yeah large stuff after 0.9.9.0
<smspillaz> duflu: right, I just kinda wanna know /when/ as in dates, so I can plan my week :)
<duflu> smspillaz: I really don't know now. Probably safe to assume we don't want to land anything large this week
<smspillaz> duflu: sure, I'm wondering when a good time to start reviewing large things is :)
<duflu> smspillaz: Don't know. I half expect to have time when I'm away next week. But maybe not
<smspillaz> well, next week will probably be bad for both of us
<smspillaz> I'm at uni for a week and you'll be away
<smspillaz> so the week after that ?
<smspillaz> I'm just mindful that it would kinda suck if we delayed until right before freezes start happening
 * duflu checks schedule
<duflu> smspillaz: Freeze is not an issue (March 7). If things have not landed by then, there must be other greater reasons why not
<smspillaz> welllllllllllllllllllllllllllll
<smspillaz> there's like 4 or 5 big ones
<smspillaz> I'm allowing a week for each
<smspillaz> duflu: anyways, maybe what I'd suggest doing is testing my ppa and checking for regressions and filing bugs ?
<smspillaz> that will allow us to get the manual-testing process mostly out of the way
<duflu> smspillaz: We will do as much as possible with the resources available. I don't know how that will pan out over the coming months
<smspillaz> duflu: fair enough I guess
<duflu> I think the point of 0.9.9.0 is to show "any release" from this point onward could be released. Just do as much as possible
<smspillaz> duflu: +1
<smspillaz> duflu: anyways, I'd suggesting running the ppa. Been running it for about a month now and I'm fixing things as they come up
<wnm> hey guys. i've got a question, maybe someone can help. I just created an desktop entry with chrome's "create application shortcut" feature. I downloaded icons in different sizes and put them in ~/.local/share/icons/hicolor each size in each directory. the new icon is showing when i search for the application with dash. but when I switch applications with [alt]+[tab] its showing the chrome icon and it says "untiteled". does someone know a guide on how to pro
<conscioususer> Cimi: overlay scrollbars discussions belong in this channel?
<Cimi> conscioususer, maybe
<Cimi> conscioususer, I have no plans to work on them this cycle though
<conscioususer> Cimi: actually, I wanted to discuss a possible bug before reporting
<Cimi> conscioususer, shoot
<conscioususer> Cimi: hold on, I'll pastebin a code
<conscioususer> Cimi: here, this is for Python3: http://www.pasteshare.co.uk/p/5ir/
<conscioususer> Cimi: this is a textview overlayed over a scrolledwindow
<conscioususer> Cimi: did it run?
<Cimi> no
<Cimi> tell me the issue, maybe is a known one
<conscioususer> Cimi: the overlay is not being rendered
<conscioususer> Cimi: this only happens if overlay scrollbars are active
<Cimi> they both use a child window
<Cimi> not sure what overlay does though
<conscioususer> Cimi: specifically, this happens if the widget below the overlay is a scrolledwindow inside a gtklayout
<conscioususer> Cimi: and, very weirdly, the bug does not happening in Ambiance/Radiance, only with Adwaita and High Contrast, for example
<conscioususer> Cimi: (I didn't mention this until now because you said the code is not running anyway)
<conscioususer> Cimi: btw, *why* is it not running, which error did you get?
<Cimi> I didn't run it :)
<conscioususer> oh, ok
<conscioususer> Cimi: as you can see, you need a rare combination of widgets to trigger it... but it's one I'm needing now :-/
<conscioususer> Cimi: what I found particularly weird is happening for some themes but not for others
<Cimi> try seeing what triggers the issue
<Cimi> editing the theme
<conscioususer> Cimi: that will take a while cuz Adwaita etc. compile everything including css'es into a binary .gresource file
<conscioususer> Cimi: need to get the source
<conscioususer> Cimi: will contact you later
<Cimi> gnome-themes-standard git
<conscioususer> Cimi: none of the themes seem to do anything specific with GtkLayout
<conscioususer> Cimi: however, I'm seeing something interesting
<conscioususer> Cimi: Adwaita sets a background color for GtkScrolledWindow, and HighContrast sets a background color for GtkViewport (which is used by GtkScrolledWindow)
<conscioususer> Cimi: the light-themes do not set a background color for either
<Cimi> so it's an issue of rendering
<Cimi> those two themes render the scrolledwindow/viewport
<Cimi> ambiance doesn't
<conscioususer> Cimi: but would is this triggered only when the ov-scrollbars are active?
<Cimi> because it's a bug in overlay scrollbar
<conscioususer> Cimi: hmm... and one last question before reporting: does it make sense to you that it happens only when the scrolledwindow is inside a gtklayout?
<Cimi> I don't know...
<conscioususer> Cimi: well, anyway, will report... should it be directly against the overlay-scrollbar LP project?
<Cimi> ayatana-scrollbar
<Cimi> I suggest you to pick up os-bar.c code and play with it
<Cimi> I don't think I will ever fix this in next months
<conscioususer> Cimi: might try, thanks for the help
<didrocks> hey mterry! saw that you are around :) how was the week-end?
<mterry> didrocks, meh.  Spent a lot of it looking at a data corruption issue in duplicity
<didrocks> doesn't sound fun
<mterry> didrocks, eh, it's fine.  When I'm weekend hacking, I can drink during, so not so bad  :)
<didrocks> heh ;)
<mterry> didrocks, what's up?
<didrocks> mterry: I was thinking switching some -dev from arch: all to arch: any
<didrocks> like nux as a first target
<mterry> didrocks, what's in the -dev that needs it?
<didrocks> nothing but:
<didrocks> because when unity is build-dep on latest nux
<didrocks> nux i386 is built and published
<didrocks> then unity on all arch starts to build
<didrocks> and the -dev can't install libnux amd64 for instance
<didrocks> so FTBFS
<mterry> right, just saw that one go by
<didrocks> this was fine in the distro, I relaunched the build normally
<didrocks> but if we want to go to our daily process
<didrocks> don't seem something we should get bothered why, thoughts?
<mterry> didrocks, I mean, arch: any is a fine workaround (just takes up archive space right?  I assume no policy problems), but isn't that really a builder bug?  That it only looks one level deep in dependencies before trying a build?
<didrocks> mterry: yeah, it's a builder bug that we have for ages, I think it's not a priority to get it fixed though
<didrocks> the space -> just a couple of .h files + symlinks
<didrocks> so I think it's not that an issue
<mterry> Just feels dirty  :)
<mterry> But sure
<didrocks> ok, proposing some dirts in a few :)
<mterry> I would normally volunteer for the work, and will do so, but I first want to prepare duplicity SRUs for this bug
<didrocks> sure sure, just feel free to approve the MP then
<didrocks> it's easy and quick enough :)
<mterry> So if you were looking for fast action, I might not get to it until tomorrow
<mterry> OK
<didrocks> doing nux, bamf, libunity, dee
<didrocks> ah nux is already any, so bamf should have been the guilty
 * didrocks starts to be puzzled, bamf was any as well
<didrocks> which one failed the chroot then?
<didrocks> mterry: ok, will try digging next time (probably tomorrow, after a rebuild)
<didrocks> mterry: seb128: btw, https://launchpad.net/~ubuntu-unity/+archive/daily-build contains latest and greatest (untested)
<seb128> didrocks, need/want testing?
<didrocks> mterry: seb128: as I think we are close to enable daily build (at one UTAH issue closed), would be good to test
<didrocks> yeah ;)
<seb128> ok
 * didrocks upgrades at the same time
 * mterry switches from staging to daily
<mterry> Oh, apparently I'm already using daily.  Odd
<didrocks> :)
<didrocks> upgrade upgrade, there is fresh new things! :)
<seb128> hum
<seb128> didrocks,
<seb128> Les paquets suivants seront ENLEVÃSÂ :
<seb128>   indicator-appmenu indicator-appmenu-tools libbamf3-0
<seb128> Les NOUVEAUX paquets suivants seront installÃ©sÂ :
<seb128>   libbamf3-1
<seb128> didrocks, is indicator-appmenu deprecated?
<didrocks> really? I don't have that on amd64
<seb128> i386 here
<didrocks> interestingâ¦ and the new hud package isn't installed I guess as it's not built
<didrocks> cyphermox: you followed the merged, nothing linked to that in your opinion?
<didrocks> oh, does indicator-appmenu deps on bamf now?
 * didrocks checks
<seb128> didrocks, that's not new, it needs bamf to know what app is focussed iirc
<didrocks> yep
<didrocks> so I need to move bamf in the indicator pocket
<seb128> didrocks, the issue is that libbamf3-1 breaks libbamf3-0
<seb128> and indicator-appmenu didn't get rebuild with the new bamf soname
<didrocks> to have things built in the correct order
<cyphermox> wasn't that recently changed in the indicator-appmenu vs. hud code?
<didrocks> yep yep
<seb128> didrocks, how come you don't get the issue on amd64?
<didrocks> cyphermox: no, this was rolled back
<didrocks> seb128: I wonder if I get the latest state or if everything is published yet
<seb128> didrocks, I'm away for some exercice, will retry in  ~45min but my reading is that indicator-appmenu needs a rebuild with the new bamf soname
<didrocks> seb128: I agree, I'm triggering another one
<seb128> thanks
<didrocks> and will move bamf between package set
<ricotz> mterry, hi
<mterry> ricotz, heyo
<ricotz> mterry, you are argumenting as ABI and API were the same, and i am suggesting to use 0.4 after the several API removals not simply taking the version number
<ricotz> if there is a need to bump the soname (e.g. ABI changes) there is no need to change the GIR name
<ricotz> the typelib will reference the right library as "backend"
<mterry> ricotz, right.  3 is not the SONAME
<mterry> ricotz, libbamf3 currently has a SONAME of 0 I think
<ricotz> right
<mterry> ricotz, much as libgtk-3 has a SONAME of 0
<mterry> ricotz, so sorry.  Maybe I'm just misunderstanding your position.  What's wrong with using 3?
<ricotz> but there is no libbamf anymore, so actually this would mean Bamf3-0.4.gir/typelib
<mterry> ricotz, no other package does that.  They all do Secret-1 or Gtk-3 or similar
<ricotz> imo it is needed to have girs parallel installable on API changes but not on ABI changes/soname bump
<mterry> ricotz, right.  That's what the 3 is.
<ricotz> gtk preserves abi compat so the api 3.0 will stay
<ricotz> take tp-logger for example
<mterry> ricotz, that is a separate thing, eh?  Their ABI compat promise just means they will always have SONAME 0, right?
<ricotz> right, and so will be the api
<ricotz> which is why Gdk-3.0.gir and so on
<mterry> ricotz, their API changes throught the 3.x series.  They add things all the time.  But the parallel installable thing is the 3.0
<mterry> ricotz, just as the parallel installable marker for libbamf is the 3 (like when we had libbamf and libbamf3)
<ricotz> yes, but the api is compatible and isnt broken in regards to backwards compat
<mterry> ricotz, right.  And when it is, they bump to 4.x
<mterry> ricotz, just as libbamf would bump to 4
<ricotz> so if you can promise bamf wont break api exept in major release
<mterry> if it did the same thing
<ricotz> you can all it bamf-1.0
<ricotz> *call
<mterry> ricotz, every other gir/library uses the library version (secret 1, gtk 3) as the gir name.  That library name, to my knowledge, is the same thing as what you are calling the API version.
<mterry> ricotz, why is bamf different?
<ricotz> what i am saying is that changing the gir name on soname bumps is not necessary if the api compat is preserved, which would be not the case with your naming scheme
<ricotz> but do as you like
<mterry> ricotz, that's not true at all
<mterry> ricotz, if bamf bumps SONAME, what happens is we get libbamf-3-1.  gir1.2-bamf-3 and libbamf3-dev would stay the same
<mterry> i.e. exactly the same as secret and gtk
<ricotz> ok, what are you doing on api removals as between 0.3 and 0.4?
<mterry> ricotz, API removals *should* only happen when we bump from 3 to 4.  I believe we had a removal that did not?  Because we were lax and felt the only consumer was unity.  I'd have to go back and look at the merge proposal
<mterry> (^ when we bump from libbamf3 to libbamf4)
<mterry> Really, we shouldn't bother removing API.  I think I noted at the time, we should just make it a no-op
<ricotz> alright, considering 3 as api while preserving abi/api compat for future 0.x releases works
<mterry> ricotz, but whether or not we did the right thing there, that's a separate issue from the naming scheme
<mterry> Because the shared library shares the same problems we created then too, it's not just a gir thing
<ricotz> ok, my problem wer the latest API removals leading this discussion and how to handle that
<ricotz> so if this won't happen after adding the offical introspection data it seems fine
<mterry> ricotz, yar, that was handled incorrectly.  I think we were just lazy about it
<ricotz> ok
<ricotz> mterry, you probably want to take a look at gir1.2-unity-5.0 and its content, i filed a bug about it ;)
<ricotz> https://bugs.launchpad.net/bugs/1096545
<ubot5> Launchpad bug 1096545 in unity (Ubuntu) "gir1.2-unity-5.0 package named wrong while containing Unity-6.0.typelib" [Undecided,New]
<mterry> ricotz, :(
<didrocks> bregma: see my answer, I can't parse how you link daily build with something that has nothing to deal with daily builds
<ricotz> mterry, better to use a fully qualified line in the install file to catch that
<mterry> ricotz, true
<ricotz> uploading daily builds can be tricky
<ricotz> i guess it will be 7.0 soon
<didrocks> hey sil2100! how are you?
<didrocks> seb128: i386 published, still waiting on amd64
<sil2100> didrocks: hello! One moment ;)
<didrocks> seb128: mterry: after a one minute of basic testing, the new unity stack seems to work here
<seb128> didrocks, ok, trying in a min
<mterry> didrocks, hasn't crashed on me yet  :)
<didrocks> mterry: neither for me, that's a start :)
<sil2100> didrocks: re-ping!
<didrocks> sil2100: hey!
<didrocks> sil2100: I just wanted to know if you were successful in the bug hunt we discussed on Friday
<sil2100> didrocks: yes, I fixed it, a merge request is submitted - but I'm waiting for a re-comment from Trevinho
<Trevinho> sil2100: ah, looking again
<didrocks> sil2100: that was the branch I saw? You're freaking awesome \o/
 * didrocks stares at Trevinho :)
<didrocks> hey Trevinho, happy new year btw!
<sil2100> Well, it's a rather ugly way of fixing it, but at least the way I did it seemed safe in my broken mind ;)
<didrocks> :)
<didrocks> sil2100: I'm running a newer test with latest unity from today
<didrocks> sil2100: with some luck, we only have those 4 failures!
<Trevinho> sil2100: commented
<Trevinho> didrocks: thanks... happy new year to you too! (including sil2100 here too :))
#ubuntu-unity 2013-01-08
<didrocks> Trevinho: hey, around?
<didrocks> popey: hey! once you are around, some more free karma:
<didrocks> https://code.launchpad.net/~didrocks/dbus-test-runner/bootstrap/+merge/142258
<didrocks> https://code.launchpad.net/~didrocks/libdbusmenu/bootstrap/+merge/142256
<popey> morning didrocks
<didrocks> hey popey! how is the weather in uk?
<popey> Grey. As always. âº
<didrocks> I share the same sky today! :)
<didrocks> what have you done to Lyon? You have broken my weather! :-)
<didrocks> thanks popey ;)
 * didrocks adds 2 to the list of bootstrapped projects now
<popey> np
<didrocks> seb128: popey: do you use standard icon size for unity?
<didrocks> or reduced one?
<popey> depends which way the wind is blowing
<popey> and which machine
<didrocks> :)
<seb128> didrocks, standard
<popey> reduced on laptop, not on desktop
<didrocks> seb128: when you press super, with the daily build ppa, you don't see any empty space between the launcher and the dash?
<seb128> didrocks, btw ppa from yesterday works fine on my laptop, no issue so far ... should I try tweaking the launcher settings?
 * popey tries
<didrocks> popey: you do use the daily build ppa, right?
<popey> on my desktop, yeah
 * popey boots it
<didrocks> seb128: well, I can reproduce it right away ;)
<didrocks> I see that: http://people.canonical.com/~didrocks/tmp/space_in_unity.png
<seb128> didrocks, I don't see it with the default icon size but I confirm when playing with the slider to change the setting
<seb128> it does it for some values
<didrocks> ok, let me open a bug :)
<didrocks> I see as well a bigger size at initialization for half a second
<seb128> k
<didrocks> seb128: mterry mentionned to me to have a super key which seems wonkey for him, I can't reproduce though
<didrocks> like some super press doesn't seem to be acked by the system
<didrocks> popey: if you can try to see if you reproduce this one ^
<didrocks> seb128: also, if you want to confirm https://bugs.launchpad.net/unity/+bug/1097184
<ubot5> Launchpad bug 1097184 in unity (Ubuntu) "Unity daily-build (07.01.13) empty space between launcher and dash in non default launcher size" [Undecided,New]
<popey> didrocks: i can't reproduce a gap between launcher and dash, with any size dash
<popey> s/dash/launcher/ âº
<sil2100> Oh, I have the same issue
<popey> i did manage to catch it once as it shrunk while the dash was open
<sil2100> With the Super key
<didrocks> sil2100: ah, please file a bug, not sure if you have the time to investigate, nice to know you are not alone :)
<sil2100> Not sure what happened, but since some update in staging sometimes I have to wank Super key more than once to get it working now
<popey> hmm, not got latest unity from the ppa.. that'll be why
<didrocks> popey: interestingâ¦ maybe try to set it to 32 and restart unity
<didrocks> popey: ahhhh :)
<didrocks> popey: yeah, that's it! :)
<didrocks> sil2100: please signal that as soon as you catch it
<popey> i dist-upgraded, still showing archive version...
<popey> hmmm
<didrocks> sil2100: it's easier then to find where the regression comes from :)
<didrocks> popey: do you really have the daily-build ppa?
<seb128> didrocks, I had some issues opening the dash with super as well
 * popey stabs ppa-purge and add-apt-repository
<popey> ppa-purge adds a # in .list files, add-apt-repository doesn't notice this
<popey> so blindly says "okay, added repo" but actually doesn't uncomment the list file
<seb128> didrocks, it seems like if you act fat-finger and stay a bit too long on the key the tap doesn't work
<seb128> didrocks, not sure if that's new I tend to use the mouse rather than the keyboard to go to the dash
<didrocks> seb128: ah, indeed, with fat-finger
<didrocks> but the press was 250ms IIRC
<didrocks> maybe the delay should be a little bit longer, not sure if it changed though, didn't see that in the merges
<didrocks> sil2100: want to give it a shot? IIRC, it's a simple #define, you can try increment it
<seb128> didrocks, well in "normal" tapping it seems to work fine in any case
<didrocks> yeah, but slow tapping isn't triggered
<didrocks> and I think in some case of testing, it should
<didrocks> popey: interesting :)
<popey> annoying!
<didrocks> interestingly annoying? :)
<popey> very
<popey> didrocks: ok, i have a gap now âº
<popey> "thanks"
<didrocks> popey: you can put a sticker on it, that's handy! :)
<didrocks> ok, a small one :p
<popey> and yes, it's losing super keypresses
<didrocks> ok, so 2 noticed issues to be fixed before releasing to distro
<didrocks> popey: seb128: do you mind if one of you open the bug for it?
<popey> sure, will do
<sil2100> didrocks: for fixing the Super key-press issue you mean?
<didrocks> yep :)
<sil2100> didrocks: will try, I'll dig and see if they actually changed something that could have caused it to (if the delay changed, or maybe the method how the delay is treated)
<didrocks> sil2100: thanks! :)
<popey> sil2100: bug 1097189
<ubot5> bug 1097189 in Unity "Super key not registered if held too long" [Undecided,New] https://launchpad.net/bugs/1097189
<davidcalle> didrocks, hey. mhr3 told me you would prefer a branch per scope (and I know why), but do you know how to deal with automated translations in this case?
<didrocks> davidcalle: I think we'll go on translation in the ubuntu package, or do you mean you want to activate the possibility to translate in the upstream project?
<davidcalle> didrocks, oh right, forgot about this possibility. Fine for me then.
<didrocks> because if you want to do that, it will be one launchpad project per scope, and it's not fun for you I guess :/
<didrocks> davidcalle: yeah, so don't enable the translation in the ubuntu-scopes launchpad projects
<didrocks> davidcalle: I think it's the easiest, I gave it another thought this week-end, that's why it changed since Friday ;)
<didrocks> and when I thought about it again, I guess you were during your lunch break, not online! :-)
<davidcalle> didrocks, no problem. ;-)
<didrocks> hey mmrazik, can you give it a look? https://code.launchpad.net/~didrocks/libdbusmenu/bootstrap/+merge/142256 it succeeded in one arch, not the other one
<didrocks> and the two pre-merging archs succeded
<didrocks> succeedeed*
<mmrazik> didrocks: looking at it but "xvfb-run: error: Xvfb failed to start" doesn't look very familiar
<didrocks> mmrazik: seems a configuration issue not making it runnable as it ran on i386 before the commit phase and succeeded in http://jenkins.qa.ubuntu.com/job/dbusmenu-ci/./build=pbuilder,distribution=raring,flavor=i386/20/console
<mmrazik> didrocks: don't understand
<didrocks> mmrazik: well, this one PASSED, isn't it? it's the same arch
<mmrazik> sure
<mmrazik> but I just don't see why xvfb-run suddenly stopped working
<mmrazik> not aware of any specific configuration for xvfb-run
<didrocks> mmrazik: if the machine you run on/the configuration is different, maybe there is a different X server started?
<didrocks> maybe just try otherwise rekicking itâ¦
<mmrazik> didrocks: yes please, try to re-approve
<mmrazik> didrocks: the builder machine is shared so maybe some other test/build influenced the build
<mmrazik> but in case of xvfb-run I would expect it doesn't really care
<mmrazik> there is no X running on those builder machines
<didrocks> weirdâ¦
<didrocks> hey andyrock, how are you?
<andyrock> didrocks, good what's up?
<didrocks> andyrock: there is a regression in unity trunk, maybe you will know what happened: bug #1097184
<ubot5> bug 1097184 in unity (Ubuntu) "Unity daily-build (07.01.13) empty space between launcher and dash in non default launcher size" [Low,Confirmed] https://launchpad.net/bugs/1097184
<didrocks> andyrock: do you think you can/have time to work on it? As told on the bug report, the first hint is that on startup, the launcher has the regular size for 0.5s
<andyrock> didrocks, "the launcher has the regular size for 0.5s" it should not be the problem
<didrocks> ok, so another bug? :)
<andyrock> yup let me check DashController.cpp :)
<didrocks> thanks! :)
<duflu> didrocks, sil2100, popey: lp:unity 2970 made the timeout configurable and changed the default from 250 to 130ms. Change it back to 250 if you like :)
<didrocks> yeah, I think this will be saner value, most of tapping are between 250 and 300ms (it's 300ms on android)
<sil2100> I think 250ms was fine ;p
<sil2100> duflu: thanks for the info!
 * sil2100 prepares a merge request
<duflu> didrocks: In independent tests by myself and Brandon we both concluded anything above 130 was "too long". But I don't mind...
<duflu> didrocks: It's because Compiz reliable tap detection is turned off. If the Super timeout is 250 then it's too easy for Super+other_keys to trigger the dash
<didrocks> duflu: any reason than compiz reliable tap detection to be turned off btw?
<didrocks> sil2100: gimme gimme :)
<duflu> didrocks: To fix: https://bugs.launchpad.net/bugs/950160
<ubot5> Launchpad bug 950160 in OEM Priority Project precise "Unity blocks other programs from binding globally to Super+* (* = any key)" [Critical,In progress]
<didrocks> and we don't have anymore issue with alt + something?
<duflu> didrocks: It's not turned off for Alt. So not a problem :)
<didrocks> ah ok :)
<andyrock> didrocks, https://code.launchpad.net/~3v1n0/unity/launcher-options-single-emission
<andyrock> didrocks, i think it's causing the regression
<andyrock> fixing it
<didrocks> andyrock: ah, nice that you spotted the cause, yeah, it seems to be linked
<didrocks> andyrock: do you think that this position is testable?
<andyrock> maybe with autopilot
<didrocks> sil2100: so, now that I've been able to run against latest unity the indicator-unity tests, here are the results:
<Mirv> added a note to the bug report about the side effect reported by smagoun that brandon is currently looking at
<didrocks> sil2100: http://10.97.0.1:8080/job/ps-indicators-autopilot-release-testing/40/label=autopilot-ati/testReport/
<didrocks> sil2100: http://10.97.0.1:8080/job/ps-indicators-autopilot-release-testing/40/label=autopilot-nvidia/testReport/
<didrocks> so 7/8 to fix still (-4 you really did fix, isn't it?)
<sil2100> huh, still failures?
<sil2100> Let me see that :/
<sil2100> test_gedit_undo again?!
<didrocks> seems :/
<sil2100> This means war
<didrocks> on both
<didrocks> at least, the failing ones are common to both
<sil2100> Ok, but now gedit_undo fails differently
<sil2100> And a new failure
<didrocks> ah, at least, what you have done had an impact :)
<didrocks> sil2100: not sure how your load is, but maybe just finish the tap thing so that it's merged, then, I'll approve it and you can go on the failures?
<sil2100> didrocks: the tap thing is submitted for review, so I will look into those failures
<sil2100> (actually am now)
<didrocks> sil2100: jumping on your MP! :-)
<didrocks> sil2100: thanks ;)
<sil2100> https://code.launchpad.net/~sil2100/unity/unity_dash_tap_duration/+merge/142273
<didrocks> if only that was giving ingress points :)
<didrocks> sil2100: oh, yo udidn't link it to the bug report
<didrocks> let me do it
<sil2100> The undo and the one new failure I can try fixing, but the next/prev ones are really mystical - I thought that introducing a wait for the started application will help, but in the end it didn't
<sil2100> But I'll try looking a bit deeper
<sil2100> oh, sorry about that ;)
<didrocks> the 4 test_dash_hud is the one you fix and need another review, right?
<didrocks> maybe after the gedit_undo, you can try unity.tests.test_hud.HudBehaviorTests.test_closes_then_focuses_window_on_mouse_down before the next/prev black magic :)
<andyrock> didrocks, that was the problem. it's fixed now
<andyrock> need to write an ap test
<didrocks> andyrock: you rock! :-)
<andyrock> ;)
<didrocks> mmrazik: is this one stalled? https://code.launchpad.net/~didrocks/libdbusmenu/bootstrap/+merge/142256
<mmrazik> didrocks: I just received an e-mail about that
<didrocks> ah? good timing then :)
<didrocks> mmrazik: we disable the autopilot job as jibel is trying to make the intel box working with raring
<mmrazik> didrocks: ok
<didrocks> and then, once we have the daily build running, this will enable us to kill the staging ppa and this job :)
<mmrazik> didrocks: mhm. the dbusmenu job still failing :-/
<didrocks> mmrazik: urgh, I can't reproduce it here, with a pbuilder, everything is working
<mmrazik> randomly, as now it failed on differen builder host (the same where it passed previously) and different arch
<didrocks> sil2100: any progress btw? :)
<petko10> hey guys , I have a question about developing for the Ubuntu phone OS - the native language is QML/Qt5/C++ right ?
<larsu> petko10, yes: http://developer.ubuntu.com/get-started/gomobile/
<petko10> ok ,nice (I asked , because , though i read most of the info on the gomobile, I didn't see any C++ code , but it's not hard to figure that qt=c++ as I think of it)
<sil2100> didrocks: yes, but now a short break for preparing lunch
<didrocks> mterry: hey! I think you saw that your regression you found was a real one :)
<mterry> didrocks, yeah, looks like it got fixed already
<didrocks> mterry: yeah, I pinged and harassed people
<didrocks> mterry: how full is our plate? do you have time for indicators and unity tests issues?
<mterry> didrocks, mmm, I've got stuff.  I can take some of it off your plate...
<didrocks> mterry: yeah, there are basically 2 kinds of thing, and they are quite urgent to have daily unity release
<mterry> didrocks, OK
<didrocks> mterry: first one is about bootstrapping dbusmenu and libappindicator
<didrocks> dbusmenu still has a test stability issue when merging
<didrocks> see https://code.launchpad.net/~didrocks/libdbusmenu/bootstrap/+merge/142256 for instance
<didrocks> so if you can give it a look, why it's failing on some archsâ¦
<didrocks> the second is libappindicator, which needs bootstrapping and test passing during build, see it with cyphermox about where he stops
<didrocks> lp:~mathieu-tl/+junk/libappindicator for some debug infos
<didrocks> the second issue is what sil2100 is working on
<cyphermox> well, that's basically where I'm at
<cyphermox> didrocks: seems to me like dbusmenu is failing because the script run-xfvb.sh is probably very broken in some way
<sil2100> o/
<cyphermox> mterry: libappindicator: i'm trying to figure out what might be different between the gtk2 tests and gtk3 tests that would explain why the gtk3 tests reproducibly fail while the gtk2 tests pass
<didrocks> mterry: if you have knowledge about that, that would be great ^
<didrocks> mterry: second things is about indicator autopilot tests
<didrocks> mterry: we need to fix them all to be able to start releasing daily unity
<didrocks> the list is at jenkins-qa/job/ps-indicators-autopilot-release-testing/
<didrocks> you can see the 3 archs
<mterry> didrocks,  https://jenkins.qa.ubuntu.com/view/PS/job/ps-indicators-autopilot-release-testing/
<mterry> oh
<mterry> OK, cool
<didrocks> we have 10/7/10 failures
<mterry> Was about to ask if that was right url
<didrocks> yeah, this is the public mirroring :)
<didrocks> so sil2100 has a regression fix for 4 of them
<didrocks> so normally this would be 6/3/6 remaining
<didrocks> can you please coordinate with sil2100 and bregma (who will put brandon on line) to get that to 0?
<didrocks> this can be either tests not stable
<mterry> OK
<didrocks> or real issues
<didrocks> mterry: sil2100 can help you to run autopilot
<sil2100> I see that some issues are still AP typical issues
<mterry> sil2100, is there a wiki for getting myself able to run the indicator autopilot tests?
<sil2100> mterry: a wiki? hm, not really, sadly...
 * mterry goes on lunch+errands, but will come back.  sil2100, if you could leave some notes on running autopilot, unless it's literally as simple as running autopilot inside the indicator source somewhere
<sil2100> mterry: I'll send you an e-mail if that's fine with you?
<didrocks> sil2100: mterry is in the US, so if you can do that before going EOD, it would be awesome :)
<bschaefer> sil2100, mterry hey, I hear you guys are work on fixing the AP tests?
<sil2100> Yes, some failures regarding the indicators mostly
<bschaefer> sil2100, well I was going to join in, and wanted to make sure I didn't step on anyones toes :)
<sil2100> bschaefer: some of the failing tests, for instance, are due to AP not waiting for the application to get focus
<sil2100> (at least that's how it looks like it)
<bschaefer> sil2100, o dang...thomi had a nice ap-view branch that made a list of all the failing AP tests along with the video
<bschaefer> though the video isn't that hard to get from jenkins
<bschaefer> sil2100, this is the list your working through right? http://paste.ubuntu.com/1510013/
<sil2100> Yes, I'm using it all the time ;)
<sil2100> apview.html banzai!
<bschaefer> :)
<bschaefer> yup!
<sil2100> bschaefer: yes, more or less - there are even some more, since the latest indicator ap results have more test failed
<bschaefer> alright, ill keep checking jeninks for more.
<bschaefer> sil2100, I think i've noticed a bug in unity though....when you do a 'unity' and something is striping focus off the windows in the first say 60 seconds
<bschaefer> though i wasn't sure if it was something I was doing :)
<bschaefer> which could explain the AP tests losing focus of an application (since its a fresh reboot)
<sil2100> oh!
<sil2100> That would, hm, really answer the question of why gedit_undo failed last time
<sil2100> hm
<bschaefer> yeah... i was going to dig into it after I got over a bunch of other work I was doing
<bschaefer> im thinking it could be the switcher, but it would be nice to have someone else confirm it :)
<sil2100> Never noticed it though - you say it happens after start of unity?
<bschaefer> yeah
<sil2100> I'll try on a guest session now
<bschaefer> as I have been restarting unity a bunch now
<bschaefer> sil2100, well a compiz --replace
 * bschaefer goes to add debuging statment to nux event loop
<sil2100> Holy shat, you're right
<bschaefer> well dam...I should have filed a bug about it
<bschaefer> well either way, Ill work on fixing that
<sil2100> After like 20-25 seconds suddenly all apps loose focus
<bschaefer> yeah, its strange, ill see what window is doing this in the nux event loop...ill see shortly!
<sil2100> bschaefer: should I fill a bug?
<bschaefer> sil2100, sure, and assign it to me :)
 * bschaefer hopes this is the cause of the problems in the AP tests
<sil2100> This would make sense, since I tried fixing the issues by adding an assertion of window focus, but it didn't help - and it also answers the question why I was unable to reproduce it here
<sil2100> I only once reproduced one of the problems, and I think it might have been right after unity --replace
<bschaefer> sil2100, yeah, interesting, it looks like the switcher steals focus for some reason....
<sil2100> I didn't notice it
<sil2100> \o/
<bschaefer> though let me double check
<sil2100> bschaefer: anyway, great catch!
<bschaefer> a bunch of events when through when it happened
<bschaefer> thanks! You have no idea how annoying that bug was when trying to reset/compile/test/repeat haha
<bschaefer> sil2100, definitely the switcher....
<bschaefer> it sends a bunch of PropertyNotify events when it happens ... interesting ... time to go fix it
<sil2100> bschaefer: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1097368
<ubot5> Launchpad bug 1097368 in unity (Ubuntu) "Windows losing focus after the start/restart of Unity" [Undecided,New]
<bschaefer> sil2100, thanks for filing that!
<bschaefer> sil2100, sorry I hadnt yet, that could have saved you some time ...
<sil2100> bschaefer: no problem, good that you spotted it even now ;)
<bschaefer> yeah, hopefully the fix will be simple!
<bschaefer> sil2100, interesting, the problem appears to be in SwitcherController::ContructWindow, view_window_->EnableInputWindow(true, "Switcher", false, false);
<bschaefer> if you remove that line, everything works, as that chunk of code should be in ShowView (which it is)
<bschaefer> the switcher window it self was being focus (but since its just an nux::XInputWindow really there is no title)
<sil2100> bschaefer: does it need to steal focus?
<sil2100> I mean, hm
<bschaefer> sil2100, nope, it was happening when it was being created
<bschaefer> as there is a bit of a delay when things get created unless you force it
<bschaefer> like with the dash
<sil2100> bschaefer: excellent, well, we don't want it doing that then ;p!
<bschaefer> sil2100, it needs to take the focus when the switcher is started, but there is code in ShowView to do that, which it does :)
<bschaefer> sil2100, sooo now to test this ... hmm
<bschaefer> I don't want to have an AP test that is 30+ seconds long...for each arc
<sil2100> Not sure if that's easy autopilot-testable...
<bschaefer> yeha...
<sil2100> Right, and besides it would require a clean unity start
<bschaefer> plus having to do a compiz  --replace
<bschaefer> yup
<bschaefer> a unit test no...
<sil2100> So maybe an unit test? I know they're not really meant for such things
<bschaefer> i mean...
<bschaefer> hmm...well we could fake creating a the switcher
<bschaefer> which then we could possibly check the panel title
<bschaefer> as it will be empty if it steals focus
<sil2100> hoo, ok, that sounds nice
<bschaefer> well im not sure if I have access to the panel in a unit test
<bschaefer> but I think I can find something to check, I can dig into
<sil2100> Since normally I would say 'let's not test it', but then we'll forget about this issue and again after a while, if it gets reintroduced, we'll be thinking 'what the heck is going on' unnecessarily
<bschaefer> sil2100, yeah I agree, this is one of those regressions that is hard to detect
<bschaefer> as looking at the rev, it was introduced by me :), at like 2500
<bschaefer> sil2100, what are you running? 13.04 or 12.10?
 * bschaefer hopes this wasn't back ported to 12.04
<sil2100> I'm running 12.10, but from staging
<sil2100> I'll check on precise if it's there ;)
<bschaefer> cool, thanks!
<bschaefer> o interesting, it is on a 75ms timer, which is why the unit test atm don't catch it either
<bschaefer> actually no its 20 seconds...
<bschaefer> dam variables looking the same
<sil2100> heh ;)
<sil2100> See you tomorrow!
<bregma> bschaefer, what was the issue with the switcher messing up the AP tests?
<bschaefer> bregma, i haven't confirmed it, but I should run those AP tests
<bschaefer> bregma, it is leaning towards that
<bregma> I'm just looking at what needs to be done to get proper unit tests set up for the switcher
<bregma> so I'm particularly interested
<bschaefer> oo yeah, hmm well I was looking at the unit test, and creating the switcher doesn't appear to make it lose focus :(
<bschaefer> soo that either means there is a deeper problem...or you need to run the unity stack to get it to lose focus
<bregma> the unit tests don't take into account of the fact that a significant portion of the logic of the switcher is in the Unity compiz plugin:  there's a signal fired off when the Switcher is initialized later after its creation, and it's connected to something in the nuityshell somewhere
<bschaefer> bregma, hmm well that could explain that, it would just be nice to fail in a simple unit test :)
<bschaefer> there are bits in the unityshell.cpp that should be moved into the switchercontroller
<bschaefer> .cpp
<bregma> bschaefer, absolutely -- I'm working on a task list for that
<bregma> part of our new focus on total QA
<bschaefer> bregma, awesome, im guessing that is why we need those books haha
<bregma> Switcher seems like a good place to start because it (should be) pretty much self contained
<bschaefer> yes it should!
 * bschaefer wonders why autopilot is being mean
<bregma> hmm, nothing activated by that Switcher signal should be stealing focus
<bschaefer> well I need to dig into why EnableInput for the view steals focus when running unity vs a unit test
<bschaefer> as the problem is in SwitcherController::ContructWindow()
<bregma> how can you tell?
<bschaefer> if you do a compiz --replace and wait 20 secods
<bschaefer> seconds you lose window focus
<bschaefer> and by adding print statements I found it was in construct window, and I commented out enableinputs and then did a compiz --replace
<bschaefer> and then the window focus was no longer being lost
<bregma> ConstructWIndow() calls EnableInputWindow() (from Nux) ... would that do it?
<bschaefer> yeah, that is what the problem was
<bschaefer> but ... doing a unit test that just creates a switcher, and gets to that function doesn't cause unity to lose window focus...
<bschaefer> though...do the unit tests run on a different X Server?
<bschaefer> besides the :)
<bschaefer> :0
<bregma> technically, the unit tests should not need a server and should not uncover this problem
<bregma> that's another story
<bschaefer> very true, I don't think a unit test is proper for this...
<bschaefer> nor is an AP test
<bregma> either way, nux::BaseWindow::EnableInputWindow() is being called with take_focus set to false, so I would expect it to not grab the focus
<bschaefer> yeah I noticed that as well...I need to spend some more time in figuring out *why* that is enable input is causing it to lose window focus
<bregma> ...unless the Nux ABO has changed again and there's a misalignment, but I think that's unlikely
<bregma> *ABI
<bschaefer> yeah, ill do some digging into Nux to figure out why...
<bschaefer> also you can see something is sending the UBUS message to the panel, saying we lost focus
<bschaefer> but it doesn't know the name of the window
<bschaefer> bregma, looking at BaseWindow...it shows the window if the first bool is true
<bschaefer> which simply showing the window could be the problem
<bregma> gorram badly named variables, we need to bring in the daeth penlaty for those
<bschaefer> yes... very
<bregma> no, daeth is too good for 'em
<bschaefer> the take_focus is just for the XInputWindow
<bregma> a boolean variable name 'b'
<bschaefer> haha
<bregma> it answers the question, 'is it b?'
<bschaefer> yes it is a b!
<bschaefer> now everyone knows, though since its an explicit typing system it should be easy to tell!
<bregma> well, it seems to be that creating an XInputWindow without take_focus set shouldn;t steal the focus, but now I have to brush up on XInputWindow
<bschaefer> yeah, the XInputWindow uses the the take_focus to send an PropertyNotify that it is taking focus
<bschaefer> so it sends an XEvent
<bschaefer> which is the event I was receiving  when the switcher was stealing focus
<bregma> so how has this ever worked properly?
 * bschaefer wonders the same thing
<bregma> second question:  why is the Switcher created as a persistent object and not created when needed?
<bschaefer> its the SwitcherController that is just created once
<bschaefer> the model gets created each time you hit alt+tab
<bschaefer> and why there is a timer...im guessing so there is a better start up time....(its done with the dash and the lenses as well)
<bregma> that's my guess, but having the Switcher (and dash et al) created when needed also saves time, and makes simpler more reliable code
<bregma> one of the things on my list is to see comparative timings of persistent vs. as-needed design for the Switcher
<bschaefer> yes...hmm ill see if the EnableTakeFocus is called when the switcher steals focus...
<bschaefer> that would be nice, we still need to get some timing done to work on improving the dash speed
 * bschaefer wonders who that was passed onto
<Stewi3_89> Hi can someone help me restoring unity desktop? I've tryied some Google tips but still not working
<bschaefer> Stewi3_89, could you explain the problem a bit more?
#ubuntu-unity 2013-01-09
<smspillaz> bregma: do you know what the status of those reviews I had up were ? They seem to just be sitting there ...
<bregma> we've been discussing requirements for change to the Switcher
<smspillaz> so I'll need to rewrite them again ? :(
<bregma> maybe
<smspillaz> argh
<smspillaz> maybe I will just fork unity .... this is getting annoying
<bregma> previous problems came from being in a hurry, we taking a moment to think long-term before the next wave of slip hits the fan
<smspillaz> bregma: so one of the things I've learnt is that our short cycles make it impossible to "think things through"
<smspillaz> by the time you've done all the thing its feature freeze
<smspillaz> *thinking
<bregma> well, that has to change or else there's a certain future and it isn't my idea of a successful one
 * duflu remembers fondly the luxury of being able to go away and develop for months and months without interruption or short cycle requirements
<smspillaz> bregma: good luck with that one
<bregma> heh, yeah, I'll need it
<smspillaz> bregma: the only way to survive in a situation like this is to embrace constant improvement over perfection
<smspillaz> because I've seen it happen again and again. We have something that gets us 75% of where we want to go and then people spend forever nitpicking over the details to make it so that every change is "perfect" and then feature freeze happens and you go from 0% to 0%
<smspillaz> examples: sheet style dialogs, mesh icons in the switcher, coverflow, the entire /unity/+activereviews
<duflu> Isn't the problem the lack of people doing nitpicking?
<smspillaz> no the problem is when nitpicking turns a review that should take 3 days into one that takes 13 weeks
<smspillaz> short cycles are a problem, yes. But the best thing we can do is adapt rather than pretend that we don't have short cycles
<bregma> well, there are plenty of problems across the spectrum, and there are ways to avoid those problems
<duflu> I think pretending can be realistic. If something's not ready or people are not confident that it's ready then the next release is only 6 months away. That lines up with commercial software practice where the cycle is measured in years, not months. And it works but is incredibly frustrating to tell people "yeah it won't be released for a year or so"
<smspillaz> duflu: the graveyard of bleeding baby deer that is the unity activereviews page begs to differ that this is an effective solution
<duflu> smspillaz: I haven't got hold of David yet but do you still want to drop the netbook over?
<smspillaz> duflu: maybe sometime today. When do you leave ?
<duflu> smspillaz: A few hours after midnight on Sat morning :(
<smspillaz> lovely
<smspillaz> bregma: in any case ... let me know when you've finalized a design for the switcher that you want. I've got lots of work sitting there waiting that will really help you with where you want to go. its your teams choice as to whether or not engagement happens or it just sits there and does nothing
<mmrazik> didrocks: it looks like the libdbusmenu tests are failing when both archs are scheduled to be built on the same builder host. If I try to execute 2 instances of xvfb-run at the same time one of it usually fails with the same error
 * mmrazik is just reading the man page if it is possible to randomize the server #
<didrocks> mmrazik: oh, interesting, even if it's run in a pbuilder?
<didrocks> so it's not multiprocess?
<mmrazik> didrocks: only tried locally
<mmrazik> ie no pbuilder
<didrocks> ah :)
<didrocks> but yeah, maybe it's what is happening
<mmrazik> didrocks: there is xvfb-run -a
<mmrazik> didrocks: shall I just create a separate MP for that to try it out (and eventually merge) ?
<didrocks> mmrazik: yeah, please do :)
<didrocks> mmrazik: we call it in debian/rules FYI
<didrocks> debian/rules:xvfb-run dh_auto_test --builddirectory=builddir/$*
<mmrazik> didrocks: ack.
<mmrazik> mhm... this is going to be difficult to test as the jobs were scheduled to be built on two different builder hosts
<didrocks> mmrazik: it was scheduled to be built on two different builder hosts? so the failure I just got is not linked to that, isn't it?
<mmrazik> didrocks: hard to tell. in the last case when one of the arch failed it was building on the same host.
<mmrazik> didrocks: my MP with xvfb-run -a is now being built on two different hosts
<mmrazik> didrocks: as well as the last message in your MP (which passed)
<mmrazik> so the hypothesis sill holds
<didrocks> mmrazik: ok, so let's try to get that merged in :)
<didrocks> mmrazik: if we can have that in 2 separate MP, it will be awesome
<didrocks> mmrazik: like, get yours merged
<mmrazik> didrocks: https://code.launchpad.net/~mrazik/libdbusmenu/xvfb-run-a/+merge/142448
<didrocks> and then, we can try again getting https://code.launchpad.net/~didrocks/libdbusmenu/bootstrap2/+merge/142446 merged
<mmrazik> the CI job is running right now (but as I said -- on two different hosts so I expect it will pass)
<didrocks> approved, let's see how it goes :)
<mmrazik> ack
<didrocks> at least, we'll have 2 MP
<mmrazik> didrocks: so the autolanding job just started and both archs are building on the same jenkins slave
<didrocks> mmrazik: sweet, can't wait for the result! :)
<didrocks> the ci passed
<didrocks> let's see autolanding
<mmrazik> didrocks: it probably was the issue because now I see in the logs that one of the server is running on :99 while the other on :100
<didrocks> mmrazik: excellent! so it's something that is leaking through the bindmount of pbuilder
<didrocks> I didn't thought about it
<didrocks> think*
<didrocks> mmrazik: let's continue crossing fingers, that would rock :)
<mmrazik> didrocks: not sure if leaking. I think this is by design. Even in chroot certain resources like sockets I shared (I think)
<didrocks> mmrazik: right, I meant leaking like "not being isolated"
<didrocks> but there are good reasons for that, I can see
<didrocks> I thought though this was done in /tmp
<mmrazik> didrocks: mhm.. the autolanding tests passed but the merge failed with the chk root keys error :-/
<didrocks> mmrazik: urgh, so you are getting the same issue?
<didrocks> you just bzr branch trunk, rihgt?
<didrocks> right*
<mmrazik> didrocks: yes. And you bootstrap2 branch is going to have it too (I just failed to checkout it).
<mmrazik> didrocks: yes
<mmrazik> didrocks: I justr tried the reconcile think and will try to push to a different location in lp
<didrocks> mmrazik: ok, keep me postedâ¦
<didrocks> mmrazik: at least, good news that it seems to have work :)
<mmrazik> didrocks:  no luck :-/
<mmrazik> no idea how to proceed with this :
<didrocks> let's go on #bzr maybe?
<mmrazik> didrocks: wasn't francis already there?
<didrocks> mmrazik: he sent an email, but it was in the US time, we will maybe grab some european folks
<didrocks> mmrazik: do you mind rerunning the merge process? (for your branch first)
<didrocks> so that if we see other issues, we can debug with the bzr guys fast enough ;)
<mmrazik> didrocks: just got merged: https://code.launchpad.net/~mrazik/libdbusmenu/xvfb-run-a/+merge/142448
<didrocks> \o/
<didrocks> mine mine mine now! :-)
<mmrazik> didrocks: the jenkins job just started
<didrocks> mmrazik: refiling coffee meanwhile :)
<didrocks> mmrazik: and merged \o/ Thanks again :-)
<mmrazik> great :) it only took a day or so :)
<didrocks> heh
<sil2100> didrocks: hi!
<didrocks> hey sil2100! how are you?
<sil2100> didrocks: the fix introduced by https://code.launchpad.net/~brandontschaefer/unity/skip-switcher-lazy-loading-timer/+merge/142396 should fix some of the indicator failures \o/
<sil2100> Yesterday evening we found this one and analyzed as a possible reason for all those annoyances
<didrocks> sil2100: yeah, I saw that, I'm running an unity rebuild right now and then, will rerun the indicator ones
<didrocks> sil2100: I saw the discussion, it's awesome :)
<didrocks> sil2100: however, on your branchâ¦ I didn't see anything proposed on the autopilot side
<didrocks> so maybe worth to merge it meanwhile?
<sil2100> You mean, the fix for the test_mouse_changes_selected_hud_button I proposed yesterday?
<didrocks> yep
<sil2100> Not sure if we should change the default rate for all mouse movements
<didrocks> yeah, I wonder as well
<didrocks> so, that's why I think we should merge yours for now
<didrocks> and we can eventually remove that later on
<sil2100> Indeed I'll have to consult Thomi, but sometimes it's not necessary, and it would only slow down the tests
<didrocks> if autopilot changes it
<didrocks> wdyt?
<sil2100> Yea, I think so too
<didrocks> want me to approve drastically?
<sil2100> didrocks: please ;) Some free karma for you as well ;p !
<didrocks> heh, here is a drastic approval!
<didrocks> sil2100: nice work! :-)
<didrocks> sil2100: do you know if you can still work on other remaining failures meanwhile I rerun a full test?
<didrocks> sil2100: and how did it go with mterry, was he able to setup his configuration fine?
<sil2100> didrocks: he went to eat lunch and do errands, I sent him instructions on how to run autopilot for indicators, but I didn't hear back from him
<sil2100> So I don't know
<didrocks> ok :)
<didrocks> sil2100: did you wait on the result or working on the next() prev() tests?
<didrocks> there are 8/9 hud tests failing from what I can see
<sil2100> didrocks: after Brandon's fix?
<sil2100> And my icon fix?
<didrocks> yeah, just without your "move slower the mouse"
<sil2100> huh
<sil2100> So the 4 tests I fixed by fixing the regression still fail?
<sil2100> Same for gedit_undo?
<sil2100> Doesn't make sense
<didrocks> https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-release-testing/label=autopilot-ati/lastCompletedBuild/testReport/
<didrocks> https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-release-testing/label=autopilot-intel/lastCompletedBuild/testReport/
<didrocks> https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-release-testing/label=autopilot-nvidia/lastCompletedBuild/testReport/
<didrocks> there is not the gedit_undo, isn't it?
<sil2100> Oh, so it's not for the indicators?
<didrocks> we run hud tests as well, isn't it?
<sil2100> Ok, some other tests fail I see
<didrocks> yeah, only the hud ones (I rerun all the tests, as I was rebuilding unity)
<didrocks> so this is with all the fixes, but the slower mouse move
<sil2100> Yes, but the prev next and undo things stopped failing, some new failures appeared, hm
<didrocks> which don't impact those tests?
<didrocks> yeah
<sil2100> Ok, let me look in detail into this
<didrocks> thanks :)
<MCR1> didrocks, sil2100: Hi :) HUD in Unity trunk also has problems to show the correct icon, but overrides the correct icon with the first one all the time...
<MCR1> didrocks, sil2100: The icon from the first HUD line always overwrites all others, which is quite bad :(
<didrocks> hum, I can see in trunk always the right icon here
<MCR1> didrocks, sil2100: Also something with the blur gotta be done - the blur function is incredibly slow, especially with free drivers...
<sil2100> didrocks: ok, so, there is one HUD fix I will add now which I forgot to commit and push yesterday for fixing the focuses_window_on_mouse_down
<sil2100> MCR1: hmm, didn't notice that
<sil2100> With the HUD I mean
<MCR1> sil2100: Maybe it is MCR-specific then - strange though...
<didrocks> sil2100: oh oh nice! :)
<sil2100> didrocks: but those 8 new HUD failures I see for the first time ;p
<didrocks> sil2100: maybe we don't run them as part of the indicators tests, let me recheck. I just stumbled above them
<didrocks> sil2100: hum, we do run unity.tests.test_hud
<didrocks> so they should be run, isn't it?
<didrocks> ok, first getting your merge in and rebuilding unity :)
<sil2100> Right, so maybe latest unity trunk broke something? Since those never failed before
<didrocks> sil2100: yeah, maybe brandon's fix has this side effect of not hiding this bug :)
<sil2100> hehe\
<didrocks> send the MP once ready! :)
<MCR1> When I open the Dash or HUD here, running video starts to stutter, the blur kills my framerate completely (on quite fast hardware ATI HD 5750) - this does not happen with fglrx, but with free gallium radeon driver...
<didrocks> sil2100: I'm about to leave for some exercice, I would like just to have your merge in the queue before you have it handy :)
<sil2100> didrocks: ok, pushing ;)
<didrocks> mmrazik: hey, how can I see which packages are installed in jenkins-qa/job/ps-indicators-autopilot-release-testing/46/label=autopilot-intel/ ?
<didrocks> mmrazik: even if only the indicators should be installed, I've a similar result than when using the whole ppa
<didrocks> so I wonder if it doesn't take unity from the ppa
<didrocks> sil2100: any luck btw? :)
<mmrazik> didrocks: #46 is still running you will be able to see it only after it has finished
<mmrazik> didrocks: here it is for #45: https://jenkins.qa.ubuntu.com/job/ps-indicators-autopilot-release-testing/45/label=autopilot-ati/artifact/results/artifacts/machine-config/dpkg-list.log/*view*/
<mmrazik> you need to go to the machine and then there are build artifacts
<mmrazik> and there its in results/artifactrs/machine-config dir
<sil2100> didrocks: https://bugs.launchpad.net/unity-2d/+bug/1060262 <- it's released? Where?
<ubot5> Launchpad bug 1060262 in unity-2d "Unity-2D SRU-1 needs releasing" [Medium,Fix released]
<didrocks> mmrazik: look at job/ps-indicators-autopilot-release-testing/46/label=autopilot-intel/artifact/results/artifacts/machine-config/dpkg-list.log
<sil2100> It's not released...
<didrocks> mmrazik: it has unity from the ppa where it shouldn't
<didrocks> sil2100: I based on the date, please revert if I've mistaken
<sil2100> I specifically pushed it back to the queue to get it released again, since last time it got rejected :<
<didrocks> mmrazik: see ii  libunity-core-6.0-5                       6.12.0daily13.01.09.1-0ubuntu1           i386         Core library for the Unity interface.
<sil2100> Now it'll land in the sponsoring queue from the beginning again :<
<didrocks> sil2100: well, juts revert to fix committed
<didrocks> sil2100: that doesn't change a thing :)
<sil2100> ;)
<didrocks> sil2100: so, at least, with that, we have the confirmation that the tests for hud fails now
<didrocks> sil2100: btw, you know that you have the ogv?
<didrocks> sil2100: for the test failing
<sil2100> didrocks: yes, I watch it every time - I'm using apview ;)
<sil2100> A really useful tool btw.!
<mmrazik> didrocks: weird... I'm just looking at the preseed and I don't see anything wrong there. dist-upgrade happens before adding the ppa
<didrocks> sil2100: apview?
<mmrazik> didrocks: is it possible that something like bamfdaemon pulls all that in as a dependency?
<mmrazik> ok
<mmrazik> bamf is probably a bad example...
<didrocks> mmrazik: no, it's not, it's a good one
<didrocks> so bamf broke its abi
<didrocks> so there is a newer package
<didrocks> do you have the apt install log?
<sil2100> didrocks: https://code.launchpad.net/~autopilot/+junk/apview
<didrocks> we should maybe "force" the version for the rest
<mmrazik> didrocks: not really :-/
<mmrazik> didrocks:  let me try to ssh to the machine. maybe its around there
<didrocks> mmrazik: or abort if we see that it wants to install something more than just those packages
<didrocks> because it means that the stack can't be released alone
<didrocks> jibel: FYI ^
<didrocks> I guess that's what happened, but a confirmation would be good
<mmrazik> didrocks: you mean to abort the build?
<didrocks> sil2100: oh nice! :)
<mmrazik> (i.e. jenkins build)
<didrocks> mmrazik: yeah, or exiting on error
<didrocks> like if we try to install more than just the list specified
<mmrazik> didrocks: are the install logs somewhere around in the system?
<didrocks> I think jibel is looking for them
<mmrazik> didrocks: http://pastebin.ubuntu.com/1512782/
<mmrazik> jibel: ^
<mmrazik> thats from /var/log/apt/history.log
<mmrazik> if I interpret it correctly it indeed upgraded libunity et al
<Mirv> sil2100: I tend to use fix committed for bugs that actually have the fixed package on its way to the release in the system
<mmrazik> didrocks: I'm not really an expert on preseed, though (where this is happening). I fear that if I remove the "-y" the install will just silently fail but the testing will go on
<Mirv> sil2100: and in progress until that
<Mirv> ie. unity-2d still needs the push to the queue, I think?
<didrocks> mmrazik: yeah, so it's the cause
<didrocks> mmrazik: I think -y shouldn't be needed, indeed, as we specify all binaries, jibel am I right?
<didrocks> not sure if a command on preseeding failed if it will failed though
<jibel> didrocks, I don't think -y is the problem here, it just answer yes to all prompts but apt will abort if there is an undesirable situation
<didrocks> jibel: well, the issue is that the ppa is there for it
<didrocks> jibel: so it's not undesirable
<didrocks> it will just pull more from the ppa
<didrocks> which is what we don't want
<didrocks> (when specifying what we want to install)
<didrocks> libbamf3-0 became libbamf3-1
<jibel> didrocks, could unity be pulled by dependency ?
<didrocks> so running the check with only and only the indicator stack should failed
<didrocks> jibel: right
<didrocks> as we have a version in the ppa build for unity against libbamf3-1
<jibel> I mean versionned dependency
<didrocks> well, not versionned, it's a binary package name change due to soname change
<didrocks> but the result is the same
<didrocks> so apt is telling "I can't install libbamf3-1 alone"
<didrocks> "oh, there is a unity in the ppa that can match the dep, let's install it"
<didrocks> which is what we don't want when installing in the ppa (and don't use "check with whole ppa")
<jibel> a solution could be to pin the ppa with high score to not auto-install packages
<didrocks> the ideal plan is that the install should just fail and that's it.
<didrocks> jibel: you meant, low score?
<jibel> or low I never remember which direction priority goes :)
<jibel> didrocks, or if it doesn't work, hold all the packages in the ppa excepted those we want to install/upgrade
<didrocks> jibel: I wonder if it will work apart from holding, yeah
<didrocks> and you do think that utah will see the preseeding failing and we'll get the apropriate rejection?
<jibel> didrocks, heh, that's another story
<didrocks> mmrazik: can you try to add to the preseed where we explicit set the packages to install:
<didrocks>  /etc/apt/preferences.d/pinning-ppa with: http://paste.ubuntu.com/1512873/
<didrocks> mmrazik: this before the apt-get update
<mmrazik> didrocks: but having that for the unity stack update is no good, right?
<didrocks> mmrazik: no, only when we provide a package list
<mmrazik> ok
<didrocks> so that it doesn't impact "build with whole ppa" as well
<MCR1> sil2100, didrocks: If you have a minute: https://code.launchpad.net/~mc-return/unity/unity.merge-fix-redundant-assignment-of-variables-to-themselves/+merge/142512
<didrocks> MCR1: approved, thanks :)
<MCR1> np
<sil2100> hehe, thanks
<sil2100> didrocks: so anyway, at least I know now that the 8 additional failures are real regressions ;)
<didrocks> mmrazik: feel free to launch the jenkins job for the indicators once you have done the change (it seems ATI has stalled)
<didrocks> sil2100: yeah, good to have tests, isn't it? :)
<mmrazik> didrocks: ok
<sil2100> Indeed! ;)
<didrocks> sil2100: please keep me posted, and let's try to sync with mterry once here
<mterry> didrocks, hello!
<mterry> didrocks, I'm mostly back to operational
<didrocks> oh already around? :)
<didrocks> it's early for you, isn't it?
<mterry> didrocks, yeah early start today, since I'm likely going to be slow to ramp up today (still recovering from hard drive break)
<didrocks> mterry: urgh, hard drive breakage and real world test of your recovering then? :)
<mterry> didrocks, eh, I don't need most of the backup contents for work
<mterry> didrocks, that was mostly a million bzr branches and pbuilder chroots and such
<didrocks> ah ok, not a great loss fortunately :)
<mterry> didrocks, let's hope so.  I haven't actually tried to restore my backup yet  :)
<didrocks> sil2100: btw, you should introduce mterry to apview for debugging the autopilot failing tests, it looks nice, indeed :)
<mterry> didrocks, so do we have the results of an autopilot run after those couple fixes yesterday?
<didrocks> mterry: yep, and there is a regression apparently from those fix (or the bug is not hidden anymore):
<didrocks> mterry: https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-release-testing/label=autopilot-nvidia/lastCompletedBuild/
<didrocks> mterry: look at the "hud" ones
<sil2100> The fix that Brandon made shouldn't cause that regression, since hm, it somehow doesn't seem related - but maybe it now leads to a stupid race condition
<didrocks> I think sil2100 has fixed unity.tests.test_hud.HudBehaviorTests.test_closes_then_focuses_window_on_mouse_down
<didrocks> right?
<didrocks> it's the one in the pipe for merging?
<sil2100> didrocks: ...most probably ;p
<sil2100> Yes ;)
<mmrazik> didrocks: done but I'm really not sure it will help. I fear that the apt-get install will fail but the process/testing will continue with the old packages
<didrocks> and also look at run 46/ https://jenkins.qa.ubuntu.com/job/ps-indicators-autopilot-release-testing/
<didrocks> mmrazik: let's see how it goes with the logs
<didrocks> so https://jenkins.qa.ubuntu.com/job/ps-indicators-autopilot-release-testing/label=autopilot-intel/lastCompletedBuild/testReport/
<didrocks> and https://jenkins.qa.ubuntu.com/job/ps-indicators-autopilot-release-testing/label=autopilot-nvidia/lastCompletedBuild/testReport/
<didrocks> there are those 8 news + the one which should be fixed by now + the _prev/_next one
<didrocks> mterry: we can have the videos of the test execution, sil2100 can maybe help you with that?
<didrocks> anyway, I'll let you organize as you prefer, I really need to go out for exercising now or I will become crazy :)
<mterry> didrocks, #46 is way better than that first link
<didrocks> mmrazik: I'll look at run #47
<didrocks> mterry: this link is only the hud and indicators tests
<didrocks> mterry: the other link is all the tests :)
<mterry> ah yes
<didrocks> mmrazik: another solution will be to add a test at start which checks the version of things that are not supposed to be upgraded
<didrocks> and abort if it fails
<didrocks> not sure if it's possible
<MCR1> didrocks: Here another minor improvement: https://code.launchpad.net/~mc-return/unity/unity.merge-reduce-scope-of-some-variables/+merge/142516
<mmrazik> didrocks: yep. would be possible. Just the whole thing starts to be a hackish bunch of scripts :-/
<didrocks> mmrazik: yeah :/
<mterry> sil2100, so of these 11 current failures I'm seeing in #46, it sounds like you fixed one?  (focuses_window_on_mouse_down)  I guess I'll look at the panel tests
<MCR1> in lp:unity/panel/PanelIndicatorEntryView line 263 we can find this:
<MCR1> gint pos = gtk_widget_path_append_type(widget_path, GTK_TYPE_MENU_BAR);
<MCR1> line 264: pos = gtk_widget_path_append_type(widget_path, GTK_TYPE_MENU_ITEM);
<MCR1> line 263 is redundant, but is line 264 the correct one ?
<MCR1> line 332, 333 the same happens...
<mterry> sil2100, I think I understand why a couple of the panel tests fail
<mterry> sil2100, the first Alt+F10 does not work
<mterry> sil2100, but subsequent ones do
<MCR1> mterry: I can confirm this observation
<mterry> I don't know enough about the codebase to offer a fix, but hopefully one of ya'll do
<sil2100> mterry: thanks for the info, good catch!
<sil2100> I'll try to fix this in a moment
<mmrazik> didrocks: ignore #47. It had a faulty preseed.
<mmrazik> just started #48
<mterry> Do we have a handle on the hud regression?
<bregma> funny, I can't repro that hud problem manually on a fully updated (from the daily PPA) raring system no matter how hard I try
<mterry> bregma, I can
<mterry> bregma, I can't, however, repro the hovering indicators panel test
<mterry> bregma, oh wait, you mean manually?  I was running the autopilot test locally and it failed
<bregma> manually, yes
<mterry> bregma, so I open an app, open the dash, then press alt?
<bregma> would that means the problem is the test and not the target software?
<mterry> bregma, I get the bfb icon even doing it manually
<bregma> oh, so you expect the dash icon to not show up in the HUD even through the dash was open when you invoked the HUD?
<mterry> bregma, that seems to be what the test is testing
<mterry> bregma, the test wants the calculator icon to appear in the HUD
<bregma> OK, understood now
<bregma> I thought that was what https://code.launchpad.net/~sil2100/unity/hud_icon_bfb_fix/+merge/141977 was supposed to fix
<bregma> looks like it didn't
<sil2100> Yes, it was fixing it before actually
<sil2100> Now it's broken again
<sil2100> I'll check in a moment what's up
<bregma> btw, does anyone have any idea why the global menus have stopped working in raring?  They come back if you manually install indicator-appmenu but that smacks of some broken packaging somewhere to me
<MCR1> didrocks, sil2100: Another one (minor performance optimization): https://code.launchpad.net/~mc-return/unity/unity.merge-remove-assignment-of-values-never-used/+merge/142527
<mterry> bregma, that sounds like I would expect.  indicator-appmenu is necessary to show the menus
<mterry> bregma, you mean, something uninstalled indicator-appmenu for you?
<bregma> it was not installed, and I didn;t notice any packages being uninstalled in my last upgrade
<bregma> even if something uninstalled it and I didn't notice (quite possible), it still sounds like broken packaging
<mterry> bregma, it could happen if you dist-upgraded before libraries were fully transitioned...
<bregma> sure, me and everyone else who is using raring, sounds fishy
<mterry> bregma, the package is on the CD
<mterry> bregma, they are working for me..
<bregma> did you do a fresh install or an upgrade?
<mterry> bregma, upgrade
<mterry> bregma, this was yesterday though.  Maybe something was temporarily broken in the past
<sil2100> bregma: the reason for that might be libbamf
<sil2100> bregma: since we switched recently from libbamf3-0 to libbamf3-1 in packaging
<bregma> maybe, and all the people who are complaining about no global menus got caught by it
<bregma> my concern is all the people who have been tracking raring:  if at least three of us have had this happen then how many non-unity-developers have had it happen?
<didrocks> bregma: do you have any kind of ppa? many are tracking staging
<didrocks> bregma: and staging don't have the rebuild of indicator-appmenu against the new bamf
<mterry> bregma, i dunno, library transitions happen all the time.  apt-get and update-manager both warn you about removing packags
<didrocks> because of the soname breakage
<mterry> didrocks, welcome back!
<didrocks> mterry: thanks! it's freezing outside :)
<didrocks> I backlogged, mterry, do you have some tests that you can work on fixing or is sil2100 over them? (at least, nice catch! ;))
<mterry> didrocks, the hovering indicators test I was trying to figure out still
<mterry> didrocks, that's the last unknown from the set of 11
<bregma> yes, apparently I have staging in my sources:  if that's the cause of the problem I'm not worried
<didrocks> that would be awesome :)
<didrocks> bregma: I'm 99.42% sure it's the cause ;)
<mmrazik> didrocks: AFAIC build #48 just didn't install anything and executed the tests :-/
<MCR1> didrocks: Could you please take a look @ https://code.launchpad.net/~mc-return/unity/unity.merge-reduce-scope-of-some-variables/+merge/142516 and https://code.launchpad.net/~mc-return/unity/unity.merge-remove-assignment-of-values-never-used/+merge/142527 - I am 99.42% sure they are correct :)
<didrocks> mmrazik: yeah, the pinning is not good
<didrocks> MCR1: sorry, if I didn't answer it's because I don't have the time for it right now ;)
<didrocks> mmrazik: I think the only way right now will be to install
<didrocks> mmrazik: and having a script parsing the log of this apt-get install
<MCR1> thaught you might have missed it, sorry 4 stressing ;)
<didrocks> MCR1: no worry ;)
<didrocks> mmrazik: and see if there is anything more than the list we gave, wdyt?
<mmrazik> didrocks: yeah... I don't see to many other options either
<didrocks> mmrazik: you do have the log right, you can abort right away, just having one test and exiting in error?
<didrocks> I don't know this UTAH thing enough
<didrocks> well UTAH/linked to jenkins
<mmrazik> me neither. It would be best to fail the installation
<mmrazik> directly in preseed
<didrocks> I think it's possible to do that in preseed
<didrocks> like redirect the apt-get install to a file
<didrocks> and then a stupid script parsing that
<didrocks> ?
<sil2100> mterry: wait, hovering indicators?
<sil2100> It's failing again?
<mterry> sil2100, did that get fixed?  I'm working off #48
<sil2100> mterry: we concluded that it was caused by the switcher fix Brandon did...
<sil2100> mterry: is the build 48 using the latest unity packages?
<sil2100> mmrazik: ^ ?
<mterry> sil2100, should be.  It looks like the latest build
<sil2100> mterry: since didrocks executed tests using the latest unity in a different jenkins job and the failure wasn't there anymore
<sil2100> https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-release-testing/label=autopilot-intel/lastCompletedBuild/testReport/
<mmrazik> sil2100: no
<sil2100> Here it was not reproducable anymore
<didrocks> mterry: oh yeah, don't look at #48
<sil2100> I think 48 is broken
<didrocks> it's our test to install only what we want :)
<didrocks> so it didn't pick anything from the ppa
<didrocks> sil2100: you can breathe! :)
 * sil2100 breathes
<sil2100> phew!
<mterry> heh, sorry
<didrocks> so, from what I understand, all the issues are on sil2100's plate?
<didrocks> for the indicators* one?
<sil2100> Yes, from the indicators side, yes
<sil2100> From ibus side as well, still didn't find the time to wrap that up
<didrocks> sil2100: it's less important right now
<mterry> yay for things being on sil2100 's plate!
<didrocks> mterry: so you can jump on the indicator-without-test-running side if you will?
<didrocks> I don't think it's a better tradeoff though :)
<mterry> didrocks, sure.   what's that side?  :)
<didrocks> mterry: the remaining components where we can't run tests under a chroot
<mterry> didrocks, ah that cyphermox was working on
<didrocks> mterry: so, from yesterday, it moved a little bit, dbusmenu tests are now running
<didrocks> yep
<didrocks> the trick was to add -a to xfvb-run
<didrocks> as we can have multiple pbuilder on the same machine
<mterry> didrocks, ah interesting
<didrocks> and so they step on each other shoes
<didrocks> I think the display is available through the bindmount or something like that
<mterry> odd, I wouldn't have guessed that
<didrocks> yeah, same for me TBHâ¦
<didrocks> but here, multiple tests and trials showed the fact
<didrocks> so, cyphermox is still doing libappindicator, and fighting on indicator-session (not sure if he needs help on that)
<didrocks> telepathy-indicator is free and needs love
<mterry> didrocks, OK, on it
<didrocks> thanks! once those are done, the whole indicator stack will be bootstrapped :)
<mterry> didrocks, thanks for review, my log of our conversation the other day about these got lost with my hard drive
 * mterry is revealed to have the complete lack of memory that he tries to hide with notes
<didrocks> mterry: well, those infos were not really important, so good :)
<didrocks> mterry: the difference is that I use physical notes!
<didrocks> mmrazik: are you doing this failure at install or do you need help?
<cyphermox> yeah I have two things I want to check on indicator-session, but if that fails I'm out of ideas
<cyphermox> as for libappindicator, need to pick things up from where they were monday, that is I got logs that should show how the environment is between the gtk2 and gtk3 tests, and we need to figure out what's causing the gtk3 tests to reproducibly fail
<cyphermox> the gtk2 tests always pass :/
<mterry> didrocks, pfft, we'll see if you survive a fire
<mterry> though...  i guess i wouldn't either
<mterry> didrocks, pfft, we'll see if you survive a strong wind!
<didrocks> mterry: like, "my disk are fire-proof now, see with you damned physical notes!"
<didrocks> good point on the wind :)
<didrocks> and yeah, already experienced
<mterry> :)
<cyphermox> ah. I trust all my notes to Ubuntu one ! :D
<didrocks> I loosed track of all my disorganized organization of my desk :)
<didrocks> cyphermox: doesn't have the paper plugin though :p
<cyphermox> sadly
<cyphermox> it's the one only thing I still need to buy for my hourse -- a fireproof safe
<didrocks> heh
<MCR1> I use the Compiz water plugin to kill any fire 8-) and the wizard plugin against wind ;)
<mterry> cyphermox, and keep your laptop in it?  :)
<mterry> who named telepathy-indicator?  it's backwards
<seb128> mterry, blame kenvandine
 * mterry shakes fist at tedg 
<mterry> whoops, I meant kenvandine
<seb128> he probably spent too much time with ted
<mterry> But my brain was like "naming problem, must be tedg"
<kenvandine> haha
<kenvandine> :-D
<mterry> Sorry tedg
<seb128> well, you can still blame ted
<MCR1> mterry:  yeah, it should be indicator-* 4 all of them (easier to find via commandline)
 * kenvandine blames tedg for everything
<mterry> seb128, where'd you come from?  :)
<mterry> you just like to chime in on naming blame  :)
<seb128> mterry, I saw an opportunity to troll tedg on naming, couldn't miss it
<seb128> sorry :p
<tedg> Hmph
<seb128> tedg, hey, happy new year! ;-)
<seb128> tedg, I hope "not naming stuff" is in your new resolutions ;-)
<tedg> Yeah, I know the year of the snake is a stupid name, I didn't do that one :-)
<seb128> hehe
<tedg> Heh, should have "not start any new projects" as one.
<tedg> We've got enough.
 * MCR1 immediately starts the wizard when hearing 'happy new year'
<mterry> didrocks, telepathy-indicator doesn't have any tests...?
<seb128> dumdumdum
<tedg> For telepathy-indicator you guys might ping larsu, as I think he was going to look at it.
<bregma> doesn't *fail* any tests either
<mterry> :)
<mterry> larsu, ^
<didrocks> mterry: oh, I don't even know, this one wasn't even looked at :)
<mterry> didrocks, ah well.  all its tests pass man!
<didrocks> mterry: hem hem :p
<larsu> mterry, I'm fixing a couple of issues in it, I didn't plan on adding tests (but I guess I could since it turns out I'm making quite some changes)
<larsu> I wonder if there's a good way already to test telepathy components
<mterry> larsu, we love tests to pieces
<sil2100> brb
<larsu> so I hear :)
<tedg> larsu, Seems like there should be a dummy telepathy plugin.
<larsu> tedg, yeah, probably. I'll have a look once I get to it
<didrocks> mterry: so at least, prepping the package inline if not already done meanwhile :)
<mterry> cyphermox, let me see those build logs for gtk2/gtk3.  maybe I'll catch something
<mterry> didrocks, guh you're right, it's not inline
<cyphermox> mterry: I have a branch for inlineing telepathy-indicator
<mterry> cyphermox, oh nice
<mterry> good thing I didn't start that immediately
<cyphermox> yeah
<cyphermox> didrocks: you had already reviewed it too:
<mterry> :)
<cyphermox> mterry: https://launchpadlibrarian.net/127835347/buildlog_ubuntu-raring-i386.libappindicator_12.10.9-0ubuntu1~mtrudel1_FAILEDTOBUILD.txt.gz logs for gtk2 vs. gtk3
<mterry> didrocks, btw, I finally set up vpn
<cyphermox> didrocks: mterry: https://code.launchpad.net/~mathieu-tl/telepathy-indicator/inline/+merge/137366
<mterry> cyphermox, is there a libappindicator branch that enables tests?
<cyphermox> mterry:
<cyphermox> https://code.launchpad.net/~mathieu-tl/libappindicator/fix-tests
<mterry> cyphermox, awesome.  I'll play with it and see if I notice anything
<cyphermox> mterry: thanks
<alesage> perhaps I should set up a Jenkins job for telepathy-indicator
<alesage> if no-ones aware of one existing :)
<cyphermox> right
<didrocks> mterry: sweet on vpn \o/ (sorry still on a hangout)
<MCR1> Trevinho, thanks 4 approval ;)
<Trevinho> MCR1: yw ;)
<mterry> cyphermox, so the libappindicator seems to be because of the warnings themselves spit out by at-spi2 (vs at-spi1 for gtk2).  Any stderr output fails the test.
<mterry> cyphermox, I'm not sure whether it's better to try to make at-spi2 happier or allow stderr output
<cyphermox> just that, seriously?
<cyphermox> thing is, seems to me like both should complain equally if the issue is that it's missing a display
<mterry> cyphermox, I added a simple g_warning to one of the tests and it failed it
<cyphermox> both should have a display set ;)
<cyphermox> right
<cyphermox> well, it makes sense
<mterry> cyphermox, yeah, but different at-spi implementations
<cyphermox> I was trying to make at-spi happy really by figuring out why it can't see it has a display
<cyphermox> but I didn't have much luck
<mterry> hm
<mterry> then maybe easier to allow stderr  :)
<cyphermox> in theory the tests are supposed to be run in xfvb already
<mterry> I think these tests all use g_assert to fail the things they care about
<mterry> agreed
<cyphermox> or gtester / dummy X
<mterry> I tried switching to xvfb-run, but that didn't help
<cyphermox> but yeah, can we have the tests ignore stderr?
<mterry> Or maybe we could turn off at-spi all together?
<mterry> I don't know how to ignore stderr yet, but that might be easier
<cyphermox> I don't know how to do either ;)
<cyphermox> seems very wrong to have stderr fail for these tests though; because there are so many dependencies and many we don't care so much about
<mterry> That's a part of gtest I believe (not gtester)
<mterry> yeah, seems not-robust since these tests use asserts to test the interesting bits
<cyphermox> it adds unnecessary complexity and uncertainty to the tests if they depend on all the external deps to be properly configured enough to be happy and not spew to stderr
<cyphermox> aye
<cyphermox> and that's what tests should do -- depend on nothing at all, or the least possible, and assert whatever needs assertin'
<cyphermox> but heh
<mterry> well, I'll look into making gtest happy
<mterry> with stderr
<noclue> hello
<mterry> cyphermox, oh btw: http://paste.ubuntu.com/1513984/
<mterry> cyphermox, sorry for delay.  Had unrelated pbuilder problems and then I forgot  ;)
<mterry> cyphermox, it seems to work for me
<cyphermox> weee
<cyphermox> nice
<mterry> Although... Actually I might have only tested a subset of the tests
<mterry> well
<cyphermox> anyway, np; I was trying to make sense of the NM patches, seeing which ones could be dropped or sent upstream, before I start to mess with the proxy stuff
<mterry> If you see other tests failing that I forgot to uncomment before submitting to you, just use the same trick
<cyphermox> mterry: got a branch now
<cyphermox> ?
<cyphermox> or do you mean I should apply this patch?
<mterry> cyphermox: I was thinking just the patch
<cyphermox> ok
 * mterry is lazy, though I realize it was probably more work to make the patch
<cyphermox> bah, I'll just add it to my branch and push it
<cyphermox> (or anyway, submit a MP)
<cyphermox> mterry: were you trying in a ppa or locally?
<cyphermox> IIRC it was only really failing in ppa
 * cyphermox is trying now
<mterry> I saw it failing in a chroot.  And I just retested my patch and it fails again in a chroot.   :(
<mterry> Gosh darn it
<cyphermox> holy crap, there's still so much delay in getting ppa builds :(
<cyphermox> I hate this, it's so annoying
<cyphermox> I really need to setup a good PPA-like rig on my server to run no-web-access-no-nothing builds that get all the dependencies
<cyphermox> mterry: I tried to setup soyuz on a container a few times but it takes too long, I never have time to finish and then I get lost in the steps :P
<cyphermox> I think I'll hire my friend and give him acces to my server to get this done
<mterry> :)
<mterry> Well, for now assume my patch is bad.  :(  I'll work more on it
<cyphermox> ack
<cyphermox> mterry: that's usually the problem though, things work in sbuild and pbuilder, but fail when it gets to the ppa
<cyphermox> it seems to be due to some little parts of the environment are available when you run things in sbuild or pbuilder, because they are running on your system
<cyphermox> I ran things on my server too, and things tend to work there as well, but it *does* have a little more than just ubuntu-minimal or whatever is on a soyuz chroot
<mterry> cyphermox, that's fair, but this was actually me not testing well enough in my own darn chroot  ;)
<cyphermox> mterry: fair enough ;)
<cyphermox> it seemed fishy anyway
<cyphermox> the two tests that fail seem to be only set-menu and set_label or whatever
<mterry> It got me further.  I think this is roughly the right path...  Maybe
<cyphermox> it seems the right path yeah
<mterry> Now I have to figure out why it was working sort of before
<cyphermox> even for indicator-session locally, the test usually works, but sometimes it times out
<cyphermox> mterry: feels kind of like this: https://www.youtube.com/watch?v=yjpd9D4Kc4Q
<mterry> :)
<highvoltage> hi!
<highvoltage> in edubuntu we want to set 2 dconf values in org.compiz.profiles.unity.plugins.unityshell
<highvoltage> but the schema for that doesn't exist by default so we can't override it
<highvoltage> is that a bug or are we doing it wrong?
#ubuntu-unity 2013-01-10
<Mirv> highvoltage: the schema is org.compiz.unityshell, but it is relocatable (to various profiles). I still don't eat gsettings for breakfast so not immediately sure how the unity profile default should be overridden
<Mirv> I guess one could try just [org.compiz.unityshell] in an .override file
<hyperair> check out the dh_installgsettings manpage.
<didrocks> mmrazik: any idea why latest ps-unity-autopilot-release-testing failed?
 * mmrazik is looking
<didrocks> sil2100: hey, quick approval: https://code.launchpad.net/~didrocks/nux/common-any/+merge/142647 ?
<mmrazik> didrocks: there is _usr_bin_compiz.1000.crash in /var/crash
<mmrazik> so I guess a compiz crash
<didrocks> mmrazik: during the install?
<mmrazik> going to look via kcm
<didrocks> ok :)
<mmrazik> didrocks: install seems to be completed
<didrocks> it doesn't seem it even launched one test, right?
<didrocks> and having that on all configs, I wonder what's happening
<mmrazik> correct. The test started but the "check unity is on" failed
<mmrazik> didrocks:  this is the AP log: http://pastebin.ubuntu.com/1516238/
<didrocks> mmrazik: let me upgrade from the ppa
<mmrazik> usually it says something like "Starting test ..."
<didrocks> ok
<didrocks> let me upgrade and starts a guest session, one sec
<didrocks> mmrazik: ok, I confirm, unity trunk is broken
<didrocks> sil2100: popey: Mirv: can any of you confirm this?
<didrocks> I think we'll have to look for the guilty commit :/
<didrocks> mmrazik: meanwhile, can you try to do what we discussed yesterday for detecting when we install more than what we should? do you need help for that?
<mmrazik> didrocks: well.. Help would be appreciated. I won't be able to have a look on it this morning. Ideally it would be best to do the testing in the preseed and quit the installation right away. I just don't know if there is a way from the preseed to kill the install in  a way UTAH will notice the whole thing terribly failed
<didrocks> mmrazik: can you just try right now to exit 1 in the late_command?
<didrocks> mmrazik: just to ensure it aborts the install
<didrocks> at least, I will be able to build on that then :)
<didrocks> mmrazik: doing that will be really helpful
<didrocks> mmrazik: you can use the indicator test if needed for it
<mmrazik> didrocks: ok
<popey> hmm
<popey> didrocks: confirmed
<Mirv> hmm, I don't have those in use
<Mirv> ok, seems confirmed enough
<popey> i get a compiz crash
<sil2100> Trying
<sil2100> Since currently I have some unity problems here in overall
<didrocks> urgh, a local build is workingâ¦
<sil2100> I confirm, unity from staging seems broken
<didrocks> sil2100: you are using staging or daily?
<sil2100> didrocks: this time I used staging to get the latest unity trunk
 * popey is on daily, not staging
<sil2100> But I see anyway unity didn't have any new risky commits, hm
<didrocks> I don't understand, local build with latest unity -> working
<sil2100> hm, I see that on my guest session, compiz decied that my system needs to use software rendering
<didrocks> I don't see anything in nux leading to an ABI break
<didrocks> duflu: anything in compiz leading to an ABI break?
<sil2100> Not sure if this was related, but unity started working after I installed compiz from staging
<didrocks> the opengl thingy?
<sil2100> So this smells like ABI breakage to me?
<didrocks> yep
<sil2100> THe recent compiz commit seems risky indeed
<didrocks> let me first rebuild unity in the daily build ppa
<duflu> didrocks: No core ABI breaks. OpenGL ABI changed yesterday but that code is unused by Unity or any plugin outside of opengl itself
<sil2100> Since the opengl plugin ABI got bumped
<duflu> So was not really an ABI bump
<didrocks> duflu: yeah, I saw you told that on the merge
<didrocks> duflu: however, right now, unity is crashing at startup, the 2 nux commits seem fine
<didrocks> duflu: and rebuilding locally with latest stack is working
<didrocks> let me try to rebuild it in the ppa
<duflu> didrocks: Hmm, let me see if Unity might use the modified class indirectly by another class
<sil2100> Latest unity works with latest compiz in staging
<didrocks> duflu: this can be some kind of this tricky case
<didrocks> duflu: seb128 confirms that only installing the new compiz since yesterday is breaking unity
<didrocks> so yeah, it's using it indirectly
<duflu> didrocks: Nope the modified class is only used privately inside compiz opengl plugin. That won't be the problem
<didrocks> well, it seems that empirical tests prooves that there is some kind of breakage for unity in some way :)
<didrocks> popey: sil2100: unity rebuild launched, I hope that we can have autopilot test results afterwards
<duflu> didrocks: Only the size/layout of PrivateGLScreen could have changed. Nothing else
<didrocks> duflu: maybe it's used in some way by unity, indirectly? or nux?
<didrocks> I doubt on nux though, it doesn't bring compiz pieces IIRC
<duflu> didrocks: No it's properly private to compiz AFAICT
<didrocks> duflu: well, something is guilty for sure in the recent compiz changes, as the tests seb128 did show
<sil2100> didrocks:
<didrocks> taking yesterday ppa state
<sil2100> \o/
<didrocks> updating   compiz compiz-core compiz-dev compiz-gnome compiz-plugins-default
<didrocks>   libcompizconfig0 libcompizconfig0-dev libdecoration0 libdecoration0-de
<didrocks> and you have the issue
<sil2100> Well, I doubt nux as well, since I didn't install new nux packages
<didrocks> sil2100: during the rebuild, two things, not sure if you saw my nux MP above to change -common from arch: all to arch: any?
<duflu> didrocks: OK, but what revision was working last?
<didrocks> sil2100: second one, I saw that brandon has committed a fix for the 8 new tests failing, what's still on the map?
<sil2100> didrocks: yes, but Alan was faster with approving ;)
<didrocks> oh? he stole karma!!! :)
<seb128> duflu, the issue is in that diff probably: https://launchpadlibrarian.net/128073372/compiz_1%3A0.9.9~daily13.01.09-0ubuntu1_1%3A0.9.9~daily13.01.10-0ubuntu1.diff.gz
<didrocks> duflu: didn't do a bisect, but I can give you with what version it was built against yesterday
<seb128> didrocks, ^
<seb128> duflu, that's the diff between the daily snapshots yesterday (which was working) and today
<duflu> didrocks: Yeah I just reviewed all those :P
<didrocks> duflu: so, between rev 3549 and 3552
<sil2100> didrocks: if our predictions are correct, with Brandon's fix and all the others, we should have no failing tests for the indicators
<duflu> didrocks: OK, looks like   if (!CompPlugin::checkPluginABI("opengl", COMPIZ_OPENGL_ABI))
<sil2100> At least that's the expectation we would wish to confirm :D
<didrocks> sil2100: \o/ let's trust the mayas then!
<duflu> The ABI was not broken, but incrementing the macro prematurely broke Unity :(
<sil2100> Damn you ABI versions
<didrocks> duflu: this is in unity?
<didrocks> this check?
<duflu> didrocks: Yes in unityshell. Looks like the problem
<duflu> I thought ABIs were compared >= but they're compared with ==
<duflu> didrocks: So either rebuild Unity or revert the COMPIZ_OPENGL_ABI increment. The increment was wrong
<didrocks> duflu: argh, the virtual package is juste creating on the core abi version
<duflu> didrocks: I know. Different library, different ABI :P
<didrocks> duflu: as you wish, maybe reverting the increment?
<duflu> didrocks: I will push it back to 6 right now if you like. Need review?
<didrocks> duflu: no, please autoapprove :)
<didrocks> thanks for digging into it
<duflu> didrocks: It's the only explanation. Not proven yet though
<didrocks> duflu: I feel you're right, if you are sure the changed struct is not leaked
<duflu> didrocks: Pushed to lp:compiz in a quick and evil way.
<didrocks> duflu: evil is fine sometimes :)
<didrocks> it's another argument to autobump the build-dep version as part of the daily process
<didrocks> I really wonder, nobody answered on that on the unity-dev ML
<didrocks> but I feel we'll have to
<duflu> didrocks: Technically it is behaving correctly. Checks the opengl plugin for compatibility and bails if it's not reporting itself as compatible
<duflu> But incompatible is bad. Quite bad
<didrocks> duflu: yeah, I guess if this kind of breakage (justified or not) without bump build-dep is happening too much, the only way will be this autobumping build-dep on all components parts of the stack
<didrocks> duflu: it's technically incorrect, but practicallyâ¦
<duflu> didrocks: I think ted was partially right. Downstream projects like Unity should not be getting new code while that new code still needs to change so often. But your argument for daily builds is at least as strong
<duflu> I would like to call the ABI "0.9.9" when 0.9.9.0 is released and declare it fixed then
<didrocks> duflu: well, after 3 years, seeing that the code still needs to change so often means that something is not working properly :)
<didrocks> I agree on young-incubating project that this doesn't work
<duflu> didrocks: Yes there are bugs because it's a massive codebase and almost no developers :(
<didrocks> but after a public official release, it should be good
<didrocks> yep
<duflu> But it's an order of magnitude fewer new bugs each week than a year ago. So lots is "working properly"
<didrocks> so we should ought to expect trunk to always work, and new incubating things in a separate "per feature" branch
<didrocks> and once properly cooked, merged into trunk
<sil2100> It's anyway much better than before
<sil2100> Since we're able to use staging/daily normally for a longer time, without any big breakages
<didrocks> sil2100: oh, not related but the prev/next issues are fixed? I didn't see a merge for this
<didrocks> as you couldn't figure out why it was still broken yesterday
<duflu> didrocks: There was nothing I could have done to avoid this. The failing function is one I had never looked at before (like 90% of compiz)
<duflu> Failures happen and we fix them
<didrocks> duflu: yeah, but we can mitigate this can of failure by forcing everytime building against latest build-dep
<didrocks> even if it's unecessary
<didrocks> and I can automate that
<didrocks> s/can/kind/
<didrocks> I just need people thought on this to know if they think it's a good idea or not :)
<didrocks> and what the eventual drawbacks that I missed out (I can only see for backports, that we don't support, at least, when the stack is partial)
<duflu> didrocks: So when do you stop forcing it? Release candidates?
<didrocks> duflu: even not
<didrocks> well, SRUs maybe
<didrocks> but otherwise, as we copy from the daily build ppa to the archive
<duflu> didrocks: It certainly has to freeze by release. You need a fixed ABI then :)
<didrocks> duflu: well, it's not a card for "break ABI whenever you want" :)
<didrocks> it's just a technical solution to avoid getting those issues revealed
<MCR> Am I the only one suffering from a broken raring desktop since yesterday night ?
<didrocks> MCR: using staging?
<MCR> yep
<didrocks> MCR: backlog the discussion ^
<didrocks> MCR: and so it's not raring being broken, it's the ppa :)
<MCR> I was not sure what exactly caused it yet
<MCR> Will it be fixed soon ?
<duflu> Heh. And I only stopped using the PPA yesterday (just reinstalled raring)
<didrocks> MCR: just a rebuild of unity is fixing it
<didrocks> or revert to a previous compiz version from the ppa :)
<duflu> didrocks: Since I hacked compiz you only need to rebuild that really
<MCR> (I am on Mint 9 [my failsafe sys] and I want back ;))
<didrocks> MCR: well, revert or rebuild compiz :)
<duflu> didrocks: Yeah I will have to increment Unity's build-deps even if plugin ABIs change in future
<MCR> No PPA fix ?
<duflu> That's a new one
<didrocks> MCR: maybe, but once we'll get a new merge in process, not sure when it happens
<MCR> ok, thx
<didrocks> MCR: as outlined in the ppa description, it's not supported and ensure to work everytime :)
<MCR> yeah, I am not blaming anyone
<MCR> I just was not sure if it was known already
<didrocks> MCR: when unity will be delivered everyday to raring, you won't need the ppa anymore :)
<MCR> :)
<sil2100> didrocks: well, hm, ok, got confused right now
<didrocks> hum?
<mmrazik> didrocks: so exit 1 in preseed does seem to exit the installation. But now utah waits for it to finish (trying to ssh) and it will take some time to timeout
<sil2100> Let me re-check something then
<didrocks> mmrazik: ok, I have another idea, can you just copy the list of additional package to install and we do that as the first test which can aborts, like the one you have to detect unity?
<didrocks> mmrazik: so I'll give you a script to install those eventual new packages, I just need that store the list of packages somewhere in the installed system
<mmrazik> didrocks: sure but its exactly that sort of hacking I was trying to avoid
<didrocks> mmrazik: well, it seems we don't have better solution right now
<didrocks> and no time for refactoring all this preseed stuff
<mmrazik> didrocks: ok
<sil2100> didrocks: since as you know, there was a lot of confusion yesterday on which tests are up-to-date and which not
<didrocks> sil2100: ah, I think those were still valid
<didrocks> sil2100: can you verify?
<didrocks> mmrazik: just tell me where you put this list of package (if empty, nothing else to install), I'll then propose a MP to your branch
<MCR> sil2100: The manual tests are also heavily outdated, one refers to the update-manager and its windows, which have completely changed for example
<sil2100> didrocks: since, for instance, in http://10.97.0.1:8080/job/ps-unity-autopilot-release-testing/23/#showFailuresLink (which was ran on a newer unity) didn't have prev/next failing
<mmrazik> didrocks: lets put it in into /home/jenkins/install_packages (--install-packages is the switch in the customize preseed command)
<sil2100> MCR: hm, yes, I think we'd need to remove those in overall
<didrocks> sil2100: ok, let's see with the new build then
<mmrazik> didrocks: or no...give me a sec
<didrocks> mmrazik: that's the list of package I have to install, right?
<mmrazik> didrocks: I'll put the following for indicators there: "bamfdaemon indicator-datetime indicator-messages indicator-application libindicator7 indicator-sound libmessaging-menu0 appmenu-gtk indicator-printers indicator-power appmenu-qt appmenu-gtk3 gir1.2-messagingmenu-1.0 indicator-appmenu libindicator3-7 libbamf3-1 libsync-menu1 indicator-applet-complete libido3-0.1-0 gir1.2-syncmenu-0.1 "
<mmrazik> which is the jenkins parameter
<didrocks> yep :)
<mmrazik> didrocks: and yep, I'll put it into /home/jenkins/install_packages
<sil2100> Unity as well! Add unity ;)
<MCR> sil2100: I wanted to revisit them, run them, report eventual bugs and update them - but for some (like the one I mentioned above) finding replacement tests is not easy...
<didrocks> mmrazik: oh, but the user don't have sudo right, isn't it?
<sil2100> MCR: I think what we need to do is browse through the manual tests and check what tests are already as autopilot tests and those that are not, but are still valid, simply turning into AP
<mmrazik> didrocks: If you need it I can add it to sudoers in preseed
<didrocks> mmrazik: or what we can do is create those two files
<sil2100> MCR: since we decided we don't want any manual-tests anymore
<sil2100> MCR: the idea is to have everything automated
<didrocks> mmrazik: like: /home/jenkins/install_packages and /home/jenkins/installed_packages
<didrocks> /home/jenkins/installed_packages beeing the output of apt-get install during the preseed
<MCR> sil2100: Yes, gotta look @ autopilot, but I am not sure if all things can be automated...
<didrocks> mmrazik: then, the script will only test the logic of this
<didrocks> mmrazik: and exit if something is wrong
<didrocks> wdyt?
<mmrazik> didrocks: ok
<MCR> sil2100: So no more nice-testhouse ?
<sil2100> MCR: autopilot is really nice, and indeed - visual changes can't really be testable by autopilot, but those we anyway don't really test
<sil2100> MCR: I think testing is still needed - remember that we're not completely automated for precise and quantal ;)
<mmrazik> didrocks: did you already branch the ~autopilot/unity/utah-jenkins branch?
<sil2100> And, checkbox-tests, which check overall system integration, are still manual
<mmrazik> if so, can you please discard and branch again? Not proud what I just did there but I changed it.
<MCR> sil2100: I seem to be the master in finding and being affected by Unity bugs noone else is suffering from :P
<didrocks> mmrazik: not yet, just creating the parsing script right now
<didrocks> mmrazik: ok, will do :)
<sil2100> MCR: ;p
<mmrazik> didrocks: can I kill ps-unity-autopilot-release-testing?
<mmrazik> or is it actually something you need?
<didrocks> mmrazik: it's needed
<mmrazik> ok
<didrocks> mmrazik: that's what was prevented by the ABI break before
<mmrazik> didrocks: I think the files should be there. The net (queued) indicators job will confirm
<mmrazik> s/net/next/
<didrocks> mmrazik: sweet! did you cat them?
<didrocks> so that we can see we have the expected content, for debugging :)
<mmrazik> didrocks: http://pastebin.ubuntu.com/1516437/
<mmrazik> "unity indicator hud" are just 3 random packages (which don't even exist)
<didrocks> mmrazik: right, I just mean cat the /home/jenkins/installed_packages for the first weeks
<didrocks> mmrazik: so that if my script don't have the proper content, we can debug it
<didrocks> or I can do it in my scripts I guess
<mmrazik> didrocks: cating wouldn't help -- utah is not stdout friendly :-/ need to store them as jenkins artifacts.
<didrocks> ah :/
<didrocks> ok
<mmrazik> didrocks: lets store them in /home/jenkins/results/artifacts
<didrocks> mmrazik: remember they are optional though
<didrocks> mmrazik: like with the "whole ppa" preseed, they are not here
<mmrazik> didrocks: after the job ends we are scp-ing the whole results dir and storing it as artifacts
<didrocks> ok, it's not file by file then
<mmrazik> didrocks: nope
<mhr3> mmrazik|lunch, could you look at why https://code.launchpad.net/~mhr3/libunity/fix-nested-previews/+merge/142538 keeps failing please?
<mhr3> stuck xvfb or something?
<didrocks> mmrazik|lunch: rev 170 and 171. Can you give it a look and if good, will worth testing that it indeed aborts the tests :)
<solancer> hey guys
<solancer> I want to hack on unity on my local system
<solancer> i have a launchapd Id and all
<solancer> I have cloned the unity repository and have been going through the doccs
<solancer> can someone explain what upstream merge means >
<mmrazik> mhr3: we had this recently with libdbusmenu. xvfb-run is trying to run the X on a specified display :99. If you are building on amd64 and i386 on the same machine then only one of the instances will work and the other fail to start
<mmrazik> mhr3: the solution is to run "xvfb-run -a"
<mmrazik> solancer: it IMHO means merging your changes back to lp:unity (but I'm lacking some context)
<solancer> mmrazik, oh I see
<mhr3> mmrazik, didn't know the merger is so awesome now that it can run both 32 and 64bit builds at the same time
<mhr3> anyway thanks
<solancer> mmrazik, so I have two repos cloned from launchpad with me
<solancer> mmrazik, unity and unity revamped
<mmrazik> mhr3: its there for months
<solancer> mmrazik, if I make changes to the unity repo and push it to my personal PPA
<solancer> mmrazik,and if unity has a new version release
<solancer> mmrazik, would have to do something extra to keep up with the releases >
<mhr3> mmrazik, then the machine got faster or something :)
<mmrazik> solancer: yes. You would need to merge the upstream (lp:unity) back to your own branch
<mmrazik> solancer: usually something like bzr merge lp:unity in your working dir
<solancer> mmrazik, cool
<mmrazik> didrocks: the changes look sane. I would prefer not to modify the other preseed files but it shouldn't hurt either
<solancer> mmrazik, and 1 more question
<mmrazik> (i.e. only base-preseed needs to be modified)
<didrocks> mmrazik: just for consistency as we run it and it will exit with 0
<mmrazik> solancer: sure. Shoot.
<didrocks> but as you prefer :)
<didrocks> mmrazik: will this be picked automatically in the indicator run?
<mmrazik> didrocks: its already there... lets keep it
<didrocks> ok
<solancer> mmrazik, the cloned repo's name is unity and mine is unity-dodge
<mmrazik> didrocks: not sure. let me kill it and start again
<didrocks> mmrazik: ok :)
<didrocks> sil2100: one hud test fail remaining! just one! :)
<sil2100> !
<sil2100> didrocks: which one? ;)
<didrocks> sil2100: seems we have the same with the dash
<didrocks>  unity.tests.test_hud.HudBehaviorTests.test_closes_then_focuses_window_on_mouse_down
<didrocks> unity.tests.test_dash.DashRevealTests.test_closes_then_focuses_window_on_mouse_down  is failing as well
<didrocks> I bet same cause
<solancer> mmrazik, shou ld I change the name of the cloned repo or I can jus start making changes to it and push it to my PPA
<sil2100> Ok, let me see that then!
<mmrazik> solancer: you have the repo on your HDD? It doesn't really matter what is the name.
<didrocks> sil2100: look at jenkins directly
<didrocks> sil2100: the public instance is broken
<solancer> mmrazik, yep I have it on my HDD
<didrocks> job/ps-unity-autopilot-release-testing/label=autopilot-nvidia/lastCompletedBuild/testReport/
<mmrazik> solancer: I would also sugest to push the repo somewhere to launchpad so you have a backup... not sure what is your launchpad ID but something like bzr push lp:~solancer/unity/my-branch-name
<mmrazik> solancer: but you don't have to do it
<didrocks> sil2100: same failure on intel at least
<mmrazik> solancer: so nothing needed. You can start make changes and then dput into a ppa
<solancer> mmrazik, cool i'll start hacking then
<didrocks> few minutes for ATI :)
<didrocks> sil2100: and ati as well, so reproduceable everywhere :)
<didrocks> mmrazik: ok, the build failed, which artefact did you use to see that it didn't run?
<mmrazik> didrocks: mhm... there is some utah stack trace in the job output. The files were apparently not copied back to jenkins
<mmrazik> didrocks: so no artifacts :-/
<mmrazik> looks like some utf issue
<didrocks> mmrazik: so, this time, it failed due to UTAH?
<mmrazik> but I wonder where
<mmrazik> didrocks: the stacktrace comes from this command:
<mmrazik> utah --install-type desktop -r /tmp/master.run
<didrocks> mmrazik: same for nvidia btw
<didrocks> nvidia/intel
<didrocks> mmrazik: are you tracking it? I'm not sure to know enough about UTAH and the guys behind it
<mmrazik> didrocks: me neither. But trying to look into source code
<didrocks> the stack is only in the logging module :/
<mmrazik> yeah... just realized that
<sil2100> hm hm
<didrocks> mmrazik: any progress? talked on #qa? (not there, so didn't see)
<mmrazik> I tried to export a locale and re-run the test
<mmrazik> didrocks: I tried to reproduce by running the utah command on the host but didn't observe the stack trace
<didrocks> mmrazik: should we just retry?
<didrocks> weird that it failed on the 3 configs though
<mmrazik> didrocks: yes. The job is already running.
<didrocks> ok
<mmrazik> didrocks: with export LANG=en_US.utf8
<didrocks> ok, let's see ;)
<mmrazik> its just a wild guess
<sil2100> So, what I noticed
<sil2100> hm, autopilot in the jenkins unity tests uses a strange keybinding for maximizing the window - it seems invalid
<sil2100> Since in compiz we're patching through patches it to Ctrl+Super+Up, while it's using the old compiz one Super+Up
<sil2100> And it seems not to maximize the window then
<sil2100> That's why those 2 tests fail - now I need to find out why he has the keybinding set to Super+Up and why then it doesn't work
<didrocks> sil2100: good catch! :)
<didrocks> sil2100: 10_ubuntu-settings.gschema.override:maximize = ['<Super>Up','<Primary><Super>Up','<Primary><Alt>KP_5']
<didrocks> sil2100: I think it's the bug that smspillaz knows about
<didrocks> he has a fix I guess, but don't want to push it without tests and no motivation to write the tests
<sil2100> didrocks: what's the problem here? So it's a real regression then?
<didrocks> sil2100: well, only on this machine, and some others, the "integrated settings" are not overwritting the integrated key on first launch
<didrocks> I think I'll just update to only have '<Primary><Super>Up' by default
<didrocks> a pity, but wellâ¦
 * sil2100 sighs
<sil2100> Ok
<didrocks> sil2100: don't we have the same issue we show desktop btw?
<didrocks> sil2100: do you know some tests using it and failing?
<sil2100> hm, let me see, maybe indeed we're also getting hit by that - usually switcher tests are usign show desktop
<didrocks> sil2100: ok, I've uploaded ubuntu-settings in the ppa, once built, I'll relaunch the tests
<didrocks> mmrazik: how to interpret the nvidia autopilot indicator result?
<mmrazik> didrocks: its the same stack trace, isn't it?
<mmrazik> didrocks: build #55?
<sil2100> didrocks: thanks!
 * sil2100 goes for lunch
<didrocks> mmrazik: there are some artefacts, isn't it?
<mmrazik> oh.. right
<didrocks> so not sure if it's exactly the same issue
<didrocks> was my script launched already?
<didrocks> not sure where to see the logs :)
<mmrazik> didrocks: your script has wrong paths. I moved the files into /home/jenkins/results/artifacts
<didrocks> mmrazik: ah, you didn't tell me :) but is the crash before it's launched or the utf8 issue is because of the script itself?
<mmrazik> didrocks: I _think_ your script was not started
<mmrazik> argh.. this preseed stuff debugging is a nightmare
<ritz> anyone good with unity-2d ? wrt https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1096954
<ubot5> Launchpad bug 1096954 in unity (Ubuntu Precise) " Enabling Xinerama causes Unity Panel/Dash to become all black" [Medium,Confirmed]
<didrocks> mmrazik: do you think it's due to the preseed? it's weird that we can reliably crash it now
<mmrazik> didrocks: I don't know but the stacktrace in logs is something I'm worried mostly about
<mmrazik> as it might very well mean the whole utah testcase just wasn't started
<didrocks> yeah
<mmrazik> giving up. asking on #qa
 * didrocks joins
<didrocks> sil2100: latest result, job ps-indicators-autopilot-release-testing, rev 57
<didrocks> sil2100: still prev/next failing
<didrocks> (both on nvidia, only prev on ati/intel)
<didrocks> mterry: FYI ^
<mterry> :-/
<mterry> I haven't read code branches today.  Does that the tested code include a fix for the alt+f10 problem?
<didrocks> mterry: I didn't see it flying
<didrocks> but maybe I missed it, with all the autopilot issues todayâ¦
<mterry> OK, good.  So we may have a path towards completion!  :)
<didrocks> hoping so :)
<didrocks> mterry: you're looking after it? maybe check with sil2100 and brandon
<mterry> k
<didrocks> thanks! :)
<didrocks> mterry: FYI, that's the latest blocker before enabling the daily release for unity \o/
<didrocks> I would love to have the first daily release tomorrow :)
<didrocks> Friday, what can happen? :)
<mterry> heh
<didrocks> mterry: also, sorry to jump on you so early, but did you get anything on the indicator test during build? trying to gather some info as I won't be really available next week :)
<mterry> libappindicator?
<didrocks> right, and indicator-session
<didrocks> IIRC
<mterry> No, I thought I had a promising fix, and it might have fixed part of it, but it wasn't enough.  Still investigating
<didrocks> ok ;)
<mterry> cyphermox, I thought you had indicator-session well understood?  Or a possible fix or something?
<cyphermox> I tried something, it failed
<cyphermox> indicator-session is borken as much as libappindicator -- the test reproducibly fails in a PPA no matter what I change
<cyphermox> I think it's due to some dependency missing in the build -- and then it should probably be explicitly listed in the binary package deps.
<cyphermox> (once we find out what the hell it is)
<seb128> what test is that in indicator-session?
<cyphermox> TestCanStartService
<cyphermox> the one you hacked to use LD_PRELOAD
<cyphermox> incidently, didn't that work?
<didrocks> I think it's the test using the system bus, isn't it?
<seb128> that test can't work
<seb128> drop it
<didrocks> I told you about it :)
<cyphermox> gladly
<seb128> it requires consolekit in a working state
<seb128> and accountsservice
<seb128> and other stuff from the system
<seb128> that can't work in the current form
<cyphermox> if that's all that's needed I can move it to a autopkgtest
<didrocks> however, autopkgtest would be good
<didrocks> cyphermox: I think it should, jibel should be able to confirm ^
<cyphermox> zug zug; that will just take 5 minutes, I got most of the code ready
<cyphermox> I get some issues running autopkgtest locally though, it tends to hang
<cyphermox> it would be useful if we could run this in the right environment soonish to make sure it's good
<mterry> zug zug?  :)
<cyphermox> mterry: warcraft peons?
<didrocks> cyphermox: sure that jibel has all the knowledge you need for that :)
<cyphermox> yup :)
<mterry> heh
<didrocks> knowing him, there is maybe even a wiki page!
<cyphermox> jibel: ^^ is there a wiki page on how to run autopkgtest locally? I know how to do it, but I want to know if I should write the howto on the iwki ;)
<jibel> I stopped writing wiki pages, people first ask questions on IRC instead of reading them
<cyphermox> hehehe
<jibel> but there is documentation http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/view/head:/doc/USAGE.md
<cyphermox> ah, that's even closer to jenkins than my adt-run --blah blah --- adt-virt-schroot
<cyphermox> jibel: thanks!@
<jibel> cyphermox, yw
<highvoltage> Mirv, hyperair: ok, will try that. thanks
<highvoltage> hyperair: well actually I use that but since the schema isn't there yet it doesn't work, will check if the manpage has some additional information for that case
<hyperair> hm.
<hyperair> just depend on the package with the schema?
<highvoltage> hyperair: I couldn't find a unity package that provides it. I was wondering if I could just do it.
<highvoltage> hyperair: unless perhaps there's another way I could set the launcher opacity and colour (perhaps I'm just doing it wrong)
<hyperair> no, a gsettings override is probably the right way to do it.
<highvoltage> hyperair: so far it responds to org.compiz.profiles.unity.plugins.unityshell launcher-opacity and background-color, but it's kind of strange that it's not there by default, isn't it?
<hyperair> grep the /usr/share/glib-2.0/schemas folder for the key/schema you're looking for
<highvoltage> hyperair: it's not there
<hyperair> uh hmm.
<hyperair> i see it in org.compiz.unityshell.gschema.xml:
<hyperair> so you could try overriding that
<mterry> sil2100, poke about alt+f10 when you are available
<sil2100> mterry: hi!
<sil2100> didrocks: hm
 * didrocks sees that sil2100 has the didrocks ignore filtering!!!
<mterry> sil2100, hello!  I still haven't caught up on merge mails.  Did you ever get anywhere with the alt-f10 bug?
<sil2100> mterry: I started looking, but I'm not able to reproduce it right now
<highvoltage> hyperair: ah interesting, in a newer 13.04 image it's there, I'll go check what happened there, thanks a lot!
<bregma> hey folks, can anyone tell me if there's an up-to-date place to look for Unity test coverage analysis (gprof, etc)?
<hyperair> :)
<sil2100> didrocks: it's not like that! I was simply still lunching, that's why!
<didrocks> sil2100: yeah yeah :'(
<mterry> sil2100, is there a way I can help?
<mterry> sil2100, since I was able to reproduce yesterday.  (I assume I still can...)
<sil2100> mterry: I'll ping you in a the nearest time, ok :) ?
<mterry> k
<sil2100> mterry: so, hm, are you able to reproduce the alt+f10 issue even now?
<sil2100> mterry: what unity package are you using?
<mterry> sil2100, I'd have to log out and back in to double confirm, but I haven't updated since I could reproduce
<mterry> sil2100, I'm using 6.12.0daily13.01.09.1-0ubuntu1
<sil2100> mterry: on the guest session it's the same?
<mterry> sil2100, ooh good point, let me check.  love that guest session
<sil2100> I'm still unable to reproduce it on the guest session though... so I was wondering if you are able
<mterry> sil2100, yeah I can reproduce on guest session
<sil2100> hm, ok, thanks - I'll try something and get back to you
<didrocks> tedg: hey, one of your test is timing out on powerpc for dbus-test-runner, am I right? https://launchpadlibrarian.net/128111076/buildlog_ubuntu-raring-powerpc.dbus-test-runner_12.10.2daily13.01.10-0ubuntu1_FAILEDTOBUILD.txt.gz
<sil2100> didrocks: btw. can you also reproduce the problem that mterry noticed? With the first Alt+F10 not working
<tedg> didrocks, Hmm,no, it seems to be getting the wrong data.
<tedg> Finding cat1 data
<didrocks> sil2100: let me check, one sec
<tedg> Finding cat2 data
<tedg> Filtering cat1 data
<tedg> Filtering cat2 data
<tedg> Verifying cat 1
<tedg> Verifying cat 2
<tedg> FAIL: test-output
<mterry> sil2100, bregma could yesterday I believe
<didrocks> tedg: ok, I'm wrong then, any idea what can be the cause? it's passing fine on all the other archs
<didrocks> sil2100: the first alt + F10 is working for me as well
<mterry> cyphermox, libappindicator is killing me.  now the gtk2 tests can't pass, failing on the fallback test
<sil2100> hm
<sil2100> popey: also says he cannot reproduce
<sil2100> mterry: could you maybe try updating to the latest unity packages?
<mterry> sil2100, alright
<didrocks> sil2100: ah, you think the failure is something else then?
<popey> i get the first indicator on first ALT+F10
<popey> will try a guest session..
<tedg> didrocks, Not really.  We'd kinda need the files that it's building.  It generates temp files to do the compare.
<popey> yup, works same as guest
<didrocks> tedg: I tried a rebuild to see if at least it's just flacky
<sil2100> didrocks: yes, since hm, even though it would make sense that this bug causes the failures, but I think there's a seperate test for Alt+F10 and I think it didn't fail
<sil2100> Or hm, wait
<mterry> sil2100, which one runs first?  ;)
<sil2100> mterry: I think each of them is being ran on a clean session I think?
<cyphermox> mterry: yellow paint!
<mterry> Oh good
<mterry> cyphermox, I know
<didrocks> sil2100: right
<sil2100> didrocks: yes, indeed it didn't fail, test_panel_first_menu_show_works passed
<sil2100> This is a big mystery
<sil2100> Back to the drawing board
<didrocks> I'm sure mterry can be of help to distract him from libappindicator love :)
<mterry> I'm trying again with latest unity
<mterry> But it takes me awhile because my backup laptop is dog slow
<didrocks> mterry: oh, you didn't have a spare disk? you switched laptop?
<mterry> didrocks, yeah
<didrocks> feeling the pain :/
<mterry> didrocks, you have spare disks lying around?  I guess that's smart, considering what I just did
<didrocks> mterry: yeah, I have one on usb just in case
<mterry> didrocks, even better, do raid duplication with an external drive  :)
<didrocks> mterry: not that far, only my server has raid duplication :)
<didrocks> ok, latest corner case fixed. I can really say that we are to those 2 tests closed to daily release of unity!
<didrocks> tedg: yeah, it's really flacky, the rebuild worked
<tedg> didrocks, Eh... good?  :-/
<didrocks> well, not really good, but meaning harder to debug
<didrocks> only happens on powerpc and not everytimeâ¦
<sil2100> Those _prev _next tests are really mysterious
<didrocks> sil2100: they don't fail locally for you at all?
<sil2100> hm, would it be somehow possible to run single tests on that jenkins machine?
<didrocks> sil2100: well, it is, but what that will teach you?
<sil2100> didrocks: completely, didn't fail even once, both on my session, on my guest session, no problems at all
<sil2100> didrocks: maybe I could add some debugging and run the tests to see what exactly is happening? But hm, maybe really it's pointless
<didrocks> sil2100: for a physical access to the machine, I think only mmrazik has it
<mterry> sil2100, still can reproduce with latest daily-build contents
<bschaefer> sil2100, you should be able to run single tests by changing the value of the  'tests' when you do a build now on jenkins
<bschaefer> a single test*
<sil2100> mterry: oh
<didrocks> mterry: so, it's failing running this pilot test for you? or you mean alt + F10?
<mterry> didrocks, alt+f10 fails.  I ran autopilot test yesterday and it failed too
<didrocks> ah, interesting :)
<didrocks> so maybe that's what is happening on those config
<sil2100> So we have one reliable reproducing person
<mterry> Plus, the logs for the autopilot test indicate that the alt+f10 fails there too
<didrocks> sil2100: and this guy is really reliable, you know :)
<mterry> it fails everytime anyway  :)
<sil2100> ok, so hm hm
<didrocks> bschaefer: no idea of why alt + f10 is still failing on first trial for mterry?
<sil2100> mterry: could you start a fresh session (best guest session I guess?), bzr branch lp:unity and run one specific test?
<bschaefer> didrocks, hmm alt+f10 is work for me :(
<sil2100> mterry: run autopilot run unity.tests.test_panel.PanelKeyNavigationTests.test_panel_first_menu_show_works
<sil2100> mterry: on that guest session please
<sil2100> And tell me if it works or not
<sil2100> :)
<sil2100> The only difference between the _prev/_next tests and the test_panel_first_menu_show_works is that the the first_menu one has a 1 second sleep() in it after launching the application
<sil2100> Which shouldn't matter, as in _prev and _next we're waiting for the application to have focus anyway
<mterry> sil2100, OK.  Will take me a few minutes
<sil2100> mterry: ok, tell me once you find time for that
<mterry> sil2100, failed but then worked (there was some noise with my computer being too slow)
<mterry> sil2100, but seemed like I was able to reproduce problem even on that test
<sil2100> mterry: but it was only failing when ran for the first time, yes?
<mterry> sil2100, yes
<sil2100> Mystical
<mterry> sil2100, so is there a way to give you a more comprehensive log of what happens?
<mterry> sil2100, are there other unity devs around that we can poll to see if they can reproduce?
<mterry> sil2100, in the hopes of hitting someone that can both repro and knows how to fix it?
<bschaefer> mterry, hmm so how do you reproduce this?
 * bschaefer is around
<mterry> bschaefer, on a guest session, open an app and press alt+f10
<mterry> See if it opens a menu
 * bschaefer goes to attempt
<mterry> Then try it a second time, and it should
<bschaefer> mterry, hmm my guest session appears to have a broken unity....
 * bschaefer goes to see what the problem is
<mterry> different than the alt+f10 thing?  hm
<bschaefer> mterry, yeeah, like unity wont start :(
<bschaefer> just an empty background...which is strange...as unity works fine on my other user account...
<sil2100> bschaefer: update compiz maybe?
<sil2100> bschaefer: since there was an opengl plugin ABI break
<bschaefer> sil2100, yeah, im updating now!
<sil2100> So hm, maybe you'll even have to re-build unity with the latest compiz? I know that staging compiz + unity works
<sil2100> But both need to be updated at the same time ;)
<bschaefer> possibly, I have staging, but I have compiz/unity/nux built right now, but not on my guest session
<bschaefer> mterry, also why does it have to be a guest account? Or is it just on a fresh reboot?
<sil2100> bschaefer: on a fresh reboot it's the same
<sil2100> It seems that the first Alt+F10 press is not registered on his system
<sil2100> But on mine, popey's, didier's and other people it's fine
<sil2100> The first on the session start
<bschaefer> sil2100, strange! Is it causing an AP failure?
<sil2100> bschaefer: probably... but the strange thing is!
<sil2100> It *sometimes* causes failure of 2 tests
<bschaefer> sounds like an uninted var
<sil2100> Although there are some other tests that use the same keybinding
<sil2100> So hm, it's not 100% reproducible even on jenkins
<sil2100> Since some machines sometimes are not affected
<bschaefer> sil2100, the keybinding comes through compiz right?
<sil2100> I think so
 * bschaefer hasn't worked with indicators/menus much
<bschaefer> Trevinho, ping
<sil2100> And it's using a correct one
<bschaefer> dang, hes away
<bschaefer> yeah odd, let me try this again (as i've updated...)
<bschaefer> but i might have to reboot ;)
<sil2100> But now at least I know it's more likely a regression in unity that's probably appearing in certain conditions
<sil2100> And not an AP problem
<sil2100> But ok, I need to rest a bit now
<sil2100> bschaefer, mterry: if you guys find out something more, please send me an e-mail!
<sil2100> I'll look into it a bit later too
<sil2100> See you later
<mterry> cyphermox, trying a fix for libappindicator in a ppa
 * mterry crosses his fingers
<bschaefer> hmm strange, my schemas/plugins seems to be messed up on my guest
<mterry> Welcome back! : )
<bschaefer> thanks...I figured I could just try it on a fresh reboot...and it worked :(
<bschaefer> i have trunk compiz/unity/nux and staging ppa as well
<cyphermox> mterry: so? :D
<bschaefer> mterry, do you get it everytime?
<mterry> bschaefer, yeah.  first time per session
<mterry> after that it works normal
<bschaefer> mterry, strange...
<mterry> bschaefer, you don't see it?
<bschaefer> mterry, nope :(, Ill poke some more people later when they get on to give it try
<mterry> darn it
<bschaefer> mterry, you said you were up with the staging ppa as well?
<mterry> bschaefer, daily-build
<bschaefer> that should be pretty much the same...
<bregma> what exactly is the unexpected behaviour I'm trying to see?
<mterry> bregma, the alt+f10 thing?  The first time you press alt+f10 in an app in a session, the menu doesn't appear
<bregma> OK
<bregma> definitely haven't been able to repro with latest staging
<bregma> I'll reboot and try one more time, for posterity
<mterry> hm
<mterry> We still fail the test on jenkins right?
<bregma> is this test_panel_indicators_key_navigation_next_works ?
<bschaefer> unity.tests.test_panel.PanelKeyNavigationTests.test_panel_indicators_key_navigation_prev_works is the only one I see failing atm
<bschaefer> prev/nux
<bschaefer> next*
 * bschaefer goes to look at the video
<mterry> bschaefer, sorry, went away
<mterry> bschaefer, didn't see highlight
<mterry> bschaefer, both next and prev fail, depending on driver
<bschaefer> mterry, no worries, I  should have mentioned your name...
<bschaefer> bregma, ^
<bschaefer> mterry, hmmm yeah the video shows no menu appearing but the AP log shows that Alt+F10 is being pressed
<bschaefer> mterry, different drivers cause this problem?
<bschaefer> do you mean arc?
<mterry> bschaefer, I believe someone mentioned a difference in failing tests between nvidia and intel
<bschaefer> mterry, yeah, looking at those only prev fails, not next
<mterry> bschaefer, curious
<mterry> bschaefer, each test is in a completely new session?
<bschaefer> mterry, yeah they are, whats odd is the nvidia one fails for both next/prev
<bschaefer> but intel/ati only fails the prev
<mterry> OK...  My machine that can replicate the failure is intel
 * bschaefer kicks off another jenkins jobs
<bschaefer> mterry, hmm I have a hybrid, but I only use the intel part but ...
<bschaefer> i cant see how this is video card related
<bschaefer> mterry, strange, I just did a compiz --replace....and the first menu attempted failed...
<mterry> ooh ooh
<mterry> I'm not crazy!  (maybe)
<bschaefer> but i can't get it to repro now :(
<mterry> bschaefer, even further --replaces?
<bschaefer> mterry, replaces just does what 'unity' does...
<bschaefer> and yeah
<bschaefer> wait opps...haha I thought that is what you were asking
 * bschaefer attempts some more
<bschaefer> very strange...
<bschaefer> now it works perfectly, as I just rebuilt unity with a print statement in the function that opens the menu
<bschaefer> well the callback function that gets called from compiz when alt+f10 is hit....
<bschaefer> andyrock, hheeey
<andyrock> bschaefer, hey ;) whatsup?
<bschaefer> andyrock, could you attempt to reproduce this problem?
<andyrock> bschaefer, what problem?
<bschaefer> andyrock, wait I forgot you're running Q!
<bschaefer> andyrock, well anyway
<bschaefer> andyrock, go to a guest session
<bschaefer> and open an app, and press alt+f10
<bschaefer> the problem is on first start up the menu doesn't work
 * mterry goes and tries to reproduce again in guest session
<bschaefer> mterry, I got this when it failed (in the terminal)
<bschaefer> ;3~
<andyrock> do i really need a guest session? (i don't have unity/compiz/... trunk there)
<bschaefer> which means....dang...I remember I bug about that
<bschaefer> andyrock, well it needs to be a on a fresh reboot
<bschaefer> (or possibly a compiz --replace)
<bschaefer> mterry, yeah, im getting it on a compiz replace...second time
<bschaefer> it is very hard to repro though...
<bschaefer> mterry, I think when ^[[21;3~ shows up in a terminal it means there is no key binding for that set up yet...
<bschaefer> i wonder why...
<mterry> ah hm..
<andyrock> bschaefer, can't reproduce it here with unity or compiz --replace
<andyrock> let me restart
<andyrock> reboot sorry
<andyrock> brb
<bschaefer> andyrock, alright :)
<bschaefer> mterry, im also hoping...that its the same problem
<bschaefer> mterry, because it seems if you hold Alt and press F10 a lot of times it fails a few times as well
<bschaefer> mterry, or actually it seems to have broke it for me...wth
<andyrock> bschaefer, nope :/
<andyrock> it's fine here
<bschaefer> andyrock, :(...very strange its hard to get for me...
<bschaefer> if Im even getting the same problem as mterry
<bschaefer> yeah..hmm after like 10 compiz --replaces it seems to fail
<mterry> huh
<mterry> it was may more reproducable for me
<mterry> But my machine is very slow....?
<bschaefer> mterry, yeah...that is why im wondering if its the same problem :(
<bschaefer> mterry, could you try to reproduce it using a terminal and see if any text appears?
<bschaefer> such at ^[[21;3~
<bschaefer> or just ;3~
<mterry> ok
 * bschaefer attempts a reboot
<bschaefer> mterry, i got it this time..on start up
<mterry> bschaefer, i have some info too
<bschaefer> mterry, sweet!
<mterry> bschaefer, I could reproduce the ;3~ if I did it a bunch in a terminal
<bschaefer> yeah, that seems to be normal
<mterry> But it seems that opening the terminal made the menubar visible for a bit, and the first one worked
<bschaefer> i got the ;3~ on start up with a terminal
<mterry> Unlike
<mterry> Normal apps, which don't make the menubar visible on startup
<bschaefer> and the menu didn't come up
<bschaefer> mterry, oo...so the terminal worked for you on start up?
<mterry> bschaefer, yeah.  Unlike nautilus
<mterry> bschaefer, but when I did it a bunch, it worked intermittently
<bschaefer> strange...it seems to work sometimes for me...
<bschaefer> mterry, yeah, i noticed that as well...but im not sure if that the same thing or a 'feature'/bug
<bschaefer> as you could think hold Alt and press F10 would toggle the menu...
<bschaefer> press*
<bschaefer> presssing*
<bschaefer> mterry, also the ;3~ I think is just what compiz outputs when there is no keybinding, the 3 seems to be for the mod (Alt), as if you do ctrl+F10 its a ;5~
 * bschaefer doesn't know if that is a useful thing to use atm
<mterry> bschaefer, it seems correlated to whether the appmenu appears for a moment
<bschaefer> mterry, yes it does
<bschaefer> mterry, sooo hmm
<bschaefer> mterry, how many times did you try the terminal on a fresh guest session?
<mterry> bschaefer, also... opening the dash seems to make it not occur
<bschaefer> as for me it isn't always repro
<bschaefer> on start up
<mterry> bschaefer, a couple, but they were interspersed with dash and other things
<bschaefer> mterry, o strange, so Startup -> Dash -> no bug?
<bschaefer> mterry, alright, can you try this then...on a start up try just mousing over a launcher icon
<bschaefer> (as the dash is set up on a ~60 second timer to init everything...)
<bschaefer> init everything dash wise
<mterry> ok.  mouse over and then what?
<mterry> launch something and try?
<bschaefer> mterry, yeah
<bschaefer> as mousing over a launcher icon will init the dash
<mterry> well I normally mouse over real quick to click a launch icon to get an app
<mterry> before pressing alt+f10
<bschaefer> mterry, o well then cool, I do a ctrl+alt+t
<mterry> my normal route is login & click nautilus & alt+f10
<bschaefer> mterry, i was checking if the ::EnsureDash fixed the issue or not
<bschaefer> mterry, the same for gcalc as well? ( As thats what the AP test uses)
<mterry> hmm
<mterry> let me put that on my launcher
<bschaefer> wth...my alt+f10 is just broken now...
<bschaefer> hmm i can't get it to fail with compiz --replace and the gcalctool
 * bschaefer does a reboot
<bschaefer> mterry, well I got it on start up with the gcalc
<bschaefer> soo at lease i seem to be able to repro this...
<mterry> bschaefer, I'm wondering
<mterry> bschaefer, is this a timing thing
<mterry> bschaefer, like if I press alt+f10 intentionally very soon after launch, it doesn't work
<mterry> bschaefer, but it does shortly after
<mterry> bschaefer, when appindicator is all initialized and such
<bschaefer> mterry, it could be...there are a lot of timing things in unity where it waits to init things...
<bschaefer> mterry, though im not as familiar with the panel/indicators
<mterry> bschaefer, this does not explain the repeated presses in Terminal
<bschaefer> mterry, but now that I know what Im looking at im doing it very quickly...
<mterry> bschaefer, but maybe it does the first time ones
<bschaefer> mterry, well I got it on the terminal on start up before
<mterry> bschaefer, try to repro but slowly.  I'll try slowly too
<bschaefer> mterry, alright,
 * bschaefer reboots
<bschaefer> mterry, strange!...
<mterry> bschaefer, gosh darn it.  Nevermind about my darn clues.  I just tried slowly *and* the appmenu appeared for a moment before I pressed alt+f10.  And it didn't work (i.e. I reproduced it)
<mterry> bschaefer, you've got info?
<bschaefer> mterry, well I at first just kinda of went slowly...and attempted it
<bschaefer> and i reproduced it
<bschaefer> mterry, but the second time, I rebooted, started gcalc, and went and poured some coffee...and it worked first time
<mterry> Hm.  So timing seems unlikely
<bschaefer> mterry, yeah...it really seems like an uninitialized variable somewhere...
<bschaefer> which i've seen cause a lot of start up only problems
<mterry> bschaefer, OK.  Doesn't clang or something notify us of such things?
<bschaefer> mterry, hmm yeah, or valgrind
<bschaefer> i haven't used clang much, but that would be fun to test out
<bschaefer> mterry, but im able to reproduce this so I can take a look at it :)
<mterry> bschaefer, OK!  Cool
<bschaefer> mterry, hopefully its a simple problem :)
<mterry> bschaefer, your uninitialized variable idea sounds right
<bschaefer> mterry, its what im hoping!
<bschaefer> but ill play around with that though, a big problem could be too that compiz isn't calling the callback function for the Alt+F10...(which is why we were getting ;3~)
<bschaefer> soo it could also mean that isn't set up right away either
<bschaefer> but ill do some digging :), thanks for being able to reproduce this!
<cyphermox> mterry: indicator-session segfaults when it gets started for the tests!
<cyphermox> ah, i see it needs a crapload of state from dbus to work
<alesage> cyphermox, I'm not seeing it fail in Jenkins dailies fwiw
<cyphermox> it's complicated
<cyphermox> it needs a bunch of state that might be available on the jenkins server, but never in a PPA
<alesage> indicator-session's relationship status to Launchpad: it's complicated
<bschaefer> mterry, it was an un initialized var
<bschaefer> mterry, FIRST MENU SHOW 1852139876
<mterry> cyphermox, you around?
<bschaefer> mterry, the fix for the issue is here: https://code.launchpad.net/~brandontschaefer/unity/panel-startup-fix/+merge/142805
<bschaefer> mterry, when it merges you should be able to confirm it your self with an update :)
<mterry> bschaefer, hi
<mterry> bschaefer, yeah, I saw that go by!  Thanks a bunch
<bschaefer> mterry, hello, cool. Ill kick the AP tests once it gets into the daily ppa
<Klap-in> hehe, one line, and so much work... intriguing to see. congratulations!
<bschaefer> reproducing the problem was the biggest problem :)
<cyphermox> mterry: yeah, around
<cyphermox> in class now though so I'll answer when I can
<mterry> cyphermox, sorry was afk.  I just had a proposed branch for ya.  Builds in a PPA for me
<mterry> cyphermox, I proposed a merge against your branch, review at your leisure
<cyphermox> awesome
<cyphermox> linky? :D
<mterry> cyphermox, https://code.launchpad.net/~mterry/libappindicator/fix-tests/+merge/142802
#ubuntu-unity 2013-01-11
<Mirv> morning
<didrocks> sil2100: hey!
<didrocks> sil2100: there is a new failure, but just one and on the 3 architectures!
<didrocks> unity.tests.test_hud.HudBehaviorTests.test_alt_arrow_keys_not_eaten
<didrocks> jibel: FYI ^
<didrocks> we were almost there, snif!
<sil2100> \o/
<didrocks> sil2100: I was really believing we would release now :p
<sil2100> didrocks: ok, let me see that then, looks like a more random failure, but maybe we can make it better not to fail
<didrocks> at least the next/prev are fixed!
<didrocks> sil2100: the weird thing is that it's failing on the 3 config
<didrocks> let's hope it's reproduceable
<didrocks> sil2100: ps-indicators-autopilot-release-testing
<didrocks> rev 63
<sil2100> Ah, ok, sorry, I misunderstood you
<didrocks> seb128: popey: btw, do not hesitate to upgrade to the daily-build ppa
<sil2100> So it's failing on all, hm hm
<didrocks> sil2100: yep
<didrocks> seb128: popey: I did it, and it looks good, just have this indicator failure ^
 * sil2100 pulls latest unity
<seb128> didrocks, you rebuilt unity with the compiz opengl abi downgraded?
<didrocks> sil2100: daily-build ppa
<didrocks> yep
<popey> didrocks: i do every morning
<didrocks> sweet ;)
<seb128> didrocks, k, upgrading
<sil2100> Ok, so, a check for is_focused is not enough, *sighs*
<didrocks> sil2100: so, the test is giving a false positive?
<didrocks> sil2100: do you know what changed from yesterday?
<sil2100> didrocks: I have no idea, I mean, this failure seems to happen when the Terminal takes a bit longer to start - i.e. the shell on it
<sil2100> I added a wait for the Terminal window to have focus, but as I can see it doesn't help always, since the window can be focused but not yet ready to fetch input
<sil2100> I'll try to think of a quick clean solution
<seb128> mhr3, hey
<seb128> mhr3, with the current daily build my dash has a sort of weird blue "," between the expendable categories and their ">"
<seb128> e.g "installed" in the app lens
<didrocks> sil2100: thanks, counting on you to be able to release unity :)
<seb128> is that normal/wanted?
<didrocks> mhr3: confirmed here
<mhr3> seb128, yea, i saw that with trunk some time ago
<mhr3> not sure who did that :)
<didrocks> you didn't ask? :/
<mhr3> iirc the number of results wasn't displayed either in that case
<seb128> no
<seb128> there is only a ","
<seb128> or "."
<mhr3> thought it's an upcoming design change
<seb128> well, it could be to drop the label, the weird char seems wrong and misaligned though, I somewhat doubt it's a design change
<mhr3> andyrock, would you know something about that ^?
<popey> it's a ':' here seb128
<popey> you have good eyes! I never noticed that! âº
<didrocks> I just have a . here
<seb128> popey, could be, I've an hard time to see exactly what char it is with my background color
<didrocks> popey: he's good, isn't it? :)
<andyrock> mhr3, no ask nick :)
<andyrock> mhr3, btw if Nick is not online (or busy) i can try to fix it in the afternoon
<didrocks> we will never be able to release unity :(
<sil2100> huh? Something besides the AP test is broken? :(
<didrocks> sil2100: yeah, but not linked
<didrocks> sil2100: you can continue on the test :)
<sil2100> Oh...
<sil2100> ;)
<didrocks> hey dednick :)
<dednick> howdy
<didrocks> seb128 | mhr3, with the current daily build my dash has a sort of weird blue "," between the expendable categories and
<didrocks>        | their ">"
<didrocks> seb128 | e.g "installed" in the app lens
<didrocks> dednick: good, this and one test failing that sil2100 is working on are the last step before enabling daily release of unity :-)
<didrocks> dednick: do you know about it? or maybe have a look at it?
<dednick> seb128: Do you have the "See X more results" showing next to the > ?
<seb128> no
<seb128> that replace those labels
<seb128> replaces
<seb128> I've like "Installed "," >"
<seb128> without the ""
<seb128> didrocks and mhr3 and popey confirmed
<dednick> ok. i think i know what this is. mandel was doing something with StaticCairoText width calculations that might have caused a regression.
<didrocks> dednick: I just have one one the file category working, all the others are like seb128 told
<dednick> i know it has caused some problems before
<didrocks> interesting :)
<dednick> didrocks: i'll check with mandel about the status of that quick.
<didrocks> thanks :)
<popey> didrocks: what do we need to do to allow users to file bugs against the compiz package in the daily ppa with "ubuntu-bug compiz"? I am getting the usual "This is not an official Ubuntu package" popup from apport
<didrocks> popey: let's see if we need to do that, as the daily-build is just a 4 hours step between build and distro normally
<didrocks> popey: if we have some stack stalled for more days, maybe it will be useful, I'm just unsure for now
<popey> ok
<jibel> didrocks, with unity ppa, dash blinks when I type something in the search bar, I'll try to make a video
<didrocks> thanks jibel, duflu will maybe have some hint about it
<sil2100> hm, there doesn't seem any 100% safe way, so I'll do it a bit hackish
<didrocks> sil2100: so adding more timing?
<sil2100> Or maybe, let me check something on my guest session ;p
<jibel> popey, hey, which tool do you use to record a video of a desktop session with the dash? I tried recordmydesktop, but it's all dark and only captures the background
<popey> jibel: kazam
<seb128> jibel, gtk-recordmydesktop works for recording the dash, etc on my raring
<seb128> jibel, you can always use your phone or camera or something otherwise ;-)
<jibel> seb128, it doesn't here with raring, all updates, etc on an intel atom IGC
<jibel> i'll try kazam
<didrocks> dednick: did you find anything relevant?
<jibel> seb128, finally recordmydesktop works fine, the problem comes from totem for the playback
<seb128> ahah
<jibel> bug 1098502
<ubot5> bug 1098502 in Unity "Dash blinks when typing text in search bar" [Undecided,New] https://launchpad.net/bugs/1098502
<sil2100> Ok, tested all nice solutions, none were giving me complete guarantee, so I'm using the simplest one
<sil2100> A sleep call, yea, we like those
<didrocks> sil2100: well, let's do that I guessâ¦
 * sil2100 sighs
<sil2100> Preparing a merge
<sil2100> I'll have a talk with thomi next week about doing it nicer, for now let's hope this will solve the issue for releasing unity
<didrocks> sil2100: sounds good, yeah, let's do what we can for now :)
<didrocks> but I need to know where dednick is as well, not sure if we should block the release on that issue, specifically if the fix is trivialâ¦
<dednick> didrocks: mandel is looking at the issue now.
<didrocks> dednick: ah sweet, what is his IRC nickname? can he come into that chan? :)
<dednick> didrocks: mandel
<dednick> didrocks: i've just asked him to join
<didrocks> thanks dednick :)
<mandel> dednick, hello
<didrocks> hey mandel ;)
<didrocks> mandel: so, I guess all eyes are on you to release unity now, but no pressure :-)
<didrocks> mandel: more seriously, do you think the fix will be trivial?
<mandel> didrocks, hello, so I'm looking at the StaticCairotText rendering, it seems that the PrelayoutManagement does have the correct size, witch is interesting
<mandel> didrocks,he, no pressure :)
<didrocks> mandel: oh, "funny" did you notice it's a blue dot as well?
<mandel> didrocks, that I did not see, let me check
<didrocks> mandel: it's barely noticeable, but we are more than one having <category> . >
<didrocks> with . being : for popey
<mandel> didrocks, is more like two blue dots,  but is probably it trying to render the font and doing something wrong
<didrocks> (and blue)
<didrocks> ok :)
<popey> yeah, could be squished text
<popey> and not actually a :
<didrocks> but why blue? :p
<popey> well that too
<mandel> didrocks, popey no to worry, I already have a fix, I need to clean the code a little and make sure it does not break in other cases
<mandel> give me 15/30 mins or so to make sure
<didrocks> mandel: you rock! :-)
<dednick> mandel: remember to check the tooltip as well ;)
<mandel> dednick, hehe, yes, I remember that ;)
<sil2100> \o/
<didrocks> sil2100: btw, if you need some approval on your branch
<sil2100> https://code.launchpad.net/~sil2100/unity/autopilot_add_ugly_sleep/+merge/142869
<didrocks> mandel: just to know, the fix will be in nux or unity?
<sil2100> Please, free karma ;)
<mandel> didrocks, unity
<didrocks> mandel: ok, great, thanks ;)
<didrocks> not respawing a rebuild immediately then
 * sil2100 always wonders why he spends so much time writing all this rationale in the merge requests
<didrocks> sil2100: I read them, worth it!
<didrocks> :)
<didrocks> sil2100: thanks! approved :)
<sil2100> Thanks :)
<sil2100> andyrock: soo, a Qt application for testing bug #1087422 is fine as well? ;)
<ubot5> bug 1087422 in unity (Ubuntu) "Windows that start minimized cannot be opened" [High,In progress] https://launchpad.net/bugs/1087422
<sil2100> andyrock: I'll add the feature you're requesting in a moment then!
<andyrock> sil2100, yeah it's fine I've already tested :)
<andyrock> thank you btw :)
<sil2100> andyrock: updated - the name is fine btw. ;p
<sil2100> andyrock: test it once again and if it works as it did before, approve and let's get it merged!
<didrocks> andyrock: sil2100: can you just wait that we do this release before getting it merged?
<didrocks> andyrock: sil2100: I don't want we add one another variable parameter before this release :)
<sil2100> andyrock: ^ ;)
<andyrock> didrocks, sil2100 yeah no problem :)
<didrocks> thanks :)
<sil2100> andyrock: let's get the testapp thing merged in the meantime
<mandel> didrocks, so nux revno 742 fixed a logical error in the layouts (no bug number, doh!) and before that was fixed I added a workaound for statica cairo text, with the new code in nux that is not longer needed and goes wrong in a diff way, I have fixed it and changed the test to ensure everything works correctly
<didrocks> mandel: oh interesting side effect of a workaround then :-) do you have a branch handy?
<mandel> didrocks, please take a look at https://code.launchpad.net/~mandel/unity/static-cairo-text/+merge/142873
<andyrock> sil2100, ok let me wrote the AP test for unity (without merging it for the moment)
 * didrocks opens and builds while reviewing
<sil2100> \o/
<mandel> didrocks, I will add no comments about nux && layouts ;-)
<didrocks> heh :)
<didrocks> mandel: well, I know what you mean, I felt the pain in the past :)
<mandel> didrocks, I don't know if I should feel happy because I knew where to find the problem or otherwise
<didrocks> mandel: ahah, well, you can call that "expertise on the subject" :)
<didrocks> some kind of niche knowledge ;)
<Mirv> can you reproduce that nautilus again starts behind other windows in raring+daily?
<didrocks> mandel: confirming the fix is working! :)
<didrocks> Mirv: hum, I don't see that
<didrocks> mandel: nice work, thanks! ;)
<didrocks> and still having tooltips :p
<mandel> didrocks, take a look at the launcher, but works too, just in case :)
<mandel> didrocks, you are faster than me ;)
<Mirv> eg. maximized firefox, super + 1, nautilus starts to the background not front
<Mirv> didrocks: ok, interesting, seems to me similar to what quantal had before nautilus was patched
<didrocks> mandel: heh :)
<didrocks> Mirv: ah indeed, if started with super + something
<didrocks> I was cliking on the launcher
<seb128> even clicking on the launcher it goes unfocussed for me
<didrocks> hum, not here, maybe something with the state
<seb128> we had to drop the nautilus patch, upstream fixed it in a different way for 3.6 which works for gnome-shell but not us
<Mirv> same as seb128, although I noticed it requires the maximized window
<seb128> andyrock was working on that
<seb128> he had a patch for gtk, not sure how that is going
<andyrock> seb128, what?
<seb128> andyrock, nautilus not getting focus in raring
<andyrock> again?
<seb128> andyrock, well, "in raring", in 3.6 since we dropped your patch, since cosimoc did a different version which works for gnome-shell but not unity
<seb128> andyrock, well, didn't you say it's a gtk bug in the timestamp handling?
<andyrock> seb128, yeah i'm sure that gtk/gdk had that bug but startup notifications maybe can workaround it :)
<andyrock> and unity does not support them
<seb128> right
<seb128> so it's not "again", it's "still" ;-)
<seb128> andyrock, did you ever get any feedback on your gtk patch?
<seb128> I wonder if we should just distro patch it
<andyrock> seb128, no Trevinho and me opened a gdk bug with a very simple test program showing the issue
<andyrock> btw we really need to support startup notification in unity
<andyrock> Trevinho wants to do it directly in bamf
<andyrock> but he is too busy
<andyrock> we need to put that bug in the "polish blueprint"
<seb128> right
<Mirv> filed bug #1098533
<ubot5> bug 1098533 in nautilus (Ubuntu) "New nautilus window starts behind fullscreen window" [Undecided,New] https://launchpad.net/bugs/1098533
<didrocks> s/fullscreen/maximized/ isn't it?
<Mirv> didrocks: thanks, yes, title is wrong
<didrocks> yw ;)
<Mirv> test case was correct. fixed title.
<Trevinho> seb128: I have a workaround that I'll try to land upstream too...
<Trevinho> seb128: this is the issue (and workaround) https://bugzilla.gnome.org/show_bug.cgi?id=688830
<ubot5> Gnome bug 688830 in gtk "gtk_window_present uses an invalid time value, and does not always work" [Major,Unconfirmed]
<seb128> Trevinho, hey, thanks, I was looking for the bug earlier but I didn't remember enough about it to find it back
<seb128> Trevinho, we should maybe distro patch it
<seb128> Trevinho, not sure upstream is going to go anywhere on that anytime soon
<Trevinho> seb128: I was talking of nautilus only.... Even if that change could maybe done at gdk level...
<seb128> oh, ok
<didrocks> Trevinho: another subject: on the one ws by default, do you still have something to do on the unity side?
<didrocks> Trevinho: on the g-c-c side, I'll just set the hsize and hsize to 1x1 or 2x2 if disabled/enabled
<Trevinho> didrocks: yes, I'm in the process of updating the shortcut-hints now... That's the final step..
<Trevinho> didrocks: ah, and probably a few lines to remove in launcher controller (to avoid removal), but on launcher side everything is done
<didrocks> Trevinho: ok, but agreed that on my side, I just have to do that, change hsize/vsize?
<Trevinho> didrocks: yes, we listen to that value
<didrocks> if one of them is > 1, you enable the "ws mode"
<didrocks> Trevinho: excellent, thanks :)
<didrocks> would be a nice hacking during my first flight on sunday
<didrocks> too early on Sunday, so need something easy :)
<mterry> cyphermox, more yellow paint.  While my branch built fine for i386 in a PPA, amd64 apparently died overnight
<Trevinho> didrocks: will you also include an option to show/hide the desktop icon?
<Trevinho> didrocks: it should be explained here btw https://docs.google.com/a/canonical.com/document/d/1cbPd9WSSbFHg4Z7BSOQxDKusMe2aJjj0FEF2AMxNOZM/edit
<didrocks> Trevinho: yep, I'll do it at the same time
<Trevinho> didrocks: fine, the notes at the bottom should explain everything
<didrocks> yep ;)
<mterry> didrocks, so how can we match a given daily build to a bzr commit number?
<didrocks> mterry: quick easily, look at debian/changelog
<didrocks> you have "automatic snapshot from rev <â¦>"
<mterry> didrocks, ah yes!  ok
<didrocks> mterry: btw, hopefully this build will be the first daily release! :)
<didrocks> running all the tests
<mterry> didrocks, yeah  :)
<didrocks> then, running only the indicator tests on the indicator stack + whole ppa
<didrocks> and if everything is fine, publishing!
 * mterry crosses fingers
 * didrocks too
<didrocks> I think ~ 20 minutes for all the test running
<didrocks> then, the indicators one will start (~55 minutes)
<didrocks> tests*
<mterry> didrocks, how can I see a list of packages uploaded for SRU but not yet accepted into -proposed?
<didrocks> mterry: check the unapproved queue
<didrocks> like for quantal:
<didrocks> https://launchpad.net/ubuntu/quantal/+queue?queue_state=1&queue_text=
<mterry> didrocks, there's a page on LP, right?
<didrocks> yep :)
<mterry> didrocks, nice, thanks
<didrocks> yw
<mterry> that's what I couldn't remember
<mterry> cyphermox, despite the amd64 build failing for libappindicator in my PPA, I have to work on some other stuff today.  But I do think my branch makes things better anyway (i386 worked)
<didrocks> mterry: cyphermox: FYI, I remove dbusmenu from the list of daily release, it's failing on every arch due (weirdly) to a missing file (see ppa failure)
<didrocks> mterry: sil2100: on another note, all indicator tests passed \o/
<didrocks> nice work sil2100 ;)
<mterry> yay
<sil2100> Yaaay! \o/
<didrocks> as soon as unity is published on armhf, it will be time for the first daily release :)
<sil2100> https://launchpadlibrarian.net/128198353/buildlog_ubuntu-raring-armhf.unity_6.12.0daily12.12.05bzr3034pkg0raring0_FAILEDTOBUILD.txt.gz <- but it looks like a random failure
<sil2100> didrocks: I guess in daily all is OK?
<didrocks> sil2100: yeah, waiting for publishing
<mterry> sil2100, ld crashed!?  ick
<didrocks> ok, done
<didrocks> time to force publication \o/
<sil2100> Excellent!
<didrocks> ok, readyyyyyyy
<didrocks> and copy request to distro done \o/
<didrocks> sil2100: mterry: first real daily release of unity done to the distro \o/
<didrocks> enabling the cronjob now!
<didrocks> nice work everyone :)
<mterry> w00t!
 * mterry opens champagne
 * sil2100 claps his hands
 * mterry uncomfortably watches the Jenkins bot proposing and approving its own branches
<didrocks> mterry: heh, you know that even that was broken?
<didrocks> I had to patch bzr lp-propose to have the option working
<mterry> :)
<didrocks> fginther: hey, I thought that merging for the latestsnapshot was skipping the build? https://code.launchpad.net/~ps-jenkins/bamf/latestsnapshot/+merge/142925
<fginther> didrocks, no sorry, there has been no progress on that
<didrocks> fginther: ok, you follow them and reapprove? :)
<cyphermox> didrocks: indicator-session buils fine now (but with start-service disabled), and I got a autopkgtest test almost working; wanna do a first review before I propose a merge to actually merge this?
<fginther> didrocks, I thought the approved rev_id issue was fixed. This is the first one of seen w/o an approved revid for many weeks
<cyphermox> https://code.launchpad.net/~mathieu-tl/indicator-session/fix-tests/+merge/142951
<didrocks> cyphermox: I would love to! looking :)
<fginther> didrocks, looking into what happened here
<didrocks> fginther: thanks :)
<didrocks> cyphermox: it sounds good to me, did you run it with some autopkg infra?
<cyphermox> yeah that's what I'm doing
<didrocks> cyphermox: maybe localcheck should be integrationcheck ?
<cyphermox> for now it's still failing but I was able to manually run it
<cyphermox> could be
<didrocks> ok :)
<didrocks> cyphermox: as you wish for the naming, but this makes more sense to me than "local"
<cyphermox> so it's just a matter of getting the autopkgtest script right
<cyphermox> yeah
<didrocks> sweet!
<didrocks> :)
<didrocks> nice work cyphermox, can't wait to see that one down! :)
<cyphermox> yeah me too
<cyphermox> the heavy drinking is starting to take a toll ;D
<didrocks> cyphermox: ahah, you needed an excuse for that! :-)
<cyphermox> didrocks: always do :P
<didrocks> heh
<didrocks> fginther: bamf and dee are the only 2 remaining ones not merged yet, isn't it?
<fginther> didrocks, compiz is still building
<didrocks> right :)
<fginther> didrocks, yes, just those 3
<didrocks> fginther: ok, thanks!
<didrocks> fginther: yeah, maybe in the future, having those bypassing the build will gain a lot of CPU cycle
<didrocks> fginther: especially as we are doing that everyday now (for all projects having new code)
<fginther> didrocks, I'll make some time to work on this today and next week, will keep you posted
<didrocks> fginther: excellent, thanks!
<didrocks> fginther: if you need some special tag to recognize those kinds of merge or have any question, do not hesitate to ask!
<fginther> didrocks, thanks!
#ubuntu-unity 2013-01-12
<Squarism> I get so depressed. I really wanna use desktop ubuntu but unity just makes it damn impossible.
<Squarism> Why cant i reassign "semi-maximize" ? Why does that have to excluded from the shortcuts that can be reassigned?
<Squarism> ...and where do i report a bug on that
<Squarism> havent worked in 12.04 and 12.10
<Squarism> I get so depressed. I really wanna use desktop ubuntu but unity just makes it damn impossible. Why cant i reassign "semi-maximize" ? Why does that have to excluded from the shortcuts that can be reassigned?
<Squarism> its 2012.. such wierdities cant be in a OS that is supposed to be taken seriously
<Squarism> oh..2013
<Squarism> So where do i report bugs on unity interface?
<Klap-in> Squarism: on the bug interface on launchpad
<xkernel> Guys, there must be "Show Desktop" button in the left menu
<bregma> xkernel, it's coming
<xkernel> bregma, took too long
#ubuntu-unity 2013-01-13
<davidkrauser> Hi everybody
<davidkrauser> has anyone tried to build unity from source using these instructions lately? ( http://unity.ubuntu.com/getinvolved/development/unity/ )
<davidkrauser> It seems there may be new changes in the NUX trunk that aren't working with the latest from unity.
<davidkrauser> I opened a thread at the Ubuntu Forums about it: http://ubuntuforums.org/showthread.php?t=2102641
<davidkrauser> Just wondering if anyone knows of a specific version of NUX that is compatible, or if there's a work around?
<davidkrauser> It also seems that the INSTALL file in the repo is VERY out of date (maybe years?).
<davidkrauser> Anyways, if anyone has any suggestions I'd love to hear 'em. You can just post them in that forum thread. I may also post about this on the mailing list, just to see if I can get more ideas.
#ubuntu-unity 2014-01-06
<Cimi> Saviq, hi, can you read me here?
<olli_> hey Cimi, saviq is off today iirc
<Cimi> olli_, good... this channel is so silent I was wondering if I had connectivity issues :)
<Cimi> olli_, gm though, you in europe?
<olli_> yeah, in .de for January
<olli_> does anyone know how to run a qml locally on the phone
<olli_> my attempts so far lead to nice core dumps
<Cimi> olli_, should work from the sdk
<Cimi> olli_, when you have your app in qt creator, just run it on the phone from the menu
<Cimi> olli_, otherwise you have to kill the shell and its service, and run the qml file with qmlscene from adb shell
<dednick> Cimi: could you do a review for me when you get a chance? https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/slider-value-fix/+merge/199462
<Cimi> dednick, sure
<mhr3> can i get someone to ack https://code.launchpad.net/~mhr3/unity-scopes-shell/update-for-api-change/+merge/200517
<mhr3> Cimi, dednick ^?
<mhr3> it's a tiny change
<dednick> mhr3: give me a sec
<Cimi> mhr3, looks fine to me
<mhr3> Cimi, can you give it top-lvl approve pls?
<mhr3> everyone holidaying, no other approvers here :)
<Cimi> mhr3, done
<mhr3> thx
<dandrader> greyback, hey
<greyback> dandrader: hey
<dandrader> greyback, did you try out the QML_DISABLE_DISTANCEFIELD env var?
<greyback> dandrader: I did at some stage yes. Can't recall if it worked. Does it?
<dandrader> greyback, don't know yet. still reading up stuff
<greyback> dandrader: ok
<dandrader> greyback, also, have you tried to "set the renderType property to NativeRendering in order to use the system back-end to rasterize the glyphs instead of Qt"?
<dandrader> From http://blog.qt.digia.com/blog/2012/08/08/native-looking-text-in-qml-2/.
<dandrader> I wonder if it has the same effect as QML_DISABLE_DISTANCEFIELD
<elopio> Hello. I need a review, please.
<elopio> https://code.launchpad.net/~elopio/unity8/open_scope/+merge/200426
<elopio> autopilot emulator stuff for scopes in unity 8 ^
<elopio> somebody around?
<mhall119> greyback: were you working on an API to detect the presence of a keyboard or mouse?  Something we can use for conditional layouts
<greyback> mhall119: not me, best check with Kaleo
<mhall119> thanks
<elopio> Saviq: can you help me finding the right person to ping to look at my branch?
<greyback> elopio: Saviq out today, as are many other unity8 folk
<elopio> greyback: my bad luck.
<elopio> I'll be back tomorrow.
<greyback> Mirv: hey, I have the qt beta2 PPA installed, it's breaking my unity install unfortunately as unity needs bamfdaemon needs libunity-webapps0 needs libunity-webapps0 needs unity-webapps-service needs webbrowser-app, which won't install as it's for 5.0
<greyback> Mirv: so can I ask you to push the 5.2 build of webbrowser-app up your queue a little please :)
<mhr3> greyback, so is Mirv :)
<greyback> mhr3: yep I guessed, but it'll be in his logs
<mhr3> greyback, so where are you residing these days?
<greyback> mhr3: back in Ireland for a while
<mhr3> greyback, waiting for barcelona to get warmer? :)
<greyback> mhr3: you go home for Xmas?
<mhr3> yep, flying back to london tomorrow
<greyback> mhr3: various reasons. Barcelona will have to wait a while.
<mhr3> so you decided you miss rain? :)
<kgunn> greyback: do you know any reason we "don't like" running unity8 always in testability mode ?
<kgunn> relating to the old thread about pointers coord reporting to AP
<dandrader> elopio, about finding the best person to review your code: do a bzr log or blame or the code you changed and around it
<dandrader> elopio, but I guess aacid would be a good candidate
<dandrader> (not around today)
<dandrader> *on the code
<kgunn> running testability plugin while testing seems sensible to /me
<greyback> kgunn: I've no problem with it, if we're running tests. But it means if using phone, running an AP test will require unity8 to be restarted with testability enabled (unsure but think unable to turn it on during runtime)
<greyback> kgunn: it's not something I'd like turned on permanently however, as could open giant security hole
<elopio> dandrader: most of it was done by thomi. I was looking for somebody from the unity team, so you guys can take care of my code in case the UI changes :)
<elopio> aacid sounds good indeed. From the calendar I get that he's back tomorrow.
<kgunn> greyback: ack...i would also not advocate full-time use testability plugin...only for testing (like the name implies :)...is the restart of unity8 a pain point ?
<kgunn> at least a pain for the ap guys ? or ?
<kgunn> i mean...you'd just restart once in the beginning it'd seem
<greyback> kgunn: yeah, that's all. I don't think it a huge deal tbh.
<greyback> mhr3: yeah, I forgot the wonderful feeling of freezing cold rain in my face, not sure how I ever gave it up :P
<mhr3> indeed, what a bliss! :)
<tedg> bregma_, So, I have a touch screen now.  Can I make the-system-formerly-known-as-utouch simulate mousewheel with two finger scrolling?
<bregma_> tedg, if you use ginn or touchegg, maybe
<bregma_> a new release of ginn is upcoming that should work better
<bregma_> this is a Trusty release goal
<tedg> Ah, okay.
<tedg> Seems I have ginn installed, does it need config?
<tedg> Hmm "error subscribing to gestures"
<tedg> Perhaps for me it should be jesters.
 * tedg will be here all week, tip your waiters
#ubuntu-unity 2014-01-07
<Mirv> greyback's qt5 prob (unity gets deinstalled) is indeed because of the dependency chain, but just more complex ie. bugs need to be fixed in other packages first
<tsdgeos> mzanetti: you back'
<tsdgeos> ?
<mzanetti> tsdgeos: hi
<mzanetti> yes, I am
<tsdgeos> mzanetti: any chance we can do that "detach CI vm thing" so i can run the qmltests faster? Trying to get more info to make them work more reliable
<mzanetti> tsdgeos: sure
<mzanetti> tsdgeos: which one do you need?
<tsdgeos> mzanetti: qmluitests
<mzanetti> tsdgeos: ps-trusty-server-amd64-3
<Cimi> hi guys
<tsdgeos> Cimi: ho
<tsdgeos> so
<tsdgeos> this is interesting
<tsdgeos> any idea why this may happen
<tsdgeos> https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/797/consoleFull
<tsdgeos> search for "qmltestrunner::GenericScopeView::test_filter_expand_expand() A 0 [object Object]"
<tsdgeos> and see how a few lines up
<tsdgeos> it was
<tsdgeos> "qmltestrunner::GenericScopeView::test_filter_expand_expand() A Header_QMLTYPE_11_QML_52(0x1e3f020, "dashSectionHeader0")"
<tsdgeos> but the variable does not get reassigned
<tsdgeos> so it's just that the thing is disappearing?
<tsdgeos> yep it is
<tsdgeos> i think i have a fix for the expand_expand test!
<tsdgeos> which is not the one i wanted to fix originally
<tsdgeos> but oh well :D
<tsdgeos> Saviq: mzanetti: https://code.launchpad.net/~aacid/unity8/expand_expand_fix/+merge/200642
<mzanetti> tsdgeos: what exactly does this fix?
<mzanetti> un unstable test?
<mzanetti> ah right
<tsdgeos> not the one i wanted to originally fix
<tsdgeos> but i can't get the other to fail ^_^
<mzanetti> :D
<tsdgeos> busy looping now to see how much time the thing runs without failing
<tsdgeos> oh
<tsdgeos> i'm running the wrong unittest
<mzanetti> tsdgeos: do we really need the tryCompareFunction? Looks a bit like a regular tryCompare would be enough
<tsdgeos> that'd make sense
<tsdgeos> mzanetti: the thing is that the header0 object goes away
<mzanetti> ah ok
<tsdgeos> at some point
<tsdgeos> i need to requery it
<tsdgeos> no idea why tbh
<tsdgeos> otherwise you end up asking for an x of an object that "is not there" anymore
 * tsdgeos runs the correct unittest
<mhr3> Saviq, ok to talk about previews and shell tomorrow?
<Mirv> greyback: hi! regarding your unity/qt5.2 problem, I wrote about it before Christmas, when I identified at least hud needing a recompile, and hud requires gsettings-qt to be fixed (bug #1257322) - libqtdbustest was already fixed, another pre-requirement
<ubot5> bug 1257322 in qtdeclarative-opensource-src (Ubuntu) "gsettings-qt doesn't work with Qt 5.2" [Undecided,Fix committed] https://launchpad.net/bugs/1257322
<Mirv> greyback: so there's a rather long chain of various dependencies that need to be fixed, about which I also wrote
<greyback> Mirv: oh I missed that message, apologies. Ok, I will be patient, thanks
<Mirv> greyback: webbrowser-app needs UI Toolkit, which has some segfault in turn
<Mirv> but it's good to know that's also required for unity to not be removed when upgrading
<Mirv> I'll update the pad accordingly
<Saviq> mhr3, yup
<mhr3> Saviq, time ok, can move if you'd prefer
<mhr3> ?
<Saviq> mhr3, fine
<mhr3> k
<tsdgeos> Saviq: the Dash::test_show_scope_on_load failure is very weird
<tsdgeos> it is the listview that is actually not creating the delegate in some cases
<Saviq> tsdgeos, hmm, IIRC we have cacheBuffer MAX_INT there effectively?
<tsdgeos> yep
<tsdgeos> i mean
<tsdgeos> it works
<tsdgeos> most of the time
<tsdgeos> but sometimes not
<tsdgeos> which is weird
<tsdgeos> because i have never seen the phone just loading 2 of the 4 screens
<tsdgeos> i'm wondering if again we're just dealing with the evil scene graph loop from 5.0 failing to "do stuff"
<Saviq> tsdgeos, since you have the VM
<Saviq> tsdgeos, can you try and upgrade it to 5.2 and see if you can reproduce the issue?
<tsdgeos> makes sense
<tsdgeos> let me see
<Saviq> mzanetti, top-approve expand_expand fix?
<mzanetti> Saviq: done. was waiting for jenkins to run through and forgot
<Saviq> mzanetti, cheers
<tsdgeos> Saviq: i've done something else before the 5.2.0 update
<tsdgeos> i've exported QML_BAD_GUI_RENDER_LOOP
<Saviq> tsdgeos, righ
<Saviq> t
<tsdgeos> that runs the non threaded render loop
<tsdgeos> and i'm running the tests in a loop
<tsdgeos> let's give it some time to see if it fails or not
<tsdgeos> and then
<tsdgeos> do the 5.2.0 anyway
<tsdgeos> since we don't want the non threaded thing
<Saviq> tsdgeos, yup
<tsdgeos> well, been running for 14 minutes
<tsdgeos> so the non theraded loop makes it work
<tsdgeos> let's see what 5.2.0 says
<tsdgeos> Mirv: i can't install qtdeclarative5-ubuntu-ui-toolkit-plugin when using the ppa for 5.2
<tsdgeos> it complains it wants libqt5core5 but the ppa provides libqt5core5a
<tsdgeos> any idea?
<tsdgeos> Saviq: â you?
<greyback> Mirv: I've a branch attached to https://bugs.launchpad.net/platform-api/+bug/1266674 to fix the ftbfs, works for me now. Just need a reviewer
<ubot5> Ubuntu bug 1266674 in platform-api "platform-api fails build against libmirserver12" [Critical,In progress]
<greyback> tsdgeos: I think UITK has a crash bug with 5.2, so wasn't pushed to the PPA yet
<tsdgeos> greyback: it is in the ppa
<tsdgeos> or so apt-cache says
<tsdgeos>      1:0.1.46+14.04.20131129-0~873~ubuntu14.04.1+disabletests2 0
<tsdgeos>         500 http://ppa.launchpad.net/canonical-qt5-edgers/qt5-beta2/ubuntu/ trusty/main amd64 Packages
<tsdgeos> but it's pulling the wrong dependency :/
<greyback> tsdgeos: ah I see. Ignore me :)
<greyback> but based on the date, I might guess that package was made before the lib name changed to libqt5core5a
<tsdgeos> seems
<Mirv> tsdgeos: UI toolkit has a failing test when compiled, so it hasn't rebuilt yet. it's blocking continuing from there currently together with gsettings-qt.
<tsdgeos> ok :(
<Mirv> tsdgeos: see http://pad.ubuntu.com/qt52-dependencies for the approximate dependency chain
<Mirv> plus bug links
<Mirv> edits welcome to the pad
<Cimi> greyback, tried running my carousel shader branch again locally on the nexus 10, it ends with "terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<Cimi>   what():  could not activate surface with eglMakeCurrent"
<greyback> Cimi: often happens when backlight turned off. Hit the power button and try again
<Saviq> tsdgeos, jenkins *really* doesn't want to merge the horizontal journal, it doesn't look like it's random any more...
<Saviq> tsdgeos, QFATAL : qmltestrunner::Dash::test_dash_bar_set_index_connection(applications.scope) ASSERT: "modelIndex == m_asyncRequestedIndex" in file /tmp/buildd/unity8-7.84+14.04.20131220/plugins/DashViews/listviewwithpageheader.cpp, line 874
<Mirv> greyback: I'm testing that platform-api branch building and approving after that
<greyback> Mirv: ack
<Cimi> greyback, ok, tested
<Cimi> greyback, it's slower
<Cimi> but it's already slow in the normal use case
<Cimi> and this looks much better
<greyback> Cimi: I would argue that smoother is more important than looks
<greyback> Cimi: but let's have a third party make that call
<Cimi> greyback, it's already bloody slow
<Cimi> greyback, we might though want to keep this to test again when mir will be faster
<greyback> Cimi: making it slower isn't improving the situation then :)
<Cimi> greyback, so postpone the approve
<Cimi> greyback, I can try again using layers in qml but I ended up doing shader because layers wasn't working
<Cimi> there has been a regression though
<Cimi> when you open the preview, you see the carousel zoom popping in and out
<Cimi> I'll have a look later this afternoon, now off to the office + lunch
<greyback> Cimi: I'm not up on the specifics, I just got worried when I saw you using a shader on a visually large ShaderEffectItem as that's expensive. Hopefully there's an alternative approach
<Saviq> Cimi, layers are basically equal to using a shader in terms of GPU usage
<tsdgeos> Saviq: right, somehow hadn't see it
<tsdgeos> Saviq: thanks for the pointer
<tsdgeos> dandrader: i should not have listened to you asking for the assert :D
<tsdgeos> now i need to find out why it's asserting :D
<dandrader> tsdgeos, :D
<tsdgeos> Saviq: ok, so i'll leave the qml error now, knowing it does not happen with the non threaded scenegraph and we can't test 5.2 atm :/
<Saviq> tsdgeos, +1
<tsdgeos> mzanetti: ok, put the VM back into the pool i guess, we'll be back to it some other day
<tsdgeos> mzanetti: tx a log!
<tsdgeos> and a lot too!
<tsdgeos> :D
<mzanetti> :)
<mzanetti> tsdgeos: done. thanks
<tsdgeos> Mirv: fwiw i reported the gsettings-qt thing and is now fixed upstream, but i think it needs a string of fixes, so we're basically stuck waiting for 5.2.1 i'd say
<tsdgeos> Mirv: if you have spare cycles you can try adding https://codereview.qt-project.org/#change,74547
<kgunn> ricmm|sick: are we good for Cimi to put together the sidestage preview for design to play with ?
 * kgunn think |sick can't be good
<olli_> Cimi, re qmlscene, didn't work for me and qtcreator seems to heavy
<greyback> kgunn: we have this list of bugs: http://pad.ubuntu.com/qP0HD1BUn4 that we're working through
<olli_> kgunn, Saviq is qmlscene --desktop_file_hint=foo.desktop foo.qml how I should be able to launch an app from an adb shell, su - phablet?
<olli_> assuming that the files are in the same dir
<Saviq> olli_, you need a full path to the .desktop file
<olli_> ah
<olli_> that might explain the core dump
<Saviq> olli_, yeah, it aborts 'cause it's rejected by unity-mir, due to not finding the .desktop file
<kgunn> greyback: yeah, i know its not "finished"...but design needed to do some testing of some sort specifically for sidestage
<kgunn> so plan was to just provide them a snapshot of our branche
<kgunn> s
<greyback> kgunn: then it's basically functional
<ricmm> sorry, hadnt changed the name on freenode
 * kgunn relieved ricmm didn't relapse
<ricmm> kgunn: as it stands right now there arent any big functional bugs, except Mir screenshoting garbage sometimes
<ricmm> mostly just flickers
<olli_> Saviq, thx!
<kgunn> ricmm: cool...we can live with that (known bug & someones working)
<Saviq> olli_, cheers
<ricmm> the flickers and related ones come from feb/march
<ricmm> not necessarily new
<ricmm> Cimi: so its just the three branches, onto a fresh N10
<ricmm> prereqs have hit the archive
<ricmm> greyback: lets land platform-api and qtubuntu branches asap, agree?
<ricmm> greyback: set-dimensions ones
<greyback> ricmm: +1
<ricmm> can you do a review of each?
<ricmm> although we've built and rebuilt a billion times
<kgunn> greyback: ricmm ....so is what you're landing equivalent to "v2" or "v3" referred to in the sketchpad ?
<greyback> ricmm: in progress...
<ricmm> not landing anything unity-mir yet, will try to fix some of the flickers right now
<greyback> just need to pop to post office, back in 5
<ricmm> k np
<ricmm> kgunn: but cimi can flash latest of the three branches and it will work
<kgunn> thanks... ricmm can he just use your zip at people.canonical ?
<kgunn> or he needs to rebuild ?
<ricmm> its better if he builds his own
<ricmm> with the latest image
<ricmm> and creates his own deployable set of debs
<ricmm> takes about 15 min on a n10
<kgunn> Cimi: can you give sidestage a shot ? on tingting's manta
<Cimi> kgunn, sure
<Cimi> Saviq, if they are equal, I'd keep the shader then
<greyback> Saviq: oh idiot, bad timing for me to run to shop, sorry I missed standup
<Saviq> greyback, nw
<Saviq> greyback, just add your things to the doc if you have anything new to report
<tsdgeos> dandrader: ok, now i remember why the if is needed and why the assert has to go
<tsdgeos> dandrader: or maybe you prefer me to reflow the code
<tsdgeos> dandrader: let me explain
<dednick> Saviq: i just flashed device, but cmake isnt installed with run_on_device anymore? :/
<dandrader> tsdgeos, explain in a comment in the code, replacing that assert
<Cimi> ricmm, to build my own debs, I simply run dpkg-buildpackage on the device?
<tsdgeos> dandrader: ok
<ricmm> Cimi: build them as you usually build debs
<ricmm> first platform-api
<ricmm> then qtubuntu and unity-mir
<ricmm> whatever your preferred way is :)
<Cimi> ricmm, don't know any other way :) but there might be 100 different in debian world :)
<ricmm> dpkg-buildpackage it then
<ricmm> install deps first, a simple build-dep should do it
<Saviq> dednick, you probably have an old build-deps .deb on the device
<Saviq> dednick, drop unity8-build-deps*deb from shell/builddir
<tsdgeos> dandrader|lunch: comment added
<greyback> ricmm: happy to top-approve your papi and qtubuntu
<ricmm> go for it
<tsdgeos> mzanetti: Saviq: you guys going to do https://code.launchpad.net/~aacid/unity8/tabbar_dash ? Don't want it to get stale again, it's a bit of a pain to merge
<Saviq> mzanetti, will you?
<ricmm> greyback: you can probably approve both, qtubuntu will block on dep wait for 0.20 platform-api
<ricmm> I think, I no longer know how these things work
<ricmm> who pushes it and what not
<Saviq> tsdgeos, http://ubuntuone.com/7dAW1FaKYID6PTx0DnealB - the chevron got cut off
<tsdgeos> hmmm
<tsdgeos> let me see
<Cimi> Saviq, chevron == > ?
<Saviq> Cimi, yeah
<Cimi> Saviq, it's on the theme
<Saviq> Cimi, probably the wrong word to use
<Saviq> Cimi, that's tsdgeos's branch
<Cimi> Saviq, tsdgeos I can point you to the right piece in the sdk
<Saviq> Cimi, and it got cut off by the search input
<Saviq> Cimi, it's there, overlaid
<Cimi> Saviq, obviusly
<dednick> Saviq: having dependency problems with unity8-build-deps
<Cimi> Saviq, it's external to the button
<tsdgeos> Cimi: i know where it is, i remade the whole code and then the sdk guys remade it all again
<Saviq> Cimi, I think you misunderstand
<Cimi> button == the title of the current lens
<Cimi> ah ok
<Saviq> Cimi, it uses a tab-like header in there
<Cimi> ah ok, custom one
<greyback> ricmm: probably, was just worried that jenkins ci might override the approval before papi landed. Have approved, let's see what happens
<mzanetti> Saviq: tsdgeosack
<tsdgeos> Saviq: actually i don't think it's overlaid, at most it's "underlaid"
<Saviq> tsdgeos, it's overlaid by the text entry ;)
<tsdgeos> Saviq: yep
<tsdgeos> Saviq: i don't think there's a way to fix that
<tsdgeos> Saviq: well we could do something like what the old code did, but someone told me it was a bad idea :D
 * Saviq wonders who
<Saviq> tsdgeos, aah wait
<tsdgeos> Saviq: i.e. the old code took into account the width of the current label to decide if put the search bar on the right or not, which meant that depending on the title length you'd have it there or not
<tsdgeos> which is pretty weird if you ask me
<tsdgeos> now we're back to the simple "if it's wide enough it'll be there or not"
<tsdgeos> don't remember who i talked to regarding this tbh
<tsdgeos> may not be even in the company anymore :D
<Saviq> tsdgeos, think we could find out the longest label and base on that?
<Saviq> tsdgeos, or well... let's just say there needs to be at least 80 GU width?
<Saviq> tsdgeos, all labels need to fit in 40GUs to be visible on the phone
<Saviq> tsdgeos, and the search entry is 40GU wide
<Saviq> tsdgeos, so if we say it only goes to the side when > 80GU
<tsdgeos> that works
<tsdgeos> probably 90
<Saviq> tsdgeos, 80 is fine
<tsdgeos> ok
<tsdgeos> sure i think that's a saner decision
<Saviq> tsdgeos, only other thing I thought of (which is not sane) would be to find out the longest label
<Saviq> tsdgeos, so no, let's not
<tsdgeos> updated to 80
<mzanetti> tsdgeos: should the >80GU thing fix this? http://i.imgur.com/qxsMKRY.png
<tsdgeos> mzanetti: no
<tsdgeos> mzanetti: that's just unfortunate widths
<tsdgeos> ah no
<mzanetti> tsdgeos: could we fade it out so it doesn't look so cut off?
<tsdgeos> or yes
<tsdgeos> mzanetti: we could, but do we do that kind of fading anywhere?
<mzanetti> fair point
<mzanetti> tsdgeos: we do in the launcher
<tsdgeos> mzanetti: with text?
<mzanetti> sort of
<mzanetti> the icons
<mzanetti> if they don't fit they are are folded and faded out
<tsdgeos> right
<tsdgeos> but it's the whole icon
<tsdgeos> in here we'd need some effect that applies to say, the last gu of the right hand side of the tabbar
<mzanetti> yep
<tsdgeos> something like the BB10 phone does and Saviq said it sucks :D
<Saviq> ;D
<mzanetti> that's just Saviq and BBX
<mzanetti> anyways... I think we should ask jouni on this
 * mzanetti continues with the review
<tsdgeos> mzanetti: we can, it'd be something for the SDK probably i'd say
<mzanetti> I tend to agree
<Saviq> yup
<Saviq> tsdgeos, FTR, I said it sucked because it was overused, IMO
<tsdgeos> ok
<tsdgeos> i still like it
<mzanetti> tsdgeos: do you really need the dashContentListHolder ?
<tsdgeos> yes?
<tsdgeos> why wouldn't i?
<ricmm> tsdgeos: ping
<ricmm> re https://code.launchpad.net/~aacid/platform-api/papi.rules.typo/+merge/182354 that saviq re-pinged me about the other day
<ricmm> libplatform-api-headers is the right package to ship that on
<tsdgeos> mzanetti: i may be able to refactor the code not to, but as it stands now, yes i need it, what's your problem with it?
<tsdgeos> ricmm: ok, i'll put it in there
<mzanetti> tsdgeos: sorry... got confused
<mzanetti> all right
<mterry> I'm must be going crazy; neither of my devices are turning on
<tsdgeos> ricmm: https://code.launchpad.net/~aacid/platform-api/papi.rules.typo/+merge/182354 passed, you can now approve
<Saviq> mterry, no, they're just completely discharged
<Saviq> mterry, connect to a charger, leave them be for a half hour
<mterry> Saviq, I figured that, but it's been a while
<Saviq> mterry, sometimes they really take their time
<Saviq> mterry, IIRC I've actually had more luck connecting to a PC
<mterry> Saviq, maybe I just haven't waited long enough, yeah
<Saviq> mterry, /laptop
<ricmm> mterry: use the n10 charger for all
<ricmm> 2A juice makes the world a better place
<ricmm> shit
<olli_> how do I keep a column from rearanging it's cells when an image in a top cell (in a 2line column) goes to visible:false
<mzanetti> tsdgeos: made a few more small comments
<mzanetti> olli_: put the Image inside an Item
<mzanetti> olli_: or just change it's opacity instead of visible: false
<tsdgeos> mzanetti: answered your comments, tell me if i'm making any sense
<mzanetti> tsdgeos: but isn't the pageHeader property in GenericScopeView always pointing to the one instance we have?
<tsdgeos> mzanetti: ah yes
<tsdgeos> the pageHeader property points to the single one
<tsdgeos> not the pageHeader of ScopeListView inside GenericScopeView but the pageHeader of GenericScopeView
<tsdgeos> what you would prefer me doing?
<mzanetti> so I still think the two signals for headerHeight/SizeChanged are not needed
<mzanetti> and it could be just set from within GenericScopeView just like all the rest
<tsdgeos> ah
<tsdgeos> i see what you mean
<tsdgeos> sure
<tsdgeos> can do that
<mzanetti> please. the rest looks good to me
<mzanetti> tsdgeos: also, please do another check for warnings. for example: "GenericScopeView.qml:284: TypeError: Cannot read property 'category' of null"
<mzanetti> just noticed right now
<ricmm> tsdgeos: the file needs to install to /usr/include/ubuntu/application/
<ricmm> where it currently installs bsically, check on your local system where it lives
<tsdgeos> mzanetti: is this introduced by this?
<ricmm> if you just set the file it will install to the wrong loc
<tsdgeos> ricmm: ok
<tsdgeos> ricmm: honestly i'm going to abandon it and will let you guys fix it
<tsdgeos> makes no sense you telling me what to do
<tsdgeos> me doing it wrong
<tsdgeos> and then you telling me what to do agai
<ricmm> tsdgeos: change branch ownership to phablet-team
<mzanetti> :)
<mzanetti> seems it isnt
<tsdgeos> ricmm: done
<tsdgeos> ricmm: https://code.launchpad.net/~phablet-team/platform-api/papi.rules.typo
<tsdgeos> mzanetti: pushed
<ricmm> thanks
<tsdgeos> whaaat
<tsdgeos> the expand_expand test failed again ^_
<mzanetti> meh
<mzanetti> tsdgeos: :D wanna know why I told you the thing about the warnings?
<mzanetti> file:///home/mzanetti/Development/reviews/tabbar_dash/qml/Dash/GenericScopeView.qml:306: TypeError: Cannot set property 'y' of null
<mzanetti> file:///home/mzanetti/Development/reviews/tabbar_dash/qml/Dash/GenericScopeView.qml:302: TypeError: Cannot set property 'height' of null
<mzanetti> because I did exactly the same change here and got those two
<mzanetti> that tricked me into believing the others were your's too
<tsdgeos> well i changed that
<tsdgeos> maybe the tests needs adjusting?
<mzanetti> no... its not the tests. happens if you run it
<mzanetti> tsdgeos: your latest change just misses a if (scopeView.pageHeader)
<olli_> mzanetti, will try, thx
<tsdgeos> we don't really have one of those, but ok
<mzanetti> tsdgeos: ?
<mzanetti> yeah... actually a good question why this happens at all
<tsdgeos> ahhhhh
<tsdgeos> booo
<mzanetti> not sure we're talking the same language today :D
<tsdgeos> ok, test fixed
<mzanetti> thanks
<tsdgeos> the pageHeader has changed
<tsdgeos> so the thing that was looking for the pageheader in the fix i made this morning was wrong for this one
<tsdgeos> makes sense?
<tsdgeos> and that said, i have taxes stuff to do
<tsdgeos> so see you tomorrow
<dednick> eh...wtf is going on with mir and unity8? installing mir 0.1.3 removes unity8... ?
<dednick> all sorts of conflicts going on.
<dednick> Saviq: ping
<Saviq> dednick, pong
<dednick> Saviq: hey, there seems to be a problem with latest mir and unity8. when doing build deps for unity8, it's trying to get mir 0.1.3, but that conflicts with current unity8 so it cant...
<dednick> current installed ver of mir is 0.1.2, but it's trying to get 0.1.3 dev packages.
<dednick> this is presumably only a problem on a clean device...
<dednick> or if you do an apt upgrade.
<dednick> s/upgrade/update
<greyback> dednick: you may have to wait until this lands: https://code.launchpad.net/~ricmm/qtubuntu/papi-setdimensions/+merge/198498
<greyback> dednick: oh wait no, please ignore
<greyback> different issue, crossed brain wires
<Saviq> dednick, hmm, there is no mir 0.1.3 in distro yet https://launchpad.net/ubuntu/+source/mir
<Saviq> dednick, maybe you have daily-build PPA enabled?
<Saviq> dednick, and unity-mir still only requires 0.1.2 http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/view/head:/debian/control
<Saviq> dednick, the bump is only under review now https://code.launchpad.net/~kgunn72/unity-mir/mir-deb-bump-0.1.3/+merge/200349
<dednick> ah. damn. it's that stupid writable image phablet-config command
<Saviq> dednick, what's it do?
<dednick> Saviq: phablet-config writable-image --ppa ppa:ubuntu-unity/daily-build
<Saviq> dednick, ;)
<Saviq> dednick, apt-cache policy is always helpful to see where stuff comes from
<dednick> Saviq: thanks
<dednick> wasted half a day...
 * greyback eod
<apsassin_> hi all i was hoping somebody could help me figure out how to remove app labels from desktop icons?
<mterry_> So the edge demo got disabled somewhere down the line
<mterry_> Saviq, was that intentional? ^
<mterry_> kgunn, I thought the latest mir was supposed to have landed.  Do you know the ETA?
<kgunn> mterry_: most likely tomorrow....
<kgunn> mterry_: for once we were waiting on platform-api mp's to land first....
<mterry_> kgunn, ok
<kgunn> i know its actively being worked by Mirv
<mterry_> thanks
#ubuntu-unity 2014-01-08
<kdub> could anyone take a look over? https://code.launchpad.net/~kdub/platform-api/mir-deb-bump-0.1.3/+merge/200430
<kdub> should be pretty simple, just bumping ABI
<Akiva-Mobile> So I am thinking of contributing a feature to unity, patch and everything, about an idea that I just thought of. I'd like to pass the idea around here first
<Akiva-Mobile> Its actually pretty mundane and simple, and has to do with moving windows with the mouse
<Akiva-Mobile> When an application is full screen, and you go to the top screen bar, on the white space where no menu actions are currently situated, and then HoldLeftClick, you can move the window around
<Akiva-Mobile> I basically want to extend this function to when windows are not full screen
<Akiva-Mobile> One of the reasons why this is, is that I often find while using spaces, that my top menu bar is stuck on another virtual desktop
<Akiva-Mobile> and I thus have to switch workspaces, or press alt+click the window to drag down.
<RAOF> Hm. I was wondering where that was going; that's an actual use-case :)
<RAOF> On the other hand, might this not be better solved by ensuring that the top bar is always visible?
<Akiva-Mobile> RAOF: http://discourse.ubuntu.com/t/unity-five-suggestions-for-global-menu-bar-whitespace/1392 << sorry, library closed, and now im at the coffee shop :P. Anyways, I extended my suggestion to five
<Akiva-Mobile> RAOF: The top bar being always visible... how would the logic work with vertical spaces?
<RAOF> Akiva-Mobile: You'd just move the window down when you switched workspaces.
<Akiva-Mobile> RAOF: wouldnt that be annoying if you were trying to escape that application, and it just happened to slightly be leaking into the next workspace?
<Akiva-Mobile> RAOF: Gnome 3 doesnt have this issue though, does it...?
<RAOF> Akiva-Mobile: Yeah, that would be awkward I guess. GNOME 3 gets around this by not having workspaces in a coherent space.
<Akiva-Mobile> RAOF: If Gnome3 had HUD, I'd definitely consider using it.
<Akiva-Mobile> RAOF: Sorry again :P
<Akiva-Mobile> RAOF: I think my idea is reasonable, and it would be neat trying to get a patch accepted by the ubuntu project. Maybe then someone will hire me as a programmer once I have that on my mantle :)
<RAOF> :)
<RAOF> I'd give it a go.
<Akiva-Mobile> RAOF: Any suggestion what file to start looking into? Save myself some time~
<RAOF> Sorry, no.
<Akiva-Mobile> RAOF: I'll expose my ignorance here, but will I have to do this on mir?
<Akiva-Mobile> or will the code be transferable?
<RAOF> No; the Unity 8 codebase is entirely distinct.
<RAOF> There's not currently any window management in Unity 8 anyway :)
<Akiva-Mobile> RAOF: For mir, how much needs to be rewritten?
<RAOF> We're rewriting everything; using Qt5 rather than compiz, etc.
<Mirv> Saviq: FYI test failing https://bugs.launchpad.net/unity-scopes-shell/+bug/1267026
<ubot5> Ubuntu bug 1267026 in unity-scopes-shell "1 test failing resulting in FTBFS" [Critical,New]
<Saviq> mhr3, â
<Saviq> Mirv, the unity-api issue is tricky :/ in theory we've identified the commit where it got better, but that one commit wasn't enough
<Saviq> Mirv, it's working fine on the stable branch, after https://bugreports.qt-project.org/browse/QTBUG-35721 has been fixed
<tsdgeos> and the tabbar was merged, let's see all the complains :D
<Mirv> Saviq: is stable = upcoming 5.2.1? please don't say 5.3 :)
<tsdgeos> yes
<Mirv> ok, yes I'd be planning to get qtbase and qtdeclarative snapshots (or maybe just qtdeclarative for starters)
<tsdgeos> "Target for Qt 5.2.1 release is at the end of January \ early February."
<tsdgeos> http://lists.qt-project.org/pipermail/releasing/2013-December/001557.html
<Mirv> larsu: if you could check (or delegate) gsettings-qt bug #1259145 at some point, it would be nice. maybe some tests shouldn't be run under xvfb? SDK team might have encountered something similar earlier, also
<ubot5> bug 1259145 in gsettings-qt "gsettings-qt fails to build (run tests) against Qt 5.2" [Critical,New] https://launchpad.net/bugs/1259145
<tsdgeos> Mirv: as said i fixed that
<tsdgeos> it's nothing about xvfb
<tsdgeos> it's just that the test was failing
<larsu> Mirv: I already did, it's fixed in qt
<larsu> tsdgeos: thanks again for that :)
<tsdgeos> Mirv: i.e. the x error we get we were getting before (afaics)
<Mirv> tsdgeos: larsu: oh right I might be confused, there was the another bug report that was filed during RC1. the latest gsettings-qt build from 2012-12-19 failed still: https://launchpadlibrarian.net/160186213/buildlog_ubuntu-trusty-amd64.gsettings-qt_1%3A0.0%2B13.10.20130902.1-0~42.1~ubuntu14.04.1_FAILEDTOBUILD.txt.gz
<tsdgeos> Mirv: a recent enough snapshot of qtdeclarative stable branch should fix it
<Mirv> tsdgeos: aha, aha, so that's also one of those that needs newer qtdeclarative?
<tsdgeos> yes
<tsdgeos> they totally from QQmlPropertyMap in 5.2.0
<tsdgeos> it's far from salvageable
<Mirv> right, in that case that's the first priority now (well aside from my ir testing)
<tsdgeos> you need 5.2.1
<Mirv> Mir
<Mirv> thanks. I'll skip qtbase updating for now until there's a known need for a snapshot.
<Saviq> Mirv, so - we're targeting 5.2.1 then?
<Mirv> Saviq: we're targeting anything that can get all FTBFS:s fixed and image results as good as with 5.0.x. preferably it would have been 5.2.0 already.
<Saviq> Mirv, i.e. if stuff works with 5.2.1 but not 5.2.0, are we sad?
<Saviq> Mirv, yeah, that isn't working apparently :/
<Mirv> Saviq: I think it doesn't matter what we use, as long as we can use it without regressions and the 100 source packages all compile neatly against it and everything is full of flowers :)
<mhr3> :/ seen that bug already
<mhr3> it's some kind of race
<Mirv> I hope the qtdeclarative will resolve some of the build failures at https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+packages (gsettings-qt is one pre-requirement to move forward)
<Saviq> Mirv, so you're snapshotting qtdeclarative from the stable branch (5.2.1) now? awesome.
<Saviq> elopio_, crap, sorry for yanking the bottom bar out from under your feet... :/
<Saviq> elopio_, didn't know you were working on that emulator
<Saviq> elopio_, hopefully this new emulator will be able to use one from the sdk? is there an emulator for tabs in sdk already?
<Mirv> Saviq: yes
<Saviq> elopio_, ah, already done! ;)
<mhr3> Saviq, mind if we start the preview meeting 15minutes later?
<Saviq> mhr3, sure
<Saviq> mhr3, I don't
<mhr3> :) moving
<mzanetti> Saviq: hey, did you come to a conclusion regarding the qml in cmake?
<Saviq> mzanetti, I don't think I did ;)
<Saviq> mzanetti, /me looks at the branch
<mzanetti> Saviq: want me to summarize the possible options again?
<Saviq> mzanetti, no, I think the only last beef I had was moving it into src/ or something
<mhr3> Mirv, you can try to just rebuild, it might just work
<mzanetti> ah ok. yeah, gerry had the same opinion. I still think qml sources are sources too but I don't really mind as long as I don't have to open 2 project files all the time
<Mirv> mhr3: well we don't allow flaky tests anyway, so it wouldn't change much even if it would work. but it seems to have failed every time on armhf: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+builds?build_text=unity-scopes-shell&build_state=all
<Saviq> mzanetti, I think file(GLOB_RECURSE ../qml/*.qml ../qml/*.js) will do what you need
<mhr3> Mirv, seeing when it started happening actually helps, thx
<mzanetti> Saviq: ok. I'll change it
<Saviq> mzanetti, so leave qml/ be, and just do the GLOB again in src/
<mzanetti> Saviq: yep
<Saviq> mzanetti, and drop .qmlproject then, I think?
<mzanetti> yep
<Saviq> mzanetti, http://paste.ubuntu.com/6713876/
<Saviq> mzanetti, that works for me
<Saviq> mzanetti, might want to add .png / .svg etc.
<Saviq> mzanetti, stuff that qmlproject itself does :/
<Mirv> mhr3: ok, great, indeed there is a certain point
<mzanetti> Saviq: on a first thought I'd say that's not needed, given that we can't really do much with them in the IDE anyways. But I'm not opposed to it
<Saviq> mzanetti, you can view them at least
<Saviq> mzanetti, and see a list of them in the project explorer
<Saviq> mzanetti, which is useful
<mzanetti> ok
<Saviq> mzanetti, .png, .svg, .sci
<Saviq> mzanetti, and see if we have any other
<mzanetti> ack
<Saviq> mzanetti, http://paste.ubuntu.com/6713935/ is probably enough... after all we want all files from under qml/ to show up
<mzanetti> Saviq: true... any idea how to make the importPaths statement work?
<mzanetti> I tried this, but doesn't seem to work: add_definitions(-DQML_IMPORT_PATH=builddir/plugins:builddir/modules:builddir/tests/plugins:builddir/tests/utils/modules)
<Saviq> mzanetti, do we actually need that?
<mzanetti> its not totally essential. but for some plugins we'd get code completion
<Saviq> mzanetti, that's *if* QtCreator would actually honor that
<mzanetti> :D
<Saviq> mzanetti, which I doubt it would
<mzanetti> for qmake based projects apparently setting QML_IMPORT_PATH should work
<Mirv> Saviq: would you have some time to test qtdeclarative stable head compilation? at least when combined with our packaging + patches, I'm getting http://pastebin.ubuntu.com/6713954/ (git hash used is there in the directory)
<Saviq> Mirv, sure, sec
<Mirv> this is with normal qt 5.2.0 otherwise (qtbase + qtxmlpatterns)
<Saviq> Mirv, I imagine this says "you need newer qtbase"
<Mirv> Saviq: I wish even stable branch would be safe from the interdependencies :)
<Mirv> but sure, I wouldn't be surprised. the referrals failing are to qtdeclarative's own sources, but maybe something in qtbase changed about finding sources.
<mzanetti> Saviq: https://code.launchpad.net/~mzanetti/unity8/qml-in-cmake-take2/+merge/200793
<mzanetti> thanks :)
<Saviq> mzanetti, still not using colocated branches, btw? ;)
<mzanetti> nope
<mzanetti> but my disk space would appreciate it I guess
<Saviq> Mirv, actually
<Saviq> Mirv, qtdeclarative compiled fine here
<Saviq> Mirv, clean chroot with qt5-beta2
<mzanetti> Saviq: where did you get the plugin from?
<Saviq> mzanetti, lp:~fboucault/bzr-colo/colo-push/ for some reason
<Saviq> mzanetti, but lp:bzr-colo is probably a better source
<dandrader> tsdgeos, about the horizontalJournal Q_ASSERt
<dandrader> tsdgeos, I thought that the signal would only be emitted if the operation was async
<tsdgeos> nope
<dandrader> therefore that slot would only be called in the async case
<mhr3> Saviq, you in a call already?
<Saviq> mhr3, no
<tsdgeos> dandrader: nope
<tsdgeos> dandrader: which Q_ASSERT in horizontalJournal ?
<tsdgeos> ignore me
<tsdgeos> can't read
<tsdgeos> ok
<tsdgeos> :D
<dednick> is s-jenkins down?
<mzanetti> dednick: works for me
<dednick> mh.
<dandrader> tsdgeos, that one in itemCreated slot
<tsdgeos> yes yes
<dednick> stupid dns thing again... sigh
<tsdgeos> dandrader: was lost in the way you built the sentence and how my brain read it
 * mzanetti wishes we could wake up the screen by double tapping it
<Mirv> Saviq: hrm!
<dednick> mzanetti: any idea? https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/832/console
<mzanetti> dednick: I've seen the same in one of my branches. So far I hoped it's temporary woes... seems not :/
<mzanetti> Saviq: ^ ?
<Saviq> hmmmpf
<mhr3> isn't that debian saying "you really need to bump the version"?
<Saviq> mzanetti, why does qmluitests build the package at all?
<Saviq> mhr3, yeah it kind of is
<Saviq> mhr3, but why would it suddenly start now?
<Saviq> TBH I never understood when dpkg starts complaining about that
<mhr3> error: ...  binary file contents changed
<mzanetti> Saviq: we've always built the package for qmltests
<Saviq> mhr3, ah, so you're saying it doesn't care until you change a binary file?
<mhr3> Saviq, i'm no debian pro, but seems that way
<Saviq> interesting...
<dednick> wtf. my character map just changed, but it's still showing correct layout in region settings
<Saviq> mzanetti, so what we're missing probably is bumping the version before building the package
<Saviq> mzanetti, but why do we build the package at all?
<mzanetti> Saviq: that was the most straight forward way to get it done in jenkins
<dednick> funny thing is, i only have uk english installed... weird
<Saviq> mzanetti, but that doesn't build the mocks etc. does it?
<mzanetti> Saviq: sure it does. it's installed into the unity8-fake-env package
<Saviq> mzanetti, I'm not sure that's true - not for *all* the mocks at least
<Saviq> mzanetti, anyway
<mzanetti> hmm, ok. I might miss something
<Saviq> mzanetti, do you have access to the job?
<mzanetti> yes, I do
<Saviq> mzanetti, the pbuilderjenkins command
<Saviq> mzanetti, doesn't use the hooks as defined in the job
<Saviq> mzanetti, if that's on purpose, add H05set_package_version there and we should be good
<mzanetti> Saviq: added
<Saviq> mzanetti, dednick restarted the job, will be at http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-trusty/834
<mzanetti> dednick: I restarted your job. lets see what happens
<mzanetti> oh
<dednick> ta
<mzanetti> looks better, yes
<mzanetti> Saviq: I've changed the job to inherit hooks from upstream jobs and just add the B09qmltests etc
<Saviq> mzanetti, yup
<mzanetti> lets hope I didn't break it. You'll know where to find me in that case
<Saviq> mzanetti, I DO KNOW WHERE TO FIND YOU!
<mzanetti> :D
 * mzanetti hides
<Saviq> mzanetti, http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-trusty/834/console
<Saviq> Started by user Saviq
<Saviq> Started by user mzanetti
<Saviq> interesting ;D
<Saviq> must be we triggered the exact same configuration and jenkins combined that into one
<mzanetti> heh
<mzanetti> I'd rather bet on a bug in jenkins :D
<Saviq> /food
<Saviq> tsdgeos, hJournal ready for merging or are you searching for the assert?
<tsdgeos> Saviq: ready for merging
<tsdgeos> i forgot to check the failure and reapprove
<Saviq> tsdgeos, k
<tsdgeos> test_show_hud_button_appears ?
<tsdgeos> weird
<tsdgeos> let's see next run
<Saviq> tsdgeos, yeah, it does fail sometimes
<Mirv> Saviq: one of these days I learn to attribute all mysterious immediate failures to syncqt when snapshot builds don't work
<mzanetti> deleting the hud-service binary wasn't such a good idea :/
<Saviq> Mirv, ;)
<Saviq> mzanetti, btw, we've missed ../tests/*qml ../tests/*js :/
<mzanetti> Saviq: true. I'll fix
<tsdgeos> kgunn: you increased the dependency of unity-mir to mir* 0.1.3 but that's still not out, no?
<tsdgeos> greyback: ok, https://code.launchpad.net/~aacid/unity-mir/application_manager_tests/+merge/180898 should be ready
<tsdgeos> CI is failing to compile because the âââ change
<greyback> tsdgeos: \o/ thanks!!
<tsdgeos> if you want to try now in the phone
<tsdgeos> just do
<tsdgeos> -               libmirserver-dev (>= 0.1.3),
<tsdgeos> -               libmirclient-dev (>= 0.1.3),
<tsdgeos> +               libmirserver-dev (>= 0.1.2),
<tsdgeos> +               libmirclient-dev (>= 0.1.2),
<tsdgeos> on the control file
<tsdgeos> it worked for me
<greyback> tsdgeos: ok
<elopio_> Saviq: I was trying to use the tab bar from ubuntu ui toolkit, but it causes a couple of problems. The biggest is that when trying to open the files & folders scope, it tries to click on the right border of the screen and nothing happens there.
<elopio_> I need to make a workaround on the toolkit emulator before it's usable by unity.
<kgunn> tsdgeos: yes...release team is testing new mir, so they had to approve and push the bump
<kgunn> it should be over soon (and hopefully mir out soon)
<tsdgeos> great
<tsdgeos> ;)
<Saviq> elopio, ack
<elopio> Saviq: but I need help from my branch, on mako there are failures that don't seem related to my branch. I was hoping to find aacid here today.
<Saviq> elopio, tsdgeos === aacid
<Saviq> he's crypto, we know
<Saviq> ;)
 * tsdgeos hides behind his nicks
<tsdgeos> elopio: need help?
<tsdgeos> Saviq: remember we talked about the "Please enter SIM PIN" text a while ago?
<Saviq> tsdgeos, not really, wassup?
<tsdgeos> Saviq: basically you said "it should come from the indicator"
<tsdgeos> but it's still there
<elopio> tsdgeos: \o/ I found you!
<Saviq> tsdgeos, right
<elopio> let me get something to drink and wake up a little, and I'll start bothering you :)
<Saviq> tsdgeos, file a bug please?
<tsdgeos> Saviq: shall i open a bug or something so someone maybe acts on it
<Saviq> tsdgeos, â that
<tsdgeos> Saviq: against what? unity8? or?
<Saviq> tsdgeos, affects unity8 and indicator-network
<tsdgeos> okidoki
<tsdgeos> man i ate too much of my fake chocolate cava bottle :D :( :-S
 * mzanetti googles chocolate cava bottle
<tsdgeos> http://www.badamelos.com/1177-large_default/botellas-cava-benjamin-chocolate.jpg
<tsdgeos> mzanetti: ââ
<mzanetti> lol
<mzanetti> leftover from new years eve?
<tsdgeos> yep
<Saviq> greyback, mterry_, standup
<greyback> mzanetti: thanks :) When I reboot, or suspend/resume, PA thinks sound is at the usual place, but is actually 0. If I wiggle the mic volume, it then works
<mzanetti> greyback: yeah... try a "asoundctl store" with non-muted settings
<tsdgeos> Saviq: https://bugs.launchpad.net/indicator-network/+bug/1267135
<ubot5> Ubuntu bug 1267135 in Unity 8 "network-indicator should provide the "Please enter SIM PIN" text" [Undecided,New]
<elopio> I'm back. tsdgeos, please let me know when you have some time, it seems I'll need more help than what I thought.
<tsdgeos> elopio: now is a good moment
<elopio> tsdgeos: the dashContentList has a currentIndex property. My problem is that the QQuickLoader and the GenericScopeViews don't have an index.
<elopio> so I have no way to tell which is the currently selected scope.
<elopio> I was assuming that the order of the list would give me the right index, but on mako where the music scope is to the left, my assumption breaks.
<tsdgeos> elopio: the current scope is the one of the currentIndex?
<tsdgeos> dashContent.model list the order of them
<tsdgeos> which is actually the list of visible scopes
<tsdgeos> as returned by Scopes
<elopio> let me see if autopilot can access that.
<tsdgeos> elopio: what do you want to find out actually? name? or something else?
<elopio> tsdgeos: well, what I need is a way to know what's the index of a scope. On the toolkit tabs I had the same problem, and they fixed it adding the a new tabIndex property to every tab.
<tsdgeos> elopio: as said the index of a scope is it's index in the list of visible scopes
<tsdgeos> i.e. whatever is sorting scopes it's not the ui
<elopio> tsdgeos: right. The problem seems to be that the list of scopes returned by autopilot is not on the same order.
<elopio> (Pdb) p self.dash.dash_content_list.currentIndex
<elopio> 1
<elopio> (Pdb) p self.scope_loaders[1].scopeId
<elopio> u'music.scope'
<elopio> there's the problem, because the selected scope at this moment is 'home.scope'
<elopio> so we shouldn't rely on the order of elements that autopilot returns.
<tsdgeos> what's scope_loaders ?
<tsdgeos> i.e. who provides that info?
<tsdgeos> and is self.scope_loaders[0] marked as visible or not?
<elopio> tsdgeos: self.scope_loaders = self.dash.dash_content_list.select_many('QQuickLoader')
<tsdgeos> ok
<elopio> tsdgeos: and all of them always have visible=True, we can't rely on the visible property.
<tsdgeos> so select_many is not giving you stuff in the corect order
<elopio> (Pdb) p self.scope_loaders[1].visible
<elopio> True
<elopio> (Pdb) p self.scope_loaders[0].visible
<elopio> True
<tsdgeos> which given the name seems even reasonable
<elopio> yes. But according to thomi, autopilot just returns the elements on the same order of the QML tree it sees.
<elopio> as we have seen before, and now again, it seems a bad idea to rely on the order of the elements of the tree.
<tsdgeos> so again, what do you need?
<tsdgeos> know the current scope?
<tsdgeos> maybe match it against the name of the selected tab?
<tsdgeos> or that is what you're trying to test?
<elopio> tsdgeos: not just know the current scope, I could use the isCurrent property for that.
<elopio> I need to know the order of them, so I scroll to the left if the index I need is lower than the currently selected one, and scroll to the right if the index is higher.
<tsdgeos> well then you can use the tabs?
<tsdgeos> i think the tabs has getters
<tsdgeos> let me see
<tsdgeos> maybe not
<elopio> tsdgeos: I found the bug and branch for the same problem on the toolkit:
<elopio> https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1233402
<ubot5> Ubuntu bug 1233402 in Ubuntu UI Toolkit "The Tab needs a tabIndex property" [Critical,Fix released]
<tsdgeos> booo
<tsdgeos> ok
<tsdgeos> :D
<elopio> tsdgeos: I could use the tabs instead of scrolling, but first I need to implement some changes on its emulator.
<tsdgeos> elopio: so you want to do the change by swiping i guess, it's not ok that we add a switchToScope function
<elopio> tsdgeos: sorry, I didn't get that last part.
<tsdgeos> elopio: Dash.qml has a "function setCurrentScope"
<tsdgeos> can you use that?
<elopio> tsdgeos: no, with autopilot it all should be black box.
<tsdgeos> or you want to trigger the change "emulating the user touch presses"?
<tsdgeos> ok
<elopio> I need to set the current scope only using the pointer.
<tsdgeos> does autopilot know how to query models?
<tsdgeos> if so i think that querying filteredScopes would be useful to get the order of things
<tsdgeos> if not, someone should make autopilot able to introspect the models :D
<elopio> tsdgeos: I think that's not possible. That's information that QML doesn't expose through the testability feature, that's what autopilot uses.
<elopio> tsdgeos: but if you look at zsombi's branch: https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/tab-index/+merge/188769
<elopio> it doesn't seem like a big change on the model
<elopio> I don't know enough QML to do it myself on this case, though.
<mzanetti> greyback: could we sort the appmanager model in a way that the focused one is at index 0?
<tsdgeos> elopio: i'm understanding you can't access the attached properties of the listview deleagtes, no?
<tsdgeos> elopio: i.e. i can use "index" inside a QML listview item
<tsdgeos> and it'll give me the index
<elopio> tsdgeos: I can access things like isCurrent and scopeId, but no, index doesn't seem to be available.
<elopio> tsdgeos: have you used autopilot vis?
<greyback> mzanetti: that should be the case already
<tsdgeos> i used it once when all the stars aligned
<elopio> it shows the QML tree as autopilot sees it. So those are the only things we can use.
<mzanetti> greyback: seems not...
<tsdgeos> errrrr, is everybody getting the tabs to show in unity8?
<mzanetti> greyback: the first app I launch is always at 0
<greyback> mzanetti: but I don't see the code to do it either
<tsdgeos> they don't show here :-S
 * tsdgeos does a clean build
<greyback> mzanetti: suspect unity8 doing it
<elopio> tsdgeos: I can see them. They work nicely here.
<mzanetti> gnaaa
<mzanetti> greyback: ok... I'll try to change it in my screenshotting-focusing branch
<greyback> mzanetti: no objection here
<tsdgeos> ok, tabs are here now, maybe needed a clean build
<tsdgeos> elopio: let me try to run the visualizer
<elopio> thanks tsdgeos. Take a look at the TabBar inside the PageHeader. It has a selectedIndex property. And then the AbstractButtons children of that TabBar have a buttonIndex property.
<elopio> that's what I need. With those properties, I don't need to rely on the order of the children as autopilot sees them.
<tsdgeos> sure
<tsdgeos> adding the property is trivial
<tsdgeos> it's just that i'd prefer not to add extra code just for the testing
<tsdgeos> elopio: maybe you can use the "x" property of the loaders to sort them?
<elopio> tsdgeos: I could use that. Let me try to see if it gets ugly.
<elopio> tsdgeos: that will work nicely :) thank you.
<elopio> when is your EOD?
<tsdgeos> cool \o/
<tsdgeos> in 1:10h aprox
<tsdgeos> 6pm spain time
<elopio> tsdgeos: I have a meeting now, so I probably won't be able to finish my branch by then. Can you please take a look tomorrow?
<elopio> https://code.launchpad.net/~elopio/unity8/open_scope/+merge/200426
<tsdgeos> sure
<tsdgeos> Saviq: so i was thinking about the organic grid for the Dash vs the one in the gallery. Ours is always visible in full width and is designed to scrolls vertically while the one in the gallery is always full height and designed to scroll horizontally. That's not a radical problem, but introduces a few else/ifs here and there, want me to code directly for both or just catter our needs at first stage and improve later?
<kgunn> mterry_: ping
<mterry_> kgunn, hello
<kgunn> mterry_: hey hope you're feeling better....
<kgunn> got a question for you that i should already know :)
<mterry_> kgunn, OK
<kgunn> so i was cleaning up some wiki stuff....for unity8
<kgunn> and greeter section referenced
<kgunn> https://launchpad.net/unity-greeter
<kgunn> but isn't the greeter in unity8 now ?
<kgunn> mterry_: ^
<mterry_> kgunn, yes.  The phablet greeter is in unity8
<mterry_> kgunn, unity-greeter is the old greeter
<mterry_> "old"
<kgunn> mterry_: ok...that's what i tho
<kgunn> t
<kgunn> mterry_: so even after you land the split...it'll still be the phablet greeter in use right ?
<mterry_> kgunn, yes
<kgunn> mterry_: thanks...i'll make it match
<mterry_> kgunn, same source package (unity8) but new binary package (unity8-greeter)
<kgunn> ;)
<kgunn> mterry_: curious...why is it delivered in a bin like that ?
<kgunn> at least the unity-greeter
<mterry_> kgunn, I don't follow
<kgunn> oh nvmd...i see...
<kgunn> mterry_: ignore me
<mhall119> Saviq: has there been any progress on building Unity 8 on Saucy?
<Saviq> mhall119, there's more data on the failures, so hopefully it'll get better soon
<greyback> fginther: hey, can I book some CI expert time for unity-mir. We've a branch that adds tests, which must run in an environment where Mir can execute. We need a hand to set up CI to deal with that
<fginther> greyback, I can help but I'll need to get back to you later, I have some fires to put out
<greyback> fginther: sure, it's far from urgent
<karni_> Saviq: If there are any conventions on the team I didn't follow, just lemme know :) https://code.launchpad.net/~unity-team/unity8/new-scopes-horizontal-card-layout/+merge/200910
<Saviq> karni, cheers
<Saviq> karni, jest juÅ¼ test "test_art_size_data"
<Saviq> ooh english ;)
<Saviq> karni, there's already test_art_size_data
 * karni paczy ;D
<Saviq> karni, would make sense to build test_art_image_size into it
<Saviq> karni, "card-size": "medium" is unsupported (and ignored, for that matter) in horizontal layout - not sure we should test that... or maybe we should, but add a "small" one, too
<karni> Saviq: oh okay. I needed any size, I can replace that with small, as all sizes are covered in previous tests, right?
<Saviq> karni, why did you need a size?
<Saviq> karni, what I mean is: in horizontal layout, the card-size setting is ignored - so we should either test that setting it doesn't matter, or not set it at all
<karni> Saviq: I looked at the code, seems I could have gone with the default
<karni> Saviq: I'll remove that, yes
<Saviq> karni, for test_card_horizontal_layout, you're only checking for width, so integrating into test_card_size should work
<karni> Saviq: I think I wanted it to test the width/height of the artImage, but we decided that need not to be tested
<karni> Saviq: agreed on first and last comment, too. fixing.
<Saviq> karni, I'd rename test_*_anchors into test_*_layout, as we're not actually checking the anchors
<karni> Saviq: agree :)
<Saviq> karni, and now... .left/right/top/bottom are anchor lines
<Saviq> karni, not pixel values
<Saviq> karni, so test_header_anchors should actually fail
 * karni looks
<karni> Saviq: the last test? I'm not actually using anchors, the test name was confusing.
<Saviq> karni, that's the thing - you are ;)
<karni> let me do the art test refactor, and I'll push, so we're on the same page :)
<Saviq> karni, header.top, header.left are anchor lines (not anchors, but something that can be attach to anchors)
<Saviq> or something that anchors can attach to
 * karni nods
<Saviq> karni, so in the last test you're comparing header.top to art.bottom, for example
<karni> may have gone blindfolded a bit
<karni> +            top: template && template["card-layout"] === "horizontal" ? artShape.top : artShape.bottom
<Saviq> karni, that's header.anchors.top, not header.top
<Saviq> which are two distinct anchor lines - what I mean is that if you revert the changes to Card.qml, the test will still pass (assuming it passes now)
<karni> ooooh right!
<karni> Saviq: lemme fix that :) thanks for the super fast review :D
<Saviq> karni, so yeah, you can't compare anchor lines of different objects
<Saviq> karni, so you should look at x/y/width/height instead
<Saviq> adding where necessary
<karni> yes, all tests pass, but I obviously failed there with that anchor bit
<Saviq> karni, shelve changes to qml/ and run your tests suite again - make sure that all tests that should fail - do
<karni> Saviq: regarding your first/second comment about integrating test_art_image_size into test_art_size, I'd have to name properties like "imageWidth" and "imageHeight" because most of test_art_size concerns art, while I'm testing artImage
<karni> So.. does it in fact make sense to pull this test into test_art_size?
<karni> test_art_size tests width/height of testCase.art, while test_art_image_size tests width/height of testCase.artImage
<karni> (FWIW, bit confusing terminology ;D)
<karni> good suggestion. it did feel weird to write tests after the code ;D
<Saviq> karni, I know, sorry for that ;)
<Saviq> karni, was easier to write the code than tests ;D
<karni> Saviq: no worries, I know how fun it is to improve/fix things :D
<karni> haha, happy I can help (and learn!)
<Saviq> karni, you shouldn't be testing artImage's size at all, as that component isn't even visible - the UbuntuShape around it is what we care for
<karni> Saviq: may have gone overboard trying to cover every line of your code ;D
<Saviq> karni, so yeah, there's only one additional entry to test_card_size_data that should be added
<karni> Saviq: yes, fixed that
<Saviq> karni, yeah, coverage for QML (or UI, for that matter) is unfortunately an arbitrary thing
<karni> haven't pushed yet, want to fix those anchors/pixels thing you noticed
<Saviq> karni, cheers
<karni> :)
<karni> Thank you!
<Saviq> karni, aren't you past EOD yourself, btw?
<karni> Saviq: You working from Poland?
<Saviq> karni, we're not talking about me here, are we now :P
<karni> Saviq: I wonder, why would you ask hahahahah
 * karni laughs
 * Saviq â food
<Saviq> karni, just leave it here if you have more, will reply when around the keyboard later
<karni> Saviq: thanks! :)
<karni> Saviq: updated the MP. Left one 'XXX', can't get that line in test_header_layout to pass. I'll get something to eat and will try the shelves that you suggested to make sure stuff would fail where it should.
<Saviq> karni, a) test_art_layout is bad, tryCompare takes three arguments: object, propertyName, timeout
<Saviq> so tryCompare(testCase.header.x, data.headerLeft, data.value); is bad
<Saviq> not to mention data.headerLeft and data.value are undefined
<Saviq> karni, as for the other thing... the problem is that the card is laid out only when the test is executed, the _data() function is called before that, on the default layout, so art.width is 148 then, but when you select index 5, it becomes 80
<Saviq> but data.left is already evaluated with 148, so the test fails
<Saviq> karni, http://paste.ubuntu.com/6717510/ fixes
<Saviq> karni, actually make that http://paste.ubuntu.com/6717513/
<karni> Saviq: wow.. I'm surprized I wasn't thrown at that .headerLeft was not defined (I did change the name, missed that one). and tests still passed. not reassuring :(
<karni> Saviq: fixed along your diff, appreciated https://code.launchpad.net/~unity-team/unity8/new-scopes-horizontal-card-layout/+merge/200910
#ubuntu-unity 2014-01-09
<mzanetti> Saviq: o/
<mzanetti> https://code.launchpad.net/~mzanetti/unity8/tests-qml-in-cmake/+merge/200872
<Saviq> mzanetti, yup, saw that
<Saviq> mzanetti, there's images in there, too, shall we go for /tests/qmltests/* as well?
<Saviq> mzanetti, or explicit .png, .svg, .sci?
<Saviq> Mirv, just tried to build unity-api i386 in a local sbuild with the latest qtdeclarative - it worked fine, so thumbs up!
<Saviq> mzanetti, could you look at https://code.launchpad.net/~unity-team/unity8/new-scopes-horizontal-card-layout/+merge/200910 - I've put too much of my hands into that for a clean-conscience review ;)
<mzanetti> Saviq: ack
<mzanetti> Saviq: updated the other one btw
<Saviq> mzanetti, cheers
<mzanetti> Saviq: I went for * to be in line with the qml dir
<Saviq> mzanetti, uh oh I don't think that's gonna work
<Saviq> mzanetti, you just added all the mocks' .h and .cpp to the unity8 executable
<mzanetti> oh crap. you're right
<Saviq> mzanetti, that's why I said tests/qmltests/*, but tests/*.qml, tests/*.js
<mzanetti> yeah, makes sense
<tsdgeos> ouch
<tsdgeos> our ci is looking too red http://s-jenkins.ubuntu-ci:8080/job/unity8-ci/
<Saviq> tsdgeos, indeed :/
<tsdgeos> too much autopilot failures it seems
<tsdgeos> Saviq: that thing is conflicting, no?
<Saviq> tsdgeos, "that thing"?
<tsdgeos> Saviq: new-scopes-horizontal-card-layout
<Saviq> tsdgeos, yeah just saw
<Saviq> interesting
<tsdgeos> Saviq: but i see the CI was from an old rev
<tsdgeos> so the two new revs maybe fix it
<Mirv> Saviq: yeah, unity-api seems good now! so it's a definite improvement, but gsettings-qt is still blocking progress from here (to eg. a point where Unity would need to be uninstalled when upgrading to Qt 5.2)
<Saviq> tsdgeos, well, I manually launched ci for it, and it's not going into lp:unity8 directly but in the new-scopes branch
<Saviq> tsdgeos, so that might be why
<Saviq> Mirv, :/
<Mirv> Saviq: I needed to force Qt Declarative version number to 5.2.0 from 5.2.1, since otherwise CMake would error out on incompatible versions. I hope this system works.
<tsdgeos> Mirv: gsettings-qt is failing even with "qtdeclarative stable branch"?
<Mirv> tsdgeos: yes
<tsdgeos> weird
<tsdgeos> Mirv: what's the error?
<tsdgeos> still that xvfb thing?
<Mirv> tsdgeos: still that. bug #1259145
<ubot5> bug 1259145 in gsettings-qt "gsettings-qt fails to build (run tests) against Qt 5.2" [Critical,Confirmed] https://launchpad.net/bugs/1259145
<Saviq> mzanetti, does qmluitests have lp:unity8 hardcoded somewhere?
<Saviq> mzanetti, could it use target_branch instead?
<Saviq> mzanetti, seems that's where the failure in https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/850/console comes from - it's merging lp:unity8 into it instead of the new-scopes branch
<tsdgeos> Mirv: maybe indeed it's the "can't access X" thing and not the problem with qqmlpropertymap that is causing that, tests pass locally here in my machine
<tsdgeos> but indeed i do have X around
<tsdgeos> :D
<Mirv> the builders don't have, although they should have xvfb (but no 3d acceleration) - like I mention in the bug report, I have a vague memory SDK team battled with something similar in ubuntu-ui-toolkit
<tsdgeos> for 5.2? or in the beginning?
<tsdgeos> i mean why would have this changed in 5.2?
<tsdgeos> besides because "everything broke" :D
<Mirv> tsdgeos: around 5.2, like when they were testing building against RC1
<tsdgeos> i see
<tsdgeos> then it may very well be yeah
<mzanetti> Saviq: fixed
<mzanetti> ci, that is ^^
<tsdgeos> Mirv: can you test this patch? http://paste.ubuntu.com/6719664/
<tsdgeos> Mirv: or you prefer me to get it into gsettings-qt ?
<tsdgeos> Mirv: i can reproduce the error if no X is avaiable here and this patch fixes it
<tsdgeos> larsu: ââââ ?
<Mirv> tsdgeos: that would make sense, since the QA team adding tests into Qt modules is using QT_QPA_PLATFORM=minimal as well
<Mirv> I can test in a PPA
<larsu> tsdgeos: sounds sane to me
<tsdgeos> larsu: Mirv: so want me to propose the merge first or first check the patch in a ppa quick?
<Saviq> mzanetti, thanks
<larsu> tsdgeos, Mirv: I don't care. This looks like a good idea in any case so feel free to propose the merge
<Saviq> chain reaction of cats scaring themselves and each other... plus hardfloors... priceless
<Mirv> tsdgeos: building now https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-daily/+sourcepub/3808316/+listing-archive-extra
<Mirv> seems good now
<tsdgeos> \o/
<tsdgeos> larsu: Mirv: https://code.launchpad.net/~aacid/gsettings-qt/use_minimal_qpa_for_test/+merge/200971
<tsdgeos> can anyone remind me how i run autopilot manually in a unity8 builddir?
<tsdgeos> Saviq: mzanetti: ââ
<Saviq> nope
<mzanetti> now he's gone
<tsdgeos> oh man, running autopilot killed my X :-S
<tsdgeos> if i disappear again
<tsdgeos> you know why
<tsdgeos> i'm doing something very wrong or we don't support running the tests on the desktop?
<tsdgeos> Ran 52 tests in 112.281s
<tsdgeos> FAILED (failures=46)
<tsdgeos> Saviq: your input needed at https://bugs.launchpad.net/unity8/+bug/1267135
<ubot5> Ubuntu bug 1267135 in Network Menu "network-indicator should provide the "Please enter SIM PIN" text" [Undecided,Incomplete]
<Saviq> tsdgeos, done
<Saviq> tsdgeos, you need to make -C builddir install first
<tsdgeos> Saviq: hmmmmmm, looking at the text it may not even be "correct"
<Saviq> tsdgeos, and then PYTHONPATH=tests/autopilot autopilot list unity8
<tsdgeos> or maybe it is
<Saviq> tsdgeos, sure, but that's orthogonal to the fact that unity8 should have no knowledge of those strings
<Saviq> tsdgeos, that will list you the tests, s/list/run/ will run them
<tsdgeos> agreed
<tsdgeos> just saying that maybe is just some placeholder
<tsdgeos> ok, let me see
<tsdgeos> see about the autopilot, not about the text :D
<tsdgeos> Saviq: i guess we should document that PYTHONPATH stuff somewhere
<tsdgeos> i'll forget to the next time :D
<Saviq> tsdgeos, you should do more python, you won't forget then ;)
<tsdgeos> oh no
<tsdgeos> i know about PYTHONPATH
<tsdgeos> it's just about the whole lot
<tsdgeos> of installing
<tsdgeos> and bla bla
<tsdgeos> larsu: Mirv: top-approve? https://code.launchpad.net/~aacid/gsettings-qt/use_minimal_qpa_for_test/+merge/200971
<larsu> tsdgeos: ah sorry. Done.
<Cimi> seb128, https://code.launchpad.net/~unity-team/ubuntu-system-settings/welcome-wizard/+merge/186862 :)
<Mirv> yeah I thought to give the top-approve honor to lar_su
<seb128> Cimi, it's on my list, quite some backlog after holidays
<Cimi> seb128, good it's on your list
<Cimi> seb128, let me know when you're planning to review it
<seb128> Cimi, and we had to spend time fixing ubuntu-themes issues, since you don't do it, which means less cycles for reviews...
<Cimi> seb128, in case I'll branch and propose something dependent on it
<seb128> Cimi, if you were doing your job I could be reviewing that...
<Cimi> seb128, I am doing my job
<larsu> Mirv: thanks :) I feel honored!
<seb128> Cimi, the theme bug larsu fixed yesterday were assigned to you since novembre and you didn't act on them
<Cimi> seb128, because we have other priorities
<Cimi> it's not the only bug I have assigned and I didn't act yet
<seb128> k
<seb128> well, anyway, the wizard in on my todolist
<seb128> I'm going to try to get to it today
<Cimi> seb128, good!!
<Cimi> seb128, I'll work on add the wifi page correctly
<seb128> great
<Cimi> seb128, btw
<Cimi> seb128, I saw marco's work on the css decorations
<Cimi> seb128, it looks really cool and no more aliased corners :)
<Cimi> seb128, he stayed at mine for the new years eve
<Cimi> and was working on that!
<seb128> you crazy Italians ;-)
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/coding_autopilot_docu/+merge/200974 ?
<Saviq> tsdgeos, we also have a "make -C builddir autopilot" target, could you check out whether it works - and if not - see why?
<tsdgeos> sure
<tsdgeos> Saviq: nah, nope working
<tsdgeos> checking why
<tsdgeos> funny thing is that with ninja it works
<tsdgeos> Saviq: bascially it seems "it can't be done"
<tsdgeos> install is not a target you can depend on in cmake
<tsdgeos> if you're using make
<tsdgeos> for some reason
<Saviq> tsdgeos, we can have a custom target that will run cmake --build --target install, though
<Saviq> tsdgeos, a custom command or whatnot
<tsdgeos> hmmm
<tsdgeos> let me see
<Saviq> tsdgeos, or actually make the autopilot target do that
<Saviq> tsdgeos, otherwise it wouldn't be called every time
<tsdgeos> yeah that'd work
<tsdgeos> or should :D
<tsdgeos> Saviq: updated https://code.launchpad.net/~aacid/unity8/coding_autopilot_docu/+merge/200974
<tsdgeos> and another one
<tsdgeos> https://code.launchpad.net/~aacid/unity8/timeformattertest_LCALL_C/+merge/200991
<Mirv> greyback: can you get a manager add platform-api to Landing Asks in case https://code.launchpad.net/~ricmm/platform-api/set-dimensions/+merge/198490 is meant to go in? (landed after platform-api was released yesterday)
<Mirv> ricardo mentioned that commit so in case it's useful to have it fast it's better to add it already to the list
<greyback> Mirv: ok. kgunn ^^
<tsdgeos> Saviq: so was thinking about the organic positioner and how it's supposed to get bigger as the width increases and until two modules fit in the width
<Saviq> tsdgeos, again, I don't think it's your concern
<Saviq> tsdgeos, I think a QML wrapper will do that
<tsdgeos> Saviq: and was wondering if we can just do that in the QML side and on the C++ side we just have size and spacing
<tsdgeos> and someone cares about making it match
<tsdgeos> ok, same thought then
<Saviq> tsdgeos, yeah, justs have a prop "moduleSize" or so
<Saviq> or width
<Saviq> and spacing, exactly
<Saviq> tsdgeos, same spacing between items as well as between modules, right?
<tsdgeos> Saviq: i was thinkin on having spacing (for in between delagates) and then smallSize and bigSize properties
<tsdgeos> and with that i can calculate everything and see if i can have one or more modules per row
<Saviq> tsdgeos, ok, that's maybe even better
<Saviq> it's not as if it's going to be difficult to calculate
<Saviq> tsdgeos, +q
<Saviq> +1 even
<tsdgeos> D:
<Saviq> tsdgeos, https://code.launchpad.net/~allanlesage/unity8/autopilot-indicator-page-title-matches-widget/+merge/196991/comments/467382
<Saviq> Wellark_, bug-chat seems to have problems ;)
<Saviq> Wellark_, the SIM PIN *dialog* is part of unity8
<Saviq> already
<Saviq> Wellark_, and the UI is displayed as the screenshots show (they're screenshot from a real phone)
<Saviq> Wellark_, the only thing is the string, which is now hardcoded in unity8, but should be provided by whoever requests that dialog (most probably indicator-network)
<Saviq> Wellark_, is that somewhat more clear?
<Wellark_> Saviq: yes, I got that it's already part of unity8
<Wellark_> I'm just trying to figure out what you want changed :)
<Wellark_> and if it's just the hardcoded string
<Wellark_> then fine :)
<Saviq> Wellark_, yes, only that - which means changes in unity8, unity-notifications potentially, and indicator-network
<Wellark_> Saviq: yeah. the dialog needs a dbus interface also
<Wellark_> so that indicator-network can update the values and provide the modem state
<Saviq> Wellark_, it already does - it really really actually works already ;)
<Wellark_> I'm skeptical ;)
<Saviq> Wellark_, over a snap decision + UnityMenuModel
<Saviq> so "extended snap decision"
<Wellark_> Saviq: ok. I'm working on the connectivity api atm, until the end of next week
<Wellark_> then it's 100% for indicator-network for me
<Wellark_> Saviq: how much in a hurry are you with this?
<Saviq> Wellark_, not at all ;)
<Saviq> dednick, http://ddebs.ubuntu.com/pool/main/m/mir/ btw :/
<dednick> Saviq: thanks
<Wellark_> Saviq: ok. let's leave the bug open then and make the hardcoded string dissapear in near future
<Saviq> Wellark_, +1, that's all I needed :)
<Saviq> dednick, apparently index generation didn't catch up yet
<kgunn> greyback: about to run the boy up to school....so i assume you want that papi mp ?
<greyback> kgunn: yes, that and https://code.launchpad.net/~ricmm/qtubuntu/papi-setdimensions/+merge/198498
<kgunn> greyback: thanks...sidestage i assume
<Saviq> tsdgeos, re: open_scope tests... if you look at https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1871/artifact/results/autopilot/artifacts/unity8.shell.tests.test_notifications.EphemeralNotificationsTests.test_urgency_order%20%28Desktop%20Nexus%204%29.ogv - it looks like the test is interrupted somehow
<greyback> kgunn: yep
<Saviq> tsdgeos, apparently we don't get unity8.log there unfortunately
<tsdgeos> oh :/
<tsdgeos> yeah it looks like it ends "too early"
<Saviq> tsdgeos, I've seen that a few times already, no idea where it comes from
<kgunn> greyback: before i top approve...any idea why that qtubuntu ci has failed so many times?
<Saviq> fginther, does testrunner-otto collect .crash files? and could it collect unity8.log from .cache/upstart/?
<Saviq> fginther, we have trouble understanding / reproducing https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1871/ :/
<greyback> kgunn: it depends on that papi change to land first.
<kgunn> greyback: thank you sir
<fginther> Saviq, I'll check on that, if it's not collecting them, it should be easy to add them
<kgunn> Mirv: ok...added "set dimension" support mp's to landing ask for papi & qtubuntu
<tsdgeos> Mirv: https://code.launchpad.net/~aacid/qml-friends/use_minimal_qpa_for_test/+merge/201009 same trick worked
<Saviq> woohoo, stuff is looking greener in qt5-beta2
<Saviq> mzanetti, re: new-scopes-horizontal
<Saviq> mzanetti, you sure the tests pass regardless? do you have an explanation?
<mzanetti> Saviq: probably that function() in data() doesn't work
<Saviq> mzanetti, it doesn't have to "work" and well, why wouldn't it?
<mzanetti> Saviq: I tried to just removing the functions in there for consistency and noticed the tests were failing
<Saviq> mzanetti, the reason for using a lambda there is that the values used to compute change in _test() when the selectedIndex is changed
<mzanetti> then I reverted and made the functions return bullshit
<mzanetti> still passing
<Saviq> mzanetti, humm
<Saviq> mzanetti, interesting, me checks
<Saviq> karni, â
<mzanetti> Saviq: I'm quite sure you can achieve the same without lambdas
 * greyback thinks it would be nice if unity8 binary could let you specify a custom directory to load the qml from
 * karni reads
<Saviq> mzanetti, I'm all ears
<mzanetti> heh
<mzanetti> ok. need to try then. but so far I haven't come across a situation where I would have needed this
<karni> mzanetti: Saviq: I still wanted to revert the changes and make sure tests would fail, was late yesterday. I'm happy to get on this now, I should have left a comment.
<mzanetti> Saviq: esp. things like "return 0". why a lambda?
<Saviq> mzanetti, that was just so that I don't have to do the "if typeof === "function""
<mzanetti> Saviq: you can define a property int expectedHeaderPos: art.x + art.width
<Saviq> mzanetti, the situation here is simple: the index: part of the data actually changes the layout
<mzanetti> and then just refer to that property in the data
<mzanetti> or something like that
<Saviq> mzanetti, nope, that won't work, 'cause it would get the value in _data()
<Saviq> mzanetti, well, you'd need to refer to it by name, not
<Saviq> value
<karni> Like Saviq said, first line setting the selector index changes layout.
<Saviq> mzanetti, so not a nicer solution that the lambda IMO
<Saviq> but /me needs to look
<mzanetti> no... not really nicer...
<mzanetti> anyways... either lambdas in there don't work at all or there is some other mistake
 * karni is looking into it
<karni> FTR changing the return 0 to return anything else makes the test fail.
 * karni looks at another lambda
<Saviq> mzanetti, changed the tests, FAIL
<mzanetti> I tried this in line 291:
<mzanetti>                 { tag: "Horizontal", left: function() { return art.width * 2 }, index: 5 }
<mzanetti> note the *2
<mzanetti> still passing
<karni> mzanetti: that makes it fail
<mzanetti> dafuq
 * mzanetti tries again
<Saviq> mzanetti, line 291?
<mzanetti> what the heck is going on
<mzanetti> it fails somethimes here
<mzanetti> Saviq: in tst_Card.qml
<Saviq> mzanetti, right, I merged it on top of new-scopes
<mzanetti> yep. now it passed again _with_ the *2
<Saviq> karni, can you please do merge lp:~unity-team/unity8/new-scopes
<mzanetti> but sometimes it fails indeed
<karni> Saviq: into that MP branch? sure
<mzanetti> hmm... maybe the tryCompare stops by the value with *2 too
<Saviq> mzanetti, indeed it does
<Saviq> mzanetti, right, tryCompareFunction then...
<karni> Saviq: done
<Saviq> karni, thanks
<karni> anytime
<Saviq> mzanetti, chicken'n'egg problem here, really...
<mzanetti> yeah... guess so
<Saviq> mzanetti, so the other possibility is to just use hardcoded units.gu() values if you think it better
<Saviq> I didn't want to do that
<mzanetti> hmm... dunno
<karni> Saviq: that would be then specific to a particular card-size, right?
<karni> if we wanted to hardcode these values.
<Saviq> mzanetti, hmm now it reliably fails
<Saviq> mzanetti, pull please
<mzanetti> I guess now that we know the lambdas are working and the issue was another one I guess I'm fine with it
<Saviq> mzanetti, well, the fact that it's a chicken'n'egg problem is still an issue
<greyback> Saviq: mzanetti standup
<greyback> quit talking about food and get back to work
<karni> haha
<Saviq> karni, wanna join?
<Saviq> karni, Standup on Canonical mumble
<karni> Saviq: hangout? oh, lemme see quickly if I have it set up
<karni> sure
<karni> been a while I used mumble
<karni> which room would that be?
<karni> hrm.. mumble just hung
<Saviq> karni, kill, start again ;)
 * karni does just that, another hang. gives it a sec.
<Saviq> karni, try again ;)
<karni> there :)
<mzanetti> greyback: I'm worried that we'll never ever get our stuff merged again
<greyback> mzanetti: "we" as in you? :)
<mzanetti> thanks
<mzanetti> :P
<greyback> mzanetti: I'm only making the tiniest changes here and there, nothing major at all
<greyback> mzanetti: I'm keeping eye on your branch
<mzanetti> greyback: ah, that sounds good :)
<mzanetti> greyback: are you mostly working in unity-mir or unity8 (aka. ApplicationManagerWrapper)?
<Saviq> mzanetti, so, what I meant was... if the target value is moving ('cause it depends on the layout) and the tested value is moving, they might "meet" and pass somewhere in the middle...
<Saviq> mzanetti, although in this case there's no animation, so that should be fine, but still...
<greyback> mzanetti: yep, most LOC changed are not in unity8 at all.
<greyback> mzanetti: how close would your work be to landing?
<mzanetti> greyback: ah ok... my changes in unity-mir are rather small
<mzanetti> greyback: unfortunately rather far away
<mzanetti> greyback: I don't think I should still re-implement the old school side stage in my branch
<mzanetti> greyback: and I don't have a design for the new one yet
<mzanetti> greyback: the phone stuff is getting closer tho, but our no-breakage policy wouldn't allow it to land without implementing the tablet stage too first
<greyback> mzanetti: ok. Then I'll be making a couple of minor tweaks to shell.qml and stage.qml probably, that might cause you pain
<mzanetti> greyback: I've deleted stage.qml in my branch
<greyback> minor tweaks = 2-3 lines of code changes
<greyback> mzanetti: yep, so it's only shell.qml really we need to be careful about I think
<mzanetti> yeah. sounds ok
<mzanetti> cool
<greyback> yep
<mzanetti> Saviq: hmm... I'm sure you'll figure a solution :P
 * mzanetti prepares for the design meeting
<Saviq> mzanetti, just using you as a sounding board ;P
<mzanetti> do I?
<mzanetti> oh... read wrong..
<mzanetti> got it
<mzanetti> brain FEC is scary sometimes... I read "..as you are sounding bored"
<Saviq> ;D
<Saviq> tsdgeos, what was the _BAD_RENDER_LOOP thing again?
<tsdgeos> Saviq: you mean the full name?
<Saviq> tsdgeos, yeah
<tsdgeos> QML_BAD_GUI_RENDER_LOOP
<Saviq> tsdgeos, is it somewhere on doc.qt-project btw?
<tsdgeos> not sure
<tsdgeos> i just grepped the sources :D
<Saviq> tsdgeos, as in that, the RENDER_TIMING one... I always seem to forget them
<Saviq> tsdgeos, yeah ;)
<Saviq> karni, you might want to export ââ =1 after having shelved qml/ changes
<Saviq> karni, otherwise qmltestrunner crashes for me her
<Saviq> e
 * karni notes
<karni> writing an e-mail for a person Alex might be hiring, I'll get my hands on the shelving part real soon.
<Saviq> karni, but yeah, http://paste.ubuntu.com/6721162/ adds some robustness to the tests
<Saviq> tsdgeos, check this out http://paste.ubuntu.com/6721167/
<Saviq> uh oh 5.2?
<Saviq> I'm not on 5.2, WTH?
<tsdgeos> that's a crash?
<Saviq> tsdgeos, yeah
<Saviq> tsdgeos, but the retrace seems bogus
<tsdgeos> :D
<Saviq> tsdgeos, somehow the retracer decided to pick up qt5.2 instead of the one I had installed...
<tsdgeos> bad retracer bad!
<Saviq> tsdgeos, indeed, apparently it always picks up latest packages (I had the 5.2 PPA enabled for the retracer - a thing to remember)
<Saviq> tsdgeos, http://paste.ubuntu.com/6721216/
<Saviq> tsdgeos, less scary, and solved by BAD_RENDER
<tsdgeos> Saviq: may even be a problem of UCFontUtils::sizeToPixels ?
<tsdgeos> not being thread-safe/reentrant/whatever?
<Saviq> tsdgeos, true
 * Saviq files a bug just in case
 * karni gets to those tests
<Saviq> tsdgeos, and now for something completely different! the launchpad retracer decided it's nothing relevant to the UCFont... but the Shape instead... https://launchpadlibrarian.net/162021731/Stacktrace.txt
<tsdgeos> that is weird :S
<elopio> tsdgeos: thanks for the review.
<elopio> I've been trying to reproduce the mako errors since yesterday, and I have finally done it. It only fails when I run the whole suite, it seems one test fails to swipe the greeter, then the screen will go blank and all the following tests will fail too :/
<tsdgeos> elopio: no worries
<tsdgeos> ouch
<tsdgeos> Saviq: is that the bug you mentioned âââ in the other autopilot merge request?
<tsdgeos> what, i'm running on batteryÂ¿?
<tsdgeos> not anymore
<Saviq> tsdgeos, no, something that happened locally
<tsdgeos> ok
<karni> Saviq: I have standup in 3 minutes, but I'll try to be first, and join you guys asap. The meeting you scheduled is in a moment, right?
<Saviq> karni, we just moved it to tomorrow
<Saviq> karni, 10am UTC
<Saviq> karni, katie couldn't make i
<Saviq> t
<karni> Saviq: perfect, thanks :)
<elopio> tsdgeos: can we prevent the screen to go blank in these tests?
<tsdgeos> elopio: sure
<tsdgeos> i mean
<tsdgeos> well there's a command line call that makes it not go blank
<tsdgeos> you should be using it
<tsdgeos> which i don't remember
<tsdgeos> powerd-cli
<tsdgeos> and some argument
<tsdgeos> powerd-cli display on
<tsdgeos> elopio: â
<elopio> tsdgeos: thanks, that will help a little.
<dednick> Saviq: why did we drop the qmlproject?
<Saviq> dednick, to not have two separate projects in qtcreator
<Saviq> dednick, they are part of the CMake project now
<Saviq> dednick, although mzanetti's still fixing a few issues with that
<mzanetti> branch updated btw
<Saviq> dednick, you might need to right-click on the project â Run CMake to get them
<mzanetti> Saviq: ^
<dednick> Saviq: how do I actually open the project? :)
<kgunn> kdub: ^^ see tsdgeos
<mzanetti> dednick: just open the cmakeLists.txt
<kgunn> talking about the powerd issue above
<mzanetti> the top level one
<Saviq> mzanetti, no it's not https://code.launchpad.net/~mzanetti/unity8/tests-qml-in-cmake/+merge/200872
<Saviq> mzanetti, still includes all the .cpp .h files in the executable
<mzanetti> hmm... seems I pushed to the wrong branch then
<dednick> Saviq: ahh, didnt even know you could do that
<Saviq> dednick, you couldn't ;)
<Saviq> dednick, but mzanetti managed to
<kdub> tsdgeos, i think that should work
<dednick> yay. source files!
<tsdgeos> kdub: yes it does
<tsdgeos> kdub: wasn't complaining
<tsdgeos> was just telling elopio
<kdub> right :)
<mzanetti> Saviq: pushed now
<Saviq> mzanetti, ack
<elopio> what I found is that when there are 6 tests left, the autopilot Touch stops working.
<Saviq> mzanetti, hrm, in that case we can drop the special case for qmltests can't we
<Saviq> mzanetti, ah wait
<Saviq> mzanetti, ignore
<Saviq> is good
<mzanetti> tests/modules
<mzanetti> UntiyTestCase.qml
<kgunn> kdub: i was just pointing it out...b/c we really shouldn't need to be using powerd cli to get past it...
<kgunn> related to https://bugs.launchpad.net/mir/+bug/1236525
<ubot5> Ubuntu bug 1236525 in unity-mir "unity8 killed/crash then restart can result in mir unable "could not unblank display"" [Medium,Triaged]
<kgunn> anyway...it'll be interesting to hear if you find this is now effecting mir ci as well
<karni> Saviq: validated tests against your changes. test_art_size_data() with "Horizontal" tag would only verify that art.height == header.height (good, along the spec). But I can't make it fail, because we actually wanted to test anchors.horizontalCenter using x (and/or width), while width and height already well defined in the code. In other words, can't make the test fail for missing line 9 here, although the tests in lines 22,23 verify UI against ...
<karni> ... spec. http://paste.ubuntu.com/6721694/
<karni> Saviq: pushed revno 575 to that MR, I got no further improvements.
<karni> Saviq: just read the comment on MR regarding what we talked before about lambdas. let me try make em fail.
<Saviq> karni, don't over-do :)
<karni> Saviq: I mean, if it's seriously an issue, I should see where stuff fails.
<Saviq> karni, I'm afraid I didn't follow your sentence above, but that might be EOD creeping up on me
<fginther> Saviq, the otto jobs are already saving crash files if they exist (the build you specified didn't have any). I have a change ready to collect the unity8.log
<fginther> Saviq, here's an example: http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty-fjg/3/
<Saviq> fginther, awesome, thanks!
<ChrisTownsend> I have a question about the SoundCloud scope.  I was supposedly deprecated by the Home Scope here: http://bazaar.launchpad.net/~unity-team/unity-scope-home/trunk/revision/146
<ChrisTownsend> I don't see how to get results from Soundcloud though.  How do I get results from Soundcloud?
<ChrisTownsend> mhr3: pstolowski: Perhaps you can answer my question above? ^^^^
<mhr3> ChrisTownsend, "soundcloud:foo" in dash home
<ChrisTownsend> oh, no automatic way via filter though, right?
<mhr3> no
<pstolowski> ChrisTownsend, or by typing a query. and *then* selecting it from filters in home
<ChrisTownsend> mhr3: Ok, thanks
<mhr3> ChrisTownsend, well, not sure what you meant by "automatic"
<ChrisTownsend> pstolowski: Soundcloud is not listed as a filter though.
<mhr3> it is here
<ChrisTownsend> mhr3: I get it if install unity-scope-onlinemusic from Universe.
<ChrisTownsend> But I don't see it if I don't have that installed.
<mhr3> hmm, doesn't sound right
<mhr3> although i do have that installed
<ChrisTownsend> mhr3: I didn't think that sounded right either.  That's why I'm asking:)
<ChrisTownsend> mhr3: However, Soundcloud:foo does work without the onlinemusic scope.
<pstolowski> ChrisTownsend, yeah, onlinemusic has nothing to do with it, it was implemented specifically for the phone (although it works on the desktop of course)
<ChrisTownsend> mhr3: Well, it this all back.  I now see the filter.
<ChrisTownsend> Why did I not see that before.
<mhr3> dee-tool -m "com.canonical.Unity.SmartScopes.RemoteScopesModel" | grep -q -i "soundcloud" && echo "It's there" || echo "Not there"
<ChrisTownsend> mhr3: I ran that, got a dee-tool crash and it printed out Not there
<ChrisTownsend> mhr3: Sorry, I entered something wrong.
<ChrisTownsend> mhr3: It's there
<mhr3> then it is there :)
<karni> mzanetti: FYI In each single lambda these new tests contain I added +1 in the return value. Each test would consistently fail. Considering your comment on the MR, does that mean we're good?
<ChrisTownsend> mhr3: lol, yeah
 * karni just pushed last revno
 * karni wants to move forward :)
<ChrisTownsend> mhr3: So my other question is if I'm in the Music scope, and I enter a search term, it won't automatically search Soundcloud though, right?
<mhr3> ChrisTownsend, right, it won't
<mhr3> though it should according to design
<mhr3> EDIDNOTHAPPEN
<ChrisTownsend> mhr3: Ok, that is where I was going with this:)
<ChrisTownsend> mhr3: Thanks
<mhr3> np
<tsdgeos> dandrader|lunch: can you do https://code.launchpad.net/~aacid/unity8/hjournalbugfix/+merge/201047 ?
<tsdgeos> and with that
<tsdgeos> eod!
<mhall119> Saviq: I want to file a bug against the fact that the HUD changes from bottom-aligned to top-aligned while you're using it, should that go against ubuntu-ux or unity8?
<Saviq> mhall119, ubuntu-ux and unity8
<Saviq> mhall119, it's per design, so the design needs to change
<mhall119> both?
<mhall119> ok
<kgunn> mhall119: ubuntu-ux....and assign to johnlea
<mhall119> ok
<mhall119> Saviq: how about all of the Unity7 integration points that Unity8 currently doesn't have, are there bugs for each of those?
<Saviq> mhall119, no, no bugs for all of those
<Saviq> mhall119, they're handled in bprints mostly
<mhall119> Saviq: do you want bugs for them (I'm filing a lot today)?
<Saviq> mhall119, not sure it will help us manage everything
<Saviq> mhall119, not when the bug is going to be "missing foo"
<mhall119> ok, I'll refrain from those then, do you have a BP link where they are work items?
<Saviq> mhall119, here's a mother-blueprint https://blueprints.launchpad.net/ubuntu/+spec/topic-s-unity-next-ui
<Saviq> mhall119, most of them should be covered, if you find something that isn't - feel free to add
<mhall119> thanks Saviq
<mhall119> Saviq: so https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-launcher has everything currently DONE for the launcher, but doesn't have any plans or work items for adding count/progress/urgent API support to it, are those things in a BP somewhere?
<Saviq> mhall119, https://blueprints.launchpad.net/ubuntu/+spec/client-1404-unity-ui-launcher
<Saviq> mhall119, so yeah https://blueprints.launchpad.net/ubuntu/+spec/topic-t-unity-ui is the mother-blueprint for T
<mhall119> ah, thanks, looks like https://blueprints.launchpad.net/ubuntu/+spec/topic-t-unity-ui is the new mother-blueprint
<mhall119> ah, what you said
 * mhall119 fails reading comprehension 101
<mhall119> thanks again Saviq
<kgunn> greyback: thanks hopping on that one
<kgunn> osk hiding when app is killed
<greyback> kgunn: np
<mhall119> Saviq: I don't see anything for the counter and progress bar on Launcher icons in https://blueprints.launchpad.net/ubuntu/+spec/client-1404-unity-ui-launcher, can I add them as TODO work items?
<mhall119> there is one for the "urgent" state though
<mhall119> there's also nothing for supporting static or dynamic quicklists
<elopio> hah! so I've proved that it's not possible to add any autopilot tests to unity8:
<elopio> https://code.launchpad.net/~elopio/unity8/confirm_6_failure/+merge/201040
<elopio> sadly, now there's nobody around to blame :(
<thomi> elopio: this is the input device issue?
<thomi> Saviq was looking at that yesterday, was going to try a suggestion of mine, but I think he may be sleeping for once :)
<elopio> thomi: it is one input device issue, I'm not sure it's the same one you are talking about.
<elopio> thomi: it seems that after the current amount of tests, when I add a new one, the Touch will stop working.
<elopio> thomi: what was your suggestion to Saviq?
<thomi> elopio: right, we know why, and there's a couple of ideas
<thomi> elopio: it's due to the fact that the u8 AP tests use a hacky workaround to get mir to recognise the input device
<thomi> however, this workaround leaks input device s
<thomi> so after a certain number of tests, we can no longer create any more input devices
<elopio> thomi: ok. So can we delete input devices?
<thomi> elopio: call close(0 on themn
<thomi> ugh
<thomi> typing is hard
<thomi> "call close() on them"
<thomi> before you create the new one
<elopio> self.touch = Touch.create()
<elopio> self.addCleanup(self.touch.close)
<elopio> thomi: like that?
<thomi> elopio: not quite... there's a workaround in the u8 codebase that calls _create_touch_device every test
<thomi> this needs to be called on the underlying uinput device, with is an AP internal
<thomi> AP never calls it because AP only ever creates a single instance :)
<thomi> greap for "create_touch_device"
<elopio> thomi: looking at it
<thomi> cool
<elopio> it happens only on the phone, makes sense
<thomi> make sure "_touch_device.close()" is called before the new one is created
<thomi> should do the trick, I think
 * elopio tries.
<fipioni> i want to ask something about unity am i at the right place if yes why no one is
<fipioni> replying to my pm
<fipioni> :'(
<karni> fipioni: If it's a technical question, you're at the right place. Bare in mind people live in different time zones. Just ask your question here, and you might get an answer.
<ChrisTownsend> fipioni: Any reason why you can't ask here and can only ask via PM?
<mhall119> he's asking about the game engine Unity, not our Unity
<fipioni> i asked something about crack software in the previous room and got bully
<ChrisTownsend> fipioni: Yeah, sorry, this channel is for the desktop environment Unity for Ubuntu, not the game engine.
<karni> oh
<ChrisTownsend> fipioni: Sorry we can't help/
<karni> fipioni: My bad, like ChrisTownsend said, this is a wrong channel :/ Sorry.
<fipioni> no i want to know something is there a way to check weather your code is comile using paid or free software
<fipioni> *compile
<mhall119> fipioni: I don't think anybody here can answer questions about the game engine
<fipioni> but what about compilation
<karni> fipioni: You sure you talking about https://unity.ubuntu.com/ ?
<fipioni> what about compilation from higher language to lower language that is understandable for certain operating system
<elopio> thomi: it works! thanks, you are the coolest one again.
<elopio> thomi: do you have permissions to approve?
<elopio> https://code.launchpad.net/~elopio/unity8/fix1267600-close_touch/+merge/201105
<thomi> elopio: let me see
<thomi> veebers: can you look at that please? LGTM, but you should be the one to review it I think
<veebers> thomi: sure I can take a look
<veebers> elopio: I have top-approved that. Thanks for that :-)
<mhall119> does the unity8 project still contain the welcome screen, or has that been broken out?
<Saviq> mhall119, sorry, have reassigned most of your bugs ;)
<mhall119> Saviq: that's fine, I expected that to happen, I just didn't know what functionality lives in what project
<Saviq> mhall119, j/k
#ubuntu-unity 2014-01-10
<elopio> thank you veebers and thomi.
<tsdgeos> Saviq: read the description!
<Saviq> tsdgeos, sooorry :D
<tsdgeos> Saviq: i tried and failed
<tsdgeos> thing is that this is executed not in sync with any call you do, so it's even hard to add a qcompare to -1
<tsdgeos> i was hoping i could make it crash or act weird
<tsdgeos> but couldn't
<tsdgeos> maybe i'm also defending with count() == 0 or isEmpty in other parts of the code
<tsdgeos> but still shouldn't be 0
<tsdgeos> Saviq: so did i convince you in https://code.launchpad.net/~aacid/unity8/timeformattertest_LCALL_C/+merge/200991 ?
<Saviq> tsdgeos, not really, especially since currently 100% of our tests should run under LC_ALL=C
<Saviq> tsdgeos, as we don't have any place that should be affected by the locale
<tsdgeos> Saviq: ok, so i can move it to cmake and update the CODING file?
<Saviq> tsdgeos, gimme a few to think what we want there
<tsdgeos> sure
<Saviq> tsdgeos, I've a feeling all our tests should run under LC_ALL=C currently
<tsdgeos> should as "they do" or as "we would like to do"
<tsdgeos> ?
<Saviq> tsdgeos, can you still run make -C builddir testfoo to run that test?
<Saviq> tsdgeos, we would like them to
<tsdgeos> Saviq: no, can't find a way to run it individually
<tsdgeos> only make test
<tsdgeos> or run the binary
<Saviq> tsdgeos, right, so that's something we should make possible
<tsdgeos> ah no
<tsdgeos> make timeformattertest
<tsdgeos> works
<tsdgeos> but doesn't get autocompleted by the bash make autocompleter
<tsdgeos> my bad
<Saviq> tsdgeos, should've used ninja ;)
<tsdgeos> i get no autocompletion at all with ninja
<Saviq> tsdgeos, oh?
<tsdgeos> and actually it gets autcompleted now :D
<Saviq> lol
<tsdgeos> don't know, just woke up
<Saviq> tsdgeos, that good enough for you?
<tsdgeos> Saviq: having the LC_ALL in the make step? yeah
<Saviq> tsdgeos, try and see if we can globally set that for the test env
<Saviq> tsdgeos, hmm doesn't look like it
<tsdgeos> why?
<Saviq> tsdgeos, you can set_test_properties on a per-test basis
<Saviq> tsdgeos, but not globally
<tsdgeos> but don't we have our own "create test" macro?
<tsdgeos> now we don't
<tsdgeos> we have parts of it scattered around
<tsdgeos> i see
<tsdgeos> i.e. set_test_properties
<tsdgeos> arg
<tsdgeos> i.e. unity8/tests/plugins/Utils/CMakeLists.txt has run_tests
<tsdgeos> but it's used there locally
<Saviq> tsdgeos, right, we could have a global macro for that indeed
<tsdgeos> but then it needs more careful thinking
<tsdgeos> i.e. in this case we are assuming testname == testfile+.cpp
<tsdgeos> but in some other cases we have multiple files
<tsdgeos> or different libs to link to
<tsdgeos> etx
<tsdgeos> etc
<Saviq> tsdgeos, sure it does :)
<Saviq> tsdgeos, if you don't want to get into it
<Saviq> tsdgeos, just move the LC_ALL into CMakeLists.txt for now
<Saviq> tsdgeos, for that one test
<tsdgeos> so boils down to maybe just add a warning in CODING and be done with it :D
<tsdgeos> tests are expected to run under the C locale
<tsdgeos> done
<tsdgeos> then i can blame myself for not following the CODING guidelines :D
<Saviq> tsdgeos, yup ;)
<tsdgeos> ok
<tsdgeos> will do that
<tsdgeos> Saviq: ok, comment added to CODING
<Saviq> tsdgeos, cheers
<tsdgeos> Saviq: do you want to do https://code.launchpad.net/~aacid/unity8/coding_autopilot_docu/+merge/200974 too or shall i find someone else?
<Saviq> tsdgeos, looking
<Saviq> tsdgeos, please add that if you don't `make install`, the tests will run on the system-installed version
<tsdgeos> ok
<tsdgeos> Saviq: done
<Saviq> tsdgeos, https://code.launchpad.net/~saviq/unity8/forgiving-genericscopeview/+merge/201147 please
<Saviq> mzanetti, can you continue with https://code.launchpad.net/~unity-team/unity8/new-scopes-horizontal-card-layout/+merge/200910 please?
<mzanetti> yes sir
<tsdgeos> Saviq: on it
<tsdgeos> now i think both my coding file changes are going to conflct...
<Saviq> tsdgeos, they might indeed
<tsdgeos> let's see
<Saviq> tsdgeos, just merge them together?
<Saviq> tsdgeos, neither is being -autolanded yet
<karni> Saviq: thanks for the follow up! :)
<Saviq> karni, sure
<tsdgeos> Saviq: ok, reapprove https://code.launchpad.net/~aacid/unity8/coding_autopilot_docu/+merge/200974 then
<tsdgeos> i cancelled the other one
<karni> Saviq: looks like good progress to me :)!
<Saviq> tsdgeos, thanks
<Saviq> karni, glad to hear that
<Saviq> karni, I'm flying to Cape Town tomorrow, won't be around much until the 27th, I'll leave you in tsdgeos's capable hands
<Saviq> karni, he's the one writing the journals and organic grid now
<dednick> is anyones indicators not showing up on desktop unity8?
<karni> Saviq: ACK! Thank you :)
<Saviq> dednick, seems to work fine
<dednick> Saviq: hm. must be something funky with mine then
<tsdgeos> Saviq: there's a lot more previewListView uses that you have not protected, no?
<Saviq> tsdgeos, those were the only ones that bit me, but you're right
<tsdgeos> dednick: there's the thing that closing down unity8 will kill them
<tsdgeos> dednick: so run unity8 and ctrl+c it
<tsdgeos> Saviq: i think that there are a few more that would break
<tsdgeos>         forceNoClip: previewListView.onScreen
<tsdgeos> ?
<tsdgeos> and the renderloader clicked
<dednick> Saviq: yeah, but it restarts them when unity8 starts
<tsdgeos> Saviq: why don't you have a previewListView, is it a test?
<Saviq> tsdgeos, the scope tool
<Saviq> tsdgeos, but yeah I'm thinking I should make it differently... just get Dash complete, and not GenericScopeView alone
<tsdgeos> +1
<tsdgeos> or DashContent at leat
<dednick> Saviq: nevermind. old qmenumodel.
<tsdgeos> that brings what you need i think
<karni> mzanetti: Could you please merge this today, so we can get it into PPA ASAP? Horizontal card layout would be very handy for my team. https://code.launchpad.net/~unity-team/unity8/new-scopes-horizontal-card-layout/+merge/200910
<sil2100> jamesh__: hello!
<karni> :)
<mzanetti> karni: yeah, on it right now. just running tests for a last time
<karni> mzanetti: sweet! thank you :)
<sil2100> jamesh__: I wanted to finally deal with the mediascanner-v2 release today, but I just noticed that we might want to modify the source package name
<sil2100> jamesh__: right now it's mediascanner2.0, but not sure if the 'source' package should have a major and minor version - so maybe mediascanner2?
<Saviq> tsdgeos, ok then, ignore that branch
 * tsdgeos ignores
<tsdgeos> what's up with autopilot again
<tsdgeos> what :D
<tsdgeos> https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1930/artifact/results/autopilot/artifacts/unity8.shell.tests.test_greeter.TestGreeter.test_greeter_background%20%28Desktop%20Nexus%2010%29.ogv
<tsdgeos> just doesn't start :D
<tsdgeos> it segfaulted like crazy :S
<tsdgeos> /var/log/syslog: Jan 10 09:16:47 trusty-amd64-20131210-1707 kernel: [2561012.274762] QThread[29589]: segfault at 1cfb6 ip 000000000001cfb6 sp 00007f2584de7228 error 14 in unity8[400000+c000]
<tsdgeos> doesn't make any sense
<Saviq> tsdgeos, yeah, it's been like that for some runs it seems
<tsdgeos> :(
<tsdgeos> any clue if it's fauly hardware or something else?
<Saviq> tsdgeos, we definitely need someone to look at it
<tsdgeos> mzanetti: can you detach me a autopilot VM?
<tsdgeos> if so i'll have a look
<mzanetti> tsdgeos: sure
<tsdgeos> organic grid is almost done [in my mind :D]
<karni> How do I actually work with the unity-scope-tool?
<Saviq> karni, right now you dont'
<Saviq> karni, I'm fixing
<karni> oh okay
<Saviq> karni, will have a branch for you to try in 3 mins
<karni> Saviq: wheee \o/ thanks MichaÅ
 * karni was wondering how to populate unity-scope-tool with an actual scope
<mzanetti> tsdgeos: ps-trusty-server-amd64-2 is yours once the job 881 is done
<mzanetti> tsdgeos: note that jenkins will revert the VM after the job is finished. so give it a minute before starting to work on it or else jenkins will revert your stuff too
<tsdgeos> oka
<Saviq> tsdgeos, https://code.launchpad.net/~saviq/unity8/tool-fulldash/+merge/201150
<tsdgeos> ok
<Saviq> tsdgeos, actually need fix
<Saviq> but meeting first
<tsdgeos> okÂ²
<tsdgeos> mzanetti: even if the machine is doing qmluitests at the moment i can use it for autopilot tests, right?
<mzanetti> tsdgeos: oh... autopilot... we don't run them in VM any more
<mzanetti> tsdgeos: they are executed on a real machine but I don't have access to that one
<tsdgeos> mzanetti: no?
<tsdgeos> oh :_/
<tsdgeos> mzanetti: ok, then put the thing back into the pool
<mzanetti> done
<mzanetti> tsdgeos: do you have autopilot failures in jenkins which you cannot reproduce locally?
<tsdgeos> mzanetti: unity8 crashing :D
<mzanetti> hmm... but that *should* behave the same on your local machine
<tsdgeos> mzanetti: see https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1930/consoleFull for the billions of segv
<tsdgeos> i definitely don't get all these crashes
<tsdgeos> fginther: ping
<Saviq> tsdgeos, tool-fulldash fixed
<Saviq> tsdgeos, going to #ubuntu-ci-eng vanguard to take a look
<tsdgeos> oki
<karni> Unity team standup is 2:30 UTC?
<tsdgeos> Saviq: so no more scope selector and just swipe left/right?
<Saviq> karni, +1
<Saviq> tsdgeos, yeah, or select by header
<Saviq> tsdgeos, felt unnecessary to have the selector now
<tsdgeos> karni: i invited you to it
<Saviq> tsdgeos, not entirely happy that all the scopes are loaded all the time
<Saviq> tsdgeos, but it works, which is more important
<tsdgeos> Saviq: but that happened before, no?
<tsdgeos> Saviq: or you mean the graphical counterpart
<Saviq> tsdgeos, no, before it only loaded the single dash page, yeah
<janimo> can unity8 be tested on an x86 workstation? Only GUI needed , no sensors or other fancyness of course
<karni> tsdgeos: thanks :)
<tsdgeos> Saviq: why the new mouse area?
<Saviq> tsdgeos, 'cause otherwise I could click on items behind the controls
<tsdgeos> janimo: yes, you can run unity8 on a x86 machine
<Saviq> janimo, it will only run in a window for now (i.e. you can't run real applications yet)
<janimo> Saviq, tsdgeos, any particular setup needed or packages not in the trusty archives?
<tsdgeos> Saviq: which items behind the controls?Â¿
<tsdgeos> Saviq: you mean the right hand side controls?
<Saviq> tsdgeos, yes
<Saviq> tsdgeos, you could click items in a dash page to the right of the selected one
<tsdgeos> ahhhh
<tsdgeos> i see
<Saviq> janimo, nope, apt-get install unity8; unity8
<janimo> the Mir spec doc has a graphic dated May 2013 regarding Mir on the free graphics stack, how valid is that still?
<Saviq> janimo, you might want to take that on #ubuntu-mir
<janimo> Saviq, heh, that indeed worked
<janimo> Saviq, hey, they sent me here :)
<Saviq> janimo, and yeah, you won't be able to run unity8@Mir on x86 yet
<Saviq> janimo, not for the free graphics stack and Mir, they didn't ;D
<janimo> Saviq, for running unity8 I meant
<tsdgeos> Saviq: does the category combobox (sorry i mean optionselector, wait Oren's gone, can we call it combobox again?) shrink up and down in size for you too when changing scopes?
<Saviq> tsdgeos, checking
<janimo> fair enough I guess you are mostly testing on ARM/platfrom-api/Android based hw
<Saviq> tsdgeos, yeah
<tsdgeos> that'd be an SDK bug of cours
<tsdgeos> e
<Saviq> tsdgeos, yup
<Saviq> janimo, this cycle we'll have it running on x86 for sure
<Saviq> janimo, just not yet there
<janimo> Saviq, do you know if there's a blueprint or some other doc specifically for that effort?
<tsdgeos> Saviq: want me to report a bug?
<janimo> Saviq, I'd like to help
<Saviq> tsdgeos, yes please
<Saviq> janimo, https://blueprints.launchpad.net/ubuntu/+spec/client-1404-unity8-on-desktop - bregma is leading that work
<janimo> Saviq, thanks
<tsdgeos> Saviq: i guess it changes size because you empty/fill it again?
<Saviq> tsdgeos, yeah, replace the model
<karni> tsdgeos: hrm. did you use michal.karnicki@canonical.com for the stand-up invite?
<tsdgeos> i think so
<karni> tsdgeos: FTR, no event in my calendar yet
<tsdgeos> interesting
<karni> tsdgeos: That's okay though, if you guys have it consistently at the same hour
<tsdgeos> i think i failed to use the google calendar ui
<karni> ^ ^
<tsdgeos> ok
<tsdgeos> now
<karni> tsdgeos: thanks! :D
<tsdgeos> you know all those webui you never know if you have to press apply/save/ok or not
<tsdgeos> too much dynamic stuff
<mhr3> Saviq, looks like category expansion no longer works in the scope tool
<karni> hahah, true. notably in Gmail "Contacts". Saves on it's own, but somehow never *felt* reliable to me ;)
<karni> mhr3: in case you're talking about the tool-fulldash branch/MP, it does work for me
<mhr3> karni, nope, new-scopes trunk
<tsdgeos> mhr3: damnit, true :D
<tsdgeos> is this because of the thing i just approved?
<tsdgeos> or was there already?
<karni> mhr3: oh.. then he just fixed it ;D
<tsdgeos> ah was there already
<mhr3> tsdgeos, worked until now afaict
<Saviq> mhr3, I fixed it
<tsdgeos> and then the new thing fixes it
<Saviq> mhr3, tsdgeos broke it
<karni> mhr3: https://code.launchpad.net/~saviq/unity8/tool-fulldash/+merge/201150
 * tsdgeos read it backwards
<Saviq> mhr3, and now he's reviewing a fix
<tsdgeos> Saviq: you don't have tests :-P
<Saviq> tsdgeos, indeed I don't
<tsdgeos> Saviq: thing is, the tests we have for genericscope do the expansion thing
<tsdgeos> how do they work?
<tsdgeos> i guess we have a fake list in there?
<Saviq> tsdgeos, the expansion was only broken in the tool
<Saviq> tsdgeos, 'cause of the previewListView
<Saviq> tsdgeos, the MouseArea in GenericScopeView was enabled all the time
<tsdgeos> yep, the tests have their own previewListView
<Saviq> tsdgeos, so the expansion works, just you couldn't click it
<tsdgeos> that's why it works
<Saviq> tsdgeos, yup
<Saviq> tsdgeos, and now the tool does, too
<Saviq> in a sense
<mhr3> Saviq, hm, doesn't work for me with tool-fulldash
<mhr3> file:///home/miso/projects/unity8/qml/ScopeTool.qml:64:5: Type DashContent unavailable
<Saviq> mhr3, that's based on trunk
<Saviq> mhr3, merge into new-scopes
<mhr3> that's what i did
<Saviq> mhr3, there will be a conflict
<karni> mhr3: Works here
<Saviq> mhr3, imports need to look like so:
<Saviq>  import Utils 0.1
<Saviq>  import Unity 0.2
<Saviq>  import "Components"
<Saviq>  import "Dash"
<mhr3> got that exactly
<Saviq> mhr3, full log please
<mhr3> http://paste.ubuntu.com/6726054/
<Saviq> mhr3, you on saucy, right?
<mhr3> ah
<Saviq> mhr3, you probably don't have the latest UITK
<Saviq> mhr3, just upgrade already
<mhr3> right, this isn't gcc, the first error isn't the issue :)
<Saviq> :)
<karni> :)
<Saviq> mhr3, mzanetti, tsdgeos, karni: bringing Card and CardHeader over to lp:unity8
<Saviq> https://code.launchpad.net/~unity-team/unity8/dash-card-iteration0/+merge/201164
<mhr3> yey :)
<Saviq> mzanetti, you can probably review â, since you already did :)
<mzanetti> Saviq: sure
<karni> \o/
<mzanetti> updating the diff takes ages... I'm afraid of the size of that merge :)
<mhr3> karni, is this desired? http://imgur.com/etQgKSj
<mhr3> i mean, the first one larger than the rest?
<karni> mhr3: It's not desired, looks like a bug. Interestingly, can't find that item on my end.
<mhr3> grooveshark is location dependant iirc
<mhr3> or maybe that's u1-music
<mhr3> i guess it can have something to do with the two-line title
<karni> mhr3: I'll look into it
<mhr3> thx
<Saviq> mzanetti, you shouldn't be - just 800loc
<Saviq> mzanetti, not sure what lp is at
<Saviq> mzanetti, I did overwrite the branch soon after I pushed it, but seems lp got stuck on it
<mzanetti> :)
<Saviq> mzanetti, can reapprove if you want
<Saviq> erm
<Saviq> resubmit
<mzanetti> no worries
<Saviq> tsdgeos, think we should force-merge stuff that only fails in otto?
<Saviq> I'm half-way there
<Saviq> mzanetti, â ?
<Saviq> we're getting queued up again
<tsdgeos> Saviq: i'd prefer to get it not to black-magicly fail :D
<Saviq> tsdgeos, of course, except we have no control over that
<mzanetti> :)
<tsdgeos> yeah ;/
<Saviq> tsdgeos, people are at it
 * Saviq runs a suite
<tsdgeos> Saviq: i mean it's impossible my change to the CODING file or to the hjournal cause those crashes
<Saviq> tsdgeos, exactly
<tsdgeos> i would not cry if it gets force merged
 * Saviq does
<Saviq> tsdgeos, and it completed on device, for that matter
<karni> mhr3: you were right, this line is causing trouble: height: template && template["card-layout"] === "horizontal" ? header.height : width / artShape.aspect
<karni> Thinking of best way to fix it.
<karni> mhr3: Basically, it's a CardHeader layout bug, and that one is actually still worked on, but I'll try to fix it since I'm already on it.
<karni> Is there a known mapping of XXS / XXXS font size to QML font pixel/pointSize ?
<Saviq> karni, http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.Label/
<Saviq> karni, mhr3, actually that "one is bigger than the rest" is, in fact, desired
<karni> Saviq: haha, thank you :) There we go, design using xxxs that doesn't exist. I'll see what makes best sense
<karni> Saviq: Is it? Like mhr3 said, I think it's because the title is wrapped.
<karni> or is it U1MS result? :O
<Saviq> karni, mhr3, "Art_Header_horizontal" â "Header and Art are equal height."
<karni> Saviq: Hrm. Don't you think title overflow should not change CardHeader size?
<Saviq> karni, what I *think* doesn't really matter does it ;D
<karni> s/size/height
<karni> hahahaha
<Saviq> karni, that requires a comment on the spec that this happens
<karni> I'll add the comment
<Saviq> karni, and the spec needs to be adjusted, if applicable
<karni> ack
<Saviq> karni, it might be that we'll need to foresee the largest header height in a configuration
<Saviq> karni, and force it to be as high
<Saviq> karni, but that's not what the spec says right now
<karni> I agree
<karni> Saviq: I would think (which may not matter :D)  text overflow should not cause CardHeader height change
 * karni comments on the spec
<Saviq> karni, OTOH you don't want to make the header always have empty space at the bottom
<Saviq> karni, if there's never overflow
<karni> Saviq: That I didn't say ;) I'd like to do something smart about that. If you look at Michal's screen, there seems to be unnecessary padding at top (invisible at bottom, because of hidden fields). I think if there was less padding (if that makes any sense), the art would not resize because Header height would not change.
<karni> Just a thought, I know it's not us to make UI/UX decisions (usually)
<Saviq> karni, sure, that padding is an issue in CardHeader, I agree
<Saviq> karni, but that won't change the fact that the two will have different size
<Saviq> karni, 'cause both will lose padding
<karni> Saviq: You know I'm relatively new to the subject, but I tend to think 'RelativeLayout' in Android, it's pretty darn flexible, so is Qt/QML :) Anyways, I won't spend too much time on it now, before we get Katie speak her mind.
<karni> :)
<Saviq> karni, sure, everything is flexible, problem is you can't know the text layout... until you lay it out
<Saviq> karni, so you won't know if something wraps or not
<Saviq> karni, but even if you know, you'd have to interrogate all results (the not-visible ones, too), to find out whether any of them overflows
<Saviq> karni, and adapt the header height
<karni> Saviq: I found a way yesterday, I thought I needed it for one test. The thing is, it's a hack really (instantiate a QML object, and measure text). I can easily imagine this would have terrible influence on the performance, though.
<Saviq> karni, yeah exactly
<Saviq> karni, so no, not a *real* way
<karni> well, sh!t
<karni> Saviq: comment added ;)
<karni> mhr3: we'll have to wait for Katies input, it's a tricky bit.
<Saviq> karni, so we need a good-enough solution to be able to foresee what can happen
<karni> +1
<Saviq> karni, the easiest would probably be to assume the largest height, basically, but that could mean we end up with space that's never used in any header in a given category
<karni> yeah, that'd sort of suck.
<karni> easy and quick, tho.
<Saviq> tsdgeos, did you notice that suddenly qmluitests pass 100% https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/
<Saviq> well, almost, but they're pretty green
<tsdgeos> yeah
<tsdgeos> well the expand_expand was actually causing more reds than the other one
<tsdgeos> and i fixed the expand_expand
<tsdgeos> but yeah i'd still expect the one for dash scope change on load to fail a bit more reliably
<mzanetti> Saviq: hey, the only thing I could complain is that make tryCardHeader is not doing anything. do you want to fix that or should I ignore?
<Saviq> mzanetti, "not doing anything"?
<mzanetti> Saviq: well... it pops up a window with a blue rectangle.
<mzanetti> no controls to actually try something
<Saviq> mzanetti, aah try*
<Saviq> mzanetti, tryCard does that
<karni> mzanetti: make -C builddir tryCard and change there
<Saviq> mzanetti, didn't make sense to have it separated out I though
<Saviq> t
<mzanetti> ok... makes sense
<mzanetti> Saviq: karni: approved
<karni> \o/
<karni> thank you
<Saviq> mzanetti, thanks
<karni> Saviq: semi-random question - how heavy would an invisible, extra Label in a layout be? Besides adding one item to the traverse tree when rendering, would it be acceptably lightweight? (You can guess why I'm asking about it - test textWrap)
<Saviq> karni, if it'd only be there for testing, don't
<karni> Saviq: well, that could be used to adjust CardHeader layout (not purely for test purposes, if that's what you're asking). I know it's a wild question, that's why I went ahead and asked ;)
<Saviq> karni, we should avoid any unnecessary objects - sure, it wouldn't be even pushed to the scenegraph or the GPU, but it would still be there in the QML tree
 * karni nod
<Saviq> karni, I really don't think we'll go that route
<karni> ACK
<Saviq> karni, remember you don't even have all the items rendered at once
<Saviq> karni, only those that are on screen
<karni> Correct.
<Saviq> karni, the rest are destroyed
<Saviq> karni, so if at any point you start thinking "look at all the items in the view to..." - stop right there ;)
<karni> Saviq: Nopes. I was thinking in terms of adding that invisible Label to test wheter text was same as card header title, and base the card header layout on that. I also know that if I wanted to traverse all model items, I wouldn't be doing that in this part of code :) So, not what I thought, no worries :)
<Saviq> karni, not following - what would that invisible Label do that the visible one wouldn't?
<karni> Saviq: no Wrap, single line, possibly elide. if text in that label is !== text in title labe, means we have 2 lines in the card header title labe.
<karni> *label
<karni> Something along that line, you prolly get the point now :)
<karni> It's a hack, but dirty because (if that worked) it'd require an invisible label in the tree, which I don't like either,
<karni> but like you said, seems there's no fast way to check if the text has wrapped/there's more than a single line in title label.
<karni> oh yeah. Text.truncated: bool
<Saviq> karni, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-text.html#lineCount-prop
<karni> haha omg. Can I hide now ;)?
<Saviq> karni, ;)
<karni> Saviq: does that in fact return 2 for wrapped label? if so, I probably wasted ~15 of thinking. It was fun, nevertheless ;)
 * karni notes to really look better (or sleep longer)
<Saviq> karni, yes it does
<karni> neat
<Saviq> mhr3, https://launchpadlibrarian.net/162016552/buildlog_ubuntu-trusty-armhf.unity-scopes-shell_1%3A0.1.1%2B14.04.20131219.1-0~36~ubuntu14.04.1_FAILEDTOBUILD.txt.gz
<Saviq> mhr3, that means there's some version mismatch between -api and -shell, doesn't it?
<mhr3> Saviq, yea, some massive renaming was merged into -api
<mhr3> yey! :/
 * Saviq wonders why it passed on i386
<Saviq> mhr3, care to comment on bug #1267831 ?
<ubot5> bug 1267831 in unity-scopes-shell "unity-scopes-shell build problems when building against Qt 5.2" [Critical,New] https://launchpad.net/bugs/1267831
<Saviq> mhr3, maybe -shell needs a dependency version bump?
<mhr3> Saviq, wait, yea, this is weird
<mhr3> it's not about the renaming
<mhr3> Saviq, what is this even?
<mhr3> it's not trunks
<mhr3> of neither shell nor api
<Saviq> mhr3, https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+sourcepub/3765701/+listing-archive-extra
<Saviq> mhr3, might be we need -api there as well, not just -shell?
<mhr3> pff, week old branches, don't you know we change everything every week? :)
<Saviq> mhr3, 'cause it builds -shell trunk against -api released?
<Saviq> yeah
<mhr3> Saviq, it also need new unity-api
<mhr3> but with latest unity-scopes-api, -shell won't build
<Saviq> mhr3, ok be back in a few
<fginther> tsdgeos, pong
<tsdgeos> fginther: we've been having some weird results in autopiltot runs but people from #ubuntu-ci-eng are already looking into it
<tsdgeos> so nothing
<tsdgeos> :)
<fginther> tsdgeos, ok, I'll check with ci
<darklight_> Is there a chance of the panel shortcuts finally being customizable in 14.04 ? seriously why was that design ever approved in the first plae
<darklight_> s/of/for
<darklight_> Not only it's a bad design and can really anny regualr users but it can be a real showstopper for people with disabilities
<Saviq> fginther, ev registered it at https://app.asana.com/0/9505407366941/9504356304887
 * Saviq is not sure what to do with that...
<fginther> Saviq, I see it, I'm going to rerun an older unity8 binary package to see if something changed on the test system
<fginther> Saviq, or possibly a dependency
<elopio> tsdgeos: this is now ready to land:
<elopio> https://code.launchpad.net/~elopio/unity8/open_scope/+merge/201107
<darklight_> Who could I contact about this? there are bugs open but they are ignored on the target mileston has been postponed for years
<tsdgeos> elopio: cool
<Saviq> darklight_, if it's a design issue, #ubuntu-design is the place to go
<greyback> Saviq: ever seen this before: http://pastebin.ubuntu.com/6726838/
<greyback> I'm trying to run AP on a pretty clean image. unity8-autopilot package is installed
<Saviq> greyback, yeah, your command is wrong
<Saviq> greyback, -p -v unity8-autopilot
<darklight_> Saviq: well design as in feature missing or better badly implemented, would that be the best place where to ask ?
<Saviq> so it tries to install "-v" and then run "unity8-autopilot" test suite as opposed to "unity8"
<greyback> Saviq: what? That's ridiculous. -v switch is in the help
<Saviq> darklight_, I'm not sure what issue you're talking about, but sounds like yes - this needs to be looked at by designers, only then will code change
<Saviq> greyback, ORDER
<Saviq> -p -v
<Saviq> --package=-v
<greyback> Saviq: OBJECTION
<greyback> ah
<jamesh> sil2100: hi.  sorry I missed your ping -- I've been at a conference all week.  Package name change sounds fine.
<Saviq> greyback, STANDUP
<darklight_> Saviq: ok thanks, just to clarify the issue is the hardcoded shortcuts in unity
<Saviq> darklight_, got it
<sil2100> jamesh: hi! No problem, Satoris already commented - the package is preNEWed and soon it will land in the new queue
<Saviq> greyback, NOTES
<jamesh> awesome!
<Saviq> greyback, you coming?
<jamesh> was having drinks with Lennart Potering tonight, and we managed to stay civil the whole way through
<Saviq> greyback, can you hear us?
<Saviq> mhr3, added -scopes-api to the PPA, -api is already there
<mhr3> Saviq, how high prio is it to make -shell buildable again?
<mhr3> we're in the process of even more api changes
<Saviq> mhr3, ah so it's not gonna build anyway?
<mhr3> not right now, no
<Saviq> mhr3, whenever you're ready basically
<mhr3> would build yesterday :)
<Saviq> right ;)
<karni> Saviq: Should "card-size" have no influcence on the size of horizontal card size?
<Saviq> karni, it does, in vertical
<karni> Saviq: but not for horizontal cards, right?
<Saviq> karni, in horizontal the card width is hardcoded at 40GU
<karni> sweet ;)
<Saviq> or 38
<Saviq> large
<karni> right
<fginther> Saviq, have you any clue as to what the unity8 SEGVs are caused by?
<tsdgeos> fginther: i don't think we do
<tsdgeos> fginther: as a matter of fact stuff works in our desktops just fine
<tsdgeos> fginther: and there's no backtrace logging in those machines, is there?
<fginther> Saviq, I reran a test that passed before, and now it fails. I also looked at the installed packages between a good and bad run and found no differences. Even checked that the test machine was the same
<fginther> tsdgeos, there is no reason for crashes to be disabled here, but perhaps they are. I'll check into it
<tsdgeos> or at least i couldn't find where they were stored :D
<Saviq> fginther, yeah, I'm completely lost, it just started happening overnight
<Saviq> fginther, if possible, it would be good to take down a machine to try and reproduce on it to at least get the .crash file
<tsdgeos> dandrader: https://code.launchpad.net/~aacid/unity8/journal_test_cmake_bugfix/+merge/201202
<tsdgeos> and i think i found another
<tsdgeos> you shouldn't ask for those last minute refactoring things :D
<Saviq> mhr3, does that FTBFS ring a bell https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+sourcepub/3811744/+listing-archive-extra ?
<karni> mhr3: Just FYI, had this tiny patch for that first item being large (wrapped title) but it fails miserably a potential OEM customization. We'll need to measure it once for the whole category instead as Michal suggested, so that change would be elsewhere :( http://paste.ubuntu.com/6726961/
<tsdgeos> Saviq: have you manually merged https://code.launchpad.net/~aacid/unity8/journal_test_cmake_bugfix/+merge/201202 alraedy?
<Saviq> tsdgeos, no
<mhr3> Saviq, unfortunately, no
<Saviq> tsdgeos, I wait for the autolanding job to complete
<tsdgeos> Saviq: ok, because i just added a new fix
<mhr3> Saviq, opening bug about it
<mhr3> karni, eeek :P
<mhr3> karni, i guess we shouldn't use grid if we want it to look good
<mhr3> needs something more dynamic
<karni> mhr3: Well, I was assuming you specifically wanted to test the grid with horizontal cards. That is, indeed, a bug. Just needs to be solved elsewhere.
<karni> mhr3: That's a configuration a 3rd party dev can choose, thus we need to get it right (at some point in time)
<karni> :)
<mhr3> karni, i was just testing the horizontal layout, but i guess that grid implies that each item is same height and therefore this can happen
<karni> mhr3: ok, I realized you meant that all cards have same height because of the first one. right.
<mhr3> still, you're right that the cards should try to look similar when possible :)
<karni> mhr3: I think we'll fix this on the category/card level, so a grid with horizontal cards would look just fine. Nevertheless, it would be interesting to allow horizontal cards of different heights indeed.
<mhr3> +1
<Saviq> karni, it's allowed already - just add a summary of different length
<Saviq> karni, that's one of the use cases for VJournal
<karni> d'oh, of course :)
<Saviq> karni, but TBH I'm starting to feel like the "mascot is the height of the header" rule is just wrong
<mhr3> Saviq, that build was with 5.2, right?
<karni> Saviq: I don't think I have an opinion on that ATM.
<sil2100> jamesh: are you still around?
<fginther> Saviq, tsdgeos, I'm not much closer on the unity8 problem. There is apparently just updated today version of apport that should help to collect the crash, but I've got to put some work into setting this up
<fginther> Saviq, tsdgeos, if you need to make progress on unity8 MPs, we may need to disable that job
<Saviq> fginther, we're fine
<Saviq> fginther, I've been forcing generic-land
<Saviq> fginther, so it's not blocking us
<Saviq> fginther, and it's EOW now
<fginther> Saviq, thanks, I'll send an update if I get anywhere today
#ubuntu-unity 2014-01-11
<Blazetama_> hello :D
<wadechandler> I'm trying to start looking at some issues related to Unity and auto reveal of an auto hidden launcher, can anyone tell me where the logic is for the launcher and if the event (possibly event system) which causes the launcher to reveal is in the same or different package? I have been look around here:
<wadechandler> https://unity.ubuntu.com/getinvolved/development/
<wadechandler> clicking through different things etc
<wadechandler> and I don't want to grab them all unless I absolutely must
<wadechandler> noticed "Launcher" under libunity, so looking into that, but any pointers will be greatly appreciated; many thanks in advance
#ubuntu-unity 2014-01-12
<FFForever> Hey hey. After some messing around with graphics drivers and disabling my second monitor I noticed that my clock on the top-right is missing. How can I add it back?
<YOURBESTFRIEND> hello, I need help fixing some bug
#ubuntu-unity 2015-01-05
<MacSlow> Greetings folks and a happy new year!
<tsdgeos> Happy new year folks :)
<MacSlow> hey there tsdgeos... thanks and dito :)
<Saviq> good mornin'
<MacSlow> hey Saviq... happy new year :)
<Saviq> MacSlow, thanks, right back at you, you had a reminder set up to come back to work after a month? ;)
<MacSlow> Saviq, hehe... not that was not needed :)
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/unitySortFilterProxyQML/+merge/245198 this one's "good"
<tsdgeos> someone/we copied a class to the sdk with not all the features and the same name
<tsdgeos> *boom*
<Saviq> tsdgeos, heh, interesting
<tsdgeos> interestingly it works in Qt5.3
<tsdgeos> but it's just sheer luck
<Saviq> mzanetti, hi!, re: one staging branch, thought that would be cleaner to not have separate branches per silo
<Saviq> mzanetti, but seeing as *all* the linked bugs are shown in the MPs, and that sometimes we need to do more than one at a time, I'm not too sure any more
<Saviq> tsdgeos, somewhat related to bug #1403045, it looks like there's a second (empty) header on top of the Manage header
<ubot5> bug 1403045 in unity8 (Ubuntu) "Bottom edge doesn't follow finger" [Undecided,New] https://launchpad.net/bugs/1403045
<tsdgeos> really?
<tsdgeos> that's weird
<Saviq> tsdgeos, only when moving
<tsdgeos> how do you see it?
<Saviq> tsdgeos, as soon as I touch the bottom
<Saviq> tsdgeos, it appears
<Saviq> https://owncloud.sawicz.net/public.php?service=files&t=280d4ae6e435e06253e3f75f54c9adf2
<Saviq> tsdgeos, â
<tsdgeos> what
<tsdgeos> is
<tsdgeos> that
<tsdgeos> Saviq: rtm? vivid?
<Saviq> tsdgeos, vivid
 * Saviq files a bug
 * tsdgeos wonders how did that happen
<Saviq> tsdgeos, bug #1407620
<ubot5> bug 1407620 in unity8 (Ubuntu) "Large empty space above Manage header during bottom gesture" [Medium,Triaged] https://launchpad.net/bugs/1407620
<tsdgeos> that's ultra weird
<Saviq> greyback, o/ Athbhliain faoi mhaise dhuit!
<tsdgeos> ah i know what's wrong
<tsdgeos> it's the upper part of the header
<greyback> Saviq: SzczÄÅliwego Nowego Roku dla Ciebie
<tsdgeos> like the search
<tsdgeos> wonder why it's there now
<Saviq> tsdgeos, yup, that's what I thought
<tsdgeos> maybe it broke when we disabled search
 * greyback closes the google translate tab
<Saviq> ;)
<tsdgeos> Saviq: i think mzanetti is not back until tomorrow
<Saviq> tsdgeos, yeah yeah
<tsdgeos> Saviq: i resorted to clipping the header
<tsdgeos> https://code.launchpad.net/~aacid/unity8/clipScopesListHeader/+merge/245556
<Saviq> tsdgeos, yeah, sounds fine
<tsdgeos> i wonder if this is what mzanetti was complaining about with the other bug
<Saviq> tsdgeos, no
<tsdgeos> ah no
<tsdgeos> you can actually have a huge gap too
<Saviq> tsdgeos, what he said is that you get a large gap between your finger and the top of manage dash
<Saviq> yeah
<Saviq> tsdgeos, barring that, maybe we can change visibility based on the contents inside PageHeader.qml?
<tsdgeos> it's hard
<tsdgeos> since it's a full height background we actually need
<tsdgeos> for the lower part
<tsdgeos> so would need to split into two backgrounds
<tsdgeos> not sure it's worth it tbh
<Saviq> ah yeah
<Saviq> that's fine then
<mzanetti> Saviq: +1 on the "not so sure on one staging branch", exactly because of that weirdness with the linked bugs
<mzanetti> but nothing that really concerns me until Wed
<mzanetti> :)
<facubatista> Hola
<tsdgeos> Mirv: did you do anything regarding qt 5.4?
<Mirv> tsdgeos: I added some modules during vacation on request, but otherwise no and it should be still usable (nothing has landed so nothing currently needs a rebuild)
<tsdgeos> oki
<tsdgeos> so we still are black on arm
<Mirv> yes
<Saviq> cwayne, hey in the new year, could you have a look at bug #1394614 and add an appropriate task / file a bug in the appropriate project?
<ubot5> bug 1394614 in unity8 (Ubuntu) "Cached results stay in scopes even with no internet" [Undecided,Incomplete] https://launchpad.net/bugs/1394614
<cwayne> err I'll take a look Saviq
<cwayne> but it seems to me that we'd want caching there, no?
<cwayne> why would we want completely blank scopes :P
<Saviq> cwayne, it's not me who filed the bug ;)
<cwayne> fair point :)
<Saviq> cwayne, someone wrote a manual testcase that said it should not cache
<davidcalle> cwayne, with a little timestamp on it for the last updated time, pretty please :p
<cwayne> yeah, just saw that, I'll chase this down with them
<cwayne> davidcalle: good idea
<cwayne> i'll chase down some people and see what the deal is
<cwayne> and happy new year everyone!
<davidcalle> cwayne, Saviq, indeed, happy new year :)
<Saviq> o/
<Saviq> elopio, hey, can you please run http://people.canonical.com/~msawicz/unity8/strip-tags.py on lp:~canonical-platform-qa/unity8/edges_demo_test and any local unity8 checkouts
<Saviq> Fuckin' Spaniards! (https://www.youtube.com/watch?v=IznxHE2pVxc) ;D
<kgunn> happy new year all
<facubatista> kgunn, happy new year!
<mterry> kgunn, I'm already bored with 2015, when will we release a beta of 2016 to run?
<kgunn> mterry: hehe, that didn't take long
<cwayne> pete-woods: btw i moved that vimeo bug from hanloon to https://bugs.launchpad.net/unity-scope-vimeo/+bug/1407691
<ubot5> Launchpad bug 1407691 in Vimeo Scope "Vimeo scope doesnt show my videos" [Undecided,New]
<pete-woods> cwayne: that's a bit of a "change the design please" request, but I can add a new feature to display uploaded videos, too. at the moment it (correctly) shows your feed
<pete-woods> i.e. the channels you have subscribed to
<pete-woods> would be fairly easy to add a new section or department to represent uploaded videos
<cwayne> pete-woods: yeah, not sure if it's a wont-fix or what, just knew it wasn't hanloon :)
<pete-woods> okay, cool
<elopio> Saviq: done.
<mterry> is jenkins down / broken?  Old deb links in MPs are giving me a 404 and it doens't seem to be generating new debs after I've added a commit to the MP
<Saviq> mterry, which MP?
<Saviq> mterry, seems to work somewhat http://s-jenkins.ubuntu-ci:8080/job/unity8-ci/
<Saviq> mterry, old links got purged, I think old jobs get purged after some time
<mterry> Saviq, hrm my MP is https://code.launchpad.net/~mterry/unity8/tutorial-refactor/+merge/239874 (with a commit from 12/23 that never got built)
<Saviq> mterry, let me kick it manually
<mterry> Saviq, OK thanks!  And it's normal that the old debs linked in that MP would be 404 now?  (we clean them out occasionally I guess)
<Saviq> mterry, yeah, as artifacts they get purged with old jobs
<Saviq> mterry, it's building in http://s-jenkins.ubuntu-ci:8080/job/unity8-ci/5074/console
<mterry> thanks
<greyback_> are qmlui tests a bit unstable atm?
<tsdgeos> are they? last time i checked they were fine
<greyback_> just got a fail with https://code.launchpad.net/~gerboland/unity8/async-dbus-dashcomm/+merge/244892 - no idea why yet.
<kgunn> greyback_: random curiosity, what the difference between "unstable" and "failed"...is it all the Qwarns ?
<greyback_> kgunn: it seems if a test fails, the test job is marked as unstable. jenkins makes that call. It's not looking deeply into the test case, just reads the return code to see if success of fail
<tsdgeos> greyback_: interesting, other jobs from today had this passing afaik
<greyback_> tsdgeos: yeah it's odd, maybe my change breaks it. Am trying to repro locally now
<Saviq> kgunn, failed usually means that the process of testing failed, so there's no test results (or they're incomplete etc.)
<kgunn> Saviq: thanks...makes sense....cause all the summaries do say "0 failed"....but i see stuff like "connection refused failed" in the body
<kgunn> of output
<Saviq> kgunn, the top job (unity8-ci, the one that reports on MPs) basically has no unstable, if any downstream job is not success, the upstream job goes failed
<Saviq> kgunn, your own test suite would have to determine whether warnings are ok or not (that's what UITK do, any new warnings fail the test)
<om26er> mzanetti, Hey! back ?
<greyback_> om26er: he's not. He's back on Wed I think
<om26er> greyback_, hmm, ok. I'll find him then.
<Saviq> kgunn, bug #1407708 maybe looks similar to the issue V reported
<ubot5> bug 1407708 in unity8 (Ubuntu) "Additionally Installed scopes disappear on reboot" [Undecided,New] https://launchpad.net/bugs/1407708
<kgunn> was just testing to confirm it...
<Saviq> mzanetti, I know you're not here, but as it's your pet peeve - input appreciated on bug #1407730
<ubot5> bug 1407730 in webbrowser-app (Ubuntu) "Support multiple app instances in the spread" [Undecided,New] https://launchpad.net/bugs/1407730
<om26er> Saviq, during the holidays, I have discovered an issue where dash is black, the process keeps running but dash never shows.
<Saviq> om26er, the dash isn't black, the dash simply isn't there, no?
<om26er> Saviq, yes, that.
<Saviq> bug #1394208
<ubot5> bug 1394208 in Canonical System Image "Unity8 unable to find the dash, which is also running in the background" [Critical,In progress] https://launchpad.net/bugs/1394208
<mterry> How do I tell what the post-transformation values for x,y are if an Item defines a set of Transform elements in its transform field?
<mterry> (And/or is there a way to query what the rendered x,y are?)
#ubuntu-unity 2015-01-06
<penghuan> hi, all , i'm not use unity7 but i want to use bamf, what's   the best way to start bamfdaemon?
<larsu> penghuan: it ships with a .service file, so you can activate it via D-Bus
<penghuan> larsu, thanks! i'll try that
<seb128> hey unity hackers, happy new year!
<seb128> so back from holidays, I updated my vivid desktop and now the desktop unity8 session fails to open any applications, is that a known issue?
<seb128> it's running in "windows mode", click on an app display a window with a title and spinner for like a second and then it closes
<seb128> oh wait, I might be on systemd again and have the ual/cgmanager issue
<seb128> yeah, that was it
<seb128> gtk apps still fail to load though
<greyback> seb128: have patch for the rendering issue (https://code.launchpad.net/~gerboland/qtmir/fix-GTK-rendering/) but I'm not fully clear as to why it works yet
<seb128> greyback, great, nice to see it's being worked on at least ;-)
<facubatista> Hola
<facubatista> rsalveti, ping; having problems with rest scopes?
<Saviq> mterry, re: transformations, I don't think there is a way actually
<Saviq> mterry, IIUC, all this happens on the GPU directly
<mterry> Cimi, tutorial-redesign should be ready for review
<Cimi> mterry, refactor or redesign?
<Cimi> or both?
<mterry> Cimi, are there both?  I must have accidentally pushed twice with different names...
<mterry> let me see which is the real one
<mterry> Cimi, no, just -refactor
<Cimi> mterry, there is -refactor
<Cimi> mterry, and -new-screens
<mterry> Cimi, -new-screens isn't ready yet
<mterry> It doesn't have an MP
<Cimi> mterry, ok I will review the other
<mterry> But -refactor does
<Cimi> mterry, yeah
<mterry> Cimi, design is reviewing -refactor too, should have their comments soon
<mterry> mzanetti, I am experiencing some performance issues with the right-edge animations in my branch that uses a tweaked version of PhoneStage for the edge tutorials.  It happens in phase 0, early in the drag, but smooths out fine afterward.  Have you seen anything similar, or have any guesses at where I should look for likely extra calculations in that area?
<greyback> mterry: he's off until tomorrow
<mterry> greyback, ah thx
#ubuntu-unity 2015-01-07
<mzanetti> o/
<tsdgeos> mzanetti: welcome bac
<tsdgeos> k
<Saviq> mzanetti, \o
<MacSlow> mzanetti, hey there
<MacSlow> mzanetti, happy new year btw
<mzanetti> MacSlow: hey, thanks. happy new year you too
<Cimi> tsdgeos, I tested your branches, they seem fine
<Cimi> tsdgeos, which tests you said you wanted to add?
<tsdgeos> the one i added to https://code.launchpad.net/~aacid/unity8/departmentListHorizontalScroll/+merge/245580
<Cimi> ok
<tsdgeos> which failed ^_^
<Cimi> tsdgeos, yeah saw that
<tsdgeos> it should be running again after my last commit
<tsdgeos> let's see how it goes
<tsdgeos> i couldn't reproduce it failing here even in a loop
<Cimi> do uou think is possible to fix the pageheader height instead clipping?
<Cimi> on the other branch
<tsdgeos> not as the code stands now
<Cimi> rebooting router, back in a min
<tsdgeos> Mirv: ping
<Mirv> tsdgeos: pong
<tsdgeos> Mirv: about the qt5.4 issue i was wondering if you could rebuild the stuff with http://paste.ubuntu.com/9686974/ and removing the -reduce-relocations from debian/rules
<tsdgeos> since this was one of the things that was causing problems in 5.3 and then our linker got fixed
<tsdgeos> but maybe not totally fixed?
<tsdgeos> i tried compiling myself but qtdeclarative-opensource-src is failing to dpkg-package for some reason :/
<tsdgeos> grrr stupid https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/245/console failed
 * tsdgeos hits rebuild
<Mirv> tsdgeos: right.. so that paste is actually the manual our patch reverting upstream lines since we got the updated binutils.
<Mirv> so I can comment out the patch. plus comment out the configure option.
<tsdgeos> right
<tsdgeos> see if it helps
<Mirv> I'm in a middle of enabling qtbase tests but I can also comment out that..
<tsdgeos> oki
<tsdgeos> greyback: did you have time to test https://code.launchpad.net/~aacid/qtmir/create_observer_sooner/+merge/244622 ?
<greyback> tsdgeos: hey, no I must do that now
<greyback> had slipped my mind
<Mirv> tsdgeos: 5.4.0+dfsg-4ubuntu1~vivid1~test2 building with http://pastebin.ubuntu.com/9687032/
<tsdgeos> oki
<tsdgeos> greyback: oki
<tsdgeos> MacSlow: how's https://code.launchpad.net/~macslow/unity8/swipe-dismiss-snap-decisions/+merge/233347 going?
<MacSlow> tsdgeos, working on it to get to work
<tsdgeos> :)
<MacSlow> tsdgeos, setting actions is giving me a headache atm
<MacSlow> getting segfaults where I didn't expect them... especially since the real (non-mock) implemenation works flawlessly
<tsdgeos> :(
<MacSlow> tsdgeos, but I'm getting there
<MacSlow> two of three segfaults are already eliminated
<tsdgeos> MacSlow|lunch: https://code.launchpad.net/~pitti/unity8/notify-api-fix/+merge/245643 is for you, right?
<Saviq> tsdgeos, nah, actually for me
<tsdgeos> oh ok
<Saviq> ACKed
<greyback_> tsdgeos: could you add checklist (https://wiki.ubuntu.com/Process/Merges/Checklists/QtMir) to https://code.launchpad.net/~aacid/qtmir/create_observer_sooner/+merge/244622 plz
<tsdgeos> greyback_: sure
<greyback_> ta
<MacSlow> Is MediaPlayer a QML-object defined unity8 or Qt itself?
<MacSlow> doh... defined by unity8...
<tsdgeos> Mirv: is there a simple way to trigger a rebuild of unity8 and qtdeclarative in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-005/+packages ?
<tsdgeos> now that the new qtbase has been built
<facubatista> Hola
<facubatista> rsalveti, ping; having problems with rest scopes?
<Saviq> tsdgeos, Mirv will have to upload bumped versions
<Cimi> mterry, test failed on jenkins
<Saviq> tsdgeos, you can't rebuild in PPAs as they prevent two different binaries with the same version
<mterry> Cimi, yeah I've been looking at that this morning
<tsdgeos> makes sense i guess
<Cimi> ok!
<Saviq> Cimi, please leave a vote on https://code.launchpad.net/~mterry/unity8/wizard-passphrase-osk/+merge/244358 apart from top-approving
<Cimi> Saviq, ok
<Saviq> greyback_, few more reasons for hash -d ;D â you can type "foo" to `cd ~foo` (where foo is how you named the "shortcut"), but even better - it also works in tab-completion, foo<tab> will autocomplete to files from foo etc.
<Saviq> ;)
<greyback_> hmmm
<greyback_> Saviq: can you use that in a command. e.g. to overwrite a file, can you do "cp thisFile foo<tab>"
<Saviq> greyback_, yeah
<Saviq> greyback_, zsh expands foo
<greyback_> hmm, that is nice
<Saviq> greyback_, *might* need to prepend ~ in this case
<Saviq> no ~ needed for some built-ins like cd apparently
<Saviq> so ~foo<tab>
<MacSlow> at least notifications still work on the device... testing unity8's notifications locally on the desktop always fails
<mzanetti> hey, I can't ./run.sh any more... anyone knows already what's going on?
<tsdgeos> i haven't run run for a long time
<tsdgeos> directly the binary i want
<mterry> Cimi, ok tests fixed, let's see what jenkins says.  I also filed the MP for the tutorial-new-screens branch yesterday, it's ready
<rsalveti> facubatista: the problem I had with the today scopes is that it wasn't adding the weather data, even when I was online (not sure if this is the one you're talking about)
<rsalveti> and the remote scopes were also not available, so cwayne1 said that this could be the reason
<Cimi> mterry, what shall I review in the tutorial refactor??
<facubatista> rsalveti, __lucio__ told me you weren't seeing any remote scopes...
<Cimi> mterry, design too? It looks nice but doesn't work well
<mterry> Cimi, doesn't work well?
<rsalveti> facubatista: yeah, worked after a clean flash, will let you know if I get to reproduce this again
<Cimi> mterry, I kept tapping the orange circle to swipe
<Cimi> mterry, before I realised I need to swipe from the edge on the ubuntu phone
<Cimi> mterry, has this been user tested?
<mterry> Cimi, I don't know whether they've user tested
<Cimi> mterry, let's wait for user testing
<mterry> Cimi, but as for what to review, I'd say just that my code isn't crazy and that it works.  I think design can handle their side
<Cimi> mterry, ok, but let's be sure we ask for user test
<mterry> Cimi, no let's not wait for user testing... Design will review the MP and sign off or not on whether they like it
<facubatista> rsalveti, ok! just let me know about *any* issue with remote scopes, I should be of help :)
<Cimi> mterry, I think we should user test, to avoid what happened with the scopes overview
<rsalveti> facubatista: great, thanks
<Cimi> mterry, so ok, I will approve code wise, but let's make sure we request that before merging
<mterry> Cimi, I'm only going to wait for Design to say it's OK.  I don't want to second guess their methods
<tsdgeos> Saviq: ok, i know what's going on with the crash on https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/246/consoleFull something is going to slow and it's crashing on a waitForRender
<tsdgeos> we should reallly make waitForRender not crash on empty items
<Saviq> tsdgeos, sounds like an easy thing to do in UnityTestCase
<Saviq> with the exception that it's going to be tricky to call the "upstream" waitForRendering
<Cimi> mterry, might go to office tomorrow if my back feels better, I can ask...
<tsdgeos> Saviq: nah it's easy too
<tsdgeos> i'll add it in and propose the fix upstream, see what they think
<Saviq> coolz
<mzanetti> tsdgeos: how do you do with the lightdm plugins then?
<mzanetti> tsdgeos: you always type the full LD_LIBRARY_PATH thing?
<tsdgeos> don't need them for unity8-dash
<tsdgeos> don't run unity8 much ^:^
<mzanetti> ah
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/waitForRenderingNoCrash/+merge/245747
<Saviq> tsdgeos, wanna add semicolons?
<tsdgeos> Saviq: to where?
<Saviq> tsdgeos, to end of lines ;)
<tsdgeos> ah
<tsdgeos> i just copied from the qt code
<tsdgeos> but sure will add
<Saviq> it's not like we're consistent about them :/
<tsdgeos> added
<Saviq> tx
<mzanetti> Saviq: so, does ./run.sh work for you?
<mzanetti> for me it runs the binary, but it doesn't show up, and it can't be killed any more except with -9
<Saviq> mzanetti, same here yeah
<Saviq> mzanetti, ah!
<Saviq> pkill -SIGCONT unity8
<Saviq> hmm wonder why upstart isn't doing it
<MacSlow> Saviq, initctl works for me, but takes ages...
<mzanetti> ah ok
<mzanetti> mterry: hey, do we still need all that lightdm LD path fun? I wonder if this couldn't be dropped at some point
<Saviq> mzanetti, there's a branch from dandrader dealing with that
<mzanetti> ah, great
<mterry> Saviq, mzanetti: except it doesn't drop the LD stuff, just consolidates it a bit.  I think we still want the LD stuff
<Saviq> mzanetti, that's unless you want to type your password in every time you start unity8 locally ;)
<mzanetti> fair enough
<Saviq> mzanetti, so what happens is that we emit SIGSTOP twice for some reason
<mzanetti> o_O
<Saviq> greyback_, ideas â?
<mzanetti> greyback_: didn't we change something there before hoidays?
<greyback_> yep
<mzanetti> we messed up
<greyback_> yep
<Saviq> ugh
<greyback_> yep
<mzanetti> lol
<Saviq> it's there in main as well as AppMan
<mzanetti> I guess we didn't update the fake AppMan, only the real one?
<Saviq> who's prepping an MP?
<Saviq> and why did we skip standup? :D
<mzanetti> we didn't
<mzanetti> just you did
<mzanetti> :P
<Saviq> :P
<greyback_> qtmir emits SIGSTOP only if UNITY_MIR_EMITS_SIGSTOP==1
<greyback_> I suspect that should not be set in the run script maybe? /doesn't remember
<Saviq> greyback_, yeah, but we have another raise in main() as well
<greyback_> Saviq: yeah we needed that for when a mock appman was used instead of real
<Saviq> greyback_, yeah, but mock appman has raise too now
<greyback_> oh
<greyback_> then main can drop it
<Saviq> yes
<Saviq> I just wonder how does it work outside of run.sh...
<greyback_> how do AP tests work??
<Saviq> indeed
<Saviq> ah
<Saviq> they're ran on Mir
<Saviq> and the main() one only acted on !Mir
<Saviq> and we're not running the AP tests on x86 for a while now
<greyback_> not all AP tests run on Mir tho
<Saviq> they do
<greyback_> oh yeah, ignore me
<Saviq> greyback_, you MP or do I?
<greyback_> some just use mock appman
<Saviq> yeah, which is why we needed the raise in mock appman too
<greyback_> Saviq: I'm trying ot focus on a critical bug right now, can do after
<Saviq> greyback_, I'll do, then
<greyback_> ok thanks
<Saviq> greyback_, let me know if you need help with the wakelock
<greyback_> Saviq: wakelock the easy bit, hard bit making sure it held only when needed
<Saviq> greyback_, bird's eye view here ;)
<greyback_> a drone more comes to mind...
<tsdgeos> Cimi: https://code.launchpad.net/~aacid/unity8/departmentListHorizontalScroll/+merge/245580 passes now
<mterry> Ugh, my krillin is Out Of Juice after the holidays
<Saviq> mterry, it lasted a whole two weeks of dogfooding? our battery usage improved a lot! ;P
<tsdgeos> easy cleanup https://code.launchpad.net/~aacid/unity8/cleanupTypeString/+merge/245756
<mterry> Saviq, :)
<tsdgeos> Saviq: need to land stuff! https://code.launchpad.net/~unity-team/unity8/trunk/+activereviews is growing :D
<Saviq> tsdgeos, yup, was just restarting failed ci jobs earlier today
<Saviq> tsdgeos, want a green on every MP
<tsdgeos> oki
<tsdgeos> we still have unstability
<Saviq> mzanetti, https://code.launchpad.net/~saviq/unity8/no-sigstop-main/+merge/245758
<Saviq> tsdgeos, yeah, I saw a few weird Mir crashes today, trying to see if I can reproduce locally
<Saviq> but stuff's a bit difficult as we're 160 packages behind vivid in latest devel-proposed image :/
<mhall119> thostr_: does the Dash cache GPS data for scopes? I noticed while traveling over the holidays that my scopes were getting old GPS data from 30 miles away, where I was over an hour ago
<mhall119> it was happening on all scopes that use location data, so I don't think it's the scopes doing it
<mhall119> (I would expect at least one of them to not do it if that were the case)
<mhall119> even pulling down to refresh didn't change their location-based results
<tsdgeos> Saviq: wow 160 :S
<Saviq> tsdgeos, yeah
<thostr_> mhall119: scopes themselves cannot access location data directly but get that passed on by the scopes FW, that's why all scopes have same location
<Saviq> mhall119, I imagine the location service does the caching
<thostr_> mhall119: so, question is rather why the location was not updated in either the system or in scopes machinery
<thostr_> pete-woods: ^ when do we trigger/request a new location? on every query?
<mhall119> thostr_: the sensor status app was showing updated GPS coordinates
<pete-woods> thostr_: when any scope that has requested location is active, we start a GPS session
<pete-woods> while a session is active the backend is always tracking the current location
<pete-woods> however last time I checked, it took quite some time before a real GPS location was received
<pete-woods> so we most often fall back to geo IP
<pete-woods> each query dispatch we retrieve the current location from the GPS session
<pete-woods> so in theory it should be current
<kgunn> tsdgeos: so is qt using the disk writes somehow for animations/event handling ?
<tsdgeos> something i
<tsdgeos> s
<kgunn> wrt your bug....it's just weird
<tsdgeos> i didn't investigate
<kgunn> odd...means there should really be a reserve
<Saviq> kgunn, well, the problem with reserve is that your shell is running as you, so if the shell can write, so can you
<Saviq> kgunn, we'd have to make sure we're writing outside of /home for whatever we need to be writing
<Saviq> and not write at all what we don't actually need to be writing
<tsdgeos> yep
<mzanetti> don't we cache in ~?
<mzanetti> and well, write logs and everything
<tsdgeos> mzanetti: qml cache?
<mzanetti> tsdgeos: I think we have at least an image cache for unity + dash in there
<tsdgeos> mzanetti: not being able to write logs should not make everything not work :D
<mzanetti> and yeah, prolly qml caching too
<tsdgeos> same for the cache
<Saviq> yeah, anything we *really* need write access to should be outside of /home partition
<kgunn> tsdgeos: i agree about logs...but i could see cache being an issue
<Saviq> and any caches, logging should just fail
<mzanetti> sure, the question is if we actually expire the cache
<mzanetti> otherwise at some point it'll just stop working, no matter where
<Saviq> mzanetti, whether we do or not doesn't matter (for this problem)
<Saviq> mzanetti, the cache can stop working
<Saviq> mzanetti, the shell can not, even if cache is not writable
<mzanetti> sure
<Saviq> it's a cache after all
<kgunn> mmm yeah, you're right...cache should just fail, i see that
<mzanetti> but I would go as far as saying the cache being full with old stuff and not cache new stuff any more is a bug too :)
<Saviq> that's not going far
<kgunn> ...and could be a bug someone is using cache wrongly
<Saviq> mzanetti, in any case, as far as the QML cache goes, it's cleared on upgrade
<Saviq> the network cache is max 50MB right now, so old things are expires
<Saviq> d
<mzanetti> ok
<Saviq> (and tsdgeos was on vivid, where the QML cache doesn't exist yet IIRC)
<kgunn> really?
<Saviq> so anyway, one problem is why it filled up
 * Saviq checks
<mzanetti> +1. really?
<mzanetti> :)
<mzanetti> yeah, the other is it should still work somewhat
<kgunn> work, just shitty :)
<tsdgeos> Saviq: well it filled up because i copied lots of stuff
<tsdgeos> that's totally my fault
<kgunn> hehe
 * kgunn wishes more users were like tsdgeos
<Saviq> tsdgeos, sure, but there's other stuff we're writing to $HOME
<Saviq> logs are rotated, but only on session start, if your session lasts for a year or something
<mzanetti> this seems like a bug that's to be fixed thoughout the system actually
<tsdgeos> sure
<Saviq> kgunn, yeah, no QML compilation in vivid
<kgunn> noted
<kgunn> glad to hear, explains poor perf i saw when testing too
#ubuntu-unity 2015-01-08
<coltim> hi - I'm having an issue with my 14.10 unity and was wondering if this would be an appropriate place to seek assistance
<penghuan> does libbamf can be use in python like libwnck
<Saviq> penghuan, there's GI bindings for bamf, so you definitely can use it, whether that's "like libwnck" I'm not sure
<facubatista> Holas
<MacSlow> facubatista, ola
<facubatista> MacSlow, hey :)
<tsdgeos> facubatista: isn't it early for your daily hola?
<facubatista> tsdgeos, it is... but couldn't sleep, and took the oportunity to do some work with somebody in opposite timezone :)
<tsdgeos> :)
<tsdgeos> it's a good thing we're spread and you can use your sleeplessness
<facubatista> :D
<penghuan> Saviq, thanks! gi binding is enough for me
<tsdgeos> Mirv: Saviq: good news \o/
<tsdgeos> ppa5 doesn't have the black screen of death
<tsdgeos> so it's really the reduce-relocations bug that crept up
<tsdgeos> now we need to find someone with ld expertise i guess
<Mirv> tsdgeos: \o/ so even without qtdeclarative and unity8 rebuild? I did qtdeclarative rebuild 3h ago but because PPA publishings were broken (until now it's slowly getting back working) it didn't get visible
<tsdgeos> Mirv: yep
<Mirv> tsdgeos: so it's that removing of reduce-relocations, what about the removing of the -Bsymbolic option?
<tsdgeos> unity8 still doesn't work because needs https://code.launchpad.net/~aacid/unity8/unitySortFilterProxyQML
<tsdgeos> Mirv: reduce relocations does remove the bsymbolic
<tsdgeos> or the other way around
<tsdgeos> not sure
<Mirv> I mean, also that patch enabling bsymbolic on armhf was disabled, in addition to removing reduce-relocations. I'm first to admit I've no idea about your debugging craze in December and how these two things related to each other :) I'm just wondering whether with the patch remaining in use, but reduce-relocations still removed, the result would be the same or if they go hand in hand.
<tsdgeos> they are the same thing
<tsdgeos> see http://paste.ubuntu.com/9692057/
<tsdgeos> basically reduce_relocations means using bsymbolic
<tsdgeos> so if we remove the patch to enable bsymbolic we need to remove the reduce_relocations call too
<Mirv> the patch only affects the test http://is.gd/XFELcp - so my understanding would be that with the patch intact, it allows using reduce-relocations on non-x86 (so that it has an effect). so for armhf, same result for armhf could be achieved by keeping reduce-relocations (enable bsymbolic) but removing the patch so that the bsymbolic test would always return fail on armhf
<Mirv> anyhow, we most of all care about armhf so debugging that so that the feature could be re-enabled would be nice
<tsdgeos> you're going to need someone that understands the linker
<tsdgeos> if you revert http://is.gd/XFELcp but keep the reduce-relocations in configure
<tsdgeos> the armhf build fail
<tsdgeos> saying "-reduce-relocations was requested but this compiler does not support it"
<tsdgeos> so if you want reduce-relocations on non-arm (which i guess we do) you need two different configure calls, one for arm and the other for non-arm
<Mirv> oh, ok! thanks for explaining.
<Mirv> that's of course probably how I ended up with that patch in the first place in May for 5.3.0... just forgotten about it
<mzanetti> how can I make the tutorial show up at boot?
<mzanetti> without wiping
<mzanetti> Cimi: ^
<Saviq> mzanetti, phablet-config
<mzanetti> Saviq: thanks
<tsdgeos> i cancel a CI job and it appears as failed :/
<Saviq> tsdgeos, yeah, that's unfortunate
<Saviq> tsdgeos, filed a bug #1408627
<ubot5> bug 1408627 in Ubuntu CI Services "Cancelling a -ci job should not vote "Needs fixing"" [Undecided,New] https://launchpad.net/bugs/1408627
<tsdgeos> guys do you think something like http://paste.ubuntu.com/9692360/ makes sense?
<tsdgeos> Saviq: mzanetti: greyback_: ââ
<mzanetti> tsdgeos: without this it segfaults, right?
<tsdgeos> not sure about no item
<tsdgeos> but without the item.visible
<tsdgeos> it just "clicks there"
<tsdgeos> clicking potentially somewhere else
<mzanetti> right. yeah
<Saviq> tsdgeos, sounds like a good idea to improve failure info
<tsdgeos> which if the item is not visible
<tsdgeos> it's most likely not what you wanted
<mzanetti> tsdgeos: definitely a +1 on line 9 and 10
<greyback_> is odd tho, as invisible item still has geometry
<mzanetti> on the invisible one.. not so sure
<mzanetti> I think I do that intentionally somewhere
<mzanetti> to make sure the click does not trigger anything
<tsdgeos> mzanetti: you click on something that's not visible?
<greyback_> but yeah, no point interacting with invisible things
<mzanetti> yeah well, it's usually visible
<tsdgeos> seems like abusing mouseClick
<tsdgeos> mzanetti: well then you do a expectFail
<tsdgeos> and click
<tsdgeos> maybe?
<tsdgeos> if you want to check that clicking did nothing?
<mzanetti> I still need to click, no?
<mzanetti> dunno
<tsdgeos> yeah dunno :D
<tsdgeos> i realizeed i was clicking on an invisible item on one of my tests
<mzanetti> or maybe you have a stack of mouse areas or something and want to trigger different things on different states of the app
<tsdgeos> and i would had hoped someone told me
<mzanetti> so you use the click() still on the topmost mouse area, regardlesss if that one is visible or not
<tsdgeos> instead of just going "oh sure i'll click there"
<mzanetti> I could live with both I guess
<MacSlow> Saviq: since when does the run.sh script no longer start unity8 itself, but only the dash?
<Saviq> MacSlow, since we messed up https://code.launchpad.net/~saviq/unity8/no-sigstop-main/+merge/245758
<MacSlow> Saviq, ah ok... trying... thanks
 * Cimi lunch
<tsdgeos> so for those tests i have that mouseClikcs are not being registered
<tsdgeos> i don't think what daniel did can be the culprit right? that was only for touches, right?
<mterry> Saviq, there is a (flaky) test failure in my tutorial-new-screens MP that is due to a "libIndicatorsFakeQml.so: undefined symbol: _ZN14UnityMenuModel12setModelDataERK8QVariant" error.  Now...  I've seen this myself locally for any test that loads the Shell, but it's very flaky.  I had mentioned that I see it before, but no one else could verify at the time.  Now that jenkins sees it too, I'm thinking it's a real error and not something my lapto
<mterry> p just does.  Any clues on why it would happen (and be so flaky?  seems like a race on loading libraries...?)
<Saviq> tsdgeos, yeah, touches only
<Saviq> mterry, hmm
<Saviq> mterry, sounds quite weird
 * mterry looks into it
<mterry> Saviq, ah, I think it's just a missing LD_LIBRARY_PATH pointing at the fake QMenuModel.  I don't know why it would be flaky though, I would expect consistent failure
<Saviq> mterry, indeed
<mterry> And doesn't explain why I saw that error on normal shell tests either in the past, unless we recently cleaned up that linking situation
<Saviq> mzanetti, think you could test http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-024 when it builds? I'm testing rtm
<Cimi> mterry, you added both chevron and tick png, but while for tick you used gridUnit, you used pixels for chevron
<Cimi> mterry, are those assets supposed to scale or not?
<kgunn> mterry: so rickspencer is testing the proposed fix for "power dialog on resume"....it's in silo3 for rtm
<kgunn> however, he's seeing
<mterry> uh oh
 * mterry gets an rtm device
<kgunn> it seems like the 3 things in combination that trigger this are:
<kgunn>  1. you are "roaming" on 2g because you are away from a known AP
<kgunn>  2. you get an sms when the phone is sleeping
<kgunn>  3. you try to turn on the phone while still roaming
<kgunn>  though, it could be a fluke that I had the bug with this combination twice in a row
<kgunn>  mterry so he says he was at home on wifi, then left home...so began to roam, dunno i f that matters as a precondition
<mterry> kgunn, what is the symptom?  (just the power dialog showing, or something worse, like a crash?)
<kgunn> mterry: correct...nothing other than a laggy startup + the unexpected sight of the power dialog
<kgunn> also...
<kgunn> <rickspencer3> last night, I could not even get into the phone
<kgunn>  the screen kept turning off when I tried to dismiss the dialog
<kgunn> <kgunn> oh wow...weird
<kgunn> <rickspencer3> today I just had to dismiss it a bunch of times
<rickspencer3> o/
<mterry> rickspencer3, hi!
<kgunn> mterry: did you have reliable repro steps?
<rickspencer3> hi mterry
<rickspencer3> nice to see you again!
<rickspencer3> it's been a looong time :)
<mterry> rickspencer3, is the problem that the silo did not improve *anything* or that it got better, but there are still cases where the dialog shows and it shouldn't?
<mterry> rickspencer3, :)
 * rickspencer3 assumes he has some MPs for quickly from mterrt to ack
<rickspencer3> mterry, hard to say
<mterry> rickspencer3, I wouldn't be so sure...  ;)
<rickspencer3> I would say, it didn't get better
<rickspencer3> though, the impact was way worse last night, so maybe it got better
<kgunn> rickspencer3: do you seem to see it more than most people?
<rickspencer3> kgunn, well, I was getting the issue fixed in silo 7 a lot
 * kgunn wonders if people are just dismissing, but not complaining
<mterry> rickspencer3, bummer -- it's a hard bug to reproduce, but my reproduction steps don't look anything like yours
<rickspencer3> mterry, what are your repro steps?
<mterry> rickspencer3, usually involve low-memory or high-load or huge background image for the greeter to load.  Basically anything to slow down the shell's ability to load the greeter longer than 2s, which is the threshold for the dialog to appear
<mterry> rickspencer3, but yours are telephony related
<rickspencer3> mterry, so, actually that is commiserate with my experience
<kgunn> high cpu load due to telephony?
<rickspencer3> kgunn, well, first high cpu load due to NM and location-service chatting back and forth
<rickspencer3> which was fixed in silo 7
<rickspencer3> not, it seems, based on 2 cases, that receiving an sms causes the phone to get busy
<rickspencer3> though not as busy as the NM/location problem
<rickspencer3> I came back home and plugged it into my 'puter asap, and top said that message+ was causing dbus daemon to take up 96% of a cpu core
<rickspencer3> though it quickly died away
<kgunn> mm
<rickspencer3> so, my suspicion, which experience suggests is totally wrong ...
<rickspencer3> is that receiving an sms when the phone is sleeping makes the phone busy when you try to wake it up
<rickspencer3> mterry, does that sound like it might be similar to your repro steps?
<mterry> rickspencer3, ok well good.  Sounds like we see high load as a trigger for the bug.  But bummer that the patch doesn't work for you.  I'll try testing the silo on my rtm device and seeing if I can make a better patch
<rickspencer3> mterry, but it seems like we could easily set up a test to cause high laud on resume, right?
<mterry> rickspencer3, yeah I'll see if I can make a little busy-wait script for easier reproduction
<kgunn> load giant image
<kgunn> or some such
<kgunn> thanks mterry
<mterry> kgunn, that was previous repro step, but it wasn't super reliable.  I'll see about loading cpu
<rickspencer3> now, if receiving an sms while asleep causes a cpu spike, we should also fix that ;)
<mterry> rickspencer3, either that or there's a weird correlation between sms and power dialog.  Which should also be fixed  :)
<kgunn> rickspencer3: well...i could see that, you wanna see texts right away...so burn & churn on cpu seems like that'd be a good thing
<rickspencer3> in any case, obviously the power dialog needs to be robust in the case of a busy CPU :)
<kgunn> right
<rickspencer3> kgunn, yeah, maybe you are right
<rickspencer3> maybe it's not a bug
<rickspencer3> hi jfunk, you missed all the action
<rickspencer3> jfunk, so, mterry is going to:
<rickspencer3> 1. install silo 3 and see if he can repro the issue himself with it installed
<rickspencer3> 2. try to create a test condition where the phone has high cpu load on resume so that we can make an automated test for this condition
<mterry> rickspencer3, (to be pedantic, the issue is high CPU load on suspend, not resume.   I think)
<rickspencer3> mterry, oh?
<rickspencer3> mterry, for me, this is stuff that happens on resume
<mterry> rickspencer3, well...  that's the issue my patch tries to fix.  But if the patch isn't fixing it...
<mterry> rickspencer3, well you wouldn't know, would you?  The power dialog just sits there while suspended
<rickspencer3> mterry, huh
<rickspencer3> mterry, so, I unplug my phone and put in my pocket
<rickspencer3> it doesn't know it's roaming until I leave, after it's suspended, right?
<mterry> rickspencer3, (the greeter is loaded when suspending, but if loading it takes over 2s, the power dialog shows because we never handle the "power button release" event -- that's what I *thought* was the problem.  Again, if the silo doesn't fix it, maybe more is happening
<mterry> rickspencer3, there could be a similar problem happening on resume with the power button event handle taking too long
<mterry> So maybe two bugs here with same symptom, and I only fixed one
<rickspencer3> mterry, yeah, so ..
<rickspencer3> this *only* happens to me when I leave my office or my apartment
<rickspencer3> so it seems like there is no way it could be on suspend
<mterry> rickspencer3, fair.  Like I said, I'm guessing that it can happen on both, and I've only fixed one side of it
<rickspencer3> yeah
<rickspencer3> ok, thanks mterry
<kgunn> mterry: so i think since it's on suspend....its related to this bug no ? bug https://bugs.launchpad.net/qtmir/+bug/1355173
<ubot5> Launchpad bug 1355173 in unity8 (Ubuntu) "Switching windows with a Trusted Prompt Session active loses the trusted prompt session" [Critical,In progress]
<kgunn> dang it...not that one
<mterry> phew
<mterry> :)
<kgunn> bug 1309915
<ubot5> bug 1309915 in qtmir (Ubuntu RTM) "foreground app should keep wakelock open until actual suspend happens (aka camera takes ~5 seconds to be responsive after waking phone)" [Critical,In progress] https://launchpad.net/bugs/1309915
<kgunn> that lag happens b/c apps weren't allowed to suspend but began to
<mterry> kgunn, I'm not sure if it's related to that or not...
 * kgunn remains suspicious it's related....
<kgunn> greyback__: what do you think ^ ? could that be the seed for mterry's bug ?
<kgunn> greyback__: basicallly, cpu spike causing power dialog to show on resume sometimes and the spike being caused
<kgunn> by the suspend happening on the resume...cause it didn't have time to do it on shutdown
<kgunn> sleep rather
<mterry> kgunn, well I know that CPU spike on suspend can cause it.  I'm not sure what the cause on resume is yet.  It might be triggered by CPU spike or not.  I haven't investigated that side of things yet
<jfunk> hey mterry, lmk if you need any support from the QA team in terms of AP expertise etc when you've got the steps locked down
<mterry> kgunn, jfunk: ok....  I can confirm that silo3 fixes the bug I was trying to fix...  "Slow greeter load causing the power dialog to show on suspend".  Of course now it seems there are more ways to trigger that dialog.  Let me get reproduction steps / script for ease of QA.  I think as long as the silo doesn't make anything worse, we should land it while I separately investigate other ways the dialog appears
<kgunn> mterry: +1 for me
<mterry> jfunk, kgunn, rickspencer3: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1383277/comments/18 lists my reproduction steps and a tiny script to load the CPU on a krillin.  jfunk, that script is not perfect for automation yet, it leaves detached CPU bombs hanging around that have to manually be killed.  Maybe that's "good enough" if automation is going to reboot anyway... But let me know if I should work on something more elegant
<ubot5> Launchpad bug 1383277 in Canonical System Image "Power dialog sometimes shown on resume" [Critical,In progress]
<mterry> jfunk: are you the QA contact for rtm silo 003 as well?
<Saviq> mzanetti, messages icon is only getting bright now (i.e. in vivid), no color
<mzanetti> oh
<jfunk> mterry: no, that would be in #qa just ping 'ops-team'
<jfunk> mterry: though you need to mark it as ready for QA
<jfunk> and it would show up automatically on their Qeue
<jfunk> queue
<mterry> kgunn, was this problem blocking silo 003?  Do we need to provide guidance for approving it with the caveat that it won't solve all power dialog problems?
<jfunk> ToyKeeper: can you read mterry's comment above re: script and steps to repro
<jfunk> ToyKeeper: since I suspect you'll be the one running the verification
<mterry> jfunk, (I don't know where silo 003 was in its landing process yet)
<jfunk> ToyKeeper: if you could distill the steps to repro and evaluate the script for suitability as part of a regression run that would be swell, please email the results of your investigation to the QA team
<ToyKeeper> jfunk: Sure, I'm just working on silo 7 at the moment.
<jfunk> ToyKeeper: I thought that one was under wraps
<jfunk> ToyKeeper: when I look at the trello it doesn't appear to be in progress
<ToyKeeper> jfunk: If so, great.  Hardware just showed up for testing it, and I'm getting that set up.
<jfunk> ToyKeeper: I think it's been put to rest, the silo 3 is more "of the essence"
<jfunk> though that hardware will come in handy for future regression runs
<ToyKeeper> At least, the plan was to add it to regression testing, so I'll need to get it set up within a few days.
<jfunk> ToyKeeper: ack
<jfunk> ToyKeeper: if you could please work with mterry on this silo and help him understand what to do to move it forward
<ToyKeeper> Yup.
<ToyKeeper> It'll take a few minutes to get a krillin reflashed.
<Saviq> mterry, nothing's blocking silo 003 afaict, I just didn't manage to test it yet
<mterry> Saviq, ok cool -- I was just called in to verify that one of my branches in it did in fact work after a brief scare.  So I just wanted to make sure it's back on track.  Sounds like it's fine, we didn't stop the line for that issue yet
<ToyKeeper> mterry: BTW, what does the background image have to do with the bug?
<mterry> ToyKeeper, the technical cause is that when handling the request to suspend, the shell loads the greeter.  Which includes loading the background image.  While it loads the greeter, it blocks handling the "power button released" event.  So if we take longer than 2s, the shell thinks the user did a long press once it eventually does handle the "release" event.  And so it shows the power dialog
<mterry> ToyKeeper, so if we have a large image and are under load, we can easily take longer than 2s
<mterry> ToyKeeper, the fix I used was to not block handling the "released" event
<ToyKeeper> Makes sense.  :)
<ToyKeeper> Still catching up on scrollback.
<Saviq> mterry, on that note, I think what greyback__'s doing (keeping wakelock while any app's not suspended) will help with that as well
<Saviq> i.e. bug #1309915
<ubot5> bug 1309915 in qtmir (Ubuntu RTM) "foreground app should keep wakelock open until actual suspend happens (aka camera takes ~5 seconds to be responsive after waking phone)" [Critical,In progress] https://launchpad.net/bugs/1309915
<mterry> Saviq, in the sense of not causing load?  good
<Saviq> mterry, well, not not causing load, but rather not letting the hw go to low power mode
<ToyKeeper> mterry: Have you also run through the unity8 test plan to check if the change affects anything else?
<mterry> ToyKeeper, no not the whole thing, just played with the greeter
<ToyKeeper> It doesn't seem like the change should affect anything else, but the diff seems large enough to need the whole test plan.
<Saviq> ToyKeeper, it's in rtm silo 003 and we will test it tomorrow
<ToyKeeper> Saviq: Fair enough.  :)
<mterry> rickspencer3, kgunn: if either of you realizes what steps lead to the power dialog on resume, I'd love it.  I tried to reproduce using phonesim and a *call* while suspended (since calls are easier to fake with phonesim than sms).  But didn't seem to do anything for me
<rickspencer3> mterry, for me, I have to be away from my home or office AP
<mterry> rickspencer3, ah right, the roaming bit.  And receive an sms while roaming
<mterry> or maybe... just not on wifi..
<rickspencer3> mterry, then you decapitate he chicken and sprinkle the blood in a circle around you
 * mterry expenses a chicken
<kgunn> lol
#ubuntu-unity 2015-01-09
<tsdgeos> Saviq: so i found why the dash tests were failing
<tsdgeos> and it sucks :D
<Saviq> tsdgeos, hit me
<tsdgeos> basically the precission of some widths goes crazy and since we're clicking on 0x0 after the million transformations of pos into pos into pos
<tsdgeos> we end up clicking on 0, -0,0000somthing
<tsdgeos> i.e. out of the area
<Saviq> ..
<Saviq> doesn't our mouseClick default to the middle these days?
<tsdgeos> yeah
<tsdgeos> nope
<tsdgeos> it does with http://paste.ubuntu.com/9697260/
<Saviq> well, yeah, that's what I meant
<tsdgeos> and i'll be proposing the change upstream too
<Saviq> yeah, makes total sense
<tsdgeos> so we don't need the overrides of mouseClick on UnityTestCase
<tsdgeos> it's actually a bug in somewhere
<Saviq> right
<tsdgeos> since printing widths
<tsdgeos> some has with 640
<tsdgeos> and the child has 639.999999999999
<tsdgeos> which is what starts all the crap
<tsdgeos> but to be honest it's not like a user will notice
<tsdgeos> because if he's clicking *so* into the border
<tsdgeos> he'll expect it to fail if the click doesn't register
<tsdgeos> so i'd say click on the middle and carry on
<Saviq> +1
<Saviq> tsdgeos, are you proposing that change? I just rebuilt our vivid silo but could just as well wait for that
<tsdgeos> Saviq: i am if you give me 10 mins
<Saviq> kk
<tsdgeos> i'm also changing all those that had width/2, height/2 to have nothing
<tsdgeos> looks much cleaner
<tsdgeos> when reading
<Saviq> agreed
<tsdgeos> Saviq: and if you can get someone to review https://code.launchpad.net/~aacid/unity8/enterSpreadTest/+merge/245928 we'll get rid of the other flacky test
<tsdgeos> mzanetti: â ?
<mzanetti> ack
<Saviq> tsdgeos, mzanetti, already done
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/mouseClickMiddle/+merge/245932
<Saviq> tsdgeos, o/
<tsdgeos> hmmm
<tsdgeos> wot, lots of tests failing now
<tsdgeos> give me a sec :D
<Saviq> tsdgeos, yeah, fails here, too
<tsdgeos> i think i copy pasted something wrong
<Saviq> tsdgeos, but actually, trunk fails for me too, at least in PreviewActions
<Saviq> hmm no
<Saviq> ah,
<Saviq> make install
<Saviq> or well, make
<tsdgeos> oh lol
<tsdgeos> somehow i dropped the ! from
<tsdgeos> if (qtest_events.mouseClick(item, x, y, button, modifiers, delay))
<tsdgeos> Saviq: ok, should be fine now
<Saviq> tsdgeos, tx, testing
<Saviq> tsdgeos, now, are you venturing into the AP test flakiness at all?
<tsdgeos> Saviq: i'll give it a go yeah
<Saviq> thanks
<Saviq> mzanetti, btw, did LP notify you about bug #1408819 ?
<ubot5> Error: Launchpad bug 1408819 could not be found
<Saviq> https://bugs.launchpad.net/ubuntu-rtm/+source/unity8/+bug/1408819
<mzanetti> nope
<Saviq> mzanetti, crash when tapping on the top quicklist item in rtm
<Saviq> mzanetti, has there been changes to launcher backend in vivid that are not in rtm?
<mzanetti> ack, fixing
<mzanetti> not that I know of
<mzanetti> investigating
<Saviq> mzanetti, yeah, that's what I thought, so not even sure we're to blame, hopefully the stacktrace will help
<Saviq> it basically crashes in url-dispatcher
<mzanetti> if it's 100 reproducible it should be clear soon
<Saviq> in utf8 encoding/decoding... but not every time Â¿?
<Saviq> it is
<Saviq> but only rtm
<Saviq> can get you a set of dbgsym packages if you want
<mzanetti> let me see
<Saviq> url = 0x281ceb0 "tu.calculator/calculator/current-useA"
<Saviq> mzanetti, looks suspicious â
<mzanetti> it does :)
<mzanetti> but it doesn't happen if you just normally click the icon?
<mzanetti> (battery won't let me turn on my rtm device yet)
<Saviq> mzanetti, yeah, does not
<Saviq> mzanetti, and actually for me it only happens the second time I try
<mzanetti> hmm... for me it doesn't happen at all :/
<mzanetti> nope... not happening
<mzanetti> meh
<mzanetti> hah. got it reproduced on krillin. not on mako with rtm though... strange
<tsdgeos> Saviq: i've updated the MR a bit
<Saviq> mzanetti, right, yeah, it seems to be krillin specific indeed
<Saviq> heh, /me just understood what's happening... my touchpad does kinetic scrolling *internally*
<mzanetti> Saviq: ?
<Saviq> which means that if I scroll in one window and move with the mouse (not touchpad) or something changes under the cursor... the scrolling happens on whatever is currently under the cursor
<mzanetti> oh yeah... have that too
<mzanetti> esp. alt+tab goes crazy :D
<Saviq> right, like WTF
<Saviq> it actually generates events for *multiple seconds* after I stopped touching it
<mzanetti> Ã½ep
<Saviq> who thought of that ;/
<mzanetti> depends on how strong you flick
<Saviq> wouldn't think Apple did that
<mzanetti> hmm... tbh I haven't had this in KDE with same hardware
<Saviq> mzanetti, doubt that, you must've just not noticed it, it's definitely hw (well, driver)
<mzanetti> hmm... hard to believe too... because atm I scale my qtcreator font like twice a day because of this
<mzanetti> it might be that the driver didn't do it back then
<Saviq> yeah, it's probably a change between utopic and vivid or something
<mzanetti> happened already in utopic for me
<mzanetti> not sure about trusty - but that's the time I switched to unity
<Saviq> mzanetti, when https://ci-train.ubuntu.com/job/ubuntu-landing-024-1-build/29/console completes, it'll be ready for testing
<mzanetti> ack
<MacSlow> Why can't I call a public Q_INVOKABLE method from an object returned by ListModel.get(i) like someListModel.get(i).method(), but only directly from the object itself myObject.method(), which was added to the ListModel with someListModel.append(myObject)?
<MacSlow> I can easily access and change regular/public properties via someListModel.get(i).property
<MacSlow> Saviq, mzanetti, tsdgeos: ^ any idea?
<tsdgeos> MacSlow: are you registering the object metatye?
<tsdgeos> metatype
<MacSlow> tsdgeos, in my mock's plugin I do the usual qmlRegisterType<MockNotification>(...) if that's what you mean
<tsdgeos> can't think of a reason really
<MacSlow> tsdgeos, I don't use Q_DECLARE_METATYPE in my mock and thus follow the real implementation, which also does not use it for the Notification object/class.
<MacSlow> making this qmltest work with the mocked Notification is a real pain
<Saviq> MacSlow, prolly best to push some code
<MacSlow> tsdgeos, Saviq: just pushed the current state... if some one can help out... I'm basically lost and don't know why it's not working
<MacSlow> that's the branch lp:~macslow/unity8/swipe-dismiss-snap-decisions
<Cimi> mzanetti, got my launcher stuck 2 px on screen when hidden, is it something you think can happen with current code or was due to mterry's refactor for the edge demo?
<mzanetti> Cimi: hmm... haven't seen it before
<Cimi> might be his branch then
<Cimi> mzanetti, http://paste.ubuntu.com/9697734/
<Cimi> mzanetti, unless you can quickly spot an issue here, I will ask him
<mzanetti> looking
<Saviq> MacSlow, tests/mocks/Unity/Notifications/MockNotificationTypes.h:41: Warning: Property declaration rawActions has no READ accessor function or associated MEMBER variable. The property will be invalid.
<mzanetti> Cimi: hmm... might well be this, yes, but can't tell where. line 71/72 from the paste look suspicious as it influences the move delta below
<Saviq> MacSlow, tryNotifications doesn't work btw
<Cimi> mzanetti, ok, will ask him
<Cimi> thanks
<MacSlow> Saviq, I know... that's what I'm trying to fix
<MacSlow> Saviq, the split between rawActions and actions is because of the way actions have to be passed in via the qmltest
<Saviq> MacSlow, you're using a ListModel, that's why
<Saviq> MacSlow, ListModel really isn't geared towards storing objects, it basically is a proxy to properties
<Cimi> mzanetti, shall we use 0 in the test comparison? https://code.launchpad.net/~mzanetti/unity8/fix-left-edge-on-spread/+merge/243400
<Saviq> getRaw isn't even documented
<MacSlow> Saviq, getRaw() is needed/used because QML can't deal with QSharedPointers directly
<Saviq> MacSlow, I know, but ListModel does not have a getRaw method
<Saviq> at least not one that would do what you expect it to
<MacSlow> Saviq, so I've to change from ListModel to ListView?!
<Saviq> MacSlow, no, you need a custom mock Model
<MacSlow> Saviq, *sigh* yet more mocking... all that code just to get close() to work
<Saviq> MacSlow, ListModel is a very dumb thing
 * MacSlow goes in a corner and cries
<mzanetti> Cimi: whatever :)
<Saviq> MacSlow, as you're just reusing the same Notification objects, you can probably just reference them directly
 * davmor2 throws wet sponges at macslow to hide his tears......don't let the code see it is destroying your soul  ;)
<Saviq> MacSlow, but I imagine sooner or later you'll want your mock model to be smarter, so you'll need an actual mock model at some point anyway
<facubatista> Holas
<MacSlow> davmor2, :)
<MacSlow> Saviq, I wouldn't mind the amount of work, if the cost-benefit relation was reasonable... but in this particular case (for the swipe-to-dismis qmltest) it's appallingly bad
<Saviq> MacSlow, that's why I'm saying - go for a shortcut
<Saviq> MacSlow, you have static Notification objects on which the .close() method is called
<Saviq> aah wait
<Saviq> now I get it
<Saviq> it's the real implementation that requires getRaw to work
<MacSlow> yes
<Saviq> MacSlow, still, put all the Notification objects in a list
<Saviq> MacSlow, and in getRaw
<Saviq> MacSlow, iterate over that, and find the one with the right nid
<Saviq> instead of trying to pull it out of the ListMoel
<Saviq> Model, even
<Saviq> tsdgeos, hum, mouseClickMiddle got a segfault
<tsdgeos> yeah, but it's old code i guess something got weird
<tsdgeos> let the new code run
<Saviq> ah
<Saviq> ok let's see
<tsdgeos> actually i'm not sure it's a segfault
<tsdgeos> when we get segfaults the log says "Segmentation Fault" usually
<tsdgeos> in this case it's "killed"
<Saviq> actually not segfault
<Saviq> wth
<tsdgeos> no idea who killed it
<Saviq> there was a test failure too
<tsdgeos> yep
<tsdgeos> that's what the other change fixes
<Saviq> but yeah, let's see the new run
<Saviq> kk
<Saviq> MacSlow, see what I mean?
<tsdgeos> we're clicking exactly in the middle of the two buttons of the categories
<tsdgeos> and once in a while it goes to "the other" button
<tsdgeos> that was a valid 0,0 that should not have been blindly replaced :D
<Saviq> :)
<MacSlow> Saviq, hm... not really sure... first I'd like to actually see the notifications being added in the tryNotification part
<MacSlow> Saviq, getting the methods (close() and invokeAciton()) to work would come second then
<Saviq> MacSlow, your getRaw implementation depends on ListModel to give the model up, but it's not possible
<Saviq> MacSlow, so put all the Notification { } declarations you have in a list
<Saviq> or an object so you can reference them by name and not by id
<MacSlow> Saviq, ok
<Saviq> and then in getRaw you just go: return dataDict[mockModel.get(id).nid]
<Saviq> assuming that your keys will be nid
<MacSlow> Saviq, I see
<Saviq> or well, nid is integer, so a list would work, too
<mzanetti> re
<mzanetti> Cimi: ok, pushed (sorry, my internet connection broke down for the last 10 minutes)
<mzanetti> Saviq: ok, added some debug stuff. the line that crashes is:
<mzanetti> QDesktopServices::openUrl(getUrlForAppId(appId));
<mzanetti> whereas the passed argument is always: "appid://com.ubuntu.calculator/calculator/current-user-version"
<Saviq> mzanetti, so it looks like we need to push the bug down to qtubuntu?
<mzanetti> I'd say so...
<mzanetti> intersting thing though:
<mzanetti> I installed url-dispatcher-tools and tried to do "url-dispatcher appid://com.ubuntu.calculator/calculator/current-user-version"
<mzanetti> now I can't repro any more
<Saviq> right
<Saviq> still, please comment on your findings and bump to qtubuntu, maybe add a url-dispatcher task to boot
<mzanetti> Saviq: done. why is this private?
<greyback> dednick: could you please merge qtmir trunk into 1355173.trust-prompt-suspend
<greyback> mzanetti: busy? Could I add a review to your plate: https://code.launchpad.net/~gerboland/qtmir/acquire-wakelock/+merge/245942
<mzanetti> greyback: ack
<greyback> mzanetti: thanks!
<Saviq> mzanetti, coredump
<mzanetti> Saviq: ?
<Saviq> mzanetti, coredumps potentially include private data
<mzanetti> ah
<mzanetti> I lost the connection to my question
<Saviq> mzanetti, so bugs are created private by default
<mzanetti> ack
<Saviq> mzanetti, I usually un-private them after they're retraced and the coredump removed, but the retracer doesn't seem to be keen on getting there
<Saviq> ah actually it's done now
<mzanetti> yep, a minute ago
<Saviq> more like over an hour, but yeah
<Saviq> (privateâpublic is manual)
<Saviq> greyback, deeep sleep
<greyback> :D oopsie
<Saviq> greyback, and missing c in checkDashFocusDoesNotAquireWakeLock
<greyback> thank you typobot
<Saviq> nw
<tsdgeos> can't we run autopilot tests on the destktop anymore?
<tsdgeos> i get to run them fine on the phone
<tsdgeos> but desktop
<tsdgeos> PYTHONPATH=../tests/autopilot autopilot run unity8.indicators.tests.test_indicators.IndicatorPageTitleMatchesWidgetTestCase.test_indicator_page_title_matches_widget
<Saviq> tsdgeos, https://code.launchpad.net/~saviq/unity8/no-sigstop-main/+merge/245758
<tsdgeos> Ran 14 tests in 0.007s
<tsdgeos> OK
<tsdgeos> ah that makes sense
<Saviq> tsdgeos, ah those
<Saviq> tsdgeos, those never ran on X11
<tsdgeos> really?
<Saviq> tsdgeos, they only have phone scenarios
<tsdgeos> oh
<Saviq> tsdgeos, FWIW, those are integration tests, so shoulnd't even live in unity8
<Cimi> mterry, did you see my comment?
<Cimi> oh yes
<Cimi> just saw mail
<mterry> :)
<tsdgeos> it's amazing how often these autopilot tests fail in CI
<tsdgeos> but running on my phone that is exactly the same setup as CI
<tsdgeos> can't reproduce :/
<davmor2> tsdgeos: I bet it is not the exact same setup though
<tsdgeos> davmor2: well i'd like to know what CI does other than flashing and running autopilot that may make it break
<greyback> tsdgeos: how about if some background process is using lots of CPU (e.g. apport/whoopsie) - maybe that destabilizes the AP test run?
<tsdgeos> greyback: but why those would be running in CI?
<greyback> tsdgeos: dunno, just hypothesizing
<tsdgeos> sure :)
<davmor2> tsdgeos: network setup, initial flashing, password and developer mode, the fact that it's behind a restrictive firewall, no cellular except through mocking etc etc
<Saviq> Cimi, hey, got an update on bug #1363400 ?
<ubot5> bug 1363400 in ubuntu-system-settings (Ubuntu RTM) "[wizard] allows to "Continue" without connecting to network" [High,Triaged] https://launchpad.net/bugs/1363400
<Saviq> dednick, and for you - update on bug #1372061 ?
<ubot5> bug 1372061 in unity8 (Ubuntu) "SMS notification: time format not translatable" [High,In progress] https://launchpad.net/bugs/1372061
<davmor2> Saviq: what happens if you are not at home when you setup the wifi and you don't want to connect?
<Saviq> davmor2, you skip ;)
<davmor2> Saviq: and is that not what the continue does is you don't select a network?
<Saviq> davmor2, continue != skip
<Saviq> davmor2, but the actual issue is that you get a popup for the password, but still can press continue
<davmor2> Saviq: fair enough :) Skip is an odd term when there is a continue button too, yes I want to continue, I don't want to skip the phone setup
<Saviq> davmor2, you're on a page to set up your wifi, not the whole phone
<davmor2> Saviq: :)
<mzanetti> dednick: where can I find the messages.py mentioned in the comments here? https://code.launchpad.net/~nick-dedekind/unity8/lp1385331.led/+merge/241417
<mzanetti> tsdgeos: do you know? ^
<tsdgeos> pfff
<tsdgeos> it was in a pastebin
<mzanetti> :D
<tsdgeos> and in my phone but i think i deleted it
<tsdgeos> let me check
<tsdgeos> mzanetti: i *think* it's this one http://paste.ubuntu.com/9530101/
<mzanetti> I'll just run it. what can possibly go wrong :D
<tsdgeos> you need some extra python stuff though
<tsdgeos> well the imports
<tsdgeos> python will complain if you don't have them
<mzanetti> right... it's python2 and we only have 3 on the phone it seems
<Saviq> mzanetti, 2to3 should help here
<mzanetti> oh, nice
<mzanetti> it wasn't much though, already adjusted
<mzanetti> still a useful hint :)
<mzanetti> I fail to find this one: cannot import name MessagingMenu, introspection typelib not found
<tsdgeos> gir1.2-messagingmenu-1.0
<tsdgeos> i think
<tsdgeos> mzanetti: â
<mzanetti> thanks! working now
<dednick> mzanetti: https://dl.dropboxusercontent.com/u/85539674/messaging_menu.py
<dednick> ah. bit late!
<mzanetti> :)
<Saviq> dednick, if you missed my question, any update on bug #1372061 ?
<ubot5> bug 1372061 in unity8 (Ubuntu) "SMS notification: time format not translatable" [High,In progress] https://launchpad.net/bugs/1372061
<dednick> Saviq: woops. forgot about that one :/ code is ready. testing did not go well.
<Saviq> dednick, any case, lower prio than the prompt one
<Saviq> dednick, let's get back to it later
<dednick> Saviq: since the translations are moving to the sdk now i had to fudge them in to test it, but couldnt get it to pick up.
<dednick> but technically it should work! think it's just my knowledge of the translation system failing me.
<Saviq> dednick, I could help if you linked a branch to the bug :)
<dednick> Saviq: give me a sec.
<Saviq> sure
<Cimi> Saviq, I cannot fix it on my side...
<Cimi> Saviq, requires changes in network manager side I think
<Saviq> Cimi, is anyone looking at it?
<Cimi> Saviq, nope
<Cimi> Saviq, we can chase again Wellark but he said is not doable...
<Cimi> in the timeframe
<Saviq> Wellark, Cimi, can you please update the bug with any status/findings
<dednick> Saviq: https://code.launchpad.net/~nick-dedekind/ubuntu-ui-toolkit/lp1378821.time-translation
<dednick> https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/lp1378821.time-translation
<Saviq> dednick, thanks
<dednick> https://code.launchpad.net/~nick-dedekind/unity8/lp1378821.time-translation
<dednick> Saviq: the ubuntu-settings-components is just a fix for text alignment. since it's a bit screwed when things get translated these days
<Saviq> kk
<mterry> Cimi, I already fixed the launcher-2px thing, you can continue that review if you like
<greyback> dednick: note, menus may have been bolted into indicators, so that HUD would index both?
<Cimi> mterry, cool thx!
<dednick> greyback: not sure about that. but it doesn't seem like the right approach to me.
<greyback> dednick: was just a thought. But agreed it's a weird design
<dednick> greyback: yeah, i mean inicators are just essentially menus so i guess it makes some logical sense. in the world of the "global menu" anyway.
<greyback> dednick: true
<mzanetti> elopio: hey
<elopio> mzanetti: hello.
<mzanetti> I'm testing a silo with your branch and I'm getting this error: http://paste.ubuntu.com/9699519/
<mzanetti> am I doing something wrong?
<mzanetti> seeing that it passed in jenkins
<elopio> mzanetti: let me see the code.
<elopio> mzanetti: probably you should do autopilot3 run.
<elopio> but unity8 helpers still need to be compatible with python2, so I probably forgot that part.
<mzanetti> elopio: oh, that looks better
<mzanetti> elopio: what does that mean? you want to fix it or should we merge it (the test passes with python3)?
<elopio> mzanetti: I just need to add the stupid super parameters that py2 needs. Give me a minute.
<elopio> that's a good catch, and I better fix it before you merge it.
<mzanetti> elopio: wait a second
<mzanetti> Saviq: this is the only issue I found with the silo ^^
<mzanetti> wanna do another rebuild?
<mzanetti> elopio: or well, if we break something we have to fix it anyways...
<mzanetti> elopio: ok... Saviq seems to be away. I'll do the rebuilding then. feel free to fix&push
<Saviq> mzanetti, elopio I'd rather land it and re-merge next week, nothing's using it, it's a new helper etc.
<mzanetti> ah, there he is :)
<mzanetti> ack. works for me
<elopio> mzanetti: Saviq: ok. works for me too.
<elopio> I'll push it to a new branch.
<elopio> mzanetti: Saviq: I've already pushed it to my branch. Should I revert it, or it won't cause any problems?
<mzanetti> I don't think it will. the silos keep a copy
<Saviq> elopio, it's fine, leave it there
<Saviq> elopio, we'll just do another MP from the same branch
<Saviq> elopio, or well, land the same MP again, actually
<elopio> Saviq: ok then. It's ready.
<elopio> mzanetti: thanks for checking it.
<mzanetti> Saviq: done. spreadsheet updated
<Saviq> mzanetti, thanks
<mzanetti> elopio: no worries
<Cimi> mzanetti, for monday https://code.launchpad.net/~mzanetti/unity8/fix-left-edge-on-spread/+merge/243400
<Cimi> mzanetti, the enterSpread test fails
<mzanetti> Cimi: ack, thanks
<Saviq> greyback, still around?
<greyback> Saviq: back now
<Saviq> greyback, nothing pressing, when you want to just tell me if I'm talking bullshit in https://code.launchpad.net/~saviq/qtmir/openurl-keep-bytearray/+merge/246017
<greyback> Saviq: ok
<greyback> Saviq: that makes the crash go away?
<Saviq> greyback, couldn't reproduce with that, and debugs as per https://bugs.launchpad.net/ubuntu-rtm/+source/qtmir/+bug/1408819/comments/10 confirm it's ok
<ubot5> Launchpad bug 1408819 in qtmir (Ubuntu RTM) "unity8 crashed with SIGABRT in g_assertion_message() when launching calculator from quicklist" [Critical,In progress]
<Saviq> greyback, and it kinda makes sense, the QByteArray from encoded() can be deleted as soon as you take the constData() out of it
<Saviq> greyback, qtubuntu seems to have avoided that by just putting url.encoded().constData() directly in the call to urld
<Saviq> so there's no way the QBA would be deleted before it returns
<greyback> Saviq: I see your point. Was pondering if the temporary QByreArray could really be deleted by then - and probably yeah, since it's a temporary
<Saviq> yeah exactly
<Saviq> now it'd be interesting to find out a way to unit-test this...
<greyback> unit testing C++ object lifetimes? Have fun with that
#ubuntu-unity 2016-01-11
<tsdgeos> pstolowski: so the audio stuff landed \o/
<pstolowski> tsdgeos, :)
<pstolowski> tsdgeos, that means beer in austin
<tsdgeos> pstolowski: is there any update we need to do for filters because of the landing
<tsdgeos> version numbers or something?
<pstolowski> tsdgeos, probably, will let you know soon
<tsdgeos> Saviq: so the big silo is next, right?
<Saviq> tsdgeos, yes, DPR's under QA and the big one's next
<tsdgeos> tags infection!
 * tsdgeos deletes
<tsdgeos> http://paste.ubuntu.com/14468126/
<Saviq> greyback, interestingly, qtmir tests failed in our CI on my first trials, in QML cache retention tests, thoughts?
<greyback> Saviq: nothing obvious. Any error messages I can look at?
<Saviq> greyback, the failures just said the dir wasn't there, what should have created it?
<greyback> Saviq: I don't know. I thought the code would, but maybe not
<Saviq> greyback, started the build again in https://unity8-jenkins.ubuntu.com/job/run-commands/223/console
<Saviq> greyback, it might be just that XDG env isn't set or something
<greyback> will see if phone can recover if I delete ~/.cache/QML/Apps
<greyback> yep, it can
<Saviq> greyback, the above job finished, there's build logs in there
<Saviq> /food
<dandrader> tsdgeos, so there's nothing holding up https://code.launchpad.net/~aacid/unity8/nodda/+merge/280814 besides https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/xvfb_pixels_per_mm/+merge/282149 ?
<greyback> Saviq: I suspect the QV4_ENABLE_JIT_CACHE=1 env var missing
<Saviq> greyback, would've failed in any other package builds then, wouldn't it...
<Saviq> /methinks it's rather something like $HOME missing or so
<greyback> QByteArray path(qgetenv("HOME") + QByteArray("/.cache/QML/Apps/") + (qgetenv("APP_ID").isEmpty()
<greyback> yes, it needs $HOME
<Saviq> meh, should use XDG instead
<Saviq> or well, Qt's path bits, even
<Saviq> QStandardPaths I mean
<Saviq> not to mention it pollutes $HOME this way
<tsdgeos> dandrader: afaik no
<tsdgeos> dandrader: there's a few failing tests, but i think that they are fixed by the mega silo
<physics> exit
<mterry> Heh, this is cute: "Tofu (è±è) is Japanese jargon for unicode replacement character "ï¿½" (U+FFFD) often displayed as replacement for unassigned or unknown characters."
<mterry> mzanetti, I just noticed you couldn't make the lockscreen meeting today, want me to reschedule?
<mzanetti> mterry, I am totally confident you can handle it. but if you'd like me to participate, then yes
<mterry> mzanetti, naw it's cool, should be simple questions
<mzanetti> yeah
<tsdgeos> cimi: pstolowski has a test scope you can use to test the other two fitler widgets you did not review
<tsdgeos> cimi: could you have a look?
<cimi> tsdgeos, sure
<cimi> tsdgeos, I am doing sth else for gerry atm
<tsdgeos> k
<Saviq> tsdgeos, ltinkl, http://pastebin.ubuntu.com/14469671/
<tsdgeos> Saviq: hmmm, what branch is that? the megasilo?
<Saviq> tsdgeos, subset of mega silo with just fixes https://requests.ci-train.ubuntu.com/#/ticket/854
<Saviq> as we're in feature/string freeze
<Saviq> that's on xenial btw
<tsdgeos> Saviq: the card creator failure is weird, none of those MRs touch the cardcreator file, no?
 * tsdgeos triple checks
<ltinkl> Saviq, in mtg, gonna have a look at it after
<tsdgeos> Saviq: is there a lp branch with everything?
 * tsdgeos quadruple checks
<Saviq> tsdgeos, as usual https://code.launchpad.net/unity8
<tsdgeos> Saviq: https://code.launchpad.net/~lukas-kde/unity8/fixLauncherDismiss/+merge/282031 requires https://code.launchpad.net/~mzanetti/unity8/launcher-updates that is not in the silo, you aware of that?
<Saviq> tsdgeos, oh right, pulling that out
<Saviq> or rather, un-rebasing
<ltinkl> Saviq, passes locally here (the launcher dismissal testÃº
<Saviq> ltinkl, can you please uncommit the merge with launcher updates and --overwrite, had to pull that one out
<Saviq> tsdgeos, maybe broken on trunk?
<tsdgeos> Saviq: think not, let me recheck
<Saviq> tsdgeos, fails reliably in the branch
<tsdgeos> oh, actually it is
<tsdgeos> http://paste.ubuntu.com/14469783/ this is trunk
<tsdgeos> at least here
<ltinkl> Saviq, oh, you had to pull out the launcher-updates?
<Saviq> ltinkl, yeah, freeze
<Saviq> tsdgeos, yup
<tsdgeos> Saviq: i can provide a fix in a minute after standup
<Saviq> tsdgeos, ack
<ltinkl> Saviq, ok, should be fine: https://code.launchpad.net/~lukas-kde/unity8/fixLauncherDismiss/+merge/281640
<ltinkl> Saviq, reverted the prereq
<Saviq> ltinkl, thanks
<Saviq> mterry, you need to update the AP test in the wizard change
<Saviq> mterry, http://pastebin.ubuntu.com/14469884/
<mterry> Saviq, ick right
<Saviq> ltinkl, http://pastebin.ubuntu.com/14469902/ reliably here
<Saviq> ltinkl, note that's the whole branch
<Saviq> lp:~ci-train-bot/unity8/unity8-ubuntu-xenial-landing-030
<Saviq> in case that has an impact
<mterry> Saviq, been a while since I touched the AP tests...  are we close to those passing?  Or do punks like me keep breaking them?
<ltinkl> Saviq, with this silo https://requests.ci-train.ubuntu.com/#/ticket/854 ?
<Saviq> mterry, that's the only one broken
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/fix_card_creator_test/+merge/282187
<Saviq> ltinkl, yes
<Saviq> tsdgeos, tx
<Saviq> mterry, I run them every landing
<ltinkl> Saviq, ok, on it
<mterry> Saviq, but they were broken in jenkins, right?
<Saviq> mterry, kinda, were fine recently, finicky xenial though
<Saviq> +on
<Saviq> ltinkl, yeah, lp:~ci-train-bot/unity8/unity8-ubuntu-xenial-landing-030 fails on that test here
<Saviq> ltinkl, could be mouse touch update
<ltinkl> Saviq, yup.. think so too...
<ltinkl> Saviq, this one right https://code.launchpad.net/~dandrader/unity8/updateMouseTouchAdaptor/+merge/280718
<ltinkl> Saviq, here's where it fails: http://paste.ubuntu.com/14470063/ , line 15
 * Saviq bisects
<Saviq> oh right, it just crashes otherwise
<tsdgeos> Saviq: run without xvfb
<tsdgeos> that'll remove the crash
<Saviq> ac
<Saviq> k
<Saviq> ah and that test isn't there before :P
<ltinkl> Saviq, mine? yeah that comes with the branch
<dandrader> tsdgeos, https://code.launchpad.net/~dandrader/unity8/nodda/+merge/282193
<tsdgeos> dandrader: that's a weird diff :D
<Saviq> indeed
<dandrader> tsdgeos, yeah, was about to say that. web diff totally messed up
<tsdgeos> dandrader: http://bazaar.launchpad.net/~dandrader/unity8/nodda/revision/2116 is the important part, right?
<dandrader> tsdgeos, might be because took trunk, merged your branch and then added mine on top
<dandrader> tsdgeos, yes
<tsdgeos> k will have a look
<dandrader> tsdgeos, you can bzr merge -c 2116
<tsdgeos> yep
<mterry> Saviq, how do you run the tests?  they don't seem to come close to passing on my xenial desktop.  do I need to do it on the phone?
<mterry> (the autopilot tests)
<Saviq> mterry, yes, phone only
<mterry> humph
<Saviq> mterry, flash phone, citrain, install unity8-autopilot (might need to drop /etc/apt/preferences.d/*), run them
<Saviq> oh yeah
<Saviq> stop unity8
<Saviq> phablet-test-run wasn't reliable for me recently
<mterry> Saviq, I also noticed that the CMakeLists.txt only runs the unity8.shell tests in its one declare_autopilot_test() command.  Do those never get used?
<Saviq> mterry, don't think so, we always use "autopilot run unity8", since we run from packages
<mterry> Saviq, hrm.  Meaning we don't use mocks?  Meaning that we can't control the environment.  That's probably why it fails for you -- you have a password set and it's skipping the password screen as a result
<Saviq> mterry, the cmake target was for running on your host, which is bitrot these days, and we should probably not support that at all since it will maybe run half the tests
<Saviq> mterry, sure it can use mocks
<ltinkl> Saviq, just checking, do you want me to do something with the launcher_dismiss test failure at this point?
<Saviq> ltinkl, just finding where it breaks
<Saviq> will let you know when I do
<ltinkl> Saviq, kk, thanks
<Saviq> mterry, tests themselves set QML2_IMPORT_PATH as appropriate, maybe that test is missing that bit
<mterry> Saviq, yup I see other autopilot tests doing it, ok.  will fix
<Saviq> tx
<Saviq> w00t, successful unity8 build in Jenkaas
<ltinkl> Saviq, I can try merging lp:~dandrader/unity8/updateMouseTouchAdaptor into mine and see if it breaks
<Saviq> ltinkl, will know soon
<ltinkl> ok
<cimi> greyback, I think I did something bad with your DPR  :)
<ltinkl> Saviq, hmm, passes here as well
<ltinkl> Saviq, but I'm tempted to do this: remove my test function since there's already one, practically the same: test_dragLeftEdgeToRevealLauncherAndTapCenterToDismiss()
<Saviq> ltinkl, still, we should understand what happened
<ltinkl> Saviq, yeah...
<Saviq> ltinkl, it was launcher updates
<ltinkl> Saviq, ack, so it should be ok now
<Saviq> ltinkl, maybe in conjunction with one of the other branches
<ltinkl> Saviq, good to know :) also verified it works fine together with lp:~dandrader/unity8/updateMouseTouchAdaptor
<Saviq> ltinkl, the existing test only does it once, right? and yours did twice?
<ltinkl> Saviq, yup, my test does it twice (specifically for the bug report) and in a slightly different way
<Saviq> ltinkl, ok, so leaving it in
<ltinkl> Saviq, yup, definitely
<oSoMoN> mzanetti, hey, Iâm wondering about how unity8 behaves with regards to multi-window apps, can you enlighten me?
<tsdgeos> dandrader: merged in
<dandrader> tsdgeos, ok, thanks
<mzanetti> oSoMoN, what in particular?
<mzanetti> oh, multiple surfaces per app
<tsdgeos> dandrader: ty
<mzanetti> oSoMoN, we're working on it. we have a branch in the queue that makes them not crash
<oSoMoN> mzanetti, yes, is that supported at all, if so what constraints does the shell enforce, â¦
<mzanetti> and daniel is working on another one that makes it actually work
<oSoMoN> mzanetti, is there a rough ETA?
<mzanetti> dandrader, what's the status on multisurface apps? oSoMoN is aksing ^
<mzanetti> you took that card from me in the last sprint. haven't checked on it since the hols
<oSoMoN> and is there a bug report to track progress?
<mzanetti> well, I guess I could say OTA-10 if all goes well
<mzanetti> oSoMoN, there is our trello board
<oSoMoN> that sounds good enough
<dandrader> mzanetti, oSoMoN working on it. but long road ahead
<mzanetti> ok, scratch ota 10 then :D
<mzanetti> but well, 11 or so still seems realistic I'd say, no?
<mzanetti> oSoMoN, https://trello.com/c/F7aFIPq4/209-13-support-multiple-top-level-windows-of-applications
<dandrader> mzanetti, you asking me? I don't know the OTA dates..
<mzanetti> you don't? you should :D
<mzanetti> well, we have frozen OTA-9 right now
<mzanetti> that means roughly 6 weeks to the next
<dandrader> mzanetti, I'm not a manager / team lead  :D
<oSoMoN> we need a tool to map OTA numbers to estimated dates :)
<mzanetti> well, you sure notice a huge traffic jam on landings every 6 months
<mzanetti> just count them, we're at 9 atm
<mzanetti> 6 weeks, sorry
<oSoMoN> mzanetti, dandrader: so when fully implemented, what kind of constraints will the shell be enforcing, if any? will apps be allowed to have multiple windows on a phone?
<dandrader> oSoMoN, yes, for the second question
<oSoMoN> interesting
<mzanetti> oSoMoN, I think we're going towards the direction that yes, it would be allowed on the phone, but there's many design questions open still
<mzanetti> guidance for a first step is to just hide them in staged mode
<dandrader> mzanetti, oSoMoN app lifecycle, screenshotting and prompt surfaces get more complicated
<mzanetti> but the more we discuss it, the more it makes sense to have multiple browser windows on a phone too
<mzanetti> oSoMoN, so prepare for everything but the first window is hidden in staged mode for a start. I will loop you in if new info comes up
<dandrader> mzanetti, I think it will be the first phone with multiple browser windowes
<oSoMoN> mzanetti, perfect, thanks
<mzanetti> dandrader, afaik android does that too now
<dandrader> mzanetti, really!?
<dandrader> mzanetti, with chrome? on what android version?
<mzanetti> given the whole phone is a tabbed ui, it seems quite odd to have tabs within a tab tbh :D
<mzanetti> I don't know, Saviq told me
<oSoMoN> mzanetti, other windows would be hidden but not closed, right?
<mzanetti> yeah, hidden I'd say
<oSoMoN> and restored when in windowed mode I guess
<oSoMoN> mzanetti, is "the first window" the first ever opened, or the most recently focused one?
<ltinkl> yup, Chrome on android does multiple windows (even spawns another instance imo)
<Saviq> ltinkl, they don't do tabs at all any more
<Saviq> which /me likes btw
<ltinkl> Saviq, yup
<mzanetti> dandrader, ^^
<Saviq> would much rather see all tabs separate in right edge than have to go through right + bottom edges
 * oSoMoN wouldnât mind that either, that would simplify quite a bit the browserâs code
<Saviq> oSoMoN, don't think that's clear enough yet (re: first or last focused window)
<oSoMoN> ok
<Saviq> oSoMoN, could be a UX question as well
<Saviq> oSoMoN, but if a browser window is focused, we should probably not close that on
<Saviq> e
<Saviq> oSoMoN, so that might be a good starting point, unless we find a problem with that
<oSoMoN> and is there gonna be some sort of signal when switching from windowed to staged (or vice-versa)?
<oSoMoN> not even sure thatâd be useful, just thinking out loud
<Saviq> oSoMoN, there must be, I think, because you need to collect the tabs
<dandrader> mzanetti, hmm, maybe it's my phone skin on top of android that doesn't enable that multi window browser. will check my Nexus 10 later
<Saviq> oSoMoN, quite likely we won't be killing your windows even, only display the last one and let you know to kill the other ones
<Saviq> as closing windows "as usual" might have implications on user data
<oSoMoN> Saviq, what we would do when all other windows are hidden needs to be discussed with design, but indeed whatever weâll do we would probably need to get notified
<dandrader> Saviq, I thought phone/staged mode would have multi-windows per app as well....
<mzanetti> too many open design questions with that atm
<mzanetti> but yes, we will probably aim for that in the long run
<Saviq> dandrader, nope
<mzanetti> at least don't build roadblocks :)
<oSoMoN> another (slightly related) question: does unity8 enforce a single instance for a given app, or is that up to the app to implement its own singleton mechanism?
<dandrader> Saviq, so far I've been workgin with the information that phone mode would also support  multi-window apps
<mzanetti> oSoMoN, qtmir enfoces that, yes
<Saviq> ubuntu-app-launch does, rather
<Saviq> or well, both do
<Saviq> dandrader, as things stand today, one window per app on phone
<Saviq> mterry, let me know if you think have the AP test fixeded so I can rebuild the silo
<mterry> Saviq, I maybe pushed a fix -- was going to wait for jenkins to build it for me
<mterry> Saviq, (before testing to confirm)
<Saviq> mterry, looks legit
 * Saviq rebuilds then
<oSoMoN> are https://wiki.ubuntu.com/Unity/LauncherAPI#Static_Quicklist_entries supported in unity8âs launcher?
<Saviq> ltinkl, â
<mzanetti> oSoMoN, Saviq https://code.launchpad.net/~lukas-kde/unity8/desktopFileActions/+merge/276408
<Saviq> right
<ltinkl> oSoMoN, work in progress, but probably not until we support multi instance/window apps
<oSoMoN> thanks
<mterry> Saviq, I'm back from lunch, which silo are you building in these days?  I want to test my wizard fix (jenkins still didn't run)
<mterry> ah silo 30
<mterry> Saviq, so I ran the wizard autopilot tests again, and silo 30 passes those
<Saviq> mterry, yup, just did that myself
<mterry> Saviq, ran the whole suite just to see, and I got 8 failures, where they couldn't find 'MainView' widget
<mterry> Saviq, is that new?
<Saviq> mterry, hmm
<Saviq> Ran 76 tests in 2231.028s
<Saviq> FAILED (failures=1)
<Saviq> but that one failure I expect, is because I have too many items on my launcher
<Saviq> mterry, that's on rc-proposed?
<mterry> Saviq, yes
<mterry> mako
<Saviq> mterry, I'm on rc-proposed@krillin and things are fine, just finishing up on devel-proposed@mako
<Saviq> mterry, I would maybe expect that on devel-proposed, not sure we've made sure they work with Qt 5.5
<mterry> Saviq, this was not a pure clean image beforehand -- I don't remember doing anything weird, but maybe I had
<mterry> Saviq, if it worked for you on krillin, this is probably just noise then
<Saviq> Ran 76 tests in 3238.810s
<Saviq> OK
<Saviq> mterry, â devel-proposed@mako
<mterry> Saviq, nice
<Saviq> so actually better than I expected
<Saviq> not sure why that much slower, though
<mterry> Saviq, one was on krillin and one on mako yeah?
<Saviq> mterry, yes
<mterry> I thought krillin was faster, so that might make sense
<Saviq> but mako should be faster I'd think
<Saviq> is it?
<Saviq> right, it may be because less pixels
<mterry> Saviq, I had a memory of thinking mako was our worst at one point
<Saviq> greyback, dandrader, are we ok with the TODO for bug #1527737? the delay to launch is significant, any reason why we can't show the app starting straight away?
<ubot5> bug 1527737 in qtmir (Ubuntu) "Apps do not start if restarted quickly after closing" [High,In progress] https://launchpad.net/bugs/1527737
<dandrader> Saviq, it's already like that
<dandrader> Saviq, so the fix is not regressing
<Saviq> dandrader, or worse?
<dandrader> Saviq, it's just stating the problem clearly
<dandrader> Saviq, worse what?
<Saviq> dandrader, when it crashes
<Saviq> dandrader, well, ok, was just thinking since you touched that, could've made it good straight away, but then you're working on rehauling the whole thing anyway
#ubuntu-unity 2016-01-12
<zzarr> good morning
<tsdgeos> Saviq: do you know how far ltinkl was on the mocks for testLogin1Capabilities ?
<tsdgeos> should i work on that?
<tsdgeos> https://code.launchpad.net/~lukas-kde/unity8/fixLogin1Tests/+merge/272493 seems pretty much almost done
 * tsdgeos finds something else to do
<Saviq> tsdgeos, quite far, but there were issues with dbus processes staying on after the test completed
<Saviq> and I never got around to looking into it
<tsdgeos> Saviq: is that reproducible with regular make foo or does it need the pkgtest to happen?
<Saviq> tsdgeos, dunno
<tsdgeos> ok let me check then
<Saviq> tsdgeos, autopkgtest results in silo 30 don't look too good :/ http://paste.ubuntu.com/14476759/
<tsdgeos> ouch
<Saviq> although most of them are Launcher(214)
<Saviq> so one fix should help a lot there
<tsdgeos> what's will all those launcher failures
<Saviq> but there are a few new ones
<Saviq> tsdgeos, I'm worried this might be timing when dragging the launcher out or so
<tsdgeos> love this one
<tsdgeos> Actual   (): 434.2858326192127
<tsdgeos>    Expected (): 434.28571428571433
<Saviq> yeah
<Saviq> that's xenial btw
<tsdgeos> yaeh the launcher ones seem to be failing to drag it into view
<Saviq> vivid looks much better http://paste.ubuntu.com/14476772/
<tsdgeos> Saviq: mzanetti: we need to focus on getting those to 0, at this point we have so many things failing it gets hard to tell if a failure is a regression, fixed elsehwere or needs fixing
<Saviq> tsdgeos, totally, I do, however, run both of them on amd64 before releasing any silo
<Saviq> so my runs yesterday for silo 30 were both 100%
<mzanetti> agreed
<Saviq> tsdgeos, I will try today to get at least a temp job running those in our jenkaas so we can maybe put it through its paces
<tsdgeos> Saviq: so this are results not from you but from the builders?
<Saviq> unfortunately that might not be enough
<Saviq> tsdgeos, https://requests.ci-train.ubuntu.com/#/ticket/776
<Saviq> down at the bottom "Autopkgtest results"
<Saviq> um wroing
<Saviq> https://requests.ci-train.ubuntu.com/#/ticket/854
<Saviq> tsdgeos, â
<tsdgeos> oki
<Saviq> so yeah, seems roughly reproducible between vivid and xenial, modulo launcher not getting pulled out
<tsdgeos> i can't get extra processes when running ltinkl's branch with regular makeFoo
<tsdgeos> i guess it's pbuilder only?
<Saviq> tsdgeos, could very well be
<Saviq> tsdgeos, oh but, our current CI's autopkgtests run on hardware actually
<Saviq> IIRC
<Saviq> s/current/old/
<tsdgeos> Saviq: what do you mean?
<Saviq> tsdgeos, not in pbuilder/autopkgtest or anything
<Saviq> tsdgeos, or actually... in a dedicated VM
<Saviq> like one with GPU and stuff
<tsdgeos> you mean the extra process for the login1 tests?
<tsdgeos> it didn't seem to be failing on the CI stage, not sure where fginther saw the extra process/failure
<Saviq> tsdgeos, he SSH'd to the machine when it failed
<Saviq> tsdgeos, lemme restart it in the mean time
<Saviq> ah conflict
<Saviq> tsdgeos, re: SM_BUSNAME, I think the plan was to put the mock on the session bas originally... but then we found that there's no problem mocking a system bus...
<tsdgeos> i see
<Saviq> tsdgeos, FWIW we already have it elsewhere
<tsdgeos> it's just that it's the thing actually causing the conflcit D:
<Saviq> http://pastebin.ubuntu.com/14476963/
<tsdgeos> if it wasn't there it'd merge fine
<Saviq> well, sure, I agree - since we can mock system bus, we shouldn't have that define at all
<dandrader> mzanetti, is this related to what you're fixing? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1515977
<ubot5> Launchpad bug 1515977 in unity8 (Ubuntu) "Nexus4 Shell rotates inappropriately in windowed mode" [High,Confirmed]
<tsdgeos> mzanetti: found race condition in one of the shell tests https://code.launchpad.net/~aacid/unity8/fix_test_focusAppFromLauncherExitsSpread/+merge/282292
<tsdgeos> Saviq: â
<Saviq> tsdgeos, coolz
<dandrader> tsdgeos, what's "bfb"?
<tsdgeos> dandrader: it's the "home" button
<tsdgeos> i didn't name it, just following the way
<mzanetti> I named it...
<dandrader> yeah
<mzanetti> design calls it like that
<dandrader> we should probably mock or disable that dismiss timer in tests....
<tsdgeos> dandrader: putting the mouse over the button disables it
<dandrader> tsdgeos, right
 * tsdgeos goes to hunt more failing tests
<mterry> kgunn_, how does deprecation work in a Touch lifecycle context?  Like with LTS releases, we don't support skipping an LTS upgrade, so we know we can drop deprecated stuff after each LTS release.  But do we have a similar story for Touch?  (not in terms of apps, which have frameworks, but in terms of things like u8's internal properties)
<Saviq> mterry, wdym "u8's internal properties"?
<kgunn_> mterry: interesting question, when you say "deprecation for life cycle" don't  you still mean for apps to understand/accomodate ?
<mterry> Saviq, uh like if we changed where a gsettings is stored, but we still need to support upgrades from old devices, so we can't yet drop the old location.  My question is "when can we?"
<mterry> kgunn_, no I mean in customer/device support lifecycle
<Saviq> so upgrades from how far back do we support, really?
<mterry> Saviq, yeah
<Saviq> ok, no idea ;)
<mterry> Saviq, like 10 OTAs?  Forever?
<mterry> Saviq, makes me much more cautious about adding settings like that now  :)
<tsdgeos> Saviq: do we worry about
<tsdgeos> FAIL!  : qmltestrunner::Card::test_art_size(Tall) property height
<tsdgeos>    Actual   (): 434.2858326192127
<tsdgeos>    Expected (): 434.28571428571433
<tsdgeos>    Loc: [/tmp/adt-run.Q55ONm/build.yU8/unity8-8.11+15.04.20160111.1/tests/qmltests/Dash/tst_Card.qml(341)]
<tsdgeos> ?
<tsdgeos> want me to change it so that it compares say the first 3 decimals?
<Saviq> tsdgeos, well... it failed, didn't it...
<tsdgeos> yeah, it's also i386
<tsdgeos> which shall be killed with fire
<tsdgeos> but ok, will make it check say up to two decimals, should me more than enough
<Saviq> tsdgeos, we need to make it pass *somehow*, shouldn't tryCompare or something be smart about it?
<tsdgeos> well you told it to compare two doubles, it doesn't know how much exact you want them to be
<tsdgeos> it has "some" wiggle room
<tsdgeos> but probably for this different it thinks it's too different
<ltinkl> isn't there some sort of qFuzzyCompare in QML? :o
<ltinkl> tsdgeos, yup, tryCompare uses fuzzy comparisons for numbers
<tsdgeos> ltinkl: yes, but fuzzy compare for those 2 numbers probably fails
<ltinkl> tsdgeos, see function qtest_compareInternal(act, exp)
<ltinkl> tsdgeos, basically it goes like: if (Math.abs(act - exp) <= 0.00001)
<ltinkl> tsdgeos, yours differ already at the 4th decimal :p
<ltinkl> tsdgeos, using number.toFixed(3) should help it, if you're happy with the precision
<tsdgeos> ltinkl: i'd be happy with 1px precision :D
<Saviq> dandrader, https://code.launchpad.net/~dandrader/qtmir/appRestart-lp1527737/+merge/281701/comments/716315
<dandrader> Saviq, always reproducible?
<Saviq> dandrader, not sure yet, but reproducible enough it seems
<Saviq> dandrader, might be related to the app failing
<Saviq> or crashing
<Saviq> dandrader, yeah, it looks app crashing is causing AppMan to go into bad state
<Saviq> dandrader, so yeah, camera + content-hub is easiest to reproduce with today, as the camera app crashes and sends AppMan into the broken state
<dandrader> Saviq, ok...
<Saviq> dandrader, I've removed qtmir from silo 30 to get it landed without that change
<dandrader> Saviq, https://code.launchpad.net/~dandrader/qtmir/appRestart-lp1527737/+merge/281701/comments/716386
<dandrader> Saviq, it's a iffy use case
#ubuntu-unity 2016-01-13
<meercat> there is a bug in the ubuntu 15.10 installation process that prevents uefi boots on some systems and in virtualbox, the fix applied does not work on all systems.  for now, the workaround is to install xubuntu and then install unity.  https://bugs.launchpad.net/ubuntu/+source/efibootmgr/+bug/1363719
<ubot5> Launchpad bug 1363719 in efibootmgr (Ubuntu Utopic) "efibootmgr may create a duplicated boot entry, "breaking" UEFI boot." [Critical,Fix released]
<meercat> the bug is specific to ubuntu
<lpotter> hmm.. I take it grayback is on holiday
<lpotter> ot just not here at the moment...
<Saviq> lpotter, yeah, he's out until next week, can I help?
<Saviq> mzanetti, bug #1532974, rings a bell?
<ubot5> bug 1532974 in qtmir (Ubuntu) "large window flicker on ubuntu apps launching in window mode" [Critical,New] https://launchpad.net/bugs/1532974
<lpotter> just wanted to chat about his change to qtubuntu-sensors. :) no biggy
<mzanetti> lpotter, grayback will show up in approx an hour...
<mzanetti> Saviq, hmm, not really
<mzanetti> lpotter, oh sorry. I saw saviq told he's on hols for real
<mzanetti> didn't know :D
<lpotter> I have a couple patches for that package, but I need to talk to someone about that. maybe tvoss might be better
<lpotter> because it has "issues" :)
<lpotter> (not his patch but sensors handling)
<mzanetti> heh, well, I guess you can just propose an MP with the fixes
<lpotter> sure. but one issue I haven't looked at, as it would be a bigger thing to deal with
 * Saviq flashes flo
<lpotter> thought I had a bug that it...
<Saviq> mzanetti, some success: https://unity8-jenkins.ubuntu.com/view/Build/job/build-2-binpkg/
<mzanetti> saviq nice!
<Saviq> I just realized, though, that cross-building will give us trouble for qmake projects and such, so might need a armhf node after all
<mzanetti> hmm... qmake cross compiling should work fine nowadays
<Saviq> oh well, yeah, but there's no project that actually implements it in their packaging
<Saviq> because it's some manual labour
<Saviq> like generating debian/control to include the cross qmake
<mzanetti> well, I anyways think proper armhf nodes would be beneficial
<lpotter> I tried xcompiling qt with sbuild last week, and it failed.
<lpotter> and I cried
<Saviq> yeah, it should be doable these days, but it's not convenient yet
<lpotter> well. qt itself is a special case and no doubt trickier than your average qt app
<Saviq> trueth
<dandrader> Saviq, did you also have https://code.launchpad.net/~dandrader/qtubuntu/offscreenSurface-lp1527737/+merge/281638 installed?
<dandrader> Saviq, (talking about https://code.launchpad.net/~dandrader/qtmir/appRestart-lp1527737/+merge/281701/comments/716413  )
<Saviq> dandrader, no
<Saviq> did I miss a prereq?
<dandrader> Saviq, it's stated in the MP checklist
<dandrader> Saviq, offscreenSurface-lp1527737 removes noise from a closing application
<dandrader> Saviq, without it an application will create a new mir surface when shutting down
<dandrader> Saviq, just so that Qt does some internal GL context clean up it seems
<dandrader> Saviq, will try that use case some more to try to get that crash, then remove the offscreenSurface-lp152773 patch and try it again. who knows, maybe I'm lucky :)
<Saviq> dandrader, if crash is indeed the problem, you can just kill -SIGABRT something
<Saviq> dandrader, the prereq says "not strictly required", so maybe it is, after all
<Saviq> dandrader, in any case, the closing surface should not cause me being unable to start an app, shouldn't it?
<Saviq> dandrader, the log said "rejecting because there is one queued to start already"
<Saviq> or some such
<dandrader> Saviq, let me reproduce that situation before saying anything else.....
<Saviq> dandrader, yeah, sorry we have no better steps, but it happened to me straight away when I tried those steps from trello
<Saviq> and he had it with both camera and settings, so unlikely to be content-hub-related
<dandrader> Saviq, when launching settings straight from the dash!?
<Saviq> dandrader, I'd assume so, rvrÂ â?
<rvr> Saviq: ?
<Saviq> rvr, when you had settings in a "can't launch" state yesterday with broken silo 30
<Saviq> rvr, do you remember how did you start them before?
<rvr> Saviq: Ah, yes, directly from the Dash
<Saviq> dandrader, â
<rvr> But I also opened it from the indicators
<tsdgeos> Saviq: went the poor man's way to fix the i386 precision test failure https://code.launchpad.net/~aacid/unity8/card_test_precision/+merge/282425
<Saviq> tsdgeos, ack
<tsdgeos> i hate how the train makes the pacakges available but takes more time to merge the code in bzr
<Saviq> tsdgeos, that's only because of overlay
<Saviq> they're not published in xenial until they migrate
<tsdgeos> right
<tsdgeos> i mean
<tsdgeos> no
<tsdgeos> 8.11+16.04.20160111.1-0ubuntu1
<tsdgeos> says apt-cache policy in xenial
<Saviq> sure you don't have proposed enabled?
<Saviq> https://launchpad.net/ubuntu/+source/unity8
<Saviq> ah because it got published already
<Saviq> code should be there then, too
<Saviq> ah it's waiting for gsettings-qt
<Saviq> which is blocked by unity-scope-click's flaky tests :*
<mterry> tsdgeos, ah that must have been it -- I didn't run make so CardCreator.js never got copied.  Didn't know about that
<tsdgeos> mterry: yeah it's a bit weird
<mterry> tsdgeos, presumably our cmake code is missing a target depends there for the test
<tsdgeos> Saviq: is there anything we can do to convince it into publishing the changes to bzr?
<Saviq> tsdgeos, yes
<Saviq> will ask for a forced merge&clean
<mterry> Saviq, ooh, a "Unity8 bot" instead of jenkins CI  :)
<Saviq> busy busy https://unity8-jenkins.ubuntu.com/view/qtmir/
<tsdgeos> cimi: https://code.launchpad.net/~aacid/unity8/avila_apps_scope/+merge/282454
<tsdgeos> Saviq: it has colors \o/
<tsdgeos> and boxes \o/
<tsdgeos> whatever they mean :D
<cimi> tsdgeos, ok !
<tsdgeos> mzanetti: that branch for you too âââ
<Saviq> tsdgeos, as long as it's green ;)
<tsdgeos> I wonder if the newly released Qt virtual keyboard is of any interest to us
<tsdgeos> Saviq: will you give us a quick lesson on how to read those boxes in Austin?
<Saviq> tsdgeos, sure
<Saviq> tsdgeos, IIUC not really, it's more geared towards embedded
<tsdgeos> code landed!
 * tsdgeos runs the conflcits script
 * Saviq will put that script in our CI at some point :p
<Saviq> @unity FYI: if qtmir tests failed for you it's because of https://code.launchpad.net/~saviq/qtmir/use-qstandardpaths-cache/+merge/282394
<tsdgeos> Saviq: on next qtmir landing can you include https://code.launchpad.net/~aacid/qtmir/timestampsInPast/+merge/280567 (and optionally https://code.launchpad.net/~aacid/qtmir/unlikelyResetStartTime/+merge/281843 )?
<Saviq> tsdgeos, ack
#ubuntu-unity 2016-01-14
<Saviq> @unity: correct, while PS Jenkins Bot works, trust that one, Unity8 doesn't run all the QML tests yet, just builds packages
<mzanetti> kk
<tsdgeos> mzanetti: i set back to needs review your launcher branches
<tsdgeos> tests are failing
<oSoMoN> Saviq, hey, Iâm looking at https://bugs.launchpad.net/qtubuntu/+bug/1433138 , trying to understand the code that forwards key events in src/ubuntumirclient/input.cpp, and more specifically the translateKeysym function, which apparently was written by Gerry but he doesnât seem to be around, do you know who could help me make sense of it?
<ubot5> Launchpad bug 1433138 in qtubuntu "Under Mir, physical keyboardâs Return key does not work within web pages" [High,In progress]
<tsdgeos> oSoMoN: yeah gerry is on holiday
<tsdgeos> oSoMoN: what question do you have about that function?
<oSoMoN> tsdgeos, see my last comment on the bug report: https://bugs.launchpad.net/webbrowser-app/+bug/1433138/comments/12
<ubot5> Launchpad bug 1433138 in qtubuntu "Under Mir, physical keyboardâs Return key does not work within web pages" [High,In progress]
<oSoMoN> tsdgeos, and a related question: where do I find the logs for qtubuntu?
<tsdgeos> oSoMoN: interesting
<tsdgeos> oSoMoN: what do you mean the logs?
<tsdgeos> in bzr?
<tsdgeos> mzanetti: did you see the other launcher branch also needs updating?
<mzanetti> yes, on it atm
<mzanetti> tsdgeos, ^
<tsdgeos> k
<mzanetti> tsdgeos, something is broken with the launcher
 * mzanetti tries trunk
<tsdgeos> mzanetti: seems fine here, what do you find broken?
<mzanetti> dismiss by tap somehow behaves really weird
<tsdgeos> seems pretty solid here on the latest phone image
<tsdgeos> there was a bug fixed lately about that
<tsdgeos> are you trying trunk or your branches?
<tsdgeos> maybe you somehow reverted it on your branches?
<tsdgeos> back in 15
<tsdgeos> pstolowski: ping
<pstolowski> tsdgeos, pong
<tsdgeos> pstolowski: taping on an artist in the my music scope
<tsdgeos> takes a long time to show me the artist "page" on the scope
<tsdgeos> at first i thought it was hung or something
<tsdgeos> long time like 10 seconds or more
<pstolowski> interesting.. it's instant here. but maybe because i've all the images cached already
<pstolowski> i think i saw the bug where we request insanely large image size for artist, but not sure
<pstolowski> lemme try to find it
<tsdgeos> i can reproduce it more or less
<tsdgeos> "The Gossip" is the artist
<pstolowski> tsdgeos, can you share the mp3 file?
<tsdgeos> i guess that depends on the legal situation of your country :D
<pstolowski> i'll remove if after the test, i promise ;)
<oSoMoN> tsdgeos, sorry I didnât see your answer earlier, by logs I mean the logs that are output (somewhere in a file, presumably) when there is a call to LOG("â¦") in the code
<tsdgeos> ah
<tsdgeos> :D
<oSoMoN> couldnât find them anywhere in /var/log nor in /home/phablet/.cache/upstart/
<oSoMoN> not sure where else to look for them
<tsdgeos> oSoMoN: LOG is going to qDebug
<tsdgeos> DLOG is compile time
<tsdgeos> so if you're using the packages may go to nowhere
<tsdgeos> LOG should be in /home/phablet/.cache/upstart/ i undertand that in the app log itself
<oSoMoN> ah indeed
<oSoMoN> Iâd swear IÂ had looked for them there too
<oSoMoN> tsdgeos, thanks
<mzanetti> tsdgeos, ok... there was a criss cross merge which would duplicate functions (like the assertFocusOnIndex one) without showing me any conflicts at all
<mzanetti> should be good now I hope
<tsdgeos> we're getting SUCCESS in CI in vivid qmluitests again
<tsdgeos> \o/
<tsdgeos> i'm having a look at the xenial ones
<Saviq> tsdgeos, nice
<Saviq> tsdgeos, just started a run in Jenkaas, wonder how that goes ;)
<tsdgeos> he he
<mzanetti> tsdgeos, do'h!
<mzanetti> sorry :D
<tsdgeos> k
<dandrader> mzanetti, would you have some spare time to review this one? https://code.launchpad.net/~dandrader/unity8/dontRotateDesktop-lp1515977/+merge/282590
<mzanetti> dandrader, ack
<ltinkl> dandrader, one question there, nothing needed to be done in the DesktopStage?
<ltinkl> dandrader, meh sorry, overlooked it
 * Saviq positively surprised @jenkaas's package install speed
<Saviq> it's done within 2m30s for full unity8 installation in a clean chroot
<Saviq> definitely not a priority to reduce, then
<Saviq> will first have a look at ccache, then
<mzanetti> ltinkl, this only happens when interacting with the mouse, correct? https://code.launchpad.net/~mzanetti/unity8/launcher-sizing/+merge/280149/comments/717178
<ltinkl> mzanetti, let me try with touch
<mzanetti> ltinkl, well, I meant pointer device
<mzanetti> ltinkl, question was really: I can't repro it if sticking to kbd interaction
<mzanetti> but it seems to happen when mixing kbd navigation and pointer interaction
<ltinkl> mzanetti, yeah, with touch too; the point is, if the quicklist is open and the kbd navigation is on, launching something or clicking outside the quicklist renders the focus ring unusuable
<mzanetti> ack
<ltinkl> mzanetti, if you don't touch/tap and just use the keyboard, all seems to be fine
<mzanetti> just wanted to understand your issue properly
<tsdgeos> Saviq: the one for the launcher tests that sometimes fail to open the launcher https://code.launchpad.net/~aacid/unity8/launcher_test_remove_dda_constraints/+merge/282600
<Saviq> tsdgeos, coolz, that should improve autopkgtest results in the cloud then (as we had a slew of launcher fails on xenial)
<ltinkl> Saviq, yup, just tried that on xenial locally, was passing
<Saviq> nice nice
<ltinkl> I'm seeing something weird locally in all branches:
<ltinkl> file:///home/ltinkl/bzr/unity8/alt-input/qml/Components/NotificationAudio.qml:38: Error: Qt.createQmlObject(): failed to create object:
<ltinkl>     file:///home/ltinkl/bzr/unity8/alt-input/qml/Components/inline:1:34: Cannot assign to non-existent property "source"
<ltinkl> tsdgeos, deos it ring a bell?
<tsdgeos> that's how it's supposed to be
<tsdgeos> i think
<tsdgeos> yeah
<tsdgeos> it's our way of load this or that
<ltinkl> should it fail really?
<ltinkl> but this doesn't seem to load anything
<ltinkl> before I used to be getting: Upstream audioRole enum not available, falling back to old role name.
<ltinkl> which is imho correct
<tsdgeos> ah wait, this is the tests
<tsdgeos> yeah the mock is incomplete
<tsdgeos> and doesn't have a source property
<Saviq> tsdgeos, nice one https://unity8-jenkins.ubuntu.com/view/Maintain/job/run-commands/376/consoleFull - only LazyImage failed, that should be fixed by cimi's lp:~cimi/unity8/fix-lazyImage-test-flakyness, if he ever puts it into Needs review ;)
<Saviq> not sure why xml output isn't there
<Saviq> and 40mins... definitely need to improve that
<tsdgeos> i guess we could re-add it for the sake of less noisy test runs
<tsdgeos> Saviq: compile+test run?
<Saviq> tsdgeos, "just" the test run, which only compiles mocks and such
<tsdgeos> Saviq: it's what it takes, no? whenevre i do a full run it's also slow
<Saviq> on that note, we're building mocks on a normal build, aren't we
<Saviq> tsdgeos, well, we can parallelize them
<tsdgeos> oh sure, if there's more cpus we could
<tsdgeos> Saviq: i think we probably are yes
<Saviq> we probably shouldn't
<cimi> Saviq, it is needs review, but I need to address mzanetti comment
<ltinkl> tsdgeos, ah right ofc, it's in tests :)
<Saviq> cimi, oh, thought it's down in WiP
<Saviq> Mirv, are you aware of a cross-build dependency issue somewhere in qt 5.5 packages? I've had lpunity-api cross-build fine on vivid but fail on xenial, can get you a more info if you need
<cimi> mzanetti, ping
<cimi> mzanetti, you sure https://code.launchpad.net/~cimi/unity8/fix-lazyImage-test-flakyness/+merge/277459/comments/705903 works?
<mzanetti> cimi, it should
<cimi> mzanetti, how would you use it, I added the id to the animations inside the transition, but still fails to get it
<cimi> mzanetti, I tried looking with findChild and findInvisibleChild both on the root and from the transition that contains the animation
<cimi> still always same error of cannot find obj
<mzanetti> cimi, hmm... odd
<mzanetti> cimi, but you can use tryCompare on any of the properties that are animated in the transition
<cimi> mzanetti, or I can try to add a property instead a signal, but to be honest I might have already tried in november, there must be a reason why I ended up adding a signal
 * cimi forgot
<mzanetti> I quite dislike adding such signals to a component's api if it's really only for testing... In most cases tests can be done nevertheless just as good
<mzanetti> but if you really find no way out with this one...
<cimi> mzanetti, do you have the flakyness on your laptop?
<mzanetti> for this test?
<cimi> yes
<mzanetti> need to try
<cimi> mzanetti, just run make testLazyImage
<cimi> if your pc is fast it fails
<cimi> in the offie atm and it does not fail here :)
<mzanetti> my pc used to be fast... now its quite regular
<cimi> :)
<mzanetti> cimi, no... passes here
#ubuntu-unity 2016-01-15
<Mirv> Saviq: no, no aware, let's try to find what it is about
<tsdgeos> Saviq: you've made test failures be failures instaead of unstable? https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/15/
<Saviq> tsdgeos, otherwise we'd end up in the make exit code situation potentially
<tsdgeos> ok, that's a bit of a step back but not terrible i guess
<Saviq> tsdgeos, you mean to not see the difference between unstable and failed?
<tsdgeos> yep
<Saviq> tsdgeos, I could interpret adt-run exit status http://manpages.ubuntu.com/manpages/precise/man1/adt-run.1.html
<tsdgeos> i guess it's fine, i mean it's just a few extra clicks
<Saviq> so if 2,4,6,8, exit 0
<Saviq> tsdgeos, no I get what you mean, when we get reports on MPs it's important to know the difference
<Saviq> hopefully I can still mark it unstable if 2,4,6,8
<Saviq> so we don't miss make exit
<Saviq> yeah easy enough to do
<tsdgeos> ok :)
<Saviq> d'oh, looks like we'll build up a dummy .xml file after all :P
<tsdgeos> mzanetti: Saviq: we're going to need a decision on whether we want https://code.launchpad.net/~aacid/unity8/fallback_for_empty/+merge/282002 or not
<Saviq> tsdgeos, mzanetti, you were arguing that it might be desirable to pass empty, I somewhat agree that fallback was meant for the case where the scope can't do anything about it, because they don't know if we successfully retrieve the image
<Saviq> when sending empty, they might as well send the fallback url again
<Saviq> s/again/instead/
<mzanetti> that's our thinking yes
<mzanetti> but dobey strongly disagrees
<tsdgeos> my guess  is mostly by the "fallback" name than by real disagreeing
<Saviq> ultimately it's the API guys' decision
<Saviq> because they're signing the contract with the scope developer
<Saviq> s
<mzanetti> fair enough.
<Saviq> tsdgeos, https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/16/ should come up unstable now instead of failed (/me should have ran the parallel qmluitests instead, cuts the time by half)
 * Saviq starts thinking Jenkaas might be a good thing for us in the end
<Saviq> looks like I'll be able to cut the CI turnaround by a significant margin
<Saviq> but we seem to have "lost" almost twenty tests somehow
<tsdgeos> :?
<Saviq> tsdgeos, and btw, it was enough to make them run in parallel https://code.launchpad.net/~saviq/unity8/parallel-qmluitests/+merge/282603 ;)
<Saviq> tsdgeos, I mean https://code.launchpad.net/~saviq/unity8/parallel-qmluitests/+merge/282603/comments/717308
<Saviq> tsdgeos, well, ok, not 20, but 7 https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/13/testReport/ vs. https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/13/testReport/
<tsdgeos> Saviq: that's the same link twice
<Saviq> grr
<Saviq> tsdgeos, https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/1774/testReport/%28root%29/ vs. https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/13/label=amd64,release=vivid+overlay/testReport/%28root%29/
<Saviq> meld to the rescue
<tsdgeos> weird
<Saviq> tsdgeos, that's the diff http://pastebin.ubuntu.com/14503845/
<Saviq> ah I wonder if it put the .xml file somewhere
<Saviq> or or
<Saviq> same name
<Saviq> or not part of xvfballtests
<Saviq> 'cause I can't see them at all in the adt-run log
<Saviq> tsdgeos, oh oh, and... good news and bad news https://requests.ci-train.ubuntu.com/#/ticket/877 (check out "Automated test results")
<tsdgeos> aren't they part of make test?
<Saviq> tsdgeos, I'll find them, nw
<tsdgeos> hey, got a pass for amd64
<tsdgeos> still some failures though :/
<Saviq> tsdgeos, the i386 fail on vivid is a time out, something got stuck (3h between start and timeout)
<Saviq> armhf is like a swiss cheese :/
<tsdgeos> yeah :D
<tsdgeos> i'll have a look
<tsdgeos> i think most are timing related
<tsdgeos> but still it'd be great if we could get them to pass
<Saviq> 123 failures
<Saviq> we could use the .xml out of that
<Saviq> xenial i386 is just two fails in launcher that didn't get pulled out, so some improvement needed there, too
 * Saviq worried to make them pass, they will shout Regression! at us all the time after that
<Saviq> ah, wonder if it's the parallel that made them stuck
<Saviq> hmm no, xvfballtests still went -j1
<Saviq> only 52 failures on xenial armhf :)
<tsdgeos> he he
<Saviq> Mirv, hey, so yeah lp:ubuntu-settings-components cross-builds on vivid+overlay but not on xenial: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=cross-armhf,release=xenial/163/console
<Saviq> Mirv, same for lp:unity-api https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/164/
<Saviq> owait that's actually a different - g++ - issue
<mzanetti> Saviq, hey, I'm sure I saw a bug report coming by lately for apps crashing if you launch them immediately after closing them
<mzanetti> can't find it any more, neither in my inbox nor on LP
<mzanetti> you happen to know about it?
<Saviq> mzanetti, bug #1527737
<ubot5> bug 1527737 in qtmir (Ubuntu) "Apps do not start if restarted quickly after closing" [High,In progress] https://launchpad.net/bugs/1527737
<mzanetti> faenil, ^
<mzanetti> thanks Saviq
<faenil> ah finally :) thanks
<Saviq> we almost landed a fix, but found a bad regression that sometimes stopped you from launching apps altogether...
<faenil> I see
<faenil> left a comment there with my current experience
<Saviq> Mirv, *or* my chroots are borked, can't seem to reproduce locally
<Saviq> ah
<Saviq> proposed??
<Mirv> Saviq: hmm
<Mirv> Saviq: maybe some gcc proposed update indeed
<Saviq> Mirv, that would actually explain the boost issue as well
<Mirv> Saviq: there was a new gcc-5 upload 14 hours ago
<Mirv> at least
<Saviq> hmm I first saw the issues earlier than that
<Mirv> boost stuff from a week ago is in release pocket
 * Saviq recreates the chroots
<Saviq> Mirv, meh, can't reproduce locally, will let you know what I find out
<Mirv> Saviq: ok, let's see later
<Saviq> tsdgeos, yay, unstable https://unity8-jenkins.ubuntu.com/view/unity8/ (second from the top)
<tsdgeos> Saviq: third?
<Saviq> maybe third by now
<tsdgeos> parallel one, no?
<Saviq> yes
<Saviq> yellow-ish
<Saviq> instead of red
<Saviq> need to fix the upstream job, too (thought I did already)
<Saviq> ah
<Saviq> now I did
<tsdgeos> food!
<mterry> Saviq, how trustworthy are the unity8 CI bot results so far?
<tsdgeos> dandrader: have a sec?
<dandrader> tsdgeos, yeah
<tsdgeos> dandrader: i can't figure out why mouseMove on the tests is failing to turn containsMouse of a MouseArea to true
<tsdgeos> i thought it was the MouseTouchAdaptor
<tsdgeos> but i've set it to false and still fails
<tsdgeos> dandrader: i can push the branch somewhere if you want
<dandrader> tsdgeos, MouseTouchAdaptor should be completely transparent to tests
<dandrader> tsdgeos, your second is up
<dandrader> :)
<tsdgeos> ok
<dandrader> tsdgeos, does it happens only in tests?
<dandrader> tsdgeos, or in "make tryFoo" as well?
<tsdgeos> make tryFoo works if i uncheck the "mouse emulates touch"
<tsdgeos> checkbox
<dandrader> tsdgeos, add some wait(xxx) between commands. helps to see if there's some race/timing issue
<tsdgeos> yeah i did, didn't seem to help
<tsdgeos> will keep trying, don't worry
<tsdgeos> it was just if you had something quick in mind
<Saviq> mterry, by now should be really trustworthy, modulo autopilot, which don't run yet
<Saviq> and armhf, which we can't build
<Saviq> and I need to find 7 tests that disappeared :P
<mterry> Saviq, hah we can't build armhf?  Because of ci restrictions?  that seems like a big gap  :)
<Saviq> mterry, no
<Saviq> because of bug #1472186 (I wanted to cross-build)
<ubot5> bug 1472186 in indicator-network (Ubuntu) "Can't install libconnectivity-qt1-dev on multiarch" [High,Confirmed] https://launchpad.net/bugs/1472186
<Saviq> where possible
<mterry> Saviq, ah
<Saviq> will likely need an armhf node for non-cross-buildable stuff
<Saviq> and then we have a phone, but don't want to use that for building, only for ap
<Saviq> on that note
<oSoMoN> is there a way to change the keyboard layout of a bluetooth keyboard connected to a phone?
<oSoMoN> nm, found https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1412492
<ubot5> Launchpad bug 1412492 in unity8 (Ubuntu) "can't change the keyboard layout" [Undecided,Confirmed]
<Saviq> mzanetti, not sure what failed in launcher-sizing autopkgtest, added some debugging and restarted
<ltinkl> oSoMoN, nope, not supported yet
<mzanetti> hmm
<oSoMoN> thatâs unfortunate, thereâs a lot of people out there who donât use qwerty and want to type non latin1 characters
<Saviq> oSoMoN, we're thinking hard about it ;)
<Saviq> but
<Saviq> people not using qwerty are... well, you know what I mean :P
<oSoMoN> Saviq, no IÂ donât, what do you mean?
<Saviq> I mean it's their own fault :P
<Saviq> should be forced to use qwerty for the sake of humanity
<ltinkl> Saviq, right but it's mainly about being able to input non latin1 stuff :)
<Saviq> I'm using qwerty and input non-latin1 stuff all the time
<Saviq> not to mention compose key
<Saviq> we've done away with the "polish" layout some time ago and everyone uses "polish (programmer's)" now ;)
<Saviq> with AltGr to add diacriticts
<Saviq> but yeah, /me has caps mapped to compose, much more useful
<oSoMoN> does Mir allow remapping keys?
<Saviq> not yet I don't think
<ltinkl> Saviq, yeah but not in u8, Mir forces a "en_US" layout
<Saviq> ltinkl, I know, I know :P
<ltinkl> Saviq, otherwise I'm using a cz+qwerty+AltGr as well
<Saviq> grr /me broke autopkgtest job, fixing
<Saviq> fixeded
<faenil> Saviq: is it possible to install&run click apps on desktop unity8 yet?
<faenil> I played a bit with click install + register
<faenil> but didn't get anywhere
<faenil> (note: it could have been that the click was corrupt as well)
<Saviq> mzanetti, you have a recipe for that â ;)
<mzanetti> faenil, should work, yes
<mzanetti> faenil, need click install, yes. but then it should just work
<mzanetti> faenil, store is broken. you can still click on them to download them. they'll end up in ~/.cache
<mzanetti> faenil, installation with pkcon will fail, but click install should work
<mzanetti> you need multiarch or x86 packages obviously
<faenil> mzanetti: yeah, does store hand out x86 or arm packages?
<faenil> and I used click install + register but it didn't work...must have been the click then
<faenil> mzanetti: pkcon is because it has apt configured as backend right?
<faenil> I had a quick look at how to swap pkcon's backend but didn't find any simple way
<oSoMoN> Saviq, ltinkl: I could use a review for https://code.launchpad.net/~osomon/qtubuntu/qkeyevent-native-virtual-key/+merge/282515
<davidcalle> Here we go! https://developer.ubuntu.com/en/blog/2016/01/15/announcing-ubuntu-scopes-showdown-2016/
<mzanetti> faenil, yes, and yes
<mzanetti> faenil, core apps are packaged multiarch nowadays
<mzanetti> faenil, simple webapps or qml only would work too
<faenil> mzanetti: okay, cool
<faenil> mzanetti: nah, clicks
#ubuntu-unity 2017-01-09
<Mirv> tsdgeos: so I was considering publishing final Qt 5.7.1 to zesty, but it turns out Unity 8 has some new test issues - can you look at how serious bug #1654819 failures seem?
<ubot5> bug 1654819 in unity8 (Ubuntu) "new failing qmluitests with Unity 8 on Qt 5.7.1" [Critical,New] https://launchpad.net/bugs/1654819
<tsdgeos> sure i saw your email/bug
<tsdgeos> still didn't get to it
<tsdgeos> let me skip the queue
<tsdgeos> look relatively bad
<tsdgeos> is that because you packager a newer Qt?
<tsdgeos> last time we did this the tests passed, no?
<tsdgeos> was it pre 5.7.1?
<Mirv> tsdgeos: yeah you closed the previous bug, that was near-final snapshot 20161022
<Mirv> tsdgeos: but it seems they changed something (fixed bugs, hopefully) before releasing the final
<tsdgeos> let me see what's missing
<Mirv> considering it's an already published stable series, changes like that in final stretch of getting .1 out are a bit unfortunate
<Mirv> all seem surface sort of issues, in test failures group of 3, 4 and 4 failing tests
<Mirv> not much in qtdeclarative http://code.qt.io/cgit/qt/qtdeclarative.git/log/?h=v5.7.1
<Mirv> not much in qtbase either http://code.qt.io/cgit/qt/qtbase.git/log/?h=v5.7.1
<tsdgeos> there was someone reporting some shortcut issues in Qt 5.7.1. vs 5.7.0 in the kde mailing lists over the weekend
<tsdgeos> didn't really pay much attention though
<tsdgeos> was busy playing kingdom rush frontiers ^_^
<Mirv> there are essentially 5 (five) real commits together in qtbase and qtdeclarative 5.7.1 since 20161021
<Mirv> ^_^
<Mirv> maybe that fbo commit in qtbase or V4 change in qtdeclarative could be related
<Mirv> I guess those surface tests wouldn't use jpegs
<Mirv> and of course there is always a possibility of something else in zesty changed, although Qt doesn't use much besides C library
<tsdgeos> the ubuntu browser killed my session ^_^
<tsdgeos> oSoMoN: â
<oSoMoN> tsdgeos, how did it do that? do you have logs / a crash file?
<tsdgeos> oSoMoN: so konsole has this "right click -> open url" when hovering a link
<tsdgeos> i clicked on it and somehow the ubuntu browser decided it was better than the firefox i had configured previously to open the link
<tsdgeos> and that's all i have
<tsdgeos> everything locked up and i needed to reboot the laptop
<oSoMoN> wow
<oSoMoN> tsdgeos, but your DE is configured to use firefox as default? or was the default somehow overridden?
<tsdgeos> if i click on a quassel link it'll open firefox
<tsdgeos> no idea why konsole decided to use the ubuntu browser
<oSoMoN> tsdgeos, is it reliably reproducible?
<tsdgeos> the crash?
<tsdgeos> i am not sure i want to try to lock my system again :D
<tsdgeos> but ok
<tsdgeos> i'll do it for you :)
<oSoMoN> tsdgeos, thanks :)
<oSoMoN> tsdgeos, I meant the fact that konsole will open the link in the browser
<tsdgeos> oSoMoN: both :D
<tsdgeos> oSoMoN: you've a telegram picture of the crash
<Mirv> tsdgeos: did you miss my ponderings about the only 5 commits in qtbase/qtdeclarative when it crashed? https://irclogs.ubuntu.com/2017/01/09/%23ubuntu-unity.html
<tsdgeos> i guess i did
<tsdgeos> was testing webbrowser-app crashyness
<tsdgeos> Mirv: there's also a weird error message about itemgrabber not being registered
<tsdgeos> let me see if i get that on current zesty
<tsdgeos> nope
<tsdgeos>  file:///home/tsdgeos/unity8/qml/Stage/ApplicationWindow.qml:143:5: QML Image: Protocol "itemgrabber" is unknown
<tsdgeos> this is bad
<tsdgeos> also
<tsdgeos> Trying to pass extra request flags to provider but it is not a QQuickImageProviderWithOptions
<tsdgeos> is weird
<tsdgeos> Mirv: do we still carry any QQuickImageProviderWithOptions patch?
<Mirv> UITK has that providerwithoptions warning too in 2/3 of its tests
<Mirv> tsdgeos: here is the list https://anonscm.debian.org/cgit/pkg-kde/qt/qtdeclarative.git/tree/debian/patches?h=ubuntu%2b1
<Mirv> I don't see any in qtdeclarative 5.6.1 either https://anonscm.debian.org/cgit/pkg-kde/qt/qtdeclarative.git/tree/debian/patches?h=ubuntu/5.6.1-7ubuntu2
<tsdgeos> ok
<Mirv> the async stuff was merged in 5.6
<tsdgeos> oSoMoN: https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1654974
<ubot5> Ubuntu bug 1654974 in webbrowser-app (Ubuntu) "webbrowser-app locks up my session (zesty)" [Undecided,New]
<oSoMoN> tsdgeos, thanks
<oSoMoN> tsdgeos, I will look into it today
<tsdgeos> oSoMoN: it *may* be related to using unity8-greeter as greeter
<tsdgeos> since i think one of the times it crashed
<tsdgeos> on reboot
<tsdgeos> it complained about unity-system-compositor having crashed
<tsdgeos> but you can't know if it did really cause the crash or it crashed because i hard rebooted the laptop and then things get antry
<tsdgeos> angry
<tsdgeos> Mirv: do you know the hash of the qtdeclarative of the last try?
 * tsdgeos hates vim decided to change behavoiur when you use the mouse on it
<Saviq> tsdgeos, thought it's some plugin, but /me hates, too
<tsdgeos> i did changed it in my main account
<tsdgeos> but chroot still borked
<tsdgeos> set mouse-=a
<tsdgeos> fixed it afair
<Mirv> tsdgeos: as Debian named its orig tarball as 5.7.1~20161021, and looking at http://code.qt.io/cgit/qt/qtdeclarative.git/log/?h=v5.7.1 , I'd say it was very likely that last 2016-10-05 merge commit ie fff4477661ae240c43088fa6d9069ccf969dbee8
 * tsdgeos kicks himself for not having made
<tsdgeos> "Trying to pass extra request flags to provider but it is not a QQuickImageProviderWithOptions" be better
<tsdgeos> it's like "something is wrong"
<tsdgeos> but i'm not going to tell you where
<tsdgeos> thought that is a red herring!
<tsdgeos> Mirv: ok i can reproduce the problem in a smaller scale now, so we're making progress
<Mirv> tsdgeos: diff between 20161021 orig tarball and final 5.7.1: http://paste.ubuntu.com/23769521/ - additionally, added the SignalSpy fix and Scale-images-correctly patches
<Mirv> tsdgeos: ok
<tsdgeos> i am thinking  Scale-images-correctly may be bad
<tsdgeos> yo i am a bad devel!
<tsdgeos> every patch i bring breaks stuff :D
<Mirv> someone requested it :)
<tsdgeos> wonder who that may be
<tsdgeos> ok at least it seems only dev upstream contains that
<tsdgeos> so i didn't break much outside dev and our wannabe packages
<tsdgeos> let me confirm it's it
<Mirv> zsombi: you may want to pay attention here if you started looking at that QQuickImageProviderWithOptions UITK warning
<tsdgeos> the warning itself is "ok"
<tsdgeos> it's not what causes the regression
<tsdgeos> but would be nice to get fixed too if possible of course
<tsdgeos> and yes i need to improve the warning
 * zsombi reading the logs
<zsombi> tsdgeos: Mirv: ok, so what is the conclusion? is that warning a valid one? is something screwed that we need to fix still?
<tsdgeos> zsombi: it is a valid warning (even though the message can defenitely be improved)
<tsdgeos> you can also ignore it, since it's a "this could be better"
<tsdgeos> not a "this is wrong" kind of warning
<zsombi> tsdgeos: any hunch what actually causes it?
<zsombi> yeah, the warning text is a bit weird :D
<tsdgeos> the new QQuickImageProviderWithOptions code i added
<tsdgeos> basically image providers can (in dev + our patches) know they are being asked to do aspectImageFit/Crop
<tsdgeos> and provide better images
<tsdgeos> than the ones they did before
<zsombi> I see
<zsombi> and how are we supposed to let it know?
<zsombi> tsdgeos: the doc https://doc-snapshots.qt.io/qt5-dev/qquickimageprovideroptions.html is pretty weak...
<tsdgeos> ey
<tsdgeos> it has a see also to itself
<tsdgeos> pretty awesome
<tsdgeos> zsombi: you don't let it know, it let's you know
<tsdgeos> an no
<tsdgeos> ah no
<tsdgeos> it has a see also to QQuickImageProviderWithOptions
<tsdgeos> that i guess give it's hidden in a _p.h
<zsombi> haha
<tsdgeos> doesn't get the docu generated
<tsdgeos> Mirv: for now i'd say revert that patch, i need to figure out how to unbreak Item::grabToImage
<tsdgeos> Mirv: you added it to debian too? or only ubuntu?
<Mirv> tsdgeos: only Ubuntu, I tend to avoid automatically adding our patches to Debian unless they are from upstream stable branch or such
<Mirv> tsdgeos: ok then
<tsdgeos> ok, good
<tsdgeos> i mean i still need to come up with a fix since upstream is broken
<tsdgeos> but that should unblock you
<Mirv> fabulous. I wonder if I dare to then publish the silo without pre-running autopkgtests again, since I get flamed for occupying autopkgtest infra for 3+ days multiple times.
<Mirv> I think I will, but will ask to test once more from the PPA once it's built
<Mirv> also since UITK shows the warning in unit tests I can just see about its rebuild
<tsdgeos> that warning will also be gone if you revert that patch
<Mirv> doh, forgot to revert the symbol changes
<Mirv> rebuild
<Mirv> tsdgeos: ok 1985 now updated with qtdeclarative.
<tsdgeos> Mirv: tests seem to be back to good now
<Mirv> great
<rvr> Is there anyway to dismiss the gesture wizard in kvm?
<Saviq> rvr, for whatever reason KVM does not allow you to "trap" your pointer in the window, so you can't push against the edge... using USB forwarding was the only way I found
<Saviq> tried with the different graphics/input stacks and it was either that or no input at all...
<rvr> Saviq: USB forwarding? How does it work?
<rvr> Saviq: Oh, you mean, sharing the mouse device directly with the VM?
<Saviq> rvr, yes
<rvr> Interesting!
<Saviq> rvr, that's really the only way to fully use it anyway, as how else will you trigger launcher or right edge
<rvr> Saviq: Thanks for the tip
<roasted> Hi friends. Is there a "feature request form" of some sort in regard to Unity 8 features?
<dmj_s76> hey Trevinho!
<greyback> roasted: really the best place is to log a bug https://bugs.launchpad.net/ubuntu/+source/unity8
<roasted> greyback: I wondered that, but "bug" didn't feel right to me, so I felt compelled to dig around first before submitting.
<greyback> roasted: I agree it feels strange, but we do also keep track of features we add via bugs. We find it handiest to use a single database for bugs, features and wish-list things
<roasted> greyback: sounds good. thanks for the insight. :D
<greyback> np, thanks for dropping by :)
<roasted> greyback: I'm somewhat hesitant to submit this in the name of cluttering things up. Perhaps you know offhand. Do you know if Unity 8 has/is planned to get display scaling/desktop zoom support?
<roasted> I'm asking on behalf of students at my district. We have a few that are visually impaired and benefit massively from U7's zoom/scale abilities.
<greyback> roasted: accessibility features like scaling, zoom, high-contrast are indeed on our roadlist
<greyback> roasted: by adding a bug, it will help push those features up the priority queue :)
<roasted> oh? well hot dog I'll submit it then.
<roasted> Maybe a heart-warming success story of a few middle school kids who use them on a daily basis to better their education would help. :P
<dmj_s76> roasted: Please do!  This will have to be implemented in a new way.  The U7 zoom functionality you're talking about is based on a Compiz plugin I believe.  When I was teaching computers to visually impaired students, the compiz zoom was super useful to them.
<roasted> super useful doesn't even do it justice. It's *gold* to the few kids we have that depend on it. :D
<greyback> yep, and to many others. We for sure want to keep that feature working in unity8
<roasted> submitted. thanks you awesome folks. <3
<greyback> roasted: thank you for the feedback, it is always appreciated
<dmj_s76> roasted: bug link?  I may want to follow this
<roasted> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1655099
<ubot5> Ubuntu bug 1655099 in unity8 (Ubuntu) "Feature Request - Scale/Zoom Features for Visually Impaired" [Undecided,New]
#ubuntu-unity 2017-01-10
<guest0915362> Hi
<guest0915362> anyone here who could tell me how the following was implemented:
<guest0915362> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1099476
<ubot5> Ubuntu bug 1099476 in xorg-server (Ubuntu) "Hiding the mouse cursor when I use my touchscreen?" [Wishlist,Confirmed]
<guest0915362> ?
<guest0915362> I mean that the cursor automatically hides when the touchscreen is in use and reappears when the mouse is being used
<guest0915362> it works
<guest0915362> but how does it work ;)?
<guest0915362> I've already asked in #ubuntu-desktop, but they didn't know either
<mterry> Are there any good resources for printing various Qt objects (like QList, QString) in gdb?  Searching the internet has given me an (untested) macro for qstring...  but nothing for more complicated structures.  They seem like a maze of d-> objects and void* arrays
<mterry> Saviq: do you like the output of https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/label=amd64,release=zesty,testname=qmluitests.sh/2166/consoleFull better? Seems to group better to my eyes; this is with https://code.launchpad.net/~mterry/unity8/autopkg-fixes/+merge/314471
<Saviq> right, so it is stderr vs. stdout
<mterry> Saviq: yeah I looked, but parallel doesn't seem to have a way to disable its default of grouping all stderr vs all stdout  :-/
<Saviq> right
<Saviq> mterry, works for me
<Saviq> not sure we really need all the exports, but maybe
<mterry> maybe we could filter that a bit more smartly.  But I preferred to hew as closely to the internal tests as possible
<dmj_s76> andyrock_: Have you had a chance to talk to Trevinho about https://code.launchpad.net/~azzar1/unity/round-gtk-scaling-to-closest-integer/+merge/313459
#ubuntu-unity 2017-01-11
<andyrock_> dmj_s76: it should land soon
<andyrock_> He prepared a silo for z
<dmj_s76> okay
<tsdgeos> "We will release current content as Qt 5.8.0 release Tue 17th January if nothing really serious found during testing"
<tsdgeos> Mirv: let's just skip 5.7.1 :D
<tsdgeos> j/
<tsdgeos> k
<Mirv> tsdgeos: yeah right, I've heard that a lot over time :)
<Mirv> like why wouldn't we ship 16.04 LTS with 5.6 as 5.6 will be released in Oct^Dec^WFeb^W..
<Mirv> 5.7(.1) for 17.04, 5.8(.1) for 17.10, 5.9(.1) for 18.04 LTS is (unfortunately) realistic
<mterry> josharenson: ok I finished a separate thing, I can look at what's happening with greeter-arrangement -- any progress there?
<josharenson> mterry: haven't looked at it yet today, so nothing new yet
<josharenson> mterry: I don't mind looking further, but id be helpful if you could reproduce the issue as well just so I don't chase something non-existent
<mterry> sure
<mterry> josharenson: yup reproduced  :(  Imma noodle at it a bit
<josharenson> mterry: that good, and bad... keep me posted
#ubuntu-unity 2017-01-12
<mterry> Saviq: is there a way we could have CI run on MPs that are WIP?  (maybe with an opt-in or opt-out...)  I would find it helpful to have CI run the tests for me and make sure the MP is all-green before unleashing it on reviewers (I can run locally, but it's not always the same and takes some of my time to babysit them)
<om26er> Hi! How far along are pointer friendly indicators ? Are they expected to appear anytime soon ?
<cimi> om26er, hi, yeah they should happen soon https://bileto.ubuntu.com/#/ticket/2291
<Saviq> mterry, it's just software, wonder if it's a common enough use case to warrant the added complexity?
<Saviq> +but
<Saviq> mterry, in any case, lp:jenkins-launchpad-plugin
<tsdgeos> Saviq: mterry: why not doing what you did in https://code.launchpad.net/~mterry/unity8/slm-test/+merge/313546 ?
<tsdgeos> i seems to have worked since noone reviewed that branch :D
<mterry> tsdgeos: it still creates noise
<tsdgeos> mterry: well, then you can just run the CI "manually", no?
<tsdgeos> otoh that's also a bit cumbesrome
<mterry> tsdgeos: not as user friendly yeah
<mterry> This isn't a huge pain in my ass.  Just trying to streamline my flow and avoid situations where reviewers (you for example) wait for me to get green lights.  I guess I can run tests more locally but that's not as nice as CI doing it for me
<tsdgeos> sure
<Saviq> mterry, I think that's probably the most interesting thing - improving the unity8-ci job so that it takes just the MP link and finds all it needs itself
<Saviq> instead of having to pass branch and MP link and revision...
<Saviq> you can already pass only the branch, it will work, just not report anywhere (of course)
<mterry> Saviq: oh that's part of it being user unfriendly.  But also a normal MP gives me an email from LP when it's done, automatically kicks off on a simple bzr push, I can see the history of the job runs in the MP, etc.
<Saviq> mterry, sure, lp:j-l-p is the thing that's deciding which MPs to run CI for
<mterry> I might poke at it, yah
<Saviq> more important, IMO, is so it runs on top-approved MPs than on WiPs, but I suppose this might be easier
<Saviq> mterry, as for "maybe opt-in or something", that would suggest LP should have a new status between WiP and NR
<Saviq> not sure I'd go as far as that
<Saviq> I'd probably just do --include-wip
<Saviq> it only runs for branches owned by trusted people anyway
<Saviq> there's not so many WiP ones
<Saviq> and it's just a matter of adding a "Work in Progress" string to a list
<Saviq> top-acked are a bit more tricky, because you want to un-ack them and make sure the top revision is what's approved
<mterry> Saviq: maybe -- or you could opt in by setting Description to "ci-plz" or something hacky...
<Saviq> oh and yeah, git ;)
<mterry> But all CI could work too
<mterry> I mean
<mterry> All WIP could work too
<Saviq> I'd be ok with that
<Saviq> there are not so many of those
<Saviq> and it'd be a per-project decision
<tsdgeos> we actually have kind of a lot of WiP
<tsdgeos> but almost noone commits to them
<tsdgeos> so that's "fine"
<mterry> If anyone complains about the extra churn, I'd also be happy if it just did WIP on mterry branches  :)
<Saviq> tsdgeos, yeah that's what I meant, there's little movement on them
<Saviq> when we turn this on is when things will be busy for a while, but it will settle down
<Saviq> and most of them will probably die in conflicts to start with
<tsdgeos> yep
<tsdgeos> i wouldn't complain if we enable for trusted-WiP  either
<tsdgeos> can enable it on a friday so all the busy stuff is done over the WE
 * tsdgeos did a bit of french there
<mterry> josharenson: so I looked at the arrangement branch a bit...  nothing jumped out at me as obviously wrong.  I tried to back up the branch to find where it went wrong, but Mir dependencies made that hard.  no insights yet
<josharenson> mterry: I'm in the same place.. there is only 1 small thing I noticed
<josharenson> mterry: I have all kinds of Keys.onPressed scattered through out the code
<josharenson> mterry: and there was a weird thing with the app drawer... If I typed ~3 characters in the search bar, there were hundreds of key events triggered
<mterry> huh
<josharenson> mterry: which was suspicious... but I backed out the changes to the shell and the launcher and saw no improvement
<josharenson> mterry: I even replaced the greeter with a blue rectangle and didn't see any change
<mterry> huh
<josharenson> mterry: Heres one for you... Log in (with a passwordless user since you can't type) and then lock the session... Greeter works perfectly afterwards.
 * josharenson has an idea or two now...
<mterry> josharenson: that's odd
#ubuntu-unity 2017-01-14
<fn_> hi, I wonder about development so I came to watch you
#ubuntu-unity 2018-01-14
<TechmanHOVMJN> ââââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS zdzjiyqvd: davidcalle Mister_Q cwayne âââââââââââââ
<TechmanHOVMJN> ââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS etxpongdj: jzheng_ charles camerin âââââââââââ
<TechmanHOVMJN> ââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS fcpfmxbti: om26er Mister_Q flexiondotorg âââââââââââââââââââ
<TechmanHOVMJN> ââââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS hrqro: mardy andyrock mdeslaur ââââââââââââââ
<TechmanHOVMJN> âââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS wouumti: ubot9 dkessel ubot5 ââââââââââââ
<TechmanHOVMJN> âââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS offklyqwqo: mariogrip camerin cwayne ââââââââââââââââ
<TechmanHOVMJN> ââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS dhvwrbf: jzheng_ cwayne JanC ââââââââââââââââââ
