[07:05] <mzanetti> good morning
[07:06] <didrocks> hey mzanetti
[07:06] <MCR> Hi. Will Compiz be the standard WM for 13.10 ?
[07:07] <didrocks> MCR: yeah, Unity + Compiz will still be the default until Unity Next is up to parity for a desktop experience
[07:07] <didrocks> MCR: which realistically won't be the case for 13.10
[07:08] <MCR> didrocks, thanks for the answer - TBH I do not think anything could replace this combination anytime soon...
[07:08] <MCR> at least not without a ton of regressions
[07:08] <didrocks> MCR: we'll, we are only talking about Unity default experience
[07:08] <didrocks> not all the compiz crazyness
[07:08] <didrocks> and that's our goal to not regress for this
[07:08] <MCR> yeah, sure
[07:08] <hyperair> anything that doesn't have ezoom doesn't deserve to be called a replacement!
[07:09] <didrocks> hyperair: ezoom was never supported in Unity btw
[07:09] <didrocks> so we can only do better there :)
[07:09] <hyperair> didrocks: i know, which was why i brought it up.
[07:09] <hyperair> didrocks: but compiz contains ezoom, and unity+compiz works with ezoom well enough.
[07:10] <didrocks> hyperair: "well enough" != enough IMHO
[07:10] <MCR> didrocks, it works perfectly ;)
[07:10] <hyperair> didrocks: where does ezoom fall short?
[07:10] <didrocks> if we really want it to be effective, you need to be able to zoom in the UI
[07:10] <didrocks> MCR: no it doesn't
[07:10] <didrocks> you can't zoom the shell
[07:10] <MCR> ?
[07:10] <hyperair> zoom in the UI?
[07:10] <didrocks> you can't zoom the dash
[07:10] <hyperair> oh that
[07:10] <hyperair> yes
[07:10] <MCR> yes
[07:10] <didrocks> so not "well" supported
[07:11] <hyperair> come to think of it, why did unity need to be a window manager? couldn't it just have been a gnome-panel thing?
[07:11] <hyperair> i mean a gnome-panel drop-in replacement
[07:11] <didrocks> hyperair: because you need deeper integration to control windows states
[07:11] <hyperair> didrocks: what window states does unity control?
[07:11] <didrocks> that's why GS and Unity are in the wm process
[07:12] <hyperair> yeah but what window states does unity control, exactly?
[07:12] <didrocks> hyperair: if maximized or not, where the windows are, which workspace, how many of them
[07:12] <hyperair> most of that is outside of the unity plugin
[07:12] <didrocks> hyperair: no, it's not, look at the unity code
[07:12] <didrocks> because unity needs to know about it
[07:12] <hyperair> compiz already had logic for which workspace a window is in
[07:12] <hyperair> oh
[07:12] <hyperair> so it's more of querying
[07:13] <hyperair> rather than controlling?
[07:13] <didrocks> right
[07:13] <didrocks> with some control to
[07:13] <didrocks> "move to ws X"
[07:13] <didrocks> or move this windows from ws X to Y
[07:13] <hyperair> wasn't there some nice compiz dbus api?
[07:13] <MCR> didrocks: well, Compiz needed until 2013 to learn how to unsnap a horizontally maximized window - in fact Compiz in Raring still doesn't know about it...
[07:13] <didrocks> hyperair: "nice" isn't the definitive word
[07:13] <didrocks> hyperair: the API is never stable
[07:13] <hyperair> didrocks: heh well, it could have been improved?
[07:14] <didrocks> hyperair: and always poking dbus is not an option :)
[07:14] <hyperair> and stabilized?
[07:14] <hyperair> ah yes, true.
[07:14] <didrocks> hyperair: people tried, in metacity, mutter, compiz
[07:14] <MCR> Try this: right click on maximize button -> now drag the titlebar
[07:14] <didrocks> hyperair: everybody failed
[07:14] <didrocks> there is maybe a reason :)
[07:14] <hyperair> hmm
[07:14] <hyperair> wmctrl?
[07:14] <hyperair> maybe dbus is just slow.
[07:14] <didrocks> MCR: I'm not interested in knowing where compiz fails, I know there is a lot of cases ;)
[07:15] <hyperair> but for all the caching of pixbufs and what other fancy stuff unity does that causes its memory to swell like that...
[07:15] <hyperair> i'm not seeing the speed improvements that should have come with it
[07:15] <hyperair> gnome shells
[07:15] <hyperair> GS's "dash" is much faster than unity's
[07:15] <didrocks> hyperair: it does a lot less
[07:15] <didrocks> like not showing as many icons, no previews…
[07:15] <didrocks> you can't really compare the dash :)
[07:15] <hyperair> there's this very annoying bug where i key in stuff, it types out my query *slowly*, and then it spins for a while, and stops spinning without refreshing.
[07:16] <hyperair> then i have to press another key, wait for the spinner, press another key, and then it'll work.
[07:16] <didrocks> hyperair: did you report a bug about it?
[07:16] <hyperair> didrocks: yes, well, super+a should be as fast as GS.
[07:16] <hyperair> didrocks: hmm, i don't recall
[07:16] <hyperair> maybe i didn't.
[07:16] <smspillaz> hyperair: RGBA GLX is slow
[07:16] <smspillaz> that's why it had to be a shell plugin
[07:16] <hyperair> smspillaz: GS also uses RGBA, does it not?
[07:17] <MCR> smspillaz, hi.
[07:17] <smspillaz> hyperair: the shell runs in process
[07:17] <hyperair> smspillaz: yes?
[07:17] <MCR> smspillaz - great you have set up a 0.9.10 PPA - but it is empty :(
[07:17] <hyperair> smspillaz: as does unity.
[07:17] <hyperair> smspillaz: so why is the dash so goddamned slow?
[07:17] <hyperair> i type super+a and it takes forever to search for whatever i type in
[07:17] <MCR> hyperair, it is already fast here
[07:18] <hyperair> MCR: you running on an SSD?
[07:18] <MCR> yep
[07:18] <hyperair> see, therein lies the problem.
[07:18] <MCR> but it got faster and faster each version
[07:18] <smspillaz> hyperair: dash blurs probably
[07:18] <hyperair> everyone uses a damn SSD and says "oh my god, it's so blazing fast"
[07:18] <hyperair> smspillaz: disabled.
[07:18] <MCR> the blur is heavy on the hardware
[07:18] <didrocks> hyperair: you are talking about the dash search
[07:18] <didrocks> not the UI
[07:18] <hyperair> didrocks: yes.
[07:18] <didrocks> and this is not in the process
[07:18] <didrocks> and goes through dbus btw :p
[07:18] <hyperair> didrocks: the blurs exacerbated the issue by having a horribly slow UI response
[07:19] <didrocks> so what you are asking, putting the shell not in the wm is something totally separate
[07:19] <smspillaz> hyperair: *shrug* Trevhino and I were looking into something the other day as to why the dash was slowing down. We think its a set of draw calls somewhere that's quite heavy, but its going to require a bit more time to consider
[07:19] <smspillaz> hyperair: we've figured out that the slow dash isn't usually CPU bound
[07:19] <hyperair> smspillaz: oh yay, finally.
[07:19] <hyperair> like how MCR and the rest of the SSD users are seeing blazing fast dash searches
[07:21] <MCR> smspillaz, I fixed all issues in my MPs btw (except screenshot) and am waiting for approvals...
[07:21] <MCR> smspillaz, also I would like to apply as Compiz maintainer...
[07:21] <smspillaz> MCR: I think we can arrange that
[07:22] <MCR> great, number 1 + 2 ? ;)
[07:22] <smspillaz> MCR: yeah
[07:22] <smspillaz> I'll get on to both ASAP, pretty busy this weekend
[07:22] <MCR> Cool, thx
[07:23] <smspillaz> hyperair: if you know of any good OpenGL profiling tools let me know. I haven't reallly been able to find any other than gDEbugger and its a pain to get that to work
[07:23] <hyperair> smspillaz: i think there was a mention of something in phoronix that valve used..
[07:23] <smspillaz> hyperair: it has a high price tag
[07:24] <smspillaz> hyperair: if you go to their website it says "contact us about pricing details"
[07:24] <smspillaz> that's code for "this is several thousand per seat and we only negotiate enterprise contracts"
[07:24] <MCR> smspillaz, do you have an ETA for the new PPA ? - I am eager to test it (altough most of 0.9.10 runs here already, ofc)
[07:25] <smspillaz> MCR: PPA of what ?
[07:25] <smspillaz> compiz trunk?
[07:25] <MCR> https://launchpad.net/~smspillaz/+archive/compiz-dev yes
[07:25] <smspillaz> 5 minutes
[07:25] <smspillaz> https://code.launchpad.net/~smspillaz/+recipe/compiz-development-head
[07:25] <hyperair> smspillaz: oh dear, that sucks.
[07:28] <hyperair> smspillaz: i suppose you've looked through all of these: https://www.opengl.org/wiki/Debugging_Tools ?
[07:29] <smspillaz> I don't recall coming across that
[07:29] <MCR> smspillaz - great, the availability of this PPA should be announced also to get more testers, but I am sure you've planned that already ;)
[07:29] <smspillaz> dunno the best place to announce it really
[07:30] <MCR> Planet Compiz ?
[07:33] <hyperair> the ayatana mailing list?
[07:33] <hyperair> unity-design now, iirc
[07:33] <MCR> It could also be added to all the bugs that are fixed in 0.9.10, so people could immediately test those and report any issues
[07:34] <MCR> I could do that
[07:54] <duflu> MCR: zoom only works on things because those things are X windows that Compiz can stretch. That's not true for Unity elements :(
[07:55] <MCR> hi duflu :)
[07:55] <duflu> Hi
[07:56] <MCR> smspillaz, compiz in the PPA is still named 0.9.9 - not sure if that is correct, should be 0.9.10, no ?
[07:56] <duflu> On the other hand, you could just figure out the tranform matrix for the zoom (including translation) and pass it through to Unity/Nux. It could work
[07:56] <duflu> *transform
[07:57] <MCR> duflu, I know that this UI zoom was requested and would make much sense for visually impaired people, but it is not my main priority at the moment
[07:57] <MCR> first all window managing stuff needs to be rock solid imho
[07:57] <MCR> no more windows jumping around workspaces or maximizing on wrong workspaces for example
[08:01] <MCR> we are (finally) almost there...
[08:04] <Saviq> tsdgeos, the plot thickens
[08:04] <Saviq> tsdgeos, https://bugreports.qt-project.org/browse/QTBUG-30730
[08:05] <tsdgeos> so there's probably an internal object somewhere that is sometimes getting magically converted to a qobject and sometimes not
[08:06] <tsdgeos> it seems
[08:08] <Saviq> tsdgeos, what's more, the type of the singleton gets registered automagically, and in the global scope
[08:08] <Saviq> tsdgeos, that's why I had to rename the singleton
[08:08] <didrocks> hey sil2100! do you feel better?
[08:10] <tsdgeos> Saviq: brrr
[08:10] <tsdgeos> Saviq: i have http://paste.kde.org/~tsdgeos/728060/ working now :-)
[08:10] <Saviq> tsdgeos, yay
[08:10] <tsdgeos> just need to get it merged :D
[08:10] <tsdgeos> it's two lines of code
[08:10] <tsdgeos> but ...
[08:10] <sil2100> didrocks: hi! I overslept by accident ;p
[08:11] <didrocks> sil2100: seems you needed it then! :-)
[08:12] <seb128> sil2100, hey, happy friday ! do you feel better than the other day ?
[08:12] <sil2100> didrocks: I got an e-mail about some apparent lockscreen errors from veebers in the 100scopes branch, might be that the fix I made is not enough - will look into that now
[08:13] <dandrader> mzanetti, have you seen this before? https://jenkins.qa.ubuntu.com/job/unity-phablet-ci/637/testReport/junit/%28root%29/qmltestrunner/FilterGrids__test_clicked_signal/
[08:13] <sil2100> seb128: hi! Happy Friday indeed - I feel mostly much better now
[08:13] <didrocks> sil2100: hum, I wonder if we shouldn't finish the hud stuff first
[08:13] <didrocks> sil2100: so, what would I tell, regarding your email is to disable the failing test for armfh right now
[08:13] <sil2100> didrocks: that as well - you got me e-mail?
[08:13] <didrocks> yeah ;)
[08:13] <sil2100> Oh, ok
[08:13] <didrocks> sil2100: and powerpc is FTBFS, so maybe the same
[08:13] <didrocks> sil2100: just write it in the spreadsheet as well :)
[08:14] <didrocks> sil2100: then, I think we should try to rerun stack per stack
[08:14] <didrocks> in head
[08:14] <didrocks> and see if autopilot behaves good :)
[08:14] <mzanetti> dandrader: yes. let me check
[08:14] <didrocks> making sense?
[08:14] <sil2100> Ok, will do that - I just didn't want to disable the failing test because it was just failing because of the loading error
[08:14] <sil2100> But let's do that not to waste time
[08:15] <mzanetti> dandrader: or better: let me Deebug it :D
[08:16] <mzanetti> morning nic
[08:16] <didrocks> sil2100: yeah, we have tracks of what's wrong, let's try to get all the stacks running first :)
[08:20] <mzanetti> dandrader: really weird. can't reproduce this locally
[08:34] <Saviq> mzanetti, there's a bunch of qmluitests that failed yesterday with that for every ui test
[08:34] <Saviq> mzanetti, looks like GL accel broke on the VMs or something
[08:35] <mzanetti> Saviq: that's already fixed
[08:35] <mzanetti> Saviq: the current red ones are merge conflicts
[08:35] <Saviq> mzanetti, I meant the shader issue dandrader mentioned
[08:35] <mzanetti> Saviq: and I'm currently Deebugging the yellow ones
[08:36] <Saviq> mzanetti, great, thanks
[08:36] <Saviq> I'm not touching anything then
[08:37] <mzanetti> Saviq: I'm not really sure how my commit passed CI tho and then broke all following ci runs...
[08:38] <Saviq> mzanetti, I'm not entirely sure it's related
[08:38] <Saviq> mzanetti, as it's just your filtergrid that fails
[08:38] <Saviq> mzanetti, but the rest report the shader errors just as well
[08:38] <dandrader> mzanetti, but what about the missing Dee module and "tst_FilterGrids.qml:91: TypeError: Cannot set property 'model' of null"
[08:38] <mzanetti> dandrader: I hope it'll be fixed by this https://code.launchpad.net/~mzanetti/unity/phablet-deebug/+merge/159773
[08:38] <tsdgeos> Saviq: https://codereview.qt-project.org/#change,54244
[08:38] <mzanetti> Saviq: but that filtergrids test must have been passing at some point
[08:39] <tsdgeos> Saviq: meanwhile yesterday i also fixed a bug dpm reported to me (no clue why) that is stalled because i haven't fixed it for windows and mac :-/ https://codereview.qt-project.org/#change,54214
[08:40] <mzanetti> tsdgeos: I think for QtQuick its RGBA, not ARGB
[08:40] <Saviq> tsdgeos, nice one, thanks
[08:40] <Saviq> mzanetti, it's ARGB
[08:41] <sil2100> didrocks: https://code.launchpad.net/~sil2100/hud/disable_source_test_and_tweak_timeouts/+merge/159776
[08:41] <tsdgeos> mzanetti: nope, it's not
[08:41] <mzanetti> ok
[08:41] <dandrader> Saviq, I didn't get the InputFilterArea issue. So the removal of the fakes from the shell code made that thing stop working (when dealing with real apps)?
[08:41] <didrocks> sil2100: waiting for the diff :)
[08:42] <tsdgeos> mzanetti: http://paste.kde.org/~tsdgeos/728096/ that's the code they use
[08:42] <didrocks> sil2100: what about powerpc FTBFS?
[08:42] <Saviq> dandrader, yes, because it relied on the "can I import Ubuntu.Application" bool
[08:42] <mzanetti> tsdgeos: its Qt.rgba()... thats why I thought so
[08:42] <didrocks> sil2100: it's the timeout being bigger?
[08:42] <Saviq> dandrader, which you removed (and rightfully so, we just need to get rid of that wrapper)
[08:42] <tsdgeos> mzanetti: yep
[08:42] <sil2100> didrocks: it was a ekhm, timing issue... there's that one problem we have when tearing down the HUD connection
[08:42] <didrocks> ok
[08:42] <dandrader> Saviq, ah, got it
[08:43] <Saviq> dandrader, and implement a noop filter in the fake plugin
[08:43] <Saviq> dandrader, and again, DON'T YOU SLEEP!?
[08:43] <dandrader> Saviq, yes
[08:43] <sil2100> It's really irritating, since there's not much we can do than wait, we might want to redesign somehow in the future maybe...
[08:43] <dandrader> Saviq, climbing this aftenoon :)
[08:44] <didrocks> sil2100: hum, is hudtest(test-source test-source.c test-source.xml) only with platform api?
[08:44] <dandrader> Saviq, I would rather say the opposite. If I log on at 5am. you're online. At 5pm, you're online as well ;)
[08:44] <Saviq> dandrader, details
[08:46] <didrocks> sil2100: commented
[08:49] <sil2100> didrocks: good catch, no need to disable it on non-platform-api systems
[08:49] <didrocks> sil2100: ping me back :)
[08:52] <sil2100> didrocks: pushed and build-tested... but the first push went to some different branch, grrr
[08:53]  * sil2100 hates when the default push branch is some old branch
[08:53] <Saviq> tsdgeos, and you guys complain about whitespace checks, "possible spelling error"? lol!
[08:53] <tsdgeos> yeah
[08:54] <didrocks> sil2100: approved :)
[08:54] <didrocks> sil2100: ok, so now some stacks in head are running
[08:55] <didrocks> sil2100: so, if you look, some have issues to fix, even before autopilot
[08:55] <didrocks> sil2100: see he yellow indicator stack? it seems something is out of sync
[08:56] <didrocks> sil2100: there is also qtvideo-node in the head/media stack which needs fixing
[08:56] <didrocks> (don't look at the mediaplayer-app, I fixed it)
[08:56] <sil2100> Looking looking
[08:56] <didrocks> sil2100: phone and apps stacks are running autopilot, we'll see the result soon :)
[08:57] <sil2100> Oh, since I didn't see those blinking, so thought it's over already ;p But I'll check the indicator stack
[08:57] <Saviq> is anyone else's PA hogging the CPU constantly since yesterday?
[08:57] <didrocks> sil2100: yeah, it's a "view", not a realtime status
[08:57] <didrocks> sil2100: it's showing "latest finished state" :/
[08:57] <dandrader> the worst thing about javascript is that it fails silently
[08:58] <Saviq> dandrader, yeah, undefined == false is the worst
[08:59] <Saviq> mzanetti, http://s-jenkins:8080/job/unity-phablet-qmluitests/448/console seems to hang
[08:59] <tsdgeos> Saviq: at least that spelling stuff is immediate, doesn't take 30 min like our whitespace check
[08:59] <Saviq> tsdgeos, if you had tested locally ;)
[08:59] <tsdgeos> yes, yes, i know, execute them locally :D
[09:00] <mzanetti> Saviq: *grrr*
[09:00] <tsdgeos> Saviq: well, i saw your whitespace error too ;-)
[09:00] <mzanetti> Saviq: I just requested 2 additional VM's
[09:00] <Saviq> tsdgeos, indeed
[09:00] <mzanetti> Saviq: before they go online I'll use one of them to debug this more
[09:00] <Saviq> tsdgeos, but I'm not complaining, am I :P
[09:00] <Saviq> mzanetti, k
[09:06] <tsdgeos> Saviq: not only that, now i have to wrap the commit message at 72 cols
[09:06] <tsdgeos> ...
[09:06] <didrocks> sil2100: ok, it's merged, I'm relaunching the hud stack with only rebuilding hud FYI
[09:07] <Saviq> haha
[09:07] <tsdgeos> let's pretend we live in 1975
[09:08] <tsdgeos> Saviq: and they're not going to accept it for 5.1 so that sucks
[09:09] <sil2100> didrocks: ok
[09:09] <Saviq> tsdgeos, I gathered as much
[09:09] <Saviq> tsdgeos, but it's fine, we have good processes for distropatching, I think
[09:10] <tsdgeos> oka
[09:10] <sil2100> didrocks: btw. the indicator stack... it seems all the jenkins stuff is month-old
[09:11] <Saviq> tsdgeos, hmm, shouldn't we also support #ARGB?
[09:11] <didrocks> sil2100: did you look at the branches in the config?
[09:11] <didrocks> sil2100: and did we got new commits?
[09:11] <tsdgeos> Saviq: don't see the need to be honest
[09:11] <tsdgeos> does anyone ever use that format?
[09:12] <Saviq> tsdgeos, #RGB is supported, so
[09:12] <tsdgeos> i know
[09:12]  * sil2100 is still noobish here
[09:12] <tsdgeos> my guess is that this is just because they need to support xpm
[09:12] <sil2100> didrocks: yes, I checked and there were commits to the indicator.cfg
[09:12] <sil2100> didrocks: but the last run of for instance cu2d-indicators-head-1.1prepare-indicator-datetime is 22 days old
[09:12] <Saviq> tsdgeos, anyway, QML doesn't support #ARGB
[09:13] <Saviq> tsdgeos, so that's that
[09:13] <tsdgeos> exactly
[09:13] <sil2100> didrocks: and that's why indicators is yellow, since it was executed when indicator-datetime was still using the raring 13.04 branch
[09:14] <didrocks> sil2100: indeed, there is no time assigned
[09:14] <didrocks> sil2100: I think nobody redeployed the stack
[09:14] <didrocks> cyphermox: seems that you never redeployed the head/indicators.cfg stack. Doing it now ^
[09:14] <sil2100> \o/
[09:15]  * sil2100 wanted to use the 'redeploy' word but wasn't sure if it's the right one
[09:15] <didrocks> nice catch sil2100 ;)
[09:15] <didrocks> heh :)
[09:15] <didrocks> sil2100: basically I looked at the head configuration
[09:15] <didrocks> sil2100: and didn't see the timer
[09:16] <Saviq> tsdgeos, typo
[09:16] <Saviq> tsdgeos, not ARBG but ARGB
[09:16] <sil2100> I think it should indeed show the 'last run' timer in the main 'Head' view
[09:16] <tsdgeos> Saviq: where?
[09:16] <Saviq> tsdgeos, commented inline, qcolor.cpp
[09:16] <Saviq> _p
[09:16] <didrocks> sil2100: yeah, that's the issue to play with jenkins to control the whole chain…
[09:17] <tsdgeos> ok
[09:17] <Saviq> actually no, qcolor.cpp
[09:17] <tsdgeos> dang
[09:17] <tsdgeos> tx
[09:19] <sil2100> didrocks: you fixed up the media stack problems already, yes?
[09:21] <didrocks> sil2100: not the qtvideo-node, as said
[09:21] <sil2100> What also confuses me in jenkins is that there is a Last Success column and Last Failure column, but sometimes I would simply need a 'Last Run' one - here I have to check both columns to get the definite answer on when the build was executed
[09:21] <didrocks> sil2100: mind looking at it?
[09:21] <sil2100> didrocks: aye!
[09:21] <didrocks> sil2100: agreed it's confusing
[09:35] <Saviq> mzanetti, did you see the jobs seem not published anymore? following the links in jenkins messages gives out 404
[09:36] <mzanetti> Saviq: no... didn't see that yet... still trying to fix the broken test
[09:36] <Saviq> mzanetti, k
[09:36] <Saviq> mzanetti, do you know who do I ping in absence of mmrazik about that?
[09:36] <mzanetti> Saviq: I guess me
[09:36] <Saviq> lol
[09:37] <mzanetti> Saviq: in the afternoon fginther or sergiusens too
[09:37] <Saviq> mzanetti, k
[09:37] <mzanetti> Saviq: I'll check it out as soon as the test is fixed
[09:37] <Saviq> mzanetti, thanks
[09:42] <Cimi> launchpad is super slow here, only to me?
[09:43] <mzanetti> Cimi: works fine here
[09:43] <Cimi> strange
[09:44] <Cimi> btw
[09:44] <mzanetti> Cimi: maybe you're super fast today :)
[09:44] <Cimi> oh definitely not :)
[09:44] <Cimi> I mean via browser, pages take a minute
[09:44] <Cimi> I'm in Italy btw for the weekend, arrived here late night
[09:45] <Cimi> maybe we don't like launchpad xD
[09:45] <Cimi> dednick, do you have any update on the categories branch you didn't push?
[09:46] <dednick> Cimi: nearly there
[09:46] <mzanetti> Cimi: for me internet is in general very slow in italy... Might be related to the mountain area I come from
[09:46] <Cimi> mzanetti, all the rest of internet is fine
[09:46] <Saviq> yeah, internets don't deal with mountain well ;)
[09:46] <Cimi> just launchpad got slo
[09:47] <Saviq> they get tired
[09:48] <dandrader> Saviq, have you mentioned pulseaudio eating CPU all the time?
[09:48] <Saviq> dandrader, yes
[09:48] <dandrader> I'm getting the same now
[09:48] <seb128> dandrader, Saviq: what version of the package do you have?
[09:48] <Cimi> ok chrome is slow, safari is fast
[09:49] <seb128> dandrader, Saviq: https://launchpad.net/ubuntu/+source/pulseaudio/1:3.0-0ubuntu6 is supposed to fix it
[09:49] <sil2100> hmmm
[09:49] <Saviq> seb128, 1:3.0-0ubuntu5
[09:49] <Cimi> DNS prefetch?
[09:49] <seb128> Saviq, upgrade
[09:49] <Saviq> seb128, trying
[09:49] <dandrader> seb128, 1:3.0-0ubuntu
[09:49] <dandrader> 1:3.0-0ubuntu5
[09:49] <seb128> dandrader, same, upgrade
[09:49] <Cimi> maybe I'm running uk dns
[09:50] <sil2100> didrocks: the problem with qtvideo-node is that the source package name is different from the branch name...
[09:50] <sil2100> didrocks: since qtvideonode-plugin is the src package, while the branch is lp:qtvideo-node
[09:51] <sil2100> At least hm
[09:51] <Saviq> seb128, hmm no upgrade available yet
[09:51] <dandrader> Saviq, https://code.launchpad.net/~dandrader/unity/phablet_remove_fakes_from_qml/+merge/158370 should be good to go know, although jenkins is having some difficulties
[09:51] <dandrader> s/know/now
[09:51] <Saviq> dandrader, yeah, mzanetti is on it
[09:51] <seb128> Saviq, change mirror?
[09:51] <seb128> Saviq, or use directly archive.ubuntu.com
[09:51] <Saviq> seb128, archive.ubuntu.com
[09:52] <Saviq> seb128, yeah, I'm using archive directly
[09:52] <sil2100> didrocks: maybe we should change lp:qtvideo-node to lp:qtvideonode-plugin ?
[09:52] <seb128> Saviq, hum, 0ubuntu6 was uploaded yesterday afternoon, it should be available
[09:53] <seb128> Saviq, sudo apt-get update?
[09:53] <dandrader> Saviq, odd I got the pulseaudio upgrade
[09:53]  * Saviq disables apt-cacher
[09:53] <didrocks> sil2100: what's the project name?
[09:54]  * dandrader reboots to try it out the new stuff (including new kernel)
[09:54] <Saviq> better
[09:54] <sil2100> https://launchpad.net/qtvideo-node <- on LP that's like this
[09:54] <didrocks> sil2100: I would rather go the other around, change the source package name to map to the project name
[09:54] <didrocks> sil2100: as it's what was decided for opening the project
[09:54] <didrocks> sil2100: also, can you please add some bootstrap commit message?
[09:56] <dandrader> well, so far so good. seb128 thanks for the tip!
[09:56] <seb128> dandrader, great, thanks for confirming the fix ;-)
[10:01] <Saviq> seb128, yup, helped, thanks!
[10:01] <seb128> Saviq, yw!
[10:01]  * Saviq wonders why apt-cacher-ng broke
[10:02] <sil2100> didrocks: in case of changing the source package name... should I change all previous changelog entries, or just the most recent? ;)
[10:02] <sil2100> Will do!
[10:02] <didrocks> sil2100: most recent is fine
[10:10] <mzanetti> Saviq: so, what exactly is not published?
[10:11] <Saviq> mzanetti, actually, it seems to have just taken time
[10:11] <Saviq> mzanetti, yeah, it's fine
[10:19] <smspillaz> MCR: which ones needed review ?
[10:19] <smspillaz> MCR: I don't see anything that's not marked resubmit, and the only other one has comments by me but no follow up
[10:20] <MCR> smspillaz, https://code.launchpad.net/~compiz-team/compiz/0.9.10/+activereviews
[10:21] <MCR> Sam, all that have been resubmitted (Resubmit: 1)
[10:22] <smspillaz> MCR: hmm, I thought when you marked something "resubmit" it meant you were going to resubmit it
[10:22] <smspillaz> in any case I can have another look
[10:22] <MCR> and if you have a solution to fix the screenshot thingy with fbos, you could take over the screenshot branch
[10:22] <smspillaz> MCR: we'll do it separately
[10:22] <MCR> ok
[10:23] <MCR> I have set the screenshot MP to WIP
[10:24] <smspillaz> MCR: hm? I meant we'll do the fbo thing in a separate mp
[10:24] <MCR> yeah, I understood
[10:24] <MCR> but I have not yet applied your suggestions
[10:24] <smspillaz> ok
[10:25] <MCR> in my MP implementing the overlay color selector for screenshot
[10:25] <smspillaz> MCR: oh, actually quesiton about the cube gears proposal
[10:25] <MCR> sure - go ahead
[10:25] <smspillaz> do we call glDepthMask (GL_FALSE); anywhere ?
[10:25] <smspillaz> (can't see it from the diff
[10:26] <MCR> I do not think so
[10:26] <smspillaz> MCR: oh, actually
[10:26] <smspillaz> MCR: never mind
[10:26] <smspillaz> MCR: I meant to ask - we're calling glDisable (GL_DEPTH_TEST);
[10:26] <smspillaz> aren't we?
[10:27] <Saviq> dednick, can you take a look at https://bugs.launchpad.net/touch-preview-images/+bug/1170465 please
[10:28] <Saviq> dednick, it's gonna be in indicators-client network plugin, I expect
[10:28] <dednick> Saviq: sure
[10:29] <smspillaz> MCR: BTW, removing the <precision> tags in https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1167933.2-KEY_MOVE_INC-is-hardcoded/+merge/158767 was largely unrelated to the point of the original proposal
[10:29] <smspillaz> try to avoid doing stuff like that, its confusing :)
[10:29] <MCR> sorry
[10:29] <smspillaz> its fine, just that it didn't belong there
[10:29] <MCR> I did find out it does not work for ints, just floats
[10:29] <MCR> so I removed it
[10:29] <MCR> but you are right
[10:29] <smspillaz> MCR: that's fine, just do it separtely
[10:29] <smspillaz> (in future)
[10:30] <MCR> should have been separated - yes
[10:30] <MCR> my main problem ;)
[10:32] <MCR> smspillaz - yes I did disable  GL_DEPTH_TEST in gears
[10:32] <MCR> line 285
[10:32] <MCR> sry - it was already there
[10:32] <Saviq> tsdgeos, can you comment on https://bugs.launchpad.net/touch-preview-images/+bug/1170550 please
[10:33] <tsdgeos> sure
[10:33] <smspillaz> MCR: I've commented on the three marked resubmit
[10:33] <smspillaz> acked two
[10:33] <MCR> thx
[10:34] <didrocks> sil2100: any issue? That should have taken 5 minutes at max. I can do it otherwise ;)
[10:34] <Saviq> tsdgeos, actually I can't seem to crash it here on manta
[10:34] <MCR> smspillaz, I see 4 acked ?
[10:34] <tsdgeos> well, it's all a matter of luck
[10:34] <tsdgeos> it's about the order stuff gets constructed/destroyed
[10:35] <tsdgeos> that may leave some things dangling
[10:35] <smspillaz> MCR: ah, sorry about that. my brain is not working today
[10:35] <smspillaz> I reviewed *five* and acked *four*
[10:35] <MCR> smspillaz, anyway thanks - no problem ;)
[10:36] <Saviq> dandrader, could you tackle https://bugs.launchpad.net/touch-preview-images/+bug/1170495
[10:37] <Saviq> dandrader, my plan would be: create a mockapp.lens in demo-assets
[10:37] <Saviq> dandrader, and use the same approach we have in DashHome to assign the relevant category results
[10:38] <Saviq> dandrader, the mockapp lens would have to be invisible, though
[10:38] <tsdgeos> Saviq: commented in https://code.launchpad.net/~saviq/unity/phablet.unity-test-module/+merge/159410
[10:39] <Saviq> dandrader, so frequent and available apps would come from the mock lens, and installed ones from the real lens
[10:39] <sil2100> didrocks: uuh, sorry, pushed it and didn't request a merge ;p Damn
[10:39] <didrocks> sil2100: ah, so I guess you are looking at the autopilot results now? :)
[10:39] <sil2100> https://code.launchpad.net/~sil2100/qtvideo-node/rename_src_package_and_bootstrap/+merge/159788
[10:40] <dandrader> Saviq, after I'm done with this Jenkins autopilot error about missing InputfilterArea
[10:41] <mzanetti> dandrader: https://code.launchpad.net/~mzanetti/unity/phablet-deebug/+merge/159773
[10:42] <mzanetti> dandrader: this should fix the problem you're having
[10:42] <tsdgeos> Saviq: adding the comment on https://bugs.launchpad.net/touch-preview-images/+bug/1170550 too
[10:42] <Saviq> dandrader, k
[10:42] <MCR> smspillaz, needs information, please: https://code.launchpad.net/~mc-return/compiz/compiz.merge-composite-cleanup/+merge/158757
[10:43] <MCR> smspillaz, foreach is now in brackets, just if is not...
[10:43] <sil2100> didrocks: there seemed to be an ssh connection refused for nvidia during the autopilot job, did utah fail or something?
[10:43] <sil2100> During the apps AP
[10:44] <mhr3> sil2100, is it possible that your disable-lock-screen fix doesn't work 100%?
[10:44] <dandrader> mzanetti, that's one problem. but there's also this https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner/1168/testReport/junit/qml_phone_shell.tests.testconfigurations/TestNexus10/test_hide_hud_dragging/
[10:44] <sil2100> mhr3: there is a possibility, yes - Chris saw some issues yesterday
[10:45] <mhr3> sil2100, cause we merged trunk into the 100scopes branch and yesterday the ap tests run and half of them failed cause the screen is locked
[10:45] <sil2100> It might be re-enabled too early
[10:45] <sil2100> I will be looking into that later today
[10:45] <mhr3> sil2100, thx
[10:45] <tsdgeos> Saviq: shall we do a new release? last one is from a week ago
[10:45] <mzanetti> dandrader: but this seems to be caused by your branch, no?
[10:46] <Saviq> tsdgeos, yeah we will, soon
[10:46] <tsdgeos> oki
[10:46] <Saviq> tsdgeos, we might want to wait for the fixes to the bugs from http://iso.qa.ubuntu.com/qatracker/milestones/268/builds
[10:46] <dandrader> mzanetti, yes. that's what I'm working on
[10:47] <didrocks> sil2100: not sure, did you ask on #qa?
[10:48] <didrocks> mhr3: the screen locker is a side effect anyway
[10:48] <tsdgeos> Saviq: ok, if we have them in the pipeline sure :-)
[10:48] <didrocks> mhr3: it's because some tests stuck, and nothing happened for 10 minutes
[10:48] <mzanetti> dandrader: you need help on that?
[10:48] <didrocks> mhr3: you do have sil2100's fix for the HUD tests, right?
[10:48] <sil2100> Ah
[10:48] <dandrader> mzanetti, I think I got it. seems like a missing install(...) entry in CMakeLists.txt. but thanls
[10:48] <sil2100> Right, I think we'll need to port that to 100scopes
[10:50] <mzanetti> Saviq: should I then try to fix one of those bugs?
[10:50] <Saviq> mzanetti, look at https://bugs.launchpad.net/touch-preview-images/+bug/1157508
[10:50] <mzanetti> Saviq: ack
[10:50] <Saviq> mzanetti, you have manta, right?
[10:51] <mzanetti> N10, yes
[10:51] <Saviq> yup
[10:53] <mzanetti> dandrader: that branch passes in jenkins now. it just posted a needs fixing because the job hung. I retriggered it manually and it works now. so once you approve qmluitests should strat working again
[10:53] <tsdgeos> dednick: what's test_unity_object for in https://code.launchpad.net/~unity-team/unity/phablet.fake-unity-plugin/+merge/158865 ?
[10:54] <dednick> tsdgeos: eh. it was just a test object when i first created the plugin
[10:54] <dednick> tsdgeos: i'll remove
[10:54] <tsdgeos> oka
[10:54] <dandrader> mzanetti, once I approve what?
[10:54] <mzanetti> dandrader: https://code.launchpad.net/~mzanetti/unity/phablet-deebug/+merge/159773
[10:56] <sil2100> mhr3, didrocks: actually, my HUD fix won't help here, since as Chris mentioned a different test is breaking everything - it seems Dash crashed really strangely in unity.tests.test_shopping_lens.ShoppingScopeTests.test_preview_works_with_shopping_scope
[10:56] <didrocks> ah, interesting…
[10:57] <dandrader> mzanetti, why tests/qmltests/plugins/Dee/CMakeLists.txt isn't needed anymore?
[10:57] <sil2100> And some *strange* introspection errors for intel as well, huh?
[10:58] <dandrader> mzanetti, because Dash test now points directly to  ${CMAKE_CURRENT_SOURCE_DIR}/plugins ?
[10:58] <mzanetti> dandrader: yes
[10:59] <dandrader> mzanetti, and tests do not get installed anyway, right?
[10:59] <mzanetti> dandrader: exactly
[10:59] <tsdgeos> dednick: i'm also a bit uneasy that the Fake Lens api is a bit different from the Real Lens api
[10:59] <tsdgeos> how does that work?
[11:00] <dandrader> mzanetti, now we only need jenkins to agree with my verdict
[11:00] <dednick> tsdgeos: only implements the API it's needs for the tests that are written.
[11:01] <mzanetti> dandrader: yeah... I'll keep an eye on it. and as soon we get the new VM's I'll use one to debug the hanging qmluitests further
[11:01] <mzanetti> thanks
[11:01] <tsdgeos> dednick: sure, i'd undersrand it being a subset, but it has new api too
[11:01] <tsdgeos> i.e
[11:01] <tsdgeos> Q_PROPERTY(QString name READ name WRITE setName NOTIFY nameChanged)
[11:01] <tsdgeos> is in the fake one
[11:01] <tsdgeos> but not in the real one
[11:02] <tsdgeos> ah wait
[11:02] <dednick> tsdgeos: yes it is.
[11:02] <dednick> although no write
[11:02] <tsdgeos> it is there
[11:02] <tsdgeos> right
[11:02] <tsdgeos> search fail :D
[11:03] <mhr3> didrocks, sil2100, but yes we have all sil2100's fixes
[11:03] <tsdgeos> so there's a bit of new api to inject the fake stuff
[11:03] <tsdgeos> that's fine
[11:03] <mhr3> the only thing we're missing from trunk is manuel's fix and changelog bumps
[11:03] <tsdgeos> dednick: ok, works for me too once you remove that fake object
[11:04] <MCR> smspillaz, done ;)
[11:05] <dednick> tsdgeos: done
[11:14] <Saviq> tsdgeos, I'll assign you to the dash crash bug
[11:15] <tsdgeos> ok
[11:21] <sil2100> mhr3, didrocks: so, from what I preliminarily see in the failing tests - my screen-lock disable fix is working to some extent, but still there's a gap that casues the screen lock to happen
[11:21] <didrocks> sil2100: I think the interesting part is rather: what tests was stuck for 10 minutes to have the screen lock enabled?
[11:23] <sil2100> Since for as long as a test is going, the screen lock is not able to appear - one of the broken tests was hanged for 12 minutes and the screen lock did not happen, but what is interesting what happened then - then the test started to do it's clean up, it cleaned up all the environment preparing to finish (also, re-enabled the screen lock again) and AGAIN hanged up afterwards for another 12 minutes!
[11:24] <didrocks> sil2100: interesting, do you have any idea if it's always the same tests, or why autopilot is doing that hangup?
[11:24] <sil2100> didrocks: yes, I'm trying to figure that out as well, since it looked like Unity started breaking down, the dash being unresponsive and glitchy
[11:25] <sil2100> There were some graphical glitches seen on the movie as well - not sure now what happened exactly, I only have some traces in the logs
[11:26] <didrocks> sil2100: but you are seeing the gap on logs, I guess
[11:27] <didrocks> sil2100: yeah, it's reproducing some times, I don't know at all how we can get the needed infos
[11:28] <sil2100> didrocks: still looking for the cause - me and Chris noticed that there's a query error appearing every 30 seconds during the first 12 minute hang up
[11:28] <sil2100> Another strange thing is that this is the nvidia failure - intel fails differently
[11:28]  * sil2100 is confused, needs coffee
[11:29] <didrocks> oh interesting
[11:30] <nic-doffay> Saviq, mzanetti more QML q's if you have the time.
[11:30] <Saviq> nic-doffay, hit me
[11:30] <nic-doffay> I'd like to do a Sequential animation with a state.
[11:30] <nic-doffay> Saviq, ^
[11:31] <Saviq> nic-doffay, you mean when changing between states, you want a SequentialAnimation in a transition
[11:31] <Saviq> ?
[11:33] <Saviq> nic-doffay, something like http://pastebin.ubuntu.com/5721295/ ?
[11:37] <nic-doffay> Saviq, yeah that looks spot on, thanks. I basically need to perform a transition between states and a transformation at the same time.
[11:49] <nic-doffay> Saviq, what's the best method to store a state in a variable to access at a later stage?
[11:51] <Saviq> nic-doffay, usually a property somewhere
[11:51] <Saviq> nic-doffay, depends on the use caes
[11:51] <Saviq> case
[11:51] <mzanetti> Saviq: there was a second bug regarding the password field misaligned, right?
[11:51] <Saviq> mzanetti, yes
[11:51] <nic-doffay> Saviq, just store it as a string?
[11:51] <Saviq> nic-doffay, what's the use case?
[11:52] <Saviq> mzanetti, launchpad.net/bugs/1170465
[11:52] <mzanetti> Saviq: ack. thats related... my MP will fix that too
[11:52] <Saviq> dednick, ^
[11:53] <Saviq> mzanetti, when I didn't get OSK on password entry, it wouldn't come up anywhere for the shell, is that what you're experiencing?
[11:54] <mzanetti> Saviq: no... its because the layout is messed up, so tapping the textfield focuses also something else which prevents the osk from popping up
[11:54] <Saviq> mzanetti, so there's two issues I'd say
[11:54] <Saviq> mzanetti, make sure you get OSK in the messaging menu and on search, for example
[11:54] <nic-doffay> Saviq, every dot has an initial variable state it needs to transition back to after the first transition. This state is set externally by the data which will be received from the backend.
[11:54] <mzanetti> Saviq: ok
[11:55] <mzanetti> Saviq: works fine for me
[11:55] <Saviq> mzanetti, it's not 100% reproducible
[11:55] <Saviq> mzanetti, try after first flash, for example
[11:56] <Saviq> mzanetti, or after rebooting
[11:56] <mzanetti> Saviq: the one on the network password was 100% reproduceable
[11:56] <mzanetti> Saviq: and right now I freshly booted and its fine...
[11:56] <Saviq> mzanetti, ok, let's see your fix, we'll try
[11:56] <Saviq> nic-doffay, then that initial state should be stored in a property on the dot
[11:56] <Saviq> nic-doffay, and the transition should happen on a different property
[11:57] <nic-doffay> Saviq, brilliant, thanks.
[11:57] <Saviq> nic-doffay, so the value stored initially is never changed, so no need to think about it
[11:58] <mzanetti> Saviq: https://code.launchpad.net/~mzanetti/indicators-client/fix-network-password-layout/+merge/159805
[12:00] <Saviq> mzanetti, why not implicitHeight?
[12:00] <mzanetti> Saviq: doesn't work
[12:00] <Saviq> mzanetti, ok, checking
[12:00] <mzanetti> Saviq: maybe something in the surrounding Menu {} element that only works with real height
[12:00] <sil2100> didrocks: argh, libappindicator failed on powerpc, making the indicator stack red on build (FTBFS because of -Werror=deprecated-declarations)
[12:00] <Saviq> mzanetti, but I do think you fixed dednick's bug and not your own ;)
[12:01] <didrocks> Saviq: not only powerpc
[12:01] <didrocks> grr
[12:01] <sil2100> didrocks: should we fix that or disable powerpc from Architecture: ?
[12:01] <didrocks> sil2100: ^
[12:01] <sil2100> Ah, not only?
[12:01] <mzanetti> Saviq: well... the keyboard pops now up all the time
[12:01] <didrocks> sil2100: IIRC? I saw a FTBFS somewhere else
[12:01] <Saviq> mzanetti, yeah, will test
[12:01] <sil2100> didrocks: right! There's one later on for amd64, looking at that one...
[12:02] <didrocks> sil2100: yep :)
[12:02] <didrocks> sil2100: better to fix the deprecation if needed
[12:02] <sil2100> Ah, the same error, ok, so let's fix that ;p
[12:02] <didrocks> yep ;)
[12:02] <didrocks> needs a hand?
[12:03] <sil2100> For now I'm branching the branch, will try doing it now
[12:03] <didrocks> ok ;)
[12:05]  * mzanetti -> food
[12:05] <sil2100> Test building
[12:10] <Saviq> mzanetti, if you freshly flash your N10, can you type the password in straight after the first boot?
[12:11] <mzanetti> Saviq: let me reflash
[12:14] <mzanetti> Saviq: you cant?
[12:14] <Saviq> mzanetti, nope, only after a reboot
[12:14] <Saviq> mzanetti, so very difficult to reproduce
[12:14] <mzanetti> Saviq: ok... but thats the one where the osk doesn't popup everywhere I guess
[12:14] <Saviq> mzanetti, and must really be some aace
[12:14] <Saviq> mzanetti, yeah
[12:14] <Saviq> mzanetti, race
[12:15] <Saviq> mzanetti, I imagine the shell starts before the OSK comes up
[12:15] <mzanetti> Saviq: yeah... what I fixes is really the osk on the network password input
[12:15] <Saviq> mzanetti, and it never tries to reconnect
[12:16] <mzanetti> Saviq: problem is, by the time you can log in to investigate, everything is already settled
[12:16] <Saviq> mzanetti, exactly
[12:17] <Saviq> dandrader|lunch, "install TARGETS given target "InputFilterAreaQmlFile" which is not an executable, library, or module."
[12:17] <mzanetti> hmpf... battery died during flash :/
[12:17] <Saviq> uh oh
[12:18] <Saviq> mzanetti, can you add a FIXME there that it should be implicitHeight, please
[12:18] <mzanetti> Saviq: just wondering. what would be the advantage of using implicitHeight?
[12:19] <Saviq> mzanetti, mostly style
[12:19] <Saviq> mzanetti, components should not define their own dimensions
[12:19] <Saviq> mzanetti, and implicit* are there to show the default dimensions
[12:20] <sil2100> didrocks: still didn't do the test build, because I needed to install a package but I still have dist-upgrade running - and my chroot is still installing build-deps ;p But the merge request is ready and looking sane:
[12:20] <sil2100> https://code.launchpad.net/~sil2100/libappindicator/fix_ftbfs_deprecated_func/+merge/159809
[12:23] <mzanetti> Saviq: I think I know what the issue is
[12:23] <mzanetti> Saviq: the implicitHeight is not supposed to change at runtime
[12:23] <Saviq> mzanetti, that can't be true
[12:23] <Saviq> mzanetti, Columns have implicit height
[12:23] <Saviq> mzanetti, based on their children size
[12:24] <Saviq> which obviously can change
[12:24] <mzanetti> Saviq: hmm... ok... then not...
[12:24] <didrocks> sil2100: I've updated the spreadsheet for the hud, feel free to complete
[12:26] <sil2100> didrocks: ok, thanks!
[12:31] <mzanetti> Saviq: added the FIXME
[12:31] <Saviq> thanks
[12:32] <mzanetti> Saviq: did you remove the link to the osk bug?
[12:32] <Saviq> mzanetti, yes
[12:32] <mzanetti> so the question arises, why? :D
[12:33] <mzanetti> Saviq: ^
[12:33] <mzanetti> it does fix that bug, doesn't it?
[12:33] <Saviq> mzanetti, did I remove the wrong link?
[12:34] <Saviq> mzanetti, the bug is more generic ;)
[12:34] <mzanetti> Saviq: "Keyboard not showing up for wifi password entry on Nexus 10"
[12:34] <mzanetti> not sure...
[12:34] <Saviq> mzanetti, ok, it should be
[12:35] <Saviq> mzanetti, "OSK not showing up in shell on first boot on Nexus 10"
[12:35] <mzanetti> imho a different one... but don't wanna argue about this now
[12:35] <mzanetti> as there really is a bug that prevents it in the network setup... regardless how often you boot
[12:37] <Saviq|mtg> mzanetti, I can access the pass entry just fine in pristine image
[12:37] <Saviq|mtg> mzanetti, assuming the OSK actually works
[12:37] <mzanetti> Saviq|mtg: didn't work here
[12:38] <mzanetti> Saviq|mtg: that said. because its because of the squeezed layout there might are some pixels where you can indeed trigger it
[12:38] <sil2100> didrocks: test build done
[12:40] <mzanetti> Saviq|mtg: FYI: can't reproduce the first-boot-no-osk thing
[12:40] <mzanetti> Saviq|mtg: works fine here
[12:40] <mzanetti> in people search and greeter and everywhere
[12:40] <Saviq|mtg> mzanetti, yeah, race
[12:47] <sil2100> didrocks: https://code.launchpad.net/~sil2100/libappindicator/fix_ftbfs_deprecated_func/+merge/159809 <- once you have a free moment
[12:51] <didrocks> sil2100: and approved!
[12:52] <sil2100> \o/
[12:52] <sil2100> Thanks!
[12:52] <didrocks> thanks to you :)
[12:52] <didrocks> sil2100: do you know about the ssh connection what was the issue?
[12:54] <didrocks> sil2100: btw, run 115 has some AP result
[12:54] <dandrader> it's amazing that to build hud I need dbus installed
[12:54] <dandrader> (build its package)
[12:55] <dandrader> make its tough to build its package from within a chroot
[12:58] <sil2100> didrocks: will look at that, just will have some hangouts in a moment
[13:04] <didrocks> sil2100: great!
[13:08] <tsdgeos> Saviq|mtg: can we milestone stuff like https://bugs.launchpad.net/touch-preview-images/+bug/1170550 so it shows in https://launchpad.net/~aacid/+upcomingwork ?
[13:12] <tsdgeos> mzanetti: http://10.97.2.10:8080/computer/ps-quantal-server-amd64-2/?
[13:12] <tsdgeos> DEAD!
[13:13] <Saviq|mtg> tsdgeos, we'd need a milestone for the touch images project
[13:13] <Saviq|mtg> tsdgeos, which there aren't any
[13:13] <tsdgeos> ok :/
[13:13] <tsdgeos> anyway i guess i can include that in my head in the same place as the carousel-listview work
[13:17] <dandrader> Saviq|mtg, fixed that dumb mistake. but now that I have a chroot to try out packaging such things shouldn't pass onward anymore :)
[13:17] <Saviq|mtg> dandrader, yeah, sbuild helps a lot her
[13:17] <Saviq|mtg> e
[13:30] <cyphermox> didrocks: what about head/indicators.cfg ? I deployed it when indicator-network was added
[13:32] <cyphermox> didrocks: yesterday I couldn't release bamf / libappindicator in time btw, the publish step didn't work for some reason
[13:32] <didrocks> cyphermox: did you use -U?
[13:32] <didrocks> cyphermox: it seems that it didn't run for the past 28 days
[13:32] <cyphermox> when I run cu2d-update-stack -dU always
[13:32] <didrocks> and there was no schedule in the head
[13:33] <didrocks> cyphermox: weird, I did the same and it's scheduled now
[13:33] <didrocks> anyway, no worry, on the publisher, do you have the run numbers?
[13:34] <didrocks> cyphermox: it's possible than the "manual publication forcing" has a bug
[13:34] <didrocks> cyphermox: those changes can be SRUed, isn't it?
[13:34] <cyphermox> that's how it looked, but now the results aren't even the same as they were
[13:35] <cyphermox> yeah, all can be SRUd
[13:36] <didrocks> cyphermox: let me quickly look at the code :)
[13:36] <didrocks> cyphermox: indeed
[13:37] <didrocks> cyphermox: I screwed up :p
[13:37] <didrocks> sorry about that
[13:37] <didrocks> the force doesn't override the force manual publishing
[13:38] <cyphermox> yeah that was builds 19 and 20
[13:39] <didrocks> cyphermox: fixed in rev 305
[13:39] <didrocks> and deployed
[13:46] <dandrader> Saviq, ok, jenkins approved the MP
[13:46] <dandrader> Saviq, it's no you now
[13:46] <dandrader> s/no/on
[13:48] <Saviq> dandrader, yup, already on it
[13:50] <Saviq> mzanetti, if you want to take the apps lens search bug from dandrader, that would probably work, too - and you have some more experience with the demo-assets package and stuff
[13:51] <Saviq> dednick, are you going to investigate the implicitHeight issue then, or are we just going to go with mzanetti's fix then?
[13:51] <dandrader> mzanetti, Saviq fine by me. I was just starting on it
[13:52] <mzanetti> Saviq: do you know in which repo I can find the tablet-services file?
[13:52] <mzanetti> to at least hot-fix it a little
[13:52] <Saviq> mzanetti, lp:ubuntu-session
[13:52] <Saviq> wrong
[13:53] <Saviq> lp:session-manager?
[13:53]  * mzanetti tries
[13:53] <Saviq> mzanetti, yeah
[13:53] <Saviq> http://bazaar.launchpad.net/~phablet-team/session-manager/trunk/view/head:/tablet-services
[13:54] <mzanetti> Saviq: and that number in the beginning is so to say a sleep n before the binary gets spawned?
[13:54] <Saviq> mzanetti, I believe so
[13:54] <Saviq> rsalveti, right ^?
[13:54] <mzanetti> ok... the reviewer will tell me if not :D
[13:55] <rsalveti> Saviq: yup
[13:55] <Saviq> dandrader, approved!
[13:55] <dandrader> Saviq, wow, I didn't think I would live to see this day! :P
[13:55] <Saviq> dandrader, it was a 2k diff after all ;)
[13:56] <dandrader> yeah
[13:57]  * dandrader goes to rebase his "close apps from dash" branch on top of it
[13:58] <mzanetti> rsalveti: I hope this should help with this: https://code.launchpad.net/~mzanetti/session-manager/lauch-shell-later/+merge/159832
[13:59] <mzanetti> rsalveti: I verified that maliit comes up successfully and is operating. so its really a race condition on the first boot
[13:59] <dednick> Saviq: i can if you think it is a good use of time.
[13:59] <mzanetti> rsalveti: we have an idea for the proper fix, but that's not going to happen today
[14:00] <mzanetti> dandrader: have a link to the bug for me?
[14:01] <dandrader> mzanetti, https://bugs.launchpad.net/bugs/1170495
[14:02] <Saviq> dednick, we'll have to fix/dive into it anyway, so your call on whether what you're doing now is higher prio
[14:02] <mzanetti> dandrader: cheers
[14:03] <dednick> Saviq: i'll just get mu current work finished, then take a look. I think Cimi is waiting on me.
[14:03] <Saviq> dednick, yeah, thought so
[14:04] <rsalveti> mzanetti: hm, that will add 2 seconds for the shell
[14:04] <rsalveti> mzanetti: what would be the proper fix for it?
[14:05] <mzanetti> rsalveti: modify the Qt maliit plugin: In case the connection to maliit-server fails during startup, it needs to listen to onServiceRegistered() on D-Bus and if malitt-server becomes available, connect to it
[14:05] <mzanetti> rsalveti: in here: https://qt.gitorious.org/qt/qtbase/blobs/606c21526aa4183946076e7784eea14b563a03f6/src/plugins/platforminputcontexts/maliit/qmaliitplatforminputcontext.cpp
[14:05] <mzanetti> line 544
[14:07] <Cimi> dednick, does variable != undefined work?
[14:07] <Cimi> dednick, in my previous code, only != "undefined" did
[14:08] <dednick> Cimi: should work
[14:08] <Cimi> dednick, you verified it works?
[14:08] <Cimi> I had to put "" because wasn't working on my code
[14:09] <Cimi> (when I did for the carousel)
[14:09] <dednick> Cimi: i've never seen "undefined"
[14:09] <Cimi> dednick, look at my code :-D
[14:09] <Cimi> ok though, fine
[14:09] <Cimi> when I had undefined things, I had to check the string
[14:09] <dednick> i did a search on the code tree for it ;)
[14:10] <Cimi> was old code indeed
[14:10] <rsalveti> mzanetti: right
[14:10] <rsalveti> mzanetti: are you planning on doing such change?
[14:10] <rsalveti> mzanetti: also, how critical is to get the workaround in, which bug will it fix?
[14:10] <mzanetti> rsalveti: https://bugs.launchpad.net/touch-preview-images/+bug/1157508
[14:10] <mzanetti> rsalveti: tmoenicke will do the proper fix
[14:11] <mzanetti> rsalveti: beginning of next week
[14:11] <Cimi> mzanetti, if we find a test where code could be simplified using _data
[14:11] <Cimi> mzanetti, shall I mark it as needs review or no? :)
[14:12] <mzanetti> rsalveti: regarding the question hwo critical it is... I would say not critical. But opinion may differ from others. the bug is mentioned here: http://iso.qa.ubuntu.com/qatracker/milestones/268/builds
[14:12] <Cimi> like this https://code.launchpad.net/~nick-dedekind/unity/phablet-tests-dashcontent/+merge/159459
[14:12] <Cimi> at least the last test
[14:12] <mzanetti> rsalveti: which creates visiblity on it :/
[14:13] <mzanetti> Cimi: yeah... the last one here should definitely be a _data() test imo
[14:13] <Cimi> mzanetti, not sure about a couple extra here
[14:13] <Cimi> mzanetti, like test_positioned_at_beginning_signal
[14:13] <mzanetti> Cimi: if one of them fails its way easier to find which one, because it will be split into separate test cases
[14:13] <Cimi> your opinion as expert?
[14:14] <rsalveti> mzanetti: right, let me check with folks then, mind updating the bzr merge package changelog to include the bug number as well?
[14:15] <mzanetti> rsalveti: sure. no problem
[14:15] <rsalveti> mzanetti: awesome, thanks
[14:15] <mzanetti> Cimi: yeah... I think the test_*_signal could be aggregated... but I'm not saying thats a must have
[14:16] <Cimi> ok
[14:16] <Cimi> dednick, so, it's up to you really
[14:17] <Cimi> read my chat
[14:19] <dednick> Cimi: ok. i'll take a look
[14:19] <Cimi> dednick, it's not required, the test works the same, it depends how you want to spend your friday afternoon :)
[14:20] <dednick> i fancy a drink
[14:20] <Cimi> go for it, I cover you ;)
[14:20] <Cimi> nobody will ever know :D
[14:20] <dednick> hehe
[14:29] <dednick> Cimi: pushed unity fake categories
[14:29] <nic-doffay> Saviq, another QML related question. I can't seem to find info on this. All I need to do is sequentially trigger one state after another. What's the best way to achieve this?
[14:31] <Cimi> dednick, awesome thx
[14:32] <didrocks> hey mterry! not sure what's your plan today, but it seems we have all autopilot tests failing, do you have a minute to look at this? (didn't get the time to look at that yet): for instance, run 115 on the generic job
[14:32] <didrocks> mterry: it's the      import Ubuntu.HUD 0.1 as HUD
[14:32] <didrocks> on gallery-app and webbrowser-app
[14:33] <mterry> didrocks, ah good, maybe their merges will go through then
[14:34] <didrocks> mterry: sorry, not following you :)
[14:34] <didrocks> mterry: btw, apparently, it's better for you to not get outside I heard today
[14:34] <mterry> didrocks, I've had merges for the hud transition ready for over a week, but they couldn't land because CI didn't have new hud yet
[14:34] <mterry> didrocks, yeah  :)
[14:34] <didrocks> fginther: can you help there? ^
[14:35] <didrocks> mzanetti: maybe you have something as well ^ :)
[14:35] <mterry> The jobs just need to be kicked
[14:35] <didrocks> mterry: do you think it's using the right ppa this time? :)
[14:35] <fginther> didrocks, mterry, I'll kick them again.
[14:36] <fginther> mterry, the phone-app was building yesterday, but failed the tests
[14:36] <mzanetti> didrocks: ?
[14:37] <Saviq> nic-doffay, you could add a PropertyAction {} that would change the state to the next one
[14:37] <Saviq> nic-doffay, but the question is if you actually need the in-between states at all
[14:37] <didrocks> mzanetti: see the backlog for some context, transition to HUD2, I think you had some dent on this for autopilot :)
[14:37] <nic-doffay> Saviq, what do you mean by in between states?
[14:38] <Saviq> nic-doffay, are we talking about QML states here at all?
[14:38] <nic-doffay> Saviq, yeah.
[14:39] <Saviq> nic-doffay, ok, so if you defined the states, in the transitions
[14:39] <Saviq> nic-doffay, you can put a SequentalAnimation { ... PropertyAction { }
[14:39] <Saviq> nic-doffay, that will mean that after everything else in the SeqAnim has finished, the state would get changed to the next one
[14:39] <Saviq> nic-doffay, but the real question is if you need the separate state at all
[14:40] <Saviq> nic-doffay, i.e. if it's just meant to be as a step in the transition, you can use sequential animations
[14:40] <Saviq> nic-doffay, without keeping it in a state
[14:41] <nic-doffay> Saviq, they should be different states. But for the inital animation I need to run through two of them.
[14:41] <Saviq> nic-doffay, then yeah, sounds like the PropertyAction {} approach will do
[14:41] <nic-doffay> Cheers Saviq !
[14:41] <Saviq> nic-doffay, you can also look at ScriptAction {} if PropertyAction won't do
[14:42] <Saviq> i.e. if you only want to do it on the first transition
[14:42] <Saviq> nic-doffay, I do remember, though, that there is some limitation around that
[14:43] <Saviq> nic-doffay, i.e. it might be that you can't change the state property in a transition
[14:43] <nic-doffay> Saviq, giving a SequentialAnimation with a PropertyAnimation a go quickly, I'll let you know if it doesn't perform...
[14:43] <Saviq> 'cause that could result in a weird state
[14:44] <Saviq> where you didn't yet reach the new state (transition has not finished)
[14:44] <Saviq> and changed the state
[14:44] <Saviq> nic-doffay, so you might need to use the running property of Transitions
[14:45] <Saviq> and act in « onRunningChanged: if (!running): »
[14:46] <fginther> mterry, I've kicked off new ci builds for your phone, webbrowser and gallery hud branches
[14:47] <dednick> Cimi: i've udpate the dashcontent test to use data. but only the last one.
[14:47] <Cimi> ok fine
[14:47] <didrocks> fginther: https://code.launchpad.net/~mterry/cupstream2distro-config/move-camera/+merge/159494 mind having a look?
[14:48] <fginther> didrocks, looking
[14:49] <didrocks> sil2100: is https://code.launchpad.net/~sil2100/cupstream2distro-config/qtubuntu_camera_additions/+merge/158931 still needed?
[14:53] <nic-doffay> Saviq, this is what I'm attempting to do at the moment.
[14:53] <nic-doffay> https://pastebin.canonical.com/89585/
[14:53] <sil2100> didrocks: let me check
[14:53] <nic-doffay> I can't really put it in a transition because I don't want this behaviour repeated every time a state changes.
[14:54] <sil2100> didrocks: I think mterry's branch is more advanced
[14:54] <sil2100> So I'll mark mine invalid
[14:54] <didrocks> ok ;)
[14:54] <didrocks> thanks sil2100
[14:54] <mterry> sil2100, my branch has robot arms
[14:54] <sil2100> ;)
[14:55] <sil2100> It has all those fancy hooks and configurations
[14:55] <tsdgeos> Saviq: ok, so the shell part for the highlighting of results is up and ready, but we don't want it merged until we get the Qt support and the backend support, right?
[14:55] <mzanetti> Saviq: what would you say is the "proper" fix for the search thingie? just hide everythig but "Installed apps" if searchtext.length > 0 ?
[14:56] <davmor2> Hey guys in autopilot is there a way to get a list of applications it knows about, I assumed it just used the .desktop name for the app but obviously not
[14:59] <tsdgeos> mzanetti: dandrader is working on that, no?
[15:00] <mzanetti> tsdgeos: no... Saviq asked us to hand it over to me
[15:00] <tsdgeos> ah
[15:00] <tsdgeos> sorry
[15:00] <mzanetti> np
[15:00] <sil2100> Oh noes, Francis dropped out
[15:00] <mzanetti> better make sure we're not duplicating
[15:00] <tsdgeos> mzanetti: i'd say that the fix he proposes in the bug is creating a proper-ish lens so that the "Recently executed" stuff goes away if there's no match
[15:01] <tsdgeos> like happens in the rest of places
[15:05] <davidcalle> didrocks, heya. I'm looking for a launchpadlib way to add affected projects to bugs, any idea? I don't find anything in the doc.
[15:06] <didrocks> davidcalle: it's quite easy
[15:06] <didrocks> davidcalle: look at lp:unify
[15:06] <mzanetti> tsdgeos: yeah... but I meant for a workaround for today
[15:06] <tsdgeos> ah
[15:06] <tsdgeos> ok
[15:06] <didrocks> davidcalle: http://bazaar.launchpad.net/~didrocks/unify/trunk/view/head:/unify/bugshandler.py#L511
[15:07] <didrocks> davidcalle: you can look some lines above for the definition of "component_to_open"
[15:07] <davidcalle> didrocks, perfect, thanks!
[15:07] <didrocks> davidcalle: ah, even better: http://bazaar.launchpad.net/~didrocks/unify/trunk/view/head:/unify/bugshandler.py#L173
[15:09] <Saviq> nic-doffay, not PropertyAnimation but PropertyAction
[15:09] <nic-doffay> Saviq, seems to be doing the job atm!
[15:10] <Saviq> nic-doffay, ok
[15:10] <Saviq> mzanetti, I commented on the bug
[15:10] <mzanetti> Saviq: yeah... don't understand what you're trying to say
[15:10] <Saviq> mzanetti, just move the hardcoded things out to a (visible=false) mockapps.scope
[15:11] <Saviq> .lens
[15:11] <Saviq> mzanetti, and use the same approach we have in DashHome
[15:11] <sil2100> fginther: hello!
[15:11] <sil2100> fginther: I know you're probably terribly busy right now...
[15:12] <Saviq> mzanetti, to use the data from the mockapps.lens for the two categories
[15:12] <Saviq> mzanetti, then, bind the search query on mockapps.lens to the page header search query
[15:12] <fginther> sil2100, what's up?
[15:12] <sil2100> fginther: but regarding for instance https://code.launchpad.net/~mterry/gallery-app/hud1/+merge/158471 - I saw you did some work to enable daily-next for the CI
[15:13] <Saviq> mzanetti, I might be overcomplicating things
[15:13] <fginther> sil2100, yes I've enabled daily-next for a few jobs so far.
[15:13] <mzanetti> Saviq: I guess so :D
[15:13] <sil2100> fginther: but I saw in one place that there was an error in executing the hook script
[15:13] <sil2100> Trying to find it now ;/
[15:13] <sil2100> I had it just a moment agi!
[15:15] <dandrader> tsdgeos, would you like to claim this review? https://code.launchpad.net/~dandrader/unity/phablet_close_apps_from_dash/+merge/159845
[15:15] <tsdgeos> sure
[15:15] <Saviq> mzanetti, you could add/remove the categories from categoryListModel indeed
[15:16] <sil2100> ah
[15:16] <sil2100> fginther: it was for the phone-app hud1 branch... -> https://jenkins.qa.ubuntu.com/job/phone-app-raring-i386-ci/54/console
[15:16] <sil2100> fginther: but I'm a bit confused...
[15:17] <dandrader> tsdgeos, thanks!
[15:17]  * tsdgeos pressed the claim button
[15:17] <dandrader> :)
[15:17] <sil2100> Anyway, we'd need the phone-app and gallery-app merges for switching to HUD 1.0 merged somehow
[15:18] <Saviq> mzanetti, yeah, I think for now just get into the SortFilterProxyModel
[15:18] <Saviq> mzanetti, and change filterRegExp and invertMatch accordingly
[15:18] <fginther> sil2100, the phone-app is building now, but it's failing the autopilot tests. one moment, I'll grab the link
[15:18] <Saviq> mzanetti, DashApps.qml:103
[15:18] <mzanetti> Saviq: purrfect... that's exactly what I started
[15:19] <mzanetti> with
[15:19] <fginther> sil2100, https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner/1132/
[15:20] <tsdgeos> dandrader: should the [x] go away if i launch a different app?
[15:20] <tsdgeos> seems it should, no idea what design said or if you have any design :D
[15:20] <dandrader> tsdgeos, I don't know
[15:21] <fginther> sil2100, gallery-app and webbrowser-app failed because of missing dependencies in the quantal builds
[15:21] <tsdgeos> dandrader: do we have a design point of contact for this?
[15:21] <dandrader> tsdgeos, I mean, i didn't put any code to change the close mode when that happens and this feature has no design yet
[15:21] <tsdgeos> i see
[15:21] <tsdgeos> :-/
[15:21] <fginther> sil2100, I'm going to try again with the old ppas add
[15:21] <tsdgeos> ok then, let them file bugs :D
[15:21] <sil2100> fginther: ah, I see that they're failing because HUD 1.0 is not available
[15:22] <dandrader> tsdgeos, it's explained in the commit description
[15:22] <tsdgeos> didn't read it :D
[15:22] <tsdgeos> sorry
[15:22] <tsdgeos> was just quick testing
[15:23] <fginther> sil2100, the autopilot tests run on quantal, is that the cause?
[15:24] <Saviq> tsdgeos, did you interface with Mirv to get QColor distropatched?
[15:24] <sil2100> fginther: probably, uhhh, why did the tests run on quantal btw.?
[15:24] <tsdgeos> Saviq: not yet since there's no agreement upstream yet on the final form of the patch, was waiting on that
[15:24] <fginther> sil2100, that what we had to support when starting to run those tests
[15:24] <Saviq> tsdgeos, ok
[15:24] <sil2100> fginther: does the generic-mediumtests-runner job only run on quantal?
[15:25] <sil2100> Ah, ok ;)
[15:25] <fginther> sil2100, yes
[15:25] <tsdgeos> Saviq: i'd prefer to have something approved upstream for 5.2 and then put it in our packages of 5.1/5.0.2/whatever, that ok?
[15:25] <fginther> sil2100, we have requested some resources to start the transition to raring
[15:25] <Saviq> tsdgeos, perfect
[15:25] <sil2100> Ok, hmmm
[15:26] <sil2100> fginther: would you mind if we approve the merges globally without the generic-mediumtests-runner passing?
[15:26] <fginther> sil2100, that's not my call. Please ask mzanetti.  Note that if we do that, we won't be able to run the medium tests on any future MPs
[15:27] <sil2100> fginther: indeed, but without those branches we're blocked with our stacks on the other hand
[15:27] <mzanetti> sil2100: tried that... if you do it we can throw away autopilot tests within a month. noone will fix them
[15:27] <fginther> sil2100, awesome, deadlock
[15:27] <sil2100> Since we already have HUD 1.0 in the daily-next PPA, so all tests are failing there
[15:28] <sil2100> Great...
[15:28] <tsdgeos> dandrader: nitpick, witdth -> width
[15:28] <sil2100> fginther, mzanetti: can't we get HUD 1.0 into some quantal PPA that could be used by CI?
[15:29] <fginther> mzanetti, can the medium tests run on raring (assuming we had a box)? Would that unlock us?
[15:29] <mzanetti> sil2100: sure. if we have a ppa we just need to add a hook to the job
[15:29] <tsdgeos> dandrader: also i'd say the "// was bla bla" is not really needed, we can use bzr log :-)
[15:29] <mzanetti> fginther: I requested the raring vm today
[15:29] <mzanetti> fginther: assuming all our scripts and autopilot works fine on it, we should be able to just switch, yes
[15:30] <sil2100> Need to check what we need to get the new hud 1.0 on quantal
[15:30] <mzanetti> tsdgeos: you know perhapy? ^
[15:30] <mzanetti> perhaps
[15:30] <fginther> sil2100, mzanetti, it's quite easy to add a ppa to the build if we can get hud in 1
[15:30] <tsdgeos> mzanetti: hmmm, what's the real question?
[15:31] <mzanetti> tsdgeos: they seem to have issues with installing the HUD stuff
[15:31] <mzanetti> sil2100: can you explain more? tsdgeos is our HUD guy
[15:31] <sil2100> Ok, so hm...
[15:31] <sil2100> Well, I'm thinking if it makes sense anyway
[15:32] <sil2100> tsdgeos: would it be hard to get the latest lp:hud (1.0) working on quantal ? Does it have any hard dependencies on raring?
[15:32] <dandrader> tsdgeos, I have to say what was its previous value (which is cleaner) to help in the explanation of the current one
[15:32] <dandrader> tsdgeos, otherwise the other sentence would be left without context
[15:32] <sil2100> mzanetti, fginther: since I'm wondering if it makes sense to bother with quantal building, since right now even quantal autopilot coverage for lp:gallery-app is pointless for us
[15:32] <sil2100> Since lp:gallery-app is anyway now ->raring
[15:33] <tsdgeos> dandrader: sure, i meant to kill both :D
[15:33] <dandrader> tsdgeos, but them someone will want to change it back again without knowing the problem with it
[15:33] <sil2100> So even autopilot test results for quantal for lp:gallery-app and lp:phone-app seems pointless, as it doesn't show the state of the app in the current release
[15:34] <sil2100> There should be separate branches for quantal anyway
[15:34] <dandrader> tsdgeos, general rule
[15:34] <tsdgeos> sil2100: lp:hud is not going to work with the shell anyway
[15:34] <dandrader> when some code is weird (as with work-arounds), you have to explain it
[15:34] <tsdgeos> dandrader: well i'd say we should have a test then :D
[15:34] <tsdgeos> dandrader: i don't trust your general rules, they say you have to wrap at column 72 ;-)
[15:34] <dandrader> tsdgeos, how am I going to test for a warning message that is printed on stdout?
[15:34] <mzanetti> hmm... I guess we will have a raring VM by monday
[15:35] <mzanetti> that means I could start trying to run mediumtests on it
[15:35] <tsdgeos> dandrader: it doesn't cause any other problem?
[15:35] <dandrader> tsdgeos, I don't know
[15:35] <tsdgeos> ok
[15:35] <dandrader> tsdgeos, wrapping long lines is a very widely used convention. I didn't invent it
[15:35] <fginther> mzanetti, I can help with some testing on my end
[15:36] <tsdgeos> dandrader: i know
[15:36] <tsdgeos> there's lots of old conventions i don't trust :D
[15:36] <dandrader> tsdgeos, it's old, but not obsolete
[15:37] <mzanetti> fginther: I think the biggest issue is to update scripts in lp:ps-qa-tools to be able to set up machines on raring
[15:37] <mzanetti> fginther: once we have those and can set them up I don't expect much troubles
[15:38] <dandrader> tsdgeos, you could just as well not trust the age-old convention of indenting your code consistently
[15:38] <tsdgeos> i could
[15:38] <dandrader> mixing tabs with spaces, etc
[15:38] <tsdgeos> but my good sense made me decide it's ok
[15:38] <fginther> mzanetti, I'll setup a local VM and check them out
[15:38] <tsdgeos> dandrader: otoh we do mix tabs and spaces in poppler :D
[15:39] <tsdgeos> hate it
[15:39] <sil2100> didrocks: what say you?
[15:39] <dandrader> tsdgeos, and compiz, if I'm not mistaken
[15:39] <dandrader> totally crazy
[15:40] <tsdgeos> never understood the reason for it
[15:41] <sil2100> didrocks: I mean, I think it would be wise to get those two merges to lp:gallery-app and lp:phone-app in, even though they would basically break quantal autopilot CI for those branches
[15:41] <sil2100> didrocks: since at least we'll get the stack AP tests to work
[15:41] <sil2100> (the HUD 0.1 -> 1.0 switch)
[15:41] <Saviq> mterry, about the moc things, it built (and worked) just fine here without the symlinks, how can I reproduce what you're seeing?
[15:41] <sil2100> Ok, brb, need to drive my girl somewhere, be back soon
[15:43] <tsdgeos> dandrader: the  ApplicationManager::stopProcess implementation in tests/mocks/Ubuntu/Application/ApplicationManager.cpp doesn't seem to match what we do in reality
[15:43] <tsdgeos> i mean, when killing an app, if you have another one it'll replace it
[15:43] <tsdgeos> not have m_mainStageFocusedApplication = 0;, no?
[15:43] <tsdgeos> or maybe you do
[15:44] <tsdgeos> and then get a focus in?
[15:45] <dandrader> tsdgeos, well, the resulting behavior is the same
[15:46] <tsdgeos> ok
[15:46] <tsdgeos> it's just the mock part
[15:46] <mterry> Saviq, hmm
[15:46] <tsdgeos> we can fix it later if we find out doesn't really adjust what the non-mock does
[15:46] <tsdgeos> that's the problem with mocks
[15:46] <mterry> Saviq, i took out that stuff and I got the symbol error
[15:46] <tsdgeos> your test depends on it being correct :D
[15:46] <Saviq> mterry, let me try again
[15:48] <Saviq> mterry, it's conflicting again, btw ;)
[15:48] <tsdgeos> dandrader: on test_enterTerminationMode() can you add the compares that check the termination mode is still enabled after the first mouseRelease ?
[15:49] <mterry> Saviq, you are killing me
[15:49] <mterry> Saviq, everyone stop changing trunk
[15:49] <Saviq> right now!
[15:49] <dandrader> tsdgeos, !?
[15:50] <tsdgeos> dandrader: now you do : press, wait, check that termination is enabled, release
[15:50] <tsdgeos> i'm askign you to
[15:50] <dandrader> tsdgeos, mousePress+wait == long press
[15:50] <tsdgeos> press, wait, check that termination is enabled, release, check that termination is still enabled
[15:50] <tsdgeos> yes
[15:51] <tsdgeos> i understand that
[15:51] <dandrader> tsdgeos, you mean adding another check after the first release and before the second press
[15:51] <tsdgeos> yes
[15:51] <dandrader> tsdgeos, ok, I can do it
[15:52] <mterry> Saviq, merged from trunk
[15:52] <Saviq> mterry, cheers
[15:52] <fginther> mterry, reviewed: https://code.launchpad.net/~mterry/cupstream2distro-config/move-camera/+merge/159494
[15:53] <dandrader> tsdgeos, done
[15:54] <mterry> fginther, updated
[15:55] <tsdgeos> dandrader: also those 800 look a bit ugly (because of the arbietrarity of 800), do you think we could do a while with a qsignalspy against pressAndHold?
[15:55] <tsdgeos> not sure it's much better
[15:55] <tsdgeos> but kills the 800
[15:56] <dandrader> tsdgeos, you mean waiting until pressAndHold gets emitted?
[15:56] <Saviq> mterry, yeah, it was working for me probably because the links were still there
[15:56] <tsdgeos> dandrader: yep
[15:56] <dandrader> tsdgeos, it's worth trying
[15:56] <tsdgeos> dandrader: actually you may as well remove the 800 and let tryCompare do the waiting, no?
[15:57] <tsdgeos> it is waiting for 5sec by default
[15:57] <dandrader> tsdgeos, I would like to make it explicit that I'm "pressing and holding"
[15:57] <tsdgeos> so that should be enough
[15:57] <tsdgeos> dandrader: add a comment :D
[15:57] <Saviq> mterry, I really would rather have the headers simply included in our tree for now, then
[15:58] <tsdgeos> or do the spy thing
[15:58] <tsdgeos> and trycompare on it
[15:58] <Saviq> mterry, instead of the link (and we could then stop pretending we actually link to liblightdm)
[15:58] <mterry> Saviq, we don't pretend we link right now
[15:58] <dandrader> tsdgeos, it will fail it the state is changed onPressed()
[15:58] <Saviq> mterry, yeah, but we depend on the -dev
[15:58] <dandrader> I mean, it will pass
[15:58] <dandrader> incorrectly
[15:59] <dandrader> actually the current test already does
[15:59] <mterry> Saviq, sure.  Is that so bad?
[15:59] <tsdgeos> dandrader: true
[15:59] <nic-doffay> Saviq, out of interest, I tried a PropertyAction as you suggested because the PropertyAnimation is overkill, but this doesn't appear to work: https://pastebin.canonical.com/89592/
[15:59] <Saviq> mterry, the process of building leaves artifacts in the source tree
[15:59] <tsdgeos> dandrader: so add the spy for pressAndHold ?
[15:59] <dandrader> tsdgeos, something like that. I'm not sure yet how to do it
[16:00] <Saviq> nic-doffay, that's because you're setting the value to "pointer" and then to "unfilled" straight away
[16:00] <Saviq> nic-doffay, and you can't animate strings
[16:00] <mterry> Saviq, hmm...  I don't like hard copying it for the mock either...  unless we add a test that fails if the system version and the local one are out of sync.  but we'd still have to dep on the -dev package then
[16:00] <fginther> mterry, approved. thanks!
[16:00] <mterry> Saviq, but at that point, we're going out of our way to avoid a symlink
[16:01] <mterry> Saviq, is there an option we can pass to moc to make it smarter about weird header situations?  I couldn't find any
[16:01] <tsdgeos> dandrader: should be "easy", no? just create a  SignalSpy { signal: "pressAndHold" }set the target to the tile and do a tryCompare(spy.count, 1) ?
[16:01] <Saviq> nic-doffay, that's why you shouldn't use PropertyAnimation on string properties
[16:02] <Saviq> mterry, ok, I'll have a fresh look on Monday
[16:02] <dandrader> tsdgeos, I have also to check that it doesn't change the terminatio mode before that signal is emited
[16:02] <nic-doffay> Saviq, PropertyAnimation was working perfectly, but PropertyAction doesn't.
[16:02] <dandrader> tsdgeos, so maybe tryCompareFunction() will do
[16:02] <Saviq> nic-doffay, that's only because PropertyAnimation has a duration
[16:02] <tsdgeos> right
[16:02] <Saviq> nic-doffay, so it only sets the value to the new one after its duration
[16:02] <tsdgeos> dandrader: will add that as needs fixing in the MR so we don't forget
[16:03] <nic-doffay> Saviq, so that would be the best method to use then?
[16:03] <tsdgeos> need to run now
[16:03] <tsdgeos> friiiiday
[16:03] <dandrader> tsdgeos, ok.
[16:03] <mzanetti> tsdgeos: hurry!
[16:03] <dandrader> tsdgeos, hey hey
[16:03] <Saviq> nic-doffay, if you put a PauseAnimation between the PropertyActions, it will work
[16:03] <dandrader> tsdgeos, one sec!
[16:03] <dandrader> tsdgeos, does signalspy have that bug that it doesn't reset its count?'
[16:03] <didrocks> sil2100: discussed with sergiusens about it
[16:03] <dandrader> tsdgeos, or is it something else?
[16:03] <didrocks> sil2100: so basically, what we can do:
[16:03] <tsdgeos> dandrader: it may, i've seen we do .reset() in some places
[16:03] <Saviq> nic-doffay, but really, if you have transitions between the "pointer" and "unfilled" states
[16:03] <nic-doffay> Saviq, ok brilliant thanks.
[16:03] <didrocks> quantal will have a final release today
[16:03] <tsdgeos> .clear() i  mean
[16:04] <didrocks> sil2100: then, we can switch on Monday to HUD 2
[16:04] <tsdgeos> dandrader: ↑
[16:04] <didrocks> for everything
[16:04] <didrocks> mzanetti: FYI ^
[16:04] <nic-doffay> Saviq, I have no transitions between them.
[16:04] <tsdgeos> dandrader: mzanetti you had this problem, right?
[16:04] <Saviq> nic-doffay, you should put the PropertyAction changing the state at the end of the transition to "pointer"
[16:04] <didrocks> sil2100: making sense?
[16:04] <didrocks> sil2100: so don't break the apps right now, let's do that on Monday
[16:04] <nic-doffay> Saviq, but then that would apply to every state change which I don't want.
[16:04] <Saviq> nic-doffay, can you push the whole code somewhere? I think there's some misunderstanding going on
[16:04] <nic-doffay> Yeah no problem.
[16:04] <mzanetti> dandrader: yes... there is a bug in signalSpy. however its a bit weird... as long as you keep the same signalName and target I think it works. but once you assign it to another signal or so the clear() breaks
[16:05] <mzanetti> tsdgeos: ^
[16:05] <dandrader> mzanetti, ah, ok. good enough for my usage then
[16:05] <tsdgeos> mzanetti: one day we'll have to report that bug too ;-)
[16:05] <dandrader> or even better: fix it and put your name in Qt's hall of fame :)
[16:05] <mzanetti> didrocks: ack. I hope the raring VM is ready by monday so I can start with moving mediumtests
[16:06] <didrocks> mzanetti: yeah, that would be needed ;)
[16:06] <didrocks> mzanetti: let's cross fingers!
[16:06] <mzanetti> tsdgeos: dandrader: nah... already in there...
[16:06] <dandrader> me too :)
[16:06] <mzanetti> lets others have some fun too
[16:06] <mzanetti> :P
[16:06] <mterry> Saviq, actually...  maybe it's not so important that we always stay in sync with the headers
[16:06] <mzanetti> indeed... doesn't sound too complicated to fix...
[16:07] <Saviq> mterry, yeah, that's what I thought
[16:07] <Saviq> mterry, since we just fake the whole interface - it's rather the opposite
[16:07] <mterry> Saviq, I can make a commit that drops the links, and thus drops the need for liblightdm in this merge
[16:07] <Saviq> mterry, if the headers changed, we would break even if we're not really using it
[16:08] <Saviq> mterry, yeah, please, just copy the headers as they currently are
[16:08] <Saviq> mterry, and when the time comes we just yank them out
[16:08] <mterry> Saviq, no, we'll still need them for the mock plugin
[16:09] <mterry> Saviq, for the mock plugin, I'd like to still use the real plugin's code, and just swap out the liblightdm bits
[16:09] <mterry> Saviq, so that we can test the plugin's logic (like the realname->name conversion0
[16:09] <Saviq> mterry, yeah, we'll work it out
[16:13] <mzanetti> Saviq: ubuntu-phone mailing list. mail from Alberto :)
[16:27] <mzanetti> Saviq: https://code.launchpad.net/~mzanetti/unity/phablet-hide-static-apps-while-search/+merge/159857
[16:30] <Saviq> mzanetti, yeah, saw that ;)
[16:30] <Saviq> mzanetti, I mean the email
[16:31] <Saviq> mzanetti, "invertMatch ?" bad :P
[16:31] <Saviq> mzanetti, either do the direct condition
[16:31] <Saviq> mzanetti, or have a separate bool prop
[16:32] <Saviq> mzanetti, I know it's slightly less performant, but much more readable ;)
[16:38] <mterry> Saviq, btw, updated the branch
[16:40] <mterry> fginther, links I'm seeing in MPs like http://jenkins.qa.ubuntu.com/job/unity-phablet-raring-i386-ci/545/console are giving me 404s
[16:41] <fginther> mterry, hmmm
[16:42] <Saviq> mterry, yeah, thanks
[16:43] <fginther> mterry, this might take a bit to figure out
[16:45] <nic-doffay> Saviq, when you have a moment: https://code.launchpad.net/~nicolas-doffay/unity/infographics
[16:45] <nic-doffay> Check Dot.qml line 35
[16:45] <nic-doffay> I'm attempting to Do a PropertyAction on the visible property which isn't working.
[16:45] <nic-doffay> Everything else is good.
[16:51] <mzanetti> Saviq: pushed a FIXME... sorry. this is all I can do now - have to run. I'll fix it properly next week.
[16:52] <Saviq> mzanetti, have fun!
[16:52] <mzanetti> Saviq: btw... using the expression directly is why I was feeling stupid... you'll understand when you see the FIXME
[16:52] <mzanetti> Saviq: diff is updated
[16:55] <mzanetti> ok. then.. have a good weekend!
[18:01] <Saviq> mzanetti, yeah, it doesn't reevaluate when invertMatch is changed...