19:00:03 #startmeeting fedora-kernel 19:00:03 Meeting started Fri Nov 16 19:00:03 2012 UTC. The chair is jwb. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:03 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:13 #meetingtopic Fedora Kernel 19:00:19 #topic init 19:00:25 ok, davej is out this week 19:00:26 i'm here 19:00:31 anyone else? 19:00:45 I am here 19:01:43 ok. maybe just the two of us :) 19:02:02 i think i'll just touch on some small points for 18, and then we'll open floor it 19:02:10 #topic F18 beta status 19:02:10 That works 19:02:22 So on the kernel front for the F18 beta, we're in decent shape 19:02:42 there are two things in the currently queued beta kernel that are broken, but not seriously so 19:03:03 1) 'flavour' kernels (e.g. PAE, debug, PAEdebug) are have incorrectly signed modules 19:03:22 2) external kernel module builds will fail because of modsigning 19:03:39 the good news is that these are both fixed, and included in the update i submitted today 19:04:02 also, the first issue doesn't really cause any major problems unless you're booting in enforcing mode, which we don't default to 19:04:29 there are other bugs open, but nothing that is screaming "blocker" at the moment 19:04:58 somewhat relatedly, there's a bug open against dracut because it's stripping off module signatures 19:05:17 i've fixed that with a patch in the bug, but no response yet. i think haraldh is out 19:05:30 again, not a major problem unless you're in enforcing mode 19:05:45 or fips mode i guess 19:06:00 that's about all i can think of for f18 beta 19:06:27 I am still looking into an issue with upower not recognizing UPSs 19:06:51 ok. i think there's another bug that just got moved over to the kernel about that too 19:07:20 Yeah, that's probably the one. adamw asked me to look into it. Seems universal with 3.6, but looking for the cause 19:07:52 no i was thinking of 845770. not the same, but maybe related 19:08:19 ahh, right 19:08:33 though that one has a lengthier history. might be some confusion in tehre 19:09:02 anyway. i think the overall status is "we're doing fairly well. progress is being made on the remaining bugs as usual" 19:09:44 ok, anything else on f18? 19:09:54 sb is still in limbo? 19:09:57 nothing here 19:10:16 nirik, legal limbo 19:10:19 yeah. ;( 19:10:26 from a technical side, things are ok 19:10:31 cool. 19:10:53 ok, let's move on 19:10:56 #topic open floor 19:11:11 we're skipping the overview of all the releases today. not much really worth talking about 19:11:22 but we'd be happy to discuss topics brought up, or answer questions 19:11:29 I haven't seen anything new on lkml for the kswapd issue. Is anything happening there? 19:11:45 there's supposedly two reverts going in 19:11:51 which i've not seen go in yet 19:12:01 i'll try and bug mel a bit 19:12:12 * nirik really needs to get around to posting his sound issue to lkml. :) Keep not having time... 19:12:37 if they're queued in the akpm tree, they'll probably go in towards the end of the release's development 19:15:35 Are there further thoughts on modifying the names used for rawhide nodebug repo kernels to avoid conflicts? 19:16:40 brunowolff: not really. conflicts are easily avoided with exclude kernel* in the rawhide repo 19:18:05 There was something odd with the conflict that happened. I never saw a nodebug build for the conflicting kernel. I don't know if that was directly because of the conflict or if something else happened. 19:18:40 Since there is a more current build as of the last hour or so, the issue is mostly moot. 19:18:47 brunowolff: there has been a nodebug build of every kernel that happened, but there were two rawhide kernels the other day 19:19:13 brunowolff: in that case, the second build launched before the first one completed, and the first one never made the repository 19:19:36 there we go, fixing stuff too fast again ;) 19:19:37 see my note earlier about nodebug builds taking more than 4x as long as regular rawhide builds 19:19:56 It was the later kernel that didn't make the repo as far as I could tell. 19:20:38 git1.3 was in the repo this morning, rawhide should have been on git1.2 19:21:07 There was a rawhide kernel 3.7.0-0.rc5.git1.3.fc19, but not a nodebug repo kernel 3.7.0-0.rc5.git1.4.fc19 (which is what I would expect the name to have been based on what I have seen so far). 19:21:28 it's merely a timing problem 19:21:42 the last digit is 'baserelease' in the kernel.spec file 19:21:53 nodebug just increments it by one and builds 19:22:01 but that is never committed 19:22:09 Right 19:22:17 so when i incremented and built a second official build, it conflicted 19:22:20 it'll be fairly rare 19:23:12 But I didn't see a nodebug kernel created for that one even though that build was quite a bit later and there was a long gap before the one that just appeared. 19:23:33 it's not automated 19:23:44 Really, there is always going to be a race between when the newest rawhide build is available and when nodebug is due to build times, so it is safest to just not even look at the rawhide builds if you want nodebug 19:24:10 and i did the second official build at like 10pm. so hopefully people weren't sitting there waiting for me to commit stuff that late 19:24:50 Aha, there was the difference 19:25:13 I did the second build based on a commit, I don't wait for koji builds. When I got the build note I just assumed it was from the one I had already built 19:25:21 my bad. will pay more attention on it 19:25:48 when you aren't sleeping ;) 19:26:00 indeed 19:26:52 I was more interested in why there was an anomoly than worry about any problems it caused. 19:27:37 human error 19:27:38 humans. very unreliable. 19:27:46 Other than the kswapd issue, things are working pretty well so I don't need updates in a hurry. I seem to be just a bit OCD about grabbing the latest ones. 19:27:55 humans: almost as bad as firmware 19:27:59 so automation would be cool, but would just add more delay in getting things out 19:28:12 jwb: not that bad! 19:28:17 heh 19:29:08 * nirik notes he's been hitting gpu lockups on intel with the latest nodebug rawhide kernel here. 19:29:36 does it recover? 19:30:22 it keeps going, but it's then very very slow. ;( 19:31:07 http://paste.stg.fedoraproject.org/1794/ 19:32:02 might want to post that on dri-devel, with the info in that debugfs file if there's anythign 19:32:15 i've seen hangchecks here, but it doesn't get slower after it recovers 19:32:46 ok, can do next time it hits. 19:34:32 anything else for open floor? 19:35:17 nothing here 19:35:41 * nirik has nothing more 19:35:44 ok, let's end early then 19:35:47 thanks for coming everyone! 19:35:50 #endmeeting