18:00:09 <jwb> #startmeeting
18:00:09 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:14 <jwb> #meetingname fedora-kernel
18:00:14 <zodbot> The meeting name has been set to 'fedora-kernel'
18:00:23 <jwb> #meetingtopic Fedora Kernel
18:00:30 <jwb> #topic roll call
18:00:35 * jforbes is here
18:00:48 * codemaniac is here
18:00:51 * brunowolff is lurking
18:01:27 <jwb> davej will be along in a sec i'm sure
18:01:45 <jwb> #topic F18
18:02:05 <jwb> we're going to skip the normal full release overview today.  f16 and f17 really haven't had much change
18:02:19 <jwb> F18 Alpha is finally ready to go.  hooray!
18:02:25 <jwb> except it's using an rc2 kernel
18:02:50 <jwb> 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 <jwb> i know of one outstanding patch for a nouveau bug that adamw reported we still have to pick up
18:03:26 <adamw> the one airlied fixed? yeah, that would be really useful
18:03:29 <jwb> yes
18:03:42 <davej> 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 <jwb> 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 <jwb> heh
18:03:59 <jforbes> hopefully linus will just pick it up, airlied sent the pull request which included it
18:04:03 <jwb> yeah
18:04:22 <brunowolff> Is F18 going to stay on 3.6 to release?
18:04:25 <jwb> yes
18:04:36 <jwb> well, for Gold anyway.  it'll get rebased eventually
18:04:40 <jforbes> well, until it doesnt
18:04:54 <brunowolff> That's what I meant.
18:05:08 <jwb> #info F18 Alpha using 3.6-rc2 kernel.  Will get -rc5/-rc6 pushed out soon
18:05:19 <jwb> #info F18 GA will stick with the 3.6 release
18:05:58 <jwb> 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 <jwb> #topic Kernel Summit/Linux Plumbers overview
18:06:25 <jwb> i'll start with modsigning
18:07:01 <jwb> we "discussed" modsigning with David Howells, Rusty Russell and Dmitry from Intel
18:07:16 <jwb> basically, modsigning will get into the upstream kernel.  perhaps for 3.7
18:07:19 <jwb> that's good news
18:07:30 <jwb> the bad news is that it isn't the modsigning code we've been using forever
18:07:55 <jwb> 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 <jwb> 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 <jwb> the premise and policy of signed modules are staying the same, just the implmentation is different
18:09:04 <jwb> 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 <jwb> #action jwb to clean up and send new modsigning patches to fedora kernel list after testing
18:09:43 <jwb> any questions on modsign?
18:10:13 <jwb> jforbes, you want to cover the idea of reports to stable?
18:11:24 <jforbes> 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 <jforbes> 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 <jwb> 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 <jforbes> 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 <jforbes> 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 <jwb> btw, the stable list is actually a list if anyone wants to subscribe there now
18:16:41 <jwb> they made that change a while ago, post-kernel.org break-in
18:17:24 <jwb> #info kernel maintainers will start sending "patches we carry" emails to the stable tree maintainers
18:18:27 <jwb> ok, i think that's about it for an overview from KS/LPC
18:18:38 <jwb> #topic Open Floor
18:18:45 <jwb> anyone have any questions/concerns?
18:21:49 <jwb> i'm concerned we never have any questions
18:22:13 <brunowolff> What kinds of questions are you looking for?
18:22:47 <jwb> 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 <davej> maybe we need to start saying more controversial things to incite some feedback
18:24:22 <jwb> #info we could still use active testing on older Fedora releases
18:24:47 <jwb> 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 <davej> we don't do that already ?
18:25:07 <jwb> not intentionally
18:25:11 <davej> heh
18:26:01 <jwb> ok, if there's nothing else anyone wants to discuss, i'll close the meeting out in 3 min
18:26:03 <brunowolff> 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 <davej> top of dmesg on each should show the gcc version
18:26:32 <jwb> yeah
18:26:41 <jwb> or look in koji at the root.log
18:27:10 <brunowolff> That is more likely than a change to the gcc options, so is worth checking.
18:27:46 <davej> f11.. that takes me back
18:27:53 <brunowolff> I have a motherboard sound issue that started occuring between the two builds (and continues today), but the change between
18:28:15 <brunowolff> the builds appears to just be a dropped patch that shouldn't be abble to trigger the problem.
18:28:47 <davej> alsa bugs are kind of a sore point for us.
18:28:58 <davej> we could do a better job at upstreaming some of those.
18:29:02 <brunowolff> So I am thinking maybe code generation was changed between the two builds.
18:29:29 <davej> brunowolff: it's not uncommon for an alsa update to fix one chip and break another in our experience.
18:30:22 <brunowolff> 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 <davej> huh, weird
18:30:45 <brunowolff> (Or in a part of the network that would likely affect the issue.)
18:31:16 <jwb> network meaning "series of code interactions" there, right?
18:31:28 <brunowolff> 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 <brunowolff> and there is significant network traffic at the same time motherboard sound is being used.
18:33:49 <brunowolff> 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 <brunowolff> 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 <brunowolff> 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 <jwb> have you reported this to the alsa people upstream?
18:35:56 <brunowolff> 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 <brunowolff> 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 <davej> they were talking recently about changing their bug tracking as their own on alsa-project went down
18:41:52 <brunowolff> 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 <brunowolff> But otherwise the bug didn't generate any interest.
18:42:32 <jwb> Takashi is the main alsa maintainer
18:42:37 <jwb> he'd be the person to work with
18:43:37 <brunowolff> OK. He's cc'd, so if I find more useful information, he should get a notice of the change.
18:43:46 <jwb> ok, so sounds like you're doing all the right things.  thanks for bringing it up during the meeting :)
18:44:00 <jwb> we should probably close out before the cloud-sig shows up
18:44:10 <jwb> thanks for coming everyone
18:44:12 <jwb> #endmeeting