17:59:59 #startmeeting 18:00:00 Meeting started Fri Oct 14 17:59:59 2011 UTC. The chair is jwb. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:00 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:12 #meetingname fedora-kernel-team 18:00:12 The meeting name has been set to 'fedora-kernel-team' 18:00:12 it begins! 18:00:28 #meetingtopic Fedora Kernel Team meeting 18:00:36 #topic Init 18:00:46 #chair davej cebbert 18:00:46 Current chairs: cebbert davej jwb 18:01:00 Who all is around? 18:01:12 _o/ 18:01:42 good. you're running this thing. ;) 18:02:14 well hopefully there are more people than you and I talking, or this is going to get old pretty quickly :) 18:02:36 at least it will be logged :) 18:02:41 * daumas is here for the kernel meeting. 18:03:16 I'm here too 18:03:16 so I don't have any particular agenda, I figured I'd start with a run-through of where the various trees stand, and we'll just take questions as we go. 18:04:19 #topic Overview 18:04:30 * nirik is lurking around. 18:04:34 starting with the oldest.. f14. End of life pretty soon, so at this stage, we're only really taking security fixes, unless there the fixes for a bug are easy to backport. 18:04:50 we're making pretty good progress at clearing out the bug backlog for 14. Down to just 220 open now. 18:05:28 there's a lot of bugs still open with things like "my suspend doesn't work". at this point, the answer is "try 15 or 16" 18:05:46 so by the end of the month, hopefully we'll have migrated most of the remaining bugs to newer releases (or closed them) 18:06:12 #info F14 is approaching EOL, so focus is on security bugs or low-hanging fruit 18:06:15 Is the intent to get to them before they're all auto-closed? 18:06:27 tibbs: yeah, hoping to. 18:06:54 becuse that seems to agitate a lot of people (especially for bugs that have been around a while -- some of them were originally filed against f11 for eg) 18:07:15 bugs like that i've been trying to move to rawhide until they get really fixed 18:07:29 and putting FutureFeature so bugzappers doesn't muck with the bug 18:07:30 agreed. and for some of those really old bugs, if we aren't going to get to it anytime soon, we should be pointing them upstream. 18:07:37 yes. 18:08:16 I think that's all I have to say on 14. 18:08:20 * cebbert is here 18:08:40 hey Chuck 18:09:09 so, moving on.. f15. 18:09:35 459 bugs open right now, could probably be a good target for a focused bug-day, if we can ever get organised enough to pull that off. 18:09:54 yeah. I've been going through that backlog the past few weeks. it started at over 500, so we've made some progress, but not enough 18:10:00 *nod* 18:10:19 when 16 is released, we might find a bunch will just 'go away' when people upgrade too. 18:10:43 hopefully. biggest issues seem to be suspend/backlight/acpi things, and that odd net watchdog thing 18:10:58 Hopefully not to be replaced by a bunch of f16 bugs. 18:11:02 yeah, the watchdog thing I'm going to ping upstream about again. 18:11:07 tibbs: that's a given :) 18:11:49 #info F15 has 459 bugs open, mostly in suspend/backlight/acpi issues 18:12:05 #idea Possibly do a targeted F15 kernel bug day 18:12:52 so there's still a lot of abrt-filed f15 bugs that could probably be a good target for triaging. Also, now that there's a version of abrt with a bunch of annoying stuff fixed, we should start seeing some improved reports from that. 18:13:06 Happy to help with triage. 18:13:13 are the abrt maintainers going to push that version into f15? 18:13:18 yes 18:13:22 awesome 18:13:41 #info New abrt update should help with improved reports 18:14:25 anything else for 15 ? 18:14:46 new stable release should be coming any time now 18:14:50 yeah 18:14:56 i'll get that rolled in as soon as it shows up 18:15:09 then i want to send whatever patches we have that aren't in it to gregkh 18:15:19 well, the ones that apply anyway 18:15:26 oh yeah. and we'll stay on stable until just after f16 comes out, when we'll look at rebasing to 3.1 18:15:52 probably wait for 3.1.1 18:15:56 right 18:16:07 #info Will update F15 to 2.6.40.7 when 3.0.7 stable release comes out. Stay on -stable until just after F16 is released 18:16:48 moving on... f16. 18:16:57 #action jwb will work on sending the small set of F15 patches to the stable maintainers where applicable 18:17:13 just 97 open bugs, but I wouldn't be surprised if a ton of those 15 bugs migrate when people start upgrading. 18:17:24 and of course, the usual flood of new reports post release. 18:18:25 cebbert, any trending bugs you've seen this month? 18:18:28 Is F15 going to stick with the 2.6.X scheme for its lifetime? 18:18:44 tibbs, oh.. good question. i would guess yes. 18:19:09 yeah, I think we probably should. 18:19:35 I would have figured that F16 had turned up all of the latent issues with the new numbering scheme so we'd know what F15 would need to update for it. 18:19:48 But the only real downside is that it confuses people.. 18:20:02 i really haven't seen all that much confusion from it 18:20:13 maybe i'm not looking in the right place for it? 18:20:25 maintainers might not want to push updates for 3.x compatibility in f15 18:20:49 Certainly understandable, but then again, has anyone asked them? 18:20:57 Anyway, it's not as if it's a big deal. 18:21:09 yeah, it's just a number. who cares ;) 18:21:27 #info F15 will likely stay with the 2.6.4x naming scheme until EOL (e.g. 2.6.41 for 3.1, etc) 18:21:54 so a bug-trend that I've noticed a lot (across several releases) are the gpu lockups. 18:22:11 yeah... 18:22:16 airlied mentioned the other day that he'd be amenable to us changing that to a printk instead of a stack trace 18:22:19 so that abrt would stop filing them 18:22:28 because there's not really enough context to do anything with those reports 18:22:55 #action davej will work on patch to lower impact of gpu lockup bugs and try to get upstream 18:23:13 should just be a one-liner 18:23:26 i wonder if that's going to lead to a bunch more manual "MY COMPUTER HUNG AND I DONT KNOW WHAT TO DO!" bugs 18:24:00 well, i guess not since the hangups seem to get kicked free eventually 18:24:00 afaict, those are followed by a gpu reset. hopefully the reset sequence doesn't also hang 18:25:13 so afair, there's nothing terrifying about f16s buglist. northing block-worthy at least 18:25:30 might be worth taking a sweep through to be sure in the next few days though 18:25:47 #info F16 has a small number of bugs. Nothing particularly block-worthy. Expect more after release 18:26:37 do we even want to bother with rawhide? 18:26:58 might as well briefly mention it. in that, we're not really putting much focus on it right now 18:27:23 yeah. mostly because it's mapping to f16 for the most part 18:27:38 the only 'big' change on the plate for 17 if we decide to do it, is the breaking out a subpackage for the lesser used modules 18:28:00 i think it would be a good thing to do 18:28:15 some of the rawhide bugs can be assumed present in f16 18:28:22 cebbert: good point 18:28:39 148 of those right now. 18:28:39 should we try and spot those, and move them back to f16? 18:28:42 bug 744221 is interesting 18:28:57 jwb: the ones that might be misfiled, certainly 18:29:25 cebbert: intel have a fix for that on sf.net aparently 18:29:46 It would be nice if there was a nodebug kernel for rawhide (at least the current performance issues of the debug version) 18:30:20 if we had a nodebug kernel everyone would run it :/ 18:30:28 brunowolff, you could just use the f16 kernel 18:30:42 yeah, branched has sort of solved that problem for the most part 18:30:53 I am rebuild f16 kernels now, though I suspect I could just directly use them. 18:32:09 #info Rawhide isn't being focused on much due to F16. Some of the bugs in rawhide are likely present in F16 as well and should get assigned back to f16 as they are found. 18:32:28 (I rebuild f16 kernels to get the config, as that was simpler than trying to learn how to change the config right now) 18:32:56 #info Biggest change pending for rawhide is possibly creating a lesser used module subpackage 18:33:31 brunowolff, aside from the debug options, the configs should be identical. i don't see much of a need to rebuild 18:33:54 Probably just that I didn't know what I needed to do. 18:34:34 upstream is adding something that looks a bit like our config merging scripts, so we might get to use that if it works the same way. though not really a big deal if we stick with our current scripts. 18:34:47 I do want to start running 3.2 kernels fairly early. I want to be able to get regressions fixed earlier and it seems a lot easier to get upstream attention for regressions in development kernels. 18:35:11 davej, yeah, i saw that too. I'd like to play with it once 3.2 shows up. we can always fix it if something isn't quite working for us 18:35:22 brunowolff: from a git checkout, just do 'make release' 18:35:33 ok, i think that's it for the overview 18:35:41 #topic Q&A/Open 18:36:09 so I think once a month is going to be adequate for this meeting. 18:36:44 Is there any chance of resurrecting the upstream kernel RPMs that were provided a few years ago? 18:36:45 it's not like we're hard to find the rest of the month if people have questions 18:37:01 isn't anyone going to ask why we don't ship kmod-nvidia? ;) 18:37:07 cebbert: ssssshhh 18:37:30 verdurin: you mean the -vanilla ones? 18:37:43 cebbert: -vanilla - yes, that's what I mean 18:37:51 so i was doing those for a while 18:38:03 I could ask about dahdi. It would probably get the same answer as kmod-nvidia. 18:38:09 verdurin, the stuff in the spec is still there, but i didn't really see much uptake in them getting used 18:38:54 we could build them in koji 18:39:05 on the subject of specfile stuff, weren't we considering ripping out something recently ? 18:39:08 cebbert, as scratch builds? 18:39:13 there's surely some cruft in there now 18:39:14 davej, rhel stuff 18:39:18 firmware 18:39:19 oh yeah 18:39:23 and firmware 18:39:38 more 17 stuff. 18:39:54 I found them useful when reporting bugs upstream, at least 18:39:54 i think i put those in the TODO 18:40:01 the firmware stuff is harmless though 18:40:06 I would be happy to help, if you're all too busy 18:40:21 cebbert: why don't you ship NVIDIA driver? my NVIDIA card no workie without it 18:40:53 sorry for the delay. i got caught on the phone. 18:41:19 i wonder if we could get rpmfusion to host vanilla kernel builds? 18:42:05 cebbert, possibly. we could talk to knurd_afk 18:42:29 i still wonder how useful that is in the long run 18:43:08 maybe for rawhide, but i really wouldn't want to do it for a release in the state of F15. i'd think those would just wind up with unfixed bugs in them 18:44:03 we could do kernel-vanilla as the alternate kernel for rawhide 18:44:34 cebbert, so kernel and kernel-vanilla both get built? 18:44:43 sort of like kernel/kernel-debug in a release? 18:44:46 and even push it to the repos 18:44:49 cebbert: not even a witty reply? :( 18:44:49 yeah 18:45:12 daumas: ;P 18:46:18 #idea Possibly build kernel and kernel-vanilla in rawhide 18:47:49 Thanks for considering it, anyway 18:48:20 i think the perfect solution is to just get rawhide down to no patches at all, but that never seems to happen :) 18:49:00 getting better though, I pushed all the debug patches recently (should be in 3.2) and mjg59 pushed some of the defaults patches (turned into config options). 18:49:32 cool 18:50:13 any other questions? 18:50:47 davej, cebbert anything else? 18:50:59 I'm about done 18:51:03 and we used up most the hour 18:51:13 i can't think of anything else 18:51:17 yeah, not too bad 18:51:40 thanks to everyone that showed up to listen and participate 18:51:45 #endmeeting