18:00:09 #startmeeting 18:00:09 Meeting started Fri Sep 14 18:00:09 2012 UTC. The chair is jwb. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:09 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:14 #meetingname fedora-kernel 18:00:14 The meeting name has been set to 'fedora-kernel' 18:00:23 #meetingtopic Fedora Kernel 18:00:30 #topic roll call 18:00:35 * jforbes is here 18:00:48 * codemaniac is here 18:00:51 * brunowolff is lurking 18:01:27 davej will be along in a sec i'm sure 18:01:45 #topic F18 18:02:05 we're going to skip the normal full release overview today. f16 and f17 really haven't had much change 18:02:19 F18 Alpha is finally ready to go. hooray! 18:02:25 except it's using an rc2 kernel 18:02:50 this seems to have been working well enough for now, but we'll want to get rc5 (or rc6) pushed out to stable relatively soon 18:03:09 i know of one outstanding patch for a nouveau bug that adamw reported we still have to pick up 18:03:26 the one airlied fixed? yeah, that would be really useful 18:03:29 yes 18:03:42 the incoming f18 bugs so far have been pretty dull. it'll be interesting to see the fallout when people start testing the alpha. 18:03:47 aside from that, i think we're playing a bit of a waiting game to see if bugs get reported from Alpha 18:03:52 heh 18:03:59 hopefully linus will just pick it up, airlied sent the pull request which included it 18:04:03 yeah 18:04:22 Is F18 going to stay on 3.6 to release? 18:04:25 yes 18:04:36 well, for Gold anyway. it'll get rebased eventually 18:04:40 well, until it doesnt 18:04:54 That's what I meant. 18:05:08 #info F18 Alpha using 3.6-rc2 kernel. Will get -rc5/-rc6 pushed out soon 18:05:19 #info F18 GA will stick with the 3.6 release 18:05:58 so F18 is also carrying some things for Secure Boot, like module signing. i think that's a good lead into the next topic 18:06:17 #topic Kernel Summit/Linux Plumbers overview 18:06:25 i'll start with modsigning 18:07:01 we "discussed" modsigning with David Howells, Rusty Russell and Dmitry from Intel 18:07:16 basically, modsigning will get into the upstream kernel. perhaps for 3.7 18:07:19 that's good news 18:07:30 the bad news is that it isn't the modsigning code we've been using forever 18:07:55 i've been poking at reworking the patches we're carrying the past couple of days. hopefully i have something that will work now 18:08:10 i'll send out some patches to the fedora kernel list after i clean them up and test out the resulting builds 18:08:36 the premise and policy of signed modules are staying the same, just the implmentation is different 18:09:04 hopefully though, third party repositories providing kmods will be able to sign things in a standard cross-distro way as a result 18:09:36 #action jwb to clean up and send new modsigning patches to fedora kernel list after testing 18:09:43 any questions on modsign? 18:10:13 jforbes, you want to cover the idea of reports to stable? 18:11:24 Right, so in the interest of playing well with the stable kernel series (and dropping patches from our rpm) We are going to start submitting "patches we carry" emails after stable kernel releases 18:12:44 Essentially, every stable release we can send the list of patches we are still carrying, why they are relevant, and pointers to the upstream commits to make sure they are not missed for the next stable release 18:13:19 i think that will help make sure we aren't carrying things we don't need to be, or that should get cleaned up and sent upstream too 18:13:42 We do have a few patches that we carry that are not upstream yet as well, and those will get sent to lkml with what we are carrying and why in hope that they will also make it 18:14:47 We don't really carry patches without reason, so hopefuly this process will benefit upstream, and greatly limit the number of patches we are carrying 18:16:28 btw, the stable list is actually a list if anyone wants to subscribe there now 18:16:41 they made that change a while ago, post-kernel.org break-in 18:17:24 #info kernel maintainers will start sending "patches we carry" emails to the stable tree maintainers 18:18:27 ok, i think that's about it for an overview from KS/LPC 18:18:38 #topic Open Floor 18:18:45 anyone have any questions/concerns? 18:21:49 i'm concerned we never have any questions 18:22:13 What kinds of questions are you looking for? 18:22:47 anything really. i mean, i don't mind this meeting being a status report, but i'm not sure anyone actually gets value out of it 18:24:17 maybe we need to start saying more controversial things to incite some feedback 18:24:22 #info we could still use active testing on older Fedora releases 18:24:47 davej, maybe next time i'll mention my plan to actively break all out of tree modules on a per-build basis 18:25:00 we don't do that already ? 18:25:07 not intentionally 18:25:11 heh 18:26:01 ok, if there's nothing else anyone wants to discuss, i'll close the meeting out in 3 min 18:26:03 OK, here is one. Is there a way I can tell from two kernel installs from the F11 era, if there was either a change in build options or if gcc changed between builds/ 18:26:24 top of dmesg on each should show the gcc version 18:26:32 yeah 18:26:41 or look in koji at the root.log 18:27:10 That is more likely than a change to the gcc options, so is worth checking. 18:27:46 f11.. that takes me back 18:27:53 I have a motherboard sound issue that started occuring between the two builds (and continues today), but the change between 18:28:15 the builds appears to just be a dropped patch that shouldn't be abble to trigger the problem. 18:28:47 alsa bugs are kind of a sore point for us. 18:28:58 we could do a better job at upstreaming some of those. 18:29:02 So I am thinking maybe code generation was changed between the two builds. 18:29:29 brunowolff: it's not uncommon for an alsa update to fix one chip and break another in our experience. 18:30:22 But the two builds where the problem didn't appear and first appeared seem to only differ in the source with a single dropped patch, that wasn't ALSA related. 18:30:40 huh, weird 18:30:45 (Or in a part of the network that would likely affect the issue.) 18:31:16 network meaning "series of code interactions" there, right? 18:31:28 The problem appears to be locking related and happens if I have two cpus enabled (sometimes only one gets enabled at boot) 18:31:55 and there is significant network traffic at the same time motherboard sound is being used. 18:33:49 It's a wierd problem. Mostly I don't care since I use my logitech headset for sound, but occasionally that stops working for a while when 18:34:23 new kernel bugs are introduced and then I want to use the motherboard sound until the bug gets fixed, so I think about trying to 18:34:58 track things down. This last time I went back and reinstalled f11 to track down at which Fedora kernel the problem first started. 18:35:42 have you reported this to the alsa people upstream? 18:35:56 I was hoping to find some obvious difference, but that didn't turn out to be the case if I properly figured out what the difference between the builds was. 18:36:45 There is a bug reported in Fedora and the kernel.org bugzilla. I don't know if the ALSA people use that a lot though. 18:37:19 they were talking recently about changing their bug tracking as their own on alsa-project went down 18:41:52 The bug is https://bugzilla.kernel.org/show_bug.cgi?id=36242 . I did get one question from a name I recognize as someone who worked on the recent headset problem I had. 18:42:08 But otherwise the bug didn't generate any interest. 18:42:32 Takashi is the main alsa maintainer 18:42:37 he'd be the person to work with 18:43:37 OK. He's cc'd, so if I find more useful information, he should get a notice of the change. 18:43:46 ok, so sounds like you're doing all the right things. thanks for bringing it up during the meeting :) 18:44:00 we should probably close out before the cloud-sig shows up 18:44:10 thanks for coming everyone 18:44:12 #endmeeting