15:01 <slangasek> #startmeeting
15:01 <meetingology> Meeting started Wed Aug 21 15:01:51 2013 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
15:01 <meetingology> 
15:01 <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:02 <slangasek> [TOPIC] lightning round
15:02 <slangasek> $ echo $(shuf -e barry doko stgraber jodh ev bdmurray slangasek cjwatson xnox stokachu)
15:02 <slangasek> barry slangasek jodh bdmurray stgraber stokachu xnox ev cjwatson doko
15:02 <barry> system image updates: meetings; LP: #1212781 (new dbus api).
15:03 <ubottu> Launchpad bug 1212781 in Ubuntu system image "Update the DBus API to the new specification" [High,In progress] https://launchpad.net/bugs/1212781
15:03 <barry> other: virtualenv 0.10.1 review, python-pip 1.4.1-1, tox 1.6.1-1, etc.
15:03 <barry> done
15:04 <slangasek> * last week:
15:04 <slangasek> * DebConf: upstart, multiarch, arm discussions
15:04 <slangasek> * this week:
15:04 <slangasek> * sorting out the question of repartitioning phones on install
15:04 <slangasek> (done)
15:04 <slangasek> (also: sorting out jetlag)
15:04 <bdmurray> phased-updater change to not send emails about fully phased updates
15:04 <bdmurray> phased-updater change to override increased rates, restart at highest p-u-p,
15:04 <bdmurray> phased-updater change log more details regarding rates, identify security updates
15:04 <bdmurray> blog post, ubuntu-devel email regarding phased update process
15:04 <bdmurray> research into increased crash rates at error tracker
15:04 <bdmurray> package to team mapping work on unsubscribed packages
15:04 <bdmurray> SRU verification of bug 1194541, 1205374 (mostly)
15:04 <bdmurray> Researched, fixed bug 1173013 regarding gdebi and password failure
15:04 <bdmurray> analysis of bug 1157900
15:04 <ubottu> bug 1194541 in apport (Ubuntu Raring) "Create core dumps for setuid binaries" [Undecided,Fix released] https://launchpad.net/bugs/1194541
15:04 <ubottu> bug 1205374 in whoopsie (Ubuntu Quantal) "Only attempts to retry the existing crash reports once, after two hours." [Undecided,Fix committed] https://launchpad.net/bugs/1205374
15:04 <ubottu> bug 1173013 in libgksu (Ubuntu Raring) "libgksu authentication mode set to su" [High,Fix committed] https://launchpad.net/bugs/1173013
15:04 <ubottu> bug 1157900 in software-properties (Ubuntu Raring) "add-apt-repository crashed with ImportError in get_ppa_info_from_lp(): No module named 'pycurl'" [Medium,Triaged] https://launchpad.net/bugs/1157900
15:04 <bdmurray> investigation into apport bug 1119543
15:04 <bdmurray> submitted merge proposal for bug 1097773
15:04 <bdmurray> reported ubuntu-release-upgrader bug 1210643
15:04 <bdmurray> submitted RT regarding access to querying errors cassandra db
15:04 <bdmurray> fixed an issue with arsenal and tag searching
15:04 <ubottu> bug 1168849 in apport (Ubuntu Raring) "duplicate for #1119543 crashes while reporting a Synaptics bug - fills up /tmp" [Undecided,Triaged] https://launchpad.net/bugs/1168849
15:04 <ubottu> bug 1097773 in apport (Ubuntu Raring) "apport-gtk crashed with ValueError in _apt_pkg(): package skype-bin does not exist" [Medium,Triaged] https://launchpad.net/bugs/1097773
15:04 <ubottu> bug 1210643 in ubuntu-release-upgrader (Ubuntu Saucy) "UnsupportedDialog not displayed for an unsupported release" [High,Triaged] https://launchpad.net/bugs/1210643
15:05 <bdmurray> sponsored upload fixing bug 670096 from jm-leddy for lupin
15:05 <bdmurray> worked with kees on provisional MRE review
15:05 <bdmurray> code review of mvo's ubuntu-release-upgrader text-install-progress branch
15:05 <ubottu> bug 670096 in OEM Priority Project precise "Ubuntu fails to boot from ISO if there's a NTFS partition with Windows hibernated on it." [Medium,Triaged] https://launchpad.net/bugs/670096
15:05 <bdmurray> ␗ done
15:06 <slangasek> stgraber:
15:06 <stgraber> Haven't been attending the meeting for a month or so.
15:06 <stgraber> - Attended the release engineering sprint in London (worked on cdimage changelogs, system image and some archive admin tools and tasks)
15:06 <stgraber> - Attended Debconf13 in Vaumarcus (talked quite a bit about secure boot, upstart and lxc with various people)
15:06 <stgraber> - Preparing LXC 1.0 alpha1 (due next week), so quite a bit of code reviews, CI work and fixing LXC to build on Android again
15:06 <stgraber> - Got back home yesterday evening
15:06 <stgraber> - Working on 12.04.3 paperwork (release notes and announcement)
15:06 <stgraber> - Have to get a new daily-proposed channel ready on system-image + migration scripts to copy to daily once tested
15:06 <stgraber> (done)
15:07 <slangasek> stokachu: heya!  anything for the lightning round?
15:07 <stokachu> slangasek: yea sorry one sec
15:08 <stokachu> bug 1157943 - stalled needs comment from maintainer, bug 1191704 needs sponsors
15:08 <ubottu> bug 1157943 in apt (Ubuntu Precise) "apt-get update fails hash checks on https repositories when file size changes" [Undecided,New] https://launchpad.net/bugs/1157943
15:08 <ubottu> bug 1191704 in heimdal (Ubuntu) "KDCs complain about not having enough file handles for /var/lib/heimdal-kdc/heimdal" [High,Confirmed] https://launchpad.net/bugs/1191704
15:08 <stokachu> bug 833994 - probably needs a final say on whether doing certificates without checks is somethinjg we want to consider
15:08 <ubottu> bug 833994 in debian-installer-utils (Ubuntu) "debian-installer does not support https when using with preseed files" [Medium,Triaged] https://launchpad.net/bugs/833994
15:08 <stokachu> done.
15:09 <slangasek> bug #1157943 seems to stalled wrt discussions with apt upstream?
15:09 <xnox> ah me.
15:09 <ubottu> bug 1157943 in apt (Ubuntu Precise) "apt-get update fails hash checks on https repositories when file size changes" [Undecided,New] https://launchpad.net/bugs/1157943
15:10 <xnox> * Multiarch icu-dev (for boost), forwarded to debian
15:10 <xnox> * Move liblzo2 to /lib to unbreak btrfs & partman-btrfs
15:10 <xnox> * Wokring on installer bugs in partman-auto and hw-detect
15:10 <xnox> * Preparing ubiquity for FeatureFreeze (U1 plugin enablement by default)
15:10 <xnox> * all but 4.7 db packages are now in-sync with debian
15:10 <xnox> * Working on android emulator (more about that later) - i got
15:10 <xnox> phablet-saucy branches to build goldfish kernel & images, not tested
15:10 <xnox> if they boot in the emulator
15:10 <xnox> done.
15:11 <stokachu> slangasek: i think support was wanting an update from David
15:11 <ev> - Tail end of fixing a fairly hairy and hard to reproduce memory corruption bug
15:11 <ev> in whoopsie (LP: #1211417).
15:11 <ev> - Reworked our Touch upstart job to call whoopsie-upload-all as a means of
15:11 <ev> collecting additional report data and signalling to whoopsie that it should
15:11 <ev> upload the report. Much thanks for jodh and pitti for providing guidance.
15:11 <ubottu> Launchpad bug 1211417 in whoopsie (Ubuntu) "whoopsie takes 100% CPU on the phone" [Critical,Fix released] https://launchpad.net/bugs/1211417
15:11 <stokachu> *donkult
15:11 <ev> - Working through improving our continuous integration story with Alexander.
15:11 <ev> Wrote up a proposal for some nearer term changes.
15:11 <ev> - Working with the lovely folks at Acunu on building a schema and some test
15:11 <ev> cases in Analytics. We've got the weighted average errors per calendar day
15:11 <ev> working and have moved on to building the "what's interesting about this
15:11 <ev> problem" section. Starting to get the hang of it. I'll work on getting the
15:11 <slangasek> stokachu: David being apt upstream
15:11 <ev> weighted average errors deployed soon since I keep getting bugged about the
15:11 <ev> graphs on errors.u.c being entirely broken, and I suspect it will be some
15:11 <ev> time before our prodstack deployment is ready.
15:11 <ev> - Charmed Acunu Analytics. Reached out to them for some feedback.
15:11 <ev> - Started work on dropping gnetworkmonitor (for more of NetworkManager) from
15:11 <ev> whoopsie as a way of avoiding gvariant, avoiding a dependency on gio,
15:11 <ev> reducing the memory burden, and most importantly reducing the ridiculous
15:11 <ev> number of wakeups that gnetworkmonitor causes.
15:11 <stokachu> slangasek: ah ok
15:11 <slangasek> stokachu: I suggest prodding him again
15:11 <ev> - Helped the web team by reviewing their work on redesigning juju.ubuntu.com.
15:11 <ev> - Booked into the cloud sprint. Looking into the QA sprint, but this one seems
15:11 <ev> unlikely given other travel plans.
15:11 <ev> Random:
15:11 <ev> - I'm off on Friday and Monday.
15:11 <ev> - Work continues on recovering the data from the old Cassandra cluster and
15:11 <stokachu> slangasek: then yes :)
15:11 <stokachu> ok
15:11 <ev> upgrading to 1.2. This is largely in the hands of Acunu and webops:
15:11 <ev> https://rt.admin.canonical.com/Ticket/Display.html?id=63904
15:11 <ev> Things are a bit slow this week as the IS managers are sprinting, so it's
15:11 <ev> largely just been David working on it. Presumably we're blocked on moving the
15:11 <ev> retracers and {daisy,errors}.u.c into prodstack for this reason:
15:11 <ev> https://rt.admin.canonical.com//Ticket/Display.html?id=58019
15:11 <ev> - Phased updating seems to be working well at identifying real problems:
15:11 <ev> https://errors.ubuntu.com/problem/7fb9e3e8592180e543a58250ce45c1f3ea12646e
15:11 <ev> Though it might be a bit fuzzy until we get the missing data from the old
15:11 <stokachu> ill make a note in that for support
15:11 <ev> Cassandra deployment integrated back in. Well done, bdmurray!
15:11 <ev> - Convinced three other London Canonical employees to join me for this:
15:11 <ev> http://www.meetup.com/Cassandra-London/events/135739442/
15:11 <ev> (done)
15:14 <slangasek> ev: hrmm, so we're still in data recovery mode wrt Cassandra?  I had the impression we made it past that
15:14 <slangasek> phased updates \o/
15:15 <ev> slangasek: we've got a database that works and we're using that, but we're still trying to get the data out of the old one
15:15 <slangasek> ok
15:15 <ev> while upgrading to 1.2, enabling compression and moving over to a larger cluster
15:15 <slangasek> right :/
15:15 <slangasek> doko: cjwatson is off, so you're next
15:15 <ev> (merging together three clusters, since the old stuff ended up getting split across two clusters)
15:16 <ev> I'm frustrated with how long this is taking, but I'm understanding of just how many steps are involved to ensure we're not making things worse
15:17 <stokachu> bdmurray: would you be willing to look at that kdc bug?
15:17 <doko> oops
15:17 <doko> - DebConf
15:17 <doko> - Integrating various cross build patches and issues into GCC
15:17 <doko> - Start looking at current GCC test failures in saucy (500 in libjava, 50 thread related in libstdc++)
15:17 <doko> - AArch64 uploads, gcc-4.8 4.8.1-9 build
15:17 <doko> - Preparing saucy test rebuild (wanting glibc-2.18 to be included into this rebu
15:17 <doko> ild).
15:17 <doko> - Looking at various AArch64 workloads and see what needs to be done to build/enable these.
15:18 <bdmurray> stokachu: I'll have a look
15:18 <doko> (done, some bug doesn't let xchat scroll down to the end :-/ )
15:18 <stokachu> bdmurray: thanks man
15:18 <slangasek> doko: thanks
15:18 <slangasek> any questions over status?
15:19 <ev> (oh, I also forgot to point out that thanks to rsalveti and oli, I've got a working Mir on my nexus 4, so I can start work on hanging applications come Tuesdayish)
15:19 <slangasek> huzzah
15:20 <xnox> =)
15:20 <slangasek> [TOPIC] AOB
15:20 <slangasek> anything else to discuss?
15:20 <slangasek> oh, I should mention
15:20 <slangasek> vUDS is next week, if you haven't already noticed
15:20 <slangasek> so if there are things you want to discuss during UDS, please get your blueprints submitted ASAP (and drop me a link to them to get them on the schedule)
15:21 <stokachu> did we see a significant decline in blueprints this go around?
15:21 <ev> https://blueprints.launchpad.net/ubuntu/+spec/foundations-1308-click-error-reporting doesn't appear to be scheduled yet
15:22 <slangasek> stokachu: I think there's not much new in Foundations land for us to discuss right now, so I expect our volume of blueprints will be down... but if there is anything anyone here wants to discuss, please get the blueprint in
15:22 <slangasek> ev: yes, I'll do a round of scheduling today
15:22 <stokachu> slangasek: gotcha
15:23 <xnox> slangasek: hm, I think there is some bits to discuss on how, if ever, we might go about supporting i386+efi installation media.
15:23 <ev> whoop
15:24 <slangasek> xnox: feel free to submit a blueprint - from the UE side this is not something we should invest in right now, but that obviously doesn't mean it can't be discussed
15:24 <ev> slangasek: if you could keep that off Tuesday, that would be ideal
15:24 <xnox> (i think infinity + kernel people + installer / enablement) need to discuss it a bit. As there are a few places where amd64 == efi is hardcoded. and whether we want to support 64bitefi but 32bit kernel/userspace.
15:24 <slangasek> ev: understood
15:24 <xnox> slangasek: ok.
15:25 <slangasek> [TOPIC] Touch device emulation on the desktop
15:26 * xnox \o/
15:26 <xnox> So in the archive we already have the following packages:
15:26 <slangasek> so for this week's topic: xnox has been working on figuring out how to enable us to run a Touch environment under emulation on the desktop
15:26 * slangasek yields the floor :)
15:26 <xnox> * gcc-arm-linux-androideabi which is a gcc4.7 based toolchain with
15:26 <xnox> bionic libc
15:26 <xnox> * android - a package which at the moment compiles minimal android
15:26 <xnox> system image which is then "launched" in the lxc container in the
15:26 <xnox> final image. (it also compiles boot.img and recovery.img for all the
15:26 <xnox> base targets)
15:26 <xnox> but above do not at the moment build images suitable for the android emulator.
15:27 <xnox> But otherwise you can totally compile binaries for android phones / android-lxc
15:27 <xnox> container / recovery image using above toolchain and load it up with
15:27 <xnox> adb.
15:27 <xnox> * caveat we only provide latest NDK/SDK level as used by Ubuntu Touch
15:27 <xnox> images, so those binaries may not run on various Android devices
15:27 <xnox> == What's android emulator? ==
15:27 <xnox> * stock AOSP can compile for a Board target "full" which is similar to
15:27 <xnox> a typical tagets (e.g. mako/nexus4, grouper/nexus7, etc) with a few
15:27 <xnox> changes:
15:27 <xnox> - no proprietary driver blobs
15:27 <xnox> - uses goldfish 3.4 android kernel (can use a prebuilt one)
15:28 <xnox> - targets armhv7 without neon (while in real world neon is faster,
15:28 <xnox> in qemu emulating neon instructions is slower than running without
15:28 <xnox> neon)
15:28 <xnox> - images generated can be yaffs2, ext4 sparse, ext4
15:28 <xnox> - the emulator is custom compiled/forked acient version of qemu
15:28 <xnox> havily patches to support android like hw: sim card emulated, abient
15:28 <xnox> light senors, hardware phone keys, gps, forwarding webcam to
15:28 <xnox> back/forward camera or using fake images, etc.
15:28 <xnox> (it will be hard to merge with recent qemu upstream, due to many hacks & regressions in hw support layer)
15:29 <xnox> - supports setting various options w.r.t. screen-resolution,
15:29 <xnox> available RAM, partition sizes, etc.
15:29 <xnox> - does not have recovery partition, or any way to run update.zip, or
15:29 <xnox> apply upgrades
15:29 <xnox> (one can theoretically boot into "recovery" image as if it was default OS, but that's not useful, since the normal os data/system/cache partitions would not be available)
15:30 <slangasek> xnox: so when targeting "full", it uses a bundled qemu from the android source?  Is that the right thing to do, or would this be runnable under our packaged qemu?
15:30 <xnox> also this means no fastboot support, only adb.
15:30 <xnox> slangasek: it will not run under our packaged qemu.
15:30 <xnox> (and well partial adb support, as adb reboot-bootloader has no bootloader to reboot into =)))) )
15:30 <slangasek> ok - is that because of missing emulation for the android hw you mentioned?
15:31 * barry still hopes someday for LP: #1192587
15:31 <ubottu> Launchpad bug 1192587 in Ubuntu system image "lxc container tests" [Wishlist,Triaged] https://launchpad.net/bugs/1192587
15:31 <xnox> slangasek: yeah. plus google employees found errors and mistakes in armhf instruction set emulation in newer qemu / when merging in the fork.
15:31 <xnox> (well attemping to update the fork)
15:31 <xnox> - in addition to armhfv7 also supports armhv7+neone, armhv5,
15:31 <xnox> i386 atom, mips.
15:32 <slangasek> oh, interesting
15:32 <slangasek> I wonder if anyone has told pmaydell
15:32 <slangasek> xnox: so what do we get wrt GL in the emulated environment?
15:33 <xnox> at the moment we only have ubuntu-touch chroot builds for armhfv7, which should be ok. but there is interest in using i386-atom emulator since it should be theoretically faster on typical developer machine.
15:33 <xnox> slangasek: there are three options w.r.t. GL in the emulator: pass-throught to host, or compile GL bridge for host & emulator, or compile GL bridge for host, emulator and the client inside it.
15:34 <xnox> at the moment i'm building without GL, but it can be enabled later once the images start booting.
15:34 <slangasek> ok
15:34 <xnox> problem: bits of api that are in the android system lxc image do not compile on
15:34 <xnox> stock AOSP project, since (a) we based on cyanogenmod (b) we patched
15:34 <xnox> cyanogenmod to allow/improve/expose some additional android
15:34 <xnox> internals/private API.
15:34 <xnox> further fun: cyanogenmod didn't find interesting to keep emulator
15:34 <xnox> targets working thus at the moment the AOSP default emulator build
15:34 <xnox> target (full-eng) is broken on cyanogenmod (missing dependancies,
15:34 <xnox> targets, out of date forked config....). So it seems to support
15:34 <xnox> emulator "properly" somebody started a device port "cm-goldfish-eng"
15:34 <xnox> which tries to build goldfish image more inline like the rest of
15:34 <xnox> cyanogenmod devices. That targets gets the build further, but is also
15:34 <xnox> not fully functional.
15:35 <slangasek> doh
15:35 <xnox> rsalveti/phonedations/myself started to bring up "cm-goldfish-eng"
15:35 <xnox> target in our fork and with a few patches it seems like I now finally get (a)
15:35 <xnox> kernel (b) ext4 images large enough to host ubuntu rootfs. But it
15:35 <xnox> didn't boot yet - needs further tweaking of android init scripts /
15:35 <xnox> mountpoint options / etc.
15:35 <xnox> ..... current status
15:35 <xnox> emulator builds from one tree.
15:35 <xnox> android builds from another tree (and boot on above emulator)
15:36 <xnox> ubuntu-touch builds from a third tree, but alas does not work with above two (linker / missing symbols / borked init config)
15:36 <xnox> ..
15:36 <xnox> this week I managed to build android & ubuntu-touch bits from a single tree (ours) and will be continuing on to
15:36 <xnox> actually boot it on an emulator.
15:37 <xnox> all armhfv7 based.
15:37 <xnox> ones we have a working armhfv7 image it should work/boot on the pre-compiled android emulators which are available for linux/macox/windows.
15:38 <slangasek> man, what a rat's nest :)
15:38 <xnox> there are also mariad (>>10) alternative free/opensource/commercial android emulators that may be better.
15:38 <slangasek> in the near term, I think the primary target for the emulator ought to be a qemu we can build ourselves
15:38 <xnox> e.g. at the moment android stock emulator hangs if one launces it with "audio" enabled. (known upstream bug, with no progress and >>200 people starred it)
15:39 <xnox> slangasek: so at the moment we still have android-tools package, which is AOSP based tree of unitilies only.
15:39 <xnox> slangasek: we can add emulator sources there, and package AOSP emulator from that one.
15:39 <xnox> as cyanogen mod, and phablet-saucy emulators do not compile at the moment at all.
15:40 <slangasek> xnox: seems like something to discuss with the Debian maintainer before pulling the trigger on, yes?
15:41 <xnox> slangasek: well android-tools maintainers are all agreeable ubuntu/linaro folks.
15:41 <xnox> at the moment we worked android-tools to build native adbd (for flipped model, ubuntu rootfs)
15:41 <xnox> s/worked/forked/
15:41 <slangasek> xnox: oh, the uploaders at least - the Maintainer is apparently not
15:41 <slangasek> but I would hate for Ubuntu to carry a merge delta of "the emulator tree" :)
15:42 <slangasek> (actually, is our adbd build currently part of the delta? yuck?)
15:42 <xnox> gcc-android cross-compiler is based on linaro-android tree so in the archive at the moment we have: 3 partial android trees.
15:42 <xnox> i'd love to consolidate them all on a single tree.....
15:42 <xnox> (phablet-saucy, AOSP, linaro)
15:44 <slangasek> wouldn't that be nice :)
15:44 <xnox> maybe after eglibc -> glibc migration =)
15:44 <slangasek> xnox: any suggestions about how we could go about accomplishing that?
15:44 <slangasek> I guess there are phablet-saucy changes that we couldn't really push to either of the others
15:44 <slangasek> I don't know how much the cyanogenmod vs. AOSP differences matter to us, but I guess even just rebasing would be nontrivial
15:45 * slangasek wonders if the rest of the audience has gone to sleep :)
15:45 <ev> it's times like these I wish we kept popcorn in the office
15:45 <xnox> slangasek: ship android-src packages similar to what gcc-source package is, but possible multiple ones - bare minimal build scripts + utilities, a bit more to build bionic/compiler, the rest to build emulators and real images.
15:45 <slangasek> ev: go to DebConf, they apparently have popcorn
15:45 <xnox> and then create extra "empty" packages to compile: utils, compiler, per-device image.
15:45 <xnox> emulator.
15:45 <ev> slangasek: I've already made my "I take it back, I wish I went to debconf (for the cake)" post ;)
15:46 <slangasek> xnox: but if it's multiple android-src packages, that doesn't sound like consolidation to me?
15:46 <slangasek> ev: hah
15:46 <xnox> slangasek: single android-src:src package, multiple binary android-src-*:all. As the full 100MB compressed tree is not needed for all builds.
15:47 <xnox> and one "edition" of thereoff, that works for all.
15:47 <xnox> slangasek: one can use single android-src package, it's just it will be large for something like - build utilities or compiler, as it will have code which is compiled during that build.
15:48 <slangasek> xnox: but you're still talking about keeping three branches of the source AIUI (phablet, AOSP, linaro)
15:48 <slangasek> putting it into a single source package seems like consolidation in name only
15:49 <xnox> slangasek: no, i'd want to use phablet only. Reverted back to AOSP where needed (e.g. emulator, utilities). linaro one should not be needed (it was simply the easiest way to bring up the working cross compiler)
15:50 <slangasek> ah, ok
15:50 <slangasek> would we actually need to revert the utilities back?
15:50 <xnox> so single tree, but still patched/diverged from AOSP/cyanogenmod. Something approx. equivalent how our "normal" gcc is: linaro patches, on top of debian patches, on top of FSF tree.
15:51 <xnox> slangasek: i don't think so, more likely merge newer AOSP versions of utilities (e.g. adb that does verification/authentication with target device)
15:51 <xnox> cyanogenmod didn't take / enable authentication.
15:51 <slangasek> hmm, alright
15:51 <xnox> low priority though.
15:51 <slangasek> yep, makes sense
15:52 <slangasek> so - any other questions about the emulator work?
15:52 <xnox> at the moment all pieces are disconnected and easy to update individually and all of them work as intended (sans emulator)
15:52 <slangasek> there will be a quiz later... when you'll all be expected to be able to use it ;)
15:52 * barry reaches for the cliff notes
15:53 <xnox> using emulator is  easy: from command line, or a graphical java based GUI pops up that "integrates" with eclipse to twiddle params and launch the emulator.
15:53 <doko> glibc-2.18 should have almost all merges from eglibc, just waiting for the 2.18 upload ...
15:54 * xnox expects to add support to phablet-flash, as a new image types, to simply use emulator images when requested
15:54 <ev> Eclipse you say? Better fire it up now and hopefully by the time I need it weeks from now I'll be past the splash screen.
15:54 <slangasek> xnox: last question: is there anything anyone could do to help you right now (if they were keen)?
15:55 <xnox> slangasek: port lxc to goldfish kernel & see/check that it works.
15:55 <xnox> on AOSP images / or anything.
15:55 <xnox> which is 3.4 based. I think one of our devices is 3.4 based as well.
15:55 <slangasek> xnox: where should someone look for the goldfish kernel?
15:56 <xnox> slangasek: http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_kernel_goldfish.git;a=summary
15:56 <slangasek> so no binaries in the archive yet?
15:56 <xnox> no, not packaged.
15:57 <slangasek> oh, or do you mean that the actual kernel code needs patched?
15:57 <xnox> i guess it should be managed as linux-maguro et al kernels.
15:57 <xnox> slangasek: yeah, other kernels didn't have lxc either, or did they?
15:57 <slangasek> I have no idea
15:57 <xnox> slangasek: i don't know, if there were patches, or if it was config changes only.
15:57 <slangasek> but if what we need is a linux-goldfish kernel package, we should get that over to the kernel team :)
15:58 <xnox> stgraber: how did lxc make it into the linux-mako/maguro/grouper/et al kernels?
15:58 <stgraber> xnox: lxc is upstream
15:58 <stgraber> xnox: you just need the right set of options enabled in the kernel build
15:58 <xnox> stgraber: ok, i'll check the current goldfish config vs the other kernels.
15:58 <stgraber> IIRC we support upstream >= 2.6.32 in the current LXC userspace tools
15:59 <xnox> spendid.
15:59 <xnox> splendid.
15:59 <slangasek> any other questions?
15:59 <slangasek> (otherwise we're at time, so)
16:00 <slangasek> xnox: thanks for taking us down the rabbit hole :)
16:00 <slangasek> #endmeeting