18:02:10 #startmeeting kernel 18:02:10 Meeting started Fri Oct 19 18:02:10 2012 UTC. The chair is jforbes. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:10 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:02:39 #topic Who's here? 18:02:54 holla 18:03:21 i just showed up to get it rolling. totally bailing now. going to play putt-putt instead 18:03:28 heh 18:03:35 #topic F16 18:03:41 ok, I'll start. 18:04:00 this week I rebased f16 frmo 3.4->3.5->3.6 18:04:09 thus tying up koji for all of wednesday 18:04:20 but there's a 3.6.2 in testing now 18:04:38 hopefully that'll get karma'd to updates-final before 3.6.3 comes out 18:05:05 once that's there, I'm planning to do a mass-update to bugzilla again 18:05:23 that's about it 18:05:30 Thanks davej 18:05:36 #topic F17 18:05:43 jwb: ? 18:05:57 F17 rebased to 3.6.x since the last meeting 18:06:07 that took care of quite a few bugs, but still others are rolling in 18:06:19 we seem to be hitting a lot of i915 bugs, but with taints already present 18:06:30 so the abrt situation davej mentioned is inflating the bug numbers a bit 18:06:45 3.6.3 should be out monday-ish and i'll roll out another update for that asap 18:07:12 some people still seem to be suffering the "fb bug" even with 3.6, so whatever that actually is isn't fixed yet 18:07:38 oh, and 3.6 seems to have broken the proprietary wl driver horribly. quite a few bugs tehre 18:07:58 of course, can't fix them. proprietary drivers suck, etc 18:08:13 and then we're seeing some weird ones 18:08:35 ipi mask issues, a bunch of bad page table issues on i686, and some other odd MM bugs 18:08:58 we haven't seen any of this in F18 yet, which leads me to believe F18 isn't getting huge testing coverage 18:09:34 i think davej pondered about the i686 page table bugs being possibly issues related to THP 18:09:59 and as usual, none of us can reproduce these weird bugs 18:10:06 entirely possible, I don't know that THP is getting any real testing on 32bit 18:10:38 i would still like to try a few test runs in i686 VMs, but not optimistic about them actually hitting 18:10:50 for some reason Chrome seems to freak things right out for quite a few 18:11:13 so if you're running a 32-bit kernel and Chrome and can hit this bug, let us know. we'll see if a bisect can be done 18:11:21 I think that's just because it uses so much memory. 18:11:47 yeah, but we've gotten surprisingly few caused by FF, which also uses a bunch of memory 18:11:50 It does, but you would think firefox would hti ti too 18:11:50 people hitting this seem to have quite a few chrome processes 18:12:03 right, chrome breaks out a process per tab 18:12:29 oh, right. forgot about that 18:12:51 I looked at seeing if it was easily possible to script chrome a few days ago 18:13:01 it would be useful to have it run in spider mode unattended 18:13:04 Though interesting we are seeing mostly chrome, not chromium? 18:13:50 yeah, it think mostly chrome 18:14:19 So something in google's build that isn't in spot's is triggering? 18:14:33 Might be useful for debugging, I have never actually run their builds 18:14:40 maybe just not as many people running spots? 18:14:40 yeah, possibly 18:14:46 also possibly that 18:14:51 * spot nods 18:15:14 other than stripping out bundled libs, is there really any difference? 18:15:31 Guess I can give it a run and see what I come up with here. I have a box I can throw a 32bit install on 18:15:32 its possible that something they have bundled is patched for different behavior 18:16:08 but i doubt there is a huge difference there, i think its just more likely that no one is using chromium. 18:16:20 maybe I'll reinstall the laptop as 32bit and run with that for a while. 18:16:30 I am happily using chromium 18:17:26 ok, done with 17 ? 18:17:30 Yup... 18:17:36 #topic F18 18:17:59 F18 is moving along, on 3.6.2 right now, expect 3.6.3 to be there Monday 18:18:38 The issues are pretty much typical, though there were some issues mentioned with testing updates due to a dracut problem, so I am not sure how many people are really running current 18:19:17 There is an issue with loading keymaps that I am looking into right now. It really needs to be fixed before the install 18:20:34 Otherwise I think nothign out of the ordinary. The fact that we are seeing so many more reports on F17 makes me worry that we don't have enough people testing F18 at the moment 18:21:09 yeah, I thought the same thing when I looked over this weeks bz report 18:21:43 maybe things will pick up soon, but so far it's been very quiet 18:21:55 That's about it for F18. I really hope for more evidence of testing as we get closer to release 18:21:56 might help if beta didn't keep slipping 18:22:28 Yeah, I think a lot of people wait for beta for testing. I actually don't move my desktop until beta 18:22:29 speaking of the slip.. 18:22:46 Though I run newer kernels 18:22:54 we decided earlier this week, we're sticking with 3.6 even though 3.7 might be out by the f18 ga 18:23:19 right 18:23:21 a day 0 update is just less risk all around, and hopefully we'll still see 3.6.x stable releases through then 18:24:04 Anyone have anything else on F18? 18:24:13 guess not 18:24:35 #agreed F18 will release with a 3.6 kernel 18:24:44 #topic Rawhide 18:25:07 sort of 18 related, but also rawhide. jwb, do you want to talk about the modsign stuff that got upstream? 18:25:30 sure 18:25:54 so David Howells work on usign x509 certs for module signing went upstream in 3.7-rc1 18:26:00 like... all of it 18:26:05 which is awesome 18:26:19 the only modsign remaining item we have is making it work with an RPM built kernel 18:26:42 i'm working on a patch with Rusty Russell and Linus to see if we can get a separate target upstream for that 18:27:11 I think kernel 3.7.0-rc1.git2.1 is breaking builds linking against libnl-1.1 18:27:13 it will mean that the modules built via RPM get signed twice, once during modules_install, once after rpm debuginfo has removed that 18:27:23 jwb: probably means I should spend some time this afternoon looking at revocation 18:27:30 but it still works 18:27:52 things are looking good, and we'll likely be carrying no additional modsign patches in rawhide by hopefully -rc2 18:27:55 pjones, er... why? 18:28:03 sgallagh: got a link to a failure? 18:28:09 jwb: so we can honor certs in db and dbx? 18:28:10 and mok 18:28:16 pjones, oh, that part 18:28:17 davej: http://www.fpaste.org/jtXb/ 18:28:31 pjones, yeah, sure. i haven't gotten to the SB aspects of modsign yet 18:28:56 sgallagh, that might be related to the UAPI work 18:29:13 i think there's a bug open somewhere on fixing kernel-headers to work with UAPI 18:29:16 jwb: I'm just reporting it. It broke SSSD's nightly auto-build 18:29:27 yeah, looks like uapi fallout 18:30:10 I've not looked to check we're actually packaging up include/uapi properly. jforbes ? 18:30:11 There has been a good bit of uapi fallout through the merge window, though I am surprised that more showed up after rc1 18:30:29 I will double check this afternoon 18:30:38 jforbes, dhowells is still merging big chunks of it. per subsystem, per arch, etc 18:30:52 davej, that's the bug i mentioned earlier. saw it go flying by 18:31:05 ok 18:31:14 or one of them anyway 18:31:54 Yeah, I will go through everyting this afternoon and make sure we are doing the right thing 18:32:21 sgallagh: mind pinging me again if there are problems after git4? 18:32:50 jforbes: I was about to file a BZ. Want me to hold off? 18:32:56 What's the eta on git4? 18:32:59 sgallagh: no, go ahead 18:33:12 sgallagh: git4 will be built either late tonight or tomorrow AM 18:33:44 ok, I'll try to check on Monday. I'll be traveling this weekend 18:34:02 Oh yeah, it's friday... 18:34:29 So it will likely be rc2 then instead of git4 18:34:43 Anything else on rawhide? 18:35:15 #Topic Fudcon Paris 18:35:32 jwb: want to talk about anything from Fudcon? 18:35:38 So this past weekend I attended FUDCon Paris and gave the usual "State of the kernel" talk 18:35:56 overall, it went pretty well. for those of you that have heard it at FUDCon NA, it's much the same 18:36:05 but there were two things that came out of it worth mentioning 18:36:13 the first is rawhide kernel testing 18:36:26 a number of people would like to see an easier way to consume rawhide kernels for testing 18:36:53 whether this be a separate repo or something along those lines, they're nervous about pointing directly to rawhide 18:37:18 there were also request for rawhide kernels without debug turned on, so they could actually run it in a usable fashion 18:37:37 i really think that's something the copr stuff that skvidal is working on would help out 18:38:05 all those extra kernels will sure make us popular with releng 18:38:30 dgilmore was sitting in the room at the time. there were no issues raised ;) 18:38:34 heh 18:38:55 it might be feasible to do a few, but not matching non-debug builds for all fo them 18:39:17 something to at least look at and determine if it's not a horrible amount of work 18:39:25 I think the non debug kernels would get us a lot more testing, doing a seperate repo for them is not a bad idea at all 18:39:48 yeah. i might try doing a few here and there in a side repo on my fedorapeople page to start with 18:39:51 jforbes: https://bugzilla.redhat.com/show_bug.cgi?id=868409 for the record 18:39:57 if that goes well, we can explore it further 18:40:18 sgallagh: thanks 18:40:36 the other item we discussed is new kernel features 18:40:41 when to enable them, etc 18:41:02 the basic method we're using now is new drivers tend to get enabled, new general features don't at first 18:41:10 which is better than blindly enabling everything 18:41:18 a specific example brought up is checkpoint/restore 18:41:27 I think it comes down to demand for a feature too 18:41:37 if enough people want it, sure. but for 1-2 people ? 18:41:59 yes, definitely. for C/R, i think we're going to get more demand as things go 18:42:17 right. conversely, hopefully we'll get fewer ax25 users over time 18:42:41 lennart has already mentioned wanting it for the CoreOS/containers thing. adrian reber brought it up for HPC stuff where you have long compute jobs and don't want to have to restart them from scratch 18:43:04 so one approach there would be to enable it in the debug kernels and let people play with it 18:43:15 and disable it in release kernels until it proves itself to not be horribly broken 18:43:28 i think we've done that with other things in the past and it worked well enough 18:43:57 C/R has some uglier dependency issues, but that approach might be suitable in a general fashion overall 18:44:52 major objections? worth trying for requested features? 18:45:46 For requested features I think it makes sense. Debug first, a rawhide cycle, etc 18:46:37 Anything else from fudcon? 18:47:00 i'd like to know from people that attended if the talk was worthwhile, or if they'd like to see something else or additional 18:47:09 but i'll ask in the blog writeup i do about that 18:47:26 kinda feel the talk is getting a bit stale, even though the content is always new because of our rebasing 18:48:57 * jwb has nothing else 18:50:18 guess we're almost done here 18:50:21 #topic open floor 18:50:38 Any other questions, topics? 18:51:24 Okay, if nothing else, closing out in 4 mins? 18:55:51 Thanks for coming everyone 18:55:53 #endmeeting