=== doko_ is now known as doko
[08:03] <cjwatson> popey: Looks like those packages you were asking about were auto-synced last night.
[08:08] <popey> super, thanks cjwatson
[09:00] <jibel> Could someone approve update-manager 1:0.156.14.15 in precise-proposed?
[10:39] <shadeslayer> hmmm, how's the libav transition going?
[10:41] <jibel> cjwatson, ^ would you have time to review/approve update-manager in precise today? we need it for testing hwe eol notifications.
[11:21] <cjwatson> jibel: doing
[11:48] <jibel> cjwatson, thank you
[13:02] <ChrisTownsend> cjwatson: Hi!  You are the SRU vanguard today, correct?
[13:36] <ChrisTownsend> cjwatson: If you saw my previous ping, no need to respond.
[14:25] <cjwatson> http://people.canonical.com/~ubuntu-archive/component-mismatches.html  new toy
[14:25] <cjwatson> (also priority, architecture)
[14:26] <cjwatson> also the next build of http://people.canonical.com/~ubuntu-archive/nbs.html should have a graph
[14:28] <cjwatson> if anyone knows how to make YUI's numeric axes work more sensibly, let me know
[22:27] <utlemming> infintiy, cjwatson: are either of you around?
[22:28] <utlemming> infinity, cjwatson: due to bug #1336855 and the recent Grub SRU for 12.04 anyone running an HVM instance on AWS will lose their instance on reboot.
[22:28] <ubot93> bug 1336855 in cloud-init (Ubuntu) "[SRU] non-interactive grub updates for 12.04 break on AWS" [Critical,Confirmed] https://launchpad.net/bugs/1336855
[22:45] <infinity> utlemming: fun.
[22:46] <utlemming> infinity: yup...and if there is a grub update for 14.04, they'll get burned too
[22:46] <utlemming> infinity: do you have any guidance how to dig out of this hole?
[22:47] <utlemming> infinity: I am leary to put the logic into cloud-init since cloud-init doesn't have a grub dependency
[22:52] <infinity> utlemming: Erm, but the bug is in cloud-init?
[22:53] <utlemming> infinity: right. So what happens is one first boot cloud-init sets a debconf selection for grub-pc "install_devices". Since it doesn't know to look at /dev/xvda and /dev/xvda, grub tries to install to /dev/sda (which is what the images originally had).
[22:53] <infinity> utlemming: Isn't it as simple as making that 1-line change to cc_grub_dpkg.py?
[22:54] <utlemming> infinity: nope. Because that module only runs once.
[22:54] <utlemming> infinity: and then there is the race condition of a user who updates grub and then cloud-init
[22:54] <infinity> utlemming: Then the bug log seems to lie.
[22:55] <utlemming> infinity: adding a better, clarifying comment
[23:01] <utlemming> infinity: clarified the bug
[23:03] <infinity> utlemming: I'm confused how you got in this state in the first place.  Wouldn't have the first run of cloud-init created a broken grub config straight up and this has been wrong since day 1?
[23:04] <utlemming> infinity: the cloud image build process installs grub by hand, since we can't build the images in AWS.
[23:04] <infinity> utlemming: That doesn't really answer my question. :)
[23:05] <infinity> utlemming: Any kernel or grub upgrade would have broken this, so what introduced the bug, and how long has it been broken?
[23:06] <utlemming> infinity: that part I am unsure of. But AWS just reported it. It has been broken since day one. Not having looked, I would guess that grub changed something such that the bits installed on disk don't work with the stuff in /boot/grub.
[23:10] <infinity> utlemming: So, if we really wanted to make this smooth, we could SRU cloud-init with the 1-line fix, and have it conditionally re-run 'cloud-init-cfg grub-dpkg' in its postinst on upgrade from known-broken versions, *and* re-upload a grub SRU with Breaks: cloud-init (<< new_version), forcing cloud-init to upgrade before grub.
[23:11] <infinity> utlemming: I'm not sure having this leak into the grub packaging is really worth the hassle, but if you always want upgrades to work, I'm not sure there's a cleaner way.
[23:11] <utlemming> infinity: I _did_ start to go down that path, but had an issue with the fact that 'cloud-init-cfg grub-dpkg' runs debconf-set-selection, which runs into a debconf lock
[23:12] <infinity> utlemming: Oh, I guess you could re-run grub-install on cloud-init postinst in the same condition that you run cloud-init-cfg grub-dpkg
[23:12] <infinity> utlemming: There should only be a lock if you're running it in a part of your postinst that happens to be debconfy?
[23:13] <utlemming> infinity: the cloud-init postinst is debconf'd, yes
[23:13] <infinity> utlemming: Sure, but not the WHOLE postinst. :)
[23:13] <infinity> utlemming: If nothing else, there's some convenient imaginary whitespace before or after the bits that are.
[23:13] <utlemming> infinity: lol, okay, I'll look at doing that