[05:14] <Term1nal> Desktop mode for ubuntu touch available yet?
[05:15] <RAOF> No
[05:15] <Term1nal> Aww :( ok see you in 6 months!
[05:15] <Term1nal> Where I'll ask agian
[05:15] <Term1nal> :D
[06:17] <CalmForest> hello anybody here?
[06:18] <CalmForest> How long does it take to boot for the first time? I tried manually flashing the zip, but after google it just gives me a black screen. wiped and tried again still results in the same situation.
[06:27] <CalmForest> anybody?
[06:42] <CalmForest> hi guys?
[07:23] <CalmForest> can anyone help me? or tell me what time it is at least
[08:13] <dholbach> good morning
[09:59] <mardy> dbarth_: hi! Is there any way we can speed up the landing of item 240? https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1
[10:01] <timppa> Hi, is there a bug open on the OTA update blacklist.tar.* file missing/corrupt?
[10:02] <timppa> I've had the problem since few images back. I can update via adb system-image-cli -v command just fine
[10:04] <ogra_> bug 1277589
[10:05] <ogra_> mardy, saking in #ubuntu-ci-eng is better for that kind of questions ... (you can most likely speed it up by running the AP tests in advance)
[10:05] <ogra_> s/saking/asking/
[10:13] <jibel> barry, mandel wrt. the bug above, I added a test case to the description and can reproduce it very easily. If you need specific info or run some tests just ask.
[10:20] <ogra_> jibel, heh, well, that only works for every 10th person
[10:21] <ogra_> (which is the big issue with this bug)
[10:21] <ogra_> many dont get it at all ... and it shows across all devices
[10:23] <jibel> ogra_, at least I can reproduce by flashing 176 and upgrading to 178 on my network, 3 times in a row
[10:23] <ogra_> yeah, if it happes to you it seems to be consistent
[10:38] <mhr3> didrocks, looks like unity-scope-scopes is in distro now, can i press the magic merge and clean?
[10:38] <mhr3> it's all red, so i'm scared :P
[10:41] <didrocks> mhr3: you can always press the magic merge and clean, it will tell you if it wasn't the right time :)
[10:41] <mhr3> heh, ok
[10:52] <davmor2> Morning all
[10:58] <tvoss> pitti, salut
[11:15] <dbarth_> mardy: yes, get the landing team to activate it
[12:21] <timppa> 20140213.1 broken on Mako? Does not boot to unity
[12:22] <popey> thats 179, yes, broken.
[12:22] <timppa> :(
[12:23] <timppa> popey: Any way to fix it without new image?
[12:23] <popey> I don't know, it's being discussed in #ubuntu-ci-eng
[12:23] <timppa> popey: ok
[12:24] <popey> you can roll back to 178
[12:24] <timppa> popey: what's the command on adb shell for rollback?
[12:25] <timppa> popey: system-image-cli -v -b 177 ?
[12:25] <timppa> 178..
[12:25] <popey> -1 i think
[12:25] <popey> -1 previous build, -2 previous previous...
[12:26] <popey> maybe check the docs for system-image-cli
[12:26] <timppa> any idea how I can enable networking?
[12:27] <popey> phablet-network
[12:33] <timppa> popey: nope, I have wireless connections configured but they cannot be enabled
[12:40] <timppa> popey: I could enable 3G data via ofono scripts, I'll try to downgrade
[12:40] <timppa> popey: thanks!
[12:53] <timppa> popey: It just refuses to downgrade. I tried with -b -1 -b 178, -b 177
[12:53] <timppa> popey: how can I check which image it "thinks" it's running?
[12:53] <popey> timppa: adb shell system-image-cli --info
[12:54] <timppa> popey: hmm, 179
[12:56] <timppa> popey: It seems it's doing something but after install it's still 179 :/
[12:59] <sergiusens> timppa, from the outside? ubuntu-device-flash --channel devel-proposed --revision 178 ?
[13:00] <sergiusens> unless you want to use system-image-cli; then I have nothing to say
[13:00] <timppa> sergiusens: as long as I don't lose any data on the phone it's fine whichever utility I use :)
[13:02] <sergiusens> it's not supposed to delete your data unless you --wipe
[13:03] <timppa> sergiusens: is it phablet-flash? Or which package contains the ubuntu-device-flash?
[13:03] <popey> sergiusens: any chance you can update https://wiki.ubuntu.com/Touch/Install with details about ubuntu-device-flash ?
[13:04] <popey> its the main place we send people to and doesn't say that phablet-flash is no longer maintained
[13:05] <ybon> popey: I think I'm stuck on OSMTouch waiting for QT5.2 to land; any apps/issues I can work on now and then in the meantime (QML/js part mainly)?
[13:05] <ybon> (I can just go to launchpad and pick one for sure, but as you coordinate things :) )
[13:05] <popey> ybon: yeah!
[13:06] <popey> ybon: could you take a look at the active reviews for calendar perhaps? That's all QML. https://code.launchpad.net/ubuntu-calendar-app/+activereviews
[13:06] <ybon> sure, lets do that :)
[13:06] <sergiusens> timppa, apt-get ubuntu-device-flash
[13:07] <popey> ybon: kunal would really appreciate the help, I'm sure!
[13:07] <popey> ybon: also, if you're any good at performance tuning, if you could figure out a better way to do the year view that would be awesome. profiler shows it spends a lot of time in a chunk of code setting colors for the hundreds of elements on screen at once.
[13:07] <ybon> popey: in two world, the worlkflow for me is: review the merge, and give comments?
[13:08] <popey> ybon: yes.
[13:08] <ybon> ok
[13:08] <popey> Thank you!
[13:08] <ybon> :)
[13:08] <popey> ahayzen: pounce!
[13:09] <timppa> sergiusens: I'm running saucy, no such package?
[13:12] <popey> ybon: we have a calendar app irc meeting in ~40 mins in #ubuntu-touch-meeting if you fancy joining
[13:15] <sergiusens> timppa, ppa:phablet-team/tools
[13:16] <timppa> sergiusens: thanks!
[13:16] <ybon> popey: sure
[13:17] <sergiusens> popey, https://wiki.ubuntu.com/Touch/Install
[13:17] <sergiusens> feel free to make edits
[13:18] <sergiusens> popey, would be good to remove manual installation and have ogra_ add the rootstock stuff
[13:18] <popey> yeah, if that worked
[13:18] <ogra_> sergiusens, popey's recovery on flo has no /cache partition at all ... i have no clue why
[13:18] <ogra_> which indeed breaks rootsotck completely
[13:19] <ogra_> popey, but other install wouldnt work either without that, not a rootstock issue
[13:19] <popey> sure.
[13:20] <sergiusens> it works
[13:20] <sergiusens> popey, what recovery are you running?
[13:20] <popey> tried http://paste.ubuntu.com/6915695/
[13:21] <popey> the instructions from there, and tried a recovery from ogra_
[13:21] <sergiusens> popey, try too boot once without rootstock; seem if that fixes it
[13:22] <popey> boot to what?
[13:22] <popey> if i boot I get a busybox shell
[13:22] <ogra_> popey, to android
[13:22] <ogra_> but you said you did that at least once
[13:23] <popey> yeah
[13:23] <popey> i just get busybox
[13:23] <sergiusens> popey, busybox booting to android?
[13:23] <ogra_> yeah, indeed, since the tarball couldnt be unpacked
[13:23] <popey> if I just adb reboot, i get busybox
[13:23] <ogra_> popey, no, your initial android 4.4 boot to android ... did you do that
[13:24] <sergiusens> what I'm saying is; flash fully without rootstock; use the ubuntu zips
[13:24] <popey> it had 4.3 or something
[13:24] <popey> i updated it and rebooted
[13:24] <ogra_> ah !
[13:24] <popey> hang on
[13:24] <popey> i did go into 4.4
[13:24] <popey> then started flashing it
[13:24] <ogra_> and you booted the 4.4 before ?
[13:24] <ogra_> it should have cared for the partition
[13:25] <popey> i started out of the box with 4.3, booted into android, system update, booted into android 4.4, booted into fastboot and thats where I started with your guide
[13:25] <ogra_> hmm
[13:32] <popey> ogra_: do i need to start again back on android original 4.4 ?
[13:32] <ogra_> i would do so
[13:32] <timppa> sergiusens: ubuntu-device-flash didn't work, error:  Cannot push /path/to/ubuntu-xxx.tar.xz to device
[13:33] <ogra_> what was the actual /path/to ... ?
[13:33] <ogra_> :)
[13:34] <popey> ogra_: https://developers.google.com/android/nexus/images#razor right?
[13:35] <ogra_> hmm, i thought it was flo there too
[13:35] <ogra_> iirc razor was the 3G grouper variant
[13:36] <popey> razor vs razorg
[13:36] <ogra_> hmm, k
[13:36] <ogra_> then i'm probably wrong
[13:36] <popey> nvm, it happens, you get used to it
[13:37] <timppa> ogra_: /home/timppa/.cache/ubuntuimages/pool
[13:37] <timppa> ogra_: file exists in that path
[13:38] <jdstrand> mhall119: hope you don't mind-- I added several things to your click frameworks todo list
[13:39] <ogra_> timppa, well, that /path/to in the error message looks really weird
[13:40] <timppa> ogra_: :) Well, I did not type the original path. My IRC client and the laptop which I'm working with the phone are two different machines so no copy-paste...
[13:47] <timppa> ogra_: which patch ubuntu-device-flash tries to push the image? Maybe there is not enough free space?
[13:48] <timppa> ogra_: pastebin.ubuntu.com/6925548
[13:49] <ogra_> timppa, yeah, check the free space on the device
[13:51] <timppa> ogra_: pastebin.ubuntu.com/6925571/
[13:52] <ogra_> /dev/disk/by-partlabel/cache    552M  366M  186M  67% /android/cache
[13:52] <ogra_> looks like you still have some spare space
[13:52] <ogra_> timppa, try using recovery mode and use -d mako for the flash command
[13:54] <timppa> ogra_: I'll try, thanks
[13:56] <timppa> ogra_: problem was that there was not enough space on cache slice
[13:56] <ogra_> right, but that theoretically shouldnt happen
[13:56] <timppa> ogra_: theoretically :)
[13:56] <popey> sergiusens: ok, so with this 2013 nexus 7, which guide should I use to take it from stock android 4.4 to ubuntu goodness?
[13:57] <ogra_> yeah
[13:57] <ogra_> popey, the pastebin still
[13:57] <timppa> ogra_: thank you for the help!
[13:57] <popey> ok
[13:57] <ogra_> (i dont think there is any other valid guide anymore)
[13:59] <MacSlow> anybody else having problems with the image in the emulator not displaying anything?
[14:01] <ogra_> MacSlow, if you used the latest one from -proposed, thats broken (see the ML)
[14:01] <ogra_> if you dont, take into account that the first boot of the emulator takes >10min
[14:02] <MacSlow> ogra_, hm... pulled the image on this machine before lunch... so I guess I've the broken one
[14:04] <popey> ogra_: flo flashed \o/
[14:04] <ogra_> yay
[14:04] <MacSlow> ogra_, so I guess I've to disable -proposed and grab a new one then
[14:05] <ogra_> so your upgrade to 4.4 somehow didnt create the cache partition on the first run
[14:05] <ogra_> MacSlow, see the ML ... there is a workaround
[14:05] <ogra_> MacSlow, or go to lunch ... there is a new image with the fix building already
[14:06] <ogra_> shuld be ready in 30-34min
[14:06] <MacSlow> ogra_, I had lunch by now :)
[14:06] <MacSlow> ogra_, I'll wait then
[14:06] <ogra_> ah, i missed how late it already is :)
[14:09] <mterry> ogra_, missing exec bit?  how did it work at all?
[14:09] <ogra_> mterry, i didnt have merged the merge branch back into the main branch ... ricardo merged the debdiff it seems, then added his merge and uploaded
[14:10] <ogra_> the debdiff didnt have the exec bit
[14:10] <barry> jibel: yes, i'm flashing to 174 and upgrading from there.  i've seen it just once on my device, but hopefully that will be good enough to capture
[14:10] <ogra_> mterry, so my upload worked fine ... and his (with a completely unrelated change set) didnt
[14:12] <cwayne> mterry, hey, so for thaat demo-users stuff, it's showing up on the mako now as well, i thought it only was supposed to do that on tablet?
[14:17] <mterry> ogra_, sorry, got disconnected.  So do we think the exec bit fix is all we need?  I remember with image 177 only sometimes were people seeing a black screen.  Which sounded like a USC crash, not an exec bit problem
 mterry, i didnt have merged the merge branch back into the main branch ... ricardo merged the debdiff it seems, then added his merge and uploaded
 the debdiff didnt have the exec bit
 mterry, so my upload worked fine ... and his (with a completely unrelated change set) didnt
[14:18] <mterry> ogra_, oh this was post 177?  I see
[14:18] <ogra_> 179
[14:18] <ogra_> but 180 is already building with the fix included
[14:18] <mterry> ogra_, well I still feel nervous about 177's occasional black-screen boot.  I'm going to spend some time rebooting today and see if I can hit it
[14:19] <ogra_> i havent had a black screen oot here
[14:19] <ogra_> and i havent heard from others
[14:19] <ogra_> apart from one person on the ML who didnt even mention which device he has
[14:19] <mterry> ogra_, on the landing thread for 177, two people mentioned
[14:19] <mterry> ogra_, one of them said mako
[14:20] <ogra_> mterry, for 177 ? are you not mixing the threads here ?
[14:20] <mterry> ogra_, listen, I don't want anything to need another nested mode revert   :)
[14:20] <mterry> ogra_, let me dig it up
[14:20] <mterry> ogra_, sorry, 176 was the image number
[14:21] <mhall119> jdstrand: I don't mind at all, especially since most of them are assigned to you :)
[14:21] <mterry> ogra_, Sebastian Gomułka reported it with mako.  I guess just the one
[14:23] <ogra_> mterry, well, as long as we hear it from only one ...
[14:23] <ogra_> mterry, note that if apport or whoopsie kick in after an upgrade, the boot can take very long ... i would currently be inclined to assume that was the case for him and he just didnt give feedback that it worked later
[14:24] <mterry> ogra_, hmm, fair
[14:25] <mterry> well, I'm still nervous, but won't spend a bunch of time trying to reproduce
[14:29] <jdstrand> mhall119: hehe
[14:29] <jdstrand> mhall119: the one for cjwatson we already agreed to (hi Colin!)
[14:29] <jdstrand> mhall119: and the one for bzoltan just makes his life easier
[14:29] <mhall119> jdstrand: as long as there aren't more items with [mhall119] on them, I'm happy :)
[14:29] <jdstrand> hi Zoltan! :)
[14:30] <jdstrand> hehe
[14:30] <cjwatson> sure, it's just blocked behind libclick
[14:30] <cjwatson> once I finish the https installer work I'm doing at the moment, that's next on my list per guidance from Steve
[14:30] <jdstrand> cjwatson: so, I'm not sure if you will land that for FF, but I can just do the parsing myself for the tag to unblock on the app showdown
[14:31] <jdstrand> ah, ok, cool, maybe I won't need to do that
[14:31] <jdstrand> s/tag/framework/
[14:31] <pmcgowan> libclick woopee
[14:31] <pmcgowan> jdstrand, gave you write access
[14:31] <jdstrand> thanks
[14:31]  * jdstrand changes 'link-reviewers-rools to 'click-reviewers-tools'
[14:32] <jdstrand> I don't have anything to do with that first project
[14:32] <jdstrand> err, lick-reviewers-tools
[14:32] <jdstrand> jokes are funnier when you type them correctly
[14:32] <pmcgowan> bad cut and paste I suspect
[14:32] <jdstrand> :)
[14:33] <pmcgowan> not the first time
[14:33] <ogra_> lick-reviwers ? is that an order ?
[14:33] <pmcgowan> dooh
[14:33] <jdstrand> there we go :)
[14:33] <cjwatson> jdstrand: maaaaaaaaaaybe
[14:34] <jdstrand> cjwatson: click-apparmor already hard codes, I'll hard code for this for now, then transition whenever libclick lands
[14:34] <cjwatson> jdstrand: if you can parse it yourself initially, that would certainly take the pressure off a bit
[14:34] <bzoltan> jdstrand: hello there ... who summoned me and for what reason? :)
[14:34] <davmor2> dbarth_, alex-abreu: Guys I installed the bbc news webapp and noticed that if I cover the sensors the screen blanks is that meant to happen ?
[14:34] <jdstrand> cjwatson: np
[14:35] <jdstrand> bzoltan: just the thread on ubuntu-appstore-developers on the 'Switching Click framework to 14.04 Dev' tasks
[14:35] <alex-abreu> davmor2, no, the webapp displays fine otherwise?
[14:35] <alex-abreu> davmor2, I dont see how it can be related to webapp per se
[14:35] <bzoltan> jdstrand: is there anything I need to do?
[14:35] <dbarth_> davmor2: wdym by "cover the sensors"?
[14:35] <davmor2> alex-abreu: Yeap it fine and if I remove my thumb from the sensors the screen unblanks
[14:36] <dbarth_> ?!
[14:36] <alex-abreu> davmor2, no idea why it does that, but it shouldn't be specific to webapps ...
[14:38] <davmor2> dbarth_: I put the phone down initially on my printer which has a fairly enclosed tray and the screen went out so I took a closer look.  Basically by the earpiece you have the sensors for light and proximity and those are blanking the screen from what I can tell
[14:39] <davmor2> alex-abreu: and you are right it is happening on normal apps too
[14:39] <robotfuel_> boiko: ping
[14:40] <alex-abreu> phfewww
[14:43] <davmor2> okay hands up if you deal with the proximity and light sensors :D
[14:43] <pmcgowan> davmor2, I dont see any relevant changes for that, which build are you on?
[14:44] <ogra_> davmor2, ricmm
[14:44] <davmor2> pmcgowan: 178, It might not be a current issue it might be an older one that I just happen to of stumbled onto
[14:44] <jdstrand> bzoltan: there are a couple of items in that thread, yes
[14:45] <pmcgowan> davmor2, never seen that, and not here on 176
[14:45] <davmor2> pmcgowan: could it be the new unity8 code that landed on 178?
[14:46] <pmcgowan> davmor2, I suppose, maybe greyback would know if any relevant code there
[14:46] <jdstrand> bzoltan: https://lists.launchpad.net/ubuntu-appstore-developers/msg00760.html (you have items '1' and '11')
[14:48] <davmor2> pmcgowan: hmmm it might actually be specific to maguro too mako is on a semi custom up-to-date build and it isn't happening there
[14:48] <pmcgowan> davmor2, interesting, I see a platform_api fix for a sensors call in 177
[14:49] <greyback> pmcgowan: davmor2: I've nothing to do with sensors really, it's powerd that reads that information directly via platform api.
[14:50] <pmcgowan> ack
[14:56] <boiko> robotfuel_: pong
[14:56] <robotfuel_> boiko: can you review this mp when you have time? https://code.launchpad.net/~chris.gagnon/messaging-app/autopilot-tests/+merge/204947
[14:57] <boiko> robotfuel_: sure, either me or salem_  will review  that
[15:04] <MacSlow> ogra_, the chmod-fix for the usc-wrapper doesn't work for the emulator?!
[15:04] <ogra_> MacSlow, feel free to try
[15:05] <MacSlow> ogra_, well when the emulator is running I get a "read-only filesystem"-error when trying "adb shell touch /userdata/.writable_image"
[15:06] <ogra_> MacSlow, yeah, thats what i suspected
[15:06] <ogra_> MacSlow, image 180 is available now btw ... it has the fix
[15:06] <MacSlow> ogra_, I guess I could only change that without the emulator running... but I don't know if I can mess with the image in that case
[15:06] <MacSlow> ogra_, ok... so just recreate the image then
[15:07] <ogra_> right
[15:07]  * MacSlow crosses fingers
[15:08] <davmor2> pmcgowan: okay weirder I rebooted and now it doesn't happen so I wonder if it is a knock on effect from the call test and the rule just never ends.   I try a call now and see if it happens again
[15:08] <pmcgowan> davmor2, oh that could be if somehow proximity was not turned off on end of call
[15:12] <davmor2> pmcgowan: Nope nothing I can't seem to trigger it again :(  I'll keep an eye out for it anyway and see if I can't reproduce it
[15:13] <pmcgowan> davmor2, ok but that makes sense now, somehow powerd didn't get the call hangup and left sensor on
[15:14] <pmcgowan> davmor2, do you have any crash files from that test?
[15:16] <davmor2> pmcgowan: only crash file I have is _usr_lib_arm-linux-gnueabihf_upstart-app-launch_desktop-hook.32011.crash
[15:16] <pmcgowan> davmor2, ok, guess we just watch for it again
[15:16] <mandel> thostr_, sorry, I had no idea you where in the hangout :-)
[15:17] <mandel> thostr_, so you know what we are doing, et me know when I can give a hand
[15:17] <mandel> agh, wrong channel
[15:23] <ilya> hi
[15:32] <MacSlow> mzanetti, tsdgeos: unity8 trunk (with unity-notifications trunk) runs without failure through all the notification AP-tests on the desktop here.
[15:34] <Yamagata> ng
[15:35] <snwh> is it possible to take a screenshot on the mir-based images on a galaxy nexus (phablet-tools is telling me my device is unsupported)
[15:36] <snwh> phablet-screenshot*
[15:39] <MacSlow> ogra_, ah... I've my emulator back... read: the 180 is working... phew :)
[15:39] <ogra_> :)
[15:40] <MacSlow> ogra_, now I won't touch that setup until April ;)
[15:45] <cwayne> mterry, ping
[15:46] <mterry> cwayne, hello
[15:47] <cwayne> mterry, heya, so now that your unity8 demo-users branch is in the image, i've added a .unity8-greeter(or whatever the filename was) to setup the multi-user greeter demo
[15:47] <mterry> awesome
[15:47] <cwayne> but it's not showing up on the phone as well (i thought it was only meant for tablet)
[15:48] <mterry> cwayne, that file is used on both phone and tablet
[15:48] <jcbjoe> hi all i have a question .. i been reading that all support has stopped and is now for nexus 7 .. i have a nexus 7
[15:48] <jcbjoe> i also have a mac computer
[15:49] <jcbjoe> can i get ubuntu touch on my nexus 7 via this mac ?
[15:51] <pessauro> heu
[15:51] <pessauro> hei
[15:59] <cwayne> mterry, blagh, so ill have to find a way to only apply it to tablets..
[16:01] <frecel__> popey: I have not changed anything in SmartFart so if it doesn't work it's something in the OS
[16:01] <frecel__> popey: also good morning :D
[16:02] <popey> frecel__: I'll do some more testing and check the logs, this is of course my top piority :p
[16:03] <jcbjoe> let me back up
[16:03] <jcbjoe> is the only way to get ubuntu touch to a nexus 7 thru gnu/linux (linux) or can i do it from a mac ?
[16:04] <cwayne> jcbjoe, which nexus 7? (old one or new one)
[16:04] <bfiller> kenvandine: meeting?
[16:04] <jcbjoe> cwayne, 2013
[16:04] <frecel> well you could also make html5 launcher work, unless it already does because the last time I checked was on 170 (i think)
[16:08] <jcbjoe> cwayne, nexus 7 2013
[16:09] <cwayne> jcbjoe, it'll be available to flash soon, but not quite yet via ubuntu-device-flash, which AIUI works on mac
[16:16] <kenvandine> bfiller, oh... i forgot the meeting
[16:16] <kenvandine> bfiller, still having it?
[16:16] <bfiller> kenvandine: lets do a quick sync
[16:16] <pmcgowan> mandel, barry do you have any debug libs to use on the update issue? my tablet currently stuck again
[16:16] <asac> barry: mandel: so do you feel stuck in the upgrade bug?
[16:17] <asac> hehe
[16:17] <kenvandine> bfiller, give me a couple minutes
[16:17] <bfiller> kenvandine: https://plus.google.com/hangouts/_/calendar/cmFjaGVsLmxpdUBjYW5vbmljYWwuY29t.ekpliocgi08ceqi2pch3emv1eg
[16:18] <barry> i'm in a meeting atm, but i will soon have a branch/ppa package that will gather more information.  i was able to reproduce the crash *once* on my device late last night, so that gives me some hope that i can capture it.  we still don't know at what layer the bug/change is though
[16:18] <asac> barry: so its a crash?
[16:19] <barry> asac: i think some downloaded file is getting corrupted, causing the gpg signatures to fail validation.  but it's *very* random and intermittent.  after i got the one error on my device, i ran it maybe 1/2 dozen more times with no errors
[16:20] <asac> barry: can you see how the code is not robust aganist that?
[16:20] <ogra_> asac, it clearly looks like the request to download the blacklist file doesnt reach the download manager
[16:20] <barry> asac: but now i know it can happen on open wifi networks, so likely has nothing to do with 3g or login-protected networks
[16:20] <asac> barry: it can always happen
[16:20] <barry> asac: well, what can it do?  if the signature doesn't match, you can't trust the file
[16:20] <ogra_> barry, u-d-m never downloads it
[16:20] <jcbjoe> cwayne, so i can get parallels or something/ install ubuntu then i can go that route correct ?
[16:20] <ogra_> and it doesnt look like it is asked for that
[16:20] <asac> barry: yes, you have to plan for that... you will always have corruptionm
[16:20] <asac> barry: or failed downloads etc.
[16:21] <asac> barry: so we need to have mechanism to evict stuff that was broken or something
[16:21] <asac> barry: also they say it works with cli?
[16:21] <barry> asac: right.  corrupted stuff does get evicted, so a retry would succeed.  if of course the corruption doesn't happen again
[16:21] <ogra_> barry, see the syslog as well as the new "ubuntu-downaload-manager-log" on the bug
[16:21] <ogra_> the download is never attempted
[16:22] <asac> barry: but is that what people observe?
[16:22] <asac> can they click again and it redownloads etc.?
[16:22] <ogra_> asac, the UI indicates so
[16:23] <barry> asac: sometimes.  for me it does work on subsequent tries.
[16:23] <ogra_> if the background process timed out you can just run the UI again and it seems to start downloading again
[16:23] <asac> pmcgowan: does it redownload/retry after this issue happens for you?
[16:23] <ogra_> yes, he told me about it
[16:23] <ogra_> last night
[16:23] <pmcgowan> asac, depends, when system-image-dbus crashes then you need to restart
[16:24] <asac> so its all about better error reporting so the user knows what to try?
[16:24] <ogra_> asac, well, that wont give you the file
[16:24] <asac> e.g. "the downloaded update wasn't good, please try again after ensuring you have good networking"
[16:24] <asac> ?
[16:24] <ogra_> https://bugs.launchpad.net/ubuntu-system-image/+bug/1277589/+attachment/3979749/+files/ubuntu-download-manager.log20140213-151948.2314
[16:24] <ogra_> grep for blacklist in this file
[16:24] <pmcgowan> asac, I dont think its that simple, my network here is fine and it failed
[16:24] <pmcgowan> something else is going on
[16:25] <pmcgowan> and was at the office and it failed
[16:25] <ogra_> or in this https://bugs.launchpad.net/ubuntu-system-image/+bug/1277589/+attachment/3972761/+files/syslog
[16:25] <barry> here's a mystery: why did we get the first report of this on feb 7 when neither u-d-m nor s-i has changed since december?  maybe nobody saw it until the u/i made it evident the error was happening, but i don't think that's the case.
[16:25] <asac> pmcgowan: yeah. so download can be corrupted by bogus wifi, but also through crashes etc.
[16:25] <ogra_> (both have download manager logs)
[16:25] <asac> imo the update manager should just recover transparently
[16:25] <ogra_> barry, they communicate over dbus
[16:25] <asac> barry: maybe our wifi is more flaky now
[16:25] <asac> or dbus etc.
[16:25] <ogra_> barry, there is polkit involved, logind and dbus itself
[16:26] <barry> asac: right, *and* there was a change to libqt5network5 on feb 6, which is darn suspicious, although the changelog doesn't reveal anything
[16:26] <ogra_> and the request to download blacklist clearly never reaches u-d-m
[16:26] <ogra_> asac, it definitely isnt the wifi
[16:27] <ogra_> it happens on the way from s-i to u-d-m somewhere
[16:27] <barry> ogra_: i hadn't thought about changes to dbus.  do you know when that might have changed on touch?
[16:28] <ogra_> barry, nope, i was looking at the one policykit change yet, but that doesnt seem to have anything that could cause this ... looking at dbus changes was on my list next (got two meetings in a row now)
[16:28] <barry> ogra_: in my test suite on amd64 desktop, i *do* see new and strange dbus behavior.  like s-i not receiving all the expected signals from u-d-m
[16:28] <ogra_> barry, right, so it could happen vice versa
[16:29] <barry> ogra_: so in the test suite, you can get timeout errors because the finish/cancel/error signal from u-d-m never reaches s-i
[16:29] <pmcgowan> dbus did update feb5
[16:29] <barry> so if dbus is somehow dropping messages, that could explain a both symptoms
[16:30] <barry> pmcgowan: https://launchpad.net/ubuntu/+source/dbus says jan 17
[16:30] <barry> but maybe it only landed in touch by feb 5?
[16:30] <pmcgowan> I see libdbus-cpp1:armhf from 1.0.0+14.04.20140123-0ubuntu1 to 1.0.0+14.04.20140123.1-0ubuntu1
[16:30] <pmcgowan> on feb 5
[16:31] <barry> pmcgowan: that is definitely a useful avenue to investigate.  mind if i ask you to follow that lead, while mandel follows the networking change, and i work on the s-i level?
[16:31] <ogra_> pmcgowan, cpp
[16:31] <ogra_> not sure there is muchg using that yet
[16:31] <pmcgowan> right
[16:32] <ogra_> (apart from location service)
[16:32] <barry> well, u-d-m might.  it's qt and c++.  s-i wouldn't, it uses libdbus
[16:33] <ogra_> mandel, ^^^
[16:33] <mandel> barry, ogra_ I'm adding even more logs to get the exact structure sent by s-i
[16:33] <ogra_> does u-d-m use dbus-cpp ?
[16:33] <mandel> ogra_, no, qtdbus, and last time someone touch libdbus in git was 2009
[16:34] <mandel> I already went that far
[16:34] <ogra_> right, but libdbus-cpp is new
[16:34] <mandel> ogra_, and not used by me
[16:34] <ogra_> i wonder if it can cause interference on the bus
[16:35] <mandel> barry, ogra_ give me a few mins and I can build a new ppa with eve more logging jibel you can reproduce it, correct?
[16:35] <barry> mandel, ogra_, jibel i need to dist-upgrade and reboot, but then i will build a ppa package of s-i that you can install to gather more data in the s-i logs
[16:36] <ogra_> great
[16:36] <barry> (i just don't want to upload that yet until i get current on trusty and have a successful unittest suite run)
[16:37]  * barry will hopefully be back in a little bit
[16:51] <jibel> bfiller, FYI I rebased lp:~jibel/address-book-app/abook_delete_contact_pickmode on trunk, renato already reviewed it. Not sure if the bot will re-review it again.
[16:51] <bfiller> jibel: thanks
[17:08] <jibel> renato, boiko , salem_ Hey, when you have time for reviews, there are 3 MPs waiting for you
[17:08] <jibel> https://code.launchpad.net/~allanlesage/address-book-app/abook_navigation_favorites/+merge/205264
[17:08] <jibel> https://code.launchpad.net/~allanlesage/address-book-app/abook_navigation_collapse/+merge/205890
[17:08] <jibel> https://code.launchpad.net/~iahmad/dialer-app/smart-dialing-test/+merge/205706
[17:09] <boiko> jibel: yep, I'm reviewing lots of other MRs today, but I think I can review those tomorrow
[17:09] <boiko> jibel: I mean, the dialer-app one, the addressbook ones are for renato :)
[17:10] <jibel> boiko, sounds good, thanks!
[17:20] <jcbjoe> is anyone using ubuntu touch on a nexus 7 and if so how do you like it .. also are you using it as a daily driver ?
[17:20] <jcbjoe> i read somewhere that all support will be going to the n7 2013 witch i have
[17:20] <jcbjoe> which*
[17:25] <popey> jcbjoe: i have it on a nexus 7 2013 here
[17:27]  * ogra_ likes the new N7 a lot
[17:28] <ogra_> ubuntu touch is super snappy on it
[17:56] <ogra_> barry, soo ...
[17:57] <ogra_> barry, this landed at the same time the issues started http://launchpadlibrarian.net/165161694/ubuntu-system-settings_0.1%2B14.04.20140203-0ubuntu1_0.1%2B14.04.20140206-0ubuntu1.diff.gz
[17:58] <ogra_> barry, do you have an idea of the update notification changes could have any influence on s-i behavior ? i tested with pmcgowan and when he rolled back the packages it worked for him (which could indeed just be coincidence)
[17:59] <barry> ogra_: i don't *think* so since the dbus api hasn't changed, and afaik, the ui isn't doing anything crazy now like canceling or pausing an update in the middle (tho those operations should of course work)
[17:59] <barry> ogra_: unless somehow the ui is messing with u-d-m
[18:00] <ogra_> barry, well, it *must* be one of the packages landed on the 7th
[18:00] <barry> ogra_: yeah, i agree!
[18:00] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/20140207.changes
[18:00] <barry> ogra_: i still want to hear what mandel|afk has to say about libqt5network5
[18:00] <ogra_> barry, that was a day before the 7th
[18:01] <barry> ogra_: but that's a possibility right?  i.e. the landings on the 6th but we didn't notice until the 7th.  or people did notice, but retried enough times to make it succeed until popey's first bug report on the 7th
[18:01] <ogra_> barry, and both first manifestations of the bug that we know about showed on the 7th
[18:01] <ogra_> (popey as well as pmcgowan had it first on the same day)
[18:01] <barry> ogra_: tbh, i'd be suspicious of any change from the 5th to the 7th
[18:02] <ogra_> yeah, probably
[18:02] <ogra_> i find it intresting though that it started to work for pat once he rolled back system-settings
[18:02] <ogra_> but that can indeed be coincidence
[18:02] <ogra_> he is just trying to reproduce the same
[18:03] <barry> that is definitely an interesting data point
[18:03] <barry> that package is "involved" in the upgrade process so it can't be ruled out
[18:03] <ogra_> the bug is so flaky that it is hard to tell if it was the package roll-back, but it smells intresting already :)
[18:03] <barry> indeed ;)
[18:04] <barry> fwiw, my test suite is running and once that's done, i'll ppa a package that folks can try out.  i'll also be trying it on my device.  it won't fix the problem but it should provide better information
[18:04] <ogra_> barry, the thing is though ... you have to make the image writable for installing the debs ...
[18:05] <ogra_> so that might have some influence indeed
[18:05] <barry> ogra_: yeah.  but it's the best we can do to continue debugging it
[18:06] <barry> ogra_: another interesting test, albeit time consuming, is to flash back to older revisions until we find one that doesn't fail.  of course, it's hard to know if that's just luck or not, but still
[18:06] <ogra_> barry, right
[18:06] <ogra_> i dont have a device to reproduce ... else i would have done exactly that during the day
[18:07]  * barry nods
[18:07] <ogra_> (my maguro didnt expose it at all, my mako is my main phone and not for testing (not a company phone) and my flo and manta are on 4.4=
[18:07] <ogra_> )
[18:17] <zhanx> Any tips for compiling for a intel z2560 soc?
[18:18] <frecel> Aaaannnnddddd I just bricked my Nexus 4
[18:19] <popey> you sure?
[18:19] <snwh> is there a way to take a screenshot on one's device?
[18:19] <frecel> well software bricked anyway
[18:19] <frecel> it's getting stucked on the google logo on boot
[18:20] <ogra_> frecel, what did you do to it ?
[18:20] <frecel> I tried to update to 180 and it didn't want to so I forced it through shell :D
[18:20] <barry> ogra_: i flashed my device to r174 and tried to upgrade it and got the error.
[18:20] <popey> snwh: depends which device
[18:20] <frecel> turns out it wasn't a good idea :D
[18:21] <popey> snwh: phablet-screeenshot is in the phablet-tools package and works on nexus 4
[18:21] <ogra_> barry, right, to my knowledge it started between 169 and 170
[18:21] <popey> frecel: force how?
[18:21] <snwh> popey, i have a galaxy nexus
[18:21] <popey> ogra_: does phablet-screenshot work on maguro?
[18:21] <snwh> the phablet screenshot doesn't work with it
[18:21] <popey> oh bummer
[18:21] <barry> ogra_: yep.  so the next step for me will be to reflash to 174, install my new s-i package and see if i can capture enough info
[18:22] <ogra_> snwh, remove /home/phablet/.display-mir ... reboot ... do what you need for the screenshot and take it, touch /home/phablet/.display-mir and reboot
[18:22] <ogra_> popey, it crashes Mir on the PVR driver
[18:22] <ogra_> crap HW ...
[18:23] <snwh> ogra_ will try that, thanks
[18:23] <ogra_> snwh, the android tool should work (i forgot the name)
[18:23] <ogra_> should be somewhere in /system/bin ... (you need to use the full PATH)
[18:23] <snwh> screencap
[18:23] <ogra_> screencap iirc
[18:23] <ogra_> yeah
[18:24] <snwh> i was under the impression that only worked with surfacefllinger
[18:24] <barry> ogra_: here's a thought: did anything in the gpg stack change during the interesting time frame?
[18:24] <ogra_> the steps i gave you above switch you toi surfaceflinger ;)
[18:24] <ogra_> barry, not that i remember, but let me check
[18:24] <snwh> ogra_ ah
[18:25] <ogra_> barry, though i still never see the request to even download the blacklist file arrive in the u-d-m logs
[18:26] <ogra_> barry, last gpg upload was end of last month
[18:27] <ogra_> i think we would heard about issues before the 7th if that would realyl cause anything
[18:27] <ogra_> 28 Jan 2014
[18:27] <barry> ogra_: that's really interesting.  what it looks like from the s-i side is that a blacklist file *did* get downloaded, but it's signature check failed, so s-i then thinks "well, maybe the image-master key is old" since that key has to sign the blacklist.  so then it tries to get a new image master, which appears to succeed, only *its* signature also fails.  there's no place else to go, since the image master has to be signed by the
[18:27] <barry> archive-master, and that's preloaded on the image
[18:27] <zhanx> Any tips for compiling for a intel z2560 soc? Broke my laptop, want to use touch on my tablet
[18:28] <mandel> barry, I'll bevery surprise is the qnetwork change, it changes nothing in th enetwork stack
[18:28] <barry> ogra_: possibly.  that was during the london sprint, but it does seem a little early
[18:28] <barry> mandel: okay, so we don't think that's it
[18:28] <mandel> barry, I have a new build of udm with more logs for you :)
[18:29] <ogra_> barry, http://people.canonical.com/~ogra/touch-image-stats/20140129.changes
[18:29] <barry> mandel: cool.  i am starting to sniff a scent though :)
[18:29] <ogra_> gpgv and gnupg
[18:29] <ogra_> thats the last time they changed
[18:29] <mandel> barry, yep, I saw the backlog :)
[18:29] <barry> ogra_: let me take a peak at the change log.  looks like a new upstream version
[18:29] <ogra_> it is
[18:30] <ogra_> blame mdeslaur if it broke :)
[18:30] <barry> :)
[18:30] <mdeslaur> what?
[18:30] <mdeslaur> what'd I do?
[18:30] <ogra_> mdeslaur, we're trying to find why people cant upgrade anymore
[18:30] <barry> i think i understand how we're getting the traceback now, but not why
[18:31] <ogra_> mdeslaur, but the first reported incident with this error is from the 7th ... i'm pretty sure its not your gpg upload
[18:31] <barry> mdeslaur: so, we're trying to figure out why phone upgrades fail now and then.  my latest thinking is maybe something in the gnupg stack has changed, though it doesn't make sense that signature checks would only fail intermittently
[18:31] <barry> right, it's probably not, but still
[18:31] <mdeslaur> ogra_: thanks for the heart attack :)
[18:32] <mdeslaur> barry: ok, let me know
[18:32] <ogra_> mdeslaur, awake now ? :)
[18:32] <mdeslaur> hehe
[18:32] <barry> gnupg 1.4.16 upstream was apparently released mid december
[18:32] <frecel> I know that I have phablet-tools installed but I get command not found when I'm trying to run ubuntu-device-flash
[18:32] <frecel> strange
[18:32] <ogra_> barry, well, if it would be not properly backwards compatible, the server signs with whatever version it runs ... precise i bet
[18:33] <ogra_> and we use the trusty version to decrypt
[18:33] <ogra_> but i guess there would be tons of other issues if there was any such incompatibility
[18:33] <barry> that's what i'd think.  it smells like we're close but not quite there
[18:33] <ogra_> frecel, ubuntu-device-flash is in a differnt package ... check the install wikipage
[18:33] <mandel> barry, I lied to you, waiting on the armhf build => https://code.launchpad.net/~mandel/+recipe/ubuntu-download-manager-daily
[18:34] <barry> mandel: cool
[18:34] <mandel> barry, but we have labeled lines for download, logs for when downloads are created and tracing of all methods
[18:34] <mandel> barry, we are really going to know what udm is doing
[18:34] <popey> frecel: you on 14.04?
[18:34] <frecel> popey: 13.10
[18:35] <frecel> nvm, ubuntu-device-flash is it's own package
[18:36] <mandel> barry, and auth errors being raised
[18:36] <mandel> barry, I cannot think of any more logging to add
[18:37] <frecel> In my defenese I have a fever so my brain doesn't really work
[18:37] <frecel> I'm going to be doing stupid things today
[18:38] <barry> mandel: the most important things are: can we easily find the relevant log file (more difficult now with google logging naming scheme unfortunately), and can we correlate udm log entries with si log entries
[18:39] <mandel> barry, I have fixed logging files, we can now see the time when the log was created, the logs are labeled with time AND download id so we can trace what happened in each step and we can see the creation method call
[18:40] <barry> mandel: cool.  i'll take a look as soon as possible.
[18:50] <balloons> popey, does loudspeaker work for you on image 180?
[18:50] <jibel> mandel, does it mean you'll have a new build to test soon?
[18:50] <mandel> jibel, yes, waiting on the builder atm
[18:50] <mandel> jibel, https://code.launchpad.net/~mandel/+recipe/ubuntu-download-manager-daily
[18:52] <jibel> mandel, if it's an arm builder, I've enough time to have dinner ;)
[18:52] <jibel> mandel, failed to build on arm BTW
[18:52] <mandel> ahghg
[18:52] <ogra_> Build finished at 20140213-1851
[18:52] <ogra_> FAILED [dpkg-buildpackage died]
[18:52] <popey> balloons: no devices on 180 yet, updating now
[18:53] <balloons> fails for me, see if you can confirm
[18:53] <mandel> jibel, *** quemu => qemu: uncaught target signal 6 (Aborted) - core dumped
[18:53] <ogra_> mandel, use the canonical-arm-dev PPA ... :P
[18:53] <ogra_> mandel,  its a native builder
[18:53] <jibel> mandel, I'll be back later, ping me when there's a deb ready
[18:56] <mandel> jibel, will do
[19:02] <frecel> balloons: the loudspeaker works for me on nexus4 r180
[19:03] <balloons> frecel, when you start a call does it display the icon with an X?
[19:03] <balloons> then pressing the X displays the volume icon? For me tapping the icon simply resets it to an X over and over
[19:04] <popey> balloons: i have audio on 180
[19:04] <popey> in music app
[19:04] <balloons> popey, frecel I'm talking about speaker mode in a phone call
[19:04] <popey> oh
[19:05] <frecel> oh
[19:05] <frecel> let me put a sim card in :D
[19:05] <balloons> lol :-)
[19:05] <popey> yup, works here
[19:06] <balloons> k, see above for what happens on mine. It's a fresh flash.. I flashed the 4.3 radio stock again as well
[19:06] <balloons> I feel like this phone is just unhappy
[19:06] <frecel> works on my phone too
[19:08] <barry> ogra_, mandel we have another clue: http://paste.ubuntu.com/6927127/
[19:09] <barry> note the m5 checksum on keyring.tar.xz{,.asc}!  two problems, they are identical, and they also don't match the blacklist on the server
[19:09] <mandel> barry, that is good, I mean, it is not network related something I was very scared off
[19:09] <ogra_> barry, what about: [systemimage] Feb 13 19:06:14 2014 (2066) No signed blacklist found
[19:11] <balloons> ty frecel and popey
[19:11] <frecel> popey SmartFart works for me just fine in r180
[19:11] <popey> hmm
[19:11] <ogra_> frecel, heh, thats also my preferred test app for click installs
[19:11] <popey> haha
[19:11] <popey> ogra_: its frecel's app ☻
[19:11] <ogra_> annoys the hell out of my GF :)
[19:11] <barry> ogra_, mandel: so.  what happens is this: si requests the blacklist.tar.xz and .asc files from the server as you can see in line 1 and 2, with the local path specified.  once the group download finished (successfully, apparently), it checks the signatures against image-master.  when that fails, you see the "no signed blacklist found" error in line 7, and *then* it prints more details of the error, including exactly what we needed.  the
[19:11] <barry> paths and checksums of all the files involved in the sig check
[19:12] <barry> ogra_, mandel this clearly tells me that blacklist.tar.xz{,.asc} are apparently downloaded successfully, but in reality are corrupt
[19:12] <ogra_> weird
[19:12] <barry> the rest of the cascading errors make perfect sense from there
[19:12] <ogra_> how do you know it is actually downloaded
[19:13] <barry> because the SignatureError details include the local file system path and md5sum of whatever it found at that path
[19:13] <thomi> cyphermox_: robru: could one of you fine gentlemen please run the 'Merge & Clean' job for silo 6?
[19:13] <mandel> barry, so, if we manually download the files, can we see if their signatures match? to ensure that it is no udm doing a bad download
[19:13] <robru> thomi, on it
[19:13] <thomi> robru: thanks, I realised this was the wrong channel after I sent that, sorry
[19:13] <cyphermox_> robru: ok
[19:14] <barry> mandel: sure. you can verify that on a desktop.  wget them and unpack
[19:14] <barry> you see something very similar when it tries to get the new image master:
[19:15] <barry> http://paste.ubuntu.com/6927172/
[19:15] <barry> note the *same* checksums on the signature error
[19:15] <barry> so what the heck is d41d8?
[19:16] <barry> now, the rest makes sense: no valid image master key, so the only thing happening next is the archive master being bad, but we cannot download it.  we've reached the end of the line with nothing more and thus we fail
[19:16] <barry> the ui error is a bit misleading, but ultimately accurate. that can be improved, but it's not the root cause
[19:17] <barry> the root cause is that the files downloaded are somehow corrupt.
[19:17] <barry> next, i'm going to instrument si to preserve the corrupt files so i can try to see what they actually are
[19:17] <barry> (they get deleted when the failure occurs)
[19:18] <mandel> barry, yes, it is interesting to know what they might be.. they prefix in the checksum.. is weird
[19:18] <barry> mandel: at the very least, the fact that the .xz and the .xz.asc are identical is a bad sign
[19:19] <frecel> I noticed that SmartFart doesnt show up when I do click list
[19:19] <mandel> barry, yes, I'm wondering, is udm downloading an error page?
[19:19] <mandel> that would be super weird..
[19:19] <barry> mandel: oh, you're going to love this:
[19:19] <barry> >>> hashlib.md5(b'').hexdigest()
[19:19] <barry> 'd41d8cd98f00b204e9800998ecf8427e'
[19:19] <barry>  
[19:19] <barry> those are the hashes of empty files
[19:19] <mandel> hahahahahahaha
[19:19] <mandel> barry, ok, that explains it
[19:20] <barry> mandel: thought: do you flush your output buffers before returning a successful dbus signal?
[19:20] <mandel> barry, yes, 100% sure
[19:20] <barry> *you or qt5network5
[19:20] <mandel> barry, let me check that part of the code
[19:20]  * pmcgowan watches with much interest
[19:20] <barry> mandel: so that's the question.  why are both files empty?
[19:23] <mandel> ogra_, huge favor, can you look the last time udm was updated?
[19:25] <ogra_> sure
[19:25] <barry> and now of course, the second time around, all the files are fine
[19:25] <barry> time to reflash
[19:26] <ogra_> 19 Dec 2013
[19:26] <ogra_> mandel, ^^^
[19:26] <mandel> ogra_, ok, long enough :)
[19:26] <ogra_> yeah
[19:26] <frecel> why does click list only list core apps?
[19:27] <mandel> ogra_, barry I can see errors when trying to download via udm that file from a desktop => http://paste.ubuntu.com/6927242/
[19:28] <mandel> ogra_, barry and that error, the 203 is QNetworkReply::ContentNotFoundError
[19:28] <ogra_> weird
[19:29] <ogra_> ERROR::203
[19:29] <barry> mandel, ogra_, stgraber: could we possibly be seeing an intermittent server error?
[19:29] <barry> maybe the client is all happy, but the server is misbehaving occasionally?
[19:29] <ogra_> 203 smells a bit like that
[19:29] <barry> maybe stgraber can check the server logs
[19:30] <ogra_> "The server successfully processed the request, but is returning information that may be from another source"
[19:30] <ogra_> is the exact definition of 203
[19:30] <barry> wtf? ;)
[19:30] <stgraber> barry: can't access the logs, sorry
[19:30] <barry> stgraber: who manages those servers? is?
[19:31] <stgraber> yep
[19:31] <ogra_> wget'ing https://system-image.ubuntu.com/gpg/image-master.tar.xz works fine
[19:31] <barry> are we being mitm?
[19:31] <jcbjoe> anyone using  n7 ubuntu touch as a everyday driver ?
[19:32] <mandel> barry, ogra_  no, that is probably my network in that error, I just did a udm download of https://system-image.ubuntu.com/gpg/image-master.tar.xz locally via udm and was ok
[19:32] <ogra_> barry, heh, that would be pointelss at the current state
[19:32] <ogra_> i doubt any hacker would make that effort
[19:33] <barry> ogra_: i've never seen wget failing.  but i wonder if udm/qt5network5 can handle a 203?  it's supposed to be identical to a 200
[19:33] <stgraber> and I'd expect udm to do ssl validation which would happen way before we get a return code
[19:33] <mandel> ogra_, would be lovely
[19:33] <mandel> barry, that 203 is an internal enum from qt, ignore the number
[19:33] <mandel> barry, ogra_ we are dealing with 200 + correctly
[19:33] <barry> mandel: ok ;)
[19:33] <ogra_> phew
[19:33] <stgraber> the problem here is that udm is considering a 2XX code as an error, all 2XX are "succesful"
[19:33] <barry> yeah
[19:33] <mandel> barry, yeah, crap from qt, sorry
[19:34] <mandel> stgraber, nah nah, that is not the issues
[19:34] <stgraber> ok :)
[19:34] <mandel> stgraber, that stdout is from an enum
[19:34] <mandel> they used 203 as a 404 when my network was funny
[19:34] <barry> but now we know that for some reason udm is returning a success signal, but the files on disk are empty
[19:34] <mandel> why, cause they are xx
[19:34] <mandel> barry, correct, and testing in my machine is returning valid files from udm
[19:35] <barry> so i have one more test to run.  i will preserve the corrupt files on error and throw a fatal error right at the first failed validation.  then i can poke around and see what happened
[19:35] <barry> remember too that these are *intermittent* errors
[19:35] <barry> not easily reproduced
[19:35] <mandel> barry, do you have access to a phone
[19:36] <stgraber> anyway, the server isn't clever or anything, it's just a standard apache2 serving static files, so usually those files are there or they're not :)
[19:36] <barry> mandel: no, but i do have a tablet
[19:36] <mandel> barry, ah, could I give you instructions to branch udm and compile it there, the deb build takes for ever and is giving me qemu errors
[19:36] <mandel> ogra_, I have no arm machine to use to build this but in a chroot  :-/
[19:37] <barry> mandel: yeah, i have an armhf chroot, but it's sloooooowwwwww
[19:37] <mandel> barry, but you have a nexus7!
[19:37] <mandel> barry, is a lot faster!!!
[19:37] <ogra_> mandel, the canonical-arm-dev PPA doesnt help ?
[19:37] <barry> nexus 10, and yeah it might be.  i haven't actually tried to build anything on it
[19:37] <ogra_> its is the fastest thing we have
[19:37] <ogra_> (same as the buildds)
[19:39] <mandel> ogra_, so, I have to create a recipe there or dput the deb package?
[19:39] <ogra_> just dput
[19:40] <pmcgowan> mandel, barry looks like good sleuthing, any smoking gun on what may have recently changed in this regard?
[19:40] <ogra_> pmcgowan, libqt5network5
[19:40] <ogra_> changed on the 6th
[19:40] <ogra_> we actually had that on the radar already
[19:41] <pmcgowan> and how did it change? has anyone tracked it  down?
[19:41] <mandel> pmcgowan, I have look at the changelog and there are comments about other parts of qt but not the network
[19:41] <ogra_> stgraber, is there no round-robin or something in front of it ... i.e. like cdimage ?
[19:41] <pmcgowan> I asked Mirv but he must have been off already
[19:42] <ogra_> yeah, late here
[19:42] <pmcgowan> was wondering if any chance the server side changed
[19:42] <mandel> pmcgowan, ogra_ I wouldbe very surprised if it is qt, really I have read the src and looks like no one changed that in a long time
[19:42] <ogra_> IS could tell i guess
[19:42] <stgraber> ogra_: not that I'm aware of, I only push to a single server
[19:42] <ogra_> ok
[19:42] <stgraber> and that's calingi which is the only server returned by system-image.ubuntu.com
[19:43] <ogra_> there were definitely some machine upgrades recently
[19:43] <ogra_> but system-image is so new that i would expect it to be on precise since day one
[19:43] <stgraber> yeah, callingi has always been precise
[19:43] <stgraber> (well, taking IS's word for it, I don't have ssh to that one)
[19:44] <ogra_> probably it has a loose cable
[19:44] <ogra_> *g*
[19:44] <barry> ogra_: :-D
[19:44] <barry> "have you power cycled your modem?"
[19:44] <ogra_> :D
[19:44] <pmcgowan> go to the start button...
[19:45] <pmcgowan> ogra_, I could not reproduce it all day here btw
[19:46] <barry> so far, in 3 tries, i've consistently gotten it right after a flash --bootstrap to r174
[19:46] <ogra_> after the one fix you mean ?
[19:46] <ogra_> barry, try 169 next time
[19:47] <barry> ogra_: okay.  one more test on r174 with some custom packages, and then i'll try that next
[19:47] <mandel> ogra_, barry only thing I can think off http://qt-project.org/doc/qt-5.0/qtnetwork/qnetworkreply.html#downloadProgress is never emitted (I need to check the code) when the download is completed and I must read the reply data on finished
[19:47] <ogra_> would be intresting if 168 exposes it actually
[19:47] <mandel> ogra_, barry could be a problem because in theory if that signal is used there is no need to read all
[19:48] <mandel> the data on finish, sorry
[19:49] <ogra_> hmm, qint64 ...
[19:49] <mandel> ogra_, it can't be that, we are working with tiny files
[19:50] <ogra_> yeah
[19:50] <mandel> that is why, if the fir in a single request with no progress.. but in my machine it works
[19:52] <barry> ogra_, pmcgowan okay, i am noticing something else quite interesting.  it seems like the ui starts a check for an update available when you open system settings, even before you hit the Updates icon.  i can't see how that could affect things, but its unexpected
[19:53] <ogra_> barry, right, i have seen the code for that
[19:53] <pmcgowan> barry, yeah, there actually is a race there, I filed a bug in the UI, it can report software up to date when its not
[19:53] <ogra_> barry, it is actually supposed to show a notification
[19:53] <barry> okay, so that's a known bug, not expected behavior?
[19:53]  * ogra_ has never seen one)
[19:53] <pmcgowan> if you go to updates before it finished the check on the main page, the update page reports the wrong status
[19:54] <ogra_> aha, i see it for the first tome now
[19:54] <ogra_> it actually adds a row at the top of system-settings
[19:54] <pmcgowan> https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1279006
[19:55] <pmcgowan> not sure why its low
[19:55] <ogra_> hmm, tapping it only gets me a spinner
[19:55] <pmcgowan> check your crash dir
[19:55] <mandel> ewewe that bug should be at least medium
[19:55] <pmcgowan> I thought I submitted it as high
[19:56] <pmcgowan> guess they are waiting to triage it
[19:56] <ogra_> system-image-dbus ... as expected
[19:56] <pmcgowan> right
[19:56] <ogra_> and i have one running process
[19:56] <ogra_> damn ... would have been clever to check before tapping the update button
[19:57] <ogra_> i wonder if the "always download on wlan" might probably start a concurring download here
[19:57] <pmcgowan> hmm, thats interesting
[19:57] <ogra_> i have that on on all devices
[19:57] <pmcgowan> I have not seen the problem since I turned that off
[19:58] <ogra_> has it ever worked for you before ?
[19:58] <pmcgowan> yes
[19:58] <mandel> pmcgowan, but, we only have one s-i and one udm, for udm to download two files in parallel is no a problem
[19:58] <ogra_> i have that on on all my devices since forever
[19:58] <ogra_> never had something pre-downloaded
[19:58] <mandel> pmcgowan, ogra_ sorry for my language F*CK
[19:58] <pmcgowan> mandel, ?
[19:58] <ogra_> heh
[19:59] <mandel> pmcgowan, ogra_ follow me here I have an idea
[19:59] <barry> ogra_: as long as you don't check *again* when they do tap Update :)
[20:00] <mandel> pmcgowan, ogra_, barry s-i is the ONLY user of a feature in udm that allows to tell it to download to an specific location, ideally we only have on s-i so there is no issue, but if we have to s-i on is going to step on the other one when trying to write on the same location and udm does nothing to prevent it
[20:00] <mandel> pmcgowan, ogra_, barry the latests intance gets the finished signal and is happy and then the second group download starts and steps on the files making this mess
[20:00] <ogra_> oh !
[20:00] <mandel> we get a bad checksum and we go nuts
[20:01] <stgraber> hmm, two running s-i-dbus would actually explain the symptoms
[20:01] <barry> mandel: you might be on to something
[20:01] <ogra_> yeah
[20:01] <ogra_> that smells about right
[20:01] <barry> would dbus activate two s-i-dbuses at the same time?
[20:01] <stgraber> barry: can we pretty please add a lock, I can't possibly think of a case where we'd want it running twice.
[20:01] <mandel> barry, ogra_, pmcgowan the change in system settings made this happen
[20:01] <Laney> Do you mean that CheckForUpdates actually starts the download in the auto download case?
[20:01] <mandel> barry, it would have one, but you will be dealing with two requests via sbus
[20:02] <ogra_> Laney, it should, no ?
[20:02] <barry> Laney: yes, it does
[20:02] <pmcgowan> ffs
[20:02] <cwayne> mterry, ping
[20:02] <barry> but internally, s-i-dbus has a flag that it sets when checking for updates, so it should not be possible to get one process to check for two updateds at the same time
[20:03] <ogra_> barry, but there are still messages in the dbus queue
[20:03] <mandel> barry, dbus can be evil in this case
[20:03] <barry> ogra_: if the same s-i-dbus process gets a CheckForUpdate while a check is already happening, it just ignores the second one
[20:03] <ogra_> so the s-i -> udm communication goes astray
[20:04] <barry> but that doesn't preclude dbus from activating more than one process (which i thought dbus activation already prevents)
[20:04] <ogra_> oh, look, i just got a "timeout error" inmy update manager
[20:04] <mandel> barry, ogra_ not at the same time, but one after the other very fast and udm stepping on the files
[20:04] <Laney> Not if the name isn't on the bus
[20:04] <ogra_> first time i get an error message at all there
[20:05] <Laney> You should have some single instance stuff, like bail out if you can't own the name
[20:05] <barry> Laney: we can definitely drop a process lock and bail if the lock is acquired (with sufficent timeout for stale locks.  i already have a *very* safe and well tested library for that elsewhere :)
[20:06] <pmcgowan> ogra_, I just turned auto update on wifi back on and reproduced first time
[20:06] <mandel> barry, ogra_ the issues here is, I'm always stepping on the files as a feature for si, I'm going to think a way on at least logging that possible case where I step on a file
[20:07] <ogra_> pmcgowan, awesome !
[20:07] <mterry> cwayne, hi
[20:07] <mandel> pmcgowan, ogra_ barry that is starting to look more and more like the bug..
[20:07] <ogra_> yep
[20:07] <pmcgowan> yep its a race of some sort
[20:07] <barry> yep, and it makes sense to have cropped up around the time of the ui change
[20:07] <ogra_> yeah
[20:08] <mandel> BRAVO!
[20:08] <pmcgowan> so who has the fix?
[20:08] <ogra_> :)
[20:08] <barry> okay, i agree it's entirely plausable.  i'll add the single instance lock and test that here
[20:08] <mandel> pmcgowan, you do, turn it off ;)
[20:08] <mandel> hehehe
[20:08] <pmcgowan> lol
[20:08] <ogra_> :)
[20:08] <Laney> barry: Can't you do it entirely with dbus?
[20:09] <Laney> Request the name and if you fail because it's already owned by another process (s-i-dbus), exit
[20:09] <barry> Laney: possibly.  i have to do some research
[20:09] <mandel> barry, ogra_ I'm going to improve the way udm steps on things.. in the case of si providing the local path, I write in a diff location and then try to step on the old file
[20:09] <Laney> That'd be a pretty standard way of doing it
[20:09] <barry> Laney: cool
[20:09] <ogra_> mandel, ++
[20:09] <barry> mandel: yes, write to a .tmp file and then atomically rename once done
[20:10] <ogra_> asac, FYI ^^^
[20:10] <mandel> barry, ogra_ worst case I step on it will a full entire file :)
[20:10] <Laney> http://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html#the-unique-instance-idiom hahaha
[20:10] <ogra_> seems we got the issue
[20:10] <barry> that way it's impossible for the client to see a partial file
[20:10] <barry> Laney: ha ha #FIXME :)
[20:10] <barry> (follow the link :)
[20:11] <ogra_> that was a very nice two day team effort btw :)
[20:11] <barry> i will utsl
[20:11] <pmcgowan> Laney, is there still a bug in settings that it starts the dowload on the check or did I miss something
[20:11] <barry> ogra_: let's not celebrate yet, but yes, if this turns out to be it, it will be a beautiful example of teamwork!
[20:12] <Laney> pmcgowan: I guess maybe it's intended?
[20:12] <ogra_> yeah
[20:12] <Laney> barry: http://lethalman.blogspot.co.uk/2008/11/single-app-instances-python-and-dbus.html something like this
[20:12] <barry> so i see two action items: 1) barry to add a single instance protection; 2) mandel to download to a temp file and atomically rename
[20:12] <pmcgowan> Laney, I am unclear on the design, auto dowload but only when I go to the update page?
[20:13]  * barry reads
[20:13] <pmcgowan> Laney, there is another symptom I reported in bug #1279006
[20:14] <mandel> barry, yes, sounds good to me, an atomic write in my side should be very helpful, adding a bug to udm
[20:15] <Laney> pmcgowan: I guess that setting means that you get auto downloaded in the background ideally
[20:15] <Laney> So next time you visit system-settings you don't have to wait for the download
[20:15] <asac> ogra_: so whats the exec summary?
[20:15] <pmcgowan> thats what I would think
[20:15] <Laney> But nothing triggers that atm apart from something asking system-image to check for updates
[20:15] <barry> Laney: i think i want to do it a little differently, but that page looks like it has the clue.  i think instead we exit if we can't get the unique name
[20:16] <ogra_> asac, UI change that triggers that the bottom pieces step on each others toes
[20:16] <Laney> barry: yep
[20:16] <barry> awesome
[20:16] <asac> ogra_: hmm. can you rephrase :)?
[20:16] <asac> ogra_: is the bug fixed :)?
[20:16] <Laney> pmcgowan: It's possible there's a bug if the page in system-settings doesn't start the download itself
[20:16] <Laney> if it comes in while it's in progress
[20:16] <pmcgowan> right
[20:17] <Laney> but we can see once this current issue is fixed I guess
[20:17] <pmcgowan> same race different symptom
[20:17] <ogra_> asac, no, but the cause is found
[20:17] <Laney> it's not a race in that case
[20:17] <ogra_> asac,  and there are ideas how to fix it
[20:17] <Laney> just... incorrect assumptions
[20:17] <ogra_> asac, <barry> so i see two action items: 1) barry to add a single instance protection; 2) mandel to download to a temp file and atomically rename
[20:17] <Laney> but we'll see
[20:17] <pmcgowan> Laney, well, its till downloading and has not installed yet, but says system up to date
[20:17] <mandel> #bug 1279965
[20:18] <Laney> ya, but nothing is racing, it's just that the panel can't talk to the backend properly (is my theory)
[20:18] <pmcgowan> Laney, but we really want what you said, find the update and download in the background
[20:18] <Laney> once the dust settles we can see what's left properly
[20:18] <pmcgowan> Laney, I think I wil lbug that feature since Automatic on wifi implies it
[20:18] <Laney> if that is the desired behaviour something will have to trigger s-i to do it
[20:19] <Laney> pmcgowan: okay, I'd file that one against system-image in the first instance
[20:19] <pmcgowan> Laney, but there is no daemon running right?
[20:19] <Laney> don't think so
[20:19] <asac> ogra_: single instance? what instance is that? a process that we spawn?
[20:19] <ogra_> asac,  system-image-dbus
[20:20] <asac> ogra_: ok. so 2. is something very basic and surely should be done if it didnt happen yet
[20:20] <ogra_> right
[20:20] <ogra_> asac, in any case we seem to be un-stuck an know where to go with a fix now
[20:20] <ogra_> *and
[20:21] <asac> in general, i think its key that we dont stop here, but now do the homework required to ensure that users with our devices will never have a broken upgrade
[20:21] <barry> and i will add a bunch of new tests around this very scenario
[20:21] <ogra_> asac, yep we have some planning for an OTA test already
[20:21] <ogra_> asac, i'll write that down tomorrow
[20:21] <asac> guess thats a pretty tough task, but needs doing
[20:21] <asac> barry: thanks for nailing this down!
[20:21] <ogra_> its not that tough
[20:21] <ogra_> we can cheat
[20:21] <Laney> the upgrades themselves were pretty well protected
[20:21] <asac> mandel: you too!
[20:22] <Laney> you got errors instead of trying to upgrade to some broken thing
[20:22] <pmcgowan> the upgrade was not broken, the code to get them was
[20:22] <ogra_> asac, pmcgowan as well, without him rolling back system-settings we wouldnt have had the ise
[20:22] <ogra_> *idea
[20:22] <Laney> the breakage on the other image earlier though, that was an upgrade failure
[20:22] <asac> ogra_: system-settings?
[20:22] <asac> rollback?
[20:22] <barry> and actually, the upgrader was working properly, ensuring that we don't try to apply a corrupted upgrade
[20:22] <ogra_> asac, yes
[20:23] <ogra_> asac, i noticed that system-settings was updated around the time we faced the issue first, pat rolled back the packages and noticed the issue goes away
[20:23] <ogra_> asac, that got us on the right track in the end
[20:23] <mandel> asac, well, regarding 2.. it is a system image update specific feature, udm just steps on files when requested.. and ergo the error, fixing asap )
[20:23] <mandel> :)
[20:24] <ogra_> asac, the bug was always there, but only system-settings changes exposed it
[20:24] <barry> stgraber: we finally have a test case for the ci-train :)
[20:24] <mandel> barry, we should just blame setting for requesting two updates at the same time ;)
[20:24] <ogra_> haha
[20:24] <barry> yeah :)
[20:24] <asac> which component drives this upgrade activity?
[20:24] <barry> system settings starts it off
[20:25] <stgraber> barry: let me know when you have a branch proposed for merge in lp:~ubuntu-managed-branches/ubuntu-system-image/client :)
[20:25] <asac> (wow big lag here - i get lines in bulks)
[20:25] <asac> system settings is UI/qml?
[20:25] <ogra_> yeah
[20:25] <barry> stgraber: will do!
[20:26] <mandel> asac, ogra_ tests in system settings are.. lacking
[20:26] <ogra_> asac, http://launchpadlibrarian.net/165161694/ubuntu-system-settings_0.1%2B14.04.20140203-0ubuntu1_0.1%2B14.04.20140206-0ubuntu1.diff.gz thats the change
[20:26] <ogra_> mandel, they are there but were failing
[20:26] <ogra_> i think that got fixed today
[20:26] <ogra_> (there was a crash for a while that made not all being run=
[20:26] <ogra_> )
[20:27] <asac> barry: what does system settings call to kick this off? do we have an upgrade manager service that then does all the steps?
[20:27] <barry> asac: system-image-dbus
[20:27] <ogra_> mandel, http://ci.ubuntu.com/smokeng/trusty/touch/mako/178:20140213:20140115.1/6562/ubuntu_system_settings/
[20:27] <barry> and it feeds signals to indicate progress
[20:27] <asac> barry: and that calls the download manager?
[20:27] <ogra_> mandel, 49 tests since today
[20:27] <barry> asac: correct
[20:28] <ogra_> mandel, http://ci.ubuntu.com/smokeng/trusty/touch/mako/176:20140212:20140115.1/6550/ubuntu_system_settings/
[20:28] <ogra_> 5 tests yesterday
[20:28] <ogra_> (and a crash)
[20:28] <asac> barry: ok so system-image owns the activity
[20:28] <barry> asac: it's the middle man
[20:28] <mandel> ogra_, it is an improvement
[20:29] <asac> barry: can the UI recover? if i kill and restart it while upgrade is running?
[20:29] <ogra_> yep
[20:29] <ogra_> asac, the UI spins eternally until system-image-dbus retires
[20:29] <barry> asac: yes, it should be able to
[20:29] <ogra_> (atm that is)
[20:29] <asac> try that :0
[20:30] <barry> ogra_: one thing we may want to think about is better detection of error states to have s-i-dbus commit suicide earlier in those cases
[20:30] <asac> if that just shows the nice progress of the still running upgrade etc. it would be cool
[20:30] <asac> hehe
[20:30] <asac> anyway.
[20:30] <ogra_> barry, yeah
[20:30] <asac> dont worry about me for now
[20:31] <asac> lets really set some time aside afterwards to think through what we can do to be really bullet and desaster proof in production
[20:31] <mandel> barry, ogra_ we must find a way to automate this...
[20:31] <ogra_> mandel, we discussed an OTA test for UTAH yesterday
[20:31] <ogra_> mandel, i'll write that down tomorrow and see if i can implement it
[20:32] <barry> ogra_: LP: #1279970
[20:32] <ogra_> perfect !
[20:32] <barry> ogra_: sounds good
[20:32] <mandel> ogra_, barry I'd say, lets fix it first because so far it is a wild guess I made thx to pmcgowan it could be something else :-/
[20:33] <barry> mandel: completely agreed.  let's not break out the champagne yet!
[20:33] <ogra_> mandel, i doubt it ... but yeah, a fix is needed
[20:33]  * ogra_ is pretty convinced we are on the right track 
[20:33]  * pmcgowan is ready to test
[20:33] <asac> pmcgowan: did you find a way to reproduce this reliably?
[20:34] <mandel> pmcgowan, asac lets update the bug letting people know the work around, disable that auto update thing from the ui
[20:34]  * mandel does not know the names of the ui things
[20:35] <asac> mandel: maybe also update the mail list? i think there were a few folks having troubles.
[20:35] <pmcgowan> mandel, yep
[20:35] <pmcgowan> mandel, I can do that if you want
[20:35] <barry> asac: i will update the si bug and send an email to the list
[20:35] <barry> then i'll work on my fix ;)
[20:36] <mandel> pmcgowan, would be very appreciated, you can explain it better
[20:36] <barry> or pmcgowan or ogra_ can email the list if they want
[20:36] <mandel> asac, yes, email to the list is a good idea
[20:36]  * ogra_ happily leaves that to pat ... :)
[20:37] <pmcgowan> hah ok
[20:39] <frecel> popey: I pushed the SmartFart click packaget o my phone and installed it with pkcon and it works
[20:39] <frecel> popey: for the future just assume that my code is flawless and it's your phone that's broken :D
[20:49] <mandel> barry, I'm going to call it an "early" night, do you need me around or should we catch up tomorrow?
[20:50] <barry> mandel: heh, yeah, i was up past midnight last night working on this too.  and if i can drive out of the neighborhood tonight i'm going to my medidation class.  let's catch up tomorrow.  g'night!
[20:51] <mandel> barry, yes, I have been not sleeping much and drinking to much tea to be awake.. and walking to the toilet every 30 mins because of that
[20:51] <barry> mandel: i've been consuming tea at a prodigious rate too, so i feel your pain ;)
[20:52] <mandel> barry, hehehe catch you later then! have a  great evening!
[20:53] <barry> mandel, ogra_, pmcgowan, Laney, asac: here's my thoughts captured in the bug comment: https://bugs.launchpad.net/ubuntu-system-image/+bug/1277589/comments/40
[20:53] <barry> so now i will mostly ignore irc and work on a fix :)
[20:54] <pmcgowan> barry, awesome
[20:57] <omgwtf> got this message INFO:phablet-flash:Once completed the device should reboot into Ubuntu
[20:57] <omgwtf> but the phone doesn't go past the google logo
[20:58] <asac> barry: thanks a lot barry!
[20:59] <omgwtf> phone is a galaxy nexus btw
[20:59] <omgwtf> any ideas?
[21:08] <ogra_> barry, yay
[21:25] <Jumblemuddle> Is it possible to run ubuntu touch on a galaxy s4?
[21:26] <ogra_> !devices| Jumblemuddle
[21:26] <ogra_> check that wikipage ... not sure how well the port is working or maintained though
[21:26] <Jumblemuddle> Well, I guess that's a no.
[21:27] <Jumblemuddle> Thanks
[21:28] <ogra_> well
[21:28] <ogra_> https://wiki.ubuntu.com/Touch/Devices/i9505
[21:28] <ogra_> that seems to be the device page for the S4
[21:29] <Jumblemuddle> Ya only the i9505 though, I got a sph-l720 (Sprint 4core variant)
[21:29] <ogra_> ah
[21:29] <Laney> barry: nice analysis
[21:30] <omgwtf> got this message INFO:phablet-flash:Once completed the device should reboot into Ubuntu but phone is stuck at google logo and after that shuts down, did anyone experienced this ?
[21:36] <ogra_> omgwtf, id the battery charged ?
[21:36] <ogra_> *is
[21:37] <ogra_> all nexus devices bahve pretty weird when on very low battery
[21:41] <omgwtf> yes
[21:41] <omgwtf> it's not fully charge but it has 70%
[21:59] <jdstrand> thomi: hey, bug #1255206 is marked 'Fix Committed'. do we have an eta on when it would be on the images?
[21:59] <thomi> jdstrand: it's in the images already
[21:59] <jdstrand> thomi: I'd like to see syslog output to debug http://ci.ubuntu.com/smokeng/trusty/touch/mako/177:20140212.1:20140115.1/6557/security/
[21:59] <jdstrand> is it?
[21:59] <jdstrand> thomi: am I looking in the wrong place?
[21:59] <thomi> pretty sure
[21:59]  * thomi looks
[22:00] <jdstrand> thomi: can you look at the above url?
[22:00] <thomi> jdstrand: I am... but.. these aren't autopilot tests
[22:00] <thomi> or am I missing something?
[22:00] <jdstrand> that is a good point
[22:00] <jdstrand> no, they aren't
[22:00] <jdstrand> hmm
[22:01] <jdstrand> so, I wonder how I get syslog output in those reports
[22:02] <jdstrand> thomi: fyi, I'm looking at http://ci.ubuntu.com/smokeng/trusty/touch/mako/177:20140212.1:20140115.1/6557/ubuntu_system_settings/, which iirc *is* autopilot, but I don't see syslog there
[22:02] <thomi> jdstrand: dunno, but you could start thinking about producing a subunit result stream as the output format for those tests, at which point it'd be pretty easy to rig up
[22:02] <jdstrand> thomi: you lost me at "producing a subunit result stream" :)
[22:02]  * jdstrand doesn't know what that is
[22:02] <thomi> jdstrand: so.. there's two issues with your last link...
[22:03] <thomi> 1) the dashboard isn't displaying test result details for passed tests, so you'll never see it on a passed test, unless someone fixes that
[22:03] <jdstrand> the 'security' link
[22:03] <jdstrand> ?
[22:03] <thomi> 2) there's a bug where autopilot doesn't have permissions to read /var/log/syslog - I'm following up on this now
[22:03] <thomi> jdstrand: http://ci.ubuntu.com/smokeng/trusty/touch/mako/177:20140212.1:20140115.1/6557/ubuntu_system_settings/
[22:03] <jdstrand> ok
[22:04] <thomi> for autopilot tests
[22:04] <thomi> for problem (1), we ought to have a conversation with the ci folks - this is probably not too hard to fix
[22:04] <thomi> for (2), I'm filing a bug now, will let you know when it's fixed
[22:05] <jdstrand> fyi, I'm not responsible for the tests in ubuntu-system-settings, but was curious if syslog was there, cause if an app wioth autopilot tests fails, we'll want to see if it is because of apparmor
[22:05] <jdstrand> thomi: awesome, thanks!
[22:05] <thomi> jdstrand:  it will be :)
[22:05] <thomi> jdstrand: if you find a failed AP test, you can actually see the empty syslog attachment
[22:06] <thomi> jdstrand: it's empty because we lack the correct permissions to read the log file on the device
[22:06] <jdstrand> oh, ok-- only on failures. cool
[22:07] <jdstrand> ev: hey, so how can I get /var/log/syslog attached to the security tests. eg: http://ci.ubuntu.com/smokeng/trusty/touch/mako/177:20140212.1:20140115.1/6557/security/
[22:07] <jdstrand> ev: these aren't autopilot
[22:07]  * jdstrand wonders if it is in utah
[22:08] <thomi> jdstrand: actually, it seems it is attached some of the time, see: http://ci.ubuntu.com/smokeng/trusty/touch/maguro/180:20140213.2:20140115.1/6577/unity8/767070/
[22:08]  * jdstrand squints
[22:09] <jdstrand> syslog is in there?
[22:09] <thomi> jdstrand: yeah - first attachment
[22:09] <jdstrand> oh, StringException
[22:09] <thomi> I have no idea why it's called StringException - that's really odd
[22:10] <jdstrand> yeah-- I envisioned it would be one of the Artificats down below-- like dbus.log or similar
[22:10] <thomi> jdstrand: that's the plan
[22:10] <jdstrand> ok
[22:10] <thomi> jdstrand: right now, the test attachments are just printed as strings
[22:10] <thomi> jdstrand: we're working with the CI team to show them as links, and do the right thing with the mime typoe
[22:10] <jdstrand> ah
[22:10] <jdstrand> cool
[22:11] <thomi> jdstrand: so we can have video links on test failure pages :)
[22:11] <jdstrand> that sounds fun :)
[22:11] <thomi> indeed
[22:12] <tam> hello
[22:13] <tam> i got stuck on ubuntu-device-flash --channel devel --bootstrap
[22:13] <tam> this command do nothing
[22:14]  * jdstrand looked in ubuntu-test-cases-touch/tests/security, but don't see how to add an artifact. /me waits for ev
[22:15] <jdstrand> I should have probably asked that in #ubuntu-ci-eng