=== hughhalf_ is now known as hugh_afk === hugh_afk is now known as hughhalf === pgraner-gym is now known as pgraner-afk === gerald is now known as Guest47666 [10:52] Diziet, as i think you have noticed the timeout has been upped for k.u.c [12:50] jibel, hey ... seems that DKMS testing didn't kick for vivid CKT (3.19.0-3.3) last night [12:57] 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] apw, I'll have a look === FreezingDroid is now known as FreezingCold [14:02] 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] tseliot, it is in the CKT PPA vivid pocket [14:03] apw: ok, I'll give it a try then === dannf` is now known as dannf === pgraner-afk is now known as pgraner [15:22] bjf, i just opened https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1415077 [15:22] Launchpad bug 1415077 in e2fsprogs (Ubuntu) "resize2fs behavior differs greatly between trusty and utopic and vivid" [Medium,Confirmed] [15:25] arges, ^ is the bug for that resize2fs behavior. [15:31] smoser, that needs to be fixed to fix the arm64 image issue? [15:32] smoser: thanks [15:32] well... its complicated. [15:32] we're building the maas images on utopic vms. [15:32] i could put a work aoround in place... to not do the resize you're seeing or just ignore it . [15:33] 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] smoser: did you try trusty e2fsprogs on utopic yet? [15:41] for that bug === caribou_ is now known as caribou [15:45] i'll try that [15:48] 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] arges, posted info on bug. [15:50] it is userspace, its purely a regression in the e2fsprogs [15:51] hopefully ted will see this. [15:51] he has been extremely responsive to my e2fsprogs bugs before. [15:52] apw: git timeout> Still does just the same thing for me. Did someone forget to reload inetd ? [15:52] Diziet, hmmm, now thats a question [15:53] Diziet, they did not ... damn [15:53] Hmmm. [15:57] Just tried it again and it still fails after almost exactly 2 minutes. [15:58] Diziet, yep, damn, poking the appropriate people [15:59] Thanks. [16:04] bjf, so we would hope to have vivid images available in daily in the next ~30 minutes. [16:04] smoser, cool [16:18] ## [16:18] ## Kernel team meeting today @ 17:00 UTC [16:18] ## [16:19] Diziet, ok, it looks to have been restart appropriatly now [16:53] smoser: check bug 1415077, I found the first 'bad' commit [16:53] bug 1415077 in e2fsprogs (Ubuntu) "resize2fs behavior differs greatly between trusty and utopic and vivid" [Medium,Confirmed] https://launchpad.net/bugs/1415077 [16:55] arges, does 'flex_bg' mean something for you? [16:55] smoser: so hopefully ted can comment on this, cause yea I don't know : ) [16:56] ## [16:56] ## Kernel team meeting in 5 minutes [16:56] ## [16:56] 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] o/ [17:00] \o [17:00] ## [17:00] ## Meeting starting now [17:00] ppisati: wrong channel [17:00] ## [17:00] : ) [17:00] heh [17:00] o/\o <- high five [17:02] smoser, do i have an image yet? [17:02] jsalisbury, have you gone pop ? [17:03] ... 'cuz this kteam meeting is dragging on and on and on . . . ;-) [17:03] ... longest kteam meeting evaaaar === apw is now known as jsalisbury === jsalisbury is now known as apw [17:10] no. it failed. http://paste.ubuntu.com/9900803/ [17:10] so i'm going to allow the arm64 to fail resizing down. === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 3rd, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! If the question is should I file a bug for something, likely you can assume yes. [17:56] arges, googling flex_bg and resize2fs seems like this is not the first time. [17:56] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696746 [17:56] Debian bug 696746 in e2fsprogs "resize2fs: The combination of flex_bg and !resize_inode features is not supported by resize2fs" [Normal,Fixed] === staticve1tor is now known as staticvector [18:14] bjf, 20150127 build of vivid available. [18:15] smoser, if i force my maas to update images will it pull that ? [18:16] smoser, trying [18:17] smoser, i don't think my maas sees anything new [18:20] bjf, you point your maas at daily ? [18:20] also there is a reverse proxy in the way, so... that can be annoying sometimes. [18:20] smoser, yes, daily [18:21] http://paste.ubuntu.com/9902210/ [18:22] http://paste.ubuntu.com/9902223/ [18:24] apw: Thanks! That clone works now. [18:26] Diziet, awsome, thanks for the feedback, i am working getting git fixed too [18:26] Good luck. [18:33] smoser, i was too quick off the blocks. i just updated and it found a new image. trying to install [18:35] horay! [18:35] smoser, it works! [18:36] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1411294 [18:36] Launchpad bug 1411294 in cloud-initramfs-tools (Ubuntu) "kernel panic during MAAS fastpath install of Vivid images" [High,Fix released] [18:36] ^ that is fixed ? [18:36] smoser: so is this related ot the resize2fs issue? or different? [18:36] smoser, yes, that bug is fixed [18:37] bjf, that bug there is overlayroot had a bug that i fixed but no full test. [18:37] so horay [18:39] 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] bjf, well, mostly should be fixed, but right now there is a transient failure in arm64 builds. === staticvector is now known as tdmackey === yp is now known as ypwong === _Traxer is now known as Traxer === apw_ is now known as apw [22:34] Hi guys, anyone willing to answer a few (hopefully) simple questions to help me educate myself? === swordsmanz is now known as hugbot [22:40] 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] 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