[00:10] <ohsix> infinity: what do you do to unmount a / that you're currently using, just dont? mount it ro and hope it doesn't fail?
[00:12] <ohsix> the 'reason' things are copied to an initramfs at all is because you need them to prepare /, you also need the same tools to 'unprepare' it; having them somewhere in the / you eventually mount is the same problem that you have an initramfs for in the first place, finding the things to mount /
[00:13] <ohsix> pivoting back just keeps the entire responsibility for it in the initramfs, it can also unmount things cleanly because it's still not on /
[00:14] <ohsix> and even disregarding network or weirder filesystems for /, any given local filesystem is going to vary in how cleanly remount -o ro / is going to be at shutdown, so you depend implicitly on the behaviour of any existing and future filesystem behaviour
[00:15] <ohsix> i like the term vortex rather than some allusion to a force that can't exist, btw
[00:15] <ohsix> there are a lot of people being introduced to these problems for the first time, and not many of them are choosing to know or care about them
[01:37] <mozmck> apw: thanks for the information.  so I'm guessing the vivid kernel at the v3.18.7 would be the closest to 3.18.9?
[01:39] <mozmck> preempt-rt has a patch for 3.18.9 and one for 3.14.34, as well as some older ones, but I would like to use the latest patch.
[09:46] <taihsiang> henrix, the kernel version looks weird if I enable -proposed to try to run few SRU test
[09:46] <taihsiang> henrix, for example:
[09:46] <taihsiang> henrix, 3.13.0-46-generic #79~precise1-Ubuntu SMP Tue Mar 10 20:25:33 UTC 2015
[09:47] <taihsiang> henrix, 3.13.0-47-generic #78~precise1-Ubuntu SMP Thu Mar 5 15:38:11 UTC 2015
[09:47] <taihsiang> henrix, 3.13.0-47 is not there anymore, and 3.13.0-46 has newer built stamp
[09:48] <taihsiang> henrix, this issue block me to perform certification part of SRU
[09:49] <henrix> taihsiang: correct, that's because 3.13.0-46.79 was a security fix kernel.  we had to respin early this week
[09:49] <henrix> taihsiang: this should be fix soon, i'm currently working on respinning the kernels again
[09:50] <henrix> taihsiang: the -47.78 kernel had to be dropped from -proposed and replaced by the security fix kernel
[09:51] <taihsiang> henrix, ok, that sounds great. one more question: so only precise(lts-trusty-backport) and trusty has such security fix and respinning?  
[09:51] <henrix> taihsiang: no, *all* the kernels have that fix
[09:51] <taihsiang> henrix, e.g. how about precise(3.2) and utopic?
[09:51] <taihsiang> henrix, oops, understood, thanks!
[09:51] <henrix> taihsiang: np
[10:04] <taihsiang> henrix, are we going to skip  the certification test of the upcoming security-fixed kernel because the kernel team may want to  release the security-fixed kernel as early as possible?
[10:05] <taihsiang> henrix, or the kernel team would like to release the security-fix kernel as the original SRU cycle date? (21 Mar) Then the certification team could have time to have certification test.
[10:07] <henrix> taihsiang: the security kernel has been released already; i believe certification testing will run on the kernels that will be in proposed later this week, for this SRU cycle
[10:08] <taihsiang> henrix, I see, thanks.
[13:57] <infinity> zequence: There's a new precise kernel spinning up shortly, FWIW.
[13:57] <infinity> zequence: You'll have a bug number later tonight, I suspect.
[15:30] <ricotz> sforshee, hi :), is there an eta for trusty-backport of 3.16.0-33.44?
[15:43] <henrix> ricotz: the utopic 3.16.0-33.44 is still building, so it will take a while.  i would say that tomorrow it will be in -proposed
[15:53] <cking> amitk, is a new tag'd version of idlestat coming out soon?
[15:56] <ricotz> henrix, ok, thanks
[15:57] <amitk> cking: I've been thinking about tagging this one. I need to run a few more tests to ensure it is stable enough
[15:57] <amitk> cking: we've already added several new features
[15:57] <cking> even it it's a 0.5.1 or something, it looks kinda useful with the new features and man page
[15:58] <cking> *if it's
[15:58] <amitk> cking: ack, let me do some more testing over the weekend and I'll tag it next week
[15:59] <cking> that's great, no rush
[16:01] <smb> infinity, Do you know from the top of your head what apt is doing when it "configures" a package as opposed to "unpacking" it? I am having a peek on fixing the false dkms failures and finding it a tad more complex than initially thought. I would imagine configuring runs a package post-inst. Or is there more? 
[16:02] <infinity> smb: configure is "postinst configure", yes.
[16:03] <smb> Ok, so I have to check what magic the headers do there... thanks
[16:03] <infinity> smb: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
[16:03] <infinity> smb: See 6.6 for the ordering.
[16:03] <smb> infinity, cool. ta
[16:21] <smb> infinity, Hm... one starts to wonder why there is a hook for dkms in kernel/postinst.d at all... The one in header_postinst.d probably should be enough...
[16:22] <infinity> smb: Probably.  Are you looking into the bug we were talking about the other day?
[16:22] <smb> infinity, yeah (with other day being last week)
[16:23] <infinity> smb: I still think the fix I suggested should be made anyway.
[16:23] <smb> infinity, So I looked today at the term.log of an upgrade that produced false positives. And saw that basically those fails all came from kernel postinst runs
[16:23] <infinity> smb: But you may be right that the hook doesn't need to live in both places.
[16:24] <smb> The problem is that the headers are unpacked at that stage, so the checks for existing directories fail to detect anything wrong
[16:26] <smb> The check we miss by exec is actually done in the dkms script again... so any echo is a duplicate. The only advantage would be that then the exit would be the rc code from the echo... 
[16:27] <smb> but then the only sucessful run is the one in the headers_postinst... so *shrug*
[16:39] <infinity> smb: Yeah, perhaps just removing the kernel image one is enough, then.
[16:39] <smb> infinity, yep, typing a patch as we type..err speak
[16:40] <smb> infinity, btw, we are past the "magic" time
[16:42] <infinity> smb: \o/
[16:42] <infinity> smb: Time to find my decapulator.
[17:02] <zequence> infinity: Alright, thanks.
[17:44] <absk007> does the standard kernel support Flash file systems? https://en.wikipedia.org/wiki/Flash_file_system#Linux_flash_filesystems
[17:44] <absk007> i want to run lubuntu in microSD card without wearing it out
[17:55] <absk007> which flash FS is good?
[20:33] <infinity> zequence: http://launchpad.net/bugs/1431501 is your new bug, FWIW.