[10:52] <apw> Diziet, as i think you have noticed the timeout has been upped for k.u.c
[12:50] <apw> jibel, hey ... seems that DKMS testing didn't kick for vivid CKT (3.19.0-3.3) last night
[12:57] <apw> tseliot, hey ... we have v3.19 getting close to release now, i see that some of your dkms packages are unhappy (as always)
[13:20] <jibel> apw, I'll have a look
[14:02] <tseliot> apw: I've been working on a new upstream release (that I had pulled from -proposed twice) that includes a fix for 3.18 but I haven't tested 3.19 yet. Is there a PPA for that?
[14:02] <apw> tseliot, it is in the CKT PPA vivid pocket
[14:03] <tseliot> apw: ok, I'll give it a try then
[15:22] <smoser> bjf, i just opened https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1415077
[15:25] <smoser> arges, ^ is the bug for that resize2fs behavior.
[15:31] <bjf> smoser, that needs to be fixed to fix the arm64 image issue?
[15:32] <arges> smoser: thanks
[15:32] <smoser> well... its complicated.
[15:32] <smoser> we're building the maas images on utopic vms. 
[15:32] <smoser> i could put a work aoround in place... to not do the resize you're seeing or just ignore it . 
[15:33] <smoser> we're using utopic because (to my memory) qemu-static on trusty was failing, but i'm not able to reproduce that failure.
[15:41] <arges> smoser: did you try trusty e2fsprogs on utopic yet? 
[15:41] <arges> for that bug
[15:45] <smoser> i'll try that 
[15:48] <arges> smoser: i highly suspect its a userspace thing. trusty vm with lts-utopic kernel also shows the same size as 'trusty/3.13'
[15:50] <smoser> arges, posted info on bug. 
[15:50] <smoser> it is userspace, its purely a regression in the e2fsprogs
[15:51] <smoser> hopefully ted will see this.
[15:51] <smoser> he has been extremely responsive to my e2fsprogs bugs before.
[15:52] <Diziet> apw: git timeout> Still does just the same thing for me.  Did someone forget to reload inetd ?
[15:52] <apw> Diziet, hmmm, now thats a question
[15:53] <apw> Diziet, they did not ... damn
[15:53] <Diziet> Hmmm.
[15:57] <Diziet> Just tried it again and it still fails after almost exactly 2 minutes.
[15:58] <apw> Diziet, yep, damn, poking the appropriate people
[15:59] <Diziet> Thanks.
[16:04] <smoser> bjf, so we would hope to have vivid images available in daily in the next ~30 minutes.
[16:04] <bjf> smoser, cool
[16:18] <jsalisbury> ##
[16:18] <jsalisbury> ## Kernel team meeting today @ 17:00 UTC
[16:18] <jsalisbury> ##
[16:19] <apw> Diziet, ok, it looks to have been restart appropriatly now
[16:53] <arges> smoser: check bug 1415077, I found the first 'bad' commit
[16:55] <smoser> arges, does 'flex_bg' mean something for you?
[16:55] <arges> smoser: so hopefully ted can comment on this, cause yea I don't know : )
[16:56] <jsalisbury> ##
[16:56] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:56] <jsalisbury> ##
[16:56] <apw> isn't flex_bg the thing that lets you populate block groups as they are needed, rather than having to clean them all during mkfs time
[17:00] <ppisati> o/
[17:00] <ppisati> \o
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ## Meeting starting now
[17:00] <arges> ppisati: wrong channel
[17:00] <jsalisbury> ##
[17:00] <arges>  : )
[17:00] <jsalisbury> heh
[17:00] <ppisati> o/\o <- high five
[17:02] <bjf> smoser, do i have an image yet? 
[17:02] <apw> jsalisbury, have you gone pop ?
[17:03] <kamal> ... 'cuz this kteam meeting is dragging on and on and on . . .   ;-)
[17:03] <kamal> ... longest kteam meeting evaaaar
[17:10] <smoser> no. it failed. http://paste.ubuntu.com/9900803/
[17:10] <smoser> so i'm going to allow the arm64 to fail resizing down.
[17:56] <smoser> arges, googling flex_bg and resize2fs seems like this is not the first time.
[17:56] <smoser> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696746
[18:14] <smoser> bjf, 20150127 build of vivid available.
[18:15] <bjf> smoser, if i force my maas to update images will it pull that ?
[18:16] <bjf> smoser, trying
[18:17] <bjf> smoser, i don't think my maas sees anything new
[18:20] <smoser> bjf, you point your maas at daily ?
[18:20] <smoser> also there is a reverse proxy in the way, so... that can be annoying sometimes.
[18:20] <bjf> smoser, yes, daily
[18:21] <smoser> http://paste.ubuntu.com/9902210/
[18:22] <smoser> http://paste.ubuntu.com/9902223/
[18:24] <Diziet> apw: Thanks!  That clone works now.
[18:26] <apw> Diziet, awsome, thanks for the feedback, i am working getting git fixed too
[18:26] <Diziet> Good luck.
[18:33] <bjf> smoser, i was too quick off the blocks. i just updated and it found a new image. trying to install
[18:35] <smoser> horay!
[18:35] <bjf> smoser, it works!
[18:36] <smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1411294 
[18:36] <smoser> ^ that is fixed ?
[18:36] <arges> smoser: so is this related ot the resize2fs issue? or different?
[18:36] <bjf> smoser, yes, that bug is fixed
[18:37] <smoser> bjf, that bug there is overlayroot had a bug that i fixed but no full test.
[18:37] <smoser> so horay
[18:39] <bjf> smoser, are daily image builds still busted or are they fixed as well? (was this a one off to verify that bug is fixed?)
[18:40] <smoser> bjf, well, mostly should be fixed, but right now there is a transient failure in arm64 builds.
[22:34] <alias_neo> Hi guys, anyone willing to answer a few (hopefully) simple questions to help me educate myself?
[22:40] <alias_neo> I'm trying to figure out how I know which modules third party tools might have created/added/installed that i might have to rebuild after a kernel upgrade. I ask because recently, after updating the kernel on my kvm host I had to dpkg-reconfigure libvirt before it would work
[23:40] <alias_neo> Ok, am i really unlucky or does this happen regularly? When i built my kernel with grsec earlier today, the version was 3.14.29, now kernel.org has 3.14.30 but grsec patch doesn't have a 3.14.30 yet