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