[07:02] <mzanetti> good morning
[07:10] <jussi> mzanetti: do you have any ideas on who/where  else to  possibly ask? (About the notification issue Im having, you suggested #ubuntu-webapps on friday)
[07:11] <mzanetti> jussi: sorry. no idea
[07:12] <jussi> mzanetti: ok, thanks. Ill let you know if I actuall find a solutoin somewhere...
[07:14] <didrocks> hey sil2100, how are you?
[07:26] <mzanetti> jussi: cheers
[07:28] <jussi> mzanetti: found the issue
[07:28] <jussi> mzanetti:
[07:28] <jussi> https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1153137
[07:29] <jussi> basically those were pulled into chromium by accident
[07:29] <jussi> and simply uninstalling them fixes the issue
[07:35] <mzanetti> tsdgeos: good morning
[07:35] <tsdgeos> hiho
[07:36] <mzanetti> tsdgeos: yeah, I just triggered a rebuild, given that it failed only one one of the builders
[07:36] <mzanetti> still weird... crash in gcc if I read it correctly
[07:36] <tsdgeos> gcc?
[07:36] <tsdgeos> perl it says, no?
[07:37] <mzanetti> yeah well, aynthing that compiles/interprets it. not our code myself
[07:37] <mzanetti> itself
[07:38] <mzanetti> actually in debhelper... never seen that before
[07:38] <mzanetti> lets see if it passes now
[07:38] <sil2100> didrocks: hi! Fine ;) How about you?
[07:39] <sil2100> didrocks: on Friday I tried to add the package to the stacks, I pushed a branch yesterday
[07:39] <tsdgeos> sil2100: hi there, asking again, sorry, did the compiz fix for qt popups get merged?
[07:39] <sil2100> didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/android-audiosystem_add/+merge/158806
[07:40] <sil2100> tsdgeos: yes \o/ So it seems at least
[07:40] <tsdgeos> sil2100: should it be in raring? or does it need releasing?
[07:41] <sil2100> It's not in raring yet, I don't see the release commit for it
[07:41] <tsdgeos> oki
[07:41] <sil2100> But I think soon it should be in
[07:43] <didrocks> sil2100: great! do you mind keeping the file ascii sorted for projects, please?
[07:44] <sil2100> Ah! Ok ;)
[07:44] <sil2100> But is the platform stack the right place?
[07:44] <didrocks> sil2100: sounds good, I would have put it in platform or misc as there is no tests, but fine either way :)
[07:44] <didrocks> sil2100: do you have time for a hangout for the next course of action then?
[07:45] <sil2100> didrocks: can we have it in 30 minutes :) ?
[07:45] <didrocks> sil2100: sure
[07:46] <mzanetti> tsdgeos: it passed
[07:47] <tsdgeos> :-)
[07:47] <mzanetti> jussi: thanks
[07:47] <jussi> mzanetti: yw
[07:48] <tsdgeos> mzanetti:  print("**volume changed", volume, actionGroup.serverVolume) ?
[07:49] <mzanetti> tsdgeos: do'h... I thought I removed them all... will do so now
[07:50] <mzanetti> tsdgeos: done
[07:51] <tsdgeos> oka, charging the phone, somehow it died even if it was turned off :S
[07:52] <tsdgeos> good that 2A charger that came with the Nexus10 :D
[07:52] <tsdgeos> charges phones fast
[07:53] <mzanetti> yeah
[07:53] <mzanetti> yeah... mine is still on
[07:53] <mzanetti> charged it mid-last week for the last time. was in standby here on my desk
[07:53] <mzanetti> say 32% remaining
[07:54] <tsdgeos> weird
[07:56] <mzanetti> awesome, not weird :D
[07:57] <mzanetti> ah... no wifi connected. that helps of course
[07:57] <tsdgeos> mzanetti: so i just moved the volume slider in overview to max
[07:58] <tsdgeos> and it is still at min in the volume indicator :-S
[07:58] <mzanetti> tsdgeos: that seems a bug in the volume indicator then. because if you move it with alsamixer, the slider in overview moves around
[07:59] <tsdgeos> seems there's something weird when it's at min and you move to max
[07:59] <tsdgeos> otherwise the rest works "ok"
[08:00] <mzanetti> tsdgeos: I'll test
[08:03] <tsdgeos> mzanetti: on the device seems that using the overview slider i can't go to 0 or to 100
[08:03] <tsdgeos> everything else, alsamixer updates to
[08:03] <tsdgeos> but 0 or 100 alsamixer ignores
[08:03] <tsdgeos> let's see the indicator
[08:04] <tsdgeos> yeah, 0 and 100 don't work from overview and work from indicator
[08:05] <tsdgeos> not sure that'd be "your fault" though
[08:11] <tsdgeos> since your code doesn't seem to care about that
[08:12] <tsdgeos> mzanetti: should serverVolume still be readonly?
[08:13] <mzanetti> tsdgeos: its now internal one....
[08:13] <mzanetti> still could be...
[08:13] <tsdgeos> true
[08:13] <mzanetti> let me fix
[08:14] <tsdgeos> mzanetti: do you know where QDBusActionGroup comes from?
[08:14] <mzanetti> tsdgeos: no... it was there for the hardware volume buttons
[08:14] <mzanetti> tsdgeos: I just made it more guideline-compliant and reused it in the overviewpage
[08:14] <tsdgeos> sure
[08:15] <tsdgeos> wanted to know what qdbus calls it made
[08:15] <tsdgeos> to prove it wasn't the ui fault that 0 and 100 don't work
[08:15] <tsdgeos> Saviq: do you know where QDBusActionGroup comes from?
[08:15] <Saviq> tsdgeos, sounds like qmenumodel
[08:15] <tsdgeos> may be
[08:15] <mzanetti> tsdgeos: ah... yeah. I suspect it to be in there too. but haven't seen it before. even though it seems really useful and probably should be part of QtQuick itself
[08:16] <Saviq> tsdgeos, https://code.launchpad.net/qmenumodel
[08:16] <tsdgeos> mzanetti: seems like a gtk/glib adaptor thing, not sure makes sense :D
[08:16] <mzanetti> tsdgeos: oh... in that case no... but exactly the same that just wraps QDbus for qml...
[08:16] <tsdgeos> yep
[08:17] <mzanetti> tsdgeos: I guess that would be QServiceFramework tho
[08:17] <tsdgeos> Saviq: yeah it's there, tx
[08:19] <tsdgeos> meh, can't call (sva{sv}) with qdbus
[08:22] <jibel> didrocks, I noticed that network and location stacks have an empty 'tests' parameter. What do they run in this case ?
[08:23] <didrocks> jibel: they are doing the dist-upgrade I guess
[08:23] <didrocks> jibel: but I'm waiting them to have components to have the list of real tests ;)
[08:23] <didrocks> sil2100: it's 40 minutes ;)
[08:25] <jibel> didrocks, so we are provisioning 3 machines just to check installability/upgradeability of the packages, right?
[08:25] <didrocks> jibel: indeed
[08:25] <didrocks> which is better than nothing ;)
[08:27] <sil2100> didrocks: ready ;)
[08:27] <sil2100> Didn't want to hang-out in my pajamas
[08:27] <jibel> didrocks, hm, okay, seems suboptimal, couldn't it be tested before starting the provisioning, running something like piuparts and then only provision physical machines and run AP if it succeeds?
[08:28] <didrocks> jibel: this is really temporary, we'll have by the end of the week I hope at least one AP to run
[08:29] <tsdgeos> mzanetti: have you been able to reproduce the 0/100 problem?
[08:29] <mzanetti> tsdgeos: not yet. had to reflash the device. still on it
[08:29] <didrocks> sil2100: https://plus.google.com/hangouts/_/7ab39ee5ed454250b930d481b69dd69b80ca8f50?authuser=0&hl=fr
[08:29] <tsdgeos> i can't find how to pass a variant to gdbus either
[08:30] <mzanetti> all those uppercase letters on the OSK even when typing lowercase letters confuse the shit out of me :D
[08:31] <jibel> didrocks, ack, just doing some capacity planning to estimate our needs in physical hw and optimizing the resources we have already.
[08:33] <didrocks> jibel: after this hangout, do you want to discuss some strategy for this?
[08:33] <jibel> didrocks, sure thing
[08:40] <tsdgeos> mzanetti: yeah the BB Z10 does the same, i find it not cool
[08:40] <tsdgeos> because the BB playbook doesn't :D
[08:40] <tsdgeos> they changed their mind from product to product
[08:40] <mzanetti> tsdgeos: stupidly copying apple crap
[08:41] <mzanetti> tsdgeos: I guess the biggest troubles is because I use maliit now for 2 years, but in a sane configuration
[08:42] <tsdgeos> D:
[08:42] <tsdgeos> what i like a "lot" about the BB10 is the inline suggestions in the keyboard
[08:42] <tsdgeos> have you seen those?
[08:42] <mzanetti> tsdgeos: narf... no. I haven't seen anything bug a youtube video from the BB Z10
[08:42] <mzanetti> I'd really like to get one into my hands
[08:44] <tsdgeos> mzanetti: see www.youtube.com/watch?v=6Fusk03iTEI&feature=youtu.be&t=27s
[08:45] <tsdgeos> the little words over the keys can be just typed by pressing they key and swiping up
[08:45] <mzanetti> yeah... this seems cool indeed
[08:46] <tsdgeos> so eventually you can have lots of "next word" suggestions
[08:46] <mzanetti> if it adjusts to personal usage it can become quite efficient I guess
[08:47] <tsdgeos> it does
[08:47] <tsdgeos> or seems to
[08:47] <mzanetti> let me try to write a mail to some developer friends at rim :D see if they have a developer device around they don't need any more
[08:47] <tsdgeos> at least here it started suggesting words quickly after the first messages
[09:13] <luv> mardy: hey mardy ... umm i have noticed few other problems with ubuntu online accounts :'(
[09:13] <luv> mardy: first of all doing async callback-based programming in gobject is a proper torture and big thumbs up for you guys to cope with that :-)
[09:16] <luv> mardy: though what makes me really upset is that I can see the passwords in gnome-keyring without being prompted for my password - well, not really a fault of UOA, but it affects UOA drastically.
[09:17] <luv> in comparison, firefox password manager will ask you for your master password (again!) before allowing you to see the passwords decrypted
[09:18] <mardy> luv: that's a "feature" of GNOME keyring: there is a master password, but the keyring is automatically unlocked when you login
[09:18] <luv> well I am happy to help ... but given me trying to hack on UOA last few week didnt get very far, Im a bit down now.
[09:18] <luv> luv: yes, that's what im saying
[09:20] <luv> also, signon_identity_signout  doesnt not do what we want ... so only possibility is to create a new identity, change account to that identity and delete the old one (which is fine ... if it didnt have to be coded in gobject async madness :-) ... it's about five lines of python ;-) )
[09:21] <luv> next problem ... even when using the existing "remove account" functionality it sometimes does not delete the associated identity - it happened to me with a made-up jabber account
[09:21] <luv> mardy: well GNOME keyring has to be cleared patch to required your password even when you are logged-in because this a huge f*cking security problem for UOA if it doesn't (sorry for being that upfront about it)
[09:22] <luv> s/cleared/clearly/ .. s/patch/patched/ .... :-)
[09:25] <luv> (an obvious use-case - I am visting a friend, (s)he lets me use the computer, leaves to make a tea and I have their google/yahoo/ms account)
[09:32] <tsdgeos> mzanetti: could you repro¿
[09:33] <mzanetti> tsdgeos: yes
[09:34] <tsdgeos> any clue what may be wrong?
[09:34] <mzanetti> tsdgeos: not yet... but there seems something fishy in my code indeed
[09:34] <sil2100> https://code.launchpad.net/~sil2100/webbrowser-app/change_arch_to_list/+merge/158871 <- didrocks
[09:35] <tsdgeos> mzanetti: you sure? mean you are just passing 0 and 1 to actionGroup.actionObject.updateState, no?
[09:36] <didrocks> sil2100: looks good :)
[09:36] <didrocks> sil2100: approved ;)
[09:37] <luv> mardy: sorry for pointing out problems in solution you are working on .. but seriously ... it's like being able to easily see your linux password decrypted after you log in (if not worse)
[09:38] <mardy> luv: you can change your master password in the gnome keyring, and then it won't open automatically at login
[09:39] <mardy> luv: signon_identity_signout might be buggy, but it should do exactly what you want to do: clear the password and all stored tokens
[09:40] <luv> mardy: well I can, and I can stop using UOA (as I do at the moment - it's the only issue which keeps me on 12.04, that's why I care) but what about those tens of millions of users who do not know about it! ... signon_identity_signout  is not supposed to clear the passwords at least not according to the docs and comments in the code
[09:40] <luv> i wish it was!
[09:40] <mzanetti> tsdgeos: yeah... I debugged a bit more... seems to be the QDBus thingie indeed. however, I found another issue in my code. so let me fix that before approving
[09:41] <tsdgeos> oka
[09:41] <luv> and again even if i change the master password - it does not help!
[09:41] <tsdgeos> and add a unit test for that you found :D
[09:41] <luv> i want to be able to use the keyring but not to see the passwords decrypted
[09:41] <luv> just as other passwords managers do
[09:42] <mardy> luv: http://code.google.com/p/accounts-sso/source/browse/src/signond/signonidentity.cpp?repo=signond#370
[09:42] <luv> umm, i guess, let's get it covered on slashdot and it will make the gnome guys fix it ;-)
[09:42] <luv> mardy: http://docs.accounts-sso.googlecode.com/git/libsignon-glib/html/SignonIdentity.html#signon-identity-signout
[09:43] <mardy> luv: oops, yes, the documentation is incomplete and misleading
[09:43] <tsdgeos> dednick: i thought we were removing FIXME's not adding them :D
[09:43] <mardy> luv: I'll fix that
[09:45] <luv> mardy: ok, I will make sure the gnome guys fix the bug in gnome-keyring :-) I guess a blog post linked from slashdot will do the job :-)
[09:47] <mardy> luv: I'm not sure it's a bug, but you can try
[09:47] <mardy> luv: the alternative is that you'll always be asked for the master password the first time an applications tries to ue the keyring
[09:50] <luv> they will probably need to add a concept of a "privileged application" or something
[09:50] <luv> your solution - to ask first time for every application trying to use it - is very good as well
[09:51] <luv> umm, the dont' think it's a bug either ... that's why we need slashdot to tell them ;-)
[09:51] <mardy> luv: I don't know, I think it would be very annoying for the users
[09:51] <luv> well, yeah, the fact that anyone can steal your password is not annoying though ;-)
[09:52] <luv> people are not shouting at gnome devs only because they do not know it's that easy to "get in"
[09:53] <luv> maybe ask every time an application wants to use the keyring + "privileged applcations" (application which are granted access just when you log in) ... would make everyone happy
[09:57] <mzanetti> tsdgeos: pushed... the 0/1 seems not to be my code
[09:57] <tsdgeos> mzanetti: shall we open a bug?
[09:58] <tsdgeos> against the shell itself
[09:58] <tsdgeos> saying "this doesn't work", seems to be either q QGroupdbusaction or of the service handling the dbus call, investigate
[10:00] <mzanetti> tsdgeos: yeah... would make sense
[10:00] <tsdgeos> mzanetti: you do it? or want me to?
[10:00] <mzanetti> tsdgeos: and we need a bug for the volume indicator tab not updating when the volume changes somewhere else
[10:01] <mzanetti> tsdgeos: feel free :)
[10:06] <luv> mardy: but indeed, this is something that should be discussed with gnome-keyring team (unfortunately, gnome devs are bit peculiar when it comes to discussing stuff with outsiders ;-) ), so back to UOA talk ... If signon_identity_signout should remove the credentials from db - what is the difference between signon_identity_signout and signon_identity_remove then?
[10:07] <mardy> luv: _signout() only removes the password and the tokens, not all the metadata -- that is, the Identity record still remains valid
[10:07] <mardy> luv: _remove() removed the record completely, which means a new record has to be stored
[10:07] <mardy> for the accounts to work
[10:07] <luv> good
[10:08] <mardy> luv: please try to see if that removes all the records from the keyring -- if not, please file a bug
[10:09] <luv> mardy: cool, thanks a lot!
[10:09] <mardy> luv: back to the keyring issue: you should never lend the PC to someone else while you are logged in; Ubuntu has the "guest user" session exactly for that reason
[10:10] <luv> mardy: yeah, that's what the gnome guys will say
[10:10] <luv> it's just a cheap excuse - not how the real world works
[10:11] <mardy> luv: true, but it's just because users are not careful about security
[10:11] <seb128> if you give access to somebody to your session you either trust the person or don't care about giving access to the datas available there
[10:12] <mardy> luv: it's not just passwords, think of all your pictures, e-mails, documents; there might be plenty of stuff you don't want to share, other than passwords
[10:12] <luv> well I know they WON'T be able to see my password saved in firefox password manager (even though they will be able to use them from that session) ...
[10:13] <seb128> how not? it's an option in firefox preferences
[10:13] <luv> because firefox ask for the master password again(!) when you ask it to show you the password decrypted
[10:13] <mardy> luv: setting the master password is not mandatory -- I for instance don't have one
[10:13] <seb128> "display password"
[10:14] <luv> yes, if you use a master password, it differentiates the two different kinds of access to the keyring
[10:15] <luv> seb128: click it and it asks for your master password (if you use one)
[10:18] <seb128> luv, dunno what "master password" is and I guess I don't use one because it doesn't ask for anything
[10:18] <seb128> luv, so it's similar to the "set a keyring password different from your login password", it applies to few people who know/care enough to do opt in
[10:19] <tsdgeos> mzanetti: https://bugs.launchpad.net/unity/+bug/1169127
[10:21] <luv> seb128: 1) almost everyone cares about it - people just don't know how easy it is to get in - so they blindly trust developers (and it's our job not to screw up). And nah, even if you set different password then your login it won't crack it! The moment you enter that different password to be used (for example by signond) it is unlocked and you do not need to enter it again to see the passwords. When using firefox you would need to ente
[10:22] <seb128> luv, IRC cut after "When using firefox you would need to ente"
[10:22] <luv> "When using firefox you would need to enter it again"
[10:22] <luv> i can make you a video of the difference when i get back home :-)
[10:22] <seb128> luv, but my point is that almost no user will know about the firefox master password or optin for one, so in practice if you hand your session to somebody you hand your firefox passwords
[10:22] <luv> umm
[10:22] <seb128> luv, no need of a video
[10:23] <luv> i think firefox asks actually
[10:23] <seb128> it ask "are you sure you want to display the passwords"
[10:23] <seb128> yes/no
[10:23] <seb128> but that's it
[10:23] <luv> no i mean
[10:23] <mzanetti> tsdgeos: confirmed
[10:24] <luv> first time you ask firefox to save a password, it tells you the implications of using a password manager (AFAIK)
[10:26] <luv> well it doesn't ask for the master password because you don't use one (I do use one for gnome keyring altough it's same as my login password - it really makes no difference). Just think of being able to see your linux password decrypted easily after you log in.
[10:26] <luv> and then saying - oh well, that's how it is, you need to lock your screen everytime - same thing
[10:27] <luv> and think of all the security vulnerabilities which can get access to your account etc.
[10:28] <seb128> if somebody has access to your unlocked session, you loose
[10:28] <seb128> they can access your private documents
[10:28] <seb128> your emails
[10:29] <seb128> the websites you are logged on
[10:29] <luv> no tehy cant :-)
[10:29] <seb128> your im logs
[10:29] <seb128> etc
[10:30] <luv> they can't access my emails, neither im log - they would have to get access to my google account as well ;-) ... they can access only local files which which the local user have access to
[10:30] <luv> maybe mess with a key logger or something
[10:30] <luv> but that's completely different league
[10:30] <seb128> you tweak your setup, which is fine
[10:31] <seb128> but you said earlier than you want to solve the issue for all users
[10:31] <seb128> on a normal config your IM logs are in empathy->log
[10:31] <luv> ok good
[10:31] <seb128> and they are not password protected
[10:31] <luv> forget it
[10:31] <tsdgeos> mzanetti: you said something about " and we need a bug for the volume indicator tab not updating when the volume changes somewhere else"
[10:31] <tsdgeos> that works here
[10:31] <luv> leave it completely open, fine :-)
[10:31] <tsdgeos> mzanetti: what do you do to repro it?
[10:32] <luv> hell, that's the original motivation to implemented the logout functionality ffs
[10:32] <mzanetti> tsdgeos: change it in alsamixer
[10:32] <tsdgeos> that doesn't seem like a supported usecase :D
[10:32] <mzanetti> tsdgeos: dafuq... that doesn't work in Overview any more either
[10:32] <mzanetti> tsdgeos: it does work on desktop
[10:32] <tsdgeos> sure
[10:32] <luv> that I can see I'm logged in into my google account so I _know_ that the computer has access to it, so when I let anyone else use the computer I f*king log out (as I do with email) and as anyone with half-brain understands
[10:33] <seb128> luv, well, the base line is "don't give access to an unlocked device/session to somebody you don't trust" in any case, you can improve things sure but that's not a proper security
[10:33] <tsdgeos> mzanetti: i'll let you file that one :-)
[10:33] <mzanetti> tsdgeos: ok
[10:35] <luv> seb128: let's add a showpass command which will show your linux password decrypted after you log in (maybe a bit of pam hacking?)
[10:35] <luv> passwords are really a different beast than emails and im logs
[10:36] <luv> and should be protected (they plain text version) even if you have access to an unlocked device
[10:37] <luv> (that's why I never use google account with android afterall - even though android doesnt go that far to show you your google password in plain text either!)
[10:37] <seb128> they are indeed
[10:37] <seb128> it still doesn't mean it's a good idea to hand an unlocked session to somebody you don't trust ;-)
[10:38] <luv> and Im telling you - most people would do same if they knew how weak the security really is :'(
[10:38] <luv> oh, of course, no disagreement there! it's absolutely not a good idea :-)
[10:38] <tsdgeos> mzanetti: quick one, https://code.launchpad.net/~aacid/unity/2many_regexps/+merge/158881
[10:39] <mzanetti> tsdgeos: lol... you should remove the others too
[10:39] <tsdgeos> mzanetti: which others?
[10:39] <mzanetti> tsdgeos: just joking... (not a big fan of boost)
[10:40] <seb128> luv, btw there is work ongoing around the keyring: https://blueprints.launchpad.net/ubuntu/+spec/security-r-app-keyring
[10:40] <tsdgeos> mzanetti: ah
[10:40] <luv> seb128: cool, I hope that's get sorted soon
[10:40] <luv> makes me really upset at the moment :-(
[10:41] <seb128> luv, the security team is working hard on apps isolation atm, hopefully we see good progresses in the next monthes
[10:43] <kgunn> mornin'
[10:44] <mzanetti> hey kgunn
[10:44] <mzanetti> good morning
[10:44] <luv> seb128: umm, great! you think the patches can make it upstream or is that ubuntu only? (not that it matters that much to me ;-) )
[10:45] <luv> it's unfortunate it didn't make it to raring. But totally ok, given how my deadlines end up ;-).
[10:54] <seb128> luv, I'm not sure how much of that will be taken upstream, I guess the code to restrict access should be upstreamable, not sure about the profiles since those are centered on apparmor and not all distributions use it
[11:00] <luv> well, let's see how it turns out ... umm according to the document the funcionality used to be there and was removed :-S
[11:19] <mzanetti> Saviq: I just checked out the *FilterGrids... seems like reusing tst_FilterGrid is not an option. you think its still worth to add tests given that they just use FilterGrid + Tile and both of them are tested already
[11:19] <mzanetti> ?
[11:20] <mzanetti> Saviq: ok... they define a clicked signal... that can be tested... I'll create something
[11:24] <didrocks> fginther: ok to me to kill every old autopilot jobs which are != from generic?
[11:37] <sil2100> didrocks: https://code.launchpad.net/~sil2100/qtubuntu-sensors/arch_change_to_list/+merge/158892
[11:37] <sil2100> didrocks: should I also remove the any bit from platform-api package?
[11:37] <sil2100> Since it currently builds for powerpc as well
[11:39] <didrocks> sil2100: qtubuntu-sensors is the only one which doesn't build, right? https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+packages
[11:39] <sil2100> Yes, that's why I'm asking abotu tplatform-api
[11:39] <sil2100> Since maybe we want to get rid of powerpc at all :>
[11:40] <sil2100> (saving disk space and everything)
[11:40] <didrocks> sil2100: no, keep any for those
[11:40] <didrocks> sil2100: no need to constrain when it's not needed (especially the day we are going to add one more arch)
[11:41] <sil2100> Ok ;)
[11:43] <dandrader> Saviq, Would you have time to check this one? It's been around for a while now: https://code.launchpad.net/~dandrader/unity/phablet_remove_fakes_from_qml/+merge/158370
[11:44] <dandrader> I wonder why jenkins didn't build it again
[12:01] <dandrader> also the "close apps from the dash" relies on that MR
[12:12] <Saviq> dandrader, yeah, I will
[12:12] <Saviq> mzanetti, why not an option?
[12:13] <Saviq> mzanetti, could we not build the FilterGrid test so that it would take them all in order and test?
[12:13] <dandrader> Saviq, thanks!
[12:16] <Saviq> kgunn, where from did you get that the UShape mounts and bottom bars are DONE?
[12:17] <Saviq> kgunn, loicm assigned it to himself, but it doesn't seem INPROGRESS yet, even
[12:17] <kgunn> Saviq: sorry, he emailed me...
[12:17] <Saviq> kgunn, that's fine
[12:17] <Saviq> kgunn, just asking
[12:18] <kgunn> Saviq: but fair question...."what is done"....i better check its all landed
[12:21] <smspillaz> didrocks: heya, do you know if jenkins jobs automatically time out if they take too long ?
[12:21] <smspillaz> fginther: ^ might know the answer to that one too
[12:21] <smspillaz> (sorry for the ping!)
[12:24] <didrocks> smspillaz: fginther will know better than I
[12:25] <smspillaz> coolio, we shall see then
[12:26] <smspillaz> if not, its pretty easy to pass a flag to ctest to force tests that take longer than 60 seconds to fail, we're just hitting a condition in the xorg gtests in compiz that times out after 3000ms, and sometimes running under valgrind hits that
[12:26] <smspillaz> so I was just going to get rid of that 3000ms timeout since its not really useful for getting rid of long-running tests
[12:34] <sil2100> didrocks: where would you put the qtubuntu-camera* bits in the stack? It was in the qt stack in phablet, I added it to platform for now - but you think it's the right place?
[12:34] <sil2100> Maybe media?
[12:34] <sil2100> But it's a backend
[12:39] <vesar> I'm trying to build unity (./build -s)  but it keeps failing in: [ 79%] Building C object tests/CMakeFiles/test-voice.dir/test-voice.c.o
[12:39] <vesar> Linking C executable test-voice.
[12:40] <vesar> Anybody any idea how to fix? The log is the same as here: http://pastebin.com/bND2DCbj
[12:44] <didrocks> sil2100: I guess it's in the media one
[12:44] <didrocks> sil2100: look for the google doc from stacks
[12:50] <vesar> Saviq, any idea^
[12:51] <Saviq> vesar, that looks like the hud is failing
[12:51] <Saviq> vesar, try ./build_unity --clean
[12:51] <Saviq> vesar, that will build the whole set in ../unity_build/ from scratch
[12:51] <Saviq> vesar, you updated to raring, btw?
[12:52] <vesar> Saviq, no I still have 12.10 64-bit
[12:52] <Saviq> vesar, you should upgrade to raring, we will soon stop caring about quantal
[12:52] <vesar> Saviq, ok. good to know. but can that cause the issue?
[12:53] <Saviq> vesar, it could, in theory (/me tries to build in quantal)
[12:56] <fginther> smspillaz, nearly all of our jenkins ci and autolanding jobs are set to timeout. A few old jobs do not, but they will eventually be fixed.
[12:57] <smspillaz> fginther: great, thanks!
[13:13] <vesar> Saviq, got a confirmation from Albert that doesn't work in quantal anymore.
[13:14] <Saviq> tsdgeos, what would we need to do for it to work?
[13:15] <tsdgeos> Saviq: probably comment out the tests
[13:15] <tsdgeos> is what i think that fails linking
[13:15] <tsdgeos> Saviq: maybe even we can trigger that on the cmake "call" level
[13:16] <Saviq> tsdgeos, right
[13:16]  * Saviq will try
[13:16] <tsdgeos> Saviq: otherwise it's hard since we are targetting a given revision on the repo so even if we fix it later won't be able to use that revision since it introduces the hud-client2 lib
[13:16] <Saviq> tsdgeos, we can always have an lp:hud/phablet branch ;)
[13:17] <tsdgeos> sure
[13:17] <tsdgeos> actually it's the branch we are using :D
[13:17] <tsdgeos> it's called phablet already
[13:17] <tsdgeos> :D
[13:17] <Saviq> right ;)
[13:24] <mterry> sil2100, the last unity raring build had too many failures from autopilot tests on nvidia.  I'm rerunning the job just to see if it was a fluke, but do any of the failures here make sense to you: http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/64/label=autopilot-nvidia/testReport/ ?
[13:32] <Saviq> dednick_, standup?
[13:38] <mterry> sil2100, you don't hang out in #ubuntu-touch?
[13:41] <Saviq> vesar, I'll have a fix for you in 5
[13:42] <vesar> Saviq, ok. cool. Though I think I should upgrade to raring
[13:42] <Saviq> vesar, yeah
[13:54] <sil2100> mterry: ok, so, as I mentioned in the qtvideo-node, it looks all fine - I had problems building with earlier package versions, but I think it shouldn't be a problem?
[13:54] <sil2100> (i.e. missing minimum versions of libplatform-api-headers etc.)
[13:55] <mterry> sil2100, yeah.  I wasn't too worried about it because I didn't want to include versions that had the daily.build.next string; once we actually have these packages in the ubuntu-unity/next ppa it might make more sense to add versions
[13:56] <mterry> sil2100, but that merge failed because of the missing deps in the cu2d-config stack, eh?
[13:58] <Saviq> tsdgeos, vesar https://code.launchpad.net/~saviq/unity/phablet.disable-hud-tests_add-regex-dep/+merge/158928
[13:58] <sil2100> mterry: yes, in the same way it happened on my system
[13:58] <sil2100> i.e. libplatform-api-headers not new enough
[13:59] <sil2100> Should we merge it in anyway?
[13:59] <mterry> sil2100, no...?  let me look at the console log again
[13:59] <sil2100> shadervideomaterial.cpp:17:30: fatal error: ubuntu/ui/config.h: No such file or directory
[13:59] <mterry> sil2100, oh right!
[13:59] <sil2100> ubuntu/ui/config.h is from libplatform-api-headers - at least the https://jenkins.qa.ubuntu.com/job/qtvideo-node-raring-armhf-ci/5/console job!
[13:59] <mterry> sil2100, this is because https://code.launchpad.net/~mterry/cupstream2distro-config/videonode/+merge/158408 hasn't landed
[13:59] <mterry> sil2100, the -ci job is still using old phablet branch
[14:00] <sil2100> Ah ;)
[14:00] <sil2100> brrrr
[14:00] <tsdgeos> Saviq: ok, going to take a while to get the quantal machine up
[14:00] <sil2100> Things are getting out of hand slowly! Ok, so first let's get this merged in
[14:00] <Saviq> tsdgeos, should've kept a clean snapshot ;)
[14:00] <tsdgeos> i do
[14:00] <tsdgeos> just cloning takes a while
[14:00] <tsdgeos> no ssd here
[14:01] <tsdgeos> a while ~10 min
[14:01] <mterry> sil2100, can we kick jenkins-bot to check for the commit message again?
[14:01] <Saviq> tsdgeos, why cloning? just snapshot, work, drop the changes?
[14:01] <tsdgeos> can virtualbox do that?
[14:01] <Saviq> tsdgeos, yeah
[14:01] <sil2100> mterry: I think if we trigger a rebuild it should re-check it (I think)
[14:01] <sil2100> Doing that
[14:01] <mterry> sil2100, thanks
[14:02] <Saviq> tsdgeos, you can even have multiple trees of snapshots now
[14:02] <tsdgeos> Saviq: interesting, i'll investigate later
[14:02] <Saviq> tsdgeos, cheers
[14:02] <mterry> sil2100, still though, we need to add the autopilot deps to the stack configs.  The stacks are failing to pass checks because of that.  Do you know what I mean by that?  (the stack configs list all the deps of the autopilot packages explicitly)
[14:02] <tsdgeos> i think for this time it's going to be faster just to clone :D
[14:03] <mterry> sil2100, I was going to have a look at that if you hadn't started
[14:03] <sil2100> mterry: yes, I had a hangout about that with Didier today
[14:03] <sil2100> mterry: I'm taking that one on me, just wanted to finish those small tasks first
[14:03] <mterry> sil2100, OK cool, thanks
[14:05] <vesar> Saviq, thanks!
[14:22] <mterry> fginther, in the qtvideo-node branch, the dropping of quantal was intentional
[14:22] <mterry> fginther, the head stacks are raring-only
[14:23] <sil2100> fginther: pushed the modified version of https://code.launchpad.net/~sil2100/cupstream2distro-config/android-audiosystem_add/+merge/158806
[14:23] <sil2100> mterry: you're handling the addition of qtvideo-node to the head stack, yes?
[14:26]  * fginther is thinking
[14:26] <sil2100> To anyone concerned - once we have all camera* branches ready, here's the stack addition: https://code.launchpad.net/~sil2100/cupstream2distro-config/qtubuntu_camera_additions/+merge/158931
[14:26] <sil2100> (so that there's no work duplication)
[14:26] <sil2100> Probably some fixing will be needed later
[14:27] <mterry> sil2100, trying
[14:27] <Cimi> dednick_, so basically from Lens I need searchQuery and name
[14:27] <sil2100> mterry: ACK
[14:27] <Cimi> dednick_, so I'll need to add some methods right?
[14:28] <Cimi> dednick_, one get method for name, a write and get method for searchquery, and a q signal each
[14:28] <dednick_> Cimi: yah. might want to separate the lens into a different source file as well. i just put it in with the lenses to save time.
[14:28] <dednick_> Cimi: think you need to add Q_PROPERTY for each
[14:29] <Cimi> dednick_, yeah exactly
[14:29] <Cimi> dednick_, was implying the property
[14:29] <dednick_> Cimi: ok :)
[14:29] <Cimi> dednick_, shall I push there once I move into a new file?
[14:31] <dednick_> Cimi: please
[14:31] <Cimi> ok
[14:36] <mzanetti> hey Cimi. wanna do a review? https://code.launchpad.net/~mzanetti/unity/phablet-test-filtergrids/+merge/158941
[14:39] <smspillaz> Trevinho: heya, do you happen to know if there's any udev events for VT switches ?
[14:46] <Trevinho> smspillaz: no, I've looked a little into it at the time, then we got a different solution..
[14:47] <Trevinho> smspillaz: platform guys could be more aware than me, though :)
[14:47] <smspillaz> Trevinho: I haven't found anything thus far
[14:48] <smspillaz> Trevinho: if we don't really care about VT switching, we can just try to handle the resume case
[14:48] <smspillaz> https://code.launchpad.net/~jassmith/unity/unity.redraw-on-resume/+merge/95945 does it for the launcher, should we just expand that to the rest of the shell ?
[14:48] <Trevinho> smspillaz: that was handled using upower signals
[14:48] <Trevinho> smspillaz: however it was not fixing things that well
[14:48] <smspillaz> Trevinho: the problem is that its the best we've got -.-
[14:49] <Trevinho> smspillaz: ok, if that's fixing for everything I think we can accept it
[14:49] <smspillaz> I'll look into hooking those bits up
[14:50] <smspillaz> Trevinho: Actually, now that I think of it, it might be better to connect to the screensaver daemon and listen for unlocks
[14:50] <smspillaz> as well as resume from suspend
[14:50] <smspillaz> the reason being that I suspect the reason it didn't work so well was a race condition between us getting the signal and the driver trashing the framebuffers
[14:51] <smspillaz> listening for unlocks on the screensaver service at least guaruntees us that we're going to do a redraw when the user has typed in their pw
[14:51] <Trevinho> smspillaz: the problem with that was that it didn't work when user was disabling the lock-screen
[14:52] <Trevinho> smspillaz: and OEMs want to support that as well
[14:54] <smspillaz> Trevinho: right, so I was thinking of putting the redraw code on a timeout (5 seconds will do) and then for all other cases the lock screen signal should handle it
[14:54] <smspillaz> Trevinho: its just a race condition really, there's not a whole lot we can do about it
[14:55] <smspillaz> better yet, we can probably do it after the first swap after resume
[14:56] <smspillaz> so resume -> first swap -> QueueDraw everything
[15:13] <tsdgeos> Saviq: what's the policy regarding new merges that introduce FIXMEs like https://code.launchpad.net/~nick-dedekind/unity/phablet-tests-menucontent/+merge/158562 ? Should we update the FIXME list? or?
[15:13] <Saviq> tsdgeos, good point
[15:14] <Saviq> tsdgeos, yeah, I'd say that's right
[15:14] <Saviq> tsdgeos, fortunately they won't get lost, but makes sense to add them to the list, yes
[15:14] <tsdgeos> oki
[15:24] <smspillaz> Trevinho: is there a way that I can tell nux "just QueueDraw everything" or do I need to expose a new method in WindowCompositor to do that ?
[15:26] <Trevinho> smspillaz: maybe at this point it's just better to include that into WindowCompositor, and using it in compizDamageNux as well
[15:26] <Trevinho> smspillaz: as there's not...
[15:26] <smspillaz> Trevinho: well, I'm poking around a bit to see what there is
[15:26] <smspillaz> there's "Draw" with "force_draw" dunno if that refers to the content or the presentation stage
[15:27]  * smspillaz would like to avoid breaking its encapsulation if possible
[15:32] <dandrader> Saviq, updated https://code.launchpad.net/~dandrader/unity/phablet_remove_fakes_from_qml/+merge/158370. I bet something got merged in the meantime disabling use of "signals" keyword by Qt.
[15:33] <Saviq> dandrader, if it wasn't before, it should've been ;)
[15:33] <Saviq> dandrader, but yeah, we're doing -DQT_NO_KEYWORDS for compatibility reasons
[15:35] <Saviq> dandrader, s/emit/Q_EMIT/, too
[15:39] <dandrader> Saviq, done
[15:42] <smspillaz> Trevinho: okay, just rebuilding nux now to give that a try
[15:59] <Saviq> tvoss, do we have html of the development guidelines published somewhere?
[16:47] <tvoss> Saviq, nope, moved it to the top of my list
[16:50] <sil2100> fginther: is it ok now? https://code.launchpad.net/~sil2100/cupstream2distro-config/android-audiosystem_add/+merge/158806
[16:51] <fginther> sil2100, sorry, got sucked into something else. I'll take a look now
[16:52] <mhall119> tvoss: ping
[16:53] <mhall119> tvoss: when is Unity Next development going to become our main focus, will that happen before the client sprint, or afteR?
[16:54] <tvoss> mhall119, I think we are already focusing it :) but best to ask kgunn and Saviq for concrete timelines
[17:06] <didrocks> mhall119: tvoss: it will be in the distro during June
[17:07] <kgunn> mhall119: its actually our main development focus now
[17:18] <mhall119> kgunn: good to hear!  So my next question is, what can I to do get more people in the community actively involved in it's development?
[17:19] <kgunn> mhall119: actually, for low hanging fruit fixme/todos
[17:20] <kgunn> mhall119: in this bp https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-iteration-0
[17:20] <kgunn> mhall119: there is a link to a google doc (completely public)
[17:20] <kgunn> mhall119: which has a list of the todos/fixmes in the code that need to be addressed
[17:21] <kgunn> mhall119: and some estimate of difficulty etc
[17:21] <seb128> mterry, didrocks: http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/label=autopilot-intel/68/artifact/results/artifacts/unity.tests.launcher.test_keynav.LauncherKeyNavTests.test_alt_f1_closes_hud%20%28Single%20Monitor%29.ogv
[17:21] <seb128> sil2100, ^
[17:21] <seb128> from the last buggy run
[17:21] <seb128> screen is locked!
[17:22] <didrocks> seb128: let me restate… "it's all your fault"
[17:22] <didrocks> :p
[17:22] <seb128> he
[17:22] <seb128> we have an inhibit api
[17:22] <seb128> it's made to be used :p
[17:22] <mhall119> kgunn: do we have any documentation on the code layout, different components and what they do, what functionality is implemented where, etc?  Something to give new developers a understanding of the codebase as a whole?
[17:22] <didrocks> seb128: tssss, that's overrated ;)
[17:23] <didrocks> sil2100: thomi: is there a way that autopilot in his setup have something to launch the inhibit api for avoiding screenlocking when using autopilot?
[17:24] <kgunn> mhall119: not really, its been in flux lately....but starting to settle....and since most of its qml....its not hard to figure out whats what
[17:25] <Saviq> tvoss, thanks, I have a QML set in the works, but it's still some work away
[17:26] <sil2100> didrocks, seb128: not sure, since I never used the inhibit API, would have to check how it's done
[17:26] <Saviq> mhall119, yeah, we try to name the components after what they are
[17:26] <didrocks> sil2100: quite easy, I have a small snippet
[17:26] <Saviq> mhall119, and we are here all the time if people have questions
[17:26] <Saviq> or try to be
[17:26] <didrocks> sil2100: http://paste.ubuntu.com/5710940/
[17:27] <didrocks> sil2100: see test_inhibit()
[17:28] <tvoss> Saviq, let's sync tomorrow on that topic
[17:28] <Saviq> tvoss, k
[17:28] <didrocks> sil2100: but I think this need to be at the autopilot level, like a facility
[17:28] <didrocks> and called at the start of autopilot
[17:29] <sil2100> didrocks: thanks! Let me test something in Ap
[17:29] <didrocks> thanks ;)
[17:30] <didrocks> seb128: good catch!
[17:30] <seb128> didrocks, thanks ;-)
[17:33] <agrester> Got a quick question, I used to be able to maximize a window and it would hide the controls and title-bar in the panel which was awesome but now using 13.04 for some reason the window no longer maximizes normally, is there a setting for this?
[17:36] <seb128> didrocks, sil2100: other (easier) option, could be to "gsettings set org.gnome.desktop.lockdown disable-lock-screen true"
[17:36] <seb128> that's what we do in e.g the guest session
[17:36] <didrocks> sounds good to me :)
[17:37] <sil2100> Ok, we'll do that if this will be too troublesome anyway
[17:57] <mhall119> Saviq: kgunn: thanks
[18:01] <sil2100> Man, AP killed my system so many times...
[18:07] <sil2100> https://code.launchpad.net/~sil2100/unity/autopilot_disable_screen_lock/+merge/158989
[18:32] <sil2100> mterry: regarding https://code.launchpad.net/~mterry/qtvideo-node/arches/+merge/158405
[18:32] <sil2100> Soo...
[18:32] <sil2100> mterry: we get a failure on quantal since there is no new libplatform-api-headers etc. available on quantal
[18:33] <sil2100> mterry: and as you already know, we can't disable it in CI
[18:33] <sil2100> So what I'm proposing:
[18:33] <sil2100> We could merge it in as it is, but then every merge would fail CI on trunk there, so I would propose to push a new libplatform-api-headers package for quantal to the daily-next PPA
[18:34] <sil2100> Same for libhybris (since I think this one also was problematic)
[18:34] <sil2100> mterry: this way CI would pull the new packages and not fail on quantal anymore - what do you think?
[18:35] <mterry> sil2100, we need to just run the daily job again after changing the config to support quantal
[18:35] <mterry> sil2100, that way the new platform-api will be in the ppa for quantal
[18:40] <sil2100> mterry: awesome
[18:41] <sil2100> mterry: will you take care of it?
[18:41] <mterry> sil2100, I think fginther said he was going to do that
[18:41] <mterry> I mean, change the config to support quantal
[18:42] <sil2100> mterry, fginther: thanks guys
[18:46] <fginther> mterry, I'd like a clarification.  'new platform-api will be in the ppa for quantal' what ppa are you referring to?
[18:47] <mterry> fginther, I'm talking about daily-next
[18:47] <mterry> Once we enable quantal for it
[18:51] <fginther> mterry, are you aware that daily-next is not used for building CI?
[18:56] <mterry> fginther, I guess not...   :)  Doh.  What PPA do we use for CI?
[18:57] <fginther> mterry, it can vary per project, but for qtvideo-node, it's usingqt5-proper and phablet-team-ppa
[18:57] <fginther> mterry, we can change that, but I didn't want you to spend a lot of effort in supporting something that we may not be using w/o more changes
[18:59] <mterry> fginther, where is that specified?
[19:00] <fginther> mterry, by the "hooks" line
[19:00] <mterry> fginther, but we just landed my merge today that changed that
[19:00] <mterry> fginther, moved it into head/media.cfg
[19:01] <fginther> mterry, and I'm adding those back in my update
[19:02] <mterry> fginther, ah... but why drop daily-next from the list of PPAs when doing CI?
[19:04] <fginther> mterry, we don't drop it. Our CI tools just don't know to look at those 'ppa' and 'dest' values yet.
[19:05] <mterry> fginther, oh.  Huh.  So can we have a global hook that adds the daily-build-next PPA?  It seems like that should be used for CI
[19:05] <mterry> For raring, I'd like the daily-build-next PPA to be self-sufficient (i.e. build without other PPAs)
[19:05] <mterry> I understand that for quantal, we'll need to have more stuff in there
[19:05] <fginther> mterry, yes, we need to figure out a way to do that and add it
[19:05] <mterry> But even then, we could just put it into the daily-build-next PPA like we've done in raring
[19:05] <fginther> there may even be a bug, let me look
[19:06] <mterry> I'd like to not add the phablet PPA if possible
[19:09] <fginther> mterry, I understand, let me try and address the ppa issue first. We haven't yet deployed these changes in the media.cfg, so the old ci jobs will continue to work for the time being (I know that doesn't help your qtvideo MP)
[19:10] <fginther> mterry, do we need to add both "ppa: ubuntu-unity/daily-build-next" and "dest: ubuntu-unity/next" when building CI jobs?
[19:12] <mterry> fginther, CI jobs don't have a dest, right?
[19:12] <fginther> mterry, I simply don't know the purpose of those two PPAs
[19:12] <fginther> mterry, we just need a source to pull in deps
[19:13] <mterry> fginther, daily-build-next is pre-validation.  Dest is final, validated result.  For example, for the raring stack, the dest is raring I believe
[19:13] <mterry> fginther, for pulling in deps, daily-build-next is your ppa
[19:17] <fginther> mterry, thx
[19:18] <kgunn> Saviq: wondering, we may have missed 2 items on indicators
[19:19] <kgunn> Saviq: "account settings" & cell radio
[19:19] <Saviq> kgunn, at least cell radio is supposed to be handled by the network indicator
[19:20] <kgunn> Saviq: that makes sense
[19:20] <Saviq> kgunn, and by account settings you mean?
[19:20] <kgunn> Saviq: account settings i suppose is the little fluffy cloud on my desktop panel
[19:20] <Saviq> that's sync
[19:20] <Saviq> I think we have that covered
[19:21] <kgunn> Saviq: you are right we do....looking at Seb's list
[19:21] <kgunn> Saviq: he called it account settings...i dont see a sync
[19:21] <Saviq> kgunn, line 41 in the draft monthly plan
[19:22] <kgunn> Saviq: right...if you look at the "services" tab....there is basically a duplicated structure that Jason & Seb are working on
[19:23] <Saviq> kgunn, indeed
[19:23] <Saviq> kgunn, so they're mostly stepping on thostr's toes rather than ours
[19:24] <Saviq> kgunn, and also I'm not sure indicators [19:24] <Saviq> or rather I expect settings(indicators)
[19:25] <kgunn> Saviq: sure...they are different, yet linked
[19:25] <Saviq> kgunn, yeah, I expect indicators to be a view into a subset of settings
[19:32] <Saviq> kgunn, that's not to say we should ignore them, not at all
[19:33] <Saviq> kgunn, at the very least we should look at the commonalities between them (will the indicators really be a subset of settings when it comes to used widgets, for example? how do we share them?)
[19:33] <kgunn> Saviq: i'm putting a note in on their page for when we think panel ui & backend are done
[19:33] <kgunn> on the month2month
[19:34] <Saviq> kgunn, but I haven't seen indicators designs even as rudimentary as those on the mentioned wiki
[23:33] <smspillaz> slangasek: hey, still around? Thanks for the review, I'll deal with the easy bits though if you're around I can deal with some of the more complicated bits over IRC