15:02 <slangasek> #startmeeting
15:02 <meetingology> Meeting started Wed Jul  3 15:02:41 2013 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
15:02 <meetingology> 
15:02 <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 * stgraber waves
15:02 <slangasek> [TOPIC] Lightning round
15:03 <slangasek> $ echo $(shuf -e barry doko stgraber jodh ev bdmurray slangasek cjwatson xnox stokachu)
15:03 <slangasek> jodh slangasek doko barry bdmurray cjwatson stgraber stokachu ev xnox
15:04 <xnox> win!
15:04 <jodh> * upstart:
15:04 <jodh> - 1.9 release.
15:04 <jodh> - Cookbook update.
15:04 <jodh> - Ubuntu merge.
15:04 <jodh> - Working on lp:~jamesodhunt/upstart/fix-libupstart which seems to
15:04 <jodh> have exposed a gettext bug (worked around with fix from cjwatson).
15:04 <jodh> - libupstart packaging preparation (ongoing).
15:04 <jodh> - Currently working on a testing Ubuntu libupstart packaging before
15:04 <jodh> putting out a 1.9.1 release (of lp:upstart tip).
15:04 <jodh> - Fixed bug 1197225.
15:04 <ubottu> bug 1197225 in upstart "upstart-file-bridge assert failure: string.c:396: Assertion failed in nih_str_split: str != NULL" [Medium,Fix committed] https://launchpad.net/bugs/1197225
15:04 <jodh> - Merged lp:~ted/upstart/starting-reversal.
15:04 <doko> hi
15:04 <jodh> - Raised startpar-bridge bug 1197426.
15:04 <ubottu> bug 1197426 in sysvinit (Ubuntu) "starpar-upstart-inject causes upstart to consume a lot of cpu" [High,Invalid] https://launchpad.net/bugs/1197426
15:04 <jodh>15:04 <jodh> ... and ignore bug 1197426! :)
15:04 <slangasek> :)
15:05 * jodh whispers 'user error'
15:05 <slangasek> * helping with the odd merge review on upstart
15:05 <slangasek> * mountall update for bug #1192514
15:05 <slangasek> * updated gnu-efi, shim for SecureBoot support; may take care of some outstanding bugs we have booting on some hardware
15:05 <ubottu> bug 1192514 in mountall (Ubuntu) "Invalid locale in /etc/default/locales halts boot" [Medium,Fix released] https://launchpad.net/bugs/1192514
15:05 <slangasek> * discussed with the kernel team about UEFI anti-bricking kernel backports
15:05 <slangasek> * talking about Mir on the Youse Tubes: http://www.youtube.com/watch?v=h00xJwMi-eY
15:05 <slangasek> * todo:
15:05 <slangasek> * public holiday tomorrow, and off on Friday
15:05 <slangasek> * look at getting plymouth working on top of Mir
15:05 <slangasek> * get parted cross-building using the android toolchain cross-builder
15:05 <slangasek> * implement repartitioning of disks on Ubuntu Touch install
15:05 <slangasek> * decide on MokManager packaging in shim, submit new binaries to Microsoft for signing
15:05 <slangasek> * reviewing new centrifydc package for partner
15:05 <slangasek> (done)
15:05 <ogra_> yay, plymouth !
15:07 <doko> - test proposed fixes for current linaro gcc-4.8 regressions
15:07 <doko> - openjdk-7 update
15:07 <doko> - cross compiler updates
15:07 <doko> - some kind of +1 maintenance, chasing down dep waits and build failures in -proposed
15:07 <doko> - aarch64 bringup (fix some config.* files)
15:07 <doko> - prepare for connect
15:07 <doko> (done)
15:08 <barry> image based updates: plumb out reboot sequence, writing command file, moving files into place; LP: #1192574; LP: #1193142 (yay! uploaded); had a meeting on the dbus api and began working on LP: #1192585; had some emails/meetings/discussions on the new dbus download service which is being written by mandel.
15:08 <ubottu> Launchpad bug 1192574 in Ubuntu system image "Issue reboots" [High,Fix released] https://launchpad.net/bugs/1192574
15:08 <ubottu> Launchpad bug 1193142 in Ubuntu system image "Create Debian packaging for client" [High,Fix released] https://launchpad.net/bugs/1193142
15:08 <ubottu> Launchpad bug 1192585 in Ubuntu system image "Add a dbus API" [High,In progress] https://launchpad.net/bugs/1192585
15:08 <barry> other: py.test rebuild to fix FTBFS; debian bug 712881 (uploaded new enum34 to debian); working on tox 1.5 in debian (but waiting for debian bug 714412 to clear NEW); python-configglue 1.1.0-0ubuntu1 (with py3 support); LP: #1196983; filed debian bug 714757; dmb meeting; gsoc mentors meeting.
15:08 <ubottu> Debian bug 712881 in wnpp "ITP: python-enum34 -- support for enums (backport of Python 3.4's enum package)" [Wishlist,Open] http://bugs.debian.org/712881
15:08 <ubottu> Debian bug 714412 in wnpp "ITP: python-pytest-instafail -- py.test plugin to show failures instantly" [Wishlist,Open] http://bugs.debian.org/714412
15:08 <ubottu> Launchpad bug 1196983 in configparser (Ubuntu) "[MIR] configparser" [Undecided,New] https://launchpad.net/bugs/1196983
15:08 <ubottu> Debian bug 714757 in configparser "configparser: Unnecessary Build-Depends on python-support" [Normal,Open] http://bugs.debian.org/714757
15:08 <barry> usa holiday tomorrow and off on friday.
15:08 <barry>15:09 <bdmurray> modified phased-updater (and updated MP) to directly call changeOverride (LP API)
15:09 <bdmurray> research into software-center not creating package install failure reports
15:09 <bdmurray> reported bug 1196740 regarding software-center
15:09 <ubottu> bug 1196740 in software-center (Ubuntu) "not all package install failures generate a crash report" [High,Confirmed] https://launchpad.net/bugs/1196740
15:09 <bdmurray> testing of .crash file detection by upstart
15:09 <bdmurray> generated new oauth token and secret for whoopsie-daisy-lp-bridge
15:09 <bdmurray> submitted and tested result of RT regarding deployment of new oauth token and secret (fixes LP: #1053395)
15:09 <ubottu> Launchpad bug 1053395 in Errors "Bugs reported from "Create" have "Evan Dandrea" as reporter" [High,Fix released] https://launchpad.net/bugs/1053395
15:09 <bdmurray> reported errors bug 1197186
15:09 <ubottu> bug 1197186 in Errors "Create link oopses for some bug reports" [Undecided,New] https://launchpad.net/bugs/1197186
15:09 <slangasek> sigh, more unity package changes preventing update-manager from being able to DTRT
15:09 <bdmurray> modification to errors / daisy to create more detailed bugs in launchpad
15:09 <bdmurray> modified bugbot to subscribe me to regression srus
15:09 <bdmurray> set expiration date for bug control members w/o one
15:10 <bdmurray> ✔ done
15:10 <cjwatson> foundations-1305-click-package: Renamed click-package to click, by request of Mark.  Thinking about D-Bus interface.  Responded to Sebastian Heinlein's questions on the list; he's offered to help with implementation, which is great.
15:10 <cjwatson> community-s-autopkgtesting: Discussion with Jean-Baptiste on various problems with the autopkgtest workflow.  Prepared announcement to explain to developers what's going on; just waiting for a couple more fixes to land first.
15:10 <cjwatson> foundations-1305-arm64-bringup: Started up auto-cross-builder on saucy/armhf.  Thanks to Evan for Canonistack help.
15:10 <cjwatson> Visited London to generate keys for image-based-upgrades.
15:10 <bdmurray> oh, I'm out Thursday and Friday too
15:10 <cjwatson> Fixed up some Python 3 compatibility in lsb (bug 1035136).
15:10 <ubottu> bug 1035136 in lsb (Ubuntu Raring) "[SRU] Fix lsb-core for 12.10 and 13.04" [Medium,Triaged] https://launchpad.net/bugs/1035136
15:10 <cjwatson> Prompted discussion on making the publisher try to run more frequently; implemented as of this morning.
15:10 <cjwatson> Fixed crazy fakechroot/chfn/PAM/audit interaction in ubuntu-touch-generic-initrd build.
15:10 <cjwatson> Merges/syncs: debhelper, jifty, graphviz, tcl8.4, bogl, python-anyjson, qt-assistant-compat, libcommons-compress-java, efax-gtk, patch, wireless-regdb, gluegen2, libtool
15:10 <cjwatson> .
15:11 * barry is eager to hear about autopkgtest
15:11 <xnox> cjwatson: how often does the publisher try to run now?
15:11 <cjwatson> I can't really announce it properly until it stops losing failed statuses ;-)
15:11 <cjwatson> xnox: I'm leaving infinity to take the glory on that since he did most of the legwork
15:11 <barry> ;)
15:11 <xnox> cjwatson: ok.
15:12 <cjwatson> But anyone who complains about slowness now is clinically impatient ;-)
15:12 <xnox> and he is not here to get the ping.....
15:13 <cjwatson> He knows :)
15:13 <slangasek> stgraber: you're up
15:13 <stgraber> Blueprint-related work:
15:13 <stgraber> - Image based updates (BLUEPRINT: foundations-1305-image-based-updates)
15:13 <stgraber> - system-image.u.c is now running with the production GPG keys!
15:13 <stgraber> - Worked on an initial plan for our DBus API with barry
15:13 <stgraber> - Wrote a new pack-system tool to generate the hardware-dependent tarballs
15:13 <stgraber> - Updated repack-rootfs to create the missing directories and symlinks to make a loop-mounted image work
15:13 <stgraber> - Implemented a basic upgrader script and ran the first image update on my N4: http://paste.ubuntu.com/5838899/
15:13 <stgraber> Other work:
15:14 <stgraber> - Ubuntu touch
15:14 <stgraber> - Cherry-picked pidns+mntns support to mako and manta, available at github.com/stgraber/linux (maguro and grouper will be much harder as they're on an older kernel)
15:14 <stgraber> - Merged a bunch of changes to lxc-android-config and the initrd to support loop-mounted flipped images
15:14 <stgraber> - Cleaned up a bunch of scripts to stop using /proc/<pid>/root as a way to access the container, instead doing clean bind-mounts from the host to the container
15:14 <stgraber> - LXC
15:14 <stgraber> - Usual code reviews
15:14 <stgraber> - Release
15:14 <ogra_> cjwatson, well, with moving to apt-less images the turnaround time gets more critical since we need an image build too to get the fix to the users
15:14 <stgraber> - Alpha-1 release engineering work
15:14 <stgraber> - Did a bunch of tests on self-service rebuilds and added to cron, appears to work reliably
15:14 <stgraber> - Upstart
15:14 <stgraber> - Fixed respawn when the exec line contains shell characters (affecting ofono on Touch)
15:14 <stgraber> - Code review
15:14 <stgraber> - Other
15:14 <stgraber> - Objectives
15:14 <stgraber> - Quite a bunch of meetings (DMB, weekly release meeting, upgrader DBus API, weekly upgrader meeting, OEM customization)
15:14 <stgraber> 
15:14 <stgraber> TODO:
15:14 <stgraber> - THIS WEEK: Integrate the system-image module with cdimage to publish updates to the daily channel as they appear
15:14 <stgraber> - THIS WEEK: Add gpg support to the upgrader script
15:14 <stgraber> - Write some tools for manual actions on system-image (manage channels, manage keyrings, manually publish updates, ...)
15:14 <stgraber> - Process some pending merges (ifupdown and resolvconf)
15:14 <stgraber> 
15:14 <stgraber> (DONE)
15:15 <cjwatson> ogra_: sure
15:15 <ogra_> (so count me in on that impatient crowd :P )
15:16 <slangasek> ogra_: but a) publisher should no longer be a source of unreasonable delays, b) the users you're trying to get fixes to quickly are all developers, who are going to want to opt out of image-based updates anyway except for dogfooding purposes...
15:16 <slangasek> stokachu: around this week?
15:17 <ogra_> slangasek, dont make stgraber unhappy :)
15:17 <ogra_> i guess we actually want *some* users that use it readonly
15:17 <ogra_> :)
15:17 <slangasek> ogra_: we've already discussed this, and agreed not to flip the switch until we have the opt-out mechanism available :)
15:17 <xnox> * Upstart:
15:17 <xnox> - fixup upstart SRU
15:17 <xnox> - upload 1.9 into saucy, and fix that one up
15:17 <xnox> * Uploaded shadow with user name space support into saucy
15:17 <xnox> * Did objectives.
15:17 <xnox> * Ongoing trying to build a working android cross toolchain, with
15:17 <xnox> help/suggestions from doko. This time around using 4.7.5 linaro
15:17 <xnox> release.
15:17 <xnox> ..
15:18 <slangasek> ah, does that mean I should downgrade my android cross-toolchain packages?
15:18 <doko> 4.7.5?
15:18 <slangasek> doko: and can xnox have access to upload to some appropriate common ppa for his cross-toolchain work?
15:18 <xnox> doko: that's linaro's 13.06 gcc-4.7 release labeled as.
15:18 <doko> slangasek, he does
15:18 <slangasek> oh, ok
15:19 <xnox> slangasek: i do now. No need to upgrade anything, packages are datestamp versioned.
15:19 <slangasek> got it
15:19 <slangasek> which ppa should I be pulling from, then?
15:19 <xnox> slangasek: not uploaded yet, still  building it
15:20 <stgraber> slangasek: we have the opt-out "touch /data/.developer_mode", then reboot and / will be read-write :)
15:20 <slangasek> yes, but which ppa :)
15:20 <xnox> slangasek: the current toolchain you have, should be ok to build a statically linked parted that will work in recovery.
15:20 <slangasek> stgraber: ok :)
15:21 <xnox> slangasek: will be in https://launchpad.net/~ubuntu-toolchain/+archive/android , last one is still in https://launchpad.net/~xnox/+archive/scratch. Let me copy it across.
15:21 <slangasek> xnox: I already have the last one - don't worry about copying, I just want to get the new one once it's available
15:22 <slangasek> any other questions over statuses?
15:22 <xnox> slangasek: will ping, once available.
15:22 <slangasek> xnox: ok, thanks :)
15:23 <slangasek> [TOPIC] AOB
15:23 <slangasek> let's do this the right way 'round this time - anybody have anything else they want to cover before we go into our discussion topic?
15:24 <slangasek> [TOPIC] click packages
15:24 <slangasek> seeing no response, I'll turn the mic over to Colin :)
15:24 <cjwatson> Heh, OK, thanks :)
15:25 <cjwatson> As last week, this isn't meant to be a lecture, but I prepared a few notes for those who're unfamiliar, or who aren't up to speed with what's currently happening
15:25 <cjwatson> "Click packages" (the name predates me, so don't blame me :-) ) are the app packaging framework for the phone, and designed with an eye to later convergence onto the desktop.
15:25 <cjwatson> They're a lightweight system designed to be fast and robust while also reusing a reasonable amount of code from elsewhere, since we have pretty tight delivery targets.
15:25 <cjwatson> They're explicitly *not* designed to replace dpkg and apt; in particular they deliberately have much simpler dependency arrangements.  But they should work for the sort of third-party apps that just use facilities of the stock GUI framework.
15:25 <cjwatson> This is a cross-team effort.  For example, Foundations is supplying the low-level packaging tools, up to the D-Bus interface; Security is handling confinement; the SDK team is handling QtCreator integration; and various Online Services teams are handling the server side and the Dash integration.
15:25 <cjwatson> Some orientation links:
15:25 <cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-click-package
15:25 <cjwatson> https://launchpad.net/click
15:25 <cjwatson> Right now a preliminary version of click is in saucy.
15:25 <cjwatson> https://click-package.readthedocs.org/
15:25 <cjwatson> The most important things coming up in July involving Foundations are:
15:25 <cjwatson> * per-user package installation
15:26 <cjwatson> * D-Bus API (will probably be based on PackageKit, possibly with assistance from aptdaemon)
15:26 <cjwatson> * app confinement
15:26 <cjwatson> * desktop file hook so that you can actually run installed apps
15:26 <cjwatson> * get click packages into touch images
15:26 <cjwatson> * demo to Mark at end of month.  NO PRESSURE
15:26 <cjwatson> Questions, discussion?
15:27 <barry> cjwatson: can you describe the dbus api a bit more?  what is the scope? what does it do and/or provide?
15:27 <cjwatson> This isn't something that distributes madly to lots of foundations people, since we're leaving most existing packages as-is, but there are definitely places where I could use a check on my madness :)
15:27 <cjwatson> barry: I think the best thing to do there is to point to the active mailing list thread on the subject
15:27 <cjwatson> https://lists.launchpad.net/ubuntu-appstore-developers/msg00151.html
15:27 <slangasek> so I understand all the Ubuntu Touch core apps are meant to be made available as click packages soon, rather than .debs (which I guess is the "get packages into touch images" part).  how's that coming along?
15:28 <barry> cjwatson: thanks
15:28 <cjwatson> We'll basically end up with a very cut-down version of the PK API, probably - so you can install from files, remove packages, list packages, but not necessarily do complex upgrades or install by package name (depending on how/whether we hook up the download service)
15:28 <cjwatson> I don't really feel a need to invent a new API for it
15:28 <xnox> cjwatson: delta-clicks defined yet?
15:29 <xnox> (as what delta-debs are to debs)
15:29 <cjwatson> slangasek: That's the goal for this month, and I've done some experimentation with it, but it won't make sense to do it until something's hooked up so that you can actually execute the app :)
15:29 <slangasek> heh, ok :)
15:29 <barry> cjwatson: the "download service" is coming out of the click work, and we're trying to make it generic enough to be useful for image updates
15:29 <cjwatson> I've been talking with Ted about the details of that, abstracted above as "desktop file hook"
15:30 <cjwatson> xnox: good question, thanks - I have notes in https://click-package.readthedocs.org/en/latest/todo.html#delta-updates
15:30 <cjwatson> xnox: I have a back-burner project to port debdelta to Python 3 so that we can more readily contemplate using it
15:30 <cjwatson> xnox: I've already verified that it can at least approximately handle click packages, in theory
15:31 <cjwatson> barry: Do you think it might be possible to hook it up to things like the PK DownloadPackages (or whatever it is) API?
15:32 <cjwatson> PK has its own network stacks which talk to NM and the like, so maybe not
15:32 <cjwatson> But I kind of feel it'd be nice to push this sort of thing down as far as possible so that we can reuse more code ...
15:32 <barry> cjwatson: i think that should be a goal.  the rough api i've seen needs to be "genericized" a bit more, but currently is somewhat app-specific.  we should have a chat with mandel about that.
15:33 <barry> the download service will be responsible for stuff like suspend/resume downloads, wifi-only, interacting with settings, etc.  basically all the weird network vagaries a phone would see.
15:33 <barry> e.g. user shuts off her phone in the middle of a download
15:34 <cjwatson> I guess we don't want to turn every single TCP connection into a download notification, so it does want some awareness of what's doing the calling
15:34 <cjwatson> (I assume the download service is doing some kind of notifications?)
15:34 <barry> right.  there are a bunch of downloads the upgrader will do (e.g. is an update available) that don't need notification
15:34 <barry> yes.
15:35 <barry> details tbd.  i expect we'll see some more concrete stuff by next week and then can refine from there
15:36 <cjwatson> For now, it's not critical; the dash code can deal with downloads and then feed to PK.Transaction.InstallFiles or similar
15:37 <cjwatson> However in some ways it'd be easier if we could use an InstallPackages type interface (package names, not file names) because it would be easier to avoid duplicate downloads for the multi-user case
15:37 <barry> yep.  i need to refactor the upgrade client internally so that it can use either the download service or my built-in dumb downloader
15:37 <cjwatson> I've only really just started looking at PKish things so I'm a little hazy on some of this as yet
15:38 <cjwatson> And very happy that Sebastian has offered to help out there
15:38 <cjwatson> This month is going to be fairly brutally focused on getting to an end-to-end demoable state
15:38 <barry> okay, mandel says spec should be transferred to wiki pages rsn
15:39 <cjwatson> i.e. build app in QtCreator, upload to click server, search for it in dash, install on phone, run app
15:40 <cjwatson> I think it's doable; but if I tell anyone I can't help with something, this is probably why ;-)
15:40 <slangasek> :)
15:41 <slangasek> if people wanted to get their hands dirty with this today, what would you suggest?
15:41 <slangasek> playing with the SDK?
15:41 <cjwatson> The SDK doesn't quite allow building click packages yet, but you can put the filesystem tree together and then run "click build" on it
15:42 <cjwatson> And "click install --force-missing-framework"
15:42 <cjwatson> It's still a little boring due to things like missing execution hooks, so the package in the archive at the moment is mostly for the purpose of putting more pieces together
15:43 <slangasek> very cool stuff
15:44 <cjwatson> For this audience, I'd also like people to have a look at the hooks interface from the POV of a world with a read-only system partition
15:44 <slangasek> when will qtcreator integration happen?  I notice the blueprint has a work item for talking about it, but not for making it happen ;)
15:44 <cjwatson> Since I wrote it before I'd fully understood what was going on there, it probably needs some rework
15:44 <cjwatson> https://click-package.readthedocs.org/en/latest/hooks.html
15:44 <slangasek> right... the putting-stuff-not-on-the-root-filesystem question
15:45 <cjwatson> I talked to Zoltan about that on 20 June, and he said then that he was going to be attacking the implementation from that Monday
15:45 <slangasek> if there are some touch apps shipped in the image, does that mean there'll be two directories on the search path?
15:45 <cjwatson> However I gather he's now on paternity leave, so it's just possible that there have been some distractions
15:45 <slangasek> cjwatson: right, I was just noticing that :)
15:45 <cjwatson> Loic and Daniel have been trying to chase up what's happening there, I believe
15:45 * slangasek nods
15:45 <cjwatson> Right, we are going to end up with multiple click installation directories, I believe, possibly abstracted through a symlink farm
15:46 <cjwatson> Per-user app installation implies each user having symlinks to their own current versions of apps
15:46 <cjwatson> So there are a couple of different ways we could assemble that
15:46 <cjwatson> There's also some question of OEM overrides
15:46 <cjwatson> Watch this space, I'm not totally sure yet :)
15:46 <stgraber> cjwatson: I guess lool will be poking you about this soon but we had a meeting about oem customizations this morning and we'll likely have yet another path for that (/oem/...) that will contain some click packages too (probably in their packed rather than unpacked form, but I'll let lool and you figure the details)
15:46 <slangasek> ok :)
15:47 <lool> (poked already  :-)
15:47 <cjwatson> As I said on ubuntu-appstore-developers (thread linked to barry above), I think this needs to be designed in conjunction with the D-Bus API to make sure it all works properly
15:47 * lool hugs
15:47 <cjwatson> stgraber: Yeah, that was what I was shorthanding as "OEM overrides"
15:48 <cjwatson> TBH that further guides me towards managing things by way of a per-user symlink farm, but it depends a little on how much wants to be mandatory as opposed to merely default, if you see what I mean
15:48 <cjwatson> Personally I think that if we don't allow users to remove OEM customisations that are there by default, then we are not on the side of the angels
15:48 <cjwatson> But maybe somebody will override me there ;-)
15:51 <slangasek> so I definitely look forward to seeing this in action at the end of the month
15:51 <slangasek> I suspect having apps on my Ubuntu Touch will make quite a difference in its utility ;)
15:51 <cjwatson> Um, yes, quite :)
15:52 <beuno> pft, so demanding.
15:52 <cjwatson> Weaning myself off all the apps I have for Android might take a while
15:52 <slangasek> waiting for the Ubuntu Touch Ingress port
15:52 <slangasek> (that one might be a while in coming)
15:52 <slangasek> :)
15:53 <slangasek> cjwatson: cool, thanks for filling us in on the click work
15:53 <slangasek> any other questions?
15:54 <cjwatson> give me a non-webapp twitter client and I'll be happy ;-)
15:54 <barry> +1
15:54 <slangasek> haha
15:55 <slangasek> #endmeeting