[06:56] <dholbach> good morning
[06:56] <nhaines> dobey: good morning.  :)
[07:54] <Chipaca> is the latest devel-proposed half baked wrt developer mode?
[08:23] <mpt> How do I take a screenshot?
[08:27] <ogra_> mpt, using phablet-screenshot
[08:28] <mpt> ogra_, thanks. But I get “remote object '/tmp/mir_screencast_768x1280.rgba' does not exist”
[08:29] <ogra_> mpt, looks like you use an ancient phablet-screenshot version
[08:29] <ogra_> (upgrade to the latest phablet-tools package)
[08:29] <mpt> phablet-tools | 1.0+14.04.20140416-0ubuntu1 | http://gb.archive.ubuntu.com/ubuntu/ trusty/universe i386 Packages
[08:30] <ogra_> heh, we dont update the distro version, use the PPA (as advised) ...
[08:30] <ogra_> that would be way to many SRUs ;)
[08:30] <Hendrik_> How do i debug the apn being used by the phone or ofono completely?
[08:32] <mpt> ogra_, is it this one? https://launchpad.net/~phablet-team/+archive/ubuntu/tools
[08:32] <ogra_> yeah :)
[08:35] <Chipaca> i seem to be stuck in r169; no adb, and going the --bootstrap route bails with “Cannot cleanup /cache/recovery/ to ensure clean deploymentexit status 255”. Ideas?
[08:36] <jgdx> Chipaca, I've seen that a couple of times and every time it's a rw issue. maybe try phablet-config writable-image
[08:36] <Chipaca> jgdx: no adb
[08:36] <jgdx> ah
[08:37] <Chipaca> yeah
[08:37] <jgdx> adb restart?
[08:38] <Chipaca> jgdx: no adb
[08:38] <Chipaca> and it's adb reboot anyway :)
[08:38] <jgdx> as in the serice
[08:39] <jgdx> service adb
[08:39] <Chipaca> ah
[08:39]  * Chipaca tries
[08:40] <Chipaca> jgdx: unknown job 'adb'
[08:41] <Chipaca> not adbd either
[08:41] <jgdx> Chipaca, $ adb kill-server; adb start-server
[08:41]  * Chipaca tries
[08:41] <Chipaca> jgdx: adb: command not found
[08:42] <Chipaca> adbd
[08:42] <Chipaca> exists
[08:42]  * Chipaca tries with that
[08:43] <Chipaca> jgdx: or do you mean on the desktop
[08:44] <jgdx> Chipaca, sorry, on the desktop
[08:45] <Chipaca> jgdx: still 'no devices'
[08:45] <Chipaca> seb128: ping
[08:46] <seb128> Chipaca, hey
[08:46] <Chipaca> seb128: morning!
[08:46] <seb128> good morning to you ;è)
[08:46] <seb128> ;-)
[08:46] <Chipaca> seb128: i've got the three packages related to the notifications settings in a ppa
[08:46] <seb128> I saw that (well, the was some build issue earlier when I looked)
[08:47] <Chipaca> seb128: that's now fixed :)
[08:47] <seb128> nice
[08:47] <seb128> did you address the schemas review comment as well?
[08:47] <Chipaca> seb128: I was going to try to test, but my phone is being uncooperative. The latest changes were because of issues i found in the first round of testing on the device
[08:47] <Chipaca> seb128: yes, tvoss suggested something which we implemented across the board
[08:48] <jibel> hi, could someone have a look at bug 1351308
[08:48] <Chipaca> that is, in the four related branches across the three packages
[08:48] <seb128> Chipaca, my review comment was like 5 hours ago
[08:48] <jibel> this is a regression in mako build #163
[08:48] <Chipaca> seb128: ah, i didn't see that, where did you comment?
[08:49] <seb128> Chipaca, https://code.launchpad.net/~chipaca/gsettings-ubuntu-touch-schemas/just-the-touch-settings/+merge/228317
[08:50] <Chipaca> Laney: I know it's not usual to make changes after getting approval, but the approval you gave was removed by seb; our changes were after that
[08:51] <Chipaca> seb128: I don't understand
[08:51] <Chipaca> seb128: we were using 'postal', which you thought was bad because it being 'postal' was an implementation detail
[08:51] <Chipaca> seb128: so we changed it to be 'hub', which is a description of what it is architecturally
[08:52] <Chipaca> seb128: but you're insisting on it not having a qualifier, which i explained before is ambiguous right now and confusing in general
[08:53] <Chipaca> Laney: unless you mean the commit after tvoss's +1, which was a commit he explicitly mentions in his message prior to approval
[08:54] <Laney> Chipaca: I think it's weird that I approved one thing and now the names are quite different
[08:54] <seb128> Chipaca, is there a documentation explaining what a "hub notification" is and how it's different from a "notification"?
[08:54] <Laney> in other words it moved from one reviewer to another without input from the first one
[08:54] <seb128> Chipaca, because I don't understand what "hub" is in this context and why we need 2 types of notifications
[08:54] <Chipaca> Laney: take it up with seb128, i had nothing to do with that one
[08:54] <seb128> shrug
[08:55] <tvoss> seb128, the different is simple: a notification is something that is always shown on screen as a bubble, a hub notification is something to be interpreted according to user preferences
[08:55] <seb128> ok, I'm going to make that simple
[08:55] <Laney> On the same token, seb asked for quite a specific change
[08:55] <seb128> we use "com.ubuntu.notifications"
[08:55] <seb128> tvoss, so we have no control of bubble notifications?
[08:55] <tvoss> seb128, a com.ubuntu.Notification is a potential result of interpreting a message/notification coming into the hub
[08:55] <tvoss> seb128, we have, on a hub level
[08:55] <seb128> so why is "hub" useful in that schemas?
[08:55] <seb128> it's just control of notifications
[08:56] <seb128> the fact that the filtering is done by a hub or the apps or the shell is not relevant to the settings
[08:56] <Chipaca> um
[08:56] <Chipaca> seb128: this is not about bubbles
[08:56] <Chipaca> bubbles are one kind of notifications
[08:56] <seb128> so we call 2 different things "notifications"?
[08:56] <Chipaca> and are the kind most usually associated with something that is just called "com.ubuntu.notifications"
[08:56] <Laney> tvoss: is someone looking at https://bugs.launchpad.net/ubuntu/+source/platform-api/+bug/1350874 ?
[08:57] <tvoss> Laney, it's already fixed
[08:57] <Laney> no
[08:57] <tvoss> seb128, yes we do
[08:57] <Laney> it's not
[08:57] <Chipaca> seb128: depending on what you mean by "we", yes we do, and that's the ambiguity i pointed out and the reason we have a hub is because there are multiple ways of notifying the user
[08:57] <seb128> Chipaca, tvoss: is there a document that explain what is the difference between a bubble notification and a hub-notification?
[08:58] <tvoss> seb128, quite a few
[08:58] <seb128> is there a simple document with a summary? ;-) like something for app writers
[08:58] <seb128> e.g "you want your app to notify users in this way, do that"
[08:58] <tvoss> seb128, an app writer does not need to care about the distinction
[08:58] <seb128> listing the different possible ways
[08:59] <seb128> so why would the settings care about the distinction?
[08:59] <seb128> can't we just make that list a list of apps that opt out of notifying users?
[08:59] <Chipaca> seb128: because it is the settings for the hub?
[08:59] <seb128> and let the services use it as they want?
[08:59] <Chipaca> applications don't interact with these settings
[08:59] <Chipaca> the hub does
[08:59] <tvoss> seb128, app authors have no control ove rthe policy
[08:59] <seb128> Chipaca, oh, ok, so it should be a key "com.ubuntu.hub"
[09:00] <tvoss> it's the user deciding
[09:00] <Hendrik_> How do i debug the apn being used by the phone or ofono completely?
[09:00] <tvoss> seb128, that's too generic, we have more than one hub
[09:00] <Chipaca> seb128: it is not "the hub", it is the notifications hub, which we call the postal service
[09:00] <seb128> how is called the service reading that key?
[09:00] <Laney> laney@iota:~/temp/platform-api-2.2.0+14.10.20140801/include/ubuntu/application/ui/input$ cpp event.h | grep PointerCoordinate
[09:00] <Laney>     struct PointerCoordinate
[09:00] <Laney>                 struct PointerCoordinate
[09:00] <Laney> tvoss: ^
[09:00] <tvoss> Laney, this should have been fixed with this: http://bazaar.launchpad.net/~phablet-team/platform-api/trunk/revision/252
[09:01] <Chipaca> seb128: sorry, could you rephrase that question?
[09:01] <seb128> Chipaca, that gsettings key is going to be read by some project/codebase, which one and what is the name for that project
[09:02] <Laney> tvoss: nope, these are different files
[09:02] <Chipaca> seb128: the settings key is read by the postal service, that is currently in the ubuntu-push codebase
[09:02] <seb128> Chipaca, ok, good, so let's have ubuntu-push ship a com.ubuntu.push schemas with its config
[09:02] <Chipaca> seb128: it's emerging from ubuntu-push, but it hasn't emerged yet. At some point it might split once the boundaries and interfaces are clear
[09:03] <seb128> and use that
[09:03] <tvoss> seb128, that only signs us up for the same renaming hassle you pointed out as an issue in your review
[09:04] <seb128> tvoss, well, at least it's specific to a project and up to the maintainer of that project to handle incompatible changes/transitions
[09:04] <seb128> tvoss, by putting your key in a common schemas you make it sort of a public interface
[09:04] <tvoss> seb128, well, .hub distinguishes us and comes closer to the actual meaning of the key
[09:05] <tvoss> seb128, we are the people doing the work in both cases, so I'm not sure private/public really matters here
[09:05] <Chipaca> seb128: I guess tedg put it in the common schemas because the settings plugin is in ubuntu-system-settings?
[09:05] <seb128> it's also confusing and specific to some component/implementation
[09:05] <tvoss> seb128, it is not, it's going to be the implementation that will drive the notification experience going forward in time
[09:05] <seb128> tvoss, I just object making the common tree/namespace confusing
[09:06] <tvoss> seb128, hence why we proposed .hub, which is the new component
[09:06] <seb128> those shared keys shouldn't be linked to a specific service/implementation, they should just common info
[09:06] <seb128> like a theme
[09:06] <seb128> or a ringtone sound
[09:06] <seb128> well
[09:07] <seb128> if it's specific to a component it should live in that component namespace
[09:07] <tvoss> seb128, that would resul in ubuntu-system-settings being tied to a specific implementation ... sounds like a very bad idea
[09:08] <Chipaca> from a practical perspective, putting the schemas in ubuntu-push would mean they wouldn't get translated unless we tied up translations to ubuntu-push, which is a bit of a pain
[09:09] <seb128> do you plan to have a "com.ubuntu.notifications" at some point, and how would that be different from the ".hub" variant?
[09:09] <seb128> let me rephrase the question like that ^
[09:09] <Chipaca> seb128: i think the first time you asked me that question i answered
[09:10] <Chipaca> seb128: although we don't have a plan for that
[09:10] <Chipaca> seb128: using it would be, at this point in time, much too confusing
[09:10] <Chipaca> seb128: for people call different things "notifications"
[09:10] <Chipaca> seb128: and this would just add to the confusion
[09:10] <Laney> jibel: contact whoever did the upload?
[09:10] <seb128> ok
[09:11] <seb128> Chipaca, please give me a document I can read to understand how a hub notification is different from a bubble notification, and how those are used in what context
[09:11] <Chipaca> seb128: maybe http://developer.ubuntu.com/apps/platform/guides/push-notifications-server-guide/ ?
[09:11] <seb128> Chipaca, thanks, reading, I'm coming back to you in a bit
[09:11] <seb128> (hopefully understanding the topic better then)
[09:12] <mandel> Elleo, did you get any feedback from the media people about udm? I'll like to request a silo
[09:12] <tvoss> Laney, as far as I can tell, the offending second declaration has been removed: http://bazaar.launchpad.net/~phablet-team/platform-api/trunk/revision/252
[09:13] <seb128> Chipaca, btw my main concern about those changes is that you are working around the issue than "notifications" is used in confusing ways rather than fixing the problem by communicating on what are the different types/finding another vocabularity for the new sort
[09:13] <Laney> tvoss: the header is in include/ubuntu/application/ui/input
[09:13] <Laney> note no android
[09:14] <Laney> tvoss: you can verify yourself using the info I gave
[09:14] <tvoss> Laney, ack, then nobody has looked into it so far
[09:14] <Laney> please do ;-)
[09:14] <Laney> want to move forward soon if possible
[09:16] <Laney> and stuff failing is generally bad if we need a bug fix, not to mention to be able to reproduce the binaries in the archive
[09:17] <Chipaca> seb128: the whole thing is evolving and I think we're reasonably close to a clear and unambiguous way to communicate this, but we can't block on having the language all down pat to implement it
[09:19] <seb128> Chipaca, well, it's unfortunate that you need to a key to a shared/stable location before things settle
[09:20] <seb128> Chipaca, that's sort of why I was suggesting trying to take the key out of the shared location until it settle down/is likely to change
[09:20] <tvoss> Laney, sure, but this is nothing I have touched in a while, so I need to talk to dandrader at the very least
[09:21] <tvoss> seb128, while I can see your point, I would argue that tying system settings to an implementation-specific key is the bigger disadvantage
[09:22] <seb128> tvoss, Chipaca: what I don't get here is why the key wouldn't be a "things users don't want to be notified" about that would apply as well to push service than bubble notifications
[09:22] <seb128> like just a list of apps that the user turned off from displaying things
[09:22] <tvoss> seb128, because the hub interprets the key and decides if a bubble should be shown at all
[09:22] <tvoss> seb128, it's just a list right now, but it will become more fine-grained
[09:23] <seb128> but nothing is going to do something similar for bubbles?
[09:23] <tvoss> seb128, not sure I understand your question?
[09:23] <Chipaca> seb128: nothing gets to present bubbles directly
[09:23] <Chipaca> seb128: in the new world order
[09:23] <seb128> well, what if rb displays bubbles when track changes and I don't want it to do it
[09:23] <Chipaca> (we're not there yet)
[09:23] <tvoss> seb128, ultimately, rb will go via the hub, too
[09:23] <tvoss> not saying that that is the case right now
[09:23] <seb128> k
[09:24] <seb128> so we are back to one list
[09:24] <seb128> and we can call it .notifications then :p
[09:24] <tvoss> seb128, sorry, that's just not true
[09:24] <Chipaca> seb128: but if I call it notifications, you're going to think it's about bubbles when it isn't
[09:25] <seb128> why would I?
[09:25] <seb128> notifications is notifications
[09:25] <Chipaca> seb128: because you've gone to thinking they are bubbles 20 times since you started doing this review?
[09:25] <seb128> if our notifications are not restricted to bubbles it's fine
[09:25] <seb128> because that's what they are today
[09:25] <seb128> they could be launcher badges
[09:25] <Chipaca> today, they are most certainly not
[09:25] <seb128> or in app baners
[09:25] <seb128> or sound
[09:26] <seb128> on desktop they are
[09:26] <tvoss> seb128, desktop is not the focus here, although it will be powered by the same infrastructure going forward in time
[09:26] <seb128> tvoss, I know, but we want something that works for a converged world
[09:26] <tvoss> seb128, right, that's why we argue for .hub
[09:26] <seb128> so I'm trying to make sure we define things in a way that is going to work for everyone
[09:27] <seb128> k
[09:27] <tvoss> seb128, sure, so do we. the desktop will inevitably change
[09:27] <tvoss> seb128, so introducing a .hub prevents mixup until we have reached convergence, I guess that's the intention
[09:27] <tvoss> s/guess/think
[09:27] <seb128> ok, let's me try to rephrase again then
[09:27] <seb128> if we need a .notifications.hub
[09:28] <seb128> it's because there is going to be another notifications.foo
[09:28] <seb128> what is foo?
[09:28] <tvoss> seb128, no, .hub is the top-most decision maker
[09:28] <seb128> (because if hub is the only one to stand, we can as well call it ".notification")
[09:28] <seb128> why do we need an extra qualifier then?
[09:28] <tvoss> seb128, because the responsibilities are different ones
[09:28] <seb128> no need to make type.subtype when there is only 1 subtype
[09:29] <seb128> it's because you object calling what comes from the hub "notifications"?
[09:29] <tvoss> seb128, notifications is just one possible type issued by the hub
[09:30] <tvoss> seb128, hence why chipaca originally proposed postal
[09:30] <seb128> k, so those are hubs objects
[09:30] <didrocks> so, it's rather a hub.notification
[09:30] <seb128> so that should be com.ubuntu.hub.notifications
[09:30] <tvoss> nope
[09:30] <seb128> :-(
[09:30] <tvoss> well, we could do it like that
[09:31] <Chipaca> except it isn't called "hub"
[09:31] <didrocks> I think that will be more inline with what we see in different domains
[09:31] <tvoss> didrocks, got an example?
[09:31] <seb128> Chipaca, well, "com.ubuntu.<whatever it's called>.<whatever the notifications it deals with are called>"
[09:31] <Elleo> mandel: nope, haven't seen ahayzen around the past few days; I could send him an email if you like?
[09:32] <didrocks> tvoss: dbus, android application domain owners
[09:32] <didrocks> this is just on the top of my head
[09:32] <didrocks> can find more if needed :)
[09:32] <mandel> Elleo, It would be nice, that way we can confirm it fixed it and land it
[09:32] <Chipaca> seb128: oh, i know, how about com.ubuntu.postal.notifications
[09:32] <Elleo> mandel: okay, will do
[09:32] <seb128> Chipaca, +1
[09:32] <Chipaca> ....
[09:33] <Chipaca> seb128: dude
[09:33] <Chipaca> seb128: it was that 100 man-hours ago, and you -1'ed it
[09:35] <seb128> Chipaca, no, first version was com.ubuntu.touch.notifications and I -1ed the touch part
[09:35] <seb128> but yeah, .postal is not something I understand
[09:36] <seb128> but this whole stack of notifications which are not notifications is confusing
[09:36] <seb128> so let's just keep the com.ubuntu.notifications.hub we have atm
[09:36] <seb128> it's already in a silo
[09:36] <seb128> and it seems we are not going to agree on something that makes more sense
[09:37] <seb128> I still wish we had a "com.ubuntu.notifications" which lists apps name, simple and easy to understand :-/
[09:38] <tvoss> seb128, but that will grow and will be more fine-grained when we are converging. with that, we would only post-pone the namechange
[09:39] <seb128> tvoss, I guess I don't understand why we can't describe what we want now and define the names/keys, even if they are not used fully yet
[09:39] <seb128> that would avoid transitions/renames later
[09:39] <tvoss> seb128, because we don't fully know them yet, and notifications is not the right level of abstraction to capture those
[09:40] <seb128> k
[09:40] <seb128> well, let's just go with what is in the silo then
[09:40]  * seb128 +1 that
[09:40] <Chipaca> now if I could get my phone to give me adb, i'd be able to do the full test to land it all
[09:52] <Hendrik_> How do i debug the apn being used by the phone or ofono completely?
[09:52] <Hendrik_> im not giving up :D
[10:00] <Chipaca> shouldn't adb work in recovery?
[10:01]  * Chipaca tries 164
[10:03] <popey> Hendrik_: /usr/share/ofono/scripts/list-contexts
[10:10] <Hendrik_> popey, thx
[10:10] <Hendrik_> :)
[10:11] <Chipaca> I'm not getting adb in recovery. Halp.
[10:11] <Chipaca> (this means ubuntu-device-flash fails)
[10:33] <Chipaca> my phone no longer gives me adb, not even in recovery. fastboot works. Tried flashing a few devel-proposed and devel itself using --bootstrap, all with the same effect: reaches recovery, then dies because no adb. help?
[11:04] <dpm> hi ogra_, IIRC with the new developer mode UI adb is enabled/disabled, but what's the plan with SSH?
[11:04] <ogra_> ssh is always off
[11:05] <ogra_> you can enable it via setprop as root
[11:05] <lool> dpm: we agreed a while ago that it was too many things to support to try to juggle between SSH and ADB; adb can do IP too and SSH can be enabled manually for powerusers
[11:05] <ogra_> (for advanced developers :) )
[11:05] <lool> but it's not part of the default dev experience
[11:05] <ogra_> well
[11:05] <ogra_> phablet-shell uses ssh over adb
[11:05] <ogra_> but i'm working on running that with a user owned sshd
[11:06] <dpm> lool, ogra_, the only issue seems to be that Qt Creator needs SSH to deploy apps to the device
[11:06] <ogra_> (not exposed to the network anywhere)
[11:07] <ogra_> dpm, well, bzoltan played with my changed adbd package last week ...
[11:07] <ogra_> my only big issue atm is phablet-network since that would need the sudo password supplied
[11:08] <popey> so can I not sudo once phablet-shell'ed into my phone?
[11:08] <popey> (seems phablet is no longer the password)?
[11:08] <ogra_> you can sudo ... there is no pw ... just hit enter
[11:09] <popey> Sorry, try again.
[11:09] <ogra_> (note that adb wont work if there is no pw set in the near future ... so you will have to set one yourself before enabling it anyway)
[11:09] <popey> nope, i cant sudo
[11:10] <dpm> ogra_, what's the way to activate SSH manually?
[11:10] <ogra_> grep phablet /etc/passwd
[11:10] <ogra_> popey, ^^
[11:10] <popey> no results returned from that
[11:11] <ogra_> dpm, setprop persist.service.ssh true
[11:11] <dpm> thanks
[11:11] <ogra_> popey, hmm
[11:11] <ogra_> and the same for /var/lib/extrausers/passwd?
[11:11] <popey> phablet:x:32011:32011:phablet,,,:/home/phablet:/bin/bash
[11:12] <ogra_> looks fine
[11:12] <ogra_> and the shadow file in there has an entry too for the phablet user ?
[11:13] <popey> nothing there
[11:13] <ogra_> weird
[11:13] <ogra_> that should have a line too
[11:13] <ogra_> wait for mterry ... something si wrong then
[11:13] <ogra_> *is
[11:14] <jgdx> mpt, ping
[11:15] <dpm> lool, so your recommendation would be for Qt Creator to move away from SSH and use ADB instead?
[11:17] <ogra_> ++
[11:18] <ogra_> oSoMoN, so with the new browser trying to scrool slow with the toolbar visible gety all jiggly ... is there a bug for that already ?
[11:18] <ogra_> *gets
[11:18] <jdstrand> cwayne1: hey, what's up?
[11:19] <popey> jdstrand: when you get a mo could you look at bug 1351041 - seems like an apparmor thing
[11:20] <ogra_> oSoMoN, also, is there any way to force the toolbar to hide ? most of my html5 games look really bad now since it is permanently shown and they try to use all of the screen (so you have black bars everywhere, input controls are off etc)
[11:21] <cwayne1> jdstrand: was getting a weird apparmor denial when trying to use a scope wih online-accounts, but I think now it may just be an oline accounts bug..
[11:21] <Chipaca> mardy: ping. Would you have time for a final review of a system settings branch? seb's been over it and we've addressed his concerns, and he approved the related schema branch, but left before top-approving the system settings branch itself
[11:26] <bzoltan> ogra_:  I think it is smart to force the developers to set unique password, but it is not smart to force them to use the password unlock for the screen.
[11:26] <ogra_> bzoltan, i fully agree
[11:26] <bzoltan> ogra_:  Also I would like to ask for an option in the Developer mode page to start and stop SSH service
[11:26] <jdstrand> cwayne1: ok
[11:26] <ogra_> bzoltan, but not my decision, talk to jdstrand, mdeslaur and victorp ... the currentl planning is an agreement between thenm i think
[11:27] <ogra_> bzoltan, not planned :/
[11:27] <jdstrand> popey: there is definitely an apparmor denial, but reminders is trying to do the wrong thing
[11:27] <jdstrand> I'll comment
[11:27] <ogra_> you can sudo and setprop to enable ssh
[11:27] <popey> thanks!
[11:27] <popey> ogra_: if sudo works ☻
[11:27] <bzoltan> jdstrand: mdeslaur: With the SDK we _DO_ start the ssh, because we need that
[11:27] <popey> should I file a bug ogra_ ?
[11:27] <ogra_> popey, blame mterry :P
[11:27] <ogra_> popey, yes
[11:27] <popey> against?
[11:28] <ogra_> hmm
[11:28] <ogra_> popey, i thinnk livecd-rootfs ... but assign to mterry
[11:28] <popey> kk
[11:28] <ogra_> bzoltan, why cant you copy via adb push ?
[11:28] <bzoltan> ogra_:  jdstrand: mdeslaur: who is the one I need to convince about these two things. (1) UI switch for starting-stoping SSH service
[11:29] <ogra_> since you need to use adb anyway
[11:29] <bzoltan> ogra_: How do I start the SSH with phablet adb push?
[11:29] <ogra_> why would you start ssh at all
[11:29] <mdeslaur> bzoltan: you need to use certs with ssh...so the developer needs to use adb first to transfer certs anyway
[11:29] <bzoltan> ogra_: because we use it?
[11:30] <ogra_> mdeslaur, you also need root to start ssh ...
[11:30] <jdstrand> popey: commented
[11:30] <bzoltan> mdeslaur: we use keys for authentication
[11:30] <ogra_> bzoltan, *why* do you use ssh and not adb
[11:30] <popey> ta jdstrand
[11:30] <mdeslaur> bzoltan: exactly
[11:30] <bzoltan> ogra_: because it is more reliable and better
[11:30] <ogra_> define better :P
[11:30] <ogra_> and it should not be more or less reliable than ssh ...
[11:30] <bzoltan> ogra_:  but firs of all... because that is how we designed and implemented the SDK.. like two years ago
[11:30] <ogra_> if it is thats a bug
[11:31] <jjohansen> jjohans
[11:31] <bzoltan> ogra_: let!s not change the fundamental architecture of the SDK Tools just few days before the release :)
[11:32] <mdeslaur> bzoltan: perhaps I'm misunderstanding your question
[11:32] <bzoltan> mdeslaur:  I need a switch in the touch UI to start/stop ssh service.
[11:32] <ogra_> bzoltan, well, feell free to develop something on top of the planned dev mode ... i wont have the time to develop a secure debus service for ssh to expose it to the UI or anything
[11:32] <bzoltan> mdeslaur:  otherwise I will do it with sudo as phablet from a script
[11:32] <ogra_> (i'm not even done with the adb side as you know)
[11:33] <mdeslaur> bzoltan: yes, doing it with sudo as phablet from a script is the right way
[11:33] <ogra_> right
[11:33] <mdeslaur> we definitely don't want users to be turning on ssh
[11:33] <bzoltan> mdeslaur: echoing a plain passwd thru scripts is the right way?
[11:33] <bzoltan> mdeslaur: that is what we do
[11:33] <ogra_> mdeslaur, the prob here is that we need to store the pw in plain text on the users PC then
[11:34] <jdstrand> how is ssh any better in this regard? because you can ssh as root into it?
[11:34] <bzoltan> mdeslaur: why not? That is how maemo devices worked, that is how Meego works, that is how Sailfish does.
[11:34] <mdeslaur> bzoltan, ogra_: well, we could ship a helper in /etc/sudo.d that would allow turning ssh on
[11:35] <ogra_> mdeslaur, hmm ... i'm not really happpy about opening ssh at all
[11:35] <popey> ogra_: filed bug 1352296 and threw at mterry ☻
[11:35] <mdeslaur> what do we need ssh for?
[11:35] <bzoltan> ogra_: that is not an option I am afraid
[11:35] <bzoltan> ogra_:  I mean not opening the SSH
[11:35] <ogra_> mdeslaur, no idea, adb should provide all we need
[11:36] <ogra_> mdeslaur, bzoltan claims ssh is "more reliable and "better""
[11:36] <bzoltan> mdeslaur:  for the SDK
[11:36] <ogra_> (of which i dont know what this means)
[11:37] <bzoltan> ogra_: mdeslaur: what I claim is not relevant.. the key here is that our SDK right now is using SSH... this is how it is out there for almost two years.
[11:37] <ogra_> why do you two ways for talking to the phone ??
[11:38] <mdeslaur> bzoltan: what sets up the ssh keys?
[11:38] <mdeslaur> bzoltan: the sdk?
[11:38] <ogra_> this means we need to open two potential security holes now
[11:38] <bzoltan> mdeslaur: ogra_: jdstrand: All I am asking (not the first time) that before you change fundamental policies on the platform please consider how it effects the app development tools.
[11:38] <bzoltan> mdeslaur: the SDK does it
[11:38] <mdeslaur> bzoltan: ok, and what is no longer working?
[11:38] <mdeslaur> sorry, I lack a bit of context on what the problem is
[11:39] <ogra_> mdeslaur, we wont have any UI to toggle ssh on oor off ... and the adb toggle is not enough
[11:39] <bzoltan> mdeslaur: it works.. I can make it work. But I need to ask and store the phablet passwd and pass it with an echo to make it work
[11:39] <ogra_> (for bzoltan )
[11:39] <ogra_> mdeslaur, that means we need to patch sshd as well to listen to the screen lock and so on
[11:39] <cwayne1> mardy: ping
[11:39] <ogra_> this isnt trivial
[11:40] <bzoltan> ogra_: why not to have an ssh switch? N9 has, Jolla has... neither the was ever compromised because of that.
[11:40] <mdeslaur> bzoltan: so if we add a snippet to /etc/sudoers.d that would allow the phablet user to turn ssh on without requiring the sudo password, that would be enough?
[11:40] <mardy> cwayne1: pong
[11:40] <bzoltan> mdeslaur: that would make it
[11:40] <ogra_> bzoltan, if you have time to safely hack up sshd and to implement the UI bits, feel free
[11:40] <cwayne1> mardy: hihi, so abouts scopes + OA :)
[11:40] <jdstrand> why isn't phablet-shell enough?
[11:41] <ogra_> tahts what i'm asking
[11:41] <cwayne1> mardy: I got it working on a device, but only unconfined.  and i added a desktop file to grant access, but it shows no info
[11:41] <bzoltan> jdstrand: because phablet user has no right to start the ssh service
[11:41] <mdeslaur> ogra_: we don't care about screenlock, as ssh uses certs, not passwords
[11:41] <oSoMoN> ogra_, there is no bug filed for the jiggliness you’re seeing, but it’s a known issue, feel free to file a bug
[11:41] <jdstrand> so, phablet-shell is what broke?
[11:41] <bzoltan> jdstrand: mdeslaur: bit the real ugly thing is the password lock... that is a killer.
[11:41] <ogra_> mdeslaur, and why cant we do the same for adb (as we have planned since a year now) ?
[11:41] <mdeslaur> bzoltan: password lock?
[11:42] <ogra_> oSoMoN, well, as long as you guys know it and work on it i'll refrain from more paperwork ;)
[11:42] <mdeslaur> ogra_: because adb uses passwords
[11:42] <bzoltan> mdeslaur:  you need to have a passwork unlock policy in order to have adb at all
[11:42] <ogra_> mdeslaur, adb doesnt use anything
[11:42] <mdeslaur> bzoltan: yes, definitely
[11:42] <ogra_> mdeslaur, we (you, me, PES) planned a blueprint for this a year ago or so
[11:42] <jdstrand> bzoltan: as for screenlock checks, that did not originate from us. that came as very late requirements from outside of UE
[11:42] <oSoMoN> ogra_, for your html5 games, I recommend you remove the --enable-back-forward and/or --enable-addressbar command line switches from the desktop file, the chrome will then be always hidden
[11:42] <ogra_> mdeslaur, two vUDSes ago
[11:42] <bzoltan> mdeslaur:  so if I want to develop apps then I need to type my passwd on the touch screen like hunderd times a day... nice
[11:42] <mdeslaur> ogra_: sorry, I don't understand what you mean
[11:43] <ogra_> mdeslaur, https://blueprints.launchpad.net/ubuntu/+spec/core-1311-complete-developer-mode-integration
[11:43] <mdeslaur> bzoltan: what? how come?
[11:43] <ogra_> mdeslaur, "add UI to popup the device fingerprint when negociating a connection: TODO" ... instead we now have to tie to the lock screen
[11:44] <bzoltan> mdeslaur: that is what happens once you set a password
[11:44] <mardy> cwayne1: it's probably because of https://bugs.launchpad.net/ubuntu-system-settings-online-accounts/+bug/1329213
[11:44] <jdstrand> yet, I fail to see how checking that the screen is unlocked if there is a password check is a burden. the user unlocks the screen, plugs in the device/clicks a button, and then you can get an adb session. the session can continue running if the screen is unlocked
[11:44] <mdeslaur> bzoltan: sure when you first plug the device in, you need to unlock it
[11:44] <jdstrand> err
[11:44] <lool> dpm: I thought it was the plan, yes; I guess the SDK team would have the latest status on this
[11:44] <mdeslaur> bzoltan: and then one it's connected, you never have to unlock it again until you close adb
[11:44] <jdstrand> the adb session can continue running if the screen later locks
[11:44] <cwayne1> mardy: ooh yes, thats exactly what it looks like :)
[11:44] <bzoltan> jdstrand: the screen will keep being locked
[11:45] <bzoltan> mdeslaur: that is not how it works now
[11:45] <cwayne1> mardy: okay, so once that's fixed -- how am I going to make my scope confined? is that going to be solved with dash-as-app?
[11:45] <jdstrand> bzoltan: right, that is what I'm saying. but open adb sessions won't close
[11:45] <ogra_> jdstrand, its a massive hack to adbd ... beyond we had a way better mechanism planned last year
[11:45] <ogra_> jdstrand, https://blueprints.launchpad.net/ubuntu/+spec/core-1311-complete-developer-mode-integration
[11:46] <cwayne1> dbarth_: why would the fix for https://bugs.launchpad.net/ubuntu-system-settings-online-accounts/+bug/1329213 take awhile to land?
[11:46] <mardy> cwayne1: I think so
[11:46] <jdstrand> ogra_: what in there is better than what was agreed to fro rtm? the device fingerprint?
[11:46] <ogra_> jdstrand, what you want means that adbd needs to be fully integrated with dbus and other bits to request the screen state etc etc ... this will be close to a re-write
[11:47] <ogra_> jdstrand, imho yes
[11:47] <ogra_> it is what android does
[11:47] <jdstrand> android does a lot of things
[11:47] <popey> oSoMoN: ooh, thanks!
[11:47] <jdstrand> we have a different model and are in a different place in time in our development of the device
[11:48] <popey> dbarth_: you should remove the --enable-back-forward from the twitter webapp imo. (as per oSoMoN above)
[11:48] <bzoltan> jdstrand:  no it will not, but forcing an app developer to a screen lock policy is super ugly... it would be a reason to return the device to the shop.
[11:48] <jdstrand> I'd really rather not rehash this conversation for the 1000th time. why is it a complete rewrite to adb to add a single check on session create when it starts?
[11:48] <ogra_> jdstrand, if i plug in an android device to a PC that was never connnected it pops up a question to allow the connection on the phone (so yu have to have the screen unlocked) ... after that it will just veify that the figerprint of the PC matches without asking
[11:49] <jdstrand> ogra_: that particular feature was something that is listed as post-rtm
[11:49] <mdeslaur> bzoltan: once ssh is turned on, you can disable the screen lock
[11:49] <ogra_> jdstrand, adbd is an android c binary ... there is no dbus on android ... to get tthe screen status asking vis dbus is the only way to get the info
[11:50] <ogra_> jdstrand, feel free to look at the adbd code ... there is no way we will have the locking stuff ready in time ...
[11:50] <jdstrand> ogra_: other teams have figured this out by having a socket bridge or something
[11:50] <bzoltan> mdeslaur: i think  that thescreen lock policy should be a totally  separated thing from the device connectivity
[11:51] <bzoltan> mdeslaur:  forcing the dev to a plicy like that at the first place isnot good
[11:51] <ogra_> jdstrand, well, then other teams need to implement it, i was working my way along the spec we defined initially (only the fingerprint stuff is missing atm since the discussion started when i wanted to attack it)
[11:51] <mdeslaur> bzoltan: I do too
[11:51] <jdstrand> ogra_: are you saying implementing the device fingerprint is doable for rtm?
[11:51] <ogra_> easier than teaching adbd about dbus i guess
[11:51] <mdeslaur> bzoltan: it wasn't a security team requirement
[11:52] <jdstrand> this did not come from us
[11:52] <ogra_> especially since we cant use it anymore ffor other stuff (like initrd debugging, emergency shell etc) once it depends oon that
[11:52] <ogra_> jdstrand, no, i know
[11:52] <bzoltan> mdeslaur: i understan
[11:52] <ogra_> i was on CC
[11:53] <bzoltan> jdstrand: mdeslaur: we should discuss it with folks who came with this concept.
[11:54] <jdstrand> mdeslaur: what if the the device fingerprinting was used for rtm instead? if the screen is unlocked, then the user can say yes or no, if the screen is locked, that ui would just be behind the screen anyway. this seems to cover the requirement for needing a password
[11:54] <jdstrand> oh, no
[11:54] <jdstrand> that doesn't work
[11:55] <jdstrand> we would have to have the UI for the device fingerprint acceptance reprompt for the password
[11:55] <jdstrand> (cause of lending)
[11:55] <jdstrand> mdeslaur: ^
[11:56] <ogra_> jdstrand, well, that would mean if you really want to steal data you need to keep the screen on until you are near a PC
[11:57] <mdeslaur> jdstrand: yeah, that's the solution we were aiming for, but couldn't get done for rtm
[11:57] <ogra_> while theoretically possible i think thats a very unlikely scenario
[11:57] <ogra_> mdeslaur, who said it couldnt ?
[11:57] <mdeslaur> ogra_: you did
[11:58] <ogra_> well, surely easier than teaching adbd about dbus and having it get the screen state from there
[11:58] <ogra_> (and the locking capabilities etc)
[11:58] <mdeslaur> ogra_: you still need to pop up a message on the screen that asks for confirmation, etc.
[11:58] <ogra_> yeah, that wont be easy
[11:59] <ogra_> (especially since i'm not even remotely ready with the initial adbd bits which rely on oassword stuff that dosnt work yet)
[11:59] <mdeslaur> jdstrand: not sure why you mentioned reprompting for the password?
[12:00] <mdeslaur> oh right, the stupid "I lend my unlocked phone to a friend" scenario
[12:00] <ogra_> jdstrand, we should simply lock automatically before the prompt comes up
[12:00] <jdstrand> ogra_: well, pick one :) either I tell people the requirement is what it is now or I convince people to change to the fingerprint check :)
[12:00] <ogra_> make that part of the popup code
[12:01] <jdstrand> mdeslaur: ok, let me read the requirements again. hold on
[12:01] <jdstrand> this conversation has morphed a billion times I can't keep it all straight
[12:01] <mdeslaur> me neither
[12:01] <cjwatson> mdeslaur: hey, so for the click store key, I've talked with slangasek and reconciled our positions; it would appear that for this purpose we can just have an operational key, and it doesn't need to be signed by a sharded master key because the mechanism for communicating key rotations to clients is to deploy a new system image containing a new keyring package
[12:01] <jdstrand> https://wiki.ubuntu.com/SecurityAndPrivacySettings/ProtectingUserData
[12:01] <cjwatson> mdeslaur: would you agree with that?  in that case all we need to do is generate a 4096-bit RSA key and give it to the click store guys
[12:02] <jdstrand> "adb should only accept new connections if screen is unlocked"
[12:02] <mdeslaur> cjwatson: yes, did agree to that
[12:02] <jdstrand> mdeslaur: that ^ is the requirement for phase 1 - initial phone delivery
[12:02] <mdeslaur> cjwatson: uhm, no, wait a sec
[12:02] <ogra_> jdstrand, yeah :(
[12:02] <jdstrand> mdeslaur: as such, we wouldn't have to reprompt
[12:03] <mdeslaur> cjwatson: we need to assume we can't deploy images, for example phones that the oem has ended support on....we still would want them to be able to access the store
[12:03] <mdeslaur> cjwatson: so that key needs to be signed by _something_, so that we can have the _store_ rotate it
[12:03] <cjwatson> mdeslaur: hm, that means the key has to be in a writeable location on the filesystem
[12:03] <mdeslaur> cjwatson: yes, definitely
[12:03] <cjwatson> mdeslaur: but maybe we can kick that part of the can down the road
[12:04] <cjwatson> doesn't have to be that way right now
[12:04] <mdeslaur> cjwatson: sure, as long as we do it before we can no longer push out updates to our shipping phones
[12:05] <mdeslaur> we can definitely use an unsigned key for now in a non-writable location shipped by the system image
[12:05] <cjwatson> I'm starting to feel the need for a graph of our important keys ...
[12:06] <mdeslaur> yes :)
[12:07] <mdeslaur> jdstrand, ogra_: so basically, to turn on adb, you need to set the screen lock. You connect to the sdk, the sdk pushed out your ssh keys, and then turns on ssh. Once that's done, you can turn off screen lock and simply use ssh from now on.
[12:07] <cjwatson> mdeslaur: I think we should specifically not reuse the archive master key (0x3F272F5B) for this, because that would then allow the click store key to be used to sign the apt archive, if its private material were compromised
[12:07] <cjwatson> So it would need to be a new set of master shards
[12:07] <mdeslaur> cjwatson: hrm, good point
[12:08] <cjwatson> or at least that seems like a possibility to me and I'd rather completely rule it out rather than having to think about it :)
[12:08] <cjwatson> We also need to generate a key for the RTM archive this week
[12:08] <ogra_> mdeslaur, well, i dont really like to leave a network accessible service permanently running ... adbd requires a wire and a PC ... ssh will simply stay open to the network for attack attempty
[12:08] <ogra_> *attempts
[12:08] <mdeslaur> cjwatson: Honestly, if everyone is in the same place next week, I think creating a new set of shards is the safest bet, knowing that we may want to do key rotations without image upgrades at some point to maintain a working store on unsupported devices
[12:08] <cjwatson> But that only really needs to be used during image building and by developers using click chroot or whatever, so it doesn't require any advance planning for rotations AFAICS
[12:09] <cjwatson> mdeslaur: This week
[12:09] <ogra_> additionally it will keep your wlan awake i guess ... and eat your battery
[12:09] <mdeslaur> ogra_: ssh is only enabled for developers, and is protected with keys....I don't think it's a big deal
[12:10] <mdeslaur> cjwatson: I'm not sure I follow your last comment
[12:11] <mdeslaur> ogra_: developers can turn it back off manually if they want...but I suspect most will want ssh running anyway
[12:11] <ogra_> hmm
[12:13] <cwayne1> mardy: do you agree that the info-less application entries in u-s-s-o-a will be easy to fix but hard to land? (going by david's comment in the bug)
[12:13] <cwayne1> if so, i'll volunteer to get it landed if you guys get it fixed :)
[12:13] <jdstrand> mdeslaur: I reread the wiki page. "adb should only accept new connections if screen is unlocked" is I think enough equivalent to device fingerprinting. in both options, the user can enable adb in the lending scenario. in both options, if the screen is locked in the theft scenario, adb can't be enabled or accessed
[12:14] <jdstrand> mdeslaur: (unless the theif has access to the unlocked already fingerprinted device)
[12:14] <jdstrand> thief*
[12:15] <mdeslaur> jdstrand: sorry, I don't know what you are referring to
[12:15] <jdstrand> https://wiki.ubuntu.com/SecurityAndPrivacySettings/ProtectingUserData
[12:15] <mdeslaur> jdstrand: aren't we talking about ssh?
[12:16] <mdeslaur> jdstrand: the issue is that the sdk can't start ssh over adb because it requires the user's password
[12:16] <jdstrand> mdeslaur: I was weighing the options of what we have currently as what needs to be done "adb should only accept new connections if screen is unlocked" with device fingerprinting since ogra_ said that adb can't do the former
[12:16] <mdeslaur> jdstrand: so supplying a /etc/sudoers.d config to enable the phablet user to turn on ssh without a password would solve that, and would be acceptable to me
[12:16] <jdstrand> mdeslaur: right, but of course, other stuff came up
[12:17] <mdeslaur> jdstrand: wait, we can't do the former for rtm?
[12:17] <ogra_> jdstrand, it can, but it will be harder to impllement and break adbd for other use cases
[12:18] <jdstrand> mdeslaur: that is what we were just told, though I'm still not sure why
[12:18] <jdstrand> oh, I thought we were told it couldn't and required a complete rewrite?
[12:18] <jdstrand> (which again, I think there are cleverer ways to do that)
[12:18] <ogra_> jdstrand, i said "close to" :)
[12:19] <ogra_> jdstrand, the point is that the screen state info can only be obtained via dbus
[12:19] <ogra_> jdstrand, and since that is a securioty thing i dont think i should do that check with a helper but in adbd itself
[12:20] <ogra_> that means a lot of code changes since adbd does not know about dbus at all
[12:20] <jdstrand> if the helper is only saying yes or no on if the screen is locked, not sure why that is risky
[12:20] <ogra_> and it means adbd wont work in any other context like inside initrd
[12:20] <jdstrand> the initrd argument is interesting
[12:20] <ogra_> or as emergency shell if all services (including dbus) fail to start
[12:20] <mdeslaur> ogra_: sure it will work, as long as the screen is not locked
[12:21] <ogra_> mdeslaur, how if it cant even find out the screen state ?
[12:21] <ogra_> (in initrd or if dbus fails to start there wont be a way then)
[12:21] <mdeslaur> if it can't find out the screen state, it allows the connection
[12:21] <ogra_> so i only need to kill dbus and can break in ?
[12:21] <mdeslaur> ogra_: yes
[12:21] <ogra_> uh
[12:22] <mardy> cwayne1: that would be very welcome, thanks! :-)
[12:22] <jdstrand> the terminal is also password protected
[12:22] <ogra_> jdstrand, my click app that bombs dbus with DOS requests isnt ;)
[12:23] <cwayne1> mardy: np, it's gonna be a requirement for us very soon I think, so happy to help any way I can :)
[12:23] <jdstrand> that click app can't be side-loaded, so it would have to be in the store, if it is in the store, then it would get removed
[12:23] <mdeslaur> ogra_: there's no way for you to kill dbus if the screen is locked
[12:24] <mdeslaur> and if the screen is unlocked, adb is allowed anyway
[12:24] <jdstrand> right
[12:25] <mdeslaur> of course, what if an attacker that gets hold of a phone is able to reboot it and adb in before the user session comes up
[12:25] <cjwatson> mdeslaur: which last comment, sorry?  (in a meeting here)
[12:25] <mdeslaur> cjwatson: you said "But that only really needs to be used during image building and by developers using click chroot or whatever, so it doesn't require any advance planning for rotations AFAICS"
[12:25] <cjwatson> mdeslaur: that's for the key that signs the RTM archive
[12:25] <jdstrand> mdeslaur: phase 1 does not cover other bootloader attacks anyway
[12:25] <mdeslaur> cjwatson: oh! ok, yeah
[12:25] <cjwatson> we have two separate key requirements going on here :)
[12:26] <mdeslaur> cjwatson: hehe, yes, I though you were referring to the store key
[12:26] <cjwatson> ok, so sharded-master + operational for click store key, operational only for RTM archive key
[12:26] <mdeslaur> cjwatson: I think that would be best, yes
[12:26] <jdstrand> mdeslaur: but phase 2 includes the device fingerprinting. so if device fingerprinting is considered 'enough', then why do the other solution at all and just go for what the long term plan is
[12:27] <ogra_> jdstrand, that was what i was asking mself since the internal discussion came up about this recently
[12:27] <cjwatson> mdeslaur: right, cool, will organise that here
[12:27] <cjwatson> thanks
[12:27] <mdeslaur> cjwatson: thanks!
[12:28] <mdeslaur> jdstrand: yeah, device fingerprinting is best, but I thought it was harder to implement as you need to pop up a prompt for the user. Simply not accepting connections when the screen is locked is a trivial helper that connects to the session dbus and performs a query
[12:28] <jdstrand> mdeslaur: so the question ogra wants to have answered is if we can remove '6' from phase 1 if we have '9' from phase 2 replace it?
[12:29] <ogra_> math !
[12:29] <mdeslaur> jdstrand, ogra_: the answer to that is yes
[12:29] <ogra_> jdstrand, well, the actual question is why did we waste so much time on this :P ... we have a blueprint everyone agreed on
[12:29] <jdstrand> mdeslaur, ogra_: ok, so I can send an email to the people involved that the implenter's can choose
[12:30] <jdstrand> ogra_: I hope you are not asking me that question :P
[12:30] <ogra_> lol
[12:30] <ogra_> no, the world in general :P
[12:30] <jdstrand> yes
[12:30] <jdstrand> I've had quite a few questions to the world in general lately
[12:30] <mdeslaur> ogra_: your "everyone" group is only a subset of the security team's "everyone" group :)
[12:30] <ogra_> haha
[12:31] <jdstrand> mdeslaur: so, back to your sudoers idea. I think that sounds reasonable, but I have quite though through what would be in the soders.d file
[12:31] <ogra_> we can alternatively just add ssh enabling to the dbus-property-service
[12:31] <jdstrand> haven't*
[12:31] <ogra_> and toggle it via dbus
[12:32] <mdeslaur> jdstrand: yes, it needs to be a shell script or something that _only_ enables ssh, and then that would be in sudoers.d
[12:32] <jdstrand> right
[12:32] <mdeslaur> only for the phablet user, or only the admin group
[12:32] <mdeslaur> basically, very restricted
[12:32]  * ogra_ thinks the property would be a safer approach then
[12:32] <jdstrand> so it has NOPASSWD?
[12:32] <mdeslaur> jdstrand: yeah
[12:32] <ogra_> via dbus ...
[12:33] <mdeslaur> or it could be one of the system dbus daemons that has an API for that
[12:33] <mdeslaur> that would probably be even better
[12:33] <mdeslaur> actually, I think I like that better
[12:33] <ogra_> we have such an api ... ssh enablement is handled by an android property
[12:33] <ogra_> and we have a dbus service that hooks into that
[12:33] <mdeslaur> ogra_: we do?
[12:33] <ogra_> (this is how we enable the user to toggle adbd)
[12:34] <ogra_> yeah
[12:34] <ogra_> dpkg -L dbus-property-service ...
[12:34] <mdeslaur> ogra_: oh, cool, so the same thing for ssh, with a proper policykit policy that only allows the admin group
[12:34] <ogra_> a simply python dbus helper
[12:34] <ogra_> *simple
[12:34] <ogra_> right
[12:34] <ogra_> mdeslaur, oh, that package could need a security team review btw :)
[12:34] <jdstrand> ogra_: so in this case, developer mode is more than adb, it is adb + ssh.
[12:34] <ogra_> bzr branch lp:dbus-property-service
[12:35] <mdeslaur> jdstrand: no
[12:35] <mdeslaur> jdstrand: developer mode is only adb
[12:35] <ogra_> jdstrand, so we want ssh on permanently if adb is on ?
[12:35] <mdeslaur> jdstrand: and then the sdk will turn on ssh if it's required
[12:35] <mdeslaur> ogra_: no
[12:35] <jdstrand> sorry, I meant to end with a '?'
[12:35] <ogra_> phew
[12:35] <jdstrand> I'm trying to understand what is being proposed
[12:35] <mdeslaur> jdstrand: a way for the sdk, via adb, to turn on ssh without requiring the user's password
[12:36] <jdstrand> so, it can tickle a property to turn it on without needing root. but, that is protected via polkit
[12:36] <mdeslaur> jdstrand: yes
[12:36] <jdstrand> so we can put whatever policy we want on it
[12:37] <mdeslaur> jdstrand: exactly, and is much better than sudoers crud
[12:37] <ogra_> well, please check the dbus-property-service package :) i'm not sure all i do there is secure yet :)
[12:37] <ogra_> but i can easily enhance it for ssh enabling
[12:38] <jdstrand> right, and adb is protected via one of the two options that will be implemented
[12:38]  * mdeslaur looks
[12:38] <jdstrand> ogra_: so, in this case, will the sdk start up ssh in the way that phablet-shell does? ie, with '-o PasswordAuthentication=no'?
[12:39] <ogra_> jdstrand, yes, it will call the equivalent to "service start ssh" .... which uses the same upstart job with hardcoded '-o PasswordAuthentication=no'
[12:39] <mdeslaur> ogra_: so dbus-property-service will need policykit integration at some point
[12:40] <mdeslaur> ogra_: it's ok on a single user device for now, but will need some love post-rtm
[12:40] <ogra_> mdeslaur, i thought the xml file actually adds that
[12:40] <ogra_> ok
[12:40] <ogra_> happy to change as needed
[12:41] <mdeslaur> you just have the dbus policy xml file, no policykit in there AFAICT
[12:41] <mdeslaur> anyway, no biggie for now
[12:43] <mdeslaur> bzoltan: hi
[12:44] <mdeslaur> bzoltan: so dbus-property-service will allow switching on ssh without requiring the user's password
[12:44] <bzoltan> mdeslaur: sorry, i lost my connection
[12:44] <mdeslaur> bzoltan: so the sdk can switch it on after setting up the keys
[12:44] <mdeslaur> bzoltan: once that's done, the developer can turn off the lock screen if they want
[12:45] <mdeslaur> bzoltan: I believe ogra_ has volunteered to add the ssh support to dbus-property-service
[12:45] <mdeslaur> :P
[12:45] <ogra_> bzoltan, have a look at the /usr/bin/android-gadget-service script ... i'll add something similar for ssh enabling
[12:45] <bzoltan> mdeslaur: OK, cool.
[12:45] <mdeslaur> bzoltan: would that be acceptable?
[12:45] <ogra_> (i.e. you can just have a dbus-send command to enable it)
[12:45] <bzoltan> mdeslaur: is there any chance to set the password and still use the swipe unlock at the first place?
[12:45] <ogra_> you will still need to copy the key etx
[12:45] <ogra_> *etc
[12:46] <bzoltan> ogra_: that is finw, for that I do not need #
[12:46] <ogra_> right
[12:47] <mdeslaur> bzoltan: currently no, but once ssh is set up, you can turn off the lockscreen
[12:48] <bzoltan> mdeslaur:  OK
[12:49] <Chipaca> Laney: ping. Would you have time for a final review of the ubuntu-system-settings branch related to the schema one that's been in discussion? seb's been over it and we've addressed his concerns, and he approved the related schema branch, but left before top-approving the system settings branch itself. Asked mardy, got no reply.
[12:49] <bzoltan> ogra_: would you ping me please when this dbus-property-service wil be available?
[12:49] <Chipaca> Laney: merge is https://code.launchpad.net/~ralsina/ubuntu-system-settings/notification-plugin/+merge/227344
[12:49] <ogra_> bzoltan, sure
[12:50] <mardy> Chipaca: I got back from holidays today :-)
[12:50] <bzoltan> ogra_: thanks! great that we do not need to hustle areound with the passwords.
[12:50] <jdstrand> ogra_, mdeslaur: can one of you followup on the ubuntu-phone thread about 'Developer mode, ADB and SSH' since you were already involved (and presumably read the whole thread, which I haven't yet :)
[12:50] <Chipaca> mardy: welcome back!
[12:50] <mdeslaur> jdstrand: I did already
[12:50] <jdstrand> ok, thanks
[12:50] <mardy> Chipaca: thanks :-) I'll have a look at your branch
[12:50] <Chipaca> mardy: if Laney can top approve, he's probably got more context anyway
[12:50] <Chipaca> mardy: because he's been following the discussion with seb, somewhat
[12:50] <mardy> Chipaca: yes, I'll let him do so, I'll just have a quick look
[12:50] <Chipaca> mardy: thanks
[12:52] <mardy> Chipaca: the indentation in PageComponent.qml is varied, in the ListItem.Base you are using tabs
[12:53] <Chipaca> ralsina: ^
[13:01] <Chipaca> mardy: good catch on the g_strdup bits
[13:09] <ogra_> mterry, hey, welcome home :)
[13:10] <mterry> ogra_, :)  thanks
[13:10] <ogra_> so there seem to be a lot of issues with setting the pw
[13:10] <mterry> ogra_, OK.  Bugs?
[13:11] <ogra_> i wonder if we dont have to ship with a locked PW insted of an empty one ... the UI definitely asks for the old one (which is empty indeed) and doesnt accept an empty one
[13:11] <ogra_> not sure there is a bug already
[13:11] <ogra_> i asked popey to file one for his sudo issue since he definitely has an empty shadow file
[13:11] <ogra_> i have a proper shadow file here but the UI doesnt allow me to change the PW
[13:12] <Louie> Hi all! I would like to request a language-pack-touch-* package update. Because the last build made at 16th July
[13:12] <mterry> ogra_, I tested this morning with an empty shadow and sudo worked for me
[13:12] <dpm> pitti, ^ - I tried to reach wgrant to do the export earlier, but it seems he's not around
[13:13] <mterry> ogra_, so something is definitely funky there if we have inconsistent results
[13:13] <dobey_> nhaines: hi. i'm not in europe. :)
[13:13] <pitti> dpm: yeah, I'm polling the page 5 times a day
[13:13] <pitti> Louie: in the works, waiting for LP
[13:13] <mterry> ogra_, but locked vs empty shouldn't be the issue
[13:13] <Louie> thanks pitti, where can I find the status of this?
[13:14] <dpm> pitti, I've just pinged him in #launchpad
[13:14] <pitti> Louie: https://translations.launchpad.net/ubuntu/utopic/+language-packs, we need a full export
[13:14] <pitti> Louie: (i. e. "base pack")
[13:14] <mterry> ogra_, what error do you get in the UI?  bad password or something else?
[13:14] <pitti> dpm: he said last week that LP is being fitted SSDs, and the export would start today or tomorrow
[13:15] <dpm> ah, cool, that should fix/mitigate the timeouts
[13:15] <dobey_> mardy: hi
[13:17] <ogra_> mterry, "internal error: user not loaded"
[13:18] <ogra_> interestingly it is also set to "password" by default for me
[13:18] <mpt> Chipaca, is it possible to tell, ahead of time, what kinds of notification (bubble, sound, vibration, Notification Center item) an app will ever try to use?
[13:19] <mterry> ogra_, hoowah?  "password"?!
[13:19] <ogra_> yep
[13:19] <mterry> what code would be doing that
[13:19] <ogra_> dunno
[13:19] <Chipaca> mpt: not at this time. Is that something we would want to do?
[13:19] <mterry> ogra_, you didn't set it to password in a previous flash run did you?
[13:19] <ogra_> not that i remember
[13:19] <Chipaca> mpt: we could make it so that they have to declare it
[13:19] <Chipaca> mpt: if we wanted to do that
[13:19] <ogra_> mterry, that "user not loaded" error seems to be very common though
[13:20] <mpt> Chipaca, yes, because it would avoid us showing settings checkboxes for things that an app is never going to do anyway
[13:20] <ogra_> i heard that from multiple people here
[13:20] <Chipaca> mpt: (but then i'd expect everybody to say "yeah, i want to do anything and everything")
[13:20] <mterry> ogra_, I'm also seeing that on my device, just tested
[13:20] <mterry> ogra_, were there recent changes to lxc-config or livecd-rootfs that were in this problem space?
[13:20] <Louie> What is "Device Image" meaning in the about page? I understand the Ubuntu image, but not the Device Image
[13:21] <ogra_> mterry, not that i'm aware of
[13:21] <ogra_> Louie, drivers and such live in their own image
[13:21] <ogra_> or image-part rather
[13:22] <Louie> ogra, thanks
[13:22] <popey> mterry: left a comment on the bug, I've not set a password either, but can't sudo
[13:23] <ogra_> well, you are completely lacking a shadow entry
[13:23] <ogra_> that shouldnt happen
[13:23] <popey> i have an entry in /var/lib/extrausers/shadow
[13:23] <popey> but not /etc/shadow
[13:23] <ogra_> oh, yoou said not when i asked :P
[13:23] <popey> yeah, you said "shadow" not that path
[13:23] <ogra_> yeah, /etc is dead :P
[13:23] <popey> i assumed /etc/shadow as that's "the shadow" file
[13:23] <popey> sorry
[13:24] <ogra_> we were talking about passwd in that path ... i kind of thought that was implied ;)
[13:24] <mterry> ogra_, user not loaded means that we had problems talking to AccountsService...
[13:25] <mterry> Does u-s-s not log anywhere?
[13:26] <mterry> Hrmm
[13:26] <mterry> The changelog for 0.6.37-1ubuntu7 seems very relevant
[13:28] <mterry> Hm, nope.  That just allowed more access it seems
[13:29] <ogra_> mterry, system-settings 0.6.37 ??
[13:29] <mterry> accountsservice
[13:29] <ogra_> ah
[13:31] <mterry> jgdx, where does u-s-s log its output?
[13:31] <pitti> jibel: does selecting a language in the wizard actually work for you? the wizard is in German for me, but it doesn't actualy write /etc/default/locale (or something resets it)
[13:31] <pitti> jibel: and thus unity and everything is still in English
[13:32] <jibel> pitti, it doesn't let me find the bug
[13:32] <jibel> pitti, bug 1351308
[13:32] <pitti> jibel: I was agoing to report one
[13:32] <pitti> jibel: ah, thanks
[13:32] <jibel> pitti, this is a regression in mako build #163
[13:32]  * pitti was looking in ubuntu-system-settings
[13:33] <jgdx> mterry, .cache/upstart/application-legacy-ubuntu-system-settings-.log # i think
[13:33] <jgdx> mterry, exact path in a sec (if you can't find it)
[13:34] <mterry> jgdx, got it
[13:34] <mterry> jgdx, thanks -- wasn't expecting the application-legacy prefix, but makes sense
[13:34] <jgdx> mterry, I'm honestly in the dark on that prefix. What does it mean?
[13:35] <mterry> jgdx, it just means that it isn't a click package
[13:35] <jgdx> mterry, ah – thanks
[13:38] <dpm> pitti, wgrant tells me he's started the export job
[13:38] <pitti> \o/ thanks
[13:47] <mardy> dobey: hi :-)
[13:49] <dobey> mardy: hi, i was trying to fix a bug in ubuntuone-credentials last week, and got stuck with another problem being introduced even though the things i was fixing work correctly now. so i think i need your help figuring out why it's happening.
[13:49] <mardy> dobey: please tell me more :-)
[13:49] <dobey> mardy: and i'm on vacation this week, so ted will be taking that over. i'm just around for a couple hours this morning to catch up with him and you, as you were both on vacation last week
[13:50] <beuno> cjwatson, re: gpg keys for click packages  :)
[13:50] <beuno> cjwatson, staging
[13:50] <dobey> mardy: https://code.launchpad.net/~dobey/ubuntuone-credentials/fix-cancel/+merge/228961 is the MP for my branch
[13:50] <beuno> cjwatson, I don't know if it needs to be something special
[13:50] <beuno> how would we do verification on the device?
[13:50] <beuno> is it easy to add the key to the phone for testing?
[13:50] <dobey> mardy: it fixes an issue where the Cancel button wasn't causing the plug-in to close, when opened via the new Client QML API, as well as the back button and broken accounts issues
[13:51] <dobey> mardy: however, with that fix, actually logging in is failing to close the UI when opened via the Client QML API now :(
[13:51] <dobey> mardy: and i haven't been able to figure out why that happens
[13:52] <cjwatson> beuno: not sure, I think it's tricky right now because the keys won't live in a writable location
[13:52] <cjwatson> beuno: do we have to solve this now?  because it's directly going to slow down getting this sorted for production ...
[13:52] <cjwatson> beuno: and Michael is on holiday at the moment
[13:52] <mardy> dobey: what is this Client QML API?
[13:53] <dobey> mardy: OnlineAccounts.Client
[13:53] <beuno> cjwatson, I don't want to slow down production, no. But the code is deployed on staging to test, I wanted to understand how we'd test staging on devices.
[13:53] <dobey> mardy: to open the plug-in directly, instead of via system-settings
[13:53] <mardy> dobey: ah OK. So the account gets created, but the UI doesn't close?
[13:53] <dobey> mardy: the pay-ui app is using it
[13:53] <beuno> cjwatson, I guess I we can try and test on production at this stage, it makes me a bit more nervous, but it's tolerable  :)
[13:53] <dobey> mardy: right, at least that is the behavior i'm seeing
[13:54] <cjwatson> beuno: Yeah, unfortunately I'm not sure right now, I *guess* we could deploy production's key on staging but that makes me kind of nervous too
[13:54] <dobey> mardy: and after the account is created and the UI doesn't close, the "Cancel" button also seems to stop working, and just does nothing
[13:55] <cjwatson> beuno: click install will have an --allow-unauthenticated option, though the current signing branch doesn't allow passing that through the PK plugin, so I guess that doesn't directly help
[13:55] <cjwatson> beuno: or we could make an image writable and then shove the right keys in
[13:56] <beuno> cjwatson, yeah, that might be the best thing to do for now
[13:56] <cjwatson> beuno: you probably ought to generate a staging key, even if not much is using it yet, anyway - would at least test that the signing process doesn't crash, and we could manually inspect the results
[13:56] <beuno> pindonga, ^^^^
[13:56] <beuno> cjwatson, I'll get that done, thanks
[13:56] <cjwatson> beuno: (which isn't hard - just check that it's still a valid ar archive, and that the original package is strictly a prefix of the signed one
[13:56] <cjwatson> )
[13:57] <mardy> dobey: and without your latest branch, it was closing properly?
[13:57] <dobey> mardy: yes, but without my branch, "Cancel" doesn't work at all, and we get the broken "empty" accounts sometimes
[13:57] <mardy> dobey: OK
[14:02] <dobey> tedg: ^^ can you raed the backlog for the discussion between mardy and me?
[14:07] <jgdx> kenvandine, could you take a look at https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/expandable-sim-name-editor/+merge/229450 ?
[14:07]  * tedg reads
[14:09] <Chipaca> mardy: ralsina just fixed the issues you found
[14:09] <Chipaca> mardy: in the system settings notifications plugin branch merge thing
[14:11] <kenvandine> jgdx, cool, sure
[14:17] <Chipaca> mardy: currently rebuilding. If neither Laney nor seb return from the dead soonish, could you do the whole thing?
[14:25] <dobey> mardy: just to be sure. you're looking into why that is happening? :)
[14:32] <Chipaca> rsalveti: ping; when can you spare five minutes to go over some powerd things?
[14:35] <rsalveti> Chipaca: sure, what's up?
[14:38] <Chipaca> rsalveti: am wanting to get woken periodically to check push notifications (and have polld do its poll). Where can I read up on the best way to do that?
[14:39] <mardy> Chipaca: unfortunately I don't have time to test the thing, I'm quite busy
[14:40] <ogra_> mdeslaur, i assume the security team doesnt mind if i remove /etc/cron.daily/passwd from the image :)
[14:40] <Chipaca> mardy: :( any suggestions as to who could review?
[14:40] <mardy> Chipaca: I'll just look at the code, and approve if I don't find anything major
[14:40] <mdeslaur> ogra_: nope, don't care
[14:40] <mardy> dobey: not yet, I'm still updating my phone
[14:41] <Chipaca> mardy: thanks
[14:42] <rsalveti> Chipaca: the right way to do that is requesting a hw alarm (via platform-api), waking up the device, holding a suspend blocker (via powerd), doing your stuff, releasing the suspend blocker and done
[14:42] <rsalveti> as you want to wake up the device in case it's also suspended
[14:42] <Chipaca> yep
[14:42] <rsalveti> that's how our alarm (indicator) is doing as well
[14:43] <rsalveti> Chipaca: first check platform-api for the hw alarm stuff
[14:43] <rsalveti> then check powerd's dbus api for suspend blocker
[14:43] <Chipaca> rsalveti: would you happen to have a link for that?
[14:43] <dobey> mardy: sure. i just want to confirm you will have a look as soon as you can. thanks :)
[14:43] <Chipaca> otherwise i'll google
[14:43] <rsalveti> Chipaca: pull-lp-source platform-api :-)
[14:44] <Chipaca> :)
[14:44] <rsalveti> and for powerd: https://wiki.ubuntu.com/powerd
[14:44] <rsalveti> Chipaca: I think there's a test case for the alarm api
[14:52] <Laney> Chipaca: We're in China so it's hard to be in sync, sorry
[14:52] <Laney> mardy's review should be fine
[14:52] <Chipaca> Laney: so i hear. Hope it's going well.
[14:53] <Laney> so far so good
[15:48] <jgdx> kenvandine, hey, do you have designs for call fwd/wait?
[15:48] <kenvandine> jgdx, not sure, i haven't gotten that far yet
[15:48] <kenvandine> i've switched gears to get caught up on content-hub stuff right now
[15:50] <jgdx> kenvandine, kay
[15:51] <kenvandine> jgdx, i'll review your branches in a bit, maybe over lunch
[15:54] <Chipaca> mardy: would you have five minutes?
[15:56] <john-mcaleely> what's a good way to completely kill adb? I want to test MTP without adb in the mix
[15:56] <john-mcaleely> I assume developer-mode hasn't landed yet :0
[15:56] <john-mcaleely> :-) even
[15:58] <jgdx> kenvandine, that's perfect.
[16:11] <Chipaca> mardy: basically i'm wondering where in ubuntu-system-settings would the push helper (that gets called when you get a broadcast message about system updates) would best be placed in the source tree
[16:11] <Chipaca> mardy: or the same thing but with 50% less "would"
[16:11] <popey> mterry: ogra_ just noticed since removing password for phablet user as you suggested, now I have no passcode (which I had set)
[16:12] <popey> I didn't realise setting a PIN sets the phablet password?!
[16:12] <mterry> popey, yes
[16:12] <ogra_> it does !
[16:12] <mterry> popey, so that's what was missing -- you needed to enter your PIN at the sudo prompt
[16:12] <popey> now if i try to set it, I get "Internal error: user not loaded"
[16:12] <mterry> popey, yup I'm looking into that -- some regression
[16:13] <popey> ok
[16:18] <popey> jdstrand: oSoMoN recommends removing --enable-back-forward from my webapp to remove the browser chrome, but this fails the desktop_Exec_webapp_args_minimal_chrome test in the click reviewers tools...
[16:21] <sil2100> boiko_: hello :)
[16:22] <sil2100> boiko_: so... we don't have a bug for it yet (too much to do :p), but could you take a look at the failing tests for address-book-app?
[16:22] <sil2100> boiko: we seem to be having locally-reproducible stable failures since some time
[16:22] <boiko> renatu: ^
[16:22] <sil2100> boiko: let me find some logs
[16:23] <boiko> sil2100: we are about to merge some design changes that include autopilot fixes, it might fix the issue you are seeing
[16:23] <sil2100> boiko, renatu: http://ci.ubuntu.com/smokeng/utopic/touch/mako/169:20140804:20140728.1/9466/address_book_app/
[16:24] <sil2100> boiko: would be nice, it's actually all caused by some icon problems
[16:24] <sil2100> (same problem on each test)
[16:24] <boiko> sil2100: Icon not being found? I fixed a couple of those
[16:24] <sil2100> Object not found with name 'Icon' and properties {'objectName': 'infoIcon'}. :)
[16:25] <sil2100> Maybe it changed recently or something
[16:27] <boiko> sil2100: yep, it changed recently, I had the same failures on messaging too, but it is fixed on silo 15 which should land soon
[16:27] <sil2100> That's excellent news
[16:30] <robotfuel> Wellark: ping, has there been any progress on this bug? https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1343341
[16:35] <jdstrand> popey: I turned it into 'info'. see r222
[16:36] <popey> jdstrand: thanks
[16:36] <jdstrand> popey: np
[16:43] <ogra_> popey, oh, awesome !
[16:43]  * ogra_ will have to re-pack all his html5 games 
[17:32] <nik90> charles: hi
[17:33] <charles> hi nik90
[17:33] <nik90> charles: were you able to figure out why the interactive notifications don't last as long as the snap notification did for alarms?
[17:34] <nik90> charles: just concerned if the interactive notification allow us to set a timeout value similar to the snap notifications
[17:34] <charles> oog
[17:34]  * nik90 looks for oog acronyms
[17:35] <charles> looks like unity-notifications ignores the timeout hint when the notification mode is Interactive
[17:35] <nik90> oh
[17:35] <charles> looking at unity-notifications/src/NotificationServer.cpp's NotificationServer::buildNotification
[17:36] <nik90> charles: I will check with macSlow if that is an intended behavior or not
[17:36] <charles> it looks at the timeout hint if the mode is Snap, but not Interactive
[17:36] <charles> nik90, is there a ticket open for this already?
[17:36] <charles> for i-datetime?
[17:36] <nik90> yes
[17:37] <nik90> charles: https://bugs.launchpad.net/ubuntu-clock-app/+bug/1350426
[17:37] <nik90> charles: it is also marked as affecting i-datetime
[17:38] <charles> nik90, I was unclear, is the Interactive-mode timeout issue discussed in any ticket?
[17:39] <nik90> charles: no, I only discovered it while testing your MP. So I wasn't sure if you added support for it or if it was a bug.
[17:39] <charles> nik90, ack. I'll add it to 1350426
[17:39] <nik90> ok
[17:47] <charles> nik90, https://bugs.launchpad.net/ubuntu-clock-app/+bug/1350426/comments/3
[18:18] <kenvandine> jgdx, have you seen the reset-api branch?  it's approved already, not sure if that interferes with your reset branch?
[19:04] <jgdx> kenvandine, seen it, but that's an api in the plugin system.
[19:05] <kenvandine> just wasn't sure if there was some conflict there
[19:05]  * jgdx cheks
[19:05] <jgdx> s/ect/etc
[19:07] <jgdx> kenvandine, no conflicts. Thank you for the review.
[19:14] <jgdx> kenvandine, ci test failures correct, I broke it
[19:20] <beuno> pindonga, 15:19 < popey> beuno: https://pastebin.canonical.com/114767/ got that when trying to upload a version of my app
[19:20] <popey> tried second time and now it wants me to bump version so assume it did actually upload
[19:20] <popey> https://myapps.developer.ubuntu.com/dev/click-apps/172/ is the app
[19:21] <pindonga> beuno, popey checking
[19:21] <popey> yes, looks like it did upload
[19:21] <pindonga> this is sca showing an oops from pkgme
[19:21] <pindonga> looks like click-updown was down at that time
[19:21] <pindonga> the error can be improved though
[19:21] <pindonga> and we have a to-do item to make these kind of things async so we can retry
[19:22] <popey> ok, thanks
[19:23] <pindonga> popey, except for the poor error handling here.. does it work now for you, or is there something else we can help with?
[19:23] <popey> pindonga: looks like it worked
[19:24] <pindonga> ack
[19:40] <derek-g> Waiting on my ubuntu phone guys. Keep going hard at it plz. - I want it asap.
[20:00] <jgdx> kenvandine, what has landed with re: to call forwarding/waiting? Or is it your WIP branch from May that holds all of it?
[20:05] <kenvandine> jgdx, it's all landed
[20:05] <kenvandine> at least single sim :)
[20:08] <jgdx> kenvandine, cool, thanks
[20:08] <pmcgowan> kenvandine, jgdx you guys see my email for updates?
[20:10] <kenvandine> pmcgowan, not yet, will be sure to respond soon
[20:10] <jgdx> pmcgowan, I'm responding atm
[20:10] <pmcgowan> thanks
[20:11] <kenvandine> pmcgowan, not yet, will be sure to respond soon
[20:11] <kenvandine> whoops
[20:11] <pmcgowan> department of redundancy department
[20:11] <kenvandine> :)
[20:12] <jgdx> pmcgowan, are there designs for call forwarding/wait for dual sim?
[20:12] <jgdx> kenvandine ^ (sorry if I am repeating myself)
[20:12] <pmcgowan> jgdx, I have not seen any
[20:12] <kenvandine> i haven't seen any
[20:13] <popey> pindonga: 404 https://myapps.developer.ubuntu.com/dev/click-apps/
[20:13] <pindonga> popey, deploy in progress most likely
[20:13] <pindonga> indeed
[20:13] <pindonga> :)
[20:13] <pindonga> will be fine in a sec
[20:13] <popey> well thats just rude
[20:13] <popey> ☻
[20:13]  * popey refers to previous conversation about error messages ☻
[20:14] <pindonga> popey, actually, the deploy exploded
[20:14] <popey> \o/
[20:14] <pindonga> trying to fix it now
[20:14] <popey> I'll leave that with you ☻
[20:27] <pindonga> popey, on it
[20:33] <pindonga> popey, should be back up
[20:33] <pindonga> popey, please let me know should you find any issues with it
[20:34] <popey> pindonga: will do
[20:40] <Chipaca> rsalveti: ping with a question about sound volumes, if you've got five
[20:40] <rsalveti> Chipaca: sure
[20:41] <Chipaca> rsalveti: so. I wasn't able to follow the sounds discussion to its end. Were you able to implement things at the pulseaudio level?
[20:41] <Chipaca> rsalveti: and if so, what arguments should i give paplay for it to do the right thing>
[20:41] <Chipaca> ?
[20:43] <rsalveti> Chipaca: ping me later this week again and I hopefully should have the answers for that :-)
[20:43] <rsalveti> I'm about to find them
[20:43] <Chipaca> rsalveti: ah, ok then
[20:44] <rsalveti> just landed handsfree, so focus is audio policy now
[20:44] <rsalveti> and a bunhc of bugfixes :-)
[20:44] <Chipaca> rsalveti: sweet. Will poke you again later this week then.
[20:44] <Chipaca> rsalveti: thanks
[20:46] <ajalkane> 404 on page http://developer.ubuntu.com/start/ubuntu-for-devices/image-channels/
[20:47] <ajalkane> for link http://developer.ubuntu.com/start/ubuntu-for-devices/image-channels/installation/
[20:52] <popey> ajalkane: you flashing a mako?
[20:53] <popey> ajalkane: mako == nexus 4.
[20:53] <ajalkane> popey: not flashing, just trying to setup ssh and WiFi access for deploying apps for developing. It's the image you flashed
[20:54] <popey> ah okay.
[20:54] <ajalkane> (if you know I should flash a newer image let me know)
[20:55] <popey> ajalkane: adb shell system-image-cli --info
[20:55] <popey> what version does it say?
[20:55] <popey> to enable ssh, do  "adb shell setprop persist.service.ssh true" then "adb reboot"
[20:56] <popey> mhall119: ^^ http://developer.ubuntu.com/start/ubuntu-for-devices/image-channels/installation/ 404's
[20:57] <ajalkane> popey: I'm not yet at the stage that adb detects the device... it's possible through WiFi or do I need to plug it in with USB?
[20:57] <mhall119> popey: where did you find a link to that url?
[20:57] <popey> you need to use usb
[20:57] <ajalkane> ok
[20:57] <popey> mhall119: ajalkane did
[20:57] <mhall119> where?
[20:58] <ajalkane> current build number: 157
[21:00] <popey> ajalkane: thats the latest devel image, that should be fine.
[21:01] <ajalkane> Okay great, thanks
[21:03] <popey> 21:46:54 < ajalkane> 404 on page http://developer.ubuntu.com/start/ubuntu-for-devices/image-channels/
[21:03] <popey> 21:47:06 < ajalkane> for link http://developer.ubuntu.com/start/ubuntu-for-devices/image-channels/installation/
[21:03] <popey> mhall119: ^
[21:07] <ajalkane> I'm trying to ssh to the device, but for some reason I get this:
[21:07] <ajalkane> ssh phablet@nexus
[21:07] <ajalkane> Permission denied (publickey).
[21:08] <ajalkane> I've removed all files in device's ~phablet/.ssh but still the same result
[21:08] <popey> I use "phablet-shell" to connect to mine
[21:09] <popey> which is in the phablet-tools package
[21:09] <ajalkane> This page recommends using ssh to access: https://wiki.ubuntu.com/Touch/ReleaseNotes#Accessing_the_system_for_development
[21:09] <jgdx> phablet-shell is ssh
[21:09] <popey> yeah, in the past "adb shell" was used and that was terrible
[21:09] <popey> so ssh was recommended
[21:10] <popey> phablet-shell just wraps up things nicely
[21:10] <ajalkane> I'll install phablet-shell and try
[21:10] <jgdx> ajalkane, pablet-shell will create a pubkey for you and push it to the device.
[21:10] <jgdx> IIRC
[21:10] <ajalkane> okay if it's just that non-publickeyauth is disallowed I can also push my own key there?
[21:10] <mhall119> popey: ajalkane:thanks, fixed the link
[21:11] <ajalkane> thanks mhall119
[21:11] <mhall119> ajalkane: for future reference, there's a button at the bottom of every page on developer.ubuntu.com for reporting problems like that
[21:11] <popey> ajalkane: yeah, you can put your own key on device
[21:11] <mhall119> it'll inject reference URLs and tags to help if find where it was encountered
[21:11] <ajalkane> mhall119: alright, good to know
[21:13] <jgdx> Saviq, hey, do you know if https://bugs.launchpad.net/unity8/+bug/1210199 also solves https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1288332 ?
[21:14] <Saviq> jgdx, the code for it exists, yes, but it's not clear that we'll manage that first one for RTM
[21:14] <Saviq> jgdx, so we should think of a plan B
[21:15] <Saviq> jgdx, which basically means that wherever we'd store the rotation lock value, we'd need to read it in UITK to stop the internal app rotation
[21:15] <Saviq> jgdx, or maybe even it'd make sense in lower levels, to disable sensors whenever the lock is on
[21:20] <jgdx> Saviq, the latter conforms with this spec [1] so I'm okay with that :P [1] https://wiki.ubuntu.com/StatusBar#rotation-lock
[21:20] <Chipaca> kenvandine: ping
[21:21] <Saviq> jgdx, yeah, it'd be a stop-gap while we don't have the shell dealing with all that
[21:22] <Saviq> jgdx, I'll have a chat with ricmm_ tomorrow about the sensors part
[21:23] <jgdx> Saviq, thanks.
[21:30] <ajalkane> Can Ubuntu SDK (QtCreator) be configured to deploy applications via WiFi or is USB connection to the device mandatory?
[21:31] <ajalkane> (I hate cables :)
[21:31] <nhaines> ajalkane: you're overthinking it.  You want to connect and deploy via network.  :)
[21:32] <nhaines> (I don't know if this is possible, though.)
[21:33] <ajalkane> Personally I think I'm trying to underthink it :)
[21:43] <ajalkane> I guess I need something? SDK returns this while trying to run on device:
[21:43] <ajalkane> Command returned 2: schroot -c click-ubuntu-sdk-14.04-armhf -- env DEB_HOST_GNU_CPU=arm DEB_HOST_GNU_SYSTEM=linux-gnueabihf DEB_BUILD_GNU_CPU=i686 DEB_BUILD_ARCH_BITS=32 DEB_HOST_ARCH_OS=linux DEB_BUILD_ARCH=i386 DEB_HOST_MULTIARCH=arm-linux-gnueabihf DEB_BUILD_ARCH_ENDIAN=little DEB_HOST_ARCH_ENDIAN=little DEB_HOST_ARCH_CPU=arm DEB_BUILD_ARCH_OS=linux DEB_HOST_ARCH_BITS=32 DEB_BUILD_GNU_SYSTEM=linux-gnu DEB_HOST_ARCH=armhf DEB_BUILD_ARCH_CPU=i386 DE
[22:00] <ajalkane> I'm using Ubuntu 14.04, do I need 14.10 development version before this works? Or will installing some libs make it work?
[22:00] <nhaines> You need the SDK PPA.
[22:01] <nhaines> (Unless you're running utopic)
[22:01] <ajalkane> I should have the PPA... I'll recheck
[22:02] <ajalkane> cat /etc/apt/sources.list.d/ubuntu-sdk-team-ppa-quantal.list
[22:02] <ajalkane> deb http://ppa.launchpad.net/ubuntu-sdk-team/ppa/ubuntu trusty main
[22:03] <ajalkane> So it should be okay. Any other checks I should run?
[22:06] <nhaines> I'm not an expert.  But that's the one that comes to mind.
[22:06] <ajalkane> ok thanks
[22:07] <ajalkane> Well, I have to go, but I'm staying on IRC and if some suggestions come I'll try reading them tomorrow
[22:07] <nhaines> Best way to use IRC.  Good luck. :)