18:00:12 #startmeeting Fedora Kernel Meeting 18:00:12 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:28 everyone ready? 18:00:34 yep 18:00:41 #addchair jwb davej 18:00:44 word 18:01:07 Great lets get started with releases 18:01:13 #topic F15 18:01:18 I'll do 15 18:01:45 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 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 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 I think lowering the karma requirements is the only way we can win this 18:03:56 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 yeah, I don't think waiting really solves anything 18:04:33 me either 18:04:45 so, bug count for 15 is just over 300. hoping to get it under that next week. 18:05:09 and then maybe do something about 16, because that's getting a bit out of control again 18:05:11 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 # info Karma threshold for F15 updates to be lowered because we just don't get testers 18:05:27 (weekly bug count stats at http://codemonkey.org.uk/2012/04/13/weekly-fedora-kernel-bug-statistics-april-13-2012 btw) 18:06:29 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 fair. 18:06:50 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 Okay, anything else on F15? 18:07:55 not from me 18:08:06 #topic F16 18:08:17 jwb: you want to take this one? 18:08:21 sure 18:08:40 F16 was upgraded to 3.3.1 recently. It should pick up 3.3.2 later today 18:08:46 we had a couple of regressions of note 18:08:50 1) ath9k 18:08:58 2) dvb stuff 18:09:09 3) ALSA for various thinkpad models/docking stations 18:09:19 the good news is that we're making progress on all 3 18:09:39 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 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 excellent, anything else on F16? 18:10:56 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 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 with the exception of unlock_new_inode 18:11:15 that still seems to be a problem for some people. 18:11:24 davej, yeah, the i915 fix seems to have worked by and large 18:11:47 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 yeah, quite possibly 18:13:01 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 that's not a small number of bugs with those 4 18:13:26 right 18:13:43 Okay, anything else on F16? 18:13:48 there's still quite a few iwl bugs too, but that never changes 18:14:50 okay, on to 17 18:14:54 #topic F17 18:14:56 i'll cover that one too 18:15:07 basically, everything I said for F16 applies to F17 18:15:16 they're almost identical kernels 18:15:39 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 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 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 f17 kernels have been running fine for me. 18:16:23 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 davej: provided people actually update, the beta is shipping with a very old kernel 18:16:48 oh, right. this week is going to be "fun" with "please update" 18:16:51 yeah, not much we can do about that 18:16:59 i believe a fairly recent kernel is already pushed to f17 stable updates 18:17:28 Anything else on F17? 18:17:34 not that i can think of 18:17:44 #topic rawhide 18:17:56 Not a whole lot to report here, today's snapshot is building. 18:18:08 so what about kernel-modules-extra? or does that come under rawhide? 18:18:26 swhiteho: seperate topic, we will get there after rawhide 18:19:14 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 We have been able to drop a decent number of patches from things that have gone upstream 18:20:05 Anyone else have anything on rawhide? 18:20:25 The nodebug builds have been working well so far. 18:21:03 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 Okay, moving on... 18:21:31 #Topic kernel-module-extras 18:21:40 davej: want to take this one? 18:22:12 sure 18:22:41 so the biggest question still seems to be is this going to be worth doing at all. 18:22:56 and personally, I could go either way on it. 18:23:44 I'd agree with that - really my interest is if it is done, then to ensure that its done well 18:24:12 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 I use one of the drivers in extras for a gamepad I have. 18:24:40 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 we don't really have a good way other than bug reports to see what our users are actually using 18:25:13 even those can be misleading 18:25:39 almost every f16/f17 bug report shows infiniband modules loaded, but that's because some service loads them 18:25:49 very much doubt they're being that widely used 18:25:55 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 jwb: yeah, some virt thing does that. dumb. 18:26:58 It would be a nice addition to smolt to be able to see what modules people are loading by release or kver 18:27:05 swhiteho: the criteria so far has been pretty much guesswork, based on empirical evidence from bugzilla and/or cve's 18:27:34 well, it is always going to be tricky... 18:28:10 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 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 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 what the cut-off for "too marginal" is probably depends on the actual module too 18:29:46 so perhaps use is the wrong criteria, and maybe active maintainership upstream is a better criterion? 18:29:58 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 indeed 18:30:53 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 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 the reason I started the thread was that I didn't know what to ask for.... 18:31:57 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 how many people (non-developers) realistically use gfs2 on fedora these days ? 18:32:08 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 jforbes, that mostly relies on upstream. we already look at the deps present 18:32:23 well, again thats a tricky question 18:32:27 jforbes, which we can certainly contribute to 18:32:36 I have a couple of bugs reported recently, but thats actually a lot 18:32:41 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 And once we can gather more data we can see what we can disable more accurately 18:33:06 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 also, why does is matter if the users are developers or not? 18:33:27 I figure people developing gfs2 are building their own kernels 18:33:34 surely the hope is to cater to both developers and other users equally? 18:33:48 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 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 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 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 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 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 jforbes: yes, thats what I hope, and it was something I mentioned at the start of the email thread 18:36:57 sctp has been pretty horrorshow in the past wrt security updates. 18:37:09 well, I have no particular love of sctp 18:37:19 and in fact we don't actually use it most of the time 18:37:20 I'm not overly convinced that it's improved with age tbh 18:37:42 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 thats a question for dave teigland 18:38:31 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 wait, confused. it is getting built, it's in extras. 18:39:04 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 yes, sctp is in extras and dlm is in the main kernel rpm 18:39:07 also... why wouldn't we move dlm to -extras 18:39:18 ah, ok. I thought we had agreed on moving dlm to extras 18:39:24 right, that makes more sense 18:39:26 because as you said on the email thread, there's very little need for it without the other stuff in extras 18:39:33 jwb: well thats one solution, and thats also why I'm asking :-) 18:39:54 so I think the answer is move dlm to extras 18:39:59 yep 18:40:00 so long as we have a division that makes sense, then I think everybody will be happy 18:40:06 ok 18:40:10 #info dlm module to be moved to kernel-module-extras 18:40:28 Okay, anything else on the module-extras discussion? 18:40:38 we're keeping it for now, yes? 18:40:46 I think so. 18:40:47 sounds like it 18:40:47 I think so 18:40:50 k 18:40:57 Okay, moving on 18:40:59 I think we should at least see how it works out for 17, and maybe revisit for 18 18:41:00 wait 18:41:03 waiting 18:41:20 what I would request is that the packaging guidelines say something about adding deps to the kernel-modules-extra package 18:41:25 i was just going to say that playing deprecation games across releases if we drop it later will be... interesting 18:41:43 maybe i'm overly concerned about that 18:41:49 swhiteho, why? 18:41:58 or rather, perhaps what? 18:42:40 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 just so as people are aware of the correct course of action 18:44:18 I don't have a problem with that 18:44:20 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 yeah 18:44:54 davej, or even if we move stuff around more 18:45:14 the other alternative that I can see is to automate the installation a bit more 18:45:44 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 so that if someone requests a module thats in the extras package, they get a message about installing it 18:46:23 so at least they know that the module isn't just "gone" 18:46:40 if that makes some kind of sense? 18:47:32 jwb: not necessarily, we can Obsoletes right? 18:47:39 then no extra deps would be needed, it could all be done from the kernel package 18:48:19 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 it's starting to feel like a rube goldberg machine though tbh 18:48:51 jforbes, yeah, i suppose 18:49:20 mostly i just want to prevent people from doing things like Requires: /lib/modules//fs/bonghits/bonghits.ko 18:49:37 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 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 That way people have time to address their deps before release 18:50:50 dlm being an exception here if it isn't safe to use without sctp 18:51:16 well, we can check that with dave teigland, but from the kconfig, I suspect its never been tried 18:51:46 yeah... that really needs to get fixed 18:52:10 it insmods without sctp just fine 18:52:19 so make that move now, then readdress for F18? 18:52:21 whether it works, probably not 18:52:45 well it probably will work with a tcp transport ok 18:53:01 but whether it oopses if you have a sctp config is another matter 18:53:34 I always advise people to use a tcp transport for it anyway, so few people will be affected 18:53:37 you're making an excellent case of moving it to -extras ;) 18:54:25 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 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 Anything else on modules-extras? 18:55:57 I don't have anything more 18:56:24 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 #topic open floor 18:56:43 We can cover testing in depth next meeting 18:57:44 Anyone? Anything? 18:58:24 I guess we're done for the week. 18:58:27 uh... Go Red Wings 18:58:34 mmm wings. 18:58:47 hehe, thanks everyone 18:58:50 #endmeeting