[00:12] <mhall119> jdstrand: what's the command to list available apparmor policies?
[00:13] <jjohansen> mhall119: aa-status will show loaded policy
[00:14] <mhall119> jjohansen: he gave me some long command, using aa-easyprof I think
[00:15] <mhall119> listed the things I could use in the click package security manifest
[00:16] <jjohansen> mhall119: maybe  aa-easyprof --list-templates
[00:16] <mhall119> nope, that's not it either
[00:16] <jjohansen> aa-easyprof --list-policy-groups
[00:16] <mhall119> ah ha, irssi logs FTW
[00:17] <mhall119> aa-easyprof --list-policy-groups --policy-vendor=ubuntu --policy-version=1.0
[00:17] <jjohansen> ouch, that is long :)
[00:17] <mhall119> jjohansen: do you happen to know where click packages install their apparmor profile to?
[00:18] <mhall119> also, the 'audio' policy group should give access to play sound via pulseaudio right?
[00:19] <jjohansen> mhall119: err let me look it up
[00:19] <mhall119> jjohansen: someone in #ubuntu-app-devel made a click app that I'm testing
[00:19] <jjohansen> mhall119: I would think audio should give access to pulse
[00:19] <mhall119> and it's giving Failed to create secure directory (/run/user/32011/pulse): Permission denied
[00:19] <mhall119> PulseAudioService: pa_context_connect() failed
[00:19] <mhall119> Assertion 'c' failed at pulse/context.c:964, function pa_context_get_state(). Aborting
[00:20] <mhall119> also shm_open() failed: Permission denied but I don't know if that's pulse or u1db (which also seems to be an issue with apparmor)
[00:20] <jjohansen> mhall119: oh, that is a bug in the underlying policy, that got introduced by a change in the last kernel upload
[00:20] <mhall119> okay...so wait for a fix?
[00:21] <jjohansen> mhall119: I thought we had a fix for it out for it already, so yeah
[00:21] <jjohansen> if its not there it should be soon
[00:21] <mhall119> jjohansen: do you know if there's been any specific apparmor work to support u1db?
[00:21] <dgalg> mhall119: hi
[00:21] <mhall119> dgalg: so jjohansen says the pulseaudio errors are due to a change in the kernel, and will be fixed without you having to do anything
[00:22] <jjohansen> mhall119: no I don't
[00:22] <mhall119> dgalg: so we just need to figure out how to make U1DB work properly
[00:23] <mhall119> kalikiana was the lead developer on u1db-qt, but it's very late in the evening for him, I'll ping him tomorrow
[00:23] <robotdevil> galaxy 4,7,10 are the only supported devices?
[00:23] <robotdevil> oh and nexus
[00:24] <dgalg> mhall119: ok. I think you are right, that LocalStorage does it for you by automatically using the correct folder but U1DB doesn't, so if you pass U1db.Database { path: "mydb.u1db" } then it should be opening that in some path elsewhere, but it isn't and is just resolving the path relative to the current directory
[00:24] <mhall119> those are all nexuses not galaxies
[00:24] <mhall119> dgalg: ok, so then that's a bug that needs to get fixed
[00:24] <dgalg> mhall119: I am guessing here though but what you suggest sounds plausible to me
[00:25] <mhall119> dgalg: can you file a bug on https://launchpad.net/u1db-qt
[00:25] <mhall119> jjohansen: does the default click package security profile give access to ~/.config/<appname>/?
[00:26] <jjohansen> sbeattie: ^
[00:26] <tyhicks> it does
[00:26] <robotdevil> mybad, meant galaxy nexus
[00:26] <tyhicks> see /usr/share/apparmor/easyprof/templates/ubuntu/1.0/ubuntu-sdk
[00:26] <tyhicks> it includes these rules:
[00:26] <tyhicks>   owner @{HOME}/.config/@{APP_PKGNAME}/                 rw,      # XDG_CONFIG_HOME
[00:26] <tyhicks>   owner @{HOME}/.config/@{APP_PKGNAME}/**               mrwkl,
[00:27] <tyhicks> mhall119: ^
[00:27] <mhall119> dgalg: ok, so then we should ask that u1db use that as the default location unless an a path is used
[00:27] <mhall119> thanks tyhicks
[00:27] <mhall119> tyhicks: and do you happen to know if that's the full click package name?
[00:27] <mhall119> com.ubuntu.developer.mhall119.{APP_NAME)
[00:28] <tyhicks> mhall119: I believe so
[00:28] <tyhicks> mhall119: According to https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest
[00:28] <tyhicks> mhall119: "APP_PKGNAME - set to name from the toplevel click manifest (eg, "APP_PKGNAME": "com.ubuntu.developer.username.myapp") "
[00:28] <robotdevil> I see there are some boasts of touch on the htc one x, wonder how true, how well it works, and if possible on one s
[00:28] <dgalg> https://bugs.launchpad.net/u1db-qt/+bug/1220481 is filed
[00:29] <mhall119> thanks dgalg
[00:29] <mhall119> !devices | robotdevil
[00:29] <mhall119> thanks tyhicks
[00:29] <tyhicks> np
[01:13] <AskUbuntu> Installing Ubuntu touch on samsung galaxy tab 2 p3100 | http://askubuntu.com/q/341081
[02:00] <RobbyF> not very busy in here tonight.
[02:04] <mhall119> RobbyF: http://ubuntuone.com/3TSyMF8OtWrzqBJ0H5zQZI
[02:08] <RobbyF> it's good to go?
[02:08] <mhall119> RobbyF: works for me
[02:09] <RobbyF> coolio whats ur email for the prize
[02:10] <mhall119> don't worry about it :)
[02:10] <RobbyF> k, now how do install it -
[02:11] <mhall119> well I'm submitting it to the click app store as we speak
[02:11] <RobbyF> ok, even better
[02:11] <mhall119> but you can copy it onto a device to install it from the commandline
[02:11] <RobbyF> those go instant?
[02:12] <mhall119> no, it'll need to be reviewed and approved
[02:12] <mhall119> installing from the commandline works instantly though
[02:20] <RobbyF> terminal is really coming along. I have no complaints with it any more
[02:21] <mhall119> RobbyF: these instructions should work for you: http://paste.ubuntu.com/6061106/
[02:24] <RobbyF> some errors on the register
[02:24] <mhall119> paste em?
[02:25] <RobbyF> http://paste.ubuntu.com/6061114/
[02:25] <mhall119> no sudo on register
[02:25] <mhall119> register adds it to the user's apps list
[02:26] <RobbyF> same error
[02:26] <mhall119> RobbyF: don't page the file name on register
[02:26] <mhall119> register takes the app name, a space, then the version
[02:27] <mhall119> don't *paste*, not page
[02:31] <mhall119> RobbyF: did it work?
[02:31] <RobbyF> yup
[02:31] <mhall119> \o/
[02:32] <RobbyF> testing gmail/gplus app with same login
[02:38] <RobbyF> works pretty nice. I assume as browser improves web apps will along with it without modification?
[02:40] <RobbyF> bed time
[02:41] <mhall119> yup
[03:07] <achiang> rsalveti: hey, you still around?
[03:10] <achiang> rsalveti: nm
[07:09] <dholbach> good morning
[07:29] <DJJeff> I got a LG nexus 4 yesterday im really excited and cant wait to try out ubuntu touch on it
[07:30] <DJJeff> I'd be curious if the wireless on the LG nexus 4 can support monitor mode and maybe even packet injection
[07:30] <DJJeff> nom nom nom nom
[07:32] <DJJeff> oh my there is a XDA thread on this too http://forum.xda-developers.com/showthread.php?t=2014078&page=2
[07:37] <DJJeff> looks like if someone modify this https://github.com/KrasnikovEugene/wcn36xx its possible for monitor mode
[07:53] <dholbach> can I get the click scope to work using the unity8 package running on the desktop?
[07:56] <lool> asac: Did you see the psas rate for mako?  :-)
[07:57] <lool> dholbach: nerver tried with unity 8 / scope, but I did install clicks here  :-)
[07:57] <asac> lool: on touch_ro?
[07:57] <lool> asac: what else!
[07:57] <dholbach> lool, right :)
[07:57] <asac> lool: yeah looks good so far :)
[07:58] <asac> bad news is that all tests, always start flawless
[07:58] <asac> aqnd then the bad stuff comes :)
[07:58] <asac> hwehe
[07:58] <lool> dholbach: the scope will pull in download manager, all arch=indep stuff; the main problem is with arch-specific clicks
[07:58] <dholbach> right
[07:59] <lool> asac: I say we announce it while it's green
[08:23] <tiagoscd> morning folks! I would like to know where can I report a bug in battery indicator on ubuntu touch?
[08:24] <OrokuSaki_> Morning =)
[08:27] <Nick> morning
[08:28] <greyback> tiagoscd: I think this is the place: https://bugs.launchpad.net/indicator-power
[08:32] <OrokuSaki_> When we compile, are we compiling in userdebug or release??? Seems it is userdebug.. is that.. slower?
[08:35] <OrokuSaki> http://pastebin.com/MNynDdmN How I got the camera-app to rotate my camera sensor 90 degrees in landscape mode.. I didn't know we could just edit the qml files without recompiling.. That is neat
[08:36] <OrokuSaki> Told the terminal app not to run in a sidestage (annoying) and told it not to have automatic orientation
[08:36] <OrokuSaki> Seems the keyboard does strange things in portrait mode on my 10" tablet with automatic orientation
[08:52] <JamesTait> Good morning all, happy Paperboy Day! :-D
[08:54] <psivaa> asac: ogra_ : we will not be able get the smoke tests running for a while. The jenkins server is inaccessible and needs either rfowler or retoaded to come online
[08:55] <ogra_> hmm, k
[08:58] <asac> psivaa: hmmm
[08:58] <asac> psivaa: can you send an email to them with me CC?
[08:58] <asac> about this?
[08:59] <asac> i want to follow up and ask how we can ensure we dont need to wait for them in the future
[08:59] <psivaa> asac: jibel is doing that
[08:59] <asac> psivaa: the email?
[08:59] <asac> or rebooting?
[08:59] <asac> L:)]\
[08:59] <jibel> asac, I'm sending a notification to inform people that the VPN end point is dead, hence all services hosted behind it are unreachavble
[09:00] <jibel> asac, I cannot reboot since there is no VPN
[09:00] <asac> jibel: ic.. thanks!
[09:05] <asac> jibel: i was able to connect to my qalab vpn :)
[09:22] <churgyi> hi
[09:22] <churgyi> somebody speak french?
[09:23] <churgyi> i can't update my phone
[09:24] <churgyi> i deploy ubuntu touch 08/28
[09:25] <churgyi> it's here for help?
[09:25] <churgyi> or questions?
[09:27] <dholbach> tvoss_, lool, or anyone else: are we going to make the u1db extension part of the platform?
[09:28] <dholbach> reason I'm asking is, there's an app in the review queue which makes use of it
[09:28] <cjwatson> we already did ...
[09:29] <cjwatson> https://code.launchpad.net/~mhall119/ubuntu-seeds/add-u1db-to-touch/+merge/183784
[09:29] <dholbach> thanks
[10:02] <davmor2> Morning all
[10:12] <OrokuSaki> Morning... anyone know of any good simple apps\games to install?
[10:13] <OrokuSaki> I remember a blackjack game....
[10:25] <AskUbuntu> Ubuntu Mobile OS | http://askubuntu.com/q/341202
[10:28] <hourd> Really tempted to buy a second nexus 4 to use for ubuntu touch
[10:38] <nerochiaro> rachelliu: hi Rachel, one quick question, do you know who's the designer responsible for the dialer, messaging and contacts apps ?
[10:39] <cjwatson> I've apparently broken something and can't boot (Nexus 7).  I can get to recovery mode but don't see anything useful in /proc/last_kmsg.  How do I modify the boot command line from recovery mode?
[10:40] <ogra_> chroot ?
[10:40] <cjwatson> Can't chroot into the system image from recovery mode, apparently.
[10:40] <ogra_> (bind mount /dev before ... and you might need to copy a shell into /system/bin/)
[10:40] <ogra_> (inside /daa/ubuntu that is)
[10:40] <cjwatson> Ah, maybe that would do it ...
[10:41] <cjwatson> And then abootimg from in there?
[10:41] <ogra_> yeah
[10:41] <ogra_> for /dev/disk/by-partlabel/boot
[10:41] <cjwatson> ~ # cp -a /sbin/busybox /system/bin/busybox
[10:41] <cjwatson> ~ # chroot /system /bin/busybox
[10:41] <cjwatson> chroot: can't execute '/bin/busybox': No such file or directory
[10:41] <cjwatson> (/system loop-mounted from /data/system.img)
[10:42] <cjwatson> Also the /dev in recovery mode doesn't have /dev/disk/
[10:43] <ogra_> oh, indeed
[10:43] <ogra_> its not udev
[10:43] <ogra_> well, what i meant above was cp /data/ubuntu/bin/sh /data/ubuntu/system/bin
[10:43] <ogra_> and then just chroot ...
[10:43] <cjwatson> No /data/ubuntu/
[10:43] <ogra_> oh ?
[10:43] <ogra_> ah, you use a system image ?
[10:43] <cjwatson> system image, if that helps
[10:44] <ogra_> yeah, i havent much experience with that yet unfortunately ...
[10:44] <ogra_> i guess we should consider shipping abootimg in recovery :)
[10:45] <ogra_> since setting up the loop mouonts manually might be hard
[10:46] <ogra_> cjwatson, dd the boot.img out of the boot partition, use adb pull/push and edit it on a desktop
[10:46] <ogra_> (then dd it back)
[10:46] <cjwatson> ok, how do I discover which one is the boot partition?
[10:46] <ogra_> find /dev -name *boot*
[10:46] <cjwatson> I vaguely recall doing this before but ages ago :(
[10:46] <ogra_> i'd guess
[10:47] <cjwatson> there's /dev/block/mmcblk0boot0 and /dev/block/mmcblk0boot1
[10:47] <ogra_> the label is there, just in a different path
[10:47] <cjwatson> nothing that's obviously a label
[10:47] <ogra_> hmm, no, it should be deeper down
[10:47] <ogra_> oh, wait, N7 you said
[10:47] <ogra_> LNX is the label then
[10:47] <cjwatson> aha, /dev/block/platform/sdhci-tegra.3/by-name/LNX
[10:47] <ogra_> yeah, tegra differs
[10:52] <cjwatson> ogra_: thanks, that's got me moving ahead a bit more at least
[10:52] <ogra_> great
[10:53] <ogra_> btw, initramfs-tools-ubuntu-touch ships the (undocumented) append-cmdline-arg and remove-cmdline-arg scripts that make changing the cmdline easy from the running system (would indeed not have heloped from recovery)
[11:03] <cjwatson> hmm, this is very weird, once it mounts virtual filesystems a load of upstart jobs seem to enter starting/running state and never leave, including ones that should execute more or less immediately
[11:04] <cjwatson> http://paste.ubuntu.com/6062218/
[11:04] <cjwatson> this is a system image which I then remounted read/write and installed a new test version of click on
[11:05] <OrokuSaki_> Seems I figured out why my touchpad feels slow.... udev is taking up almost all my cpu usage... cannot seem to find out why.. ran top, then ran udevadm monitor.. only thing that happens is my battery events.. seems normal
[11:05] <OrokuSaki_> Is this... normal?
[11:05] <OrokuSaki_> I have no other device to compare with..
[11:06] <OrokuSaki_> can you guys run adb shell and then top and tell me how much cpu usage your udev is taking?
[11:06] <cjwatson> ogra_: is it possible that adbd might be able to start on virtual-filesystems instead?  (not necessarily asking for a change of default, just whether it would work at all)
[11:06] <cjwatson> it might make it easier to see what's going on ...
[11:07] <ogra_> cjwatson, hmm, we need /sbin/adbd available and /sys mounted, i'm not sure what it implies for the getprop calls that rsalveti added to the adbd upstart job if you start it that early
[11:08] <cjwatson> virtual-filesystems => /sys is mounted
[11:08] <ogra_> yeah
[11:08] <OrokuSaki_> @ogra what do you think about cpu usage and udev? =)
[11:08] <ogra_> oh, /usr/sbin/adbd actually
[11:08]  * cjwatson tries it
[11:08] <ogra_> OrokuSaki_, udev is good for managing devices ... CPUs are used ... :P
[11:09] <ogra_> can you be a bit more specific ?
[11:09] <OrokuSaki_> I ran ps -ef and noticed /system/lib/udev --daemon is taking up around 86%
[11:09] <ogra_> huh ?
[11:09] <cjwatson> ogra_: oh.  hmm.  I seem to have no adbd in /system/usr/*bin/, but adb normally works ...
[11:09] <OrokuSaki_> screenshot hang on
[11:09] <ogra_> what would udev do in /system/lib ?
[11:10] <cjwatson> that's peculiar, the dpkg database thinks it's there
[11:10] <ogra_> yeah, android-tools-adbd should put it there
[11:11]  * ogra_ finds it massively distrurbing that stgraber chose /system for the ubuntu part in system images .... since usually android uses that dir 
[11:12] <ogra_> cjwatson, looking at all these jobs in starting state in your log, none of them is used, i wonder if we should just override them
[11:13] <OrokuSaki_> @ogra screenshot http://s9.postimg.org/pnwiuqgzz/screenshot.png
[11:13] <ogra_> (mountnfs and console-setup are pretty moot ... )
[11:14] <cjwatson> ogra_: well, maybe, but I think that's a side issue
[11:14] <ogra_> OrokuSaki_, aha, thats not /system/lib/udev :)
[11:14] <OrokuSaki_> What is that? =)
[11:14] <ogra_> thats udev
[11:14] <OrokuSaki_> Is it normal?
[11:14] <ogra_> it tries to process kernel uevents for your devices
[11:14] <cjwatson> tempted to just give up, reflash, try again
[11:14] <ogra_> no, thats not normal, check your udev rule for your device i'd say
[11:15] <nze> hey guys! the question's probably come up before, but I only found old news, so...
[11:15] <nze> how open/hackable would you say is the HTC One? any chances I'll be able to run ubuntu (or firefox OS) on it?
[11:15] <OrokuSaki_> Sweet... thanks man.. I have gone over it.. I can't seem to find anything out of the ordinary.. but.. I will look
[11:15] <ogra_> also make sure your android side was recently rebuilt, we had some fixes to ueventd that might influence udev behavior
[11:15] <nze> (also, how do the galaxy s4 and the nexus4 compare in that regard?)
[11:15] <OrokuSaki_> Hmmm sweet.. thanks!
[11:16] <ogra_> asac, bah, 0904 is totally borked thanks to jenkins beiing down (teh android zip only contains the kernel, not the android container rootfs)
[11:16] <nze> the info on the wiki is rather sparse…
[11:17] <ogra_> nze, well, we only fully support the nexus devices (with focus on the phones  for 13.10)
[11:17] <ogra_> if you want to use ubuntu touch on any other device it depends how actiuve the community person maintaining the port is
[11:17] <ogra_> !devices
[11:18] <OrokuSaki_> Need to update the touchpad info soon as I get udev fixed. =)
[11:18] <ogra_> we have a list of  comkunity supported devices on that wikipage ^^^
[11:18] <nze> ogra_: that's what I gathered. I was hoping the community person was maybe here on freenode, or someone who could comment
[11:19] <nze> well my guess was that the htc one being a pretty popular device there'd be a rather strong community backing
[11:19] <ogra_> nze, if you click on the specific device entry it should take you to the actual device page, there you should be able to get to the porters launchpad page ... on which you have a "contact this person" button to mail her/him
[11:20] <nze> but the missing piece is: is the One even open enough to make it possible?
[11:20] <nze> ogra_: I'll do that, thanks!
[11:20] <ogra_> also note most ports are maintained by people that are more active on the xda developers forum ... that might also be a valuable source of info
[11:20] <asac> ogra_: well, i am blind, so i am not really worried that the build that i cant see is broken :)
[11:21] <ogra_> asac, heh
[11:22] <asac> ogra_: lets kick start the infrastructure once the lab is online
[11:22] <ogra_> asac, well, i am, since it is my fault ... i need to do that cdimage implementation to use the android package completely for all img files .... its a matter of luck that the android build comes through the same gateway so both, dashboard and android build are always broken at the same time
[11:22] <asac> sil2100: Mirv: whats the fallout from this on your side?
[11:22] <asac> sil2100: Mirv: do we need a manually re-kick of stuff when things come back?\
[11:23] <sil2100> asac: what do you have in mind?
[11:23] <asac> sil2100: is daily-release impacted by the lab outage?
[11:23] <sil2100> asac: are you talking about the QA jenkins lab down?
[11:23] <asac> i think everything running in the qa lab is not accessible
[11:24] <sil2100> asac: yes... depends on when the lab gets back up, but right now everything is stalled, as all our machinery was in that place
[11:24] <asac> right
[11:24] <asac> sil2100: so what are we doing once the thing comes back online?
[11:24] <asac> sil2100: will it just do the right thing? :)
[11:24] <sil2100> asac: if it's back around one of our ticks, we'll just make it work automatically - if it appears in-between ticks, we'll run things manually
[11:25] <asac> sil2100: okay
[11:25] <asac> sil2100: what about merge proposals? will the bot pick stuff up?
[11:25] <asac> or do we need to replay something there?
[11:25] <sil2100> asac: I had a chat with Francis about that once, and the bot will pick it up automatically
[11:25] <asac> good
[11:25] <sil2100> But it will take a while since the queue will be stuffed
[11:26] <asac> sil2100: so we basically missed a tick? thats all in best case?
[11:26] <asac> sil2100: sure that jenkins is not in a very weird state with all the problems pulling stuff from network :)?
[11:26]  * asac guesses that it at least requires a fresh restart
[11:26] <asac> heh
[11:26] <cjwatson> Argh.  Um - does anyone know how to reflash ubuntu-system images by hand from recovery mode?  https://wiki.ubuntu.com/Touch/Install seems rather cdimage-touch-ish.
[11:26] <asac> sil2100: maybe we should set the system in manual mode for sure
[11:26] <asac> sil2100: and wait until the MP queue has cleared a bit?
[11:26] <sil2100> asac: we had a few outages like that in the past and nothing appeared in a broken state afterwards, so we should be safe
[11:26] <asac> sil2100: and then manually handhold every stack once into the image?
[11:28] <asac> just wonder how we can get asap to the best and latest image possible
[11:28] <asac> ogra_: so do we need to restart that android thing?
[11:28] <asac> ogra_: didnt cdimage just reuse the last android artifact?
[11:28]  * asac thought it would do that
[11:28] <ogra_> asac, we should do an image rebuild immediately
[11:29] <asac> ogra_: so you want us to turn of stack publishing, build 1 image first
[11:29] <asac> to hit a safe starting point
[11:29] <ogra_> asac, cdimage assembles the zip from jenkins parts and parts from the android package atm ... if it cant download the jenkins parts it doesnt fail but only dumps the packaged bits into the zip
[11:29] <asac> and then turn daily-release on again?
[11:29] <asac> ogra_: interesting
[11:29] <asac> doesnt fail?
[11:29] <asac> wow
[11:30] <ogra_> asac, i dont care about daily-release ...
[11:30] <asac> feels like a bug
[11:30] <ogra_> it is
[11:30] <asac> ogra_: shouldnt we just use set -e ?
[11:30] <asac> :)
[11:30] <cjwatson> I think that's my mistake
[11:30] <ogra_> cjwatson, using -b -d grouper with phablet-flash might help
[11:30] <asac> hehe. well, guess doesnt really matter much in pratice for today
[11:31] <cjwatson> osextras.fetch returns True/False for historical reasons and I forgot to handle it in the android code
[11:31] <ogra_> that should re-bootstrap from scratch
[11:31] <asac> ogra_: so when can we switch to the android code?
[11:31] <asac> err packaged android bits
[11:31] <ogra_> cjwatson, not sure it is worth to fix it, i plan to overcome my cdimage code fear today and to implement the usage of the ackaged bits (and drop all jenkins downloading)
[11:31] <cjwatson> it is worth fixing it
[11:31] <cjwatson> in general
[11:31] <ogra_> *packaged
[11:31]  * asac is slightly scared that we have those two worlds unconsolidated
[11:31] <ogra_> ok
[11:32] <cjwatson> because osextras.fetch is used elsewhere and this is bad design on my part
[11:32] <cjwatson> I should make it just raise an exception when a download fails, and catch it where it's safe to ignore
[11:32] <ogra_> asac, i'm working on it today, should be fixed before end of the week i hope
[11:33] <ogra_> asac, its long on my todo, but its a big change to the build system that has to land altogether
[11:36] <cjwatson> ogra_: thanks, -d grouper did it (omitting -b because ubuntu-system doesn't support that one)
[11:36] <ogra_> ah, k
[11:37] <cjwatson> asac: I think it's better to fail than to reuse the previous version, FWIW
[11:37] <ogra_> yeah
[11:38] <Mirv> asac: my only addition is that it's useful for the vanguard to watch closely the stacks building/checking so that there are no stalls, in order to get most rebuilded on time
[11:39] <Mirv> currently bug #1219636 affects things so that the daily release manager needs to be a bit vigilant in order to catch things on time so that the tick is not wasted
[11:41] <cwayne_> zsombi, ping
[11:41] <asac> cjwatson: i agree that if bits that should be there are not there, we should fail :)
[11:42] <asac> Mirv: sil2100: so i wanted to discuss the idea of running everything in manual mode all the time for a while
[11:42] <asac> Mirv: sil2100: basically using our daily-release and image production tools to accurately put the image together
[11:42] <asac> like a stack rotation with each stack tick getting an image and gets tested before we release the next stack
[11:43] <nerochiaro> asac: i got disconnected and missed the answer to your question about CI jobs. do we need to re-kick them somehow ?
[11:43] <cjwatson> asac,ogra_: Fixed: http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1336
[11:43] <nerochiaro> asac: i mean, CI jobs on merge proposals
[11:43] <asac> cjwatson: nicey!
[11:43] <asac> nerochiaro: i was told that our bot will pick stuff up
[11:44] <nerochiaro> asac: thanks
[11:44] <asac> nerochiaro: just has a big backlog. if you wait for something badly let me know
[11:44] <nerochiaro> asac: nothing that can't wait a few more hours
[11:47] <cwayne_> bzoltan, does gallery-app have auto-landing? or would i need to push a merge manually
[11:47] <bzoltan> cwayne_: I do not know
[11:49] <muzzol> is there a way to emulate touch with virtualbox or similar?
[11:49] <ogra_> nope
[11:49] <ogra_> you can run the apps in the ubuntu-sdk shell, but we dont have a full system emulation
[11:50] <muzzol> ogra_: so if i don't own any supported device i can't test it?
[11:50] <ogra_> you can develop and test apps, but there is no working emulator yet
[11:50] <muzzol> ok, thx for quick response ogra_ :)
[11:50] <ogra_> so yes, you need a device atm
[11:51] <muzzol> i'll try to get a nexus 4 then
[11:59] <sil2100> asac: has this been discussed with management?
[11:59] <asac> sil2100: what?
[11:59] <sil2100> asac: since we anyway wanted to switch some of the stacks to manual mode, but we didn't want to slow down the touch development/release process
[11:59] <asac> sil2100: its an idea and i am asking what you think :)
[11:59] <sil2100> asac: the 'switching to manual mode' ;)
[12:00] <asac> sil2100: well, i am leading the effort on how we do this stuff
[12:00] <asac> so i am exploring options how to diligently get in charge
[12:00] <asac> and the idea of putting stuff together very accurately and manually
[12:00] <asac> has come up in mangaement :)
[12:00] <asac> yes
[12:01] <asac> sil2100: the challenge is really to find a way to be able to do that in a decent pace
[12:01] <sil2100> asac: I'm always worried about switching everything to manual mode, since this would implicate that someone with proper rights needs to be around all the time to pull the release switch every time
[12:01] <sil2100> asac: it's not something bad, since we're anyway covering most of the ticks
[12:01] <ogra_> so we need to raise the staffing rate :)
[12:01] <asac> right. so what i see is that we handhold this stuff anyway
[12:01] <asac> constantly :)
[12:01] <asac> and whenever we just keep stuff running and dont care
[12:02] <sil2100> asac: but I'm worried that sometimes we might be busy with doing some other stuff and miss some releases that people find urgent
[12:02] <asac> it will not be a good result ... e.g. we basically open the floodgates
[12:02] <asac> so the question is: how can we be smart and organize our workflow that we get back in control
[12:02] <ogra_> did you consider involving more community persons ?
[12:02] <asac> at all times, but still have good throughput
[12:02] <asac> ogra_: at this point no :)
[12:02] <asac> later yes
[12:02] <asac> or ... depends
[12:03] <ogra_> all i see is a staffing problem to cover all timezones
[12:03] <asac> ogra_: well, we can also just grow the people with powers insight our team
[12:03] <sil2100> asac, ogra_: I was asking about management discussion, because I want to know if the upstream guys and managment would be fine with things landing slower than they are already
[12:03] <ogra_> asac, inside an already overworked team ...
[12:03] <asac> sil2100: if it makes sense and we have a sane story, folks will agree :)
[12:03] <sil2100> Since all this daily-release and auto-publishing is for upstreams to be able to see things landed faster
[12:03] <asac> so lets work on that story.
[12:04] <asac> sil2100: i am not sure if thats the only reason for that :)
[12:04] <ogra_> sil2100, right, and the solution to the slowdown would be to involve the community into it and find volunteers
[12:04] <asac> sil2100: we want to land as fast as possible while being in control in the sense that we can ensure a constant quality level
[12:04] <asac> on our images
[12:04] <ogra_> so the staffing isnt an issue anymore
[12:05] <asac> ogra_: we have enough folks in th CI team if we can make the interfaces/control mechanisms easy enough
[12:05] <asac> to use
[12:05] <asac> and if thats not enough we can surely involve more community etc.
[12:05] <sil2100> ogra_: right, but I guess this also bares a lot of responsibility, as even we're not allowed to publish everything by ourselves - even we have to ask core-devs for ACKs whenever there's a packaging change
[12:05] <ogra_> if it is easy and safe to use, trusted people from the community should be able to click a button too ;)
[12:06] <asac> right. i agree. but lets first make it so easy and use our internal folks for that experiment :)
[12:06] <ogra_> sil2100, being allowed to upload to the archive (and having root on millions of PCs due to that) is about the same amount of responsibility imho
[12:07] <asac> sil2100: so maybe think how we could manually get the throughput needed _during_ your worktime
[12:07] <ogra_> we should open CI to core-dev or even all ubuntu-developers at some point
[12:07] <asac> sil2100: if its just a matter of finding someone outside of your business hours, thats a good problem to have
[12:07] <asac> sil2100: throughput needed means: minimize time for landings that dont break tests
[12:08] <sil2100> I'm wondering, I guess that we could manage to do things in the state we have now, I always try to assume the worst-case-scenario
[12:08] <asac> right
[12:08] <asac> we could just everyhour
[12:08] <asac> sil2100: oops
[12:09] <asac> sil2100: so one thing that would be good from the workflow would be to have all the binaries staged
[12:09] <asac> and ready for release
[12:09] <asac> before hitting the release button
[12:09] <asac> ... then after that button it basically would just go to remove without further delay
[12:09] <asac> in that way we could see when the stacks are ready for release and could very timely land it, produce a new image, see test results
[12:09] <asac> and act on it in case this change broke something (e.g. backout etc.)
[12:10] <asac> if the thing hits the daily-release testing wall, we just move to the next stack(s)
[12:10] <asac> and dont publish that stack until the engineering team has fixed
[12:12] <nerochiaro> rachelliu: hi, do you have a moment ?
[12:17] <sergiusens> xnox: wrt to your emails, can I bring it over to IRC? I'm not sure we can escape building in a chroot or some other confined environment because we want the base set of -dev packages to not exceed what is provided by the base touch image
[12:19] <xnox> sergiusens: sure. But at the moment I cannot have a single chroot that can do both native and cross builds against the base set of -dev packages. Since the base set of -dev packages fails to co-install for both amd64/i386 and armhf.
[12:20] <xnox> sergiusens: and the idea is that i cross-compile any non-standard extensions. Cause e.g. for stuff that's in the archive I can just download the package and copy the libfoo.so into my click package ;-)
[12:20] <xnox> (the armhf package that is)
[12:21] <xnox> makes sense?
[12:22] <xnox> (the intention certainly was that it can co-install as it has been went at lengths to make all base -dev packages multiarch:same, but seems like a few pieces / leaf nodes are still missing)
[12:22] <sergiusens> xnox: for distribution and copying into click, that's perfectly fine
[12:23] <sergiusens> xnox: and building standalone qml extensions
[12:23] <sergiusens> xnox: was wondering how to solve the next step, for stuff like the dialer-app which is c++ + qml
[12:24] <xnox> well ubuntu-touch-settings thing has multiple c++ and qml extensions and it's all properly package, alas it's still using native compilation, as well one cannot at the moment cross-compile qml extensions easily.
[12:24] <xnox> (without doing all the jumps though all the loops as in my README I published in the branch)
[12:26] <sergiusens> xnox: I'll grab your readme now and see how I can got from code -> click
[12:27] <xnox> sergiusens: well I got from code -> .so. I haven't actually packaged a single .click yet =) please try, maybe there is something missing and/or not clear.
[12:28] <sergiusens> xnox: yeah, you made good progress... making it click is rather simple from there
[12:28] <Anze-> hello everyone. I'm trying to port ubuntu touch to motorola droid 1. I get this error after sync http://pastebin.com/PFkbWnVY
[12:30] <Anze-> http://pastebin.com/eHMaEJfE this is my roomservice.xml
[12:30] <sergiusens> Anze-: first do a 'repo -b phablet-saucy'
[12:30] <Anze-> thanks, going to try that now
[12:32] <sergiusens> Anze-: then figure out what branch nadlabak/android_device_motorola_umts_sholes lives on, as it is not on the phablet repos and it picks up from cyanogenmod but for specific branches (which you can override with roomservice)
[12:33] <Anze-> WTF!!!! it gives me back this!? http://pastebin.com/6feQHY28
[12:34] <sergiusens> Anze-: Anze- I forgot an init in there, repo init -b phablet-saucy
[12:34] <Anze-> oh right ;)
[12:34] <Anze-> that's running! :))
[12:35] <sergiusens> Anze-: also, you ran breakfast/brunch in the past it seems, right?
[12:35] <Anze-> nope...
[12:35] <Anze-> droid 1 is not supporting cm10..
[12:35] <Anze-> :(
[12:37] <Anze-> "in the past" i ran repo init -u git://phablet.ubuntu.com/CyanogenMod/android.git -b phablet-10.1
[12:37] <sergiusens> Anze-: well the -b just needs to be phablet-saucy instead of phablet-10.1
[12:41] <Anze-> the hell again the same error:  http://pastebin.com/CJ0ftmZ4
[12:41] <Anze-> :(( what's wrong!?
[12:42] <sergiusens> Anze-: I asked if you ran breakfast/brunch before because the repo it fails to find is not in the default list, check here .repo/local_manifests/roomservice.xml
[12:44] <Anze-> I wrote the .repo/local_manifests/roomservice.xml by hand... and it's here..: http://pastebin.com/eHMaEJfE
[12:45] <Anze-> is there a way to build it automatically so that I can see how it's different?
[12:45] <rachelliu> nerochiaro: hi, sorry only saw your message
[12:46] <rachelliu> nerochiaro: think i was out at lunch but free now
[12:46] <nerochiaro> rachelliu: no problem. do you know who's the designer in charge of the dialer, sms and contacts app ?
[12:47] <rachelliu> nerochiaro: i'm working on it but christina is the lead
[12:48] <jdstrand> mardy: hi! can you look at your portion of bug #1220552? in particular comments 2 and 3?
[12:48] <mardy> jdstrand: yes, I was about to reply in the bug
[12:49] <jdstrand> ah, great :)
[12:49] <mardy> jdstrand: didn't we agree that there would be an "online accounts" access which applications could specify in their manifest file, which would give them access to the accounts DB?
[12:50] <mardy> jdstrand: (note that ~/.config/libaccounts-glib/accounts.db is just the list of accounts, it doesn't contain any secrets)
[12:51] <davmor2> ogra_: for touch I have quite a few issues but I think most have bugs already is it worth me jotting them down in an email to the list? Just for the sake of double checking
[12:51] <nerochiaro> rachelliu: ok. the question is: is it by design that these apps don't have any actions in the hud ?
[12:51] <ogra_> davmor2, well, 0904 is completely borked anyway ...
[12:51] <sergiusens> Anze-: just use breakfast
[12:52] <ogra_> davmor2, we're waiting for jenkins to come back to trigger a rebuild with a fixed android side
[12:52] <jdstrand> mardy: there is an accounts policy group (see comment #3)
[12:52] <rachelliu> nerochiaro: it's because the hud is still being designed and not sure if its going to be available for use
[12:52] <nerochiaro> rachelliu: ah, other apps are using it just fine though
[12:53] <rachelliu> nerochiaro: the access to the hud usually means additional tasks like access to settings
[12:53] <davmor2> ogra_: uhoh I've just flashed 04 :D ah the fun
[12:53] <jdstrand> mardy: I thought we said that we would not allow direct access to the database. let me get mdeslaur involved
[12:53] <nerochiaro> rachelliu: i see. so for now it's ok that these 3 apps have no actions in the hud ?
[12:53] <rachelliu> nerochiaro: currently for 13.10 we just want the primary functions of the telephony apps to be working
[12:53] <jdstrand> mdeslaur: should the accounts policy group allow access to the accounts.db?
[12:53] <mdeslaur> jdstrand: isn't that what we decided?
[12:53] <jdstrand> mardy: I'm quite sure it should not have write access
[12:53] <nerochiaro> rachelliu: ok. just wanted to confirm that it was ok
[12:53] <jdstrand> mdeslaur: that's what I thought
[12:53] <rachelliu> nerochiaro: currently there are no designs for what actions should be in the hud but we can have a look into it and check
[12:54] <mdeslaur> jdstrand: I mean, I thought we decided apps could access the db
[12:54] <jdstrand> oh
[12:54] <jdstrand> mdeslaur: write access?
[12:54] <jdstrand> apparmor="DENIED" operation="open" parent=716 profile="com.wellsb.blackjack-app_blackjack-app_0.0.1" name="/home/phablet/.config/libaccounts-glib/accounts.db" pid=24322 comm="qmlscene" requested_mask="rwc" denied_mask="rwc" fsuid=32011 ouid=32011
[12:54] <mdeslaur> no, not write access
[12:54] <mdeslaur> just for account enumeration
[12:54] <rachelliu> nerochiaro: for the voice i can't imagine we need access to the hud but perhaps for contacts and messaging in the future for various settings
[12:54] <jdstrand> so, there are two denials, one for write, one for read
[12:55] <nerochiaro> rachelliu: well, i'm asking because i was talked to go through all apps and verify that the hud actions work correctly, and it did strike me as strange that all other apps had actions except these 3
[12:55] <nerochiaro> rachelliu: er, i mean "i was tasked", not talked
[12:55] <jdstrand> mdeslaur: because it is .db, I'm betting we'd need 'rk', so in theory an app could put a read lock on it and not let go
[12:55] <rachelliu> nerochiaro: ok sure, so are you saying apps like Calculator has access to the hud?
[12:56] <stgraber> ogra_: hmm, what? /system is a symlink to /android/system which is the android rootfs, not sure what's confusing about that
[12:56] <nerochiaro> rachelliu: i mean the "basic" or "built-in" apps, whatever is the name for them these days. the ones we develop in-house like camera, notes, etc. they all have access to the hud and put actions there, except for dialer, messages and contacts
[12:57] <ogra_> stgraber, oh, i thought /system carried /
[12:57] <nerochiaro> rachelliu: even though it is debatable if they actually should put actions in there or not. but they do at the moment
[12:57] <rachelliu> nerochiaro: ok i just wanted to know what sort of actions they have. I know for MWC this year, we needed to get HUD working for camera, notes and gallery
[12:57] <mdeslaur> jdstrand: hrm
[12:58] <rachelliu> nerochiaro: since then, there's been on changes on that
[12:58] <mardy> jdstrand: the problem is that I don't think there's a way to tell sqlite to open an archive in read-only mode
[12:59] <rachelliu> nerochiaro: it might be worth asking oren about the hud in general as there are still designs for the whole bottom edge interaction (toolbar + hud)
[12:59] <nerochiaro> rachelliu: for camera you can do from the hud the same things you do in the toolbar. for mediaplayer you can share or play/pause. for browser you have back, forward, reload, bookmark, goto. for notes you have new note and remove note.
[12:59] <Anze-> in which dir shoul I run breakfast? it gives me this error: breakfast: command not found
[13:00] <jdstrand> mardy: http://www.sqlite.org/c3ref/open.html seems to support SQLITE_OPEN_READONLY
[13:00] <nerochiaro> rachelliu: i think if this area is still subject to design change then i should just leave things as they are and when design settle go back and add/remove actions as you see fit.
[13:00] <sergiusens> stgraber: https://code.launchpad.net/~sergiusens/phablet-tools/recovery_from_system_images/+merge/183868
[13:02] <sergiusens> Anze-: first source build/envsetup.sh
[13:02] <dholbach> asac, saw my PM? :)
[13:02] <mardy> jdstrand: mmm... interesting
[13:03] <mardy> jdstrand: is there a way for the a process to know if it has write access to a certain file (libaccounts-glib could use this to determine the opening mode)?
[13:03] <rachelliu> nerochiaro: yup that's a practical suggestion. I know there are reviews ongoing with Mark about the bottom edge interaction in general. I'm going to check with Christina about the telephony apps
[13:04] <rachelliu> nerochiaro: but i know for 13.10, the core functionalities for telephony apps need to work smoothly first
[13:04] <Anze-> I know I tried that but gave 'sudo: build/envsetup.sh: command not found'
[13:04] <jdstrand> mardy: also http://harmattan-dev.nokia.com/docs/library/html/qt4/qsqldatabase.html (QSQLITE_OPEN_READONLY)
[13:04] <sergiusens> Anze-: sudo?
[13:04] <nerochiaro> rachelliu: ok, thanks for the advice
[13:04] <w-flo> jdstrand, have you seen my bug from last week about QMediaPlayer failing for me because of confinement? bug #1218655
[13:05] <rachelliu> nerochiaro: anytime
[13:05] <Anze-> he asked me to! :P bash: build/envsetup.sh: Permission denied
[13:05] <jdstrand> jjohansen: hey, if I do acess() on a file to check for write access, I am going to hit DAC, not LSM, correct?
[13:05] <sergiusens> Anze-: I said source build/envsetup.sh
[13:05] <jdstrand> jjohansen: access()
[13:05] <stgraber> sergiusens: looks good
[13:06] <sergiusens> stgraber: I flashed with it just now
[13:06]  * cjwatson isolates his bug to a missing " character.  Sigh
[13:06] <sergiusens> cjwatson: it sucks when it's that...
[13:07] <jdstrand> w-flo: I have seen it. I just commented int he bug
[13:07] <jjohansen> jdstrand: err it hits the LSM but I am need to check what we are doing with that exactly, give me a sec
[13:08] <ogra_> root@ubuntu-phablet:/# route -n |grep ^0
[13:08] <ogra_> 0.0.0.0         37.80.2.77      0.0.0.0         UG    0      0        0 rmnet_usb0
[13:08] <ogra_> 0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 wlan0
[13:08] <cjwatson> sergiusens: ... but the good news is that I think I just sorted out the last piece of doing multi-database preinstalled apps the way I proposed not long ago
[13:08] <ogra_> cyphermox, any idea why i end up with two default routes ? (and no functional network anymore)
[13:09] <mardy> jdstrand: if access() considered the apparmor permissions as well, than that would be perfect
[13:09] <cjwatson> though this test app isn't appearing in unity, hmm
[13:09] <jjohansen> mardy: it does not
[13:10] <jjohansen> jdstrand: ^
[13:10] <jdstrand> cyphermox: and to piggyback on ogra_, yesterday I left the house and tried to use data, but it didn't work. In that case, I was on wifi at home, left, got the 3G icon, then couldn't use networking (I couldn't resolve names-- don't know if it was a default route thing or not)
[13:10] <mardy> jjohansen: :-(
[13:10] <jdstrand> mardy: you could try to open with write and fallback to read
[13:10] <jdstrand> jjohansen: is there anything better than that ^
[13:10] <jjohansen> jdstrand, mardy: nor can we do that properly atm, we need another hook into the fs to get it right
[13:11] <w-flo> jdstrand, I will provide the click package ASAP, but that's not very soon I'm afraid.. (rather busy right now) thanks for looking into it!
[13:11] <jdstrand> w-flo: you might actually get the fix you need via another bug
[13:11] <jdstrand> w-flo: but whenever you can respond to the bug, that would be great
[13:12] <Anze-> ok it worked but now http://pastebin.com/AqLtqfhz
[13:12] <mardy> jdstrand: right, that will work as well
[13:13] <jdstrand> mardy: I can also explicitly deny the 'w' to silence the denial, but lets see if jjohansen has a better idea
[13:14] <jjohansen> jdstrand: err, let me restate, we could add a new LSM hook to the kernel
[13:14] <Anze-> could I extract the device tree and other things from a pre-built cm10 for sholes which is unofficial but I can find elsewhere on the net? how?
[13:14] <jdstrand> jjohansen: right, but that isn't 13.10 material, correct?
[13:15] <w-flo> jdstrand, sure, thanks! I can respond next week when I'm back at home. (you don't have a DLNA share available for testing I guess, so I'll just create a simple test case app)
[13:15] <jdstrand> jjohansen: I think I'll just say it isn't. I can add a task to the bug for apparmor and mention it would be an improvement
[13:15] <jjohansen> jdstrand: eh, it could be, its not a large change. Its not something I could get upstream in 13.10 time frame but its a hook we should be able to upstream.  Its not a lot of work
[13:15] <mdeslaur> mardy: alternatively, you can check to see if the confinement env ver is set, and open read only if it is
[13:15] <mdeslaur> jdstrand: ^
[13:16] <jdstrand> mdeslaur: yes, that would work too until the lsm hook is there
[13:16] <jdstrand> jjohansen: I'll create a bug for the lsm hook. let's not be distracted by it since we have other options
[13:17] <sergiusens> cjwatson: if it's unity8, restart; it's not updating on changes to ~/.local/share/applications/
[13:18] <cjwatson> I was looking in the wrong place actually
[13:18] <Anze-> anyone?
[13:18] <cjwatson> confused by the app in question showing up under suggestions and didn't realise I needed to expand the installed-applications widget
[13:18] <mardy> mdeslaur: what is "confinement env ver"? An environment variable?
[13:19] <mdeslaur> mardy: yeah, sorry, typo...hold on a sec, I'll find it for you
[13:19] <cwayne_> zsombi, ping
[13:19] <cyphermox> ogra_: jdstrand: I'll do some testing this morning to check out what's up with the routing behavior
[13:19] <zsombi> cwayne_: pong
[13:19] <mdeslaur> mardy: UBUNTU_APPLICATION_ISOLATION=1 is set when apps are run confined
[13:19] <mdeslaur> mardy: see https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement
[13:20] <cwayne_> zsombi, hey, i had some question about app theming if youve got a second
[13:20] <ogra_> cyphermox, FWIW the device was lying around for four days before i touched it again today (intrestingly it didnt really use much battery) ... and the issue is gone after a reboot indeed
[13:20] <cwayne_> sergiusens, ping
[13:20] <mardy> mdeslaur: well, the app could be confined and still have rw access to the accounts DB, if one day we decide to offer that profile
[13:21] <mardy> mdeslaur: I think the safest and most general way is to open the DB in rw mode, and then open it ro if that fails
[13:21] <mdeslaur> mardy: for writes, we should be going through dbus...if you prefer trying it rw first, your call
[13:22] <jdstrand> mardy, mdeslaur (and jjohansen): it might be more portable to look at /proc/<pid>/attr/current to see if you are running under confinement
[13:22] <zsombi> cwayne_: where?
[13:22] <mardy> mdeslaur: for the accounts, there is no DBus daemon; apps are directly accessing the DB (hence the issue)
[13:22] <jdstrand> mardy, mdeslaur (and jjohansen): though I don't know what that looks like under say, selinux
[13:22] <cwayne_> zsombi, well my main question is, can I change the default theme on the system?
[13:22] <jdstrand> (or smack, or tomoyo, ...)
[13:23] <jjohansen> you get a string out that isn't all that different
[13:23] <mdeslaur> jdstrand: that only works until we start confining stuff that actually needs write access though
[13:23] <cwayne_> so that all unthemed apps will change basically
[13:23] <jdstrand> mdeslaur: that's true
[13:23] <mardy> jdstrand: yep, that's why I'd rather play dumb and use the rw->ro fallback
[13:23] <jdstrand> and this is a workaround until we have the LSM hook anyway
[13:23] <jdstrand> mardy: ok, so you decided on rw -> ro? I'll update the policy group
[13:23] <zsombi> cwayne_: not programaticaly yet
[13:24] <jjohansen> how much work is this workaround?
[13:24] <cwayne_> zsombi, is it in the plans?
[13:24] <jdstrand> mardy: I'm going to upload that without 'k' (lock) for now. maybe we can get away with that :)
[13:24] <zsombi> cwayne_: yes, we have plans for that, we need the settings to be in place for that
[13:24] <mterry> tvoss_, so can you explain bug 1219164 to me?
[13:25] <cwayne_> zsombi, okay, so there's no 'real' way to do it
[13:25] <cwayne_> zsombi, but as a hacky alternative, we could overwrite Ambiance's Palette.qml, yeah?
[13:25] <mardy> jjohansen: should be relatively trivial: http://code.google.com/p/accounts-sso/source/browse/libaccounts-glib/ag-manager.c?repo=libaccounts-glib#1161
[13:25] <Anze-> sergiusens did you see my last one?
[13:25] <zsombi> cwayne_: checking the modifications on that...
[13:26] <jjohansen> mardy: well as long as its relatively trivial, I would hate to push a solution that is a fair bit of work and is going to just be thrown away
[13:27] <jdstrand> jjohansen, mdeslaur, mardy: fyi, bug #1220713
[13:27] <jdstrand> jjohansen: I've targeted it to t-series for now and will add it to a bp so it isn't lost
[13:27] <mdeslaur> jdstrand: thanks
[13:29] <jdstrand> mardy: I took the liberty of subscribing you to that bug, so when it is fixed, you can adjust your code as desired
[13:29] <zsombi> cwayne_: one way is to load the theme in your app like Theme.name = "Ubuntu.Components.Theme.Whatever" or any dotted path to your theme
[13:29] <jdstrand> w-flo: re DNLA> I do not, sorry
[13:30] <popey> pmcgowan: if you get a moment can you see if you can reproduce https://bugs.launchpad.net/touch-preview-images/+bug/1220717 ?
[13:30] <popey> (or anyone really)
[13:30] <mardy> jdstrand: thanks!
[13:30] <zsombi> cwayne_: if you need this for all of your apps, then modify ~/.config/ubuntu-ui-toolkit/theme.ini
[13:31] <cwayne_> zsombi, right so what i'm trying to do is customize the theme for operators
[13:31] <cwayne_> zsombi, ah, with that i can change the default theme?
[13:31] <zsombi> cwayne_: yes, atm that's the setting file the user theme is stored
[13:32] <cwayne_> zsombi, do we have any docs for what goes in that file?
[13:32] <cwayne_> or any examples
[13:32] <zsombi> cwaynbe_: the dotted theme URI :)
[13:32] <jdstrand> mardy: so is the apparmor integration in saucy now?
[13:33] <cwayne_> zsombi, oh so i can make a new theme, and just pass the uri in theme.ini?
[13:33] <zsombi> cwayne_: that simple :)
[13:34] <cwayne_> zsombi, what's the actual structure of theme.ini?
[13:35] <zsombi> cwayne_: a text file with a single line specifying the theme URI
[13:35] <zsombi> cwayne_: INI file format
[13:35] <mardy> jdstrand: very soon: https://code.launchpad.net/~mardy/signon-apparmor-extension/new-signond/+merge/182379
[13:35] <cwayne_> zsombi, ah, that's pretty simple
[13:35] <cwayne_> zsombi, and this will work in today's image?
[13:35] <zsombi> cwayne_: you must have one in order to have the theme selectable
[13:36] <zsombi> cwayne_: that works for months already
[13:36] <ogra_> cjwatson, do you think i can use  a naming scheme like in http://paste.ubuntu.com/6062676/  ? or would that break anything
[13:37] <mardy> kenvandine: hi! Once the signon-apparmor-extension MP has been merged, can the package be added to main?
[13:37] <jdstrand> mardy: shouldn't signon's task in bug #1220552 be 'In Progress' (for the rw -> ro bit)?
[13:37] <kenvandine> mardy, what package will depend on it?
[13:37] <cwayne_> zsombi, and does the theme *have* to be installed to the Ubuntu/Components/Themes dir?
[13:37] <ogra_> cjwatson, (respectively for system-|recovery-armel+$subarch.img)
[13:37] <cwayne_> or can it be anywhere
[13:38] <mardy> kenvandine: we can make signond depend on it (we need a distro patch for the /etc/signond.conf file to mention it)
[13:38] <mardy> jdstrand: I'm actually finishing something else now, I'll start working on that tomorrow
[13:38] <zsombi> cwayne_ it must be under /usr/lib/*/qt5/qml or somewhere from where qmlviewer can load it
[13:38] <cwayne_> zsombi, ack, thanks
[13:38] <jdstrand> mardy: ok, I more just meant not 'Invalid'. I'll put it as Triaged
[13:38] <mardy> jdstrand: ah, no!
[13:38] <zsombi> cwayne_: welcome
[13:39] <mardy> jdstrand: it's libaccounts-glib, not signond
[13:39] <kenvandine> mardy, well is it something that is really required for the desktop?  or something for touch?
[13:39] <jdstrand> mardy: ok, I'll adjust
[13:39] <kenvandine> we can get it in touch without going to main
[13:39] <kenvandine> for now
[13:39] <mardy> kenvandine: so, on the desktop is not required
[13:39] <mardy> kenvandine: OK
[13:39] <cwayne_> zsombi, thanks a lot for the help!  i'll try it out before i bother you with more questions :)
[13:39] <zsombi> cwayne_ :) ok
[13:40] <mardy> kenvandine: but then we need to have different versions of signon? One with the /etc/signond.conf file mentioning the extension (for touch) and one which doesn't?
[13:40] <kenvandine> ok, that's what i was wondering
[13:40] <kenvandine> we don't want that
[13:40] <kenvandine> so we really need to make signond depend on it
[13:40] <mardy> kenvandine: but wait, I don't remember; maybe it's not necessary to modify that file
[13:41] <mardy> kenvandine: I can't remember if I made signon just use the extensions if finds
[13:41]  * mardy checks
[13:42] <popey> kenvandine: is there a gsettings fudge to enable/disable scopes on touch? I have managed to disable some and can't re-enable them (chicken & egg error 101)
[13:42] <cjwatson> ogra_: names of livefs download targets don't matter too much, but wouldn't "armhf.armel+maguro.zip" etc. be a pretty confusing name?  I'd be half-inclined to just set target = os.path.join(output_dir, item)
[13:42] <popey> kenvandine: context: bug 1220717
[13:42] <kenvandine> popey, i actually don't know how to stores the scope state
[13:42] <kenvandine> s/to/it/
[13:42] <popey> kenvandine: do you know who does?
[13:43] <mardy> kenvandine: oh, no, I didn't :-)
[13:43] <ogra_> cjwatson, yeah, thats not finished, the above was just a copy paste of the above elif, i actually want to get rid of the arch in there ... i was mostly worried about breaking simething by using something with dot and plus in the name
[13:44] <kenvandine> popey, any of the shell folks probably
[13:44] <cjwatson> ogra_: right, livefs download target names not a big deal.  published names matter a lot more - if those aren't in a fairly standard form then it does tend to cause confusion and excessive complexity elsewhere
[13:44] <kenvandine> mardy, so it really needs to be a depends... can you please file a bug for it explaining why it's needed and i'll convert that bug to a MIR bug
[13:44] <ogra_> right, i dont plan to change the resulting names
[13:46] <asac> oSoMoN: can you check the results
[13:47] <oSoMoN> asac: those for 20130903.3 ?
[13:47] <asac> oSoMoN: yeah
[13:48] <oSoMoN> asac: not any better on maguro for the browser, I assume because nothing was done to deactivate the edge swipe intro animation
[13:49] <annerajb> hello,
[13:50] <tvoss_> mterry, so the location-service will be a trusted helper and ask the user whether an app is allowed to access the service
[13:50] <annerajb> ogra_, i have a question about the mountall upstart job.
[13:50] <annerajb> why do we need to mount the fs if we already have it mounted by the initrd
[13:50] <tvoss_> mterry, that portion isn't implemented yet, although the respective hooks are in the code
[13:51] <tvoss_> mterry, that's what the TODO hints at
[13:51]  * cjwatson scratches head at "qmlscene: failed to check version of file '/custom/.click/users/@all/com.ubuntu.developer.mhall119.xda-developers-app/xda-developers.qml', could not open..."
[13:52] <cjwatson> that seems to just be a QFile(fileName).open(QFile::ReadOnly | QFile::Text) failure which is pretty weird
[13:53] <wellsb>  jdstrand I've added an attachment to 1220552
[13:53] <cjwatson> (the file does exist)
[13:54] <wellsb> Ahh, perhaps I was too late.  Anyway, there it is if it helps
[13:54] <alecu> cjwatson: perhaps it's blocked by apparmor?
[13:55] <ogra_> annerajb, to make it match the fstab, to make sure all bits that werent mouted from initrd are available as well and to make sure all virtual filesystems are mounted too ...
[13:55] <cjwatson> alecu: I'd just got there, yeah
[13:55] <annerajb> ogra_, ok so it basically double checks everything is correctly moutned with the righe modes and such.
[13:56] <ogra_> and to have the right event emitted on success of mountall (which other jobs may rely on)
[13:56] <ogra_> it processes the fstab and emits an event that triggers the other mountall upstart jobs (there are multiple)
[13:56] <annerajb> ah ok well i think that event is working fine since the /var/log/upstart folder has other log files like ureadahead, procps and lxc (when i had it enabled)
[13:57] <annerajb> ogra_, yeah i read the scripts and the upstart cookbook
[13:57] <ogra_> these jobs might run before mountall
[13:57] <ogra_> or in parallel
[13:57] <annerajb> would it be possible that a job is hanged? because those are the only jobs that it run (based on log files)
[13:57] <annerajb> i added console log and console output to all jobs and it didnt make a difference
[13:58] <ogra_> did you read all the logs in /var/log/upstart yet ?
[13:58] <barry> mandel: hi.  saw the d/l service now has group downloads.  yay, and thanks!  have you started to update the docs?  i want to work on the integration again
[13:58] <annerajb> ogra_, yeah
[13:58] <cjwatson> @{CLICK_DIR}="/opt/click.ubuntu.com"
[13:58] <cjwatson> bzzt click-apparmor loses
[13:58] <jdstrand> cjwatson: what are you looking at?
[13:58] <cjwatson> will have to track that down after the call
[13:59] <cjwatson> jdstrand: I'm working on preinstalled click packages which go in a different prefix
[13:59] <annerajb> ogra_, btw every variation of --verbose -d --debug on the kernel cmdline didnt do a difference
[13:59] <cjwatson> and I seem to have confused click-apparmor along the way
[13:59] <jdstrand> cjwatson: click-apparmor should be using pkgdir. it outputs what it finds into the profile
[14:00] <jdstrand> maybe I misunderstand what you are looking at
[14:00] <cjwatson> click pkgdir is working, the apparmor profile is generated wrongly.  I'll recheck to make sure it isn't a local mistake
[14:00] <annerajb> ogra_, this http://pastebin.com/8jdWG89k are the only log files there their content dont seem to show a error
[14:02] <jdstrand> cjwatson: oh, it isn't using pkgdir. it is walking up from .click/info
[14:02] <jdstrand> cjwatson: get_package_manifest() in apparmor/click.py
[14:02] <cjwatson> jdstrand: I forced a regeneration of the profile and it works now, so I think it's probably something broken in timestamp comparison
[14:02] <jdstrand> I see
[14:03] <sergiusens> cjwatson: might be that you isntalled the same version
[14:03] <sergiusens> as a prior one
[14:03] <jdstrand> cjwatson: aa-clickhook only regenerates everything if given '-f'
[14:03] <cjwatson> sergiusens: I had, but the hook ought to regenerate when the timestamp is newer
[14:03] <cjwatson> though maybe the mtime was preserved actually
[14:04] <jdstrand> I'll leave you to it. let me know if I can help with anything
[14:04] <sergiusens> cjwatson: the apparmor one doesn't (from what jdstrand told me)
[14:04] <cjwatson> no, shouldn't have been.  I'll track it down
[14:04] <cjwatson> sergiusens: yeah, that's a bug :)
[14:04] <sergiusens> ack
[14:06] <tvoss_> mterry, anything else you need from my side?
[14:07] <mterry> tvoss_, I was looking for explanation of severity
[14:07] <tvoss_> mterry, well, we need it, but it's a feature
[14:08] <mterry> tvoss_, it's not security related?
[14:08] <tvoss_> mterry, it is
[14:08] <mandel> barry, I'll get you downloads updated for today :)
[14:08] <mandel> barry, is about time I update that wiki
[14:08] <mterry> tvoss_, so that seems more than a feature?  :)
[14:09] <barry> mandel: great, thanks!
[14:09] <dpm> thanks kenvandine for looking at that Friends API MP for the rss reader :)
[14:12] <kenvandine> dpm, np
[14:12] <wellsb> Actions defined on a page level instead of the mainview level don't appear in the hud when that page is opened.  Are others observing this?
[14:15] <tvoss_> mterry, that depends I would say. Sure, it's security relevant, but: it does not get worse at this point
[14:15] <tvoss_> mterry, worse than before that is
[14:16] <asac> om26er: hey
[14:16] <asac> om26er: so we have this problem with the swipe intro thing
[14:16] <asac> consuming CPU while we test ...
[14:16] <asac> om26er: can we somewhat fix our autopilots so it kills that demo?
[14:16] <asac> (first thing)
[14:16] <pmcgowan> popey, I do not see that disable issue, I get to enable again
[14:17] <pmcgowan> popey, are you saying enable doesnt work?
[14:18] <om26er> asac, yes sure, after flashing the device we can just disable that demo and its won't affect us
[14:19] <asac> om26er: i dont like to code that into infrastruvcture
[14:19] <asac> om26er: rather in the tests
[14:19] <asac> so that people running the test get the same experience
[14:19] <asac> om26er: so eihter in phablet-test-run
[14:19] <asac> or directly in autopilot
[14:19] <asac> om26er: how do we stop that demo?
[14:19] <asac> do you know?
[14:19] <mterry> tvoss_, right, but in terms of letting something into main or not...  having security holes isn't great.
[14:19] <om26er> asac, there is a gsettings key for that
[14:19] <tvoss_> kalikiana, ping
[14:20] <om26er> asac, I don't have it on hand, mterry gave it to me
[14:20] <asac> om26er: can you look and make it happen? we have webbrowser and potentially other testsw failing/noisy because of that
[14:20]  * mterry reads up
[14:20] <asac> om26er: we can also temporarily do something in the infrastructure
[14:20] <asac> so we get betyter results now, but i dont want hacks to be there
[14:20] <asac> unless i am 100% sure that the other solution will arrive
[14:21] <om26er> asac, btw disabling the demo means we will need to restart the phone each time because it will only read that value the next time the device comes up
[14:21] <cjwatson> lool: Is there any predefined layout for stuff under /custom or is it all ad-hoc right now?
[14:21] <mterry> asac, ok, yeah.  someone else, can't remember nick was asking about turning it off during autopilot
[14:21] <asac> om26er: cant we do it different?
[14:21] <om26er> asac, so I don't think its fine for who are running tests on their devices with phablet-test-run that their device restarts first
[14:21] <asac> i really hate the idea to make it restart
[14:21] <asac> i want locally to just run the tests
[14:21] <asac> and that should do the right thing
[14:21] <asac> wrt prepping the device
[14:21] <asac> om26er: exactly. its not ok
[14:22] <om26er> or, we could change that gsettings key and restart unity
[14:22] <asac> so lets go and fgure how to do it better
[14:22] <asac> mterry: ^^
[14:22] <asac> we want to stop this stuff for all tests but a test that tests the intro itself :)
[14:22] <cjwatson> lool: I have preinstalled apps working now - the last thing I need to do is to define databases that're analogous to the things Sergio had done in session-manager-touch (/usr/share/preinstalled/click for core apps, /custom/preinstalled/click for carrier customisations AIUI)
[14:22] <asac> mterry: so how can we stop that intro? :)
[14:22] <cjwatson> lool: I'd rather not use those same paths, as they have different semantics (the previous ones were directories full of .click files, while these will have roughly the same layout as /opt/click.ubuntu.com has today)
[14:23] <cwayne_> sergiusens, ping
[14:23] <popey> pmcgowan: there's no way to enable, once you disable, try rebooting
[14:23] <cjwatson> lool: so maybe /usr/share/click/preinstalled/ and /custom/click/ ?
[14:23] <mterry> asac, well, for "live" stopping/starting demo...  that would have to be a new branch to add support for it.  Right now, no autopilot test tests the demo
[14:23] <popey> pmcgowan: the option to enable just isn't there because you disable the dash scope, which is the thing that shows the enable/disable button
[14:23] <pmcgowan> popey, I just long pressed again and the button toggeled to enable
[14:23] <mterry> So it hasn't been an issue.  But it would be nice to add autopilot tests yeah
[14:23] <mterry> asac, for disabling it, I can give you a dbus-send line...  let me see
[14:23] <asac> yeah
[14:24] <asac> that would be cool
[14:24] <pmcgowan> popey, the scope icon was still there after disabling
[14:24] <asac> doanac: are we using phabklet-test-run now?
[14:24] <popey> pmcgowan: lock the screen and unlock, it goes away
[14:24] <jdstrand> beuno: hey, I'm looking at https://myapps.developer.ubuntu.com/dev/click-apps/26/. Can I se the developer's phone number and adress because I am a member of a particular team, or is that available to everyone?
[14:24] <mterry> asac, dbus-send --system --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User32011 org.freedesktop.DBus.Properties.Set string:com.canonical.unity.AccountsService string:demo-edges variant:boolean:true
[14:24] <mterry> asac, sorry, that enables it
[14:24] <asac> hehe
[14:24] <mterry> asac, dbus-send --system --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User32011 org.freedesktop.DBus.Properties.Set string:com.canonical.unity.AccountsService string:demo-edges variant:boolean:false
[14:24] <doanac> asac: not quite. we are close, but probably about 1 week away still
[14:24] <asac> mterry: can we make it just stop consuming CPU if its not in foreground?
[14:25] <asac> doanac: so we want to run the above
[14:25] <asac> doanac: after every boot
[14:25] <pmcgowan> popey, not for me, maybe something got fixed
[14:25] <pmcgowan> I have 0903
[14:25] <asac> doanac: until we use phablet-test-run
[14:25] <doanac> phablet-test-run now uses the same mechanism that utah does though (adb)
[14:25] <asac> good
[14:25] <asac> mterry: so our problem is that the launcher behaves nicely if we start apps without unlocking
[14:25] <mterry> asac, it should stay remembered (unless you're playing with read-only images)
[14:25] <asac> mterry: but the intro is just consuming cycles
[14:25] <popey> pmcgowan: I'm running pending
[14:25] <asac> mterry: yeah, well, better save
[14:26] <sergiusens> beuno: all the click apps would need to be in the store to rate them anyways, right?
[14:26] <pmcgowan> popey, I have yesterdays pending
[14:26] <pmcgowan> popey, and 04 is broken so cant try right now
[14:26]  * ogra_ wonders what happened to simplicity like "touch ~/.first-run-thingie-done" for first run bits ... 
[14:26] <ogra_> this dbus-send stuff is horrid
[14:27] <asac> mterry: you think we could make it just behave nicely?
[14:27] <mterry> ogra_, this was partly because the greeter needs to set/read that value too.  So it can't be stored in user dir
[14:27] <asac> this would avoid udoing this dbus stuff
[14:27] <ogra_> mterry, yeah, and its a modern way, too ... i'm just sad nobody uses such simple things anymore nowadays
[14:27] <asac> mterry: will the dbus above _stop_ a running intro?
[14:27]  * ogra_ is nostalgic today 
[14:28] <mterry> asac, no, not in middle of run
[14:28] <asac> ok so that doesnt help either
[14:28] <asac> mterry: i really want something to just get rid of it
[14:28] <asac> whether its running or not :)
[14:28] <mterry> asac, I could look into making it behave nicely yeah
[14:28] <asac> mterry: what does that involve? just stop doing stuff when not in foreground?
[14:28] <mterry> asac, would you rather I add "live" stop/start or just make it stop animating when unfocused?
[14:29] <asac> mterry: i think the later if we know that this will help :)
[14:29] <asac> mterry: so what we do is we run autopilot after boot
[14:29] <asac> we want th eintro to stop consuming CPUs in that case
[14:29] <mterry> asac, ok, I can look at that today
[14:30] <asac> mterry: is there anything we can do as a quick hack?
[14:30] <asac> like sending this dbus send
[14:30] <asac> and then killing a process?
[14:30] <asac> we are stitting here not getting good dashboard results because of the noise :) ... and people want a new image
[14:30] <asac> (at best before the MIR landing - aka today)
[14:31] <mterry> asac, you can just restart unity8
[14:31] <mterry> asac, after setting the flag
[14:31] <asac> mterry: so send dbus + restart unity8?
[14:31] <asac> doanac: is that possible to do?
[14:31] <asac> om26er: ^^?
[14:31] <mterry> asac, yeah.  it's a user upstart job
[14:31] <cjwatson> jdstrand: should bug 1215997 still be open?  the unity-mir task on bug 1204596 is fix released ...
[14:31] <om26er> asac, we can do that in phablet-test-run as well
[14:32] <asac> om26er: right. if we add it there we need to tell doanac so he can hack it into his utah thing until that uses that
[14:32] <asac> but cool
[14:32] <asac> om26er: how woudl we design it?
[14:32] <doanac> asac: sorry in a meeting. what are you asking is possible?
[14:32] <asac> like phablet-test-run --clean-start ... ?
[14:32] <asac> doanac: get out of the meeting :)
[14:33] <asac> doanac: we want to run dbus-send and restart unity
[14:33] <asac> before running autopilots
[14:33] <om26er> asac, I was just thinking of going phablet-test-run (without arguments) but yeah lets not change what's already working
[14:33] <doanac> asac: you also need to swipe the screen to unlock it if you do that/
[14:33] <om26er> asac, doanac restart in utah probably won't be needed, my unlock script does that already
[14:33] <beuno> sergiusens, they would, yes
[14:33] <asac> doanac: we dont swipe the lock screen anymore afaik
[14:33] <doanac> we really need to get the unlock_screen.sh script into our SDK
[14:34] <asac> so we dont need to do that here either
[14:34] <asac> doanac: the autopilots seem to do it here without anyuthing
[14:34] <asac> they just start the app
[14:34] <asac> it feels
[14:34] <asac> without even bothering
[14:34] <doanac> asac: oh - that's nice. let me look at hacking phablet-tools in a bit
[14:34] <mardy> kenvandine: actually, if we specify "apparmor" in the signond.conf file, and it's not found, the worst thing that happens is a warning in the syslog. Maybe we can live with that and avoid the MIR?
[14:34] <asac> doanac: if we have unlock_screen.sh then we can just drop this hack there as well
[14:34]  * mardy afk
[14:34] <asac> doanac: so in case we still in ned that, lets just add this killing etc. to that logi
[14:35] <asac> c
[14:35] <jdstrand> cjwatson: no, I just closed it mentioning it was fixed in 0.1+13.10.20130826-0ubuntu1
[14:36] <pmcgowan> popey, hey thanks a lot, after a reboot the scope is gone
[14:36] <popey> \o/
[14:36] <cjwatson> jdstrand: excellent, thanks
[14:36] <popey> Borking other people's devices since 2013.
[14:36] <mterry> asac, so do you still want the no-running-when-unfocused?
[14:38] <asac> mterry: i dont know... i think thats not a good solution either
[14:38] <asac> :)
[14:38] <mterry> asac, well.  you have a temporary solution.  Maybe the best long term is being able to stop/start it live
[14:38] <asac> mterry: i think if its built-in phablet-test-run we are fine
[14:38] <kenvandine> mardy, i would prefer avoiding the MIR for now
[14:38] <Laney> mpt: https://wiki.ubuntu.com/SecurityAndPrivacySettings#Phone_locking seems to be missing a design for "Change passcode..."
[14:39] <mterry> asac, we'd want that for testing it
[14:39] <asac> mterry: yeah i guess having a real freature for that is best
[14:39] <Laney> is it just the "Switching /to/ ..." case?
[14:39] <asac> mterry: right. we want ability to opt-out from stopping it for certain tests
[14:39] <mterry> asac, OK.  Will forget unfocus for now, and work on live switch
[14:39] <stgraber> sergiusens: any kind of rough ETA for a new phablet-tools in the archive?
[14:39] <mpt> Laney, I'm drawing it right now. :-) Or at least the "Change passphrase" equivalent.
[14:39] <asac> mterry: maybe its just a command "force-skip-intro"
[14:39] <asac> :)
[14:39] <asac> or something
[14:39] <Laney> mpt: hah, ok then
[14:39] <asac> your call.. i doubt we want to bring it back during aboot/test run if it stopped
[14:40] <asac> mterry: just runtime (e.g. next reboot everything should be normal i guess)
[14:40] <mterry> asac, :-/
[14:40] <mterry> asac, that's harder  :)
[14:40] <asac> mterry: yeah, but its saner :)
[14:40] <asac> dont you agree?
[14:40] <asac> :)
[14:40] <mterry> not sure
[14:40] <asac> mterry: or we have a command: force-state
[14:41] <asac> mterry: well, my problem is that we install once
[14:41] <asac> but reboot many teimes
[14:41] <asac> and would prefer if our device is behaving similar on each reboot
[14:41] <asac> so either we always force an explicit state (then feel free to remember)
[14:41] <mterry> asac, well.   why not as part of installation, just call this command?
[14:41] <asac> or we just skip/kill intro for this boot
[14:41] <asac> mterry: we dont have an installation
[14:41] <mterry> l
[14:41] <mterry> k
[14:42] <asac> afaik we have no facililties for such things
[14:42] <asac> its just flashing our image
[14:42] <asac> and we have no params for that part
[14:42] <mterry> asac, well.  live stop/start is fine.  Any test that needs to enable the demo again can do so for just its test and unset the value at the end of test
[14:42] <mterry> we don't even have those right now
[14:42] <asac> right
[14:43] <asac> yeah, well if i can do both
[14:43] <asac> we can always start/stop before as needed
[14:43] <asac> agreed
[14:43] <asac> for now
[14:43] <asac> later maybe we can be smarter... so lets do that
[14:43] <mterry> asac, will let you know when implemented
[14:43] <cwayne_> stgraber, ping
[14:43] <asac> doanac: om26er: so can we hack something in so we can rerun todays images?
[14:43] <stgraber> cwayne_: pong
[14:43] <asac> doanac: om26er: and replace it when mterry comes along with a clear api?
[14:43] <pmcgowan> popey, how do I re-enable the scope via command line?
[14:43] <cwayne_> stgraber, hey, just curious if we have an ETA til we can stop asking you to sign each of our custom tarballs :)
[14:44] <mterry> asac, I think the API will stay the same as long as that works for you.  It will just take effect immediately
[14:44] <asac> mterry: dbus directly? can you add a convenience command/abstraction maybe?
[14:44] <asac> or jsut an upstart job :)
[14:44] <asac> e.g. stop live-demo
[14:44] <asac> :)
[14:44] <asac> start live-demo
[14:44] <stgraber> cwayne_: no clear ETA, this week my priority is to move everyone to system images, once that's done, I'll have time to rewrite import-cdimage which will add support for derived channels which we need for the -customized channel
[14:44] <stgraber> cwayne_: so I'd say, best case scenario, a week, more if other things get delayed.
[14:45] <om26er> asac, I'll work on that if doanac is not planning to
[14:45] <asac> om26er: go ahead... requires phablet-test-run and utah_setup.sh hackery
[14:45] <asac> guess focus on utah first
[14:45] <asac> so we can get our test results refreshed
[14:45] <asac> and i can get people look at failures again (which they currently refuse due to noise)
[14:46] <asac> om26er: thanks!
[14:46] <doanac> i can take a look, but its going to be a few minutes before I can catch up on this thread  and understand what I'm agreeing to
[14:46] <asac> doanac: we can have a quick call
[14:46] <doanac> k
[14:46] <asac> with you and om26er
[14:46] <asac> let me set it up
[14:46] <asac> in 2 minutes
[14:46] <doanac> asac: make it 10 minutes- i'm still in a meeting
[14:48]  * asac looks at doanac's calendar 
[14:48] <asac> doanac: maybe we should just join in the standup
[14:48] <asac> ? :)
[14:48]  * asac is about to click "join" :)
[14:48] <asac> can wait a couple minutes
[14:48] <asac> tell me when i can come in
[14:49] <sergiusens> stgraber: as soon as the jenkins gets powered up
[14:50] <asac> om26er: do you knwo who was the person behind designing the autopilots for our memory testing?
[14:50] <asac> om26er: http://reports.qa.ubuntu.com/memory/memevent/image/68/machine/mako/
[14:50] <om26er> asac, I believe that's jcollado
[14:50] <asac> cool
[14:50] <asac> doanac: is he also in the standup? :)
[14:50] <jcollado> asac: Yes, I am
[14:51] <asac> ok i will come in a few minutes :)
[14:51] <asac> so dont leave the standup :-P
[14:51] <asac> jcollado: doanac: oh seems its mumble
[14:51] <asac> om26er: jcollado: doanac: so lets have a separate hangout right after ... i am bad at mumble
[14:52] <doanac> asac: meeting done.
[14:52] <om26er> likewise
[14:52] <doanac> asac: add josepht - he now works on memevent
[14:53] <asac> josepht: om26er: jcollado: doanac: https://plus.google.com/hangouts/_/cc43376c7a5e2cb32d16d1c764ea10932a866c15
[14:53] <asac> doanac: come :)
[14:54] <jdstrand> ChickenCutlass: what is the lp team for phone foundations so that phone foundations bugs show up on http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-s-tracking-bug-tasks.html?
[14:55] <jdstrand> ChickenCutlass: should I just use foundations-bugs?
[14:56] <mterry> asac, sorry, switched windows and didn't see your dbus question.  I think from a unity8 perspective, just enabling live start/stop is fine.  But the phablet tools can certainly add a tiny little upstart job that can manage it.  (It doesn't make sense to add yet another API for unity8 to toggle that setting)
[14:56] <jdstrand> ChickenCutlass: also, if I wanted to make sure a bug showed up on your radar, should I assign it to a team? if so, which one?
[14:56] <popey> pmcgowan: feel free to confirm bug 1220717 ☻
[14:58] <cjwatson> jdstrand: I don't think foundations-bugs includes phonedations - it's a trad foundations thing
[14:58] <cjwatson> ICBW
[14:58] <jdstrand> cjwatson: yeah, that was my thinking too
[14:58] <stgraber> sergiusens: looks like it's back online
[14:58] <sergiusens> jdstrand: we don't have one, we used to operate under phablet-team, but too many people are in there now
[14:59] <sergiusens> stgraber: let me kick start
[15:00] <asac> mterry: you think you can give us a single comamnnd for unlocking/locking the screen as well?
[15:00] <jdstrand> pmcgowan: should ubuntu-sdk-bugs be subscribed to qtwebkit-opensource-src, qtbase-opensource-src and qtdeclarative-opensource-src?
[15:00] <asac> mterry: that would help us so much in automation
[15:00] <jdstrand> pmcgowan: I'm trying to get several application confinement bugs to show up on http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-s-tracking-bug-tasks.html
[15:02] <pmcgowan> jdstrand, sure, lets subscribe that team
[15:02] <pmcgowan> jdstrand, I can do it
[15:03] <jdstrand> pmcgowan: thanks, I'd be happy to but I don't think I can cause I am not a part of that team
[15:03] <pmcgowan> right
[15:07] <jdstrand> beuno: when do you expect the click filename changes to land on the server?
[15:08] <beuno> jdstrand, we are deploying them today, I'd say in ~4h
[15:10] <jdstrand> beuno: ok cool (just wondering cause I am seeing the old filenames)
[15:12] <beuno> jdstrand, I'll let you know when it's out the door
[15:13] <jdstrand> thanks
[15:14] <mterry> asac, sorry connection problems.  for swiping away the screen, long term, it will be a separate mechanism (real lightdm greeter, etc) and you can just enable autologin
[15:15] <mterry> bbiab
[15:15] <tmoenicke> mzanetti: ping
[15:15] <mzanetti> tmoenicke: pong
[15:16] <ogra_> asac, 0904.1 build running
[15:19] <lool> cjwatson: the new pathnames for preinstalled seem good to; the only thing is that we had a /custom/share for some stuff under /custom, notably xdg, but it's not mandatory
[15:20] <lool> cjwatson: I'll capture the new pathnames in a wiki
[15:22] <cjwatson> lool: Well, I can equally make it /custom/share/click, although I'm not sure what the /share buys us ehre
[15:22] <cjwatson> *here
[15:22] <sergiusens> cyphermox: can we daily release phablet-tools ?
[15:22] <sergiusens> stgraber: ^^
[15:22] <sergiusens> already merged, waiting on daily release
[15:23] <lool> cjwatson: true
[15:23] <lool> cjwatson: /custom/click seems fine to me
[15:24] <cjwatson> lool: Do you expect any other click databases to need to exist for weird carrier layering use cases or anything?
[15:24] <cjwatson> lool: I've written it such that all it takes is for a .deb to drop a file into /etc/click/databases/*.conf, anyway
[15:25] <lool> cjwatson: this seems just fine to me; we can always extend it later or in an update if the use cases aren't covered yet; it covers what we know we need today
[15:25] <cjwatson> righto
[15:25] <cjwatson> thanks
[15:25] <plars> asac: just catching up on some of the backlog, I had plans to change our runs so that the intro gets disabled today using the dbus-send, I can add that now unless you want us to wait for a different way to do it
[15:25] <lool> plars: oh hey
[15:25] <plars> lool: hi :)
[15:28] <plars> lool: so this network thing is still causing some problems, 30s was a guess, but I may have to extend it
[15:29] <plars> lool: unless we can figure a better way to deal with it
[15:29] <plars> lool: or hang on until we can (hopefully soon) fully convert to running from the host
[15:29] <lool> plars: this is really weird
[15:29] <lool> plars: did you see my proposed PING change?
[15:29] <plars> lool: I did, and responded
[15:29] <lool> plars: or would like to see some packet capture if that's possible
[15:29] <lool> plars: oh sorry
[15:29] <plars> lool: icmp was blocked for us previously, but I think we actually have it now
[15:30] <plars> lool: I'll get that when the phones aren't busy testing
[15:31] <plars> lool: and not just that, but I'm getting name resolution problems again also
[15:31] <sil2100> sergiusens: any important change in phablet-tools needing release?
[15:31] <sil2100> I'll roll all the stacks now if that's the case since jenkins is up again
[15:32] <lool> plars: Also I cant explain why this would specifically affect r/o images
[15:32] <sil2100> With misc going first
[15:32] <plars> lool: we did see at least the name resolution problems previously on the other images, but not so much now
[15:32] <plars> lool: anecdotally at least, it does seem to be worse on the touch_ro images
[15:33] <sergiusens> sil2100: yes, a bootstrapping change for the image based upgrade images
[15:34] <plars> but I did see it make it through once this morning before falling asleep, and it works for me locally in all my tests
[15:34] <plars> so it could be some odd infrastructure issue that we just can't see yet
[15:35] <lool> plars: it might be a slight variation in startup time causing this
[15:35] <lool> plars: I suspect it's a firewall related thing, like time to allow packets through or something
[15:41] <Stskeeps>    
[15:41] <asac> plars: coordinate with doanac
[15:41] <asac> we bascically said we do what you said
[15:41] <asac> and rerun the jobs
[15:42] <asac> because we want to get a /current promotion
[15:42] <plars> asac: but aren't we about to get a 20130904.1 image from what ogra_  said earlier?
[15:43] <plars> asac: I'm not sure the current set of jobs will finish by then anyway, because we had to wait for the power to come back before starting them, so they haven't been running long
[15:43] <asac> plars: i want to land it now
[15:43] <asac> and rerun
[15:43] <asac> unless the image pops out before we can commit the patch
[15:43] <asac> i have no time to loose :)
[15:44] <asac> plars: i am fine to also rerun just the ones that failed
[15:44] <asac> plars: point is that people refuse to look at failures, so i want to give them new results without this noise :)
[15:44] <plars> asac: ok, so the changes that went into 0904.1 weren't critical enough that you want to pick them up?
[15:44] <asac> and not having a new /current is blocking touch_ro as well as MIR rollout
[15:45] <plars> asac: understand
[15:45] <asac> plars: i dont know what landed
[15:45] <asac> people were refusing to look at results
[15:45] <asac> whatever gets me beyond that point sooner
[15:45] <asac> the better
[15:45] <asac> ogra_: whjere is the .1 image?
[15:45] <asac> ETA?
[15:45] <asac> ogra_: can you teach plars to learn how to find out if an image is building?
[15:46] <ogra_> dunno still running (though it will be .2, i typoed the build command for .1)
[15:46] <ogra_> asac, that requires cdimage access
[15:49] <asac> ogra_: when did the image start building?
[15:49] <asac> plars: so yeah. lets land it before the new image is out
[15:49] <ogra_> around :30
[15:49] <asac> plars: and at best retry the webbrowser test on maguro
[15:49] <asac> to see if it has any effect
[15:50] <asac> plars: so that we are sure that stuff works before we start getting results for .1
[15:50] <cwayne_> anyone know when the smart scopes are landing in utouch?
[15:50] <asac> err .2
[15:50] <asac> ogra_: yo
[15:50] <plars> asac: doanac is pushing it in right now
[15:50] <ogra_> should be done arnound the full hour ...
[15:50] <cwayne_> imc onfused cause i had them yesterday, but not today
[15:50] <asac> plars: right. cool.
[15:50] <plars> asac: and we'll retry as soon as that happens
[15:50] <ogra_> +/- 5min
[15:50] <asac> nice
[15:50] <asac> plars: thanks!
[15:50] <plars> asac: np :)
[15:50] <asac> ogra_: so you think the .2 build is nice and beautiful?
[15:52] <ogra_> asac, heh, how could i tell :P
[15:52] <asac> ogra_: you have experience and you know what landed
[15:52] <asac> etc.
[15:52] <ogra_> i doubt it regressed
[15:53] <asac> ogra_: thats a good thing... if it is back to where we were
[15:53] <awafaa> mhall119: can you advise jono i need an answer by this week please ;)
[15:53] <asac> would even better :)
[15:53] <asac> e.g. no absolute regression\
[15:56] <mhall119> awafaa: in regards to what?
[15:56] <mhall119> awafaa: jono is on holiday this week, btw
[15:57] <popey> greetings awafaa, anything any of us can help with?
[15:58] <awafaa> mhall119: ok it's in regards to touch at the dev summit. chris kenyon was fairly positive about attending but i need the workers to answer :)
[16:00] <awafaa> popey: greetings, unless you can confirm if/what herr bacon will talk about at the end of october, i doubt it
[16:00] <ChickenCutlass> jdstrand, sorry -- was away
[16:00] <ChickenCutlass> rsalveti, what is the team in LP for us with regards to bugs
[16:00] <ChickenCutlass> rsalveti, jdstrand is looking to assign us one.
[16:00] <mhall119> awafaa: is this the ARM conference?
[16:00] <popey> awafaa: no idea
[16:00] <lool> ah new build numbers
[16:01] <rsalveti> ChickenCutlass: only one we have now is phablet-team
[16:01] <ChickenCutlass> rsalveti, I thought we created something else.
[16:01] <rsalveti> but that's not necessarily for the phabledations
[16:02] <rsalveti> let me check the ones I'm part of
[16:02] <rsalveti> ChickenCutlass: canonical-phonedations-team
[16:02] <lool> asac: we're not blocked on new /current promotion anymore
[16:02] <lool> asac: we did the testing we needed now
[16:03] <lool> (AFAIK)
[16:03] <ChickenCutlass> rsalveti, right
[16:03] <ChickenCutlass> jdstrand, https://launchpad.net/~ubuntu-phonedations-bugs
[16:03] <stgraber> lool: yep, just waiting for new phablet-flash to land, then I can send the email/g+/blog post
[16:03] <dwisse> Is libpurple available on ubuntu touch?
[16:04] <rsalveti> ChickenCutlass: this one is not covering our team
[16:04] <lool> stgraber: cool
[16:04] <awafaa> mhall119: yup
[16:04] <jdstrand> ChickenCutlass: great, thanks!
[16:04] <ChickenCutlass> rsalveti, it is not
[16:04] <stgraber> lool: the new phablet-flash removes the last dependency on cdimage.u.c that we had for system-images (extracting the recovery image)
[16:04] <lool> stgraber: that's the one pulling recovery from system-image.u.c, right?
[16:04] <lool> right
[16:04] <jdstrand> slangasek: if I assign/subscribe a bug to https://launchpad.net/~ubuntu-phonedations-bugs, will it show up on http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-s-tracking-bug-tasks.html?
[16:04] <rsalveti> ChickenCutlass: would you mind adding our team as part of that one?
[16:05] <jdstrand> slangasek: there aren't any now, but that might just be because there aren't any bugs
[16:05] <ChickenCutlass> rsalveti, I am confused -- add who to what?
[16:05] <ChickenCutlass> lol
[16:05] <nyl> hi
[16:05] <nyl> mount -t ext4 /sdcard/tubuntu.img /data/tubuntu
[16:06] <plars> asac: ok, doanac pushed the change, anything that hadn't been run already and had any failure in it has been restarted (one was a systemsettle, one autopilot)
[16:06] <rsalveti> ChickenCutlass: add our team members to https://launchpad.net/~ubuntu-phonedations-bugs
[16:06] <nyl> will this work?
[16:06] <jdstrand> ChickenCutlass: I think the other part of it is for the packages you are interested in, subscribing ubuntu-phonedations-bugs to those packages
[16:06] <nyl> so i can boot ubuntu of sdcard
[16:07] <nerochiaro> gusch: is there any specific reason why the MainView in gallery is loaded by a loader ?
[16:07] <slangasek> jdstrand: no; the bugs that show up there are the release-targeted bugs on packages that ~ubuntu-phonedations-bugs is subscribed to
[16:07] <jdstrand> ChickenCutlass: eg, ubuntu-phonedations-bugs isn't subscribed to lxc-android-config
[16:07] <gusch> nerochiaro: for performance reasons (I'd say)
[16:07] <jdstrand> slangasek: that is what I meant-- I just didn't know if a bug was all set up correctly, if the report would pick it up for ubuntu-phonedations-bugs
[16:07] <nerochiaro> gusch: yeah, but what i mean is, why can't the main view be loaded immediately and whatever heavy stuff inside of it loaded via a loader ?
[16:08] <nerochiaro> gusch: i think MainView is supposed to be the top level of an app
[16:08] <ChickenCutlass> jdstrand, ok
[16:09] <gusch> nerochiaro: well MainView is already quite heavy ;)
[16:09] <gusch> nerochiaro: but if you change it - go ahead ;)
[16:09] <slangasek> jdstrand: yes - but just to make sure we're on the same page, this is subscribing the team to the package and targeting the bug, *not* assigning the bug to the team
[16:09] <jdstrand> slangasek: gotcha. not assignments
[16:11] <jdstrand> ChickenCutlass: for now I assigned two bugs to ubuntu-phonedations-bugs so it is on your radar, both against lxc-android-config, but I think both may be retargeted to another more appropriate source package. can you make sure whatever they are retargeted to else ends up having ubuntu-phonedations-bugs to it?
[16:11] <jdstrand> s/else/also/
[16:11] <ogra_> slangasek, any reason why we cant just use canonical-phonedations-team and need to maintain an extra team for this ?
[16:11] <jdstrand> weird typo..
[16:11] <ChickenCutlass> jdstrand, ok got it
[16:12] <ChickenCutlass> ogra_, I don't mind which team is used
[16:12] <ChickenCutlass> ogra_, whatever is easier
[16:12]  * jdstrand also doesn't care-- just trying to make them show up for people :)
[16:13] <ogra_> ChickenCutlass, well, it is extra maintenance we add for no use imho
[16:13] <ogra_> ChickenCutlass, unless we want community people to joun that ubuntu- team
[16:13] <ChickenCutlass> ogra_, ok, so what do we want to do?
[16:13] <ogra_> then it makes sense to keep an extra team
[16:14] <slangasek> ogra_: so that you don't have everyone on the team getting all the bug mail for every package you're responsible for
[16:15] <ogra_> slangasek, well, but if i have canonical-phonedations-team being a member of ubuntu-phonedations-bugs the whole team will get the mails anyway :)
[16:15] <ogra_> so we can save the overhead of maintaining an extra team *unless* we want community people to join that team
[16:17] <slangasek> ogra_: no, they will not.  The separate team is created *specifically* so that bug mail goes to a no-op mailing list.
[16:17] <ogra_> slangasek, but we want the mail
[16:17] <slangasek> you bloody well don't
[16:18] <ogra_> why wouldnt i  ?
[16:18] <rsalveti> yeah, I would want that email as well
[16:18] <ogra_> it makes sense that the phonedations team gets bug mail for all packages it is responsible for
[16:19] <ChickenCutlass> ogra_, I would like that
[16:20] <slangasek> you want *everyone* on the team to get bug mail for *all* the packages that *anyone* on the team is responsible for?
[16:20] <ogra_> so lets do it that way
[16:20] <rsalveti> yup
[16:20] <slangasek> I mean, if that's really what the team wants, we can set it up that way
[16:20] <slangasek> but I think that's insane :)
[16:20] <ogra_> slangasek, yes, i'm perfectly able to set up filters in my mail client :)
[16:20] <ogra_> and my team mates are too
[16:21] <slangasek> why make everyone set up filters for mail you could have not been receiving in the first place?
[16:21] <ogra_> because then we miss the bugs
[16:21] <asac> plars: keep me posted. thx
[16:21] <ogra_> or have to look them up somewhere
[16:21]  * ogra_ prefers push to pull 
[16:22] <ogra_> ChickenCutlass, rsalveti, lets probably postpoe that until tomorrow and discuss it in the standup
[16:22] <ogra_> *postpone
[16:22] <ChickenCutlass> ogra_, ack
[16:22] <ogra_> slangasek, ^^
[16:23] <ogra_> slangasek, i'm in the installer team, i'm used to mail bombs all day :)  (but i guess asking the others first is fair)
[16:25] <lool> plars, doanac: Can we kill the 4:20130904:20130903.2 touch_ro tests to make way for 04.1?
[16:26] <slangasek> ogra_, ChickenCutlass: it's up to phonedations how they want to manage their bugs; bdmurray and I just need to know what team you want used for the package tracking
[16:26] <ChickenCutlass> slangasek, ogra_ rsalveti  I don't really care what name we use.  Let's just pick something
[16:27] <lool> xnox: thanks for the writeup on cross-building qmake
[16:27] <lool> xnox: did you also look at replacing the qmake templates with cmake ones?
[16:27] <rsalveti> yeah, would say to use ubuntu-phonedations-bugs for now, and we discuss tomorrow if we want canonical-phonedations-team to be part of that team
[16:27] <ogra_> ++
[16:27] <lool> xnox: in a chroot with just the cross stuff installed (:armhf SDK), it installs fine and starts the build (dies horribly in qmake runes)
[16:28] <darius_> is there any ubuntu os available for sony xperia e?
[16:29] <ogra_> asac, 0904.1 is done btw (weird, i thought it would have come out as .2 since the former attempt failed)
[16:30] <plars> lool: those shouldn't be interfering with it
[16:30] <plars> lool: the 0904 tests are still running (they got a late start due to the power outage), and asac said to go on with those rather than restarting for .1
[16:31] <xnox> lool: correct, at the moment I had to run qmake on the host system targetting cross-arch, and run $ make clean, to get all makefiles. After that transfer into chroot, and finish the actual $ make all, there
[16:32] <lool> xnox: geez
[16:34] <xnox> lool: it's because at the moment it's impossible to co-install all of *qt*-dev for two architectures. If i could, it would work from a "single" hmm.... "os"? "installation" / chroot.
[16:34] <plars> asac: webbrowser test is passing now, still 1 failure on friends app
[16:34] <lool> xnox: ack; will check your branch to see what's the problem in qt
[16:35] <xnox> lool: thus the bug that qt5-qmake (at least) must be co-installable should be a high priority to fix. Which includes changing mkspec location from /usr/share/qt5/mkspec -> /usr/lib/$(DEB_HOST_MULTIARCH)/qt5/mkspec across the board of all qt*-opensource-src packages.
[16:35] <xnox> and any qml extensions that drop-ship qmake config files, etc.
[16:39] <asac> plars: cool
[16:39] <asac> plars: lets get fresh results then for everything
[16:39] <asac> and take a look
[16:39] <asac> oSoMoN: friends is failing still
[16:39] <asac> om26er: ^^
[16:39] <asac> even with intro fix
[16:40] <plars> bug #1220815
[16:40] <asac> plars: fresh results == latest iamge from today
[16:40] <plars> asac: want me to kill the current run to let it go on with the .1 image? or let this one keep going?
[16:40] <asac> oSoMoN: maybe thats the toolbar thing?
[16:40] <om26er> friends have like 2 tests from last I saw
[16:40] <asac> plars: not sure .. how far are we in?
[16:40] <asac> plars: i feel lets have all the jobs we retried finish
[16:40] <lool> sergiusens: I didn't get the point about recovery.img being a stable interface; if it breaks in some way it will break all the QA infrastructure etc. but wont brick devices, so we will immediately fix it, yes?
[16:40] <asac> the idea was to get a bteter view asap
[16:41] <asac> then we get .1 aftr
[16:41] <plars> asac: all the jobs we retried are already finished, it's just finishing out the rest since it hadn't gone very far
[16:41] <om26er> asac, plars I can fix that failure
[16:41] <plars> asac: they are less than half done on the 20130904 image
[16:41] <om26er> its just expecting wrong state
[16:41] <lool> plars: 166 out of 261 expected?
[16:42] <plars> lool: I'm just looking at total jobs run
[16:42] <lool> ok
[16:42] <asac> plars: ok lets go directly to the .1
[16:42] <cjwatson> xnox: not easier to convert to cmake rather than rearranging qt5-qmake to be co-installable and to have a way to pick the target arch?
[16:42] <asac> plars: and get results there soonish
[16:43] <asac> om26er: please do!!
[16:43] <plars> asac: ok, will do
[16:44] <xnox> cjwatson: not if your cmakemodule file for your extension is generated by qmake?! something for me to investigate, a couple of people suggested that.
[16:44] <plars> looks like messaging-app had a fail also before I killed the run
[16:44] <asac> plars: new?
[16:44] <asac> plars: maybe show om26er as well
[16:44] <cjwatson> xnox: isn't that under the control of the SDK?
[16:44] <plars> asac: I think it may have been in the 20130903.3 image from last night too
[16:45] <asac> plars: was there a landing of messaging-app?
[16:45] <asac> plars: lets check http://people.canonical.com/~ogra/touch-image-stats/
[16:45] <plars> om26er: https://jenkins.qa.ubuntu.com/job/saucy-touch-maguro-smoke-messaging-app-autopilot/17/console
[16:46] <asac> plars: dont see a landing of that app on quick glance
[16:46] <plars> asac: no, doesn't look like
[16:46] <plars> asac: but it failed twice in a row
[16:46] <asac> plars: one or many tests?
[16:46] <xnox> cjwatson: in what sense? as in our default template for qmlextension all does it in native cmake without using qmake? ok.
[16:47] <plars> asac: just one
[16:47] <oSoMoN> asac: looks like the friends app is using a deprecated API, should be easy to update, let me see
[16:47] <asac> oSoMoN: om26er is also on it... so sync with him
[16:47] <asac> thanks!
[16:47] <asac> oSoMoN: messaging-app ... also interesting
[16:47] <asac> see the failure: https://jenkins.qa.ubuntu.com/job/saucy-touch-maguro-smoke-messaging-app-autopilot/17/console
[16:47] <asac> we killed the job so we dont have the dashboard ...having .1 spinning already
[16:47] <plars> http://reports.qa.ubuntu.com/smokeng/saucy/image/3944/messaging-app-autopilot/
[16:47] <oSoMoN> om26er: you’re on the friends-app failure?
[16:47] <plars> just on maguro though?
[16:47] <cjwatson> xnox: if possible, that seems like it'd be a lot simpler
[16:48] <om26er> oSoMoN, yes I am, its using the wrong state to check for the toolbar
[16:48] <cjwatson> but I realise I speak from a position of relative ignorance of building QML things
[16:48] <om26er> plus the app does not wait for the window to appear before clicking here and there
[16:48] <cjwatson> xnox: AFAIK nobody has so far said "no, you can't do that" though
[16:48] <oSoMoN> om26er: the tests should be updated to use the standard UITK emulators
[16:49] <om26er> oSoMoN, that as well, I have a blueprint to improve apps I'll add friends there as well. but for now isn't it fine to just fix that test and move on ?
[16:50] <oSoMoN> om26er: I think it’s the perfect opportunity to convert this app, it shouldn’t take long, I can take care of it if you have other priorities
[16:50] <davmor2> ogra_: do we have a fixed build yet?
[16:50] <oSoMoN> asac: the messaging app failure looks easy to fix, I’ll ping boiko
[16:50] <om26er> oSoMoN, I am not doing anything else so if you want to take it go ahead, I'll something else ;)
[16:50] <xnox> cjwatson: right. I'll put that to the test, later tonight. need to finish up a few things before eod.
[16:50] <om26er> *fix
[16:51] <oSoMoN> om26er: well if you’re not busy I’ll leave it to you, I have other stuff on my plate atm, but I can review your MR
[16:52] <om26er> oSoMoN, cool, I'll have a branch soon
[16:52] <oSoMoN> om26er: thanks
[16:53] <cjwatson> sergiusens: uploaded click 0.4.3 with new code to handle preinstallations.  I'll adapt livecd-rootfs and session-manager-touch to that tomorrow, I think - EOD soon
[16:54] <doanac> plars: in a meeting, but can you look at lool's request to me a while up in the log?
[16:55] <wellsb> popey: Have you received any more reports of audio failure on n4 besides me and nik90?
[16:55] <popey> not that I have seen
[16:55] <plars> doanac: I think I already responded to it
[16:56] <wellsb> Mine worked briefly yesterday, but today there's no sound again.  I wish I had kept up with what update fixed and then broke it
[16:58] <mhall119> wellsb: I have no audio on my n4 either
[16:58] <mhall119> nor rotation either it seems
[16:59] <cyphermox> ogra_: jdstrand: so I managed to somewhat reproduce the issue, apparently
[16:59] <mhall119> camera still works at least
[16:59] <wellsb> My rotation wasn't working earlier in the day, but it seems to be working now
[16:59] <mhall119> sergiusens: ogra_: any idea what's going on with the n4?
[16:59] <mhall119> I've been dist-upgrading, so I'm assuming I'm installing stuff that hasn't gone through the testing gauntlet
[16:59] <mpt> Laney, https://wiki.ubuntu.com/SecurityAndPrivacySettings?action=diff&rev2=32&rev1=31
[17:00] <wellsb> I have, too.  Oh well
[17:00] <mhall119> wellsb: if you phablet-flash without --pending and it's still broken, then we have an issue
[17:01] <sergiusens> cjwatson: great, thanks
[17:01] <wellsb> mhall119: I reflashed yesterday and did not use --pending that time.  and I used --wipe
[17:03] <sergiusens> lool: by stable interface I mean to always find it in partitions/recovery.img when extracting
[17:03] <wellsb> Audio worked immediately after the flash, but not after upgrading and dist-upgrading
[17:03] <lprofil> Hello there
[17:04] <lprofil> i just wanted to flash my "old" nexus 7 folowing the wiki guide on:
[17:04] <lprofil> https://wiki.ubuntu.com/Touch/Install
[17:05] <lool> plars: yup I think you did, the overall question is identifying top issues with tests on the touch_ro run
[17:05] <AskUbuntu> Why doesn't Ubuntu Touch support multiple users? | http://askubuntu.com/q/341355
[17:06] <asac> lool: can you help me decipher the version that i see on dashboard?
[17:06] <asac> lool: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/
[17:06] <Anze-> trying to port UbuntuTouch to motorola droid 1 'sholes' device. breakfast gives back this: http://pastebin.com/mBB6wEPh     . Workarounds?
[17:06] <lool> asac: it's a new triplet that plars/doanac added to list the system-image version + android version + ubuntu version
[17:07] <asac> lool: ok so the first part is what matters to me
[17:07] <plars> lool: yes, and on the maguro runs I can't seem to get past a bunch of name resolution and other errors when it does apt-get update
[17:07] <sergiusens> lool: oh, and a bad recovery won't brick devices since we have fastboot
[17:07] <plars> asac: actually they all matter, apparently for now at least, the first part isn't going to change just because one of the other ones do
[17:07] <asac> lool: i kind of dont like that we give the same global number that is combined from different dates for the other parts
[17:07] <plars> though I've seen it change more than I expected... stgraber?
[17:07] <asac> if you know what i mean
[17:07] <asac> like we have one build that has a different android version
[17:07] <asac> but all builds are 4:
[17:08] <asac> ... guess harder to fix :)
[17:08] <lool> asac: only the first number matters
[17:08] <lool> (4)
[17:08] <asac> right
[17:08] <lool> asac: but the other are FYI
[17:08] <asac> i will dismiss the rest
[17:08] <lool> asac: see bottom of http://system-image.ubuntu.com/daily-proposed/mako/index.json
[17:08] <asac> until its needed
[17:08] <plars> asac: exactly, we talked to stgraber about this yesterday and he said it was fixable, but would be much easier to fix once he lands some other stuff, ETA I think was a couple of weeks
[17:08] <lool> asac: second block from bottom
[17:08] <asac> lool: i dont like that its out of sync though
[17:08] <asac> :)
[17:08] <ElectroPug> Hello everybody - I'm a total noob in development and have a quetion: A member in my xda-forum said he could get a working ubuntu-touch rom if he could get chroot.. How can you actually acquire chroot?
[17:09] <plars> asac: so we'd really like to see the build number match a single pair of rootfs/android images
[17:09] <asac> lool: guess requires a better heartbeat synchonisation?
[17:09] <lool> asac: it's not out of sync, the android package has  20130903-0ubuntu1
[17:09] <asac> plars: i feel that we would like to see the build come together from the same parts
[17:09] <asac> unless we explicitely dont want that
[17:09] <asac> lool: we have two 4: builds for mako
[17:09] <asac> i think thats the confusing parts
[17:10] <asac> 4:20130904:20130903.2 touch_ro mako
[17:10] <asac> 4:20130903.3:20130903.2 touch_ro mako
[17:10] <lool> hmm right
[17:10] <asac> maybe a bug in our incrementor?
[17:10] <plars> asac: the way he explained it was that the build number wasn't set up to increment until we get a release, but I don't think we've declared 3 official touch ro images since changing the numbering scheme right?
[17:10] <lool> stgraber: do daily-proposed ids get reused?!
[17:10] <asac> plars: the touch_ro tests are run in parallel to our touch tests? e.g. do we have a separate device for those?
[17:11] <lool> stgraber: (like number 4 above)
[17:11] <asac> plars: ok i see. that might make some sense
[17:11] <plars> asac: yes, we do
[17:11] <asac> so the first version is basically the "/current"
[17:11] <asac> and then we see something else :)
[17:11] <plars> asac: the thing I'm confused on though, is that based on that description, why are we not still on "1"
[17:11] <asac> wonder how i can find out what the 4 build is
[17:11] <asac> :)
[17:11] <Anze-> anyone can help me custom porting ubuntu? ::::::::::::::::::::::)))))))))))))))))))))))))
[17:12] <asac> i guess a 4:...:... build bcomes a 4 through promotion
[17:12] <asac> but not sure
[17:12] <oSoMoN> boiko: hey, can you please have a look at this trivial MR: https://code.launchpad.net/~osomon/messaging-app/fix-ap-test-activeFocus/+merge/183934
[17:12] <asac> plars: well, guess there were test images etc.
[17:12] <boiko> oSoMoN: sure
[17:12] <stgraber> lool: yes, they do
[17:12] <stgraber> lool: the version of daily-proposed is always that of daily + 1
[17:12] <lprofil> adb push
[17:12] <lprofil> seems to obsolete now and instead i try with
[17:12] <lprofil> adb sideload
[17:13] <asac> lool: also i dont understand what the 20130904 ? build is that is also tested
[17:13] <stgraber> lool: unless they both have the same image as their tip, in which case they both have the same version
[17:13] <asac> is that before we landed the version scheme?
[17:13] <plars> asac: I think so, yes
[17:13] <boiko> oSoMoN: I'll just wait for jenkins to finish running on it and then I'll approve it
[17:13] <oSoMoN> asac: there’s a pending MR that fixes the failure in the messaging app, and om26er is taking care of the friends app
[17:13] <oSoMoN> boiko: sounds good to me, thanks
[17:13] <plars> asac: I think those just need to be flagged in the dashboard to ignore them... probably from when I was testing last night (before the dashboard changes landed)
[17:13] <cjohnston> asac: the ? should be ignored
[17:13] <asac> oSoMoN: very nice
[17:13] <stgraber> lool: that's why I want the dashboard to show "4 (ubuntu=20130904, grouper=20130903, custom=20130902)" so that we clearly know what all the bits are
[17:14] <kerio_> hi all
[17:14] <cjohnston> plars: no.. its the fact that X:YYYYMMDD:YYYYMMDD existed before the dashboard was ready for it
[17:14] <plars> cjohnston: right
[17:14] <cjohnston> So it will need to be ignored in the dashboard, not in jenkins
[17:14] <plars> cjohnston: I think that's what I said... I was spitting out results with the new version before the needed dashboard changes landed
[17:14] <asac> stgraber: so is it right that the 4: means that this is a diff on top of our 4: build?
[17:14] <asac> stgraber: where can i find what the 4 build is?
[17:14] <Guest33057> i'm looking for a speaker about ubuntu mobile during the sfd in côte d'ivoire
[17:15] <plars> cjohnston: also what I said :) "<plars> asac: I think those just need to be flagged in the dashboard to ignore them... probably from when I was testing last night (before the dashboard changes landed)"
[17:15] <cjohnston> sorry.. misread :-)
[17:15] <plars> cjohnston: this is what you mentioned earlier right? Is there an admin dashboard that we can do that in easily?
[17:15] <stgraber> plars: note that the current version number 4:20130904:20130903.2 doesn't really tell me anything, can you please use the format I suggested? In this case 4 (ubuntu=20130904, mako=20130903.2)
[17:15] <asac> plars: kk so just ignore the ones with the old version scheme. gotcha
[17:15] <cjohnston> plars: yes.. kinda..
[17:16] <stgraber> plars: because we'll be adding extra tarballs soon enough and I'd rather not have to guess which version refers to what bits
[17:16] <asac> cjohnston: can you do that convenience hack for stgraber?
[17:16] <stgraber> asac: 4 is the system-image version number. That's the version that'll be used in the production index.json should the image pass all the tests.
[17:16] <asac> stgraber: ic
[17:17] <asac> stgraber: i think that makes sense now
[17:17] <stgraber> asac: the version numbers after that are the version of all the various bits that are part of the image #4 (ubuntu rootfs, android image, customization tarball, ...)
[17:17] <cjohnston> plars: that should be done in the job not in the dashboard, correct?
[17:17] <plars> stgraber: we did that to make parsing the version much easier in the dashboard, the ordering is the same as what you suggested though
[17:17] <asac> stgraber: yeah. so i feel i would really like to somehow consolidate that triplet
[17:17] <asac> for that we probably need an atomic tick
[17:17] <asac> though
[17:18] <asac> so we can build all the parts from a snapshot of the archive
[17:18] <asac> and be sure we picked up the same state in all images
[17:18] <stgraber> asac: we can't, by design. We will have cases where we only update the rootfs and not android. That's because the whole point of system image is to have a shared rootfs across devices but have the other bits evolve on their own.
[17:18] <asac> but well, i guess the android parts go into the rootfs soon anyway
[17:19] <asac> stgraber: i dont think thats a problem. i just give the whole new run a new tick
[17:19] <asac> even if the rootfs doesnt change
[17:19] <asac> we just produced a new revision of the whole thing
[17:19] <asac> what i am sure about is that we dont want to move individual devices forward independently
[17:19] <asac> we always want to treat all as one output
[17:19] <asac>  / produce
[17:20] <asac> but well, thats later
[17:20] <asac> i dont think the versioning scheme blocks us in that regards
[17:20] <asac> seems pretty flexible to carry 1-N versions :)
[17:21] <asac> stgraber: do we preserve the knowledge about the staging version when promoting?
[17:21] <stgraber> asac: what do you mean by knowledge?
[17:21] <asac> stgraber: if i see an image "4" in the daily channel, can i reverse lookup which proposed version produced that?
[17:21] <asac> in practice, e.g. can i find the matching dashboard results
[17:21] <stgraber> asac: that'd be "4"
[17:22] <asac> stgraber: but then its hard to guess
[17:22] <asac> maybe we didnt promote the latest,. but the one before
[17:22] <asac> http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/
[17:22] <asac> so in this case 4:20130903.3:20130903.2
[17:22] <asac> rather than 4:20130904:20130903.2
[17:22] <asac> so if i see a 4 tomorrow, i dont know which one that was
[17:22] <asac> (also, which parts were used to produce it)
[17:23] <asac> hope that makes some sense :)
[17:24] <lool> stgraber: why can't be always increase the daily-proposed version higher?
[17:24] <lool> stgraber: is this just because we have no place to track the latest id we used?
[17:24] <stgraber> we can re-generate the same long version number from what's in the daily channel
[17:24] <lool> stgraber: I mean, publish 4, 5, 6 etc. in daily-proposed, then promote 6 to daily
[17:24] <stgraber> lool: yes, currently import-cdimage always pick the next available version in the channel
[17:24] <lool> so that daily gets 4, then 6
[17:25] <lool> stgraber: so perhaps we would want to persist the highest daily-proposed number as to make sure we have unique numbers?
[17:25] <lool> stgraber: so that "4" is unambiguously referring to a triplet
[17:25] <lool> superseded or not
[17:25] <lool> or 5
[17:25] <stgraber> lool: that'll become possible in a couple of weeks with the new import-cdimage, but not now
[17:25] <stgraber> lool: that's what we discussed in the call yesterday
[17:26] <lool> stgraber: oh right
[17:26] <lool> stgraber: so that's fine
[17:26] <lool> asac: so in a couple of weeks it will even less confusing  ;-)  for now to understand what bits were in a version we'll need the actual triplet or look at the contents of the image in use
[17:26] <lool> asac: but that's only for daily-proposed; daily always has unique ids
[17:27] <asac> lool: i would really like to preserve the previous version
[17:27] <lool> asac: the previous version?
[17:27] <stgraber> lool: the main benefit I see in having unique version numbers for daily-proposed is that you'll be able to stay on that channel and update day to day (though always with full images in that case)
[17:27] <asac> lool: the version we had in staging
[17:27] <lool> stgraber: yup
[17:28] <lool> asac: yeah, just no deltas to it / from it though
[17:28] <asac> stgraber: can we just somehow preserve that version? like a cvs rev id that i can encode in an image version?
[17:28] <lool> asac: we will
[17:29] <stgraber> asac: we can always find the triplet for any image that's still available publicly on system-image.u.c, once it gets cleaned up, then there's no way of getting it back.
[17:30] <asac> lool: ok i lost everything you said in last few minutes
[17:30] <asac> my usb driver crashed
[17:30] <asac> :)
[17:30] <asac> no usb anymore
[17:30] <asac> odd
[17:45] <asac> ricmm: hey
[17:45] <asac> you are involved in the unity8 landing?
[17:47] <mhall119> the unity8 landing was staged
[17:47] <mhall119> :)
[17:48] <popey> You can tell by the shadows
[17:48] <asac> ricmm: so i would like to coordinate that landing with CI engineering a bit
[17:48] <asac> ricmm: can we have a meeting with you, someone from unity team and sil2100/Mirv?
[17:50] <Chocanto> mhall119: Hey ! :)
[17:51] <oSoMoN> boiko: CI failed for my MR, I’m seeing the following error in the logs: Error while loading page: file:///usr/share/messaging-app/MainPage.qml:23 module "Ubuntu.Contacts" is not installed
[17:51] <oSoMoN> boiko: any clue what the issue really is?
[17:51] <mhall119> hi Chocanto
[17:52] <Chocanto> mhall119: I just wanted to ask you about xdg-open and the docviewer, this task is Blocked in the blueprint since a long time and I forgot the reason, maybe you remember ?
[17:52] <boiko> oSoMoN: ah yes, that's new: it is probably missing a dependency, I can fix that one and retrigger your MR
[17:53] <lool> asac: who needs USB anyway
[17:53] <asac> plars: did we land the disable-intro
[17:54] <asac> plars: on touch_ro as well?
[17:54] <lool> asac: basically we will get unique ids soon
[17:54] <asac> lool: yeah... i am actually hoping to get PS/2 back :)
[17:54] <plars> asac: yes, it would only be needed one place
[17:54] <asac> plars: hmm. the webbrowser is still unhappy there
[17:54] <asac> plars: http://reports.qa.ubuntu.com/smokeng/saucy/image/3964/
[17:54] <asac> hmm. wait
[17:54] <asac> thats an old build :)
[17:54] <asac> nevermind
[17:54]  * asac thinks the versioning is hard :)
[17:55] <asac> plars: can you also give some love to the touch_ro things?
[17:55] <asac> plars: http://reports.qa.ubuntu.com/smokeng/saucy/image/3963/
[17:55] <asac> psivaa: ^^
[17:55] <oSoMoN> boiko: thanks
[17:55] <asac> would be cool to pay attention to those for the next couple days (until its the default)
[17:56] <psivaa> asac: ack, will do
[17:56] <asac> psivaa: from what i undersatnd those are on adifferent maguro/mako device?
[17:56] <plars> asac: I'm trying to, there are a lot of network problems still biting us
[17:56] <sergiusens> kenvandine: hey, can you trigger a daily release for phablet-tools?
[17:56] <plars> asac: not sure yet why on ro, and not on touch
[17:56] <asac> eg. we dont get in our way with the touch builds
[17:56] <asac> plars: we want to get rid of the wifi dependencies :)
[17:57] <asac> hehe
[17:57] <sergiusens> kenvandine: sil2100 told me he started one, but I don't see any results (2h+)
[17:57] <asac> j.k.
[17:57] <asac> though we surely want
[17:57] <psivaa> asac: yes, the ro ones are on different devices
[17:57] <asac> ok cool
[17:57] <plars> asac: yes, we know :)
[17:57] <asac> so it doesnt hurt if we poke around there too
[17:57] <mhall119> Chocanto: it required the implementation of the desktop services Qt API, which I believe was targetted to be done by end of last month
[17:57] <asac> lets do it
[17:57] <asac> plars: i thought it was almost fixed once :)
[17:57] <mhall119> pmcgowan: who was working on the desktop services API implementation?
[17:57] <asac> actually :(
[17:57] <ricmm> asac: what landing?
[17:57] <asac> ricmm: unity8
[17:57] <ricmm> what about it?
[17:58] <asac> ricmm: kgunn will send an invite tomorrow
[17:58] <Chocanto> mhall119: Oh ok, good. I was wondering because October is approching very fastly ^^
[17:58] <asac> ricmm: coordinating
[17:58] <asac> ricmm: when/how/what before/what after/what in case :)
[17:58] <mhall119> Chocanto: yeah, It is :)
[17:58] <pmcgowan> mhall119, do not recall anyone working on it - what were you looking for?
[17:58] <plars> asac: doanac had a change to phablet tools to do networking differently, but it was blocked, iirc he said it might be able to make some progress soon though (don't recall the details atm because I'm context switching from something else)
[17:58] <asac> ricmm: so all for now: don't land unity8 before that call :)
[17:58] <asac> thanks
[17:59] <pmcgowan> mhall119, is that for uri handling?
[17:59] <Chocanto> mhall119: Do you need something really important to be done on the docviewer on priority ?
[17:59] <ricmm> asac: its two prereq branches into qtubuntu and unity-mir
[17:59] <ricmm> and unity8 is one branch
[17:59] <mhall119> pmcgowan: yes
[17:59] <asac> ricmm: good. lets talk about that and make a landing plan together with CI folks etc. tomorrow
[17:59] <asac> ricmm: unless you know that one of the parts is super safe to not regress any tests
[17:59] <asac> :)
[17:59] <mhall119> Chocanto: has pinch zooming been done yet?
[18:00] <ricmm> I expect each landing to run its tests as they usually do
[18:00] <karni> Hi guys. Does anyone know if run_on_device script works? If not, is there an easy workaround to build and deploy unity8 onto a device?
[18:00] <pmcgowan> mhall119, Saviq but I think someone else picked it up, maybe kgunn knows
[18:00] <ricmm> either ways the branches arent up yet, we can talk bout it tomorrow with gerry if you want
[18:00] <ricmm> and daniel
[18:00] <ricmm> whos working on the unity8 branch
[18:01] <Chocanto> mhall119: Hum, no. I will get my Nexus 4 in the next week, and will develop the pinch zoom direclty on it. Even if you can test it, I can't really develop this functionnality to the blind
[18:01] <ricmm> the MRs are scheduled to be up tomorrow, we can discuss it after they have been tested
[18:02] <asac> ricmm: yeah lets talk
[18:02] <asac> ricmm: will be great :)
[18:02] <asac> ricmm: kgunn will send around an invite
[18:02] <mhall119> Chocanto: I think pinch zoom for images and pdf, and page navigation in PDF, are the big features to have done by 1.0
[18:02] <Chocanto> mhall119: I think too, and it will be done, but I'm kind of blocked for this week :/
[18:03] <plars> asac: maguro is finally getting passed install on touch_ro at least, I'd like to see again if I can reproduce what's going on there in a more isloated way, but need the jobs to finish up first
[18:03] <mhall119> blocked on us, or something else?
[18:03] <karni> mhall119: Hi Michael. Any hints (or perhaps person to point me at) about deploying unity8 onto Nexus 4?
[18:03] <plars> asac: both mako and maguro are currently running on touch_ro tests though
[18:03] <asac> plars: yeah. we can also move the job to a different maguro device
[18:03] <asac> plars: i bevelive tryuing a new device if something is flaki might be a valida approach
[18:03] <mhall119> karni: mzanetti can probably help you with that, join #ubuntu-unity
[18:03] <asac> plars: cool
[18:04] <karni> mhall119: thanks
[18:04] <mhall119> np
[18:04] <asac> plars: so lets see how much our results agree on both sides
[18:04] <asac> if we can get touch and touch_ro agree and go green
[18:04] <asac> we have a jackpot
[18:04] <plars> asac: that would be easy enough to try, but I don't think it's related to the device. Both mako and maguro are having issues with this
[18:04] <mhall119> karni: IIRC, you can just call run_on_device from the unity8 branch
[18:04] <asac> om26er: oSoMoN: friends fix was in-flight, right?
[18:04] <mhall119> karni: http://unity.ubuntu.com/getinvolved/development/unity8/
[18:04] <om26er> asac, inprogress
[18:05] <Chocanto> mhall119: Just blocked for the pinch zoom :)
[18:05] <karni> mhall119: Yes, thank you, I've been there. Popular belief (at least 2 other devs) is that run_on_device never worked, that's why I asked :)
[18:05] <asac> plars: ic ... and significantly more often than on rw?
[18:05] <mhall119> Chocanto: ah, need a device, I understand now
[18:05] <karni> If things have changed, that's great news.
[18:05] <plars> asac: ys
[18:05] <plars> yes
[18:05] <asac> plars: dont we put it in rw anyway?
[18:05] <asac> for running the tests?
[18:05] <plars> asac: yes, we do
[18:05]  * asac wonders what is different
[18:05] <mhall119> karni: it worked for me, granted that was about a month ago
[18:05] <Chocanto> mhall119: Yes :) I will get this device in few days, so it's good
[18:05] <karni> mhall119: perfect
[18:05] <asac> lool: did we ever try a file diff?
[18:05] <asac> on touch vs. touch_ro?
[18:05] <mhall119> Chocanto: cool
[18:05] <Chocanto> mhall119: I can develop the horizontal scroling for pdf
[18:05] <asac> lool: whats different? :)
[18:06] <ricmm> asac: kgunn I'd prefer if the call happens *after* the actual work is done (aka the MRs are up) tomorrows schedule is constrained and I dont want to block on early discussions
[18:06] <Chocanto> mhall119: But I don't think it's really the most important
[18:06] <ricmm> considering that by the time kgunn and I are up its already afternoon there
[18:06] <asac> ricmm: well, lets have a call before. it requires some up front on other sides as well
[18:06] <asac> so we cant star tright after
[18:06] <asac> ricmm: its really just about agreeing how this will happen and what we do before etc.
[18:06] <asac> ricmm: i am fine to have a late call
[18:07] <asac> though if you really feel not having 30 minutes helps you
[18:07] <asac> ricmm: so when do you anticipate landing? friday?
[18:07] <asac> ricmm: iw ould like to land when sil2100 and Mirv are up
[18:08] <plars> asac: are you specifically waiting on the 20130904.1 results to make a decision for touch_ro also? that's already running on maguro, but mako is still making it's way through the previous build
[18:08] <kenvandine> sergiusens, it built 2 hours ago, but we aren't publishing automatically right now
[18:09] <ricmm> asac: set up the call as best suits you, gerry kgunn sil2100/mirv me
[18:09] <asac> right
[18:09] <plars> asac: I can kill it if you like, but last time it took a long time before it was happy enough with the network to keep it going
[18:09] <asac> ricmm: thx. at best it will be short. just a standup before the landing :)
[18:09] <ricmm> not daniel
[18:09] <plars> asac: so unless you are waiting on it, I'd like to let it finish as much as possible on the previous build
[18:09] <asac> plars: i am not sure i am waiting on it... keep it running this time i guess... lets treat touch_ro thougth the same as touch in the coming days
[18:09] <asac> starting aftrer this buld
[18:10] <asac> we basically want to switch once we see the good results
[18:10] <asac> and then we can ignore touch :)
[18:10] <plars> asac: right
[18:10] <kgunn> ricmm: asac done
[18:10] <asac> thx kgunn
[18:10] <kgunn> racarr: ...meeting is kinda early, but it'd be nice if you could join for some mir-team representation
[18:12] <racarr> kgunn: Sounds like the social event of the season :)
[18:12] <racarr> ill be there
[18:13] <kenvandine> sergiusens, oh, it's because of a qtorganizer5-eds failure
[18:13] <kgunn> racarr: i'm titling it "burning man 2"....asac is going to perform some live performance art & ricardo is going to sing
[18:14] <om26er> kenvandine, please +1 this https://code.launchpad.net/~om26er/friends-app/fix-test/+merge/183944
[18:14] <om26er> *can you please :)
[18:14]  * kenvandine looks
[18:14] <sergiusens> kenvandine: thanks, we are waiting on that one, well stgraber is
[18:14] <sil2100> asac, ricmm: you know when I'm available usually, so just poke me by e-mail beforehand
[18:15] <racarr> kgunn: Sounds good :p
[18:15] <racarr> I have an image in my head now of burning a giant pile of nexus 4's
[18:15] <kgunn> :)
[18:16] <asac> kgunn: exactly
[18:16] <asac> :)
[18:16] <om26er> oSoMoN, seems I couldn't get my head around a few things with using SDK emulators, never really ported any app. So I proposed the branch to just change it to toolbar.opened
[18:17] <oSoMoN> om26er: link to the MR?
[18:17] <om26er> oSoMoN, don't worry I am working on porting to SDK emulators as well, just need a fresh mind
[18:17] <om26er> oSoMoN, https://code.launchpad.net/~om26er/friends-app/fix-test/+merge/183944
[18:17] <oSoMoN> om26er: sure, no worries, you might want to have a look at how gusch did it for the gallery app
[18:17] <om26er> oSoMoN, I do have preliminary things in place just need to poke around a few apps and see what they do
[18:17] <om26er> oSoMoN, right will do
[18:18] <oSoMoN> om26er: I also migrated the browser app and the calendar app, so those can serve as models too
[18:19] <asac> om26er: the notes-app is not your domain?
[18:19] <om26er> oSoMoN, i'll look at calculator as that the potential of being most simple
[18:19] <asac> http://reports.qa.ubuntu.com/smokeng/saucy/image/3966/notes-app-autopilot/
[18:20] <asac> oSoMoN: om26er: you think we should retry that notes-app test?
[18:20] <om26er> asac, It is, I am trying to run that test here first
[18:20] <asac> maguro seems to be not plagued by tthat
[18:20] <asac> om26er: thx
[18:20] <asac> rock
[18:21] <asac> balloons: did you give me a heads up on the core app test status this week? (sorry if i missed your reply)
[18:23] <mhall119> bzoltan: do we have any documentation/information for app developers using C++ and OpenGL that I can put on developer.ubuntu.com?
[18:26] <asac> om26er: so that friends app patch became necessary because of a uitk change, right?
[18:27] <om26er> asac, yep
[18:27] <asac> kk
[18:28] <kenvandine> sergiusens, built and published
[18:28] <sergiusens> kenvandine: thanks
[18:28] <kenvandine> np
[18:32] <beuno> jdstrand, we've deployed the update for file names, although it will only apply to uploads from today on
[18:32] <jdstrand> beuno: cool, thanks! :)
[18:38] <om26er> asac, I cannot break the test on the phone I tried on so I think a retry should pass us
[18:39] <asac> om26er: ok
[18:39] <asac> plars: retry :) ... notes
[18:40] <asac> on mako that is
[18:40] <asac> om26er: do you have mako>?
[18:40] <asac> maguro succeeds :)
[18:40] <om26er> asac, yeah I have mako but I tried blindly on a device in the lab with its serial number as identity
[18:40] <plars> asac: I did, it failed on the previous image (different failures it looks like) on mako also
[18:41] <om26er> tries mako
[18:41] <asac> plars: try again i guess
[18:41] <asac> different failures might indicate flakiness
[18:42] <penguincoder> i am having a heckuva time with my toro
[18:42] <asac> maybe even nasty in this case
[18:42] <stgraber> sergiusens: yay, phablet-tools finally got uploaded!
[18:42] <plars> asac: right, I did... it will start again as soon as the current test is done runnign
[18:43] <plars> calculator-app test is running atm I believe
[18:49] <om26er> they passed on mako as well :S
[18:50] <sergiusens> stgraber: I guess you are taking care of the pocket stuff, right?
[18:51] <stgraber> sergiusens: yep
[18:51] <jrei> someone here who could give me a hint on the nexus4 with ubuntu touch?
[18:51] <jrei>  i flashed cdimage-touch but i have no wifi or gsm data connection
[18:54] <JoshStrobl> Question I asked in #ubuntu-app-devel with no answer: can I use the Cordova APIs (for Ubuntu Touch) in the QML / JS implementation of applications?
[18:54] <JoshStrobl> I believe so, just figured I'd double check with someone that is more experienced in the field. Obviously it is usable in the HTML5 implementation that is still in the works.
[18:54] <Anze-> who knows how to set  ROOMSERVICE_BRANCHES global in breakfast
[18:54] <Anze-> ??
[19:11] <beuno> cjwatson, o/    is the     "lint_package_filename_pkgname_match": "'com.ubuntu.developer.majster-pl.ushopper-0.1.5' != 'com.ubuntu.developer.majster-pl.ushopper' from DEBIAN/control"
[19:11] <beuno> thing on your plate?
[19:11] <beuno> ah, this is the filename issue, but different, isn't it?
[19:13] <plars> asac: notes-app seems to pass ok on mako now, but I think it still might be worth looking at why it had random failures
[19:13] <asac> certainly
[19:13] <plars> one of the times it failed, the change for killing the intro was already in place
[19:13] <asac> thx
[19:14] <asac> so if nothing goes bad, and nothing big lands, we can be lucky and pick up omers fix for the next build
[19:14] <jrei> i just flashed the cdimage but wifi still doesn't ask for a password. Has anyone an idea?
[19:14] <asac> plars: guess tomorrow morning build will have that
[19:14] <asac> plars: anything else beyond friends that is still failing?
[19:15] <asac> plars: calendar app is odd
[19:15] <asac> had just 1 test run on yesterdays image byut was green
[19:18] <asac> plars: i am off for couple hours
[19:18] <asac> plars: psivaa started a spreadsheet recording all the "retries"
[19:18] <plars> asac: yeah, I'm restarting some of those
[19:18] <asac> maybe we can continue using that to start a database
[19:19] <asac> plars: more for later investigation
[19:19] <asac> statistics etc.
[19:19] <plars> yeah
[19:19] <asac> not sure if yo know where it is
[19:19] <asac> otherwise maybe note down todays retries
[19:19] <asac> and then record tomorrow in there
[19:19] <asac> ok later
[19:33] <jrei> ubuntu touch on nexus 4 feels like beeing back to openmoko. is there something else except https://wiki.ubuntu.com/Touch/Install what I should do to get wifi or 2G working?
[19:38] <stgraber> plars: new phablet-tools has landed in saucy. I'm doing a test flash now to confirm I get 2GB by default.
[19:39] <stgraber> plars: or not, it's completely broken...
[19:39] <stgraber> sergiusens: ping
[19:39] <plars> stgraber: :(
[19:39] <plars> stgraber: I'm on saucy too, so if we get a good one I can try it at home
[19:39] <plars> stgraber: the lab systems are not on saucy though
[19:39] <stgraber> sergiusens: When reviewing your branch I completely missed the fact that phablet-flash is python2 not python3
[19:39] <stgraber> sergiusens: lzma doesn't exist as a module in python2
[19:41] <stgraber> sergiusens: oh, actually it does but as a separate module
[19:41] <stgraber> sergiusens: so you're missing a python-lzma depend
[19:41] <AskUbuntu> Error when phablet-flash -b | http://askubuntu.com/q/341414
[19:42] <stgraber> plars: ok, so saucy's phablet-flash should be fine if you make sure you have python-lzma installed too
[19:43] <plars> stgraber: ah, ok
[19:43] <stgraber> sergiusens: http://askubuntu.com/q/341414 is the same problem
[19:43] <plars> stgraber: I do
[19:43] <cjwatson> beuno: yeah, that's the filename issue AFAIK in the app store, not on my end
[19:44] <sergiusens> stgraber: hmmm, it is in the mr
[19:44] <cjohnston> sergiusens: its as a build depends
[19:44] <stgraber> sergiusens: the build-depend is, not the runtime depend
[19:44] <sergiusens> stgraber: then I screwed up
[19:45] <sergiusens> stgraber: never wanted it to be a build dep
[19:45] <beuno> cjwatson, thanks
[19:46] <stgraber> sergiusens: does that also mean that Jenkins never actually runs the command? :)
[19:47] <sergiusens> stgraber: yeah, from the built package, it doesn't
[19:47] <cjohnston> stgraber: https://code.launchpad.net/~cjohnston/phablet-tools/lzma
[19:47] <sergiusens> cjohnston: create an MR
[19:47] <cjohnston> done
[19:47] <cjohnston> :-)
[19:48] <stgraber> good, land it!
[19:55] <AskUbuntu> Puedo instalar ubuntu touch en una tablet titan 7010me | http://askubuntu.com/q/341425
[19:55] <sergiusens> stgraber: cjohnston so it seems the test did cover this, python-lzma is needed as a build depend
[19:57] <sergiusens> cjohnston: can you add it back?
[19:58] <cjohnston> MR updated
[19:59] <cjohnston> sergiusens: ^
[20:01] <stgraber> sergiusens: well, the test must be wrong if it runs with the build-deps and not the runtime deps, but anyway, as long as it works, I don't really care :)
[20:02] <sergiusens> stgraber: well it's all unit
[20:03] <sergiusens> stgraber: might be good to add autopkg or similar
[20:07] <stgraber> plars: confirmed that we get 2GB using the curren phablet-flash
[20:07] <stgraber> plars: you mentioned Jenkins doesn't use saucy, where is ti taking its phablet-flash from?
[20:07] <plars> stgraber: ppa
[20:08] <sergiusens> stgraber: ppa:phablet-team/tools
[20:08] <stgraber> plars: which one?
[20:08] <stgraber> ok
[20:08] <plars> right
[20:08] <stgraber> ok, apparently the package gets uploaded there at the same time as the archive
[20:08] <stgraber> so once we get the one with the fixed dependency landed in the archive, it should start magically working on Jenkins too
[20:09] <lool> asac: file diff between ro and non-ro images?
[20:09] <lool> asac: dont think this would be too interesting, but there is a difference in the mount points (with the loop-mounted filesystems vs. subdirectories)
[20:10] <lool> asac, plars: Wow, the test pass rates are getting really good
[20:11] <stgraber> lool: so in case you didn't notice, we've got one more smallish issue with phablet-flash. I'm hoping to have this solved in the hour, then get QA to re-run some tests.
[20:11] <lool> stgraber: just read that
[20:12] <lool> stgraber: (thanks for mentioning it though as the traffic here is so high that I sometimes miss stuff)
[20:12] <lool> stgraber: do we know of tests that failed because of this?  like do we have a number?
[20:13] <stgraber> lool: because of what?
[20:13] <lool> stgraber: of the 2 GB vs. 1.2 GB
[20:13] <cjohnston> lool: seems like it would be nice at times to have a touch dev channel and a touch support channel.. make following conversations easier
[20:14] <stgraber> lool: my understanding was all of them since without that free space the tools wouldn't even install.
[20:14]  * plars checks
[20:14] <lool> stgraber: some tests did definitely pass  :-)
[20:14] <stgraber> lool: yeah, I saw that and found it a bit surprising :)
[20:14] <plars> at least one of the devices running touch_ro jobs...
[20:14] <plars> rootfs                        1.2G  1.1G   46M  96% /
[20:14] <sergiusens> cjohnston: at the begining ogra_ was pushing for all deve to happen on #ubuntu-devel
[20:15] <plars> stgraber: unconfirmed at the moment if any of the failures there are related to space, but we're a little tight on space there at the moment...
[20:15] <sergiusens> kenvandine: can you trigger another daily release of phablet-tools please?
[20:15] <cjohnston> devel at times is high enough traffic as is :-/
[20:15] <sergiusens> stgraber: cjohnston ^^
[20:15] <lool> sed: cannot rename /etc/default/sedA4Epno: Device or resource busy
[20:15] <plars> it's towards the end though,
[20:15] <lool> that seems like a test that needs updating for r/o
[20:15] <plars> lool: where was that?
[20:16] <lool> plars: first security failure on r/o
[20:16] <lool> not showing up on latest mako run
[20:16] <lool> http://reports.qa.ubuntu.com/smokeng/saucy/image/3963/security/340451/
[20:17] <lool> I'm checking out lp:utah hoping that's where it lives
[20:17] <plars> lool: strange...we are putting those in writable mode, so it shouldn't be because of an error writing anywhere
[20:17] <lool> this branch is pretty big though, and branching at 50kB/s for some reason
[20:18] <lool> plars: ultimately we want to fix the tests anyway, and the device or resource busy thing seems just wrong
[20:18] <kenvandine> sergiusens, building
[20:18] <plars> lool: indeed, jdstrand would probably be the one to talk to on that one
[20:18] <lool> plars: where's the code of check-ufw?
[20:18] <plars> jdstrand: http://reports.qa.ubuntu.com/smokeng/saucy/image/3963/security/340451/
[20:18] <jdstrand> qrt
[20:18] <jdstrand> lp:qa-regression-testing/tests
[20:19] <lool> branching lp:qa-regression-testing/tests: bzr: ERROR: Permission denied: "Cannot create 'tests'. Only Bazaar branches are allowed."
[20:19] <jdstrand> lp:qa-regression-testing/tests/image/privileged/check-ufw specifically
[20:19] <lool> bzr: ERROR: Permission denied: "Cannot create 'tests'. Only Bazaar branches are allowed."
[20:19] <jdstrand> lool: bzr branch lp:qa-regression-testing
[20:20] <lool> geez stupid me
[20:20] <jdstrand> lool: you can just grab the script if you want. there aren't any outside deps
[20:20] <plars> lool: part of qrt
[20:21] <jdstrand> lool: so I can fix the sed
[20:21] <jdstrand> lool: but the moddep errors are legitimate
[20:23] <lool> stgraber: could it be that depmod isn't allowed to run ever on / and so we're missing some moddep.bin files?
[20:23] <stgraber> lool: if that's the case, then it should be called during image build
[20:24] <stgraber> lool: ah no, it's simpler than that, our kernels don't have modules, so /lib/modules doesn't exist at all
[20:25] <lool> jdstrand: ^
[20:25] <lool> right, no /lib/modules on grouper either
[20:25] <stgraber> I'm a bit surprised that /lib/modules doesn't exist at all though
[20:25] <lool> now why does it pass on mako?
[20:25] <stgraber> I'd have expected it to be empty but not just plain missing
[20:25] <stgraber> no idea, I clearly have the same thing on mako
[20:26] <lool> sorry, I meant why does it pass with cdimage images?
[20:26] <stgraber> not sure, maybe something creates /lib/modules there
[20:26] <plars> balloons: have you seen http://reports.qa.ubuntu.com/smokeng/saucy/image/3963/calendar-app-autopilot/
[20:26] <lool> http://reports.qa.ubuntu.com/smokeng/saucy/image/3966/security/341006/
[20:26] <stgraber> I have code in the initrd that'd bind-mount /lib/modules to /system/lib/modules if the former existed
[20:26] <stgraber> which would make that test pass
[20:27] <stgraber> so the question is why don't we have /lib/modules in the image
[20:27] <balloons> plars, no I hadn't.. we were just working on calendar today
[20:28] <lool> stgraber: if there's no modules, that seems adequate?
[20:29] <stgraber> flipped does:     [ -e /lib/modules ] || ln -s /system/lib/modules /lib/modules
[20:29] <lool> aha
[20:30] <stgraber> so that explains why it's not a directory. Now for my images, it'd work better if it was, so I can add code to create it when repacking the image.
[20:31] <stgraber> (I prefer having it be a directory than a symlink since an empty directory is less likely to create havoc than a dangling symlink)
[20:31] <lool> ack
[20:32] <stgraber> fix pushed, next image should be fine
[20:32] <lool> stgraber: looking at the test, it seems best to keep it as is and mount / rw before running the test; do you have an idea of where the device busy comes from?
[20:32] <lool> The shell snippets are like:
[20:32] <lool> cp -a /etc/default/ufw /etc/default/ufw.image-test-backup
[20:32] <lool> sed -i 's/^DEFAULT_FORWARD_POLICY="DROP"/DEFAULT_FORWARD_POLICY="ACCEPT"/g' /etc/default/ufw
[20:32] <lool> so cp passes, but then sed fails
[20:33] <stgraber> lool: sed trying to be clever and create a temporary file
[20:34] <barry> stgraber: ping
[20:34] <lool> stgraber: https://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/tests/image/privileged/check-ufw
[20:35] <lool> stgraber: but the cp just above creates files in the same dir
[20:35] <stgraber> lool: and it's /etc/default/ufw that fails, right?
[20:35] <lool> stgraber: yes
[20:35] <plars> balloons: want me to file a bug for it? or did you want to?
[20:36] <lool> stgraber: ah that's bind-mounted
[20:36] <stgraber> lool: right, so it can't be moved
[20:36] <lool> crap
[20:37] <lool> stgraber: so it would be the same problem if we had used symlinks instead of bindmounts at least  :-)
[20:37] <stgraber> barry: pong
[20:37] <lool> well, it would have worked though
[20:37] <lool> but converting the symlink to a file
[20:37] <stgraber> lool: it'd have worked but gave you a mess instead
[20:37] <lool> yeah
[20:37] <stgraber> lool: IIRC it was one of my objections to symlinks, they may give you the impression of working when they really don't ;)
[20:37] <lool> haha
[20:38] <stgraber> lool: I wish sed had a "--really-do-it-in-place" which would just read everything into memory, do the replacement seek(0) and write
[20:38] <lool> stgraber: right
[20:38] <lool> stgraber: when turning on writable_image, we copy back the files into place. yes?
[20:39] <lool> I mean, this is happening with mount -o remount,rw but wouldn't happen with touch .writable_image + reboot?
[20:39] <stgraber> nope, we still have the bind-mounts when / is writable
[20:39] <lool> stgraber: shouldn't we reset the image back to a normal setup when turning that flag on?
[20:40] <jdstrand> lool, stgraber: so there is nothing for me to adjust for the sed?
[20:40] <lool> jdstrand: well you could avoid it
[20:41] <lool> jdstrand: I wonder how frequently we'll face such issues
[20:41] <jdstrand> I'm fine with changing it
[20:41] <lool> jdstrand: the workaround is to sed >tmpfile; cat tmpfile>/etc/default/...
[20:41] <jdstrand> yes
[20:41] <lool> jdstrand: because /etc/default/ufw is bind-mounted to a writable location
[20:41] <jdstrand> yes
[20:41] <jdstrand> (I did that :)
[20:41] <lool> thanks  :-)
[20:42] <jdstrand> ok, so I'll fix the sed
[20:42] <stgraber> lool: so, we could, except that it means the users would loose all their changes when swtiching back to read-only
[20:42] <kenvandine> sergiusens, published phablet-tools
[20:42] <lool> stgraber: might be something to keep in mind, it would also fix the use case of apt-get updating lxc-android-config
[20:43] <stgraber> lool: and that flip flopping quickly between both modes without changing anything would alter your rootfs and force you to reflash
[20:43] <lool> stgraber: we could copy the file back with some other command (or in system-image-cli)
[20:43] <sergiusens> stgraber: ^^
[20:43] <lool> kenvandine: ty
[20:43] <kenvandine> lool, np
[20:44] <stgraber> lool: not very easily since the actual list of bind-mounts is dynamic and generated by the initrd
[20:44] <lool> kenvandine: is that the one with the new dep?
[20:44]  * lool doesn't see it in LP yet
[20:44] <lool> I see one from an hour ago
[20:44] <kenvandine> it'll take a few minutes
[20:44] <lool> stgraber: well we have that list though
[20:45] <lool> kenvandine: ok thanks
[20:45] <kenvandine> https://launchpad.net/ubuntu/saucy/+source/phablet-tools/1.0+13.10.20130904.1-0ubuntu1
[20:45] <kenvandine> lool, ^^
[20:46] <stgraber> lool: to be honnest, I don't want to spend too much time working on developer mode just now, I've got a ton of higher priority things to keep myself busy with
[20:47] <lool> stgraber: sure, that's completely fair
[20:48] <lool> stgraber: let's keep this in mind if we run into other issues with bind-mounts that would be solved with such a feature
[20:48] <lool> plars, stgraber: The only other failure seems to be http://reports.qa.ubuntu.com/smokeng/saucy/image/3963/share-app-autopilot/
[20:48] <lool> plars: any idea why it didn't run?
[20:48] <lool> plars, stgraber: Sorry I meant the only other regression when compared to a mako run on non-ro images
[20:48] <plars> lool: yeah
[20:49] <plars> lool: networking problem... network never came up before it timed out
[20:49] <plars> lool: it happens, but is somewhat rare
[20:49] <plars> lool: I'll restart it
[20:49] <lool> thanks
[20:49] <plars> balloons: still around?
[20:49] <Anze-> who knows how to extract a cm10 build tree from update.zip to port ubuntu?
[20:49] <stgraber> new phablet-tools should be out in the next 30min
[20:49] <balloons> plars, indeed
[20:50] <lool> jdstrand: mind pinging here when you've updated check-ufw so that we can rerun the test?  (pass rate is the only thing holding ro images still :-)
[20:50] <stgraber> sergiusens: what triggers the push to the ppa?
[20:50] <jdstrand> lool: ping
[20:50] <plars> balloons: did you open a bug for the calendar issues? want me to?
[20:50] <sergiusens> stgraber: a ppa-sync tool
[20:50]  * lool sees lp:phablet-tools was automatically updated
[20:50] <jdstrand> :)
[20:50] <lool> jdstrand: 3>
[20:50] <jdstrand> lool: r1988
[20:50] <lool> jdstrand: ups, I meant  <3
[20:51] <balloons> plars, I can, if you'll link to it
[20:51] <jdstrand> hehe
[20:51] <plars> balloons: yep, just ping me with the number
[20:51] <lool> plars: what's needed to pull latest check-ufw?  is lp:qa-regression-testing bzr pulled on each build?
[20:51] <lool> plars: would be good to relaunch check-ufw now  :-)
[20:51] <plars> lool: yes, it is
[20:51] <plars> lool: ack
[20:52] <sergiusens> stgraber: http://10.97.2.10:8080/job/ppa-sync-phablet/654/console
[20:52] <stgraber> sergiusens: cool, looks like it's done
[20:53] <sergiusens> stgraber: yup... well it would be pending pub in the ppa most likely
[20:53] <plars> lool: I'll relaunch it on maguro, but not mako, mako is currently testing 4.1/4.1 and hasn't got to it yet
[20:53] <plars> lool: so it'll get there
[20:54] <balloons> plars, https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1220908
[20:56] <plars> balloons: thanks
[20:56] <lool> plars: phone-app-connected-autopilot shows up on the maguro report for touch_ro but not for touch
[20:56] <lool> with zero tests
[20:57] <plars> lool: yeah, it's supposed to be disabled right now
[20:57] <stgraber> plars: looks like new phablet-tools has published to the PPA, so would be great if you could re-test with that, see if more space helps
[20:58] <lool> plars: do we care about grouper still?
[20:58] <plars> lool: not at the moment
[20:58] <lool> plars: Ok; so I think we're in really good shape when comparing touch vs. touch_ro builds (only looked on mako and maguro though)
[20:58] <lool> asac: ^^^
[20:59] <lool> plars: did we miss other tests that didn't have time to run or some such?
[20:59] <plars> lool: mako is still fairly early on on the 4/4.1/4.1 build
[20:59] <plars> lool: we were letting it finish the previous one
[21:00] <stgraber> lool: 20130904.2 just finished building and will publish to system-image in a few minutes with hopefully a fixed /lib/modules
[21:00] <lool> plars, doanac: would you think you could compare the touch vs. touch_ro test passes for ubuntu=20130904.2 ?
[21:00] <lool> stgraber: cool
[21:01] <lool> hopefully phablet-tools + /lib/modules + the qa-regression-testing changes will have gotten us in a better place
[21:02] <plars> lool: I'll probably have to step away for a bit to take care of kids/bedtime, etc but I'll be back tonight and can take a look
[21:02] <lool> plars: who can I ping in the EU morning to get reruns?
[21:03] <plars> lool: psivaa
[21:03] <lool> plars: ok thanks!
[21:28] <plars> balloons: clock seems to have issues too http://reports.qa.ubuntu.com/smokeng/saucy/image/3966/ubuntu-clock-app-autopilot/
[21:29] <balloons> plars, ohh, I was waiting for clock.. I believe that should be the code that fixed things
[21:29] <balloons> i'll have to check the version and compare
[21:29] <plars> balloons: well, it passed on the .1 build from yesterday, but not since
[21:30] <plars> balloons: according to http://people.canonical.com/~ogra/touch-image-stats/20130903.2.changes we got an update at .2
[21:30] <plars> yesterday
[21:30] <plars> balloons: doesn't look like any changes landed since then
[21:32] <balloons> it should have landed yesterday
[21:32] <balloons> well that's dissappointing then
[21:33] <plars> balloons: it did, and appears to have broken things :)
[21:36] <stgraber> plars: 4.2 has published, can you make sure those tests will run with the latest phablet-tools?
[21:36] <plars> stgraber: let me check
[21:39] <plars> stgraber: maguro had already started, mako is lagging behind a bit so I'll restart maguro
[21:41] <rsalveti> xnox: I sent all the details about that cronjob (phablet.u.c export) via email, before I left for vacation (2,3 weeks ago)
[21:41] <rsalveti> xnox: and that I still had some stuff to be changed in there, and one is moving to a generic cron
[21:42] <rsalveti> xnox: but it's running daily currently
[22:11] <NedsFlam> Is ubuntu touch ready for the kindle fire yer?
[22:11] <NedsFlam> yet*
[22:26] <iBotPeaches> would failing to create "debugfs" dir prevent boot?
[22:27] <iBotPeaches> (in regard to last comment: http://ibotpeaches.com/last_kmsg), oppo find 5 trying to boot saucy
[22:32] <asac> rsalveti: hey
[22:32] <asac> rsalveti: sensorservice going wild again: http://reports.qa.ubuntu.com/smokeng/saucy/image/3973/webbrowser-app-autopilot/341924/
[22:32] <asac> interestingly enough this problem disappeared after the test was run :)
[22:33] <asac> rsalveti: http://reports.qa.ubuntu.com/smokeng/saucy/image/3973/webbrowser-app-autopilot/
[22:33] <asac> plars: guess thats a retry after logging it with a comment "sensorservice looping"
[22:33] <asac> in the spreadsheet
[22:33] <asac> lool: right. so tomorrow - once i see friends fixed - i will promote stuff to current and we can move our default to touch_ro (if things continue as they are_)
[22:34] <asac> lool: http://reports.qa.ubuntu.com/smokeng/saucy/image/3963/security/
[22:34] <rsalveti> asac: is this the default image or the mir one?
[22:34] <rsalveti> I/ServiceManager(  759): Waiting for service SurfaceFlinger...
[22:34] <asac> http://reports.qa.ubuntu.com/smokeng/saucy/image/3963/
[22:34] <rsalveti> doesn't make any sense
[22:34] <asac> rsalveti: default
[22:35] <asac> as i said ... i find it also "less sensible" that the problem disappears during our test run :)
[22:35] <stgraber> lool: hmm, security is still failing on 04.2, flashing that one now to see what's going on
[22:36] <asac> yeah thats odd
[22:36] <asac> would like to hear a story about that one
[22:37] <rsalveti> the sensor should probably be a race, I'm testing the upstart-bridge here to better handle the android init events
[22:37] <rsalveti> hopefully that should be enough
[22:37] <asac> rsalveti: yeah, but that race seems to starve after a while ... :)
[22:37]  * asac checks if there is a crash report attached
[22:37] <asac> might be an explanation why it stopped if the service crashed in the end
[22:37] <rsalveti> well, it's quite weird that logcat is waiting for surfaceflinger
[22:37] <rsalveti> that shouldn't happen
[22:38] <rsalveti> unless it crashed hard when starting, but then the test would fail
[22:38] <asac> no crash file that i can see
[22:38] <asac> so seems it stopped "properly"
[22:39] <asac> rsalveti: how would you explain sensorservice going rogue in the "race" caase?
[22:40] <rsalveti> something trying to use the mako sensorservice before it's fully up
[22:40] <rsalveti> that's something we can still hit
[22:40] <asac> and our code is buggy and loops on some odd fds?
[22:40] <asac> guess something polling on not-yet-ready fds?
[22:41] <asac> is that the explain?
[22:41] <asac> :)
[22:41] <rsalveti> not our code, this is the proprietary service from qcom
[22:41] <rsalveti> we might be breaking it somehow
[22:41] <rsalveti> I'll dig a bit further
[22:44] <asac> rsalveti: related question: is there more info that automation could give you to ease debugging such runaway processes?
[22:45] <asac> rsalveti: i think we already have quiet a few logs etc.
[22:45] <asac> but looking for ideas whatelse to capture that makes some sense (and how to prepare the data so its consumable)
[22:46] <asac> plars: is http://reports.qa.ubuntu.com/smokeng/saucy/image/3972/ a recurring issue?
[22:46] <asac> something that goes away with retry?
[22:46] <asac> camera-app that is
[22:49] <stgraber> lool, plars: apparently I lost a race by a couple of minutes when landing the /lib/modules fix earlier... re-spinning an image now which should really include it this time
[22:52] <jdstrand> stgraber: seems like the sed fix in check-ufw didn't make it either. hopefully the respin will include it
[22:52] <jdstrand> or rather, the test run will include it
[22:55] <rsalveti> asac: what we have there seems to be enough
[22:56] <stgraber> plars: any idea why jdstrand's change to qrt didn't get pulled in?
[22:56] <asac> rsalveti: cool
[23:02] <plars> asac: the .crash file you mean?
[23:03] <jdstrand> thomi, doanac: ok, since you an email on autopilot/apparmor/etc
[23:03] <asac> plars: i think i was talking about calendar app ... not camera
[23:03] <plars> asac: no, calendar app has a bug on it (see previous runs) I just haven't had a chance to tag this one yet
[23:04] <jdstrand> thomi, doanac: it should be self-explanatory, but I'm heading out now. ping me if you have questions
[23:04] <asac> plars: kk
[23:04] <asac> thanks
[23:04] <plars> asac: there's a mediaserver crash that happened during camera app run though which is interesting
[23:04] <thomi> jdstrand: thanks!
[23:04] <asac> plars: was it ever better? thats a core app, right?
[23:04] <jdstrand> s/since/sent/
[23:04] <asac> plars: yeah interestingly enough... just spotted it
[23:04] <asac> didnt see the crash column before
[23:04] <jdstrand> thomi: sure thing
[23:04] <plars> asac: looks like webbrowser tests failed again on mako too
[23:05] <asac> will remember to check that. maybe visualization could be better in highlighting those cases
[23:05] <asac> plars: same way?
[23:05] <thomi> doanac: I'm unlikely to get to this today, and I'm on conference leave tomorrow, are you able to have a look at that for me?
[23:05] <asac> plars: yeah "just" one
[23:06] <asac> plars: oh thats the systemsettle problem i was talking to rsalveti about
[23:06] <jdstrand> thomi: note, this is pretty click specific, but click packages are the only ones that have mandatory confinement, so I think we're good. the technique is useful otherwise though and we could come up with something similar for non-click if needed
[23:06] <asac> its interestingL: sensorservice is going wild before, but somehow our testrun cures that problem :)
[23:06] <asac> plars: rsalveti wanted to look at that ... i guess for its a good retry
[23:06] <thomi> cool
[23:07] <plars> touch_ro for 04.2 is finally starting on mako
[23:07] <plars> asac: clock seems to have a bug with it too, I pinged balloons about it earlier
[23:10] <plars> stgraber, jdstrand: security tests haven't run yet for the 04.2 image yet - wait :)
[23:10] <plars> ok, tagged some known things and restarted some things that needed it... I'll be back later to check on things again
[23:14] <xnox> rsalveti: I see. I didn't see that email and it seemed like neither did stgraber. Where was it sent to? I think we worked it out in the end. Thanks for documenting it, and sorry we failed to find that =)
[23:14] <stgraber> xnox, rsalveti: reverse engineering is way more fun than following instructions anyway ;)
[23:15] <rsalveti> haha, yeah :-)
[23:15] <xnox> =))))
[23:15] <rsalveti> xnox: subject: Phablet export for the Android package
[23:17] <xnox> rsalveti: ha, I am left with no excuses, i even have it marked as read. Hm. somehow I forgot about it.
[23:18] <asac> plars: ok ... i will continue tomorrow morning with psivaa
[23:18] <rsalveti> xnox: no worries
[23:18] <asac> on the next image that hopefully has friends-app fixed as well
[23:19] <plars> asac: I'll be back later too... things are running right now, and not much more I can do until some more time passes
[23:20] <rsalveti> bbl, dinner
[23:34] <RobbyF> lol I just flashed and 30 seconds later a new build
[23:38] <doanac> jdstrand, thomi: just looking at the email. I can take a look at this tonight if someone can tell me what needs to go in the rules file
[23:57] <riddlebox-t530> does ubuntu touch support 4G in the US?