19:00:03 <jwb> #startmeeting fedora-kernel
19:00:03 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:13 <jwb> #meetingtopic Fedora Kernel
19:00:19 <jwb> #topic init
19:00:25 <jwb> ok, davej is out this week
19:00:26 <jwb> i'm here
19:00:31 <jwb> anyone else?
19:00:45 <jforbes> I am here
19:01:43 <jwb> ok.  maybe just the two of us :)
19:02:02 <jwb> i think i'll just touch on some small points for 18, and then we'll open floor it
19:02:10 <jwb> #topic F18 beta status
19:02:10 <jforbes> That works
19:02:22 <jwb> So on the kernel front for the F18 beta, we're in decent shape
19:02:42 <jwb> there are two things in the currently queued beta kernel that are broken, but not seriously so
19:03:03 <jwb> 1) 'flavour' kernels (e.g. PAE, debug, PAEdebug) are have incorrectly signed modules
19:03:22 <jwb> 2) external kernel module builds will fail because of modsigning
19:03:39 <jwb> the good news is that these are both fixed, and included in the update i submitted today
19:04:02 <jwb> 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 <jwb> there are other bugs open, but nothing that is screaming "blocker" at the moment
19:04:58 <jwb> somewhat relatedly, there's a bug open against dracut because it's stripping off module signatures
19:05:17 <jwb> i've fixed that with a patch in the bug, but no response yet.  i think haraldh is out
19:05:30 <jwb> again, not a major problem unless you're in enforcing mode
19:05:45 <jwb> or fips mode i guess
19:06:00 <jwb> that's about all i can think of for f18 beta
19:06:27 <jforbes> I am still looking into an issue with upower not recognizing UPSs
19:06:51 <jwb> ok.  i think there's another bug that just got moved over to the kernel about that too
19:07:20 <jforbes> 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 <jwb> no i was thinking of 845770.  not the same, but maybe related
19:08:19 <jforbes> ahh, right
19:08:33 <jwb> though that one has a lengthier history.  might be some confusion in tehre
19:09:02 <jwb> 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 <jwb> ok, anything else on f18?
19:09:54 <nirik> sb is still in limbo?
19:09:57 <jforbes> nothing here
19:10:16 <jwb> nirik, legal limbo
19:10:19 <nirik> yeah. ;(
19:10:26 <jwb> from a technical side, things are ok
19:10:31 <nirik> cool.
19:10:53 <jwb> ok, let's move on
19:10:56 <jwb> #topic open floor
19:11:11 <jwb> we're skipping the overview of all the releases today.  not much really worth talking about
19:11:22 <jwb> but we'd be happy to discuss topics brought up, or answer questions
19:11:29 <brunowolff> I haven't seen anything new on lkml for the kswapd issue. Is anything happening there?
19:11:45 <jwb> there's supposedly two reverts going in
19:11:51 <jwb> which i've not seen go in yet
19:12:01 <jwb> 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 <jwb> if they're queued in the akpm tree, they'll probably go in towards the end of the release's development
19:15:35 <brunowolff> Are there further thoughts on modifying the names used for rawhide nodebug repo kernels to avoid conflicts?
19:16:40 <jforbes> brunowolff: not really. conflicts are easily avoided with exclude kernel* in the rawhide repo
19:18:05 <brunowolff> 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 <brunowolff> Since there is a more current build as of the last hour or so, the issue is mostly moot.
19:18:47 <jforbes> brunowolff: there has been a nodebug build of every kernel that happened, but there were two rawhide kernels the other day
19:19:13 <jforbes> brunowolff: in that case, the second build launched before the first one completed, and the first one never made the repository
19:19:36 <jwb> there we go, fixing stuff too fast again ;)
19:19:37 <jforbes> see my note earlier about nodebug builds taking more than 4x as long as regular rawhide builds
19:19:56 <brunowolff> It was the later kernel that didn't make the repo as far as I could tell.
19:20:38 <jforbes> git1.3 was in the repo this morning, rawhide should have been on git1.2
19:21:07 <brunowolff> 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 <jwb> it's merely a timing problem
19:21:42 <jwb> the last digit is 'baserelease' in the kernel.spec file
19:21:53 <jwb> nodebug just increments it by one and builds
19:22:01 <jwb> but that is never committed
19:22:09 <jforbes> Right
19:22:17 <jwb> so when i incremented and built a second official build, it conflicted
19:22:20 <jwb> it'll be fairly rare
19:23:12 <brunowolff> 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 <jwb> it's not automated
19:23:44 <jforbes> 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 <jwb> 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 <jforbes> Aha, there was the difference
19:25:13 <jforbes> 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 <jforbes> my bad. will pay more attention on it
19:25:48 <jwb> when you aren't sleeping ;)
19:26:00 <jforbes> indeed
19:26:52 <brunowolff> I was more interested in why there was an anomoly than worry about any problems it caused.
19:27:37 <jforbes> human error
19:27:38 <jwb> humans.  very unreliable.
19:27:46 <brunowolff> 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 <jwb> humans: almost as bad as firmware
19:27:59 <jforbes> so automation would be cool, but would just add more delay in getting things out
19:28:12 <jforbes> jwb: not that bad!
19:28:17 <jwb> heh
19:29:08 * nirik notes he's been hitting gpu lockups on intel with the latest nodebug rawhide kernel here.
19:29:36 <jwb> does it recover?
19:30:22 <nirik> it keeps going, but it's then very very slow. ;(
19:31:07 <nirik> http://paste.stg.fedoraproject.org/1794/
19:32:02 <jwb> might want to post that on dri-devel, with the info in that debugfs file if there's anythign
19:32:15 <jwb> i've seen hangchecks here, but it doesn't get slower after it recovers
19:32:46 <nirik> ok, can do next time it hits.
19:34:32 <jwb> anything else for open floor?
19:35:17 <jforbes> nothing here
19:35:41 * nirik has nothing more
19:35:44 <jwb> ok, let's end early then
19:35:47 <jwb> thanks for coming everyone!
19:35:50 <jwb> #endmeeting