18:00:16 #startmeeting 18:00:16 Meeting started Fri Jan 20 18:00:16 2012 UTC. The chair is davej. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:16 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:28 #meetingname kernel 18:00:28 The meeting name has been set to 'kernel' 18:00:58 LET'S DO THIS 18:01:12 \o/ 18:02:24 lets start as always with a runthrough of the releases. 18:02:40 k 18:02:53 for the most part, we can do 15/16 as the same thing (aside from the rebase which I'll cover later) 18:03:41 so f15 and f16 are on 3.1.10 at the moment 18:03:55 with a number of additional security patches 18:04:12 pretty quiet overall the past couple of weeks. just a few small patches and some stable rebases 18:04:42 due to some excellent help at FUDCon, F15 is actually on a somewhat current stable release and not sitting at 2.6.41.4 anymore 18:05:27 we'll have to keep an eye on the karma situation for updates 18:05:45 yeah, agreed. also do a better job of asking for testing too 18:06:10 that mostly covers f15/f16 until last night 18:06:40 807 open bugs right now :-/ 18:07:15 f15 really needs a going-thru for stale bugs at this point 18:07:29 yeah, though 16 seems to have seen an uptick in bugs lately. 18:07:41 a bunch in compat-wireless 18:07:52 it went from 277 this time last month to 414 today 18:08:09 nngh 18:08:16 we should start keeping stats on the number of wireless bugs we're getting 18:08:30 because it feels like we're seeing more of them since the compat-wireless thing 18:08:51 I'll do some bugzilla magic for that later. 18:09:19 k 18:09:23 #action davej to work on bz script to track number of wireless bugs 18:09:51 there is still the crazy hibernate issues as well. a number of bugs seem related to that 18:10:19 yeah. I'm not sure how that's going to pan out (the 'disable hibernate' bug) 18:10:38 for sure it would be an unpopular move. 18:10:40 it doesn't seem to have too much pushback so far that I have seen. 18:10:47 adamw offered to do an informal poll on the forums. while i hate forums for other reasons, it might be worth doing... 18:10:50 nirik: I think it's mostly off peoples radar so far 18:10:53 nirik, it hasn't really been broadcsat must 18:10:55 er, much 18:10:56 could be. 18:11:21 was there a chance of a 'please-let-me-hibernate' boot time option? 18:11:42 that doesn't really solve anything, because when people using it get fs corruption, we're where we are now. 18:12:33 yeah, that doesn't make sense to me 18:12:37 either we kill it entirely or not at all 18:13:07 well, much fewer people will see or use it. 18:13:14 but ok 18:14:03 moving on. I committed the f16 rebase to 3.2 last night 18:14:17 we could do a username match and only let the hibernate maintainer switch it on, but... 18:14:36 davej: running that kernel here, so far everythings fine for me. ;) 18:14:42 nirik: great 18:14:53 i've been running 3.2 for a while. seems to work well enough here 18:15:04 yeah, same here. 18:15:34 Me too. 18:15:38 jwb: so I'm on vacation next week, how do you want to handle pushing that out ? 18:15:50 davej, i'll submit it monday to updates-testing 18:15:58 that sounds good to me. 18:16:13 if a 3.2.2 shows up between then, throw that in too. 18:16:19 yep 18:16:42 #action jwb to push 3.2 update to f16-updates-testing on Monday. 18:16:58 I'll tackle f15 when I get back. 18:17:11 i figure we'd let it sit in f16 for a few days after it when to updates stable anyway 18:17:20 yeah 18:17:35 there will be no more 3.1.y updates, so if anything really urgent pops up we'll backport 18:17:44 but it'd have to be pretty bad 18:18:11 this kind of highlights why we need to keep rebasing 18:18:39 yeah 18:18:56 ok, anything else about 15/16 ? 18:19:08 don't think so 18:19:46 ok, so rawhide. 18:20:14 I went on a spree recently disabling some of the prehistoric crap that we've always built 18:20:51 there's probably still a load more in there that can go, but it's at least one step closer to being a "modern hardware only" kernel. 18:22:13 rebase to 3.3rc1 next week ? 18:22:19 actually, probably today 18:22:26 ok 18:22:26 i just booted a local build of it 18:22:57 I've been running it locally the last week or so on my laptop. other than iwlwifi being a disaster, it's been ok 18:23:00 the rebase work is done in my local git tree, so i'll probably commit it and do a build with debug disabled later today 18:23:11 I'm still working that out with the intel guys, who seem to be slowly getting there 18:23:27 i have an email i'm sending to the kernel list with a few questions to various people on stuff that came up during the rebase 18:23:33 also, yes iwlwifi ugh 18:24:07 in 3.3, iwlwifi grew some debug options at least, so we should at least be able to debug problems with it easier in the future 18:24:53 nothing particularly exciting in the 3.3 kernel tbh 18:25:16 well, small thing 18:25:29 it supposedly has THE fix for the "writes to slow media cripple machine" thing 18:25:31 I noticed earlier that the 'copy lots of data from dvd kills interactivity' bug seems to be fixed 18:25:35 hah 18:26:34 so aside from hitting a kmemleak issue yesterday that prevented booting (which i have a patch from Catalin for), and a lockdep spew from radeon, it seems to work well enough on my machine 18:27:16 davej, for the first build... still disable debug? 18:27:21 then build again with it on? 18:27:36 yeah, sounds like a good idea 18:27:51 we said one per rc so even though it makes me nervous i figured we'd stick with our word 18:28:05 probably wait until rc1-git1 to turn debug back on anyway (monday) 18:28:20 I think this will be a good idea just for coverage testing too. sometimes we see bugs that disappear when the debug stuff is turned on 18:28:38 yeah, agreed 18:28:41 timing related 18:30:33 ok, running out of material. 18:30:43 i think that's about it anyway 18:31:59 oh, wait 18:32:02 so, utrace 18:32:06 it doesn't apply 18:32:34 i've left it out of the 3.3-rc1 rebase until oleg can get to it. seem reasonable? 18:32:40 yeah 18:32:43 word 18:33:18 hopefully it'll go away for 3.4 (this seems to be a perpetual thing..) 18:33:23 heh 18:33:33 I'll be sure to CC Oleg in my email to point it out 18:34:13 at fudcon the systemtap guys seemed optimistic that it was moving in the right direction 18:36:41 ok, unless anyone else has anything, I guess we can end early 18:36:50 Are branched and rawhide going to get essentially the same kernel builds? 18:37:05 until we hit 3.3 final, probabl 18:37:07 y 18:37:14 Thanks 18:37:16 davej: Anything besides lmbench you want in the performance testing autotest bits? 18:37:53 brunowolff: yeah, we'll move them forward in lockstep. after 3.3 final, we might keep branched on release builds and rawhide on debug.. ask again later. 18:38:03 jforbes: ooh, forgot about that stuff 18:38:41 jforbes: I think that would be a good thing to start with. maybe one of the filesystem benchmarks too (not sure what the benchmark du jour is in that world) 18:38:44 I haven't seen any updates on adding the extra kernel modules package to the install only list for yum. 18:39:08 davej: yeah, started on the framework yesterday, but still need to figure out a good way to store/graph historic results 18:39:14 That seems like something that would be nice to have for F17 alpha. 18:39:18 jforbes: awesome 18:39:54 jforbes: just to clarify, is this going to be just for performance testing, or also regression testing ? 18:40:15 davej: well, it can be both, though performance was what we talked about 18:40:23 ok. because the kernel seems to be growing a tests/ dir that might be useful there going forward 18:40:41 davej: so basically when a kernel build test is called, we tell a machine to install, reboot and run the series of tests that we specify 18:41:03 I wonder if we should perhaps keep a tests/ directory in our git tree. 18:41:13 davej: it would be very easy to add regression testing, or pretty much anything else. 18:41:19 because I have a boatload of thigns from over the years. 18:41:44 Hmm, git tree would be okay, would be even better if it could end up in an rpm somewhere, so that it is versioned with the kernel we are testing 18:41:58 kernel-tests would be nice :) 18:42:11 can we just lump it into kernel-tools? 18:42:19 possibly. 18:42:19 jwb: sure 18:42:30 kernel-everythingelse 18:42:44 Really doesnt matter where it is, just matters that we know how to get it 18:42:45 though that might grow quite big, whereas someone who just wants perf.. 18:42:55 davej, perf is split out 18:43:13 f16 lumped it into kernel-tools, f17 has it split out again 18:43:16 oh right, was looking at 16 18:44:33 ok, I'll take a look at the tests I have sitting around when I come back from vacation, and make a start on organising that 18:44:49 For rawhide, we also have a question of how userspace can interract, but that doesnt have to be decided immediately 18:44:54 #action davej to look into packaging up kernel test cases 18:46:09 for released versions, we just dont update userspace on the test machine, if only kernel changes, we always know performance differences are a direct result of the kernel 18:46:59 jforbes: good point. a new glibc for eg could skew results noticably. 18:47:50 davej: right, so for rawhide, I was thinking maybe controlled userspace updates, and we can run pre/post with same kernel to judge impact 18:49:49 [distracted by arrival of sushi guy] 18:50:36 davej: plenty of time to go over policy once mechanism is finished, doesn't have to be hashed out today 18:50:40 sure 18:51:17 lets revisit this in 2 weeks. I'll be back from vacation then, and might have a bunch of new ideas. 18:51:50 excellent 18:52:45 ok, lets call this done ? 18:52:50 yes. 18:53:03 Thanks folks for all your hard work! 18:53:14 #endmeeting