[11:18] <xnox> apw: ogasawara: yo, ms wants some kernel patches for trusty ideally to enable ext2 freezing https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1297012/comments/15
[11:19] <xnox> apw: ogasawara: otherwise hyperv (well azure) cannot freeze/migrate default installs off ubuntu (as it uses ext2 for /boot =( )
[11:19] <xnox> apw: ogasawara: are those ext2 patches in 14.10 or 15.04 kernel yet, or will be? and will they make it into hwe kernel?
[11:32] <apw> xnox, i know they have asked before, so we may well have done so.  though it also depends if we are using ext2 or ext4 to mount ext2 in that context
[11:33] <apw> xnox, oh these are very new bits, so no they won't be currently
[11:34] <xnox> apw: we are using ext2 file format for /boot & we do have CONFIG_EXT4_USE_FOR_EXT23=y, however i don't think that makes ext2 freezable without those patches.
[11:35] <apw> xnox, right, but as you point out they could select something else, rather than a lot of backporting
[11:35] <xnox> apw: i'd rather have kernel changed with those patches, than changing installer default partitioning filesystems in the default configuration in a trusty point release.
[11:35] <apw> as they know it does not work
[11:35] <apw> xnox, it is not clear why they can't preseed it
[11:36] <xnox> apw: it's not up to them to select. but for the guest-os / any client workload on azure.
[11:36] <xnox> apw: it seems that telling all users to do something else doesn't work.
[11:36] <xnox> (well ubuntu based client custom images)
[11:36] <apw> xnox, right but the only reason this is a problem is because they believe they can make a consistant snapshot of the machine if they freeze it, which btw, i think is flawed thinking
[11:37] <apw> xnox, the images most people use on azure are supplied by us, this would be hyper-v on a local install only prety much
[11:37] <xnox> apw: i do hope they are not exposing that to people, when they clearly see a given VM is not freezable.... i hope they only do so when they think they actually can do it.
[11:37] <xnox> apw: right, ENOCLUE.
[11:38] <xnox> apw: i haven't looked into partman-auto enough, hopefully we can make /boot ext4 without journaling / extents / etc. (e.g. more like an ext2 thing)
[11:38] <xnox> such that it becomes freezable, but we don't need to increase it's disk space.
[11:38] <apw> the unfreezability looks to be related to not having a journal
[11:38] <xnox> also we should finally make grub2 not require /boot for just lvm2 based installs, as it can parse things off it.
[11:38] <xnox> =(
[11:38]  * xnox does not want /boot with a journal.....
[11:41] <apw> xnox, on my boxes i have no /boot on my lvm installs, no idea why we need it
[11:42] <apw> xnox, it is not clear whether this second fix would stand alone, it might well do
[11:45] <xnox> apw: hm, maybe cjwatson fixed that already....
[11:45] <xnox> apw: i'll make a note to self to retest that.
[11:45] <apw> cirtainly i have what i think is a P install using it, you need a 2048 block aligned first cylinder sort of thing else there isn't room in the gap for grub
[11:48] <apw> xnox, so this is for .2 right?  so will be with an lts-u kernel ?
[11:49] <apw> we'd not care for anything older i presume
[11:49] <xnox> apw: well if those ext2 patches are in u's kernel, then yeah lts-u-hwe / .2 target is good.
[11:49] <xnox> apw: if those patches are only in v's kernel, then we are looking at .3 target.
[11:50] <xnox> apw: and i don't have ubuntu kernels cloned here to confirm which kernel those patches are in, if at all, and/or need cherry-picking.
[11:51] <apw> they are 3.18-rc3 so very new, not in anything at all right now
[12:09] <xnox> apw: cherrypick!!!! what could possibly go wrong?! =)
[12:10] <apw> xnox, heh, we shall see if they even build, let alone work
[12:10] <xnox> apw: cause 3.17/3.18 are so wonderful with all the regressions since 3.16..... =))))
[12:19] <apw> xnox, 3.18 isn't feeling toooo bad to me
[12:19] <xnox> apw: i'm on 3.17.4 on my dev hardware and "i don't like it" (big brother quote)
[12:20] <xnox> apw: using stock 14.04 LTS otherwise everywhere as it's the release i can trust =) after all the things i broke for 14.10 ;-)
[12:20]  * xnox wishes for my SRUs to be accepted.....
[13:43] <cking> amitk, i just tried to send some idlestat patches to sched-tools@linaro.org and my mailer complained it did not exist
[14:01] <amitk> cking: I see the patches....
[14:01] <cking> amitk, yep, I cc'd you on them ;-)
[14:02] <cking> amitk, do you have access to the coverity scan for idlestat? there are a bunch more issues that need fixing that I wasn't so sure about the best way to fix them
[14:03] <amitk> cking: I think you subscribed me to the report, I saw it today
[14:04] <amitk> cking: I'll look at the sched-tools alias later today, thanks for reporting. And thanks for the patches.
[14:04] <cking> ok, cool, just wanted to keep you in the loop about the outstanding issues ;-)
[14:04] <amitk> cking: much appreciated
[14:05] <cking> amitk, BTW, idlestat still could do with a man page ;-)
[14:16] <amitk> cking: honestly speaking it will probably happen only when we stop changing the options so much. Every few patches we change the behaviour a little. Lack of a spec, I guess
[14:16] <amitk> cking: but if you file a bug on bugs.linaro.org, atleast it'll stay on the radar
[14:17] <cking> okay will do
[15:49] <jsalisbury> ##
[15:49] <jsalisbury> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:49] <jsalisbury> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[15:49] <jsalisbury> ##
[16:56] <jsalisbury> ##
[16:56] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:56] <jsalisbury> ##
[19:51] <kgunn> ogasawara: hey curious, we've recently been discussing how to automate some testing for rotation
[19:52] <kgunn> curious if there is some known kernel tool/trick that could be used to 
[19:52] <kgunn> inject sensor events, e.g. mock rotation/orientation sensor firing
[19:53] <ogasawara> kgunn: I don't know anything off the top of my head, but let me sync with my guys and get back to you
[23:25]  * xnox finally realised that brad-figgs bot is launchpad's equivalent of "please hold the line, your call is very important to us"
[23:26] <xnox> and then the call center closes and unanswered calls are just left playing that message =))))