[15:01]  * slangasek waves
[15:01] <jodh> o/
[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> 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] <jodh>   - Merged lp:~ted/upstart/starting-reversal.
[15:04] <doko> hi
[15:04] <jodh>   - Raised startpar-bridge bug 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] <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] <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] <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] <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] <bdmurray> reported errors bug 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] <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
[15:55] <meetingology> Meeting ended Wed Jul  3 15:55:03 2013 UTC.
[15:55] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-07-03-15.02.moin.txt
[15:55] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-07-03-15.02.html
[15:55] <slangasek> thanks, all!
[15:55] <stgraber> thanks!
[15:55] <barry> thanks!
[15:58] <xnox> cjwatson: there is non-webapp twitter client on touch images, via friends app. one does need to launch authentication via adb shell, but it otherwise works good.
[16:07] <cjwatson> xnox: ah, ok
[16:08] <xnox> cjwatson: http://askubuntu.com/questions/310172/how-to-add-accounts-to-friends-app-in-ubuntu-touch