15:03 <slangasek> #startmeeting
15:03 <meetingology> Meeting started Wed Jul 17 15:03:42 2013 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
15:03 <meetingology> 
15:03 <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
15:03 <slangasek> [TOPIC] Lightning round
15:04 <slangasek> $ echo $(shuf -e barry doko stgraber jodh ev bdmurray slangasek cjwatson xnox stokachu)
15:04 <slangasek> stgraber slangasek doko stokachu xnox jodh barry ev cjwatson bdmurray
15:04 <slangasek> stgraber: you're up :)
15:06 * stgraber waves
15:06 <stgraber> slangasek: sorry, just finished typing :)
15:06 <stgraber> Blueprint-related work:
15:06 <stgraber> - Image based updates (BLUEPRINT: foundations-1305-image-based-updates)
15:06 <stgraber> - Landed a new version of the upgrader, that's now feature complete (does GPG checking)
15:06 <stgraber> - Worked on some code to make mark-current add a stamp file in the cdimage build directories for import-cdimage to parse
15:06 <stgraber> - Added code to generate a system-image configuration file at boot time
15:06 <stgraber> - Fixed a few subtile bugs in import-cdimage causing broken upgrade paths when some files are identical to the previous build
15:06 <stgraber> - Did a test backport and raised RT to get pxz and android-tools in precise-cat
15:06 <stgraber> Other work:
15:06 <stgraber> - LXC
15:06 <stgraber> - Linux Plumbers mini-conference preparation
15:06 <stgraber> - Some tweaks to lxc-start-ephemeral and the python binding
15:06 <stgraber> - Poked the security team about the MIR
15:06 <stgraber> - Usual code reviews
15:06 <stgraber> - Network
15:06 <stgraber> - Uploaded a new openvpn now that we have iproute2
15:07 <stgraber> - Helped doko figure out why isc-dhcp was broken after his merge
15:07 <stgraber> - Other
15:07 <stgraber> - Some shim testing
15:07 <stgraber> 
15:07 <stgraber> TODO:
15:07 <stgraber> - THIS WEEK: Get all UEFI systems to install and boot shim-signed (even when not running under secureboot)
15:07 <stgraber> - THIS WEEK: Figure out the needed changes to run the phablet test suite on readonly images
15:07 <stgraber> - THIS WEEK: Add an option to phablet-flash to bootstrap an image based system
15:07 <stgraber> - THIS WEEK: Land the mark-current change on cdimage and apply matching change to import-cdimage
15:07 <stgraber> - THIS WEEK: Update pack-system to include the recovery partition image (not ideal but better than not updating it at all)
15:07 <stgraber> 
15:07 <stgraber> TRAVEL/VACATION:
15:07 <stgraber> - NEXT WEEK: I'll be in London all week for the release engineering sprint
15:07 <stgraber> - WEEK AFTER: I'll be on vacation, only working on the 2nd of August (Friday)
15:07 <stgraber> - WEEK AFTER that: I'll be on vacation Monday-Wednesday, working on Thursday (8th) and Friday (9th)
15:07 <stgraber> - WEEK AFTER that: I'll be at Debconf2013 all week
15:07 <stgraber> - => back to normal on the 21st of August
15:07 <stgraber> - => as a result of all that, I'll be missing the next 4 team meetings
15:07 <stgraber> 
15:07 <stgraber> (DONE)
15:07 <ev> oh hai (pickup time got moved)
15:09 <slangasek> stgraber: is your android-tools precise-cat backport any different from the one in the ubuntu sdk ppa (besides version #)?
15:10 <stgraber> slangasek: probably not, I asked IS for a clean backport from precise (I tested it with backportpackage)
15:10 <slangasek> ev: hey there!
15:10 <stgraber> slangasek: I really just need simg2img on nusakan (currently using a local copy which isn't ideal)
15:10 <slangasek> stgraber: right
15:10 <slangasek> * prep for client sprint on IoM (in two weeks)
15:10 <slangasek> * lots of internal meetings
15:10 <slangasek> * following up on arm64 bootstrap
15:10 <slangasek> * broke unity builds over the weekend by getting rid of unity-common; this led to a renewed discussion about getting all our Ubuntu Touch packages out of ppas and into the archive, the deadline is now end of month
15:10 <slangasek> * still working on parted this week
15:10 <slangasek> * still working on shim in the lead-up to 12.04.3
15:10 <slangasek> (done)
15:10 <slangasek> doko: your turn
15:11 <xnox> stgraber: pxz currently segfaults for me on android.tar  bug 1199895, which is simply possibly bug 1096782
15:11 <ubottu> bug 1199895 in pxz (Ubuntu) "pxz crashed with SIGSEGV in _IO_vsnprintf()" [Undecided,New] https://launchpad.net/bugs/1199895
15:11 <ubottu> bug 1096782 in pxz (Ubuntu) "pxz do not handle >4GB size files" [Undecided,New] https://launchpad.net/bugs/1096782
15:11 <xnox> would we be affected?
15:11 <doko> - Linaro Connect last week
15:11 <doko> - gcc-4.7 C++11 bug fix backported
15:11 <doko> - gcc-4.7 Linaro release and upload
15:11 <doko> - still trying to sort out network setup for the arm64 bootstrap
15:11 <doko> - arm64 bootstrap, starting with languages, ruby, lua done, working on php, guile
15:11 <doko> (done)
15:12 <stokachu> just one bug this week: bug 1199037 - spent the better part of the week learning juju and deploying some internal applications
15:12 <ubottu> bug 1199037 in python-eventlet (Ubuntu Raring) "backport eventlet exception context fix" [Undecided,In progress] https://launchpad.net/bugs/1199037
15:12 <stokachu> done
15:12 <stgraber> xnox: ah, haven't had any problem with my delta or rootfs tarballs so far
15:13 <stgraber> xnox: I'm certainly not affected by the >4GB one, not sure about the other
15:14 <xnox> bah, me!
15:14 <xnox> * upstart code review
15:14 <xnox> * upstart 1.9.1 upload into saucy
15:14 <xnox> * sru on hold, pending resolution of bug 1199778
15:14 <xnox> * android build:
15:14 <xnox> - <<100MB source package now (dropped chromium, multiple copies of
15:14 <xnox> stdc++ libraries, all prebuilt binaries, tools and not-needed files.
15:14 <ubottu> bug 1199778 in upstart (Ubuntu) "upstart crashes if re-exec'ed with active chroot sessions" [High,In progress] https://launchpad.net/bugs/1199778
15:14 <xnox> - split out vendor blobs into a separate src&binary package (it's
15:14 <xnox> not going to change)
15:14 <xnox> - should be relatively straight forward to make a copyright file for
15:14 <xnox> and upload into the archive. Will need security team review of
15:14 <xnox> embedded copies of code and if/which need CVE tracking (agreed with
15:14 <xnox> security team)
15:14 <xnox> - refresh toolchain against doko's gcc-4.7 upload, dropped binutils patches.
15:14 <xnox> * Plumbers/LinuxCon upstart talk accepted by james and myself. \o/
15:14 <xnox> * this week:
15:14 <xnox> - push out updated upstart SRU
15:14 <xnox> - finish up with android build and upload into the archive
15:14 <xnox> - thus moving on to QML/OOBE app for next week
15:14 <xnox> ..
15:14 <jodh> * foundations-1305-upstart-app-launching:
15:14 <jodh> - libupstart now in the archive.
15:14 <jodh> * foundations-1305-upstart-work-items:
15:14 <jodh> - upstart-dconf-bridge: Progress on reacting to jobs being
15:14 <jodh> added/removed (slow as we have to use GDBusProxy rather than the
15:14 <jodh> usual NIH routines).
15:14 <jodh> * upstart
15:15 <jodh> - Spent last few days working on the best fix for bug 1199778.
15:15 <jodh> - Wrote 2 new tests and resubmitted the MP:
15:15 <jodh> https://code.launchpad.net/~jamesodhunt/upstart/bug-1199778/+merge/174138
15:15 <jodh> - "Android event bridge" (more details to follow at the end of the meeting).
15:15 <jodh> - worked on the host side (currently called upstart-text-bridge, but
15:15 <jodh> really needs a better name! :-)
15:15 <jodh> - Started to look at the Android side (which will be heavily
15:15 <jodh> influenced by 'watchprops').
15:15 <jodh> * TODO
15:15 <jodh> - Aside from the unfinished items above, work on getting some
15:15 <jodh> DEP-8 integration tests running for Upstart (which will result in
15:15 <jodh> the python module getting merged for Upstart testing only).
15:15 <jodh>15:15 <barry> image updater: LP: #1199498, LP: #1199488, LP: #1199981, LP: #1199986, LP: #1199982, LP: #1195420, LP: #1195479, LP: #1200981.  meetings.  upload versions 0.3-0.6
15:15 <ubottu> Launchpad bug 1199498 in Ubuntu system image "Update client for updated ubuntu_command format" [High,Fix released] https://launchpad.net/bugs/1199498
15:15 <ubottu> Launchpad bug 1199488 in Ubuntu system image "Include the archive-master keyring in system-image-common" [High,Fix released] https://launchpad.net/bugs/1199488
15:15 <ubottu> Launchpad bug 1199981 in Ubuntu system image "Reboot class is missing reboot() method override" [Critical,Fix released] https://launchpad.net/bugs/1199981
15:15 <ubottu> Launchpad bug 1199986 in Ubuntu system image "Fix ubuntu_command file ordering" [Critical,Fix released] https://launchpad.net/bugs/1199986
15:15 <ubottu> Launchpad bug 1199982 in Ubuntu system image "/var/lib/system-image must be present in packaging" [Critical,Fix released] https://launchpad.net/bugs/1199982
15:16 <barry> d/l service: discussions/status with mandel.  need to do more on this asap, with click package and upgrader client integration.
15:16 <barry> other: work to eliminate configparser as configglue dep.  discussions w/configparser upstream about various problems we encountered.  tox 1.5.0 (debian bug 702009), codespeak-lib 1.4.15 (with pull request in debian to re-enable dep8 tests, and debian bug 678398).  python bug 18440 (hash() truncates __hash__() to machine bit width).  syncpackage codespeak-lib (failed).  syncpackage tox.
15:16 <ubottu> Debian bug 702009 in tox "tox: Upgrade tox to 1.4.3" [Normal,Fixed] http://bugs.debian.org/702009
15:16 <ubottu> Debian bug 678398 in codespeak-lib "codespeak-lib: Enable test suite (as DEP-8 tests)" [Normal,Open] http://bugs.debian.org/678398
15:16 <ubottu> bug 18440 in xorg (Ubuntu) "xserver-xorg 6.8.2-32: xv is corrupted for some video sizes" [Medium,Fix released] https://launchpad.net/bugs/18440
15:16 <barry> this week: working furiously on LP: #1192585, leading to work on minimal ui.
15:16 <ubottu> Launchpad bug 1192585 in Ubuntu system image "Add a dbus API" [High,In progress] https://launchpad.net/bugs/1192585
15:16 <barry> 𝄢
15:16 <slangasek> jodh: why "text" bridge? :)
15:17 <ev> I guess I'll paste here again so the logs have it
15:17 <ev> This week has again been focused on the Cassandra move into Prodstack.
15:17 <ev> We've finally gotten past the hurdles around the initial repair of
15:17 <ev> etcassandra/0 and are currently up to etcassandra/3 (we need a minimum
15:17 <ev> of six nodes built to have at least one copy of all the data).
15:17 <ev> James Troup and I had some very productive discussions with the folk
15:17 <ev> at DataStax and Acunu for a support contract, and possibly to have
15:17 <ev> Acunu Analytics handle top-k for errors.ubuntu.com.
15:17 <ev> I'm exercising Analytics in canonistack as preparation for getting it
15:17 <ev> turned on in production to demo it with real world data. More on that
15:17 <ev> soon.
15:17 <ev> I've also been working on getting automatic error reporting set for
15:17 <ev> the server and mobile (building the settings UI, teaching apport to be
15:17 <ev> quiet, etc). I'm going to be optimistic and say that we'll have
15:17 <ev> automatic error reporting turned on for the phone by the end of the
15:17 <ev> week.
15:17 <ev> While waiting for g++ to melt my CPU, I've been porting our pyjuju
15:17 <ev> deployment code over to gojuju.
15:17 <ev> done
15:17 <cjwatson> foundations-1305-click-package:
15:17 <cjwatson> - Wrote a PackageKit plugin for click.
15:17 <cjwatson> - Added a "click list" command, hooked into PK.
15:17 <cjwatson> - Some work to make things build on precise.
15:17 <cjwatson> - Refactoring hooks design to meet needs of AppArmor and desktop file handling.  Aiming to finish this by end of week.
15:17 <cjwatson> - Preparation for demo at end of month.
15:17 <cjwatson> Yet more Apache 2.4 / PHP 5.5 transition madness.
15:17 <cjwatson> Made net-retriever's deduplication code lots faster for large Packages files (bug 1067934).
15:17 <ubottu> bug 1067934 in net-retriever (Ubuntu Raring) "spends 10+ minutes deduplicating Package lists" [High,In progress] https://launchpad.net/bugs/1067934
15:18 <jodh> slangasek: just "because" :) As I say, better names welcome. I don't want to call it the upstart-android-bridge though.
15:18 <cjwatson> Filed RT#63122 for a new host for offloaded archive jobs.
15:18 <cjwatson> ..
15:18 <bdmurray> submitted RT #63071 regarding updating errors and daisy
15:18 <bdmurray> tested deployment of new version of errors and daisy
15:18 <bdmurray> resolved an OOPS in errors (writing to bugtocrashsignature) when creating a bug in Launchpad
15:18 <bdmurray> tested update-notifier crash notification change (using MATCH instead of FILE)
15:18 <bdmurray> uploaded update-notifier to saucy with a new version of the crash notification
15:18 <bdmurray> uploaded update-notifier fixing LP: #1200044
15:18 <ubottu> Launchpad bug 1200044 in update-notifier (Ubuntu) "update-motd-updates-available wastes 1 second on every login by forking hundreds of /usr/bin/stat" [Medium,Fix released] https://launchpad.net/bugs/1200044
15:19 <bdmurray> investigation into and fix for bug LP: #1200135
15:19 <bdmurray> uploaded R SRU of fix for bug LP: #1199157 (verified it too)
15:19 <bdmurray> modified ubuntu-release-upgrader not to use GObject.threads_init()
15:19 <bdmurray> SRU verification of LP: #1078697
15:19 <bdmurray> research into sessioninstaller / dbus-python LP: #771404
15:19 <ubottu> Launchpad bug 1200135 in ubuntu-release-upgrader (Ubuntu) "Raring to saucy upgrade fails with "AttributeError: Values instance has no attribute 'devel_release'"" [High,Fix released] https://launchpad.net/bugs/1200135
15:19 <ubottu> Launchpad bug 1199157 in ubuntu-release-upgrader (Ubuntu Raring) "proposed should be disabled on upgrade to development release" [Medium,Fix committed] https://launchpad.net/bugs/1199157
15:19 <ubottu> Launchpad bug 1078697 in apt (Ubuntu Lucid) "Ubuntu archive is missing SHA-1/SHA-256 hashes for some packages" [High,Triaged] https://launchpad.net/bugs/1078697
15:19 <ubottu> Launchpad bug 771404 in dbus-python (Ubuntu) "aptd crashed with UnicodeEncodeError in _method_reply_error(): 'ascii' codec can't encode characters in position 20-28: ordinal not in range(128)" [Medium,Confirmed] https://launchpad.net/bugs/771404
15:19 <bdmurray> modified bugbot to subscribe me to regression bugs (from proposed) w/o an SRU bug
15:19 <bdmurray> package to team mapping work
15:19 <bdmurray> created a csv file of the package to team mapping for the current teams we are using in LP
15:19 <bdmurray> review of packages added to seeds in raring
15:19 <bdmurray>15:19 <bdmurray> wrote a tool to query the archive to find unsubscribed packages
15:19 <cjwatson> Oh, I forgot to mention, I also got the fix for bug 1192286 verified - it's awaiting the next nodowntime deployment now
15:19 <ubottu> bug 1192286 in Launchpad itself "Allow phased update percentage to be set when copying a package" [High,Fix committed] https://launchpad.net/bugs/1192286
15:20 <bdmurray> cjwatson: thanks!
15:22 <bdmurray> I'm done if that was not clear
15:23 <slangasek> \o/
15:23 <slangasek> [TOPIC] AOB
15:23 <slangasek> anything else?
15:23 <stokachu> could i get an ack on bug 1199037
15:23 <xnox> jodh: bionic-upstart-bridge (on android side) upstart-bionic-bridge (on host/ubuntu side)
15:23 <ubottu> bug 1199037 in python-eventlet (Ubuntu Raring) "backport eventlet exception context fix" [Undecided,In progress] https://launchpad.net/bugs/1199037
15:23 <stokachu> could i please*
15:24 <slangasek> stokachu: "ack" :-)
15:24 <stokachu> slangasek: thank you! :D
15:24 <slangasek> stokachu: is it waiting for sponsorship or SRU queue approval?
15:24 <jodh> xnox: I'd rather not make any reference to android/bionic on the host side as the bridge is generic.
15:24 <stokachu> slangasek: theyve linked the related branch and i dont believe its been uploaded yet
15:24 <bdmurray> I'll be on holiday from the 22nd to the 31st.
15:25 <bdmurray> stokachu: it looks to me like it needed some minor fixing
15:25 <slangasek> bdmurray: can you follow up on it?
15:26 <stokachu> bdmurray: would you mind commenting and ill work with the engineer to get it in shape
15:26 <stokachu> i need to write a lint tool or something for these outside requests
15:26 <bdmurray> sure, I'll comment and watch for fixes
15:26 <stokachu> bdmurray: thanks man i appreciate it
15:27 <slangasek> [TOPIC] upstart and android
15:28 <slangasek> so today's in-depth topic is the upstart android bridge jodh is working on
15:28 <slangasek> timely and topical!
15:28 * slangasek yields the floor to jodh
15:28 <jodh> slangasek: thanks.
15:28 <jodh> you may have noticed that as of Monday the touch images are now running a Session Init.
15:29 <jodh> All the android bits are now running in the android lxc container.
15:29 <jodh> The issue this bridge is trying to solve though is that upstart services on the host side (ubuntu) need to know when specific android services in the container are "ready".
15:30 <jodh> I outlined this in a post recently to ubuntu-devel: https://lists.ubuntu.com/archives/ubuntu-devel/2013-July/037469.html
15:30 <jodh> Currently, some of the session jobs are using heuristics (ahem) to determine when certain android services are available but they are not reliable.
15:30 <slangasek> heuristics like "sleep", I believe ;)
15:30 <jodh> slangasek: right :(
15:31 <slangasek> and I think the ofono job is also respawning messily when the rild socket comes and goes
15:31 <jodh> so what this bridge needs to do is somehow detect when android services are ready and create an upstart event that jobs on the host side (potentially system and session I think?) can make use of.
15:31 <jodh> slangasek and I are not terribly happy with the design as it stands so if anyone knows a better way speak up.
15:32 <jodh> The plan currently though is to:
15:32 <jodh> - create an *android* service that runs in early android boot (that is to say some time after the lxc container starts).
15:33 <jodh> this service will run before any other android service and will "hook" into the service manager facility provided by android init (basically a block of shared-memory it updates when things change).
15:33 <jodh> this service will also attempt to connect to an already-running bridge on the host side and squirt name=value pairs over the wire.
15:33 <jodh> the bridge on the host side will then emit upstart events like 'android-service $name=$value'.
15:34 <slangasek> so from what rsalveti had said, I thought the plan on the android side was simpler than that... I thought they were modifying android init to dump the android service states over a socket
15:34 * rsalveti checks backlog
15:34 <jodh> well, that was the original idea, but we don't need to modify androids init as it already provides this shared-memory facility (used by getprops/watchprops/etc).
15:35 <rsalveti> slangasek: yeah, the additional service will be quite small, so don't need to change the init itself
15:35 <slangasek> ok
15:35 <jodh> so, on the host side, jobs should eventually be able to specify things like:
15:35 <stgraber> jodh: I'm assuming the actual exchange between host and container is a socket created by the bridge on the host that's bind-mounted into the container?
15:35 <rsalveti> but it'll be called when starting init
15:35 <jodh> start on :sys:android-property init.svc.ueventd=running
15:35 <jodh> when the ueventd (androids version of udev) daemon is running.
15:36 <slangasek> why would it be bind mounted instead of using an abstract socket?
15:36 <jodh> stgraber: yes, the host side will create the socket. I might need your help on the bind-mounting of it though :)
15:36 <slangasek> you shouldn't need to bind mount anything
15:36 <stgraber> slangasek: we tend to prefer bind-mounts of real socket vs abstract socket because if we ever choose to use a separate netns for the container, access to abstract sockets won't be possible (as they'd live in different namespaces)
15:36 <jodh> we could use a real socket but security might be a concern.
15:37 <rsalveti> yeah
15:37 <stgraber> slangasek: the kernel has explicit logic in it for bind-mounted sockets to be accessible across namespaces so it's the preferred way of doing things
15:37 <slangasek> stgraber: I can see that being desirable for containers generally, but we're already relying on abstract sockets for Touch
15:38 <slangasek> and upstart makes heavy use of abstract sockets throughout - so I don't see the advantage of bind mounting
15:38 <stgraber> slangasek: ok, I guess if we already really on access to Android abstract sockets from Ubuntu, then it won't make things much worse (and it's not terribly likely we'll turn on the netns for the Android container any time soon anyway)
15:38 <rsalveti> jodh: do you know when you'll get enough time to start the implementation there? just so I can sync it with some other changes I'm doing in the android side
15:40 <jodh> rsalveti: I need to discuss with slangasek before committing to timings. As mentioned, I've got a basic bridge on the host side and have been sniffing around bionic (somewhat misnamed perhaps? :-) to see how much effort it will be for me to write the android side. Oh and learning the Android.mk bits.
15:40 <slangasek> rsalveti: so I've asked jodh to address autopkgtest of upstart first before doing any more feature work; I'd assume that puts the android bridge at least 2 weeks out
15:40 <rsalveti> slangasek: jodh: right, ok, as this will be a major improvement :-) should fix all the races we're having in there
15:41 <slangasek> jodh: so what are the bits of the design that you're not happy with currently?
15:42 <slangasek> rsalveti: and the plan is still to make ueventd a "run-once" service in the android container?
15:42 <jodh> well, I was hoping we could somehow make the android service manager accessible to the host to allow a single application to handle the injection of the events.
15:42 <rsalveti> jodh: I can set up the git repo and a stub in there (with a stub .c/Android.mk) if that helps you
15:42 <jodh> rsalveti: great - thanks!
15:42 <rsalveti> slangasek: yes
15:42 <rsalveti> slangasek: we'll get a init.svc.ueventd stopped
15:43 <slangasek> jodh: ah, so you don't like having to run a daemon both in the host and in the container?
15:43 <slangasek> rsalveti: right :)
15:43 <jodh> rsalveti: btw - do we have any facility (like androgenizer) to handle autoconf packages in bionic land?
15:43 <slangasek> I guess the problem with trying to do it outside the container is that it would be racy trying to start listening for events inside the container
15:43 <jodh> rsalveti: autotools I mean
15:43 <rsalveti> you can manage some services via the property system as well
15:44 <slangasek> you really need something within the container to synchronously kick things off
15:44 <rsalveti> jodh: no :-( all pure makefiles
15:44 <jodh> rsalveti: ack
15:44 <ogra_> rsalveti, we should probably work out some sleeps or so to improve the races a bit, i recently start seeing ueventd acting up on maguro too
15:44 <ogra_> that wasnt the case before we switched to upstart sessions
15:44 <ogra_> (we got to fast)
15:44 <rsalveti> ogra_: right, that's why I want us to have the bridge asap :-)
15:44 <rsalveti> avoid more hacks
15:44 <ogra_> so that we can somehow survive these two extra weeks
15:45 <rsalveti> ogra_: sounds fine, if that really helps us
15:45 <ogra_> dunno, i'll do some tests
15:46 <slangasek> yeah, slowing things down with a sleep in the meantime is probably best
15:47 <rsalveti> sleep, sed and grep, we can solve everything with those tools
15:48 <slangasek> jodh: so I think it would be possible, and might reduce the memory usage, to have the synchronous trigger within the container be a one-shot program that connects to the host's socket with a simple "the container is ready" message
15:48 <xnox> jodh: you should be able to simply $ apt-get install gcc-arm-linux-androideabi and do ./configure --host=arm-linux-androideabi; which will build for android user-space and link against bionic. Then just adb push your binaries and they will work.
15:49 <jodh> one issue we have is how to tell the android service where to connect. We could hard-code that somewhere (in 2 places!) but maybe we could pass that in as an env var to the lxc container? Security team might want to get involved in this plan.
15:49 <xnox> jodh: in terms of getting it on to the images, we have ability to fetch binaries like that without any Android.mk madness.
15:49 <slangasek> so: host launches bridge; bridge listens on (abstract) socket; host launches container; container starts init; init runs "tell-upstart-I.m-here"; t-u-i-h connects to abstract socket and sends message; bridge receives message, connects to android init shared memory; bridge acks message to t-u-i-h; t-u-i-h exits; android init continues starting other services
15:49 <rsalveti> xnox: but I'm hoping that the service will be small enough to be included in there by default
15:49 <jodh> slangasek: not sure I understand - there are multiple android services that the service manager will notify us about.
15:49 <xnox> jodh: caveats apply, that you are building against bionic with incomplete pthreads, no exceptions and partial implementation with many stubs everywhere.
15:50 <slangasek> jodh: see above
15:50 <rsalveti> xnox: until we do some more progress on your work and get that as default
15:50 <xnox> jodh: or me/rsalveti other android gurus will package it later =)
15:50 <jodh> and single-shot wouldn't handle android service restart scenarios.
15:51 <rsalveti> jodh: an ENV var might me enough as a start
15:52 <jodh> slangasek: I still don't understand what you've said. I believe ofono is currently the issue, but I was going for a generic solution that would inject upstart events for all android service changes.
15:54 <slangasek> jodh: your current design requires two daemons, one inside the container and one outside the container.  But the only reason you have one inside the container is to copy state from the shared mem region to the socket, *and* to ensure synchronization of the startup so that the bridge doesn't miss service start events that happen soon after android init starts because we aren't yet listening in the right place
15:55 <jodh> slangasek: correct.
15:55 <slangasek> jodh: the second of these can be addressed by a synchronous callback to an upstart socket by a one-shot program, instead of a daemon.  and the first of these is unnecessary if the bridge just talks directly to the android shared mem interface.
15:55 <slangasek> this makes it completely un-generalized, it will be an actual upstart-android-bridge at that point; but I think that's preferable
15:56 <jodh> slangasek: the bridge on the host cannot talk to the android inits shared memory.
15:56 <slangasek> why not?
15:56 <jodh> because it's not actually shared memory in the conventional sense: init mmaps a file in /dev (tmpfs) then unlinks it.
15:57 <slangasek> oh, really?
15:57 <slangasek> so it's not using /dev/binder?
15:57 <jodh> no
15:57 <slangasek> oh fun
15:57 <slangasek> then I guess I don't see a way around having two daemons
15:57 <jodh> so, yes, we could tweak androids init to "play fair" as another option I guess, but I'd rather we didn't if possible.
15:59 <slangasek> ok, so I guess the design holds up to scrutiny ;)
15:59 <slangasek> unless anyone has any other ideas? :)
16:00 <jodh> are there any security issues anyone can think of?
16:00 <jodh> the host bridge will specify the event which stops any malicious android apps injecting random upstart events.
16:00 <jodh> (since all they can specify is a single name=value env var for the fixed event)
16:01 <slangasek> would android apps have access to this anyway?
16:01 <slangasek> I'm assuming that every piece of this requires root privileges
16:02 <rsalveti> yeah, as long we have just root-like apps setting up properties, we're good
16:02 <jodh> I'm not sure if the android service could drop privs at some point.
16:02 <rsalveti> because we can probably generate an event via 'setprop foo bar'
16:03 <rsalveti> but that's something we can also block if not root
16:03 <slangasek> yeah, it all seems fine to me
16:03 <jodh> I was thinking the android service would only react to init.* events
16:03 <jodh> can setprop still set those?
16:04 <slangasek> once the code is there it might need a security review, but I don't see anything in the design that gives me security concerns
16:04 <jodh> ok great.
16:05 <rsalveti> jodh: I think it can, but we can also protect that if needed
16:05 <slangasek> any other feedback for James?
16:06 <slangasek> #endmeeting