[01:50] <lotuspsychje> nice work on the apps close slide guys!!
[01:50] <nhaines> lotuspsychje: thanks!
[01:50] <lotuspsychje> every update touch gets nicer
[01:50] <nhaines> <--- had absolutely nothing to do with this.
[01:50] <lotuspsychje> lol
[01:51] <nhaines> Seriously, though, the last promotion is (mostly) a phone I'd be proud to hand to anyone.
[01:51] <nhaines> Dash and scopes are *really* nice now, even if search is still pretty wonky.
[01:51] <lotuspsychje> its all very logical once you know the tricks
[01:52] <lotuspsychje> the swipes are like its meant to be
[01:53] <lotuspsychje> search is indeed a bit strange, i loved the apps icons at first
[01:53] <nhaines> Dash-as-an-app makes right-edge navigation much easier.
[01:53] <lotuspsychje> when they all showed (last installed ones up)
[01:53] <lotuspsychje> true
[01:54] <nhaines> At least when you search and choose the app store, it carries your search over.
[01:54] <lotuspsychje> yes with your trick *
[01:55] <lotuspsychje> i really hope brightness gets fixxed
[01:56] <lotuspsychje> and terminal apps install
[01:56] <nhaines> Hmm, I don't recall if brightness is a problem.  Oh, I know what I could do.  I'm going to hope someone makes it so the screen ever turns off instead of just staying on always.
[01:57] <nhaines> Terminal apps install isn't important to me.  Flip to developer mode and turn on read/write and you can break your phone any way you wish.  :)
[01:57] <nhaines> Although they're going to have to think of something eventually.
[01:58] <lotuspsychje> the brightness prob has been bugged
[01:58] <lotuspsychje> when i reboot my nexus7 it sets brightness back to default
[01:58] <lotuspsychje> instead of 100%
[01:58] <nhaines> Oh, no... I mean yes, I know that was a problem on some phones.  I just meant I didn't remember if it was still an N5 problem, sorry.  :)
[01:58] <lotuspsychje> i am at developer mode already
[01:59] <lotuspsychje> ah your on n5?
[01:59] <nhaines> Yup.
[01:59] <lotuspsychje> andworks nicely with touch?
[01:59] <nhaines> Click packages install just fine on the command line.  I've done it!  :D  But apt is problematic.  But that's a deficiency with apt.
[01:59] <nhaines> Works beautifully.  If the backlight would ever turn off then it'd be perfect.  Except cellular data at the moment, but that's fixable.
[02:00] <lotuspsychje> well i just dont wanna wait until someone makes nmap a touch app example
[02:00] <lotuspsychje> i have tons of ideas to try with terminal
[02:01] <lotuspsychje> like lightweight mupdf would be nice to try
[02:01] <lotuspsychje> would be nice if there's a button to unlock to write protect
[02:02] <nhaines> Pull the .deb, extract the files, and shove them in a subdirectory.  :)
[02:02] <nhaines> Design says there will never, ever be a button to unlock to write protect, and I agree.
[02:02] <nhaines> It's a simple copy/paste command, which seems a low barrier to something that will break a phone.
[02:03] <lotuspsychje> so if device will always be locked, howto install new terminal stuff?
[02:03] <RAOF> We'll need to solve that problem for convergence, anyway.
[02:04] <lotuspsychje> installing the deb will also result to var lock error no?
[02:04] <RAOF> Right. We'll need to engineer some solution that allows both apt and system images.
[02:04] <lotuspsychje> that would be real nice
[02:05] <nhaines> lotuspsychje: the problem is that apt install works but apt upgrade breaks everything.
[02:05] <lotuspsychje> so if i drag n drop a deb it should install?
[02:05] <nhaines> So I can't imagine worrying about make it really easy for people to apt install things when it will break everything.
[02:05] <nhaines> No, that would break everything too.
[02:05] <lotuspsychje> howcome?
[02:06] <nhaines> I'm just saying, copy it to the phone to your home directory, extract the binaries, and run it from there.  Something very simple should still run.
[02:06] <nhaines> I don't know how come.  apt can't handle hard links across many mountpoints or something esoteric.
[02:07] <lotuspsychje> ok
[02:08] <lotuspsychje> that also means click apps cant change something internally also?
[02:08] <RAOF> Well, you can't *have* hard links across mountpoints, so... :)
[02:09] <RAOF> Indeed. Click apps are, well, apps. They don't do libraries or daemons or whatever.
[02:09] <lotuspsychje> not like the way android needs all kinds of permissions etc
[02:10] <lotuspsychje> so a hacker could not unlock write protect with an ubuntu click app?
[02:19] <RAOF> No
[07:19] <dholbach> good morning
[07:20] <nhaines> dholbach: morning.  :)
[07:20] <dholbach> hi nhaines
[07:20] <nhaines> Busy writing, writing, writing.  Hope your morning's more fun so far.  :)
[07:45] <dholbach> nhaines, what are you writing?
[07:47] <nhaines> dholbach: some technical article stuff, and then reworking that book proposal... they liked it and said to do it more free-format rather than as one of their series, so I'm going to resubmit.  :D
[07:50] <dholbach> nice
[07:51] <nhaines> Yup, I was pleased, because I think it'll be a better book.  More of a guide to Ubuntu for Windows and Mac users.
[07:58] <dholbach> that sounds great :-)
[08:01] <nhaines> So it'll be a great resource for Ubuntu 14.04, and maybe if I'm lucky they'll need a second edition for 16.04... but I'm only worried about the first edition for now.  ;)
[08:02] <ogra_> ricmm, did anyxone think about making sure the shell-as-app has a better oom score than the rest, now that it runs as app ? (i think i saw it beeing OOMed once this weekend)
[08:04] <nhaines> Does it auto-respawn?
[08:05] <ogra_> nhaines, it just hung for me ... the point is that the system kills based on oom_score for the process ... for unity8 we have this hardcoded so that it never gets killed (or at least gets killed last), i'm not sure that was taken over into the dash-as-app setup
[08:06] <ogra_> i assume the dash gets handled like any other app on that level
[08:08] <nhaines> Oh, I'm not suggesting that it's a good idea to let it OOM and then just respawn.  But it'd be nice if it did at least respawn.
[08:10] <ogra_> well, if in my case (i wasnt near a PC to check anything and needed to reboot to use the phone) it was oom, it surely didnt respawn ... it was just unresponsive ... i could still flick through the apps
[08:11] <nhaines> And no swiping it away. :)
[08:12] <ogra_> heh, yeah
[08:33] <JamesTait> Good morning all; happy Monday, and happy Ingersoll Day! :-D
[08:36] <nhaines> JamesTait: good morning!  :D
[08:36] <nhaines> dholbach: I'm seeing the LoCo contacts emails roll in.  Were you on vacation or something?  :)
[08:47] <dholbach> nhaines, no just a bit busy with a few other things for a few days
[08:47] <dholbach> :)
[08:51] <vaskozl> is it possible to get the ubuntu touch de/wm on regular ubuntu?
[08:53] <Beldar> vaskozl, No read the headers
[08:53] <nhaines> dholbach: I know how that is.  :)
[08:53] <vaskozl> Beldar: what are headers?
[08:54] <vaskozl> the topic?
[08:54] <dholbach> vaskozl, yes, you can install unity8-desktop-session-mir to run it on your desktop
[08:54] <dholbach> vaskozl, or you can run it in an emulator: https://wiki.ubuntu.com/Touch/Emulator
[08:54] <vaskozl> oh neat
[08:54] <vaskozl> thanks
[08:54] <nhaines> dholbach: I've never had that work.  I'm hoping one day the desktop-next ISO will boot.  :)
[08:54] <dholbach> vaskozl, using utopic (14.10) will probably be best
[08:54] <dholbach> nhaines, for me it does
[08:55] <Beldar> wont be supported on the utopic channel is all
[08:55] <nhaines> Aww. What graphics chipset?
[09:02] <Chipaca> Laney: ping (morning!)
[09:04] <ricmm> ogra_: probably not, can you take a look? if not, I'll look in a bit
[09:29] <ogra_> ricmm, seems to run with an oom_score_adj of -10 ... which is what lightdm sets for the session
[09:29] <ogra_> not sure why or how, but that seems fine (i dont see the score set in any upstart job)
[09:45] <mpt> Anyone know what package is responsible for the startup screen? (The little spinning Ubuntu logo)
[09:47] <mgreg> plymouth
[09:58] <ogra_> mpt, unity-system-compositor
[10:01] <Laney> hey Chipaca, not working today but I approved your stuff anyway :-)
[10:02] <Chipaca> Laney: ooh, excellent, thanks!
[10:02] <Chipaca> Laney: now get out of here :)
[10:02] <ogra_> mpt, do you see the tethering thread on the phone ML ?
[10:02] <ogra_> some design questions popped up there
[10:09] <mpt> thanks ogra_
[10:11] <ogra_> nhaines, lol !
[10:11] <ogra_> (re: your mail)
[10:21] <piiramar> ogra_: is the USB tethering expected to break adb? or is it just me and my device
[10:21] <ogra_> piiramar, defin "break adb" ... switching the gardget driver forces a USB reconnect if you mean that
[10:21] <ogra_> *gadget
[10:21] <ogra_> *define ...
[10:21] <ogra_> sigh
[10:22]  * ogra_ needs to learn typing
[10:22] <piiramar> ogra_: I meant, while the rndis mode is active, all 'adb' commands fail
[10:22] <ogra_> they dont here
[10:22] <piiramar> ogra_: after reboot, I'm back to mtp and adb is fine
[10:22] <ogra_> you might need to restart your adb on the PC side ... perhaps it dosnt pick up the ID change properly
[10:22] <piiramar> ah ok
[10:22] <ogra_> the USB device ID changes ...
[10:23] <piiramar> didn't try that. makes sense
[10:23] <ogra_> so: adb kill-server; adb devices ... might work
[10:23] <ogra_> if that doesnt, we miss a USB udev rule for that device ID
[10:28] <piiramar> ogra_: thanks, working fine now
[10:28] <ogra_> just the restart of the server helped ?
[10:28] <ogra_> (you didnt need sudo or something ?)
[10:29] <piiramar> I'm afraid I tried several things at once, not 100% if the kill-server was the decisive one
[10:34] <ogra_> right, if you run into it again, see if just "adb devices" shows it then ro if you actually needed "sudo adb devices" to make it show up ... in case of the latter we need to adjust the udev rules
[10:34] <ogra_> (in case of the former we cant really do anything)
[10:41] <popey> thostr_: heya, who can review https://code.launchpad.net/~jamesh/mediascanner2/model-auto-update/+merge/229903 ?
[11:06] <mardy> tvoss|lunch: hi! I updated https://code.launchpad.net/~mardy/ubuntu-system-settings/other-app-access/+merge/228299 with unit tests
[11:27] <zyga> hey, is there a browser bug about the erracit scrolling behavour of the browser as the header bar shows and hides?
[11:27] <zyga> I'd like to report it but if it's something well know I'd like to track it instead
[11:39] <greyback> zyga: https://bugs.launchpad.net/webbrowser-app/+bug/1354700 - that the issue?
[11:40] <thostr_> popey: jussi will... already pinged him.
[11:40] <zyga> looking
[11:41] <zyga> greyback: yes!
[11:41] <zyga> yay, I guessed what the reason was
[11:41] <greyback> zyga: yeah it's pretty noticeable, it needs fixing
[11:41] <nhaines> ogra_: hehe, only half serious.  ;)  But yeah, hopefully design will come up with something interesting.
[11:54] <mzanetti> cyphermox_: ping
[12:19] <cwayne> mardy: ping
[12:22] <zyga> is there a way to update the emulator image other than destroying/re-creating it?
[12:22] <popey> thostr_: thanks
[12:42] <mardy> cwayne: pong
[12:46] <cwayne> mardy: hi -- it looks like our linkedin account-plugin has the redirect uri set incorrectly, do you control that?
[12:49] <mardy> cwayne: "control" as in "owner of the project" yes, but I didn't create that plugin
[12:49] <mardy> cwayne: but I know it worked, so maybe linkedin changed something
[13:07] <tvoss|lunch> mardy, great, let me get to it right away
[13:30] <cwayne> mardy: dbarth: is there any ETA on a fix for the blank .desktop files in accounts (to grant an app access to a specific account)
[13:31] <mardy> cwayne: I hope by the end of the week, but it's only a hope :-)
[13:32] <mardy> cwayne: but that shouldn't be blocking you, right? You can workaround it by playing with the .application file a bit
[13:34] <cwayne> well it makes a scope using onlinea ccounts not very usable
[13:41] <sergiusens> cwayne: do you know if it's possible to bundle a scope and webapp in the same click yet?
[13:41] <cwayne> sergiusens: it is
[13:41] <sergiusens> cwayne: I wanted to bundle them together to reuse the same online accounts data
[13:42] <sergiusens> cwayne: great
[13:42] <cwayne> sergiusens: not super-simple to use online accounts ina  scope yet btw
[13:44] <tvoss> mardy, thanks for the tests, ci is failing due to merge conflicts, though :) would like to see it go green prior to approving
[13:46] <mardy> tvoss: thanks, I'll try :-)
[13:46] <tvoss> mardy, cool
[13:48] <sergiusens> cwayne: ah, then I need to wait more
[14:05] <mhall119> has anyone else had trouble adding a twitter account in the latest promoted image?
[14:08] <mhall119> Green Mahjong is working now! Thanks for helping with that daker
[14:11] <cwayne> sergiusens: what scope/webapp were you going to do?
[14:12] <mhall119> ok, adding twitter worked just now, but I tried half a dozen times over the weekend and Online Accounts would always crash
[14:21] <mardy> Saviq: is there a quick way to disable the application lifecycle, for debugging?
[14:21] <Saviq> mardy, afraid not, at the moment
[14:22] <popey> you could make a click with it being unconfined, could you not?
[14:22] <Saviq> popey, unconfined != exempt from lifecycle
[14:22] <popey> oh, i thought they were
[14:22] <popey> ignore me
[14:22] <Saviq> mardy, actually, if you launch the app from console
[14:22] <Saviq> mardy, with --desktop_file_hint=, I believe those don't get suspended
[14:23] <Saviq> mardy, or well, you can always just call SIGCONT on the app
[14:23] <Saviq> after it gets suspended
[14:23] <popey> dbarth: your webapps have ubuntu-sdk-14.04-dev1 as their framework, you might want to consider bumping them next time you upload
[14:23] <mardy> Saviq: I'll try, thanks
[14:24] <dbarth> popey: ack
[14:24] <popey> ta
[14:24] <dbarth> popey: should i bump all of them to dev2?
[14:24] <popey> no pressing need, but as and when
[14:24] <popey> they're approved with the current framework
[14:24] <dbarth> ok, for the next batch then
[14:25] <popey> it'll probably be -dev6 by then ㋛
[14:25] <dbarth> h
[14:25] <dbarth> e
[14:51] <mterry> jgdx, hello!  Do you know if anyone has spare cycles to review https://code.launchpad.net/~mterry/ubuntu-system-settings/wizard-password/+merge/229853 ?  I'd like to try to get that in the image by Thursday
[14:53] <jgdx> mterry, I know I can take a look.
[14:55] <mardy> Saviq: so, there's something weird: I have a branch of online accounts where I refactor it into a Ui-less DBus server, which spawns the UI processes with QProcess
[14:55] <mardy> Saviq: the system-settings is a client of this D-Bus API, and when I run it and click on online-accounts, I get the OA window as expected
[14:56] <mardy> Saviq: when I close it, I'm back to system-settings, but the app is frozen
[14:57] <mardy> Saviq: if I start system-settings from the console, it behaves very similarly, but the UI un-freezes after I move to the task switcher and re-select it
[14:57] <Saviq> mardy, can you see it suspended from `ps aux | grep settings`?
[14:57] <Saviq> mardy, i.e. is status T?
[15:00] <mardy> Saviq: OK, it seems that the process unfreezes after selecting it from the switcher, even if not launched by the terminal
[15:00] <mardy> Saviq: and yes, before moving to the task switcher, it has T status
[15:00] <Saviq> mardy, so it doesn't resume if it's "auto-focused" by means of the foreground app going away?
[15:00] <Saviq> mardy, let me try something
[15:00] <mardy> Saviq: exactly
[15:01] <mardy> Saviq: could it be because I'm starting the UI processes with QProcess and not upstart?
[15:01] <Saviq> mardy, it *could* yes
[15:01] <Saviq> mardy, but let me investigate
[15:02] <Saviq> mardy, but no, it's the same if one of the apps goes away, even if both are upstart-launched
[15:03] <Saviq> mardy, dandrader was reworking the lifecycle in qtmir/unity8 these past weeks
[15:03] <Saviq> dandrader, do you know if foreground app dying not resuming previous app would be fixed by that?
[15:03] <Saviq> dandrader, i.e. launch two apps, kill foreground app, current app on screen does not resume
[15:06] <balloons> zyga, re: your g
[15:06] <zyga> balloons: :-)
[15:06] <zyga> balloons: yeah?
[15:08] <balloons> zyga, so you should be able to run the tests from tests/autopilot by typing 'autopilot list TESTSUITE' to list tests and 'autopilot run TESTSUITE'
[15:08] <balloons> if the tests are python3, autopilot3 is recommended
[15:08] <zyga> balloons: I just started with a new app from the sdk
[15:08] <zyga> balloons: I ran make autopilot and got what I showed you
[15:08] <zyga> balloons: is the template buggy or did I misconfigure something?
[15:09] <balloons> zyga, interesting the template has autopilot as a build target
[15:09] <balloons> it's python, so nothing is needed to make
[15:10] <zyga> balloons: it just runs: tests/autopilot/run
[15:10] <balloons> so autopilot list checkbox_touch shows 2 tests
[15:11] <balloons> hmm.. interesting run script.. it's not needed
[15:11] <balloons> you can execute autopilot run yourself
[15:14] <sergiusens> cwayne: untappd
[15:14] <dandrader> Saviq, no, the patch wouldn't fix that.
[15:14] <zyga> balloons: SDK bugs then
[15:14] <zyga> balloons: I just created a new app
[15:14] <cwayne> sergiusens: too late, i already did that one :)
[15:14] <Saviq> dandrader, ok, /me files a bug
[15:14] <sergiusens> cwayne: nice; with push notifications?
[15:15] <cwayne> sergiusens: nah, i havent gotten it hooked up to online-accounts yet
[15:15] <sergiusens> cwayne: it is my main concern :-)
[15:15] <sergiusens> being able to toast appropriately
[15:15] <cwayne> sergiusens: :) if you get me an account-plugin ill work it in
[15:16] <sergiusens> cwayne: ok; where does your code live? I was going to do a push notification server + webapp and then expand on the scope;
[15:16] <sergiusens> so there's no conflict yet :-)
[15:16] <sergiusens> the problem is we need to bundle both things in the same click
[15:16] <cwayne> sergiusens: ill create a project on lp and push it up there
[15:16] <sergiusens> so if you give me the branch, I might just piggyback
[15:28] <mardy> Saviq: can you please tell me the bug number?
[15:30] <Saviq> mardy, will do
[15:30] <Saviq> mardy, filing just now
[15:31] <jgdx> mterry, are you able to build uss for armhf?
[15:32] <jgdx> mterry, specifically for your wizard password branch.
[15:32] <mterry> jgdx, uh, I haven't tried recently, but I have been able to.  I remember building it to test that, yeah
[15:33] <mterry> jgdx, doesn't work now?  I'll rebuild in a bit to see what's up
[15:33] <mterry> in the middle of flashing right now
[15:33] <jgdx> mterry, ack. I'm getting dep failures (dbusmock package). If you do have packages laying around, please do send :)
[15:34] <zyga> balloons: so about autopilot
[15:34] <zyga> balloons: let me try if I can get it to work as you said
[15:34] <zyga> balloons: do you want a bug on the SDK for the incorrect / buggy app template?
[15:34] <balloons> zyga, yep. I'll be playing with make autopilot in a bit
[15:35] <balloons> I know #ubuntu-qa was working on the AP templates a bit ago. But I'm not sure who was working on it
[15:35] <Saviq> mardy, bug #1355263
[15:35] <elopio> balloons: it was me. I need to update my branches.
[15:35] <mterry> jgdx, the MP has packages from jenkins: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-utopic-armhf/4380/artifact/work/output/*zip*/output.zip
[15:35] <jgdx> mterry, right. Thanks
[15:36] <zyga> balloons: is that something the SDK team owns?
[15:37] <balloons> zyga, ultimately I suppose yes indeed they own it
[15:37] <balloons> elopio, you own too many things :-)
[15:37] <balloons> zyga, perhaps you could help fix them for all?
[15:37] <elopio> balloons: they keep appearing on my hands
[15:37] <balloons> elopio, perhaps zyga will take the bait
[15:38] <elopio> zyga: https://code.launchpad.net/~elopio/qtcreator-plugin-ubuntu/update_tabs_autopilot_template/+merge/225256
[15:38] <zyga> balloons: I'm not sure where they live yet
[15:38] <zyga> hehe
[15:38] <zyga> maybe
[15:38] <elopio> what happened is that they changed the format of the templates while I was waiting for this to land.
[15:38] <zyga> I'm just learning, not sure what's good / bad yet
[15:38] <elopio> sooo, it needs a little redoing from scratch :)
[15:39] <balloons> best way to learn zyga :-) #ubuntu-autopilot exists as well to help out
[15:47] <cyphermox_> mzanetti: hey?
[15:48] <mzanetti> cyphermox_: hey. just wanted to ask some stuff about bluetooth. Reported this bug: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1355152
[15:48] <mzanetti> cyphermox_: should that work by now or is it still WIP?
[15:49] <cyphermox_> yeah it's possible that's still not working
[15:55] <c_> hello
[15:55] <Guest27003> helo
[16:05] <daker> mhall119: yw
[16:29] <zyga> sergiusens: hey
[16:29] <zyga> sergiusens: are you the upstream for phablet-tools?
[16:29] <ogra_> he is one of them :
[16:29] <zyga> sergiusens: if so I've filed: https://bugs.launchpad.net/qtcreator-plugin-ubuntu/+bug/1355286 (also affects phablet-tools' phablet-shell)
[16:29] <zyga> ogra_: ^^ have a look too
[16:29] <zyga> I talked to zoltan a little, the upcoming adb reorg is also going to affect both
[16:29] <ogra_> zyga, i'll rip that piece apart within the next two days anyway
[16:29] <zyga> and since it also affects plainbox' remote testing I'd like to help
[16:30] <zyga> ogra_: what are your plans?
[16:30] <zyga> ogra_: I knew you were the person to talk to :>
[16:30] <ogra_> we will provide a dbus interface for unprtivileged users to enable ssh ...
[16:30]  * zyga enjoys his recollections from linaro
[16:30] <ogra_> so you will just adb shell ogras-new-script enable ssh
[16:31] <ogra_> phablet-shell witll do the same in the background
[16:31] <zyga> ogra_: ok, can we work together (you, sdk, and hw/cer) -- as we all need this in some form
[16:31] <zyga> ogra_: can you use python3 :>
[16:31] <zyga> ogra_: I'd love to have that in python3-phablet
[16:31] <ogra_> if there are issues with the keys i'll make sure both methods handle thjem similar
[16:31] <zyga> ogra_: the thing is that phablet-shell guesses the key
[16:31] <zyga> ogra_: plainbox doesn't currently care as long as it works
[16:31] <ogra_> erm, no, i wont re-write that stuff from scratch
[16:31] <zyga> ogra_: but the SDK has a per-device key
[16:32] <zyga> ogra_: what? phablet-shell?
[16:32] <ogra_> we can do that later, just not before RTM
[16:32] <zyga> sure but *for* the RTM it has to work on all three cases
[16:32] <zyga> for cert and for sdk (I assume your patches work already)
[16:33] <ogra_> not completely
[16:33] <zyga> I'm not sure what you mean
[16:33] <ogra_> and i didnt know about cert ... i'm in conversation with CI, smoke testing and SDK since several weeks about this
[16:33] <ogra_> (my patches are not completely complete yet was what i meant above)
[16:34] <zyga> cert needs to do remote testing, we can update our code but we need to know what to do
[16:34] <zyga> I see
[16:34] <zyga> ogra_: what are you writing your stuff in?
[16:34] <ogra_> schedule is that everything lands on wed
[16:34] <zyga> (we need py3k APIs)
[16:34] <zyga> oh, fun :)
[16:34] <ogra_> in shell as the stuff is today
[16:34] <ogra_> phablet-tools is 90% shell
[16:34] <ogra_> and a few bits in python
[16:35] <zyga> ogra_: could we gradually replace that with python3? it's still invokabe-from-shell and it would really help us as we need more control than fire-and-forget
[16:36] <ogra_> zyga, yes, but not before rtm
[16:36] <zyga> ogra_: alternatively, what else can we do that has an API (shell scripts are poor API-wise)
[16:36] <zyga> ogra_: ok
[16:36] <zyga> ogra_: so for the RTM, we'll reimplement the new mechanism in python3-phablet
[16:36] <zyga> ogra_: and I assume the SDK team knows what to do about it already
[16:36] <ogra_> well, they use the scripts as is today
[16:36] <zyga> ogra_: is there any description of how the new method works? the DBUS api you've mentioned?
[16:36] <zyga> ogra_: nope! they dont
[16:36] <zyga> I just talked to zoltan
[16:36] <ogra_> ?
[16:36] <zyga> that's why it failed for me
[16:36] <zyga> they do something custom
[16:37] <ogra_> i thought they use stuff like phablet-network
[16:37] <zyga> (maybe they work on using your scripts but that's not in packages today)
[16:37] <zyga> they explicitly scp stuff and do a few other things
[16:37] <ogra_> well, everyone is obligated to use these tools
[16:37] <zyga> anyway, zoltan knows that more than I do
[16:37] <ogra_> we are pretty strict about that for i.e. smoke testing
[16:37] <ogra_> so changes only happen in one place
[16:37] <zyga> ogra_: is that communicated in any way? (there's something I'm not monitoring that I should know about()
[16:38] <zyga> ogra_: sure, that makes sense
[16:38] <zyga> ogra_: though as I said we cannot use your scripts directly so we'll have to reimplement that in python again
[16:38] <ogra_> not really ... we just have made sure that parties involved i discussions know about it in the past
[16:38] <zyga> ogra_: we really only need phablet-shell and something you don't (currently) provider which is like phablet-rsync
[16:38] <zyga> ogra_: ok, I see
[16:38] <zyga> ogra_: could you please append me to the list :)
[16:39] <ogra_> what do you do with phablet-shell actually ? it can only work interactively
[16:39] <zyga> ogra_: I'll be landing plainbox'es remote testing ability and I want us to have a solid foundation for RTM and later
[16:39] <zyga> ogra_: that's one of the things we had to change
[16:39] <ogra_> "had to change" ?
[16:39] <ogra_> are there MPs for this ?
[16:39] <zyga> ogra_: we don't use phablet-shell, I reimplemented the whole logic in python to have API and more than just interactive console
[16:39] <ogra_> it surely isnt in the code today
[16:40] <ogra_> ah, well, then you just go via adb
[16:40] <zyga> ogra_: all the code I have is in that git branch
[16:40] <zyga> ogra_: we don't quite go via adb,
[16:40] <ogra_> which shoudl really be sufficiaent
[16:40] <zyga> ogra_: adb has other issues
[16:40] <zyga> ogra_: we only go via adb initiall as you did
[16:40] <ogra_> the only thing that werid ssh'ing gets you is better tty handling
[16:40] <zyga> ogra_: rsync is far faster
[16:40] <ogra_> which you dont care at all about in automation
[16:40] <zyga> ogra_: and adb push was unreliable
[16:40] <ogra_> oh?
[16:41] <ogra_> we use it everywhere else in autmation
[16:41] <zyga> ogra_: adb also has no error control which we totally require, I know we can work around that with PS1 and such but we need ssh for server-common code paths
[16:41] <zyga> ogra_: yeah, I heard
[16:41] <zyga> ogra_: we could fail it easily
[16:41] <zyga> ogra_: adb pushing lots of small files fails often without meaningful messages
[16:41] <ogra_> yes, the CI and smoke test people have handlers for that (adb return codes)
[16:41] <zyga> ogra_: so we switched to rsync and had no issues
[16:42] <zyga> ogra_: yeah, and again, no python api, cannot reuse, no standalone library, it's not something that we can just depend on and call it a day :/
[16:42] <ogra_> that sounds like a lot of fragmentation to me :(
[16:42] <zyga> ogra_: the CI/cert overlap is a problem but also the reality
[16:42] <zyga> ogra_: we have different needs
[16:42] <zyga> ogra_: although we do a lot of common things
[16:42] <ogra_> which we tried to avoid over the ... well ... last year
[16:42] <zyga> yeah/
[16:42] <zyga> ?
[16:42] <zyga> anyway, that's not a discussion for today
[16:43] <zyga> what we need soon-ish is the new implementation landing so that we can update python3-phablet and continue
[16:43] <zyga> to iterate, talk and converge
[16:43] <ogra_> we need to try to get all parties involved to have the same API for everyone ...
[16:43] <zyga> yeah
[16:43] <zyga> I agree
[16:43] <ogra_> though most of the otrher bits are all shell ...
[16:43] <zyga> see :>
[16:43] <zyga> only we care about error messages and stuff like that ;-)
[16:43] <zyga> and i18n
[16:43] <zyga> and more
[16:43] <zyga> anyway
[16:44] <zyga> have a look at the python code I wrote if you want
[16:44] <zyga> I'm pretty sure it can be made to suit all the parties if everyone else wants just shell
[16:44] <zyga> ogra_: who is the best CI person to talk to?
[16:44] <zyga> ogra_: I'll try to follow up
[16:47] <ogra_> zyga, hmm, dunno ... for the smoke testing stuff plars is your man ... for CI thats probably fginther
[16:48] <zyga> ogra_: ok, noted
[16:48] <zyga> ogra_: thanks!
[16:48] <plars> zyga: what's the question?
[16:49] <ogra_> plars, if you can re-write all your stuff in python :)
[16:49]  * ogra_ grins
[16:49] <plars> oh sure... done!
[16:49] <zyga> ogra_: well, that's not fair
[16:49] <zyga> ogra_: I'm not asking anyone to do that
[16:49] <plars> well, there are a handful of shell scripts out there
[16:49] <ogra_> yeah, sorry, bad joke
[16:49] <plars> but mostly python
[16:49] <zyga> ogra_: I wrote a 100% replacement for phablet-shell version at the time
[16:49] <zyga> ;-)
[16:50] <zyga> ogra_: invoked from shell it works exactly like that
[16:51] <plars> zyga: in the future, we are probably going to be looking to use adt-run for many more things
[16:51] <plars> zyga: it uses adb to set up the ssh forwarding for adb devices, and then does things over ssh
[16:52] <ogra_> zyga, note that the only change i'm currently working on for phablet shell is to drop the "start ssh" call from there and replace it with a dbus call, you should be able to easily do the same in your python-phablet code
[16:52] <plars> zyga: in the meantime, if I need a return code from an adb command, we just have a wrapper that feeds it back to us after running the command
[16:52] <ogra_> i had not planned to do any additional changes to it atm
[16:52] <ogra_> (especially since i lack the time for more)
[16:52] <plars> it's only really a problem when you want to run more complex things - and that's where small shell scripts come in that get pushed to the device, run them using the adb wrapper
[16:53] <ogra_> (just looking at your github tree)
[16:53] <zyga> plars: we cannot use adt-run, we are not running DEP-8 tests
[16:53] <zyga> ah, wait
[16:53] <zyga> adb-run?
[16:53] <zyga> ogra_: excellent
[16:53] <plars> zyga: no, you had it right - autopkgtest
[16:53] <zyga> oh
[16:54] <ogra_> zyga, all you should need is to replace line 370 in your code :)
[16:54] <zyga> so we cannot use that, it's totally not what we do :/
[16:54] <ogra_> (in phablet.py)
[16:54] <zyga> cool
[16:54] <zyga> ogra_: that code is out of date, I had a few fixes to it (minor) later on
[16:54] <ogra_> notze that this wont fix anything in phablet-shell*s key behavior though
[16:54] <zyga> ogra_: and some extra functionality (like phablet-rsync)
[16:54] <zyga> ogra_: the key handling can be already customized in the python api
[16:55] <ogra_> thats a separate issue we need to fix
[16:55] <zyga> ogra_: all that needs redefinition is the UI of how the key is picked
[16:55] <zyga> eyah
[16:55] <zyga> yeah*
[16:55] <zyga> ok
[16:55] <zyga> I should really EOD now
[16:55] <zyga> I've been doing this too long
[16:55] <ogra_> haha
[16:55] <zyga> thanks for your time, both of you _)
[16:55] <zyga> :-)
[16:55] <ogra_> thanks for  the heads up
[17:16] <ogra_> cyphermox_, so if i pull psk=* out of the NM file,  is that enough or are there other keys for the keys ... (i see wep-key[0-4], do we need to support that in phablet-network ? )
[17:16] <ogra_> err
[17:16] <ogra_> [0-3] actually
[17:16] <cyphermox_> yeah, there is also wep-key
[17:16] <cyphermox_> that's about it
[17:17] <ogra_> hmm, so i need to pull them out as well, k
[17:17] <cyphermox_> there's a chance the password actually isn't in the file though, where password-flags= is set IIRC
[17:17] <ogra_> well, then we wont find a ky and fail for now
[17:17] <cyphermox_> that's partly why asking for the AP name and password then in phablet-network might be a good idea
[17:18] <ogra_> (i can add some interactive fancy "please enter your key manually" later)
[17:18] <cyphermox_> don't even need to do that much
[17:18] <ogra_> for now we just want to be sure to not break automation
[17:18] <cyphermox_> it could just straight proxy the values to the nmcli command
[17:18] <cyphermox_> well.. the automation is broken anyway
[17:18] <ogra_> who are supplying an artificial file anyway :)
[17:19] <cyphermox_> right. making it passed as a command-line parameter could simplify all of this
[17:19] <ogra_> currently all smoke and I testing uses phablet-network to bring the devices online when provisioning
[17:19] <ogra_> but since that happens from a server that isnt on the wlan they just provide a file for that
[17:19] <cyphermox_> yes, I understand
[17:19] <cyphermox_> I'm saying you wouldn't have to generate a file if you adjusted the automation as well
[17:20] <cyphermox_> it's not a lot of work to do so
[17:20] <ogra_> oh, like --ssid= --key= options
[17:20] <ogra_> yeah
[17:36] <mterry> robru, phablet-shell is giving me "Received disconnect from 127.0.0.1: 2: Too many authentication failures for phablet" -- is this something you've seen?
[18:09] <sergiusens> mterry robru you probably have more than 5 keys which would trigger that and need to pass the key id manually
[18:10] <mterry> sergiusens, I understand the words... but not what you mean  :)
[18:11] <ogra_> mterry, might be related to bug 1355286 ?
[18:11] <sergiusens> mterry: your ~/.ssh has more than 5 id_rsa*; sshd fails auth for the 5th try iirc; they key that grants the access is probably 5+n away
[18:14] <mterry> hmm
[18:15] <mterry> I'll figure it out between those two problems, I'm sure one of them is it
[18:15] <mterry> I did recently play with the SDK
[18:15] <olli> awkward... how do I become root/su on the device
[18:15] <olli> iow what's the password
[18:20] <ogra_> there i none
[18:20] <ogra_> just hit enter
[18:20] <ogra_> *is none
[18:26] <sergiusens> ogra_: olli if you set a pin, it's the pin
[18:27] <ogra_> yeah
[18:27] <robru> mterry, sergiusens : yeah sorry, phablet-shell has bitrotted some since it was introduced. i haven't tried it recently, would be surprised if it even worked frankly. didn't we disable the ability to launch ssh or something critical?
[18:27] <sergiusens> robru: I'm using it fine
[18:27] <ogra_> robru, many people use it ... i have to change it for dev mode anyway
[18:28] <robru> sergiusens, nice
[18:28] <ogra_> i'll look into the key handling after dev mode landed and will try to sanitize it
[18:28] <sergiusens> ogra_: and add the ability to run commands :-)
[18:28] <robru> ogra_, phablet-shell attempts to mimic ssh-copy-id by just using the key with the most recent mtime.
[18:28] <ogra_> right
[18:29] <sergiusens> robru: yeah, and playing with the sdk and having too many keys might break that :-)
[18:29] <ogra_> sergiusens, well, see the python tree thats attached to that bug above
[18:29] <robru> mterry, try doing 'touch ~/.ssh/id_rsa_some_key_you_have.pub' and see if that helps you
[18:29] <ogra_> seems there is actuall a python module that mimics phablet-shell and more
[18:30] <ogra_> something we should think about switching to ...
[18:30] <ogra_> (but indeed post RTM stuff)
[18:33] <robru> wow, that python module is 600 lines long. totally inscrutable
[18:34] <robru> phablet-shell is 94 lines to put it in perspective
[18:36] <ogra_> robru, it does a lot more ... like having proper return valuesfrom adb operations ... replacing adb push/pull with an rsync backend etc
[18:36] <robru> hm
[18:36] <ogra_> you would still need a phablet-shell to make use of it ... but that could then be 10 lines ;)
[18:37] <ogra_> and just use the bits the module ships
[18:37] <ogra_> (but as i said, thats post RTM stuff anyway ... no more heavy changes in the infrastructure if avoidable)
[18:38] <robru> yeah for sure
[18:42] <kenvandine> seb128, mind trying something ?
[18:42] <kenvandine> ctx.font="normal normal normal %1px Ubuntu".arg(fontHeight)
[18:43] <kenvandine> in the battery panel
[18:43] <kenvandine> seb128, with antialias enabled
[18:43] <kenvandine> at least on the device, it looks good to me when all the properties are included
[18:43] <kenvandine> but now after trying a bunch of variations, i don't trust my eyes :)
[18:44] <seb128> kenvandine, k
[18:44] <kenvandine> seb128, the first 3 properties are "optional"
[18:44] <kenvandine> but it looks like ass if i leave them out :)
[18:46] <seb128> kenvandine, no, that looks crap compared to the commented property, at least on my desktop config
[18:46] <kenvandine> seb128, note: it still looks awefull on the desktop
[18:46] <kenvandine> but on the device i think it looks much better
[18:46] <seb128> well, seems luck then?
[18:46] <kenvandine> font rendering is different on the desktop, clearly :)
[18:47] <seb128> does it look better than the comment property on the device?
[18:47]  * kenvandine thinks so
[18:47] <kenvandine> it looks quite smooth imo
[18:47] <seb128> k, let me try
[18:47] <kenvandine> but i can't explain why specifying all the optional properties in the font string makes a difference
[18:50] <seb128> kenvandine, to me the version without antialiason still looks better (on the n4)
[18:50] <seb128> liasing
[18:50] <kenvandine> ok
[18:50] <kenvandine> i knew i  shouldn't trust my eyes there
[18:50] <kenvandine> after trying like 20 combinations :)
[18:50] <seb128> yeah, that's a bit tricky
[18:51] <seb128> but I that version also looks better cross devices
[18:51] <seb128> so I would prefer to stick to it
[18:51] <seb128> even if I don't understand what's going on
[18:51] <seb128> seems like a canvas/toolkit bug
[18:53] <kenvandine> yeah
[18:53] <kenvandine> something
[18:54] <kenvandine> oh...
[18:54] <kenvandine> seb128, add one more thing
[18:55] <kenvandine> renderTarget: Canvas.FramebufferObject
[18:55] <kenvandine> right below antialiasing
[18:57] <kenvandine> seb128, something else that's interesting is the quality varies without code changes
[18:57] <kenvandine> seb128, i tried to take screenshots of the device with both antialiasing enabled and disabled
[18:57] <kenvandine> but was changing the code on my desktop instead...
[18:58] <kenvandine> so no code changes on the device, and the 2 screenshots look pretty different
[19:01] <seb128> kenvandine, that's confusing :/
[19:02] <kenvandine> seb128, indeed... but i think it's more stable with changing the renderStrategy
[19:02] <kenvandine> to Canvas.Threaded
[19:02] <kenvandine> it defaults to Immediate
[19:03] <seb128> kenvandine, I don't like it still feels random
[19:03] <seb128> changing those strategy shouldn't impact on text aliasing for example
[19:03] <kenvandine> i would thinks so
[19:03] <kenvandine> it all feels weird
[19:04] <kenvandine> and... changing the renderTarget seems to trigger crashing the shell randomly :)
[19:04] <seb128> shrug
[19:04] <kenvandine> i've had 2 shell crashes while loading the panel :-D
[19:04] <seb128> quality toolkit!
[19:04] <kenvandine> so i guess we shouldn't mess with that :)
[19:04] <seb128> yeah
[19:04] <seb128> well, I'm not going to do more than my change to comment the property
[19:05] <seb128> if you want to submit another changeset I'm happy to review it though
[19:05] <kenvandine> yeah, that's a good start :)
[19:05] <kenvandine> i'll think about it
[19:05] <kenvandine> that font rendering has bugged me for a while, but never enough to stop what i was doing and look at the code
[19:05] <seb128> thanks ;-)
[19:06] <seb128> I first pondered doing the legend out of the canvas with the toolkit
[19:06] <seb128> but it was challenging to align the yesterday/today "|" with the legend then
[19:06] <kenvandine> it's also really puzzling that antialiasing: false doesn't look better than just not setting it
[19:06] <seb128> yeah, I don't get it
[19:07] <kenvandine> wtf is up with that?
[19:07] <seb128> default value set or implicit should be the same
[19:07] <kenvandine> indeed
[19:07] <kenvandine> unless... there is a signal emitted there somewhere
[19:07] <seb128> it's like that codepath was creating issues
[19:07] <kenvandine> so setting it to false triggers a repaint
[19:07] <kenvandine> or something
[19:07] <seb128> there is no repaint
[19:07] <kenvandine> maybe it's actually null by default
[19:07] <seb128> I put a console.warn in onPaint
[19:07] <kenvandine> ok
[19:07] <kenvandine> weird
[19:08] <seb128> it's painted only once
[19:08] <seb128> then repainted if you e.g rotate or resize
[19:22] <kenvandine> seb128, do you have time for a review?
[19:22] <kenvandine> https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/brightness_slider/+merge/230345
[19:23] <kenvandine> a little bigger than the ones you had me do :)
[19:23] <seb128> kenvandine, I'm about to go but I can have a look a bit later maybe, or tomorrow morning otherwise
[19:23] <kenvandine> no worries
[19:23] <kenvandine> or maybe i'll harass someone else :)
[19:23] <seb128> that works too ;-)
[19:23] <seb128> I'm going to try to do a landing tomorrow
[19:24] <kenvandine> jgdx, still around?
[19:24] <kenvandine> seb128, i'm doing one now
[19:24] <seb128> oh, great
[19:24] <kenvandine> well, hijacking ralsina's :)
[19:24] <seb128> I was waiting on CI to do retries
[19:24] <seb128> but that takes a while
[19:24] <kenvandine> yeah, i did that already
[19:24] <kenvandine> we can get them building in the silo and all
[19:24] <seb128> great
[19:24] <kenvandine> it'll be an hour or so before ralsina will be ready for a silo
[19:25] <kenvandine> so should be good timing
[19:25] <kenvandine> we can test it all in the morning then
[19:25] <kenvandine> seb128, so feel free to check on it in the morning :)
[19:25] <kenvandine> i'll have it all built in a  silo before i leave tonight
[19:27] <seb128> kenvandine, sure, I'm going to try the silo tomorrow morning
[19:27] <kenvandine> seb128, the best thing about the time zones :)
[19:27] <seb128> ;-)
[19:37] <jgdx> kenvandine, sure i
[19:37] <jgdx> s
[19:38] <kenvandine> jgdx, mind reviewing https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/brightness_slider/+merge/230345
[19:38] <jgdx> kenvandine, sure
[19:39] <jgdx> mterry, also looking at yours now, got nowhere with adb on my other device
[19:40] <mterry> oh weird
[20:06] <jgdx> kenvandine, could I have one back? https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/default-sims/+merge/230227
[20:06] <kenvandine> jgdx, yup
[20:07] <jgdx> kenvandine, another one, small one :) https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/1350380-hide-radiosettings-when-offline/+merge/230226
[20:08] <kenvandine> ok
[20:10] <jgdx> kenvandine, I'll have to wait a bit for the jenkins armhf packages, since sbuild is broken @ my laptop
[20:11] <kenvandine> jgdx, nod
[20:11] <kenvandine> CI is taking ages...
[20:12] <jgdx> kenvandine, should we land the rest of the dual sim stuff when default sims is gtg?
[20:13] <kenvandine> jgdx, maybe, now that CI should be fixed lets try to wrap it up
[20:13] <jgdx> awesooome
[20:13] <kenvandine> i have a big landing request right now, lets get the rest of the dual sim stuff lined up for the next landing
[20:13] <kenvandine> tomorrow
[20:13] <kenvandine> assuming we get builds out of CI
[20:14] <kenvandine> peddle faster jenkins!
[20:14] <jgdx> paddle
[20:14] <kenvandine> :)
[20:19] <pmcgowan> kenvandine, whats going into the silo?
[20:20] <kenvandine> pmcgowan, look at line 29 of the spreadsheet
[20:20]  * pmcgowan looks
[20:20] <lotuspsychje> popey: great work on the pdf man! you just made my day
[20:21] <lotuspsychje> my whole pdf collection on nexus7 touch :p:p
[20:21] <popey> ah, wasn't me ☻
[20:22] <lotuspsychje> oh, you just replyed then
[20:22] <pmcgowan> kenvandine, so just turning on location control pretty much, plus fixes
[20:24] <lotuspsychje> zhang boren it is :p
[20:26] <lotuspsychje> fantastic work
[20:26] <lotuspsychje> cheers
[20:26] <kenvandine> pmcgowan, yeah
[20:26] <kenvandine> maybe the brightness control thing too
[20:27] <pmcgowan> whats that?
[20:27] <kenvandine> actually, probably not today
[20:27] <kenvandine> it fixes one of the rtm bugs :)
[20:27] <kenvandine> basically updated the battery panel to match design
[20:27] <kenvandine> dropping the brightness slider in favor of a push to the brightness panel
[20:27] <pmcgowan> ah ok that was a might do but fine
[20:28] <kenvandine> so we can move that control into that panel
[20:28] <kenvandine> then it'll get translated properly
[20:28] <pmcgowan> ok
[20:28] <mhall119> is it just me or does the x86 emulator use more CPU while idle than it used to?
[20:36] <mhall119> cwayne: have you done any C++ scope dev? I'm stuck with an exception I don't know how to fix
[20:36] <mhall119> unity::ResourceException: /opt/click.ubuntu.com/com.ubuntu.developer.mhall119.ubuntucommunity/0.5/ubuntucommunityscope/libcom.ubuntu.developer.mhall119.ubuntucommunity_ubuntucommunityscope.so: undefined symbol: _ZN25UbuntucommunityscopeQuery16progress_handlerERKN4core3net4http7Request8ProgressE
[20:42] <cwayne> mhall119: nope, sorry
[20:42] <dobey> mhall119: are you using MODULE or SHARED as the target library type in the CMakeLists.txt?
[20:43] <mhall119> dobey: um....whatever the template used
[20:45] <dobey> mhall119: so, the problem is that your built scope is referencing an undefined symbol. using the MODULE target library type will hide these as it is expected some symbols may be resolved when the library is loaded into whatever process loads the plug-in. in this case though, the missing symbol is an internal one that is for some reason undefined, so it's not loading, and you don't get the error until the scope runner ties to d
[20:47] <mhall119> dobey: I'm afraid I really don't understand....I used the template to create a scope project, which produced the cmake files for me
[20:49] <dobey> mhall119: is the code visible somewhere on launchpad or such?
[20:49] <mhall119> dobey: https://code.launchpad.net/~mhall119/+junk/ubuntu-community-scope
[20:50] <dobey> mhall119: https://bazaar.launchpad.net/~mhall119/+junk/ubuntu-community-scope/view/head:/src/ubuntucommunityscope-query.h#L23
[20:50] <dobey> mhall119: that is not defined in the code
[20:52] <dobey> the .cpp file has no UbuntuCommunityscopeQuery::progress_handler implementation, that is
[20:55] <mhall119> dobey: ah, leftovers from when I was trying to use net-cpp the wrong way
[22:23] <jgdx> yay, successful uss build!