[00:45] <bigjools> wgrant/StevenK: did the recipe builds change recently to append ~ubuntuNN instead of ~series?
[00:47] <wgrant> bigjools: Yes
[00:47] <wgrant> Ubuntu's used the version number for backports for a while, and we need to switch before u-series
[00:47] <bigjools> wgrant: ok.  you broke juju-core folks. haha :)
[00:47] <wgrant> Why are they depending on the version number?
[00:47] <wgrant> s/version number/structure of the version number/
[00:47] <wgrant> That's pretty broken
[00:47] <bigjools> stupidity I think :)
[00:47] <wgrant> Still
[00:48] <wgrant> That recipe is already pretty broken
[00:48] <wgrant> I'm going to close that tab and pretend I never saw it.
[00:48] <bigjools> heh
[04:00] <StevenK> wgrant: The next branches for buildd-manager are due RSN?
[04:00] <wgrant> Indeed
[07:44] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/buildd-manager-inlineCallbacks/+merge/183578
[07:55] <StevenK> wgrant: I'm wary of the the commit in the manager code
[07:57] <wgrant> StevenK: It's committing after it comes back from a Deferred
[07:57] <wgrant> Which doesn't make much sense.
[07:58] <wgrant> Though I'm surprised you noticed that in the merged diff.
[07:59] <StevenK> It's five lines into a green diff
[07:59] <wgrant> In fact, you couldn't have noticed. Which commit are you talking bout?
[07:59] <StevenK> 455	+ # Commit the changes done while possibly rescuing jobs, to
[07:59] <StevenK> 456	+ # avoid holding table locks.
[07:59] <StevenK> 457	+ transaction.commit()
[07:59] <wgrant> That's not new
[08:00] <wgrant> And it shouldn't do anything, but it's there to ensure that builder.currentjob is as up to date as possible.
[08:00] <StevenK> Oh, it's just moved from other twisted garbage
[08:00] <wgrant> I didn't change any code except for removing two xmlrpc.Fault wrappers.
[08:00] <StevenK> And I guess that is one of the commits that is not long for this world?
[08:01] <wgrant> Correct.
[08:01] <wgrant> We can't afford to calculate currentjob there.
[08:01] <wgrant> It will be precalculated, and that method won't touch the DB until further down.
[08:02] <StevenK> So thanks to a day of JavaScript and Twisted, my brain is now leaking out of my ears
[08:05] <StevenK> wgrant: r=me
[08:05] <StevenK> wgrant: Sorry, I got distracted
[08:07] <wgrant> Thanks
[09:01] <cjwatson> wgrant: Your buildd-manager-inlineCallbacks branch and my destroy-builder-aborted branch clash.  Which would you prefer to have landed first?
[09:06] <wgrant> cjwatson: I was deliberately waiting for yours to land, sorry.
[09:07] <cjwatson> OK, landing
[09:08] <wgrant> During the refactoring I discvoered something that I thought was just a production glitch a few months ago.
[09:08] <wgrant> A manualled, disabled builder won't get its current build terminated.
[09:09] <wgrant> Probably missed originally because of the convoluted callbacks. It makes no sense otherwise.
[09:16] <wgrant> cjwatson: test_binarypackagebuildbehavior still references AbortedSlave
[09:18] <cjwatson> what.  I grepped.
[09:19] <cjwatson> one moment :(
[09:19] <cjwatson> Oh, I must have only grepped buildmaster, damn
[09:19] <wgrant> Ah, yeah
[09:21] <cjwatson> Very confused by what buildbot just did
[09:21] <cjwatson> It successfully ran no tests
[09:22] <wgrant> It doesn't check the exit code due to an old lxc-start-ephemeral bug
[09:22] <wgrant> The testrunner probably died badly due to the import.
[09:29] <cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/testfix-destroy-builder-aborted/+merge/183598
[09:33] <wgrant> cjwatson: r=me
[09:34] <cjwatson> landing
[09:57] <stub> Anyone up for a Swift branch review? More /srv and /srv2 juggling underway it seems.
[10:02] <wgrant> I really should get to that eventually
[10:02] <wgrant> But the /srv and /srv2 juggling can't stop for at least a few months after we start using Swift


[02:06] <hugok> Hello, I have nexus 5, and when I used the ubunut-device-flash from the server appropriate for my device it installed the ubuntu cwm based recovery
[02:07] <hugok> how do I boot into ubuntu?
[02:09] <hugok> this channel is less active than the libreoffice irc, seriously?
[02:13] <hugok> welp i guess I'll look elsewhere
[06:23] <dholbach> good morning
[06:44] <afiskon> Hello. I realize this question could be frequently asked on this channel. But - is it really no way to close a running application in ubuntu touch?
[06:44] <lotuspsychje> afiskon: slide it down away
[06:45] <lotuspsychje> afiskon: you know when you slide from right, you see all windows in 3d
[06:45] <lotuspsychje> afiskon: then slide down an app to close
[06:48] <afiskon_> wow, cool! tnx :) maybe you could recommend some video or tutorial which explains all this UI related stuff?
[06:48] <lotuspsychje> afiskon_: alot of youtubes demonstrate yes
[06:48] <afiskon_> ok
[06:48] <lotuspsychje> afiskon_: wich device are you testing on?
[06:49] <afiskon_> lg nexus 4
[06:49] <lotuspsychje> nice
[06:49] <lotuspsychje> im on nexus 7 wifi 2013
[06:49] <afiskon_> i bought it specially for ubuntu touch :) took some time to deliver it in Russia
[06:50] <lotuspsychje> lol, same here
[06:50] <lotuspsychje> i specially bought my n7 for ubuntu
[06:50] <lotuspsychje> as android is unsafe as hell
[06:50] <lotuspsychje> at least were are more secure on tablet now
[07:47] <seb128> hum
[07:47] <seb128> mpt, so in the updates list, the ubuntu item should be different from the apps ones?
[07:47] <seb128> e.g the first one has no frame but the others have one?
[08:16] <JamesTait> Good morning all; happy Wonderful Weirdos Day! :-D
[08:16] <seb128> tvoss, hey, I've ubuntu-location-serviced which keeps using 100% cpu on my krillin when activating gps, let me know if you are interested to debug
[08:16] <seb128> tvoss, I put some info on bug #1358918
[08:16] <tvoss> seb128, yeah, that would be helpful. There should be debugging instructions on the bug report
[08:17] <tvoss> seb128, don't touch anything :) it's a really weird heisenbug
[08:17] <seb128> tvoss, well, it happened yesterday, my device when flat during the night and it's happening again today after a fresh boot
[08:17] <seb128> tvoss, I added the debug info to the bug, just not the dump because it was a bit big and I had to go yesterday before my dsl would have been upload to upload that
[08:17] <tvoss> seb128, I have a theory: The location service upstart job does not wait for the android container to be up
[08:18] <tvoss> seb128, anyway, any sort of trace would be very much appreciated
[08:18] <seb128> tvoss, well, killing the service doesn't fix it, it respawn in 100% cpu usage mode again
[08:19] <tvoss> seb128, yeah, that points towards the firmware being in a weird state
[08:19] <tvoss> seb128, or the gps chipset driver as provided by the android hal
[08:19] <tvoss> seb128, could you check if other processes are going havoc, too?
[08:19] <seb128> tvoss, no other process being weird that I can say
[08:20] <seb128> tvoss, http://paste.ubuntu.com/8297792/
[08:21] <tvoss> seb128, could you check with htop which thread is using a 100% cpu?
[08:21] <mpt> seb128, well just look at it. :-) It isn’t an app icon, and framing it like one makes it ugly
[08:22] <seb128> mpt, well, it doesn't mean we shouldn't have a better icon which works with a frame
[08:22] <mpt> seb128, are you suggesting we change the Ubuntu logo? ;-)
[08:22] <seb128> mpt, the reason that icon is blurry and not nice is because design didn't provide us an icon and we use one that happens to be on disk
[08:22] <seb128> mpt, no, but we could have a grey bg around the icon or something
[08:24] <seb128> tvoss, how do I do that in htop? I've 2 lines that use 100% cpu, pid 3459 and 2466
[08:26] <tvoss> seb128, you have switch to tree view mode
[08:26] <ogra_> seb128, did you just OTA upgrade ? iirc you need to re-run the wizard (and accept the licensing) for the location stuff to work properly
[08:27] <tvoss> seb128, hit 't'
[08:27] <mpt> seb128, I just discovered that the notifications API has the same problem as the ListItem API, just with the opposite default
[08:27] <ogra_> (or discard the licensing... i guess there is some setting you are missing if you did not)
[08:27] <tvoss> seb128, also: hitting s gets you an interactive strace view
[08:27] <popey> ogra_: how do you re-run the wizard?
[08:28] <ogra_> popey, enable it with phablet-config ... or remove the file it touches ... (i forgot the exact path, search for wizard_has_run or some such with find)
[08:29] <mpt> seb128, I’ll ask Benjamin what’s the appropriate process for fixing bugs like that and like bug 1289401
[08:30] <seb128> mpt, well, it's easy to fix those, just toggle the iconFrame property
[08:30] <seb128> tvoss, k, well I'm still unsure what info would be useful, 3466 is the pid that uses the cpu, but all the lists are labeled "u-l-s --bus system --provider gps::Provider"
[08:31] <popey> ogra_: kk, ta
[08:31] <seb128> ogra_, was that for me?
[08:31] <tvoss> seb128, could you just pastebin the output?
[08:31] <seb128> ogra_, i've no issue with things no working, I'm just trying to provide info for "location service use 100% cpu"
[08:32] <ogra_> seb128, yep
[08:33] <tvoss> ogra_, remind me, what was the upstart event for the android container being ready?
[08:33] <ogra_> tvoss, "android" ;)
[08:33] <tvoss> ogra_, wow, that was easy
[08:35] <seb128> tvoss, http://people.canonical.com/~seb128/debug.png
[08:40] <tvoss> seb128, that helps, know where it happens now
[08:40] <seb128> tvoss, from the screenshot? how? ;-)
[08:40] <tvoss> seb128, the lwp provided by htop corresponds to the lwp in the gdb backtrace
[08:40] <seb128> oh ok
[08:40] <tvoss> seb128, so it's thread 6 causing issues, and I'm pretty sure I know what's going on
[08:41] <seb128> tvoss, great
[08:41] <seb128> tvoss, seems like I can easy trigger the issue, so if you need more info/me to test a fix or patched version, let me know
[08:41] <tvoss> seb128, thanks for debugging
[08:41] <tvoss> seb128, yup
[08:41] <seb128> tvoss, yw!
[09:11] <mpt> Why does --channel=devel give me an older lock screen than --channel=ubuntu-touch/ubuntu-rtm/14.09-proposed does? I would have expected the opposite
[09:13] <ogra_> mpt, devel is the last promoted utopic image
[09:14] <zbenjamin> ajalkane: hey, thx for approving the MP
[09:14] <ogra_> mpt, this was released the day we opened the rtm distro
[09:14] <ogra_> no updates there since
[09:14] <mpt> oh
[09:14] <zbenjamin> ajalkane: i was not sure wether to disable the INSTALL_TESTS, could you check if that is required and if it is add it to the debian/rules file?
[09:15] <ogra_> mpt, if you want to see something newer try devel-proposed
[09:15] <mpt> ogra_, last week I thought I understood that devel was the best image to test and report bugs on
[09:15] <ogra_> that only works if we promote regulary
[09:15] <ogra_> it usually is, but the switch to rtm also switched our focus
[09:15]  * mpt reflashes
[09:16] <ogra_> the best thing to test against should be the promoted 14.09 image ... but rtm wasnt at a promotable quality yet
[09:16] <ogra_> so we currently only have 14.09-proposed
[09:16] <ogra_> (and devel-proposed)
[09:17] <mpt> Ok, I’ll use devel-proposed
[09:18] <ogra_> there is hope that we can promote an image this week, so things should get better soon
[09:19] <mpt> thanks ogra_
[09:40] <dpm> hi pitti, how are you? Thanks for looking at translations while I was away. Quick question: how often are the language packs for the RTM distro generated?
[09:51] <pitti> hey dpm
[09:51] <pitti> dpm: we now set up a weekly export; I didn't yet set up a cronjob for langpacsk
[09:51] <pitti> dpm: as currently I update the ubuntu packages manually once or twice a week and copy them into RTM
[10:21] <vitimiti> Hi
[10:40] <mailyaseen> hi.... any chances of whatsapp in ubuntu touch??
[10:41] <mailyaseen> i have install ubuntu touch on my nexus 4... its awesome...
[10:41] <mailyaseen> there is lot of improvement with respect to perfomance and the looks...
[10:41] <mailyaseen> i can consider ubuntu touch as my daily driver, only concern is whatsapp...
[10:42] <ogra_> no whatsapp yet ... but i heard sailfish has a client that might be not to hard to port over
[10:42] <dbarth_> uh, sorry if that's been asked before, but how come i get quicked out right after adb shell'ing into my device?
[10:42] <dbarth_> (i have dev. mode enabled, pin code set)
[10:42] <ogra_> dbarth_, youshouldnt get kicked out ...
[10:43] <mailyaseen> yes, there is native sailfish app, Mitakuuluu in sailfish OS
[10:43] <ogra_> mailyaseen, well, if someone ports it and uploads it to the store ... :)
[10:44] <mailyaseen> orga_ : it will be great...
[10:44] <ogra_> dbarth_, i dont get kicked out here ... and the smoke tests seems to work fine as well on todays image (FSVO well)
[10:45] <ogra_> dbarth_, what exactly did you do that kicked you out ?
[10:45] <dbarth_> ogra_: the device "avaiability" seems unstable
[10:45] <ogra_> stable here
[10:45] <dbarth_> ie adb devices shows the device is changing state
[10:45] <ogra_> weird
[10:45] <ogra_> i dont see that here
[10:46] <dbarth_> i see the battery icon switching from charging to not charging
[10:47] <ogra_> dbarth_, that sounds like your cable or something else physical is wrong/broken
[10:47] <dbarth_> had been working fine so far :/
[10:47] <dbarth_> i can try another cable
[10:48] <ogra_> also how is the charge level ?
[10:48] <mailyaseen> ogra_ : it seems Nexus status document is not updated??
[10:48] <dbarth_> 80% or so
[10:48] <ogra_> mailyaseen, might be ... popey ?
[10:49] <dbarth_> ogra_: same behavior with another cable
[10:49] <ogra_> strange
[10:49] <dbarth_> i've had console cables going wild, but they went to the bin
[10:49] <ogra_> it is definitely rock solid here
[10:50] <dbarth_> i guess i have somthing odd in my config
[10:50] <tbr> ogra_: I heard the mitakuulu dev tried to get a touch dev env set up but found this channel to be rather unhelpful so canceled his efforts
[10:50] <ogra_> dbarth_, any devbs installed ? writable/readonly etc ?
[10:50] <popey> mailyaseen: yeah, needs updating, will do
[10:50] <dbarth_> i just re-flashd to 234
[10:50] <ogra_> tbr, bah, he should have been directed to #ubuntu-app-devel by someone
[10:51] <tbr> ogra_: or it was there, not sure, but he said things didn't progress at all
[10:51] <dbarth_> so i can't blame debs; except if my 'citrain device-install' managed to do anything; but it was stuck until i realized dev. mode was enforced more strictly now
[10:51] <ogra_> dbarth_, i just OTAed to that ... (originally flashed 230) ... works as expected
[10:51] <dbarth_> so i think i have a clean r234
[10:57] <dbarth_> the battery charge stops going crazy whn i toggle off dev mode, and restarts if i turn it on; so it's linked
[10:57] <dbarth_> i will try to flash back to 221 for now
[10:57] <dbarth_> ogra_: or which r23x version would you recommnd?
[10:57] <dbarth_> 233, 232?
[10:58] <ogra_> 233 has teeh new adbd ...
[10:58] <ogra_> *the
[10:58] <dbarth_> ok, so anything before to do some A/B testing
[10:59] <ogra_> well, it would be good to know if 233 exposes this at all
[10:59] <ogra_> if not it must be some other landing causing it
[10:59] <ogra_> 234 had a new udev
[10:59] <ogra_> which could have some influence
[11:00] <ogra_> my mako is still connected fine here ... no disconnect
[11:00] <dbarth_> just to clarify, i am using 14.04 phablet-tools
[11:00] <mailyaseen> popey: u r going to update the document now? just wanted to have a look on the document once it is updated.. :)
[11:01] <ogra_> dbarth_, well, does it disconnect only if you use phablet tools ?
[11:01] <ogra_> dbarth_, or even on plan adb shell
[11:01] <popey> mailyaseen: there's not a lot to update to be fair
[11:01] <popey> mailyaseen: do you have specific questions?
[11:02] <dbarth_> ogra_: adb devices, it was seeing the device go on and off
[11:02] <mailyaseen> popey : after every restart, bluetooth, wifi and other things gets on, even if i switched it off, it wont stay... need to switch off after phone starts
[11:03] <ogra_> dbarth_, so not related to phablet-tools then
[11:03] <dbarth_> dmesg on my desktop showed the device was reconnecting every 5s or so
[11:03] <dbarth_> i'm doing a device flash --bootstrap, cause it couldn't see the adb interface stable enough + 542M left on recovery it said
[11:04] <dbarth_> i'll tell you just after the sandwich break ;)
[11:04] <ogra_> dbarth_, thanks
[11:04] <ogra_> i wonder if the issue is actually on the PC side ... android-tools-adb got updated alonside ... though without any changes
[11:04] <popey> mailyaseen: updated it
[11:05] <popey> mailyaseen: sounds like a known bug i think
[11:06] <mailyaseen> popey : ohh okay.. and a option to control display rotation will be included in next release?
[11:06] <ogra_> *before* release :)
[11:06] <ogra_> we didnt have an actual release yet
[11:06] <popey> mailyaseen: in progress
[11:06] <popey> mailyaseen: I'll add a line for that
[11:09] <mailyaseen> popey: thank you...
[11:13] <popey> np
[12:12] <mailyaseen> @CODeRUS... Developing for #UbuntuTouch - not this year. Please fix your buggy SDK first and invite me when done.
[12:12] <mailyaseen> CODeRus is the one who developed MitaKuuluu, native whatsapp client for SailFish OS
[12:20] <cwayne> you can make all the native whatsapp clients you want, whatsapp is still going to shut them down
[12:21] <tbr> cwayne: nope, mitakuulu survives nicely. it seems after removing all mentions of whatsapp (trademark) they have no handle on it and they probably didn't want to provoque another backlash
[12:30] <ogra_> dbarth_, any luck ?
[12:36] <popey> cwayne: there's an unofficial whatsapp client in FirefoxOS too.
[13:08] <dbarth_> ogra_: was still going wrong; until i stopped qtc
[13:08] <ogra_> dbarth_, oh !
[13:08] <dbarth_> ogra_: zaspire mentioned the problem occured with android as well
[13:08] <ogra_> dbarth_, so its SDK induced ?
[13:08] <dbarth_> ogra_: i think so
[13:08] <ogra_> zbenjamin, ^^^
[13:08] <ogra_> can you verify that ?
[13:09] <zbenjamin> let me try
[13:09] <zbenjamin> ogra_: i can, it has to be one of the scripts
[13:10] <ogra_> yippie !
[13:10] <ogra_> *rumpel* ...
[13:10] <ogra_> that was the stone that dropped off my heart
[13:10] <ogra_> :)
[13:10] <ogra_> zbenjamin, happy to help if you can identify the script
[13:11] <zbenjamin> ogra_: let me go through the scripts
[13:28] <Raaz> Hallo
[13:29] <zbenjamin> ogra_: its either http://pastebin.ubuntu.com/8299900/ or http://pastebin.ubuntu.com/8299899/
[13:29] <Raaz> is anyone here ?
[13:29] <jgdx> mpt, do you have a minute? It's re: bug 1287249 and bug 1301429
[13:29] <jgdx> Raaz, ask your question, please.
[13:29] <zbenjamin> ogra_: since i get no output from the second one its probably the first one
[13:29]  * zbenjamin tries
[13:29] <mpt> jgdx, yes
[13:30] <Raaz> im trying to get make my phone ubuntu  can anyone help
[13:30] <jgdx> mpt, is the ubuntu-system-settings wifi list design divering from the indicator-network's wifi list?
[13:31] <jgdx> !devices | Raaz
[13:31] <Raaz> Samsung G
[13:31] <Raaz> galaxy s3
[13:32] <Raaz> i dont think the ubuntu has it on that site ?
[13:32] <jgdx> mpt, you see, the wifi list in the indicator is just mirrored in ubuntu system settings* (* afaiui)
[13:32] <afiskon> I noticed that my ubuntu touch version is r203 while newer versions are available. Now i'm using devel branch with all updates. Maybe I should consider using some other branch, with more bugfixes included, etc? Or this is a bad idea since stability will affected?
[13:33] <Raaz> anyone can i make my android to ubuntu ?
[13:34] <mpt> jgdx, I think the former is a superset of the latter … They show the same networks listed in the same order, but u-s-s has the intro labels while indicator-network doesn’t
[13:34] <mpt> Does that make sense?
[13:35] <Raaz> sudo add-apt-repository how do i run this command ? Newbie here
[13:35]  * mpt discovers that 14.10 r234 on Mako has no Wi-Fi at all :-(
[13:36] <ogra_> zbenjamin, the first one works flawless if i call the command locally
[13:37] <zbenjamin> ogra_: the the same for me
[13:37] <zbenjamin> ogra_: i have no idea atm whats happening
[13:37] <jgdx> mpt, right.
[13:37] <ogra_> zbenjamin, how does "adb_shell" look like in the finctions you source at the top of number two ?
[13:38] <ogra_> *functions
[13:38] <mailyaseen> popey: unofficial whatsapp client in FFOS is Loqui IM.
[13:39] <ogra_> zbenjamin, must be either that or something "device_image_hardware" or "device_image_version" do
[13:39] <popey> mailyaseen: there is another, "connnect a2"
[13:43] <mailyaseen> popey: it will be great, if anyone one of this gets ported to UT...
[13:43] <mailyaseen> popey: then many will start UT as there daily driver... :)
[13:44] <popey> mailyaseen: feel free to port it ☻
[13:45] <mailyaseen> :)
[14:04] <zbenjamin> ogra_: ping
[14:04] <zbenjamin> ogra_: line 27 and 28 http://pastebin.ubuntu.com/8300137/
[14:05] <ogra_> zbenjamin, woah
[14:05] <ogra_> zbenjamin, only 27 actually
[14:05] <zbenjamin> ogra_: that code predates me so i have no idea if its required or not
[14:05] <ogra_> rip that out :)
[14:06] <zbenjamin> lol
[14:06] <ogra_> no, we never supported the "adb root" command ... it was just a no-op before
[14:06] <afiskon> Hey, guys. Could anyone answer on my last question please (17:32)? :(
[14:06] <sergiusens> zbenjamin: ogra_ pre flipping era and a left over even then
[14:07] <ogra_> sergiusens, yeah
[14:07] <popey> afiskon: yes ☻
[14:07] <zbenjamin> ogra_: what did it do?
[14:07] <sergiusens> afiskon: 17:32? we are not all on the same timezone
[14:07] <popey> afiskon: if you use a different branch then chances are your stability will be affected
[14:07] <sergiusens> zbenjamin: adb ran as user, adb root, given the proper toggles, allowed you to switch to root
[14:07] <afiskon> popey: I see. OK.
[14:07] <popey> afiskon: a proposed image hasn't been promoted recently, thats why
[14:07] <sergiusens> this is not something enabled on production devices
[14:07] <ogra_> zbenjamin, on android adbd starts as the shell user and with adb root you can switch to a full root user mode
[14:08] <ogra_> we dont allow that at all
[14:08] <zbenjamin> ogra_: sergiusens: ah ok
[14:08] <zbenjamin> thanks
[14:08] <ogra_> zbenjamin, so a bug against android-tools would help ... adbd should not crash ... it should just be a no-op
[14:08] <sergiusens> zbenjamin: you probably can get rid of the adb_root function comletely
[14:08] <ogra_> zbenjamin, feel free to assign me directly
[14:09] <zbenjamin> ogra_: there? https://bugs.launchpad.net/ubuntu/+source/android-tools
[14:09] <ogra_> yeah
[14:11] <ralsina_> Hello, anyone knows an API to check if the screen is locked?
[14:15] <zbenjamin> ogra_: whats your launchpad name?
[14:15] <ogra_> ogra ;)
[14:16] <zbenjamin> ogra_: seems i'm not allowed to assign you https://bugs.launchpad.net/ubuntu/+source/android-tools/+bug/1367304
[14:16]  * ogra_ hugs zbenjamin
[14:17] <zbenjamin> ogra_: you are welcome ;)
[14:23] <mhall119> didrocks: thanks for the sdk-libs seed review
[14:23] <didrocks> mhall119: yw!
[14:23] <mpt> jgdx, but bug 1287249 has nothing to do with System Settings vs. indicator
[14:23] <mhall119> zbenjamin: ^^ half-way there, I'm pinging cjwatson for input on the other
[14:24] <zbenjamin> mhall119: awesome!
[14:24] <jgdx> mpt, how come?
[14:25] <mpt> jgdx, because “Auto-join previous networks” isn’t in the indicator in the first place
[14:26] <jgdx> mpt, actually, where is "Auto-join previous networks"? I have never seen that element anywhere
[14:31] <mhall119> zbenjamin: second one is now approved
[14:31] <mhall119> zbenjamin: now all that's left is https://code.launchpad.net/~pete-woods/qtcreator-plugin-ubuntu/new-scope-template/+merge/233218
[14:32] <zbenjamin> mhall119: we will include it in the next release then
[14:33] <cjwatson> well, and the previous click upload landing so that I can safely top-approve that
[14:33] <cjwatson> but hopefully that's today
[14:36] <zbenjamin> jdstrand: ping, did you already land the debug policy that prevents rights from ~/.local/share when in confinement?
[14:38] <mpt> jgdx, it may have been hidden because NetworkManager isn’t smart enough yet to refrain from connecting
[14:40] <jgdx> mpt, or removed
[14:43] <mhall119> thanks zbenjamin
[14:48] <jdstrand> zbenjamin: that is in apparmor-easyprof-ubuntu 1.2.22 that landed in utopic yesterday
[14:48] <jdstrand> working on the rtm landing today
[14:48] <zbenjamin> jdstrand: so it should be in devel-proposed?
[14:49] <jdstrand> it is in utopic
[14:49] <jdstrand> oh right, should be
[14:49] <jdstrand> should be in devel-proposed. just verify if that version is installed
[14:50] <jdstrand> it landed less than 12 hours ago, so not sure if it hit that image or something else
[14:50] <jdstrand> s/something else/the next one/
[14:50] <zbenjamin> jdstrand: ii  apparmor-easyprof-ubuntu                             1.2.21  nope
[14:50] <zbenjamin> jdstrand: but now i know what to look for , thx
[14:51] <elopio> ping tedg: can you take a look here? https://code.launchpad.net/~canonical-platform-qa/reminders-app/fix1363599-upstart_and_sandbox/+merge/233832
[14:51] <elopio> was that what you had in mind to launch sandbox?
[14:51] <jdstrand> zbenjamin: np. you can also install it manually by remounting rw, dpkg -i..., remount ro (that is safe)
[14:51]  * tedg clicks
[14:51] <bzoltan> dbarth_: so here
[14:51] <dbarth_> bzoltan: i had issue with qtcreator-plugin-ubuntu 3.1.1+14.10.20140728.1-0ubuntu1~0trusty1
[14:51] <dbarth_> bzoltan: with adbd
[14:51] <bzoltan> dbarth_:  the 3.1.1+14.10.20140903.3-0ubuntu2~0trusty1	 should have the fix
[14:51] <zbenjamin> jdstrand: i need to wait for the package to be available before depending on it anyway. Everything else is just easy then
[14:52] <zbenjamin> dbarth_: at least i'm not the only one ;)
[14:52]  * jdstrand nods
[14:53] <bzoltan> dbarth_:  ahh... yet an archaeologist :)
[14:53] <bzoltan> zbenjamin:  it if OK if dbarth_ has an outdated SDK ... but you my son Brutus?
[14:54]  * zbenjamin hides ... NOT under the table
[14:54] <zbenjamin> bzoltan: i have an excuse, i hacked on core and system apps ;)
[14:54] <bzoltan> smart, very smart ... :D
[14:58] <tedg> elopio, Generally that works, I put a couple of comments inline.
[14:58] <elopio> thanks tedg.
[15:00] <elopio> tedg: any example of how to use libclick?
[15:00] <tedg> elopio, Probably the click utility itself is the best :-)
[15:01] <tedg> Though cjwatson may have a better example.
[15:01] <cjwatson> elopio: ubuntu-app-launch, url-dispatcher, and there are a couple of others; check reverse-dependencies of libclick-0.4-dev
[15:01] <tedg> cjwatson, He'd be most interested in Python examples
[15:02] <cjwatson> oh, click/commands/* is OK for that yes
[15:02] <cjwatson> /usr/lib/python3/dist-packages/click/commands/
[15:03] <elopio> I'm looking there. Thanks cjwatson
[15:03] <cjwatson> elopio: what are you trying to do?
[15:04] <elopio> cjwatson: get the version and directory of an installed package.
[15:04] <cjwatson> elopio: ok, that's easy enough, look at click/commands/list.py (the non-manifest mode) for the first and click/commands/pkgdir.py for the second
[15:05] <cjwatson> no doubt you'll want to put things together differently but that gives you the basic sequence of operations
[15:36] <elopio> cjwatson, tedg: calling subprocess.check_output(['click', 'pkgdir', 'com.ubuntu.reminders']) seems to me the clearer way to write it.
[15:36] <elopio> I no longer need the version, I think. I'm giving it a try.
[15:37] <tedg> elopio, The problem is that it makes you dependent on an unversioned interface, so that makes your test more fragile, and difficult to debug when it changes.
[15:38] <alecu> hola mandel! I guess that when you guys land this, a rebuild of the scope will be needed, right? https://code.launchpad.net/~mandel/ubuntu-download-manager/properties/+merge/233348
[15:38] <mandel> alecu, yes, but I'm also adding a mr for the scop to use the new properties
[15:40] <alecu> mandel: how will it look? where's the app icon taken from? will installations be able to be paused or cancelled? what happens when the user taps on the icon?
[15:40] <mandel> alecu, the info is grabbed from click with the app id (logo etc..)
[15:40] <cjwatson> elopio: This is also slower (300ms or so); if you can use libclick then you should.
[15:40] <mandel> alecu, charles is the one that knows more about how much will the indicator be allowed to interact with the downloads
[15:40] <alecu> mandel: yes, but the click is not available while you are downloading, right?
[15:41] <mandel> alecu, only click apps will have the click info
[15:41] <mandel> alecu, no idea, I'm just adding the properties, charles is the one dealing with the ui details, he said he was able to get the info
[15:42] <mandel> alecu, we can always add an icon property etc... which is my initial idea
[15:42] <alecu> mandel: I think we should just use "setShowInIndicator(false)" for the click scope.
[15:43] <mandel> alecu, design call I suppose
[15:43] <charles> mandel, alecu, the UI details are wireframed by Design at <https://docs.google.com/a/canonical.com/document/d/1OyHUg_uUfmhDNa-9UrMc1tZ_eH_99PEU_V2l1YFA1UY/edit#>
[15:45] <charles> mandel, alecu, design doesn't have any special cases for unpausible items. If pausing/resuming an item either doesn't make sense, or is problematic because of implementation, I'd say let's hide it from the indicator to keep things simple
[15:46] <mandel> charles, alecu I would spect the scope to be able to deal with paused downloads.. but I don't know the details
[15:46] <alecu> charles: I don't think pause is problematic, but I do think Cancel to be problematic
[15:46] <alecu> (otherwise we'll have to distinguish between network errors and the user choosing to cancel, both in the download manager, the dash preview widgets and the scope, and it sounds like a loooot of work to do at this point.)
[15:46] <charles> alecu, yeah let's not open that can of worms for RTM
[15:47] <alecu> charles: agreed
[15:47] <alecu> so, setShowInIndicator(false)
[15:47] <alecu>  ftw!
[15:47] <charles> alecu, unless download-manager has some option for making an item uncancellable, let's ShowInIndicator(false)
[15:47] <alecu> mandel: ^
[15:48] <mandel> alecu, charles I don't but I can add it as one of the properties and indicator can check that
[15:49] <elopio> cjwatson, tedg: ack. I will follow your advice.
[15:49] <alecu> charles: one other Q: can indicator take remote urls for the icons?
[15:50] <charles> alecu, erm not sure, that depends on the unity8 rendering. dednick_? ^
[15:51] <charles> mandel, alecu, I kind of like the idea of adding properties for "CanPause" (default to true if not present?) and "CanCancel" (same?), that way we could at least see alecu's downloads in the indicator
[15:52] <charles> mandel, alecu, that also handles the Design use case of "pause everything until I get to a hotspot"
[15:52] <charles> mandel, alecu: that would be my vote, but it depends on how much work this creates for the two of you...
[15:52] <dednick_> alecu: should be able to
[15:52] <alecu> great
[15:53] <dednick_> https://code.launchpad.net/~nick-dedekind/qmenumodel/icon-remote-uri/+merge/228680
[15:55] <seb128> kenvandine, I don't get why u-s-s started hitting all those issues on the keypad sound test
[15:55] <seb128> kenvandine, wfm locally
[15:58] <kenvandine> it's failing to scroll to click
[16:00] <kenvandine> seb128, and it only fails sometimes...
[16:00] <seb128> kenvandine, I don't get why, there is no scrolling to do in that screen
[16:02] <kenvandine> seb128, yeah, but it still uses swipe_into_view
[16:03] <kenvandine> which isn't necessarily needed on that page
[16:03] <kenvandine> File "/usr/lib/python3/dist-packages/ubuntuuitoolkit/_custom_proxy_objects/_flickable.py", line 119, in _swipe_non_visible_child_into_view
[16:03] <kenvandine>     "Couldn't swipe in the flickable.")
[16:03] <kenvandine> sounds like maybe it thinks it's not visible?
[16:03] <kenvandine> or rather it is actually not visible
[16:03] <kenvandine> seb128, i would say a uitk change, but tests pass sometimes...
[16:04] <seb128> kenvandine, is that setting visible conditional to having a sim or something?
[16:05] <kenvandine> shouldn't be
[16:06] <kenvandine> maybe...
[16:06] <kenvandine> seb128, no... that setting is always there
[16:06] <seb128> :-/
[16:07] <kenvandine> there is a loader in the list though, that loads different items depending on single sim or multi sim
[16:07] <kenvandine> but that setting stays
[16:10] <kenvandine> seb128, oh... interesting... the dialpad test isn't failing because of the setting, its failing in go_to_phone_page
[16:10] <kenvandine> so the swipe is on the main window
[16:10] <seb128> oh
[16:10] <kenvandine> maybe it's because of the updates available?
[16:10] <seb128> kenvandine, I wonder..*
[16:10] <kenvandine> that messes these things up
[16:10] <seb128> yeah, I was going to say
[16:10] <seb128> we need to turn that off :p
[16:17] <cjwatson> jdstrand: is bug 1342858 still a thing on any your systems?
[16:17] <cjwatson> *any of
[16:18] <cjwatson> jdstrand: just wondering if so, if I could get "find /opt/click.ubuntu.com -ls" output
[16:18] <elopio> tedg: for your other comment, if don't use the aa-exec I get http://paste.ubuntu.com/8301110/
[16:19] <elopio> if I put the path to the bin dir, I get qml/reminders.qml does not exist at any of the standard paths
[16:20] <tedg> elopio, Hmm, okay. I know why that is, let me think about it a bit.
[16:33] <jdstrand> cjwatson: very much so
[16:33] <kenvandine> seb128, can you look at https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/updates-battery-check/+merge/233593
[16:33] <kenvandine> seb128, again :)
[16:36] <mhall119> zbenjamin: has all of the Unity/Dash work you needed to launch scopes form QtC landed in the -proposed images now?
[16:36] <jdstrand> cjwatson: http://people.canonical.com/~jamie/cjwatson/
[16:36] <jdstrand> cjwatson: http://people.canonical.com/~jamie/cjwatson/cjwatson-1342858.txt.gz
[16:38] <jdstrand> cjwatson: fyi, I currently have 252 json files in /var/lib/apparmor/clicks but only 113 apps listed with 'click list'. so, some apps do ship multiple profiles, but most apps do not
[16:40] <cjwatson> jdstrand: would it be OK to attach that to the bug?  I shouldn't have thought it'd be private
[16:41] <jdstrand> I can attach it
[16:41] <cjwatson> thanks
[16:41] <cjwatson> I have some ideas for addressing it
[16:41] <cjwatson> but wanted to make sure my theories were correct
[16:44] <jdstrand> cjwatson: attached
[16:48] <cjwatson> jdstrand: sorry, could I have "find /usr/share/click/preinstalled -ls" too?  forgot about that
[16:49] <seb128> kenvandine, that still has the "it takes some 15-30 seconds to get the dialog after the bar hit 100%"
[16:50] <seb128> kenvandine, not really a blocker, but it's a bit annoying since it makes you wonder what's going on
[16:50] <jdstrand> cjwatson: sure
[16:50] <elopio> tedg: ok. And I have a new problem. Next step is to launch reminders with a temporary home directory, but ubuntu-app-launch complaints about not finding the desktop file, and it logs that on /home/phablet, so I'm probably missing something.
[16:50] <elopio> it's really weird because it finds the -s argument, which is only on the desktop file on the temp dir. And then complaints about not finding the desktop file.
[17:09] <jgdx> kenvandine, thanks for the review. Pushed fix
[17:20] <kenvandine> jgdx, thx
[17:20] <kenvandine> seb128, thx :)
[17:20] <kenvandine> seb128, that delay shouldn't be related to my change
[17:20] <kenvandine> it's when UpdateManager emits the signal
[17:23] <kenvandine> jgdx, actually... the bottom anchor is probably not right
[17:24] <kenvandine> jgdx, top and bottom should get ignored there because you have fill
[17:26] <seb128> kenvandine, k
[17:26] <seb128> kenvandine, fill doesn't work well with flickable, you need left/right
[17:35] <kenvandine> jgdx, ^^ what seb128 said
[17:36] <kenvandine> also... i'm finding some brokeness in the wifi plugin, not related to your branch
[17:36] <kenvandine> like bottomMargin failing to be set.. and some weird animation for bottomMargin when the keyboard shows
[17:37] <kenvandine> and it calls positionViewAtIndex on the repeater, which doesn't exist
[17:37] <kenvandine> fortunately, that never happens right now because setting bottomMargin fails :)
[17:37] <kenvandine> i'm thinking we can just remove that...
[17:38] <kenvandine> bottomMargin: Qt.inputMethod.visible ? (Qt.inputMethod.keyboardRectangle.height - main.anchors.bottomMargin) : 0
[17:38] <kenvandine> main isn't defined
[18:07] <popey> tedg: you about?
[18:13] <elopio> mandel: lool: I'm picking up the testing of the location silo from rvr.
[18:13] <lool> elopio: awesome, thanks
[18:16] <lool> elopio: to avoid same issues as with rvr: 1) start fmor latest rtm image; 2) dist-upgrade to latest packages; 3) ideally test this with an unlocked SIM
[18:17] <elopio> lool: I'm flashing #27 on krillin, unlocked sim. I'll let you know if I get stuck.
[18:17] <lool> elopio: ack
[18:26] <kenvandine> barry, i have a device that is reliably reproducing bug 1365646
[18:26] <kenvandine> barry, just started happening today... yesterday it was fine
[18:27] <barry> kenvandine: that's pretty interesting.  can you attach /var/log/system-image/client.log to the bug?
[18:27] <kenvandine> i did :)
[18:28] <kenvandine> along with a theory
[18:29] <kenvandine> barry, note the checking for updates on both the main and updates pages hasn't changed
[18:29] <kenvandine> barry, although, the other day i was messing with changing that behavior, so we don't check on both... but that's not what i have installed right now
[18:29] <barry> kenvandine: interestingly, there's no traceback in the log file
[18:30] <kenvandine> yeah, but there is in the crash file
[18:31] <barry> i guess that can make sense
[18:32] <kenvandine> barry, http://pastebin.ubuntu.com/8302163/
[18:32] <kenvandine> barry, i'm on image 233
[18:32] <kenvandine> i can reliably reproduce it if i wait on the main view for 10 seconds or so
[18:33] <kenvandine> if i very quickly click on updates
[18:33] <kenvandine> it doesn't crash
[18:33] <barry> kenvandine: that could be a good clue.  let me update my n10 and see if i can reproduce
[18:33] <kenvandine> barry, cool
[18:33] <kenvandine> barry, however... i test this path nearly daily... never hit it before
[18:33] <kenvandine> which is puzzling
[18:34] <kenvandine> system-image-dbus crashes each time
[18:34] <barry> kenvandine: indeed, since it's been quite a while since there's been a new system-image.  do you know when the last time system-settings was updated?
[18:34] <elopio> lool or mandel: the first test, which I guess is using a dummy provider doesn't seem to work for me.
[18:35] <elopio> this was left on the terminal :http://paste.ubuntu.com/8302187/
[18:36] <lool> elopio: which app was this with?
[18:36] <lool> elopio: also, did you --wipe to run the tests?
[18:37] <elopio> lool: I wiped. And it was web browser on google maps.
[18:37] <lool> elopio: could you try with OSM app?
[18:37] <elopio> lool: yes, give me some time.
[18:40] <elopio> lool: same error when I open osmtouch.
[18:40] <lool> elopio: even if you press the location button a couple of times?
[18:41] <elopio> when I click the button to show my location, it says no gps available, position is approximate. And it shows the province next to mine.
[18:41] <kenvandine> barry, nearly daily :)
[18:41] <lool> elopio: and that's with the dummy provider instead of the regular service step?
[18:41] <kenvandine> barry, but it's been a while since the update plugin has changed
[18:42] <cwayne> lool: FWIW im able to see my correct location in ubuntu-espoo-provider.log, but never in any apps
[18:42] <lool> cwayne: that's what landing 6 ppa is supposed to fix
[18:42] <elopio> lool: yes. I'm just following the first step of the plan: https://wiki.ubuntu.com/Process/Merges/TestPlan/location-service
[18:42] <barry> kenvandine: okay ;)  we've seen new races w/settings updates before.  anyway it looks like i'm on r231
[18:43] <lool> elopio: I'm reflashed both phones in the mean time, let me try dummy provider will be right with you
[18:44] <ybon> lool: I see changes around location-service, anything that will need to be done in OSMTouch you think?
[18:44] <lool> ybon: should not be
[18:44] <ybon> okay
[18:45] <kenvandine> barry, a few weeks ago seb128 did some UI cleanup, but nothing that should change the UpdateManager code
[18:46] <barry> kenvandine: ack
[18:47] <lool> elopio: so I see the error, and it's indeed not going to the eiffel tower; it's quite possible we've broken the way the dummy provider works with the latest change
[18:47] <lool> elopio: would you mind downgrading the packages to the rtm versions and see whether the dummy provider works there?
[18:48] <lool> apt-get install ubuntu-location-service-bin=2.0.1+14.10.20140825-0ubuntu1 libubuntu-location-service2=2.0.1+14.10.20140825-0ubuntu1
[18:49] <kenvandine> barry, also... i just verified i can't reproduce this on my krillin using the rtm channel, which is now has the same version of system-settings as utopic-proposed
[18:49] <kenvandine> barry, the other day i was twiddling my channel.ini file to make it show me updates...
[18:49] <kenvandine> any chance i got it confused?
[18:49] <seb128> kenvandine, what's the issue?
[18:50] <barry> kenvandine: i think i have to figure out the new adb shell stuff now
[18:50] <barry> kenvandine: it might be, but i can't think of a change to the ini that would cause this race
[18:50] <barry> well unless you fiddled with the timeout
[18:50] <lool> elopio: so in my testing with above apt-get, the dummy provider doesn't work with prior version either
[18:51] <kenvandine> seb128, bug 1365646
[18:51] <kenvandine> seb128, i just started hitting this with my mako... and i can reliably reproduce it
[18:51] <elopio> lool: one second, I'm getting back my original sources.
[18:52] <kenvandine> seb128, it only crashes if i wait for the update check for the update notification on the main page to finish before switching to the updates panel
[18:52] <seb128> kenvandine, hum, k, I didn't see that one I think
[18:52] <kenvandine> seb128, if i quickly click on updates... before it's finished, it doesn't crash
[18:52] <seb128> kenvandine, using the mock with system+click updates on desktop u-s-s update panel segfaults though
[18:52] <kenvandine> and prompts me for the system update
[18:52] <kenvandine> system-image-dbus and system-settings crash
[18:53] <kenvandine> but only if i wait for the first check to finish before clicking updates :)
[18:53] <kenvandine> and only if there's a system update available
[18:53] <kenvandine> seb128, i can't reproduce it at all with my other device... running the same version of settings
[18:54] <kenvandine> which makes me wonder if i got my mako in a weird state... i kept trying to trick it to make it prompt me for system updates last week :)
[18:54] <dobey> is terminal app not unconfined? tried to run a shell script and i get permission denied on /bin/bash
[18:55] <elopio> lool: I would return this silo until the test plan can be fully executed. Or do you have an alternate proposal?
[18:55] <lool> elopio: I think the test plan is wrong
[18:55] <lool> elopio: the approach can't work with the trust store
[18:56] <barry> kenvandine, seb128 dang, it's been a while.  how do i enable adb shell on my device now?
[18:56] <lool> elopio: /usr/share/upstart/sessions/ubuntu-location-service-trust-stored.conf
[18:56] <lool> stop on stopping JOB=dbus or (:sys:stopped JOB=ubuntu-location-service)
[18:57] <kenvandine> barry, put it in developer mode
[18:57] <kenvandine> barry, which is under about in system-settings
[18:58] <lool> elopio: to get a dummy provider, you have to set some android props
[18:58] <ogra_> slangasek, i have a pam question ... i need to have something hooked into pam that disables developer mode if the password is unset or locked, i was planning to use pam_exec for that with a shell script attached, is there any way for me to knowteh password state without having o make the module pipe it to stdin of my script ?
[18:58] <lool> elopio: run setprop custom.location.fake true
[18:58] <tedg> popey, back
[18:58] <barry> kenvandine: got it, but um, the pin choose dialogs cannot be typed into :(
[18:58] <kenvandine> ?
[18:58] <tedg> elopio, I'm confused what you mean by temporary home directory? You created a new user?
[18:59] <kenvandine> barry, no OSK?
[18:59] <bzoltan> popey: bfiller: I have sent you a mail with a list of MRs for a bunch of apps. Taking those fixes would improve the SDK story big time. We could just direct new developers to any of the system or core apps and tell them to open them in the SDK and run it on the device. That woud be a huge motivation for devs.
[18:59] <barry> kenvandine: no osk
[18:59] <elopio> tedg: not create a new user. Change the HOME env vars to point to /tmp/tmpXXXXX
[18:59]  * kenvandine grumbles
[18:59] <kenvandine> barry, go to security and privacy
[19:00] <kenvandine> and set it
[19:00] <kenvandine> then come back :)
[19:00]  * kenvandine wonders what was in 231
[19:00] <elopio> lool: let me try.
[19:00] <kenvandine> oh... the n10... ?
[19:00] <popey> bzoltan: yeah, we're working through them
[19:00] <barry> kenvandine: no osk there either :(
[19:00] <barry> kenvandine: yep, n10
[19:00] <kenvandine> never tested that stuff on a tablet...
[19:01] <lool> mandel: you around?
[19:01] <kenvandine> also not sure if manta 231 is the same as mako 231
[19:01] <tedg> elopio, You kinda need to change that before logging in.
[19:02] <tedg> elopio, Upstart and everything else use that variable.
[19:02] <barry> kenvandine: i guess i should just reflash it
[19:02] <tedg> elopio, So it kinda needs to be a new user.
[19:02] <kenvandine> barry, when you flash it, you can set developer mode and the pass
[19:02] <barry> no osk for passphrase it either
[19:02] <barry> kenvandine: yep
[19:02] <kenvandine> sigh...
[19:02]  * barry tries
[19:03] <popey> tedg: could you join us #ubuntu-touch-meeting?
[19:03]  * kenvandine wonders if those ever worked on manta
[19:03] <popey> tedg: could you join us #ubuntu-touch-meeting?
[19:03] <popey> oops
[19:05] <lool> elopio: I've screwed my install after trying to remove the trustdb; I'm never prompted anymore
[19:05] <lool> gosh
[19:05] <lool> elopio: and it doesn't work from web
[19:06] <lool> elopio: but clearly, the testplan can't work with the packages we have today; it says to run things which wont work IMO
[19:06] <bfiller> bzoltan: I will take a look
[19:06] <lool> elopio: too bad I'm finding this out now, cause the change is actually unrelated
[19:07] <slangasek> ogra_: what do you mean by "password state"?  I don't think I understand what you're describing
[19:08] <ogra_> slangasek, if the user switches his phone to "swipe" the password gets unset ...
[19:08] <elopio> lool: I'm a couple of steps behind. With that setprop line, it still doesn't work.
[19:08] <ogra_> slangasek, in that case the dev mode needs to be disabled immediately by design
[19:08] <slangasek> ogra_: what does "disabled" mean?
[19:08] <ogra_> changing the config of the android gadget driver
[19:09] <ogra_> via android-gadget-service disable adb ... or the dbus call that sits behind this
[19:09] <elopio> lool: I know it's not a regression you are introducing. But there are two bad things: somebody landed something without running the test plan and introduced the regression at some point. And who proposed this silo, I guess mandel, also didn't run the test plan because we found out until the last phase were we should care only on exploratory.
[19:09] <slangasek> ogra_: and how does this account for the testing lab use case?
[19:09] <ogra_> slangasek, not at all ... they dont unset the PW during tests
[19:09] <elopio> lool: so, are you ok with me returning the silo, reporting a bug and asking you or any other dev to run the test plan before proposing the silo again?
[19:10] <slangasek> ogra_: so what is it set to?
[19:10] <swordfish> Hi tedg, David rerouted me here to you as official url-dispatcher expert :) ... The idea is to use the url-dispatcher to open the terminal emulator with a custom working directory. This should work fine if the app is not started yet but I'm trying to figure out a way to handle url-dispatch events when the application is already running (the behavior will be to open a new tab in the new directory). Is that pos
[19:10] <swordfish> sible with the current apis and are there some applications already doing that? Thank you in advance...
[19:10] <ogra_> slangasek, what now ? the password during tests ?
[19:10] <elopio> tedg: so, ubuntu-app-launch will never work by just updating the HOME ?
[19:10] <slangasek> ogra_: how is "unset the pw" different from "have never set the pw"?  (since I assume you need to have the password unset for testing, so that swipe to unlock works for autopilot)
[19:11] <ogra_> slangasek, oh, thats the same indeed :)
[19:11] <slangasek> ogra_: so that's a case where adb has to work, on a system with no pw
[19:11] <ogra_> and no we dont have a test for this
[19:11] <slangasek> which makes me nervous about hooking into pam for it
[19:11] <slangasek> I'm not concerned about tests /for this/; I'm concerned about these changes being compatible /with autotesting/
[19:12] <ogra_> slangasek, right, i'll work out something for this once we get there :)
[19:12]  * balloons listens in
[19:12] <ogra_> for now this is the last bit that blocks me from landing dev mode in rtm ... adb needs to be disabled if the user unsets the PW
[19:12] <lool> elopio: exactly
[19:13] <lool> elopio: do we need to throwaway the silo
[19:13] <lool> elopio: or can we keep it with an updated testplan tomorrow?
[19:13] <tedg> swordfish, Yes, that API exists you need a http://developer.ubuntu.com/api/qml/sdk-14.10/Ubuntu.Components.UriHandler/
[19:13] <ogra_> slangasek, if i use a script like described i can make it read an evn var the the test suite puts in place etc ...
[19:13] <lool> elopio: if you just mean QA returning it, yes, that's fair
[19:13] <tedg> elopio, It'll be odd behavior, you're going to have to set HOME in the Upstart environment variable context. I think things will get weird quick.
[19:13] <elopio> lool: I don't know about that. I would say you can keep it if it's not for too long, but you would have to ask the trainguards.
[19:14] <tedg> elopio, UAL will pass that on and work with it, but everything else is gonna get funky.
[19:14] <ogra_> slangasek, my main concern is how to implement it in the first place and if pam_exec can give me the info without me having to parse the password lenght or some such
[19:14] <lool> elopio: FYI the setprop approach was insufficient, albeit it was required -- setprop custom.location.fake true; restart ubuntu-location-service
[19:14] <balloons> ogra_, would there be a way then to systematically set and unset developer mode?
[19:14] <slangasek> ogra_: ok; I think the testing case needs to be part of the design on the ground floor
[19:15] <slangasek> ogra_: so I think you shouldn't parse the password at all - and not necessarily even change the password when changing the password method
[19:15] <balloons> we're already there, we need to be able to run tests against file manager and terminal which have PAM implemented and they fail
[19:15] <ogra_> but we have no test for what you ask for ... not even remotely any testing of the password stuff ... i'll happily help to develop it once we get to that
[19:15] <slangasek> ogra_: can't the state about the authentication mode be stored as a config setting directly at the time you make the change?
[19:15] <kenvandine> barry, ok... so looking closer on krillin with rtm image 26, settings doesn't crash
[19:15] <slangasek> ogra_: I'm *not talking about testing the password stuff*
[19:15] <kenvandine> but system-image-dbus does crash
[19:15] <ogra_> slangasek, but that is how the password handling is implemented now
[19:15] <slangasek> ogra_: I'm talking about your changes *breaking all adb access for the existing smoketests*
[19:15] <kenvandine> barry, same traceback
[19:16] <elopio> tedg: I'm updating the upstart variable and the $HOME env var too. We are copying many folders from the real home so app armor doesn't complain. And we can copy anything else required. But I don't like the new user approach because we would have to restart unity for each test.
[19:16] <ogra_> slangasek, sorry, i dont get it ... my stuff is in utopic and the smoke tests are largely fine ...
[19:16] <slangasek> ogra_: this piece that you're talking about isn't in, or you wouldn't be asking me about it :)
[19:16] <swordfish> tedg, thank you! That's perfect!
[19:16] <barry> kenvandine: okay.  i'm giving up on n10 and trying krillin but i haven't flashed or repartitioned it before
[19:16] <slangasek> ogra_: you're talking about developer mode being disabled when swipe-to-unlock is enabled
[19:16] <kenvandine> barry, that'll take a little time... hopefully i've given you some useful info
[19:17] <slangasek> ogra_: and if that's the only rule, that's incompatible with automated smoke tests
[19:17] <ogra_> slangasek, why ?
[19:17] <barry> kenvandine: at least i know who to ping now if i need more :)
[19:17] <tedg> elopio, So what you're going to end up with is a blend of which home directory everything thinks it's in. Content hub, the app, etc. etc. It's going to get funky.
[19:17] <slangasek> because we don't set a password during smoke tests
[19:17] <ogra_> we dont have any lock mechanism in place in the tests today
[19:17] <slangasek> and adb *must work*
[19:17] <ogra_> slangasek, we do
[19:17] <ogra_> since about a week
[19:17] <slangasek> ah
[19:17] <slangasek> well, that's not a good thing either ;)
[19:18] <ogra_> right
[19:18] <tedg> elopio, I don't have a specific thing that'll break, but I don't think it's a good approach.
[19:18] <ogra_> but not different to how tests have run before
[19:18] <tedg> elopio, Complain in #ubuntu-unity about how long it takes Unity to start ;-)
[19:18] <slangasek> ogra_: it is different; before, the tests ran without a password required
[19:18] <ogra_> we need to add functions for this
[19:18] <elopio> tedg: do you have any alternate proposal? Something that doesn't require a unity rerstart, but that will keep all the user data clean?
[19:18] <ogra_> but not right now
[19:18] <sergiusens> slangasek: ogra_ but doesn't the greeter implement something to work around this? I don't want to have the logic spread out to every component
[19:18] <ogra_> sergiusens, yes
[19:19] <tedg> elopio, No, I think you need to restart Unity, otherwise it'll have cached values (i.e. screenshot of the app)
[19:19] <sergiusens> I'd rather have a inhibit adb without password toggles in place
[19:19] <slangasek> so I think pam_exec is a possible solution here
[19:19] <slangasek> but that it should query a flag that's set when you change the unlock method in the UI
[19:19] <ogra_> sergiusens, but slangasek is right that we somehow need to test the password stuff, locking etc
[19:19] <balloons> ogra_, I agree with slangasek.. The terminal and file manager tests are broken now, and apart from trying to work around them inside the test, they really need to run without a password required
[19:19] <ogra_> but thats not in place today
[19:19] <slangasek> and not have it be a query of the password database itself
[19:19] <elopio> tedg: well, my complaint is because nobody seems to think about testability features. Anything from quick unity restart, to a backup and reset command will do.
[19:20] <slangasek> ogra_: "slangasek is right" - er, I'm right about a thing I was not talking about at all? :)
[19:20] <ogra_> slangasek, hmm
[19:20] <elopio> but what we are finding at every step is that things are not easy to automate.
[19:20] <ogra_> slangasek, well, you said we need to take password handling into account ... which i agree to
[19:21] <ogra_> but there are no tests for this today
[19:21] <slangasek> that is not what I was talking about
[19:22] <slangasek> balloons says that the existing tests have already been broken
[19:22] <ogra_> slangasek, no, but what i initially understood :) sorry, you only ignited a thought
[19:22] <slangasek> that's what I'm concerned about
[19:22] <ogra_> slangasek, right, i heard that after the LT meeting from him
[19:22] <slangasek> ok
[19:22] <ogra_> but there is no way we drop the passwords
[19:22] <elopio> lool: I get restart: Unknown job: ubuntu-location-service
[19:23] <elopio> I restarted ubuntu-location-service-trust-stored, but it still fails.
[19:23] <ogra_> unless the security team can tell me how without ripping a giant security hole into their design
[19:23] <lool> elopio: are you running the restart as root?
[19:23] <lool> elopio: ubuntu-location-service is system service; sorry should have been clearer
[19:24] <ogra_> balloons, but you said you knew about it and were planning to work on it anyway ...
[19:25] <balloons> ogra_, yes, I knew it was coming. But my expectation was that the feature would have some testability in mind. I wish this conversation had happened sooner, but here we are
[19:25] <slangasek> ogra_: it needs to be a setting at the provisioning phase
[19:26] <ogra_> slangasek, well there it already is --developer-mode and --password=1234 or some such are used
[19:26] <elopio> lool: I ran the commands with sudo and still get the error.
[19:26] <ogra_> i dont see why AP cant punch in the password in the UI when required
[19:26] <slangasek> ogra_: and what does --developer-mode without --password do?
[19:26] <slangasek> well, it probably can
[19:26] <ogra_> slangasek, it enables dev mode and sets a password
[19:26] <ogra_> right
[19:26] <slangasek> /without/ --password
[19:27] <lool> elopio: that's kindaweird
[19:27] <elopio> lool: I'm sorry, I need to go for lunch now. If you update the test plan and run it all, I can test again later today or tomorrow.
[19:27] <slangasek> it probably can, but then that makes your tests depend on the OSK
[19:27] <lool> elopio: yup, thanks
[19:27] <slangasek> so then, is this actually the thing you want to be testing
[19:27] <ogra_> slangasek, the OSK isnt used at all in smoke testing anywhere
[19:27] <ogra_> it is explicitly disabled during tests
[19:27] <slangasek> so how does the "punching in" happen?
[19:28] <ogra_> directly via /dev/uinput i think
[19:28] <ogra_> you need to ask an AP persom :)
[19:28] <slangasek> I think it's pointless for our design to require a password for the smoketests
[19:28] <slangasek> ah
[19:28] <slangasek> ok, that's certainly better than OSK
[19:28] <slangasek> but it's still added complexity
[19:28] <ogra_> slangasek, well, the security design requires adb to refuse to start when no password is set
[19:28] <balloons> we are migrating to using the OSK and yes you are right ogra, though it's not disabled during tests in general
[19:28] <ogra_> which is whats in the image today
[19:29] <slangasek> one of the other things we talked about was adb not accepting connections when the screen is locked
[19:29] <slangasek> this is fundamentally incompatible with smoketesting :)
[19:29] <ogra_> this is not implemented yet (but on my list)
[19:29] <slangasek> where is this list?
[19:29] <ogra_> * disable when password is unset
[19:29] <ogra_> * fix the last minot UI glitch
[19:30] <ogra_> * implement the unlocking integration
[19:30] <ogra_> there it is
[19:30] <ogra_> *minor
[19:30] <slangasek> so what are the provisions in this design for auto-testing of phones that have no one to run their finger across the screen to unlock them?
[19:31] <ogra_> slangasek, unity8 ships an unlock tool
[19:31] <ogra_> in its AP test
[19:31] <ogra_> which completely unlocks the screen password or not
[19:32] <slangasek> I don't think you're understanding
[19:32] <slangasek> you provision the phone
[19:32] <slangasek> it reboots
[19:32] <slangasek> it comes up with the splash screen which requires swiping to unlock
[19:32] <ogra_> and with adb enabled and a pw set
[19:32] <slangasek> you apply a policy to adb that says it doesn't accept connections when the screen is locked
[19:32] <slangasek> how do you get into the phone to run the unlock tool?
[19:32] <ogra_> which lets you adb shell in an call the screen unlock script
[19:33] <lool> elopio: aha, I've got the dummy provider to work :-)
[19:33] <slangasek> the policy I heard was that adb would not accept connections when the screen is "locked" (which includes the swipe-to-unlock case)
[19:33] <slangasek> there *must* be an override for this policy for the auto-testing case
[19:33] <ogra_> slangasek, i guess i'll hook something into --developer-mode then, that allows overridng that policy
[19:34] <slangasek> ok, so do that first, and then the rest of my concerns go away ;)
[19:34] <ogra_> beyond. i'm not even sure i'll do the unlock stuff ... we have key exchange ability in adbd which is the other option for this issue
[19:34] <ogra_> in any case thats not my issue today
[19:35] <slangasek> it needs to be part of the design of the whole
[19:35] <ogra_> i need to land this tomorrow and just need to make sure the gadget reacts when the pw gets unset so the device doesnt get into an inconsistent state
[19:35] <ogra_> (gadget on, adbd off)
[19:36] <slangasek> right; and for that piece, my recommendation is still that the UI should store a config setting to disk, not have pam trying to infer something from the contents of the password database
[19:36] <ogra_> i will (like i did all the time) consult plars (or psivvaa) from the smoke testing team for the other implementation that affects them
[19:36] <balloons> ogra_, there's other folks who need to smoke test beyond CI
[19:37] <ogra_> slangasek, so if i do: "sudo passwd -l phablet" in the terminal app all is fine ?
[19:37] <slangasek> balloons: and those should all be using the same --developer-mode interface when provisioning, no?
[19:37] <ogra_> balloons, yes, and you will be involved in the next round ... i wasnt aware of that issue til now
[19:37] <slangasek> ogra_: what do you mean by "fine"?
[19:37] <slangasek> ogra_: are there design docs for any of this?
[19:38] <cyphermox_> kenvandine: howdy
[19:38] <ogra_> balloons, but essentially i think we should have an AP function that can enter the PW for terminal, filemanager and whatever else comes along
[19:38] <cyphermox_> kenvandine: are you doing more ubuntu-system-settings landing or are things still blocking on the last one?
[19:38] <balloons> slangasek, I'm ok with whatever design, so long it's repeatable and useable by others. It'sok to require --developer-mode to run tests certainly
[19:38] <cyphermox_> kenvandine: I have this other fix that would be nice to land: https://code.launchpad.net/~mathieu-tl/ubuntu-system-settings/more-audio-types/+merge/233776
[19:39] <balloons> ogra_, ideally we want to test security features of the app, in secure mode, as well as the app in an unsecured state
[19:39] <ogra_> slangasek, well, if i do the above, my password will be unset but nothing in the UI will notice ... i dotn want to hook a security critical feature into that
[19:39] <balloons> so I would want to disable PAM, as well as set it and a password for testing security response by the app
[19:39] <ogra_> why would you disable pam ?
[19:39] <balloons> sorry, I mean to say, passwordless access.. unsecure mode if you will
[19:40] <slangasek> ogra_: ok, but I don't know why you're proposing to run 'passwd -l phablet' in the first place
[19:40] <kenvandine> cyphermox_, that's in silo 14 already
[19:40] <ogra_> balloons, we can surel have self containing tests that dont require adb at all or can dis/enable it while they run stanndalone
[19:40] <cyphermox_> oh, cool, thanks!
[19:40] <kenvandine> np
[19:40] <kenvandine> cyphermox_, feel free to help test :)
[19:40] <ogra_> slangasek, no idea, users do such stuff :)
[19:40] <elopio> what about this option? mir running but unity not running. Could we run the apps in that environment? If we want to test the integration with unity at some point, we can start it with testability and control it fully on the test. Also, if we want to test PAM or something, we set it up before starting the test
[19:40] <slangasek> ogra_: trying to review this via IRC conversation is very frustrating; this really needs to be a spec somewhere that people can refer to
[19:41] <slangasek> ogra_: er, I don't think users using non-obvious 'passwd' commandline interfaces to mangle the state of their auth db should be our primary concern
[19:41] <ogra_> slangasek, i'll happily wrtite that up, but not after my nth nightshift trying to get the finla bit landed
[19:42] <balloons> ogra_, how do you propose we provision and execute without adb?
[19:42] <tvoss> elopio, ping
[19:42] <tvoss> elopio, reading backlog
[19:42] <ogra_> balloons, nohup for example
[19:42] <tvoss> elopio, so what exactly is going wrong?
[19:42] <ogra_> balloons, you need adb initially ... once
[19:42] <ogra_> (and i guess even that could be avoided somehow)
[19:42] <elopio> tvoss: I need more context. If you want a list of things that have gone wrong since I wake up, it's going to be big :)
[19:43] <lool> tvoss: hey
[19:43] <lool> tvoss: https://wiki.ubuntu.com/Process/Merges/TestPlan/location-service says to stop ubuntu-location-service
[19:43] <tvoss> elopio, location service landing, which part of the testplan did not work?
[19:43] <lool> tvoss: then run it by hand
[19:44] <balloons> ogra_, I'm not sure I'm following what you mean by nohup.. But you are right I could leave a payload on the system that would execute; even if I only had one-time adb access
[19:44] <lool> tvoss: but the trust helper session job will never start again if you stop location-service
[19:44] <elopio> tvoss: the first step, use the dummy to get a location fix.
[19:44] <slangasek> ogra_: in the absence of a written spec, my view is that this is being landed prematurely and without due diligence
[19:44] <ogra_> balloons, right, and i guess we could even go further
[19:44] <lool> tvoss: this is due to: start on (started JOB=dbus and started JOB=unity8) and (:sys:started JOB=ubuntu-
[19:44] <lool> location-service)
[19:45] <lool> tvoss: the started unity8/started dbus wont ever be emitted
[19:45] <ogra_> slangasek, so what should i do, not land it at the dawn of rtm ? which would leave adb completely open ?
[19:45] <balloons> ogra_, I mentioned CI is not the only ones who need to run tests.. but I too am not the only one. I'd like to keep the case of others (like a partner) wanting to replicate test runs
[19:45] <slangasek> ogra_: "at the dawn of RTM"?  I don't believe that we're pushing this out to customers the moment you land this
[19:46] <tvoss> lool, sorry, but that's irrelevant if you start by hand
[19:46] <slangasek> to the contrary, I think not having a handle on this is going to cost us a lot of time fighting with bugs and unclear design
[19:46] <ogra_> balloons, we made pretyt sure that things like phablet-click-test-setup and stuff work
[19:46] <lool> tvoss: oh yes, but then you miss the trust helper
[19:46] <lool> tvoss: and apps cant access your position anymore
[19:46] <tvoss> lool, sure, that's a known bug
[19:46] <ogra_> slangasek, that is why it is in utopic since a week
[19:46] <tvoss> lool, elopio https://bugs.launchpad.net/ubuntu/+source/location-service/+bug/1359866
[19:47] <ogra_> slangasek, and why i worked with plars and bzoltan over the last weeks to make sure their bits do not regress
[19:47] <lool> tvoss: right, so every single test should start with manually running it
[19:48] <slangasek> ogra_: neither plars nor bzoltan are on the security team, though?
[19:49] <ogra_> slangasek, not if they didnt join recently :)
[19:49] <elopio> tvoss: that's good to know. The problem is that the test plan doesn't mention anything about that.
[19:49] <tvoss> elopio, you know now, would appreciate a ping if things go wrong
[19:49] <balloons> this is clearly something that needs design input from a security perspective.. feels a bit like we've implemented and are adding back things to close gaps
[19:49] <ogra_> slangasek, the security team reqs are pretty clear though
[19:50] <lool> tvoss: with the workaround, it works
[19:50] <ogra_> (and yes, contrary to my code changes they are written down)
[19:50] <elopio> tvoss: and if the test plan is outdated, it means it was not run before being proposed to land, so the silo needs to go back, people need to update the tests and run them.
[19:50] <tvoss> elopio, also: quite some landing went through with qa signoff, surely it should have popped up earlier?
[19:50] <slangasek> ogra_: except the security team's reqs don't discuss the autotesting case at all, and modifications are being made to various pieces to accommodate those use cases
[19:50] <elopio> tvoss: I agree. It should have been found earlier.
[19:50] <slangasek> and it all looks very ad hoc to me
[19:50] <tvoss> elopio, sorry, I don#t think we should resort to harsh measures here. I appreciate your attention to detail, but we still have to keep on landing stuff.
[19:52] <ogra_> slangasek, so why do you ask about plars being int the securtiy team then ? i worked with the stakeholders (obviously missing the case of the two clisk apps balloons is now concerned about)
[19:52] <lool> tvoss, elopio: Actually I wonder whether an independent change broke location-service, and now the test plan doesn't work because we miss the workaround that tvoss pointed at
[19:52] <elopio> tvoss: I'm available here to confirm that the silo is good to go. But I'm not available here to run all the manual tests of all the projects. I don't think it's a hard measure, as soon as somebody tells me that they successfully ran the tests, I will do some exploratory to look for regressions.
[19:52] <ChickenCutlass> slangasek: should ogra_ and I get on a hangout and fill you in?
[19:52] <ChickenCutlass> would that be easier
[19:53] <elopio> lool: that's possible. But on the spreadsheet it doesn't say the number of the image you tested initially.
[19:54] <slangasek> ChickenCutlass: unless the output of the hangout is a written spec that comprehensively addresses the authentication design used for autotesting, I don't think that really addresses my concern :)
[19:54] <plars> ogra_: I'm a bit lost in the conversation, is there a new requirement coming in on this? We've shown that it works in utopic
[19:55] <ogra_> plars, not sure, slangasek seems very unhappy
[19:55] <balloons> plars, but it doesn't work in utopic.. fm and terminal for instance don't work
[19:55] <balloons> I'm now curious about autopkgtest being broken as well. How do you autounlock?
[19:56] <lool> elopio: would you mind running the test plan after setting up the workaround, that is, run as user: /usr/bin/trust-stored-skeleton     --remote-agent RemoteAgent --bus=system     --local-agent MirAgent     --trusted-mir-socket=/var/run/user/$(id -u)/mir_socket_trusted     --for-service UbuntuLocationService     --store-bus session
[19:56] <tvoss> elopio, test plan updated, checked locally
[19:56] <lool> tvoss: thanks
[19:56] <tvoss> lool, even easier: just restart restart ubuntu-location-service-trust-stored
[19:56] <tvoss> lool, mentioned that in the test plan
[19:57] <lool> tvoss: I thought you had to attach to a session for that to work, but glad it just works  :-)
[19:57] <tvoss> lool, nope, just phablet-shell into the phone
[19:57] <plars> balloons: oh? Those are broken in rtm too though right?
[19:57] <ogra_> slangasek, the test tools in phablet-tools we provide are capable to work with the dev mode today, smoke testing works fine as well, yes there is the case of the two apps ... the SDK works well with what we have now and i will happily do a write up of everything in place so we can revise bits of it before final release
[19:58] <plars> balloons: there's a script that ships with unity8 that we use for autounlock. It's the same one we used before, but they also added the ability to unlock the password lock
[19:58] <balloons> plars, I looked at the breakage today, and it is clearly the introduce of pin locking that causes them to fail
[19:58] <elopio> lool, tvoss: of course, I'll set up my device again. But just to be clear, you are telling me that you or somebody else ran the whole test plan and didn't find any issues?
[19:58] <lool> unity7 stop/waiting
[19:58] <lool> uh
[19:58] <tvoss> lool, ?
[19:58] <plars> balloons: pin or password? I'm told there's a bug with that where it treats pin unlocking the same as password that's causing some trouble. Current blocker iirc
[19:58] <balloons> plars, I assumed it was updated. Do you know how the password unlock works?
[19:58] <tvoss> elopio, yup, likely because I'm used to that workaround
[19:59] <lool> tvoss: just surprized to see some unity7 stuff  :-)
[19:59] <plars> balloons: it's a dbus call, if you look at the unlock script in unity8-autopilot you'll find the necessary bits for it
[19:59] <balloons> plars, either one.. the presence of developer mode requiring security causes it
[19:59] <plars> balloons: also... why is filemanager and terminal-app needing their own extra unlock step?
[19:59] <elopio> tvoss, lool: ok, taking back the card. I'll let you know if I find something weird.
[19:59] <lool> elopio: great, thanks
[19:59] <tvoss> elopio, ack
[19:59] <plars> balloons: I'm not saying you're wrong of course, I'm just curious why that's the case
[20:00] <balloons> plars, they were protected; in leiu of locking down everything, they targetted just those 2 apps
[20:00] <tvoss> elopio, my proposal for the next time: just file a bug against the project and mark it critical
[20:00] <balloons> plars, your questions are as valid as mine :-)
[20:00] <slangasek> ogra_: so I'm not standing in your way on this; it's not my place to do that.  But you asked me for input on the pam change, which hopefully I've given you to your satisfaction, and in the process I'm very concerned that there's extensive work being done around authentication with only an incomplete written design (https://wiki.ubuntu.com/SecurityAndPrivacySettings/ProtectingUserData, which doesn't address the developer-
[20:00] <tvoss> elopio, if I hadn't been accidently around today, or lool, we wouldn't have found out
[20:01] <plars> balloons: ah, in that case we could probably use something similar to work through it I think.  Take a look at that script
[20:01] <plars> balloons: and thanks for checking those out, it's been the source of some stress in the landing calls this week! :)
[20:01] <balloons> plars, https://bugs.launchpad.net/bugs/1347010. that's useful, but I echo all of slangasek's concerns
[20:01] <elopio> tvoss: I marked the card as failed, so it wouldn't have landed. You didn't give me time to file a bug.
[20:01] <tvoss> elopio, ah okay
[20:02] <ogra_> slangasek, there are only few people whose developer input i find more valuable than yours and i am concerned if you raise concerns and would like to get to a point where i feel i did the right thing ... so lets please look over it, together with the security team and whoever else may be concerned and adjust it to DTRT
[20:03] <ogra_> slangasek, i just think we can as well do it with the stuff in place already
[20:03] <kenvandine> barry, bingo... if it downloads a system update and you choose not to apply it, then later when it checks it crashes
[20:03] <kenvandine> barry, i tested by deleting the downloaded update and trying again
[20:03] <kenvandine> it doesn't crash if i let it install it...
[20:04] <kenvandine> and it doesn't crash if i say not now
[20:04] <barry> kenvandine: could you update the bug with that info?  if i ever get my device flashed i will try to reproduce :/
[20:04] <kenvandine> but if i come back to it later... it crashes
[20:04] <kenvandine> yeah
[20:04] <kenvandine> will do
[20:04] <barry> kenvandine: thanks
[20:04] <slangasek> ogra_: well, for that I would really like to see things written down about the intended design
[20:05] <ogra_> slangasek, i will write down the implemented design and will schedule a meeting next week ...
[20:05] <slangasek> ok
[20:05] <slangasek> thanks :)
[20:05] <ogra_> thanks for the feedback :)
[20:13] <kenvandine> jgdx, i found some unrelated issues in the wifi panel, so i proposed a branch with your branch as a pre-req
[20:17] <ajalkane> zbenjamin: howdy, I guess INSTALL_TESTS is not needed since Jenkins ran the tests fine without it. I'm going to try reapproving your changes as Jenkins again seem to have some env problems.
[20:17] <zbenjamin> ajalkane: ok :)
[20:19] <balloons> ogra_, if I can get an invite, I'd appreciate it :-)
[20:22] <ogra_> balloons, sure ... your partner concers should already have been taken care of though ... as i said before, all pieces in  phablet-tools that run tests have been adjusted (else plars wouldnt be able to run his tests)
[20:22] <ogra_> balloons, but happy to get more input on this, i'll forward you the writeup too
[20:25] <ogra_> balloons, and just FYI, i just looked at the rtm tests, seems both apps fail there too without PW set
[20:25]  * ogra_ wonders how he didnt notice that before
[20:26] <balloons> ogra_, plars pointed that out, I'm looking
[20:26] <ogra_> ah, k
[20:26] <balloons> my concerns still exist though, heh, as it's still a big issue
[20:26] <balloons> :-)
[20:26] <ogra_> sure
[20:27] <ogra_> but we cant drop all security i think ... the current setup is more a compromise
[20:27] <balloons> ogra_, right.. it's the idea I'd rather not hack around security, but instead, have testing in mind when we do this. So we can both run tests, and run tests ensuring our security works
[20:27] <ogra_> (dont break security for users but still allow tests by poking small holes in special setup)
[20:28] <ogra_> right
[20:28] <balloons> the failures look the same on rtm.. my guess is because pins are enabled for the devices... plars is that correct? rtm devices have pins/password set too yes?
[20:28] <ogra_> oh, right
[20:28] <ogra_> i think the provisioning call is the same
[20:29] <balloons> ogra_, yep.. I had the same ah, duh moment :-)
[20:29] <ogra_> just that adb still runs as root on rtm
[20:35] <jgdx> kenvandine, ack
[20:43] <barry> kenvandine: quick question: on the device that you can reproduce this, how is your auto-download set?  wifi-only?  manual?  or automatic?
[20:44] <kenvandine> barry, wifi only
[20:44] <barry> kenvandine: and you're on wifi, right?
[20:44] <kenvandine> yes
[20:44] <barry> kenvandine: cool, thanks
[20:44] <kenvandine> barry, it is downloading it
[20:45] <kenvandine> it only crashes when it's already downloaded
[20:45] <kenvandine> and i go back into settings
[20:46] <plars> balloons: yes, they are set everywhere. So it's not related to the adb stuff then, only to whether a password has been set?
[20:48] <ogra_> plars, right, the apps see that a pw is set and pop up a password window before you can use them
[20:49] <elopio> tvoss, lool: here.com works. maps.google.com seems to work, it centers on france but doesn't zoom in. osmtouch gives the same error as before
[20:49] <balloons> yep ^^
[20:50] <elopio> Error creating session: Client lacks permissions to access the service with the given criteria
[20:50] <lool> elopio: m.here.com does center on eiffel tower FYI
[20:50] <lool> elopio: you might want to kill the running apps and restart the trust store thing
[20:50] <lool> elopio: it might be crashing
[20:51] <lool> elopio: stop ubuntu-location-service-trust-stored; start ubuntu-location-service-trust-stored
[20:52] <elopio> hum, now it works. The first time I opened it, it didn't. But now seems fine.
[20:52] <elopio> lool: is that nothing to worry about? ^
[20:52] <ajalkane> balloons: forcing authentication off: filemanager --forceAuth off, please see merge proposal and approve if it's what you had in mind: https://code.launchpad.net/~ajalkane/ubuntu-filemanager-app/force-authentication-parameter/+merge/234006
[20:53] <tvoss> elopio, we have a bug logged for it. Once I finished silo 4, I'll be on it
[20:54] <elopio> tvoss: do you have the # at hand?
[20:54] <tvoss> elopio, looking
[20:55] <tvoss> elopio, const std::shared_ptr<media::Player>& cp
[20:55] <tvoss> elopio, even https://bugs.launchpad.net/ubuntu/+source/trust-store/+bug/1356468
[20:56] <balloons> ajalkane, yes, minus the pot file updates :-)
[20:56] <balloons> ajalkane, thanks for doing that
[20:58] <barry> okay, so back on my manta, r231, i have a pin set, but adb shell still doesn't let me in.  the wiki page is out of date i think.  how do i adb shell into the device now?
[20:59] <ajalkane> seems like the potty files are autoupdated, which might be good as no diapers needed then
[21:00] <barry> adb devices never shows me any devices, even after multiple adb kill-servers
[21:07] <elopio> thanks tvoss.
[21:09] <tvoss> elopio, sure
[21:11] <elopio> tvoss, lool: now $ sudo cp /system/etc/gps.conf /etc/gps.conf
[21:11] <elopio> cp: cannot stat ‘/system/etc/gps.conf’: No such file or directory
[21:11] <balloons> ajalkane, can you resubmit under filemanager-devs, so I can push to it as well? The test will need updated
[21:11] <balloons> I'll save my comments until you have a new mp
[21:11] <ajalkane> yeah sure
[21:11] <balloons> also, ajalkane working on that bug so we can reference it
[21:11] <tvoss> elopio, fixed, thank you
[21:13] <ajalkane> uh, a stupid question arises. What's the command to push under filemanager-devs?
[21:13] <elopio> tvoss: ok. And should I run the ubuntu-location-service-tests while the dummy is still running?
[21:13] <balloons> ajalkane, ~ubuntu-filemanger-dev
[21:13] <balloons> replace your name with that
[21:13] <tvoss> elopio, no
[21:14] <ajalkane> balloons: aye, pushed, do I revoke the previous merge proposal and use this instead?
[21:14] <elopio> ok, restarting it...
[21:15] <tvoss> elopio, please note the preliminary before the agps test plan
[21:15] <balloons> ajalkane, you can actually use the superseded button
[21:16] <balloons> ajalkane, so hit resubmit proposal and change the branch
[21:16] <balloons> see it on the right?
[21:20] <elopio> tvoss: do you mean, to get the estimate location before running them?
[21:20] <ajalkane> balloons: is it when doing merge proposal or after that?
[21:20] <tvoss> elopio, no, it might fail
[21:20] <balloons> ajalkane, look at your current proposal: https://code.launchpad.net/~ajalkane/ubuntu-filemanager-app/force-authentication-parameter/+merge/234006
[21:21] <tvoss> elopio, but the test completing with a sensible success/failure result is good enough
[21:21] <balloons> ajalkane, also if possible, get rid of the pot file updates in there :-)
[21:22] <elopio> tvoss: I don't understand the "please note the preliminary before the agps test plan"
[21:22] <elopio> there's a section called Preliminary AGPS Test Plan.
[21:23] <elopio> I'm not sure what you mean with the preliminary before the agps test plan.
[21:23] <ajalkane> balloons: I could not find any supersede button nor did ctrl+f in browser find it in the link you provided
[21:23] <balloons> ajalkane, it's called resubmit proposal
[21:24] <ajalkane> ah then I'm okay :) thanks
[21:24] <balloons> a yellow button in the top right.. sorry I told you the wrong word
[21:24] <tvoss> elopio, the section is called "Preliminary AGPS test plan" :)
[21:24] <ajalkane> The potties were alreayd bzr committed so unsure how to get them away
[21:24] <balloons> ajalkane, bzr pull before the changes
[21:24] <balloons> or bzr merge trunk no
[21:24] <balloons> *now
[21:26] <elopio> tvoss: I'm confused, but I think it doesn't matter :) I'm just running everything the page says.  I resolved to delete the old branch proposal and making it a new to filemanager-devs
[21:30] <ajalkane> https://code.launchpad.net/~ubuntu-filemanager-dev/ubuntu-filemanager-app/force-authentication-parameter/+merge/234015
[21:30] <ajalkane> The potties are there unfortunately
[21:32] <esra> Hi everyone! A question: it seems it has been a bit silent around the feature that you can use a full desktop version of ubuntu with a dockingstation. is this a soon to come reality or was that just a plan?
[21:35] <balloons> ajalkane, no worries. I left my comments and for now I'll leave it as-is. I'll make the test changes tomorrow and confirm they work on the device. I don't intend to land it unless we can't do it another way
[21:36] <ajalkane> balloons: thanks!
[21:36] <balloons> I suspect we may be forced to land it as a workaround regardless, which is why I asked you to do it :-) thanks ajalkane !
[23:32] <elopio> lool: mandel: any chance you are still around?