18:00:12 <jforbes> #startmeeting Fedora Kernel Meeting
18:00:12 <zodbot> Meeting started Fri Apr 13 18:00:12 2012 UTC.  The chair is jforbes. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:28 <jforbes> everyone ready?
18:00:34 <jwb> yep
18:00:41 <jforbes> #addchair jwb davej
18:00:44 <davej> word
18:01:07 <jforbes> Great lets get started with releases
18:01:13 <jforbes> #topic F15
18:01:18 <davej> I'll do 15
18:01:45 <davej> biggest problem there right now is that updates are languishing in updates-testing too long, so they keep getting obsoleted by the next build.
18:02:10 <davej> I closed out a bunch of old bugs earlier this week, and when 3.3.x finally gets to updates proper, I bet we'll be able to close a lot more
18:02:41 <jforbes> Sadly this has been a problem for almost all F15 packages, there just aren't testers.  But we move fast enough that we never see the timeout which lets us push
18:03:05 <davej> I think lowering the karma requirements is the only way we can win this
18:03:56 <jforbes> I don't have a problem with that.  Essentially if we don't do it, we just have to wait for a timeout before submitting the next.  the end result is slower fixes to F15, but the same amount of testing
18:04:15 <davej> yeah, I don't think waiting really solves anything
18:04:33 <jwb> me either
18:04:45 <davej> so, bug count for 15 is just over 300. hoping to get it under that next week.
18:05:09 <davej> and then maybe do something about 16, because that's getting a bit out of control again
18:05:11 <pjones> in the past, fesco has encouraged - through, for example, the new (at the time) updates policy - doing fewer updates on older distros unless there are security problems.
18:05:12 <jforbes> # info Karma threshold for F15 updates to be lowered because we just don't get testers
18:05:27 <davej> (weekly bug count stats at http://codemonkey.org.uk/2012/04/13/weekly-fedora-kernel-bug-statistics-april-13-2012 btw)
18:06:29 <davej> pjones: then we end up with kernels like fedora 14. which just isn't something any of us want to deal with again
18:06:49 <pjones> fair.
18:06:50 <jforbes> pjones: the thing is, the bugs are there.  F15 is on the same version as F16 right now, so we have users, bugs are getting fixed
18:07:25 <jforbes> Okay, anything else on F15?
18:07:55 <davej> not from me
18:08:06 <jforbes> #topic F16
18:08:17 <jforbes> jwb: you want to take this one?
18:08:21 <jwb> sure
18:08:40 <jwb> F16 was upgraded to 3.3.1 recently.  It should pick up 3.3.2 later today
18:08:46 <jwb> we had a couple of regressions of note
18:08:50 <jwb> 1) ath9k
18:08:58 <jwb> 2) dvb stuff
18:09:09 <jwb> 3) ALSA for various thinkpad models/docking stations
18:09:19 <jwb> the good news is that we're making progress on all 3
18:09:39 <jwb> the ath9k issue seems to be solved by reverting a commit that wound up in 3.3.1 and John has a handle on it
18:10:08 <jwb> Mauro brought in a number of fixes for the dvb issues and that kernel is actually queued to go to stable today
18:10:54 <jforbes> excellent, anything else on F16?
18:10:56 <davej> I've noticed we're not getting any new suspected memory corruption bugs on the latest updates. We're still getting reports, but they're old builds.
18:10:59 <jwb> the ALSA stuff is still being worked, but upstream seems to be really responsive right now and hopefully we'll narrow down a fix soon.  in the meantime, people that hit the issue should be able to specify 'model=thinkpad' for the hda driver and have it work
18:11:06 <davej> with the exception of unlock_new_inode
18:11:15 <davej> that still seems to be a problem for some people.
18:11:24 <jwb> davej, yeah, the i915 fix seems to have worked by and large
18:11:47 <davej> jwb: might be worth going through the kernel_hibernate list in a week or two and just closing out the suspect ones
18:12:47 <jwb> yeah, quite possibly
18:13:01 <jforbes> I think with ath9k, dvb, and alsa on thinkpad taken care of, plus closing out some of the old i915 bugs, we should be in much better shape
18:13:13 <jforbes> that's not a small number of bugs with those 4
18:13:26 <jwb> right
18:13:43 <jforbes> Okay, anything else on F16?
18:13:48 <davej> there's still quite a few iwl bugs too, but that never changes
18:14:50 <jforbes> okay, on to 17
18:14:54 <jforbes> #topic F17
18:14:56 <jwb> i'll cover that one too
18:15:07 <jwb> basically, everything I said for F16 applies to F17
18:15:16 <jwb> they're almost identical kernels
18:15:39 <jwb> the one thing i can think of that we added for F17, is that RC6 should be enabled on i915 graphics chips by default now
18:15:41 <davej> will be interesting to see if f17 beta finds bugs that aren't showing up on 15/16
18:15:54 * swhiteho standing by for thoughts on kernel-modules-extra
18:16:11 <jwb> knurd_afk pointed out the upstream commits for that, and we backported them to f17.  i've been running it locally without any lockups
18:16:19 <brunowolff_> f17 kernels have been running fine for me.
18:16:23 <jwb> should make for at least some power savings
18:16:27 * nirik notes rc6 has been working fine here for a long time.
18:16:31 <jforbes> davej: provided people actually update, the beta is shipping with a very old kernel
18:16:48 <jwb> oh, right.  this week is going to be "fun" with "please update"
18:16:51 <davej> yeah, not much we can do about that
18:16:59 <jwb> i believe a fairly recent kernel is already pushed to f17 stable updates
18:17:28 <jforbes> Anything else on F17?
18:17:34 <jwb> not that i can think of
18:17:44 <jforbes> #topic rawhide
18:17:56 <jforbes> Not a whole lot to report here, today's snapshot is building.
18:18:08 <swhiteho> so what about kernel-modules-extra? or does that come under rawhide?
18:18:26 <jforbes> swhiteho: seperate topic, we will get there after rawhide
18:19:14 <jforbes> So merge window is closed, nothing earth shattering... A lot of the issues in F16/F17 remain.  I hope to see a lot of those staged upstream, which will also allow them to get into stable
18:19:46 <jforbes> We have been able to drop a decent number of patches from things that have gone upstream
18:20:05 <jforbes> Anyone else have anything on rawhide?
18:20:25 <brunowolff_> The nodebug builds have been working well so far.
18:21:03 <jforbes> Yup, from what I have seen, more bugs fixed than introduced. I think the biggest new bug we have seen was the use after free in btrfs that davej fixed
18:21:22 <jforbes> Okay, moving on...
18:21:31 <jforbes> #Topic kernel-module-extras
18:21:40 <jforbes> davej: want to take this one?
18:22:12 <davej> sure
18:22:41 <davej> so the biggest question still seems to be is this going to be worth doing at all.
18:22:56 <davej> and personally, I could go either way on it.
18:23:44 <swhiteho> I'd agree with that - really my interest is if it is done, then to ensure that its done well
18:24:12 <davej> one of the primary reasons for doing this was "if something is rarely used, we'll punt it there, and then if no-one complains at all maybe even consider dropping it"
18:24:21 <brunowolff_> I use one of the drivers in extras for a gamepad I have.
18:24:40 <swhiteho> for example, when packages lose maintainers, there is a process for letting people know about it and them potentially dropping them - perhaps the same should apply to rarely used kernel modules?
18:24:43 <davej> we don't really have a good way other than bug reports to see what our users are actually using
18:25:13 <jwb> even those can be misleading
18:25:39 <jwb> almost every f16/f17 bug report shows infiniband modules loaded, but that's because some service loads them
18:25:49 <jwb> very much doubt they're being that widely used
18:25:55 <swhiteho> if we do have kernel-modules-extra then I'd like to see a set of clear criteria for what goes in it, too
18:26:06 <davej> jwb: yeah, some virt thing does that. dumb.
18:26:58 <jforbes> It would be a nice addition to smolt<next> to be able to see what modules people are loading by release or kver
18:27:05 <davej> swhiteho: the criteria so far has been pretty much guesswork, based on empirical evidence from bugzilla and/or cve's
18:27:34 <swhiteho> well, it is always going to be tricky...
18:28:10 <swhiteho> I keep thinking that the decnet module has had its day and could be dropped upstream, but then people keep popping up and saying please don't do it because it is still in use
18:29:05 <davej> right, but there's a balance to be struck. do we leave a module enabled for a handful of users at the expense of having to do security updates for every single user even if they don't have any intention of using that module
18:29:21 <swhiteho> I've nothing in principle against having an rpm with lesser used modules in it, and I agree that a balance is needed
18:29:32 <davej> what the cut-off for "too marginal" is probably depends on the actual module too
18:29:46 <swhiteho> so perhaps use is the wrong criteria, and maybe active maintainership upstream is a better criterion?
18:29:58 <davej> for something like decnet for eg, if someone filed a fedora bug asking for it, we'd very likely say "build your own kernel"
18:30:12 <swhiteho> indeed
18:30:53 <swhiteho> in fact because I always build my own kernels for my test machine is one reason I didn't spot this issue myself, earlier, but I guess thats getting off the point
18:31:05 <davej> so one possibility is that we just do more of that approach and just remove a bunch of the really weirdo stuff (like ATM, x25 etc) entirely.
18:31:39 <swhiteho> the reason I started the thread was that I didn't know what to ask for....
18:31:57 <jforbes> I think it might make the most sense to keep modules-extra, just make sure it is done well, with module deps and such in the right place
18:32:05 <davej> how many people (non-developers) realistically use gfs2 on fedora these days ?
18:32:08 <swhiteho> should I be asking for gfs2 & sctp to be moved to the main kernel, or should I just be figuring out how to let people know its new home?
18:32:18 <jwb> jforbes, that mostly relies on upstream.  we already look at the deps present
18:32:23 <swhiteho> well, again thats a tricky question
18:32:27 <jwb> jforbes, which we can certainly contribute to
18:32:36 <swhiteho> I have a couple of bugs reported recently, but thats actually a lot
18:32:41 <davej> if there's a silent horde of gfs2 users that I'm unaware of, moving it back to main would seem to be a thing to do.
18:32:45 <jforbes> And once we can gather more data we can see what we can disable more accurately
18:33:06 <davej> but if it is really marginal use, then it probably just needs DLM and anything else dependant moved too, and then a dependancy added to gfs-utils
18:33:09 <swhiteho> also, why does is matter if the users are developers or not?
18:33:27 <davej> I figure people developing gfs2 are building their own kernels
18:33:34 <swhiteho> surely the hope is to cater to both developers and other users equally?
18:33:48 <jforbes> Even if we can't get metrics on specific module use, we should be able to get a count from the mirror statistics to see how many unique IPs are installing module-extras at all right?
18:34:08 <swhiteho> we do, I know, have a problem with upstream testing of gfs2, and so I'd rather not do anything to make it even more tricky than it already is
18:35:12 <swhiteho> but that is, I suspect, mostly down to the fact that the number of people with a spare cluster and and array with a suitable lun is a tiny fraction of the fedora userbase
18:35:21 <davej> I'm leaning towards saying a dependancy on modules-extra is the thing to do here. (at least for now, if we decide modules-extra lives)
18:35:48 <jforbes> swhiteho: well, if it is modules-extra I am guessing you can add a dep on it for the userspace and gfs2 users shouldn't even really notice the change
18:36:06 <swhiteho> ok, that solves gfs2, but what about sctp? I think that should be moved to the main kernel rpm if that is where dlm will remain
18:36:38 <swhiteho> jforbes: yes, thats what I hope, and it was something I mentioned at the start of the email thread
18:36:57 <davej> sctp has been pretty horrorshow in the past wrt security updates.
18:37:09 <swhiteho> well, I have no particular love of sctp
18:37:19 <swhiteho> and in fact we don't actually use it most of the time
18:37:20 <davej> I'm not overly convinced that it's improved with age tbh
18:37:42 <swhiteho> but what I'm not sure about is whether it is safe to use a dlm module without sctp having been built
18:37:52 <swhiteho> thats a question for dave teigland
18:38:31 <swhiteho> there has been some moves recently to fix up sctp for the use of dlm for a new feature that the cluster people are planning
18:38:35 <davej> wait, confused. it is getting built, it's in extras.
18:39:04 <jforbes> davej: right, the confusion is dlm is in kernel, sctp is in extras.  Is it safe to use dlm without sctp loaded
18:39:05 <swhiteho> yes, sctp is in extras and dlm is in the main kernel rpm
18:39:07 <jwb> also... why wouldn't we move dlm to -extras
18:39:18 <davej> ah, ok. I thought we had agreed on moving dlm to extras
18:39:24 <jforbes> right, that makes more sense
18:39:26 <jwb> because as you said on the email thread, there's very little need for it without the other stuff in extras
18:39:33 <swhiteho> jwb: well thats one solution, and thats also why I'm asking :-)
18:39:54 <jforbes> so I think the answer is move dlm to extras
18:39:59 <davej> yep
18:40:00 <swhiteho> so long as we have a division that makes sense, then I think everybody will be happy
18:40:06 <davej> ok
18:40:10 <jforbes> #info dlm module to be moved to kernel-module-extras
18:40:28 <jforbes> Okay, anything else on the module-extras discussion?
18:40:38 <jwb> we're keeping it for now, yes?
18:40:46 <davej> I think so.
18:40:47 <swhiteho> sounds like it
18:40:47 <jforbes> I think so
18:40:50 <jwb> k
18:40:57 <jforbes> Okay, moving on
18:40:59 <davej> I think we should at least see how it works out for 17, and maybe revisit for 18
18:41:00 <jwb> wait
18:41:03 <jforbes> waiting
18:41:20 <swhiteho> what I would request is that the packaging guidelines say something about adding deps to the kernel-modules-extra package
18:41:25 <jwb> i was just going to say that playing deprecation games across releases if we drop it later will be... interesting
18:41:43 <jwb> maybe i'm overly concerned about that
18:41:49 <jwb> swhiteho, why?
18:41:58 <jwb> or rather, perhaps what?
18:42:40 <swhiteho> just so that people know what to do... "if your package depends on some kernel module in kernel-modules-extra then you should add that as a dep to your package" or something like that
18:42:51 <swhiteho> just so as people are aware of the correct course of action
18:44:18 <jforbes> I don't have a problem with that
18:44:20 <davej> jwb: oh, now I see what you're concerned about. if we decide to drop modules-extra in f18, things like gfs2-utils will need their deps changed
18:44:28 <jwb> yeah
18:44:54 <jwb> davej, or even if we move stuff around more
18:45:14 <swhiteho> the other alternative that I can see is to automate the installation a bit more
18:45:44 <swhiteho> since we know at rpm build time what is in kernel-modules-extra, then we could add a list of those items and a script to the main kernel rpm
18:46:03 <swhiteho> so that if someone requests a module thats in the extras package, they get a message about installing it
18:46:23 <swhiteho> so at least they know that the module isn't just "gone"
18:46:40 <swhiteho> if that makes some kind of sense?
18:47:32 <jforbes> jwb: not necessarily, we can Obsoletes right?
18:47:39 <swhiteho> then no extra deps would be needed, it could all be done from the kernel package
18:48:19 <davej> hmm, packaging up mod-extra.txt would be easy enough. changing modprobe to take advantage of it, and call into packagekit to install it is a bit more involved.
18:48:47 <davej> it's starting to feel like a rube goldberg machine though tbh
18:48:51 <jwb> jforbes, yeah, i suppose
18:49:20 <jwb> mostly i just want to prevent people from doing things like Requires: /lib/modules/<kver>/fs/bonghits/bonghits.ko
18:49:37 <swhiteho> well, I'm open to better ideas .... I'm just trying to suggest a few things and see what people like most
18:49:52 <jforbes> right, we can avoid that. But I think it would be wise not to move modules between main and extras except during pre-alpha
18:50:10 <jforbes> That way people have time to address their deps before release
18:50:50 <jforbes> dlm being an exception here if it isn't safe to use without sctp
18:51:16 <swhiteho> well, we can check that with dave teigland, but from the kconfig, I suspect its never been tried
18:51:46 <jwb> yeah... that really needs to get fixed
18:52:10 <jwb> it insmods without sctp just fine
18:52:19 <jforbes> so make that move now, then readdress for F18?
18:52:21 <jwb> whether it works, probably not
18:52:45 <swhiteho> well it probably will work with a tcp transport ok
18:53:01 <swhiteho> but whether it oopses if you have a sctp config is another matter
18:53:34 <swhiteho> I always advise people to use a tcp transport for it anyway, so few people will be affected
18:53:37 <jwb> you're making an excellent case of moving it to -extras ;)
18:54:25 <swhiteho> well, thats not a big deal - provided its there and people understand how to find/use it, I don't really mind what the package is called
18:55:04 <jforbes> Right, so be safe and move it, that way they are together whether needed or not. I am sure dlm would fit the extras criteria anyway
18:55:33 <jforbes> Anything else on modules-extras?
18:55:57 <swhiteho> I don't have anything more
18:56:24 <jforbes> Okay.  I had planned to cover testing a bit, but we are running out of time before the cloudburst so lets open the floor
18:56:31 <jforbes> #topic open floor
18:56:43 <jforbes> We can cover testing in depth next meeting
18:57:44 <jforbes> Anyone? Anything?
18:58:24 <davej> I guess we're done for the week.
18:58:27 <jwb> uh... Go Red Wings
18:58:34 <davej> mmm wings.
18:58:47 <jforbes> hehe, thanks everyone
18:58:50 <jforbes> #endmeeting