[14:44] <lamont> arges: around?  can I poke you to process bcache-tools/precise-proopsed out of NEW?
[14:44] <lamont> that way, I can test it and confirm it.
[14:48] <arges> lamont: yes
[14:48] <arges> lamont: looking
[14:49] <lamont> ta
[14:49] <lamont> arges: and then there's bug 1515661
[14:51] <arges> lamont: so this works with precise/3.2 or do you need to use the lts-trusty kernel
[14:51] <arges> bcache that is
[14:53] <lamont> bcache needs the kernel module that hasn't been backported to the precise kernel
[14:54] <lamont> which is acceptable, in that we can document taht you have to use hwe-t kernel
[14:55] <lamont> tbf, I haven't actually checked the stock precise kernel.  let me do that for giggles, but I'm 99% certain that it'll tell me to jump in a lake
[14:55] <arges> lamont: so just to be clear, hwe-t works? or you have to use an out of tree module build?
[14:56] <lamont> hwe-t is demonstrated to work
[14:56] <arges> lamont: ok ok
[14:56] <lamont> though it did require me to use 1515661's kernel/initrd
[14:57] <lamont> which actually means that really testing stock precise with any hope of success needs 1515661 to land along with bcache-tools, and a new daily image...
[14:58] <arges> lamont: so ideally for cloud-initramfs-tools we need bug 1236380 to be verified as well and it should cook in -proposed for 7 days
[15:00]  * lamont pokes smoser about that
[15:00] <arges> infinity: ^^^ since you did the acceptance, is this one of those high prio things we should push out sooner than later? cloud-initramfs-tools in precise
[15:00] <lamont> arges: it's a blocker for maas1.9, which will rc2 this week, if I'm understanding things correctly
[15:01] <arges> lamont: ok good to know
[15:02] <arges> i think at a minimum getting bug 1236380 verified should be done
[15:06] <lamont> arges: so... 1236380 is actually "not fixed, but not regressing anything" -- I'll be updating it shortly with what I think is an actual diff
[15:06] <arges> lamont: ok appreciate it
[15:06] <lamont> but I don't know that we need to reject the promotion on that account
[15:07] <lamont> arges: and I've been schooled.
[15:08]  * lamont doesn't actuallyhave anything to test that with, so it's semi problematic
[15:08] <lamont> and I misread the code.
[15:13] <lamont> arges: trying to make a machine that loves it enoug to exercise that code.  as a side note, regression is highly unlikey, in that every trusty cloud boot since early 2014 has been exercising this very code.
[15:14] <arges> lamont: ack. also not sure if some maas people could also verify too. i'd think some arm hardware might run into this issue more frequently?
[15:14] <arges> but then again probably not running precise
[15:14] <lamont> arges: tbf, I am one of the maas people.
[15:15] <lamont> but yeah, seeing what I can see
[15:15] <arges> lamont: ah. : )
[15:43] <infinity> arges: I don't mind it being fasttracked, if they prove they've tested the three bits that changed.
[15:44] <arges> infinity: ack
[15:48]  * lamont finds a laptop that netboots
[17:07] <lamont> arges: and yeah, stupid sd cards shows up as sdb on the both of hte machines I can test with, so no go for my testing.
[17:08] <arges> lamont: ok
[17:08] <lamont> otoh, I'm willing to believe that it's at least no worse than the prior code wrt 1236380
[17:13] <arges> lamont: ok made a note in the bug to please re-open if verification fails. thanks for attempting to verify this one
[17:17] <lamont> ta
[17:19] <arges> lamont: bcache-tools accepted, so once that hits the archive you can verify.
[17:22] <lamont> arges: woot
[17:22]  * lamont looks forward to dropping his ppa and associated hackery from his last test
[17:24] <lamont> arges: will test in several minutes, since I see it released
[18:44]  * stgraber pokes queuebot, there should be two more of those :)
[18:49] <lamont> can I sweet talk someone into letting django-piston3 out of NEW? (xenial)
[18:58] <stgraber> Laney, micahg: updated lxc backport in trusty-backports queue (two cherry-picks from upstream)
[19:37] <micahg> stgraber: looking