[16:01]  * stgraber waves
[16:01] <jodh> o/
[16:01]  * slangasek waves
[16:02] <xnox> \0
[16:02]  * ogra_ shores
[16:03] <slangasek> #startmeeting
[16:03] <slangasek> [TOPIC] lightning round
[16:03]  * slangasek pokes the bot
[16:03] <ogra_> i think its dead since a few days already
[16:04] <slangasek> boo, ok
[16:04] <xnox> slangasek: the bot is on well-deserved holiday =)
[16:04] <slangasek> stupid Robot Equality Act
[16:04] <ogra_> went together with the piloting bot from #ubuntu-devel
[16:05] <slangasek> $ echo $(shuf -e barry doko stgraber jodh ev bdmurray slangasek ogra infinity cjwatson xnox stokachu)
[16:05] <slangasek> doko barry xnox ogra ev stgraber slangasek stokachu cjwatson jodh infinity bdmurray
[16:05] <slangasek> doko: you're up first :)
[16:06] <slangasek> stokachu says he won't make today's meeting btw
[16:06]  * xnox thinks they are simply running around the pool of selenium in circles
[16:06] <slangasek> tick tock
[16:06] <ogra_> i heard they have a cabin in the mountains, meeting bot wanted that because of all the waves at the sea reminding him of work
[16:06] <slangasek> barry: why don't you go ahead, we'll grab doko later
[16:07] <barry> oauthlib issue 68 (ValueError in escape()). bug #1077076 (in progress). bug #1061149 (*lots* of additional debugging/data gathering w/ more to come). tox packaging for debian (cleared debian new!). piston-mini-client (py3, oauthlib, packaging - uploaded). review, merge, sponsor: ~mitya57/ubuntu/raring/python-defaults/resync (python-defaults 2.7.3-3ubuntu1). done.
[16:07] <barry> yay, no bot
[16:07] <barry> 1077076 is oneconf for py3 and oauthlib
[16:07] <barry> 1061149 is boot freezes
[16:07] <cjwatson> tox didn't build anywhere in raring-proposed
[16:07] <cjwatson> yi
[16:07] <cjwatson> fyi
[16:08] <barry> cjwatson: yeah, i just noticed that.
[16:08] <xnox> * assist jamespage with maintainer scripts for bug 1079897
[16:08] <xnox> * fix cmake fallout (causes unity to FTBFS) bug 1080713
[16:08] <xnox> * geoname-loop is deployed! bug 837064 / rt 55554 is fix released
[16:08] <xnox> * patch pilot tuesday
[16:08] <xnox> * upload ubiquity with many bugfixes
[16:08] <xnox> * ubiquity/compiz support done, pending upload (lp:~xnox/ubiquity/compiz)
[16:08] <xnox> ..
[16:08] <cjwatson> missing build-dep on python-pytest perhaps?
[16:09] <ogra_> done:
[16:09] <ogra_>  * plenty of nexus7 image fixes. bug 1084063, bug 1071185 (and various ones that were just fixed on the go without report)
[16:09] <ogra_>  * uploaded a cleaned up ubuntu-default-settings-nexus7
[16:09] <ogra_>  * nexus raring images are close to usable, sadly bug 1065638 is still blocking us from having a proper desktop
[16:09] <ogra_> todo:
[16:09] <barry> cjwatson: it made it to unstable: http://packages.debian.org/search?keywords=python-tox&searchon=names&suite=all&section=all
[16:09] <ogra_>  * meeting for discussing the remaining WIs of https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-reduced-power-ram (carried over again)
[16:09] <ogra_>  * flash-kernel fixes (carried over as well)
[16:09] <ogra_> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1084063
[16:09] <ogra_> https://bugs.launchpad.net/ubuntu-nexus7/+bug/1071185
[16:09] <ogra_> https://bugs.launchpad.net/ubuntu-nexus7/+bug/1065638
[16:09] <ogra_> ..
[16:09] <cjwatson> barry: Yes, but Architecture: all packages in Debian aren't necessarily built in clean environmenets
[16:12] <ev> - Continued development of the retracer squid cache. We had to back this out
[16:12] <ev>   because the retracing time shot through the roof and we suddenly had several
[16:12] <ev>   thousand pending retraces, completely overwhelming the disks in the
[16:12] <ev>   retracers. I think that's due to a bug, which I'm working on fixing while we
[16:12] <ev>   get the queues back under control.
[16:12] <ev> - Call with Ale and her team on the juju GUI, then a follow up brainstorming
[16:12] <ev>   session in Blue Fin. Provided my own experiences and suggestions. Helped them
[16:12] <ev>   better define the developer and webops personas.
[16:12] <ev> - Implemented the prototype of Pig on Hadoop on Cassandra for the error tracker:
[16:12] <ev>   https://wiki.ubuntu.com/ErrorTracker/MapReduce
[16:12] <ev>   With this deployed to production, we'll be able to write map/reduce queries
[16:12] <ev>   in Pig Latin that are ideally distributed over the Cassandra nodes and can
[16:12] <ev>   run independent of a developer machine.
[16:12] <ev>   
[16:12] <ev>   So if Steve wants to know what is the average number of crashes reported by a
[16:12] <ev>   machine during the first week that the machine is seen, he can without
[16:12] <ev>   leaving his computer running for days and without greatly impacting the
[16:12] <ev>   performace of the Cassandra cluster.
[16:12] <ev>   
[16:13] <ev>   We can make that impact very negligable in the future by moving this to a
[16:13] <ev>   seperate Cassandra cluster that's replicated from the main cluster.
[16:13] <ev> - Mail to Foundations on setting up the error tracker in Canonistack:
[16:13] <ev>   https://lists.launchpad.net/private-platfound/msg00774.html
[16:13] <ev> - Debugging the error tracker charms with Kapil. He tracked the issue down to
[16:13] <ev>   our schema creation script, which I've fixed. You can now run `bzr branch
[16:13] <ev>   lp:~ev/+junk/whoopsie-daisy-deployment; ./whoopsie-daisy-deployment/deploy`
[16:13] <ev>   without any extra fiddling.
[16:13] <ev> - Dumping my notebook into Launchpad Bugs in preparation for our sprint.
[16:13] <ev> - Massive triage of Errors, Whoopsie, and Daisy bugs in preparation for the
[16:13] <ev>   sprint.
[16:13] <ev> - Firefighting with webops:
[16:13] <ev>   https://wiki.canonical.com/InformationInfrastructure/WebOps/BrokenServiceEscalation/2012-11-28-UE-Retracers-Disk-Usage
[16:13] <ev> (done)
[16:13] <stgraber>  - Upstart
[16:13] <stgraber>   - Upstart meeting, got a workitem list for the Session Init work
[16:13] <stgraber>   - Some cleanup work on the upstart-dconf-bridge at: lp:~stgraber/upstart/upstart-dconf-bridge
[16:14] <stgraber>   - Implemented the prctl call in: lp:~stgraber/upstart/upstart-prctl
[16:14] <stgraber>   - Implemented use of initgroups in: ~stgraber/upstart/upstart-initgroups
[16:14] <stgraber>   - Early implementation of the new DBUS signals in: ~stgraber/upstart/upstart-dbus-events
[16:14] <stgraber>   - Now fighting with the tests for those.
[16:14] <stgraber>  - Container
[16:14] <stgraber>   - Updated the upstream python code for the new pep8 warnings.
[16:14] <stgraber>   - Added a new function to the API to pass a device (block or character) directly to a running container.
[16:14] <stgraber>   - Introduced a new lxc-device tool using the new device passing code in the API.
[16:14] <stgraber>   - Cleaned up arkose to be fully python3 compatible, PEP-8 clean, updated the testsuite and fixed a bunch of other bugs.
[16:14] <stgraber>   - Reviewed a bunch of merge proposals and patches on the upstream mailing-list.
[16:14] <stgraber>   - Found and fixed a UEFI related bug where mountall was attempting to mount efivars in the container but was blocked by apparmor, leading to unbootable containers.
[16:14] <stgraber>  - Networking
[16:14] <stgraber>   - Looking at reducing the delta between Debian and Ubuntu for bridge-utils. Will add some code to detect upstart-udev-bridge and change the codepath accordingly.
[16:14] <stgraber>  - Other
[16:14] <stgraber>   - Did some (unsuccesful) precise UEFI testing, need to do another batch later today to confirm the issue was fixed.
[16:14] <stgraber>  - TODO
[16:14] <stgraber>   - Continue on the upstart work (including bug 1058029)
[16:14] <stgraber>   - Test precise under UEFI secureboot
[16:14] <stgraber>   - Port arkose to python3-lxc
[16:14] <stgraber> (DONE)
[16:17] <slangasek> "dumping my notebook into Launchpad bugs" - that's a very matrix-esque visual image
[16:18] <slangasek> stgraber: I haven't seen merge proposals come in for those upstart branches?
[16:18] <xnox> stgraber: lxc-device - does this mean i can run full ubiquity install from one fake disk onto another all inside lxc-container?
[16:18] <ev> :)
[16:19] <stgraber> xnox: possibly
[16:19] <slangasek> stgraber: what was the efivars fix?  change to the container config?
[16:19] <xnox> stgraber: sounds like a challenge =)
[16:19] <ev> I should note that the Hadoop deployment is blocked on us providing some long term resolution to the problems webops are seeing with the retracers
[16:19] <stgraber> slangasek: for the upstart branches, I want to get some tests added before I send a merge proposal
[16:19] <slangasek> stgraber: ack
[16:19]  * ogra_ totally fogot to mention that he installed steam on the weekend ... sadly its broken *sniff*
[16:20] <slangasek>  * short week, Thanksgiving vacation
[16:20] <slangasek>  * working through details of our Secure Boot revocation process; discussing whether we need separate prod vs. pre-release signing keys, so a revocation event doesn't have to invalidate our released boot media
[16:20] <slangasek>  * upstart 1.6 is in Debian unstable, blogged, etc.  Still need to fix an intermittent build failure on amd64, somehow nih isn't picking up job files in subdirs, probably a kernel bug to work around
[16:20] <slangasek>  * missed my patch pilot shift this week, will make it up today
[16:20] <slangasek> (done)
[16:20] <stgraber> slangasek: for efivars, yeah, the current fix is to allow lxc to mount it but prevent access to it with apparmor. The proper fix would be to change mountall to make the mount failure non-fatal
[16:20] <slangasek> stgraber: hmm, I don't see why we want mounting of efivars to be treated any differently than mounting of /sys or any of the other virtual filesystems
[16:21] <slangasek> except that it's "optional" and failure to mount due to lack of /support/ is ignored
[16:21] <slangasek> cjwatson: your turn
[16:22] <stgraber> slangasek: well, I'm not sure that mountall not emitting virtual-filesystems if one of the filesystem fails to mount is really a good "feature" as it's essentially preventing your system from booting, maybe mount failures should be considered as if the fs wasn't supported?
[16:22] <cjwatson> oh yes, sorry
[16:22] <cjwatson> Finished initial batch of UEFI Secure Boot backports to precise.
[16:22] <cjwatson> Some easy cross-building fixes.
[16:22] <cjwatson> Backported fix for bug 1001189 to precise.
[16:22] <cjwatson> Finally got round to sponsoring stokachu's appmenu-gtk multiarch work (though still awaiting SRU review - anyone?).
[16:22] <cjwatson> Merged Upstart support into Debian experimental's openssh, and synced it.
[16:22] <cjwatson> Lots and lots and lots of merges.
[16:22] <cjwatson> Fixed broken libnewt.so symlink in libnewt-dev, which broke the cdebconf build on amd64/armhf.
[16:22] <cjwatson> Hacking on germinate in support of work to get signed kernels into 12.04 images (don't ask).  Actually, I think I may have to change Launchpad ...
[16:22] <cjwatson> ..
[16:23] <jodh> * Misc:
[16:23] <jodh>   - Holiday-ette yesterday.
[16:23] <jodh> * Project:
[16:23] <jodh>   - Patch-piloting Monday.
[16:23] <jodh> * Upstart:
[16:23] <jodh>   - Applied fix for 2 bugs found by cking.
[16:23] <jodh>   - Reviewed and applied lp:~vorlon/upstart/fix-environ-order-assumption.
[16:23] <stgraber> slangasek: (sadly there's no magic we can use to have apparmor somehow show a restricted list a filesystem to the contained application, so we can't hide things from /proc/filesystems ...)
[16:23] <jodh>   - bug 1083723 ("'telinit u' has a cage fight with busybox init"): Created a fix. Needs testing.
[16:23] <jodh>   - bug 1079715 ("'telinit u' run from within a chroot causes a crash"): Working on additional tests.
[16:23] <jodh>   - Enhanced User Sessions: Lots of updates to spec
[16:23] <jodh>     (https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions)
[16:23] <slangasek> stgraber: the knock-on effects of having the filesystem not mounted are impossible to determine.  Consider what the boot would be like if the filesystem that failed to mount was /proc
[16:23] <jodh>     and discussions with stgraber and xnox.
[16:23] <jodh>   - Upstart Cookbook updates:
[16:23] <jodh>     http://bazaar.launchpad.net/~upstart-documenters/upstart-cookbook/trunk/changes/
[16:23] <jodh> TODO:
[16:23] <jodh>   - Finish bugs.
[16:23] <jodh>   - Upstart Raring upload.
[16:23] <jodh>   - Get spec updated for PAM stuff.
[16:23] <jodh>   - Review stgrabers 2 upstart branches.
[16:23] <jodh>   - Get onto RaringUpstartUserSessions!!
[16:23] <jodh>   - Nominate bug 1083723 for "Most Amusing Bug Title 2012" award.
[16:24] <slangasek> stgraber: the difference between /proc and efivars is quantitative, not qualitative, AFAICS
[16:24] <jodh> ⎌
[16:24] <jodh>  
[16:24] <slangasek> cjwatson: doing the appmenu-gtk SRU review this morning
[16:24] <stgraber> slangasek: right, question is whether it'd be any worse than what we get currently :) I "think" I'd prefer my system to stil try booting without /proc as unlikely as it's to work, than hang "for sure" in mountall :)
[16:25] <slangasek> stgraber: I think you're taking a container-centric view here; I don't think you'd really want a host system to boot up without /proc
[16:26] <cjwatson> slangasek: ta
[16:26] <slangasek> so I think the right answer is to make the container more like a real system, not to make mountall special-case containers
[16:26] <xnox> slangasek: cjwatson: is there any list of fails to cross-build & essential package for bootstrap? and/or a quick how to test clean cross-building?
[16:26] <cjwatson> xnox: publishing such a list is on my to-do
[16:26] <cjwatson> there's stuff on the linaro wiki about how to set it up locally
[16:26] <xnox> the mk-sbuild kind of has --host support, but it creates chroots with incorrect name =))))
[16:26] <xnox> (sbuild will not find it)
[16:26] <cjwatson> yeah, you can just rename that into place
[16:26] <slangasek> jodh: is the fix for bug 1083723 published where we can look?
[16:27] <cjwatson> I believe the creation docs are linked off foundations-r-aarch64
[16:27] <cjwatson> or I'll be publishing my juju charms in a bit
[16:27] <xnox> cjwatson: ok, I'll have another go at it.
[16:27] <stgraber> slangasek: I'm not sure about that ;) I think I'd prefer a host system to still try to boot without /proc because having a 1% chance of getting a shell to do something about it is better than a 100% chance of being stuck and having to reboot.
[16:27] <stgraber> slangasek: but maybe that's just me being weird
[16:27] <jodh> slangasek: not yet. Will push after the meeting. Approach is to attempt to connect to Upstart via D-Bus and if that succeeds, send the signal, else it's a NOP.
[16:28] <ogra_> stgraber, just make the kernel mount 7proc ... it does that with devtmpfs already :)
[16:28] <ogra_> */proc
[16:28] <slangasek> xnox: how should the chroots be named to make sbuild happy?  I don't think we want them named the same as a native chroot
[16:28] <slangasek> bdmurray: no infinity, so your turn
[16:29] <cjwatson> slangasek: they should in particular not be named after the build architecture :)
[16:29] <bdmurray> updated SRU wiki page regarding time before removal
[16:29] <bdmurray> called for testing of packages in -proposed in oneiric, lucid
[16:29] <bdmurray> modified sru-report to show comments after verification still needed
[16:29] <bdmurray> SRU verification of bug 1076186
[16:29] <bdmurray> updated sru verification opportunities in harvest to use json and appear for more releases
[16:29] <bdmurray> investigation into apport-package missing duplicate signatures
[16:29] <bdmurray> reported and fixed apport bug 1080915 regarding ubuntu general hook
[16:29] <bdmurray> package to team mapping work for foundations-bugs
[16:29] <bdmurray> setting up / testing the error tracker in juju
[16:29] <bdmurray> and some holidays last week
[16:29] <bdmurray> done
[16:29] <cjwatson> slangasek: if you want them named distinct from native chroots you'll need to patch sbuild to support that; or you could just require people use -c raring-armhf-cross or whatever
[16:30] <xnox> slangasek: currently with non-matching build/host sbuild will look for $distro-$hostarch or $distro-$hostarch-sbuild. The mk-sbuild with --host passed creates the chroot as $distro-$buildarch which clashes with native chroot.
[16:30] <cjwatson> slangasek: personally I just call them raring-armhf; the probability of having both native and cross chroots for the same host architecture on the same system is sufficiently small that I don't care
[16:30] <slangasek> cjwatson: oh bah, did I use the build arch by mistake?
[16:30] <cjwatson> yes
[16:31] <slangasek> ogra_: "have the kernel mount /proc" - not the problem at hand
[16:31] <xnox> slangasek: ideally sbuild should learn about $distro-$hostarch-$buildarch in case of multiple cross chroot, but I don't think that's a "typical" user of this =)
[16:32] <xnox> slangasek: cause we currently have native armhf with qemu-static chroots generated by mk-sbuild as e.g. raring-armhf
[16:32] <cjwatson> http://paste.ubuntu.com/1394818/ - the config-changed hook from my current charm
[16:32] <cjwatson> somewhat workaround-heavy
[16:33] <xnox> ack. i'll use --name for now =))))
[16:33]  * slangasek nods
[16:33] <slangasek> doko: here yet?
[16:34] <slangasek> [TOPIC] bugs
[16:34] <slangasek> bdmurray: take it away :)
[16:34] <bdmurray> When I was reviewing old SRUs I noticed some comments regarding lucid and bug 771372
[16:34] <bdmurray> https://bugs.launchpad.net/ubuntu/+source/procps/+bug/771372
[16:35] <jodh> slangasek: lp:~jamesodhunt/upstart/bug-1083723
[16:36] <bdmurray> even though the lucid task is set to Fix Released
[16:37] <slangasek> bdmurray: can you give a comment #?
[16:37] <slangasek> is this #38?
[16:38] <bdmurray> and 40 and 41
[16:38] <jodh> bdmurray: the current solution is the best compromise we could find. See #4 (the full version).
[16:38] <slangasek> ah
[16:39] <bdmurray> jodh: okay, I'll have a look at that comment
[16:39] <slangasek> bdmurray: so #40 would always have been racy and unreliable; the SRU change just turned this from a race into a sure thing
[16:40] <bdmurray> then we have https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1070427
[16:40] <bdmurray> Ubiquity removes kernel headers, fails to build nonfree drivers
[16:43] <cjwatson> Nasty
[16:43] <slangasek> cjwatson: pitti attributes it there to the behavior with signed kernels; too late to fix for quantal, but do you know if this affects the SB enablement backports?
[16:44] <cjwatson> My instinct is also to attribute it to signed kernels, but we may not be correct there
[16:44] <cjwatson> But I'll investigate that as a priority
[16:44]  * slangasek wonders if it's practical to have an integration test for dkms drivers
[16:44] <cjwatson> If it is something to do with that then we'll need to backport, yes
[16:44] <slangasek> possibly one of the non-hardware-specific dkms drivers
[16:45] <slangasek> cjwatson: assign to you for p+r?
[16:45] <cjwatson> already done
[16:45] <cjwatson> well, q+r; I'll create p tasks if necessary
[16:45] <slangasek> oops, already did that :)
[16:46] <slangasek> bdmurray: anything else?
[16:46] <bdmurray> https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1075717
[16:46] <bdmurray> mounted-dev must not re-create consoles in a container
[16:46] <doko> sorry, slept in, getting a cold
[16:46]  * slangasek denies that mountall has any bugs
[16:46] <slangasek> doko: sorry to hear it
[16:47] <xnox> slangasek: we deny your denial =)
[16:47] <ogra_> could that be related to https://bugs.launchpad.net/bugs/960770 ? (there was a dep on the linux-headers packages in dkms before thats gone now)
[16:47] <cjwatson> ogra_: ubiquity has explicit code to handle kernel headers
[16:47] <ogra_> (the ubiquity removes headers thing)
[16:47] <cjwatson> because package-level relationships are in general insufficient to handle it accurately
[16:47] <ogra_> cjwatson, i know check-kernels, but i thought if there is a dep the headers would have kept in place
[16:48] <cjwatson> *shrug* it's a bug anyway ...
[16:48] <ogra_> indeed
[16:48] <slangasek> bdmurray: fixing that mountall bug was backburned on my end because of $obscure_Debian_release_reason; I can take care of it now
[16:48] <slangasek> (assigned)
[16:48] <bdmurray> okay, that's all then
[16:48] <slangasek> cool, thanks
[16:48] <cjwatson> there's no way for dkms to say "use linux-headers-$FLAVOUR depending on the kernel flavour you're using"
[16:48] <slangasek> doko: want to give us a status update?
[16:49] <ogra_> cjwatson, nope, it had "Recommends: fakeroot, menu | sudo, linux-headers-generic-pae | linux-headers-686-pae | linux-headers-amd64 | linux-headers-generic | linux-headers, linux-image"
[16:49] <doko> slangasek, I'll send it by email later
[16:49] <cjwatson> ogra_: yeah, but that was always a ghastly broken hack anyway :)
[16:49] <ogra_> doko, get well
[16:49] <slangasek> doko:
[16:49] <ogra_> yeah, definitely
[16:49] <cjwatson> I don't really care if it's been removed
[16:49] <slangasek> [TOPIC] AOB
[16:49] <slangasek> anything else?
[16:49] <slangasek> doko: "ok", I meant to say :)
[16:51] <jodh> ev: can errors.u.c filter by team?
[16:51] <bdmurray> jodh: not yet
[16:51]  * xnox we have a few things growing on http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-r-tracking-bug-tasks.html
[16:52] <ogra_> were the trendlines on status.u.c already reset ?
[16:52] <slangasek> ogra_: yes, they were
[16:52] <ogra_> bah
[16:53] <ogra_> doesnt take done items into account, feels like i didnt do any work yet
[16:53] <slangasek> heh
[16:53] <slangasek> the done items are shown, above the line :)
[16:53] <slangasek> but yeah, I think it's strange to truncate the graph instead of just resetting the line
[16:53] <slangasek> (but not worth spending effort fixing
[16:53] <slangasek> )
[16:53] <ogra_> yeah, i see them, but my line would be so much steeper if they were below
[16:53] <ogra_> :)
[16:54] <ogra_> (and i'm not serious)
[16:55] <slangasek> #endmeeting
[16:55] <slangasek> I think that's it :)
[16:55] <slangasek> thanks, all
[16:55] <ogra_> thanks !
[16:55] <barry> thanks!
[16:55] <xnox> cheers
[16:55] <stgraber> thanks!
[16:55] <jodh> thanks
[17:41] <Bechir> hello everybody
[20:15] <xnox> bug 1
[20:15] <xnox> at least bug bot will be present for the next meeting we will
[20:16] <xnox> hold in this channel
[20:16] <ogra-cb> great