17:59:30 <jwb> #startmeeting
17:59:30 <zodbot> Meeting started Fri Apr 27 17:59:30 2012 UTC.  The chair is jwb. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:59:42 <jwb> #meetingname fedora-kernel
17:59:42 <zodbot> The meeting name has been set to 'fedora-kernel'
17:59:57 <jwb> #meetingtopic Fedora Kernel meeting
18:00:06 <jwb> #topic init
18:00:07 <jforbes> timely
18:00:32 <jwb> alarms are wonderful things :)
18:01:06 <jwb> davej, you around?
18:01:08 * jsmith lurks
18:01:54 <jwb> we can start without davej.  he'll catch up
18:02:11 <jwb> so we failed at putting the agenda on the wiki this week
18:02:19 <jwb> however, there is no agenda this week, so we didn't really fail
18:02:43 <jwb> we'll do a brief review of the releases and then leave it to the open floor
18:02:51 <jwb> #topic rawhide
18:03:00 <davej> yeah, I'm here. sorry.
18:03:08 <jwb> jforbes, you wanna cover rawhide or should i?
18:03:37 <jforbes> I suppose you know the most current state, though really things are churning along
18:03:54 <jwb> yeah, basically just the normal roll
18:04:01 <jwb> we're at 3.4-rc4-git3
18:04:23 <jwb> the 3.4 release seems fairly stable thus far, but as usual i get the feeling we have rather limited exposure at the moment
18:04:46 <davej> my local testing has turned up a bunch of weird vm stuff, but they seem to be edge cases.
18:04:55 <jforbes> RCs have been coming every Sunday.  I have been running it here
18:05:17 <jwb> davej, most of them are from running trinity too, right?
18:05:43 <davej> jwb: yeah, that + oom killer seems to be causing some kind of anon memory leak
18:06:27 <jwb> wait, OOM is leaking memory?
18:06:44 <jwb> that seems... odd
18:06:47 <davej> yeah. the oom killer kills the processes, but for some reason, the memory never gets freed.
18:07:09 <jwb> heh.  excellent work there OOM
18:07:43 <jwb> OK, so the workaround is for Fedora users to not intentionally try and crash/OOM their machine.  i think most people can cope with that ;)
18:08:02 <davej> it's an ongoing mystery. One of the google guys was helping me look into it yesterday, but I've been without access to my mail today, so it's come to a halt
18:08:17 <jwb> #info Rawhide is at 3.4-rc4-git3.  RCs are coming fairly regularly
18:09:09 <jwb> anything else on rawhide?
18:09:37 <jwb> #topic F17
18:09:50 <jwb> who's taking F17?
18:09:51 <jforbes> I can take F17
18:10:34 <jforbes> I was hoping to push 3.3.4 because it contains a number of fixes we could use for release, but in the interest of getting something better for TC2 I am building 3.3.3 right now
18:11:03 <jwb> 3.3.4 was released about 15min ago
18:11:13 <jwb> timing is never on our side :\
18:11:24 <jforbes> Well, then I will stop this build and do 3.3.4 now!
18:11:46 <jwb> are either of those going to make TC2?  i thought it had to go through updates
18:12:02 <jforbes> If we beg test-list I think we can get it in
18:12:13 <jwb> ok
18:12:29 <jwb> #info F17 at 3.3.2.  3.3.4 being built for TC2
18:13:09 <jwb> anything else on F17?
18:13:26 <jforbes> Nothing else major at the moment.
18:13:56 <jwb> #topic F16
18:14:09 <jwb> should be pretty much the same as F17, eh?
18:14:23 <jforbes> Pretty much, I will build 3.3.4 for it as soon as I get F17 building
18:14:31 <davej> pretty much. other than the crazy bug count.
18:15:01 <jwb> #info F16 is on 3.3.2.  3.3.4 will be built and submitted to updates-testing
18:15:10 <jwb> davej, on the bug count
18:15:30 <jwb> so you and i talked about that last week, and i think it's worth mentioning briefly here
18:15:55 <jwb> basically, with all 3 released branches being on the same kernel, we're really condensing our bug count into the most popular release
18:16:19 <jwb> so f16 is going to be highest a bit naturally
18:16:48 <jwb> but as we fix things there, it'll either prevent bugs from showing up in f15/f17 or also close duplicates in those releases
18:17:17 <davej> you can see that from the rate new bugs are getting filed too. this week: f15- no new bugs. f16- 44 new bugs
18:17:48 <jwb> yeah.  anyway, the bug count is still too high but at least it isn't as bad as it might see
18:17:52 <jwb> er, seem
18:18:16 <davej> Just posted http://codemonkey.org.uk/2012/04/27/weekly-fedora-kernel-bug-statistics-april-27-2012/ btw
18:18:28 <davej> we closed more f16 bugs than we had opened this week \o/
18:19:19 <davej> which has actually been happening for the last few weeks, so progress is being made.
18:19:33 <jwb> #link http://codemonkey.org.uk/2012/04/27/weekly-fedora-kernel-bug-statistics-april-27-2012/ weekly bug statistics
18:20:17 <jwb> #info Progress on F16 bug count is being made.  This also helps F15/F17 by either closing out duplicates or preventing those bugs from being hit there as all 3 releases are on the same kernel version
18:20:53 <jwb> anything else on f16?
18:21:37 <VICODAN_> may i ask a quick question?
18:21:42 <jwb> sure
18:21:55 <VICODAN_> i have heard about ongoing issues with intel wifi
18:22:13 <VICODAN_> and i have seen several bugs on kernel.org over several distros
18:22:26 <VICODAN_> can you please talk about that for a second?
18:22:38 <jwb> davej, you want to take that one?
18:22:52 <jwb> or should we round up linville
18:23:02 <davej> linville would be in a better position to answer it probably
18:23:05 <VICODAN_> well
18:23:20 <VICODAN_> whether it's known or not
18:23:23 <davej> I've not been using it personally the last month or so, so I'm a bit out of the loop with it
18:23:45 <VICODAN_> i think the new intel wifi adapters 6xxx series that have wimax might be triggering the crash
18:24:08 <davej> I do recall seeing wimax related crashes in bz this last week
18:24:21 <jwb> let me see if i can get linville here and we can come back to this question during open floor.  sound ok?
18:24:22 <VICODAN_> yes
18:24:30 <linville> here I am
18:24:34 <jforbes> davej: yes, there was one wimax related fix in 3.3.4
18:24:37 <jwb> ah, ok
18:24:44 <VICODAN_> i would say if you see that type of adapter just to disable the wimax radio automatically or, actually fix it
18:24:44 <VICODAN_> heh
18:25:14 <VICODAN_> but i think Intel also needs to come out with a firmware update
18:25:15 <jwb> linville, the question is about the status and possible issues that seem to be ongoing with iwlwifi, and if those have to do with wimax
18:25:20 <jwb> etc
18:25:21 <VICODAN_> I was even having issues on windows
18:25:52 <linville> people actually use wimax? :-)
18:26:10 <VICODAN_> no.
18:26:15 <VICODAN_> that's why i said just disable it.
18:26:53 <jwb> in f17/f18, it's actually moved to modules-extra
18:27:00 <linville> I wouldn't object to turning-off wimax, but I think there are regions of the world that use it
18:27:27 <VICODAN_> what regions?
18:27:57 <VICODAN_> the only time wimax is ever used is on a sprint phone and offices that have wireless ISPs like Covad HiCap
18:29:01 <davej> iirc, we had a request from someone in .ru with wimax that wasn't working this week
18:29:05 <jforbes> I know sprint sells the service around here, not sure if you have to use their dongle or not
18:29:23 <jwb> davej, that was about an out-of-tree madwimax driver
18:29:28 <jwb> not the wimax stuff we build
18:29:35 <jforbes> Yes, the patch from 3.3.4 was actually added before the 3.3.4 release, so someone had a bug on it
18:29:41 <davej> right, but it shows that wimax exists in other regions
18:29:46 <jwb> oh, yes
18:30:13 <linville> that said, I don't know how much effect that has on iwlwifi if you aren't using the wimax part
18:30:36 <VICODAN_> .ru uses wimax?
18:30:42 <jforbes> notting filed the bug
18:30:47 <VICODAN_> jforbes: i use wireless tether on my phone
18:30:52 <VICODAN_> and sprint is discontinuing wimax
18:31:00 <linville> iwlwifi has been refactoring itself for a while with intentions of supporting new hardware
18:31:16 <linville> which seems to have destabilized it
18:31:22 <jforbes> VICODAN_: sprint will keep the WIMAX network up for a while still, just moving to LTE for new bits, they are still trying to decommision old nextel networks
18:31:28 <VICODAN_> yes
18:31:29 <VICODAN_> i know
18:31:32 <VICODAN_> i have a wimax phone
18:31:36 <VICODAN_> evo shift 4g
18:31:53 <VICODAN_> I also have a brand new intel 6 series laptop
18:31:56 <VICODAN_> with intel wimax
18:32:07 <VICODAN_> i dont know where or when i would ever use the wimax on this thing
18:32:36 <VICODAN_> i was kind of frustrated because someone in #fedora-devel brought this issue up and i got the 6150 and they had the 6250 on their latop.. i was mad they got a 5ghz radio and i didnt.
18:32:45 <jwb> i think the 2 main points here are 1) iwlwifi is in a turbulent state at the moment overall, including the firmware, and 2) wimax may or may not contribute to that but we can't disable it because some people might be using it
18:32:57 <davej> hmm, the wimax modules might be a candidate for modules-extra.
18:33:09 <jwb> i already pointed out they were in modules-extra for f17/f18
18:33:19 <davej> oh, great.
18:33:36 <VICODAN_> great
18:33:41 <VICODAN_> okay
18:33:45 <VICODAN_> 2 other unrelated qustions
18:34:04 <VICODAN_> and feel free to flame and say no
18:34:09 <davej> NO
18:34:14 <VICODAN_> :P
18:34:15 <VICODAN_> are there any plans for built in virtualbox support and AMD Graphics support
18:34:22 <jforbes> NO
18:34:28 <jwb> virtualbox NO (being serious)
18:34:28 <VICODAN_> :P
18:34:34 <davej> I'd go as far as "hell no"
18:34:39 <VICODAN_> why is that a no?
18:34:43 <jforbes> Well, AMD graphics is well supported by open source driver
18:34:50 <VICODAN_> eh
18:34:53 <jwb> we'd be happy to enable virtualbox modules as soon as they get them into the mainline kernel
18:34:53 <VICODAN_> mesa is alright
18:35:01 <VICODAN_> jwb: how would they do that?
18:35:11 <jforbes> Virtualbox is an absolutely not, they are not willing to go into mainline
18:35:28 <jwb> VICODAN_, they'd submit them like everyone else
18:35:28 <VICODAN_> well from my understanding they werent wanted there
18:35:34 <jwb> they never tried
18:35:39 <jwb> at least afaik
18:35:39 <VICODAN_> i thought there was a redhat vs oracle thing as well
18:35:49 <jwb> what?  no
18:35:52 <VICODAN_> okay
18:35:53 <jforbes> VICODAN_: weren't they the ones that tried but wanted to break everything else in the process?
18:36:00 <VICODAN_> no
18:36:26 <misc> no, that's just vbox people prefer to keep the freedom of changing their own ABI between kernel module and the userspace
18:36:28 <jforbes> VICODAN_: it has nothing to do with RH vs Oracle, it has everything to do with they must submit upstream, and actually work with others to get things accepted.
18:36:46 <jwb> misc, yeah that was my understanding too
18:36:59 <VICODAN_> so from an outsider but fan of virtual box's perspective lets say I'm beta testing fedora 17 and vbox guest additions stop working. they always complain about how new kernels break virtualbox and they dont support prerelease software blah blah and redhat loves kvm and could careless about virtualbox
18:37:38 <VICODAN_> so with that i will drop it, and let them know that their conception is inaccurate on that issue
18:37:52 <jforbes> VICODAN_: it isn't an us vs. them thing, it's a mainline kernel vs not thing.  if they can't be bothered to get their drivers into mainline, we can't be bothered to support them.  Xen was the same way, and they finally got into mainline
18:37:59 <jwb> kvm is in-kernel.  if it wasn't, fedora wouldn't be building that either at this point
18:38:06 <VICODAN_> yeah
18:38:06 <jwb> hell, we build xen now that it's in tree
18:38:08 <jforbes> VICODAN_: and now Xen is treated with the same respect as anything else
18:38:08 <VICODAN_> and so is hyper-v
18:38:16 <jwb> i can't think of anyone here that actually LIKES xen
18:38:23 <jwb> except for maybe jforbes and he's weird
18:38:23 <VICODAN_> so i see kvm and hyper-v in the kernel and i wonder why not vbox
18:38:39 <jwb> up to the vbox people to make it happen
18:39:02 <jforbes> VICODAN_: and that was your answer, if vbox cared enough to get their things upstream, we would care enuogh to support them in Fedora
18:39:19 <jforbes> but if they don't it just creates a nighmare for us
18:40:26 <jwb> what was your other question?
18:40:57 <VICODAN_> fair enough
18:41:04 <VICODAN_> about amd graphic drivers
18:41:19 <jwb> what about them?
18:41:20 <VICODAN_> anyway to get native support
18:41:32 <jwb> er... you mean flgrx?
18:41:32 <VICODAN_> like fglrx never installs properly and freezes my system
18:41:33 <VICODAN_> yes
18:41:35 <jwb> no
18:41:38 <VICODAN_> is that an AMD problem?
18:41:38 <jforbes> Similar story, though at least most AMD cards are supported out of the box, with a decent experience
18:41:47 <VICODAN_> yes
18:41:50 <jwb> the radeon module covers most of them
18:41:51 <VICODAN_> decent experience
18:41:56 <VICODAN_> but not great
18:42:03 <VICODAN_> again, that's an AMD problem right?
18:42:05 <jwb> flgrx is proprietary, so it's the same story as vbox but even worse
18:42:11 <VICODAN_> yes
18:42:21 <jforbes> If you want the advanced features of fglrx, you have to deal with their inability to keep up as well
18:42:37 <jwb> same for nvida, wl, the vmware stuff, etc
18:43:17 <jforbes> Nothing at all against amd, most of my systems have radeon graphics... But I wouldn't install fglrx, and can't say I have missed it
18:43:30 <VICODAN_> well nvidia stuff actually works out of the box
18:43:47 <VICODAN_> jforbes: same here, i'd just like to have the full support if it were possible. i'm 100% amd fanboy over here
18:43:59 <jwb> if nvida works, it's not through anything we're doing
18:44:00 <brunowolff> dahdi-linux is another example, but they are much better at keeping up lately. the 2.6.1 release already has a fix to accommodate a change in 3.4.
18:44:41 <jforbes> VICODAN_: if they can't support their single driver themselves, and they have the source, it is impossible for us to support it when we don't have the source
18:44:58 <VICODAN_> well it seems that new kernels break things that used to work
18:45:13 <jwb> that's why it's important to get drivers in-tree
18:45:19 <misc> it still work for the rest of the kernel :)
18:45:32 <jforbes> VICODAN_: and if they were open source and in tree, the people making changes that impact them would also change their driver to support those changes.  It works for everyone.
18:45:48 <jforbes> But they are neither in tree or open source, so there isn't anything we can do
18:45:55 <brunowolff> Do you look at there source trees for fixes? That's what i do for dahdi-linux which I am running on a machine using a 3.4 kernel.
18:46:54 <jwb> ok, so i think we need to move on and at least finish up the releases
18:46:58 <jwb> #F15
18:47:02 <jwb> er,
18:47:05 <jwb> #topic F15
18:47:09 <jwb> ew
18:47:24 <jwb> i know the 3.3.3 rebase (2.6.43.3) finally went to stable
18:47:29 <VICODAN_> thanks guys
18:47:33 <jwb> so at least it's there
18:47:39 <jwb> VICODAN_, sure, thanks for participating
18:47:56 <jwb> anything else on f15 worth noting?
18:48:12 <jwb> actually, 3.3.2
18:48:23 <VICODAN_> np
18:48:25 <jwb> #info F15 is at 2.6.43.2 (3.3.2)
18:49:25 <jwb> ok, we have a few minutes left for more questions or other topics
18:49:29 <jwb> #topic open floor
18:49:32 <jforbes> Nothing else here, though I will also do 3.3.4 for F15
18:49:38 * nirik has one item...
18:49:53 <jwb> nirik, shoot
18:49:53 <nirik> re: darkserver
18:49:58 <jwb> oh yes!
18:50:06 <jwb> #topic open floor - darkserver
18:50:17 <nirik> so we are running a darkserver plugin on koji, which pulls out buildids and sticks them in a db.
18:50:24 <nirik> this takes a long time on things like the kernel...
18:50:38 <jwb> somewhere between 30-60min per build additional time
18:50:45 <nirik> I talked with kushal a bit about it and he had some ideas to fix it, but I've not seen him around for a while...
18:50:55 <nirik> so, could you guys perhaps file a darkserver bug on it ?
18:51:02 <nirik> and we can try and get some traction to get it fixed.
18:51:19 <jwb> yeah, i can do that.  infrastructure ticket?
18:51:22 <jwb> or bugzilla?
18:51:27 <nirik> or just against darkserver in bugzilla
18:51:33 <jwb> ok great
18:51:34 <nirik> probibly best in bugzilla.
18:51:42 <nirik> if you could cc me that would be great too.
18:51:45 <jwb> iirc, he suggested running it async in the background or something
18:51:49 <nirik> yeah.
18:51:53 <jwb> but the plugin doesn't work that way
18:52:04 <jwb> ok, i'll get it opened
18:52:17 <nirik> I'm sure its affecting other packages too...
18:52:24 <nirik> but the kernel has that massive debuginfo. ;)
18:52:35 <jwb> #action jwb to open bug against darkserver for additional build time issue
18:52:52 <nirik> thanks, just wanted to make sure it didn't get lost.
18:52:55 <jwb> thanks for the reminder
18:52:57 <davej> not sure the debuginfo size is going to get any smaller any time soon
18:53:02 <davej> at least, not from our doing
18:53:10 <jwb> yeah
18:53:39 <jwb> #topic open floor
18:54:23 <jwb> jforbes, we don't have much time now.  want to briefly talk about testing or queue it up first thing next time
18:54:30 <dgilmore> jwb: any concerns over any of the arm stuff?
18:54:34 <jwb> so we don't keep pushing it out
18:54:37 <jwb> dgilmore, in what way?
18:54:50 <dgilmore> jwb: not sure. just in general?
18:55:00 <dgilmore> anything you owuld like us to do differently?
18:55:31 <jwb> at the moment, no.  the arm changes seem fairly minimal thus far, and if there is a mistake you and probinson are quick to respond
18:55:36 <dgilmore> jwb: happy for jforbes to talk about testing
18:55:39 <jforbes> jwb: Lets queue it for next time
18:56:01 <jwb> maybe a reduction in the number of ARM boards more in line with whatever the PA proposal winds up being, but it isn't like it's impacting us right now
18:56:04 <jwb> jforbes, word
18:56:49 <dgilmore> jwb: ive heard 3.5 should start seeing us starting to build kernels for multiple boards
18:56:59 <jwb> would be nice
18:57:07 <dgilmore> so that should mean we can start looking at reducing the number of images
18:57:12 <jwb> ok
18:59:24 <dgilmore> just wanted to make sure we are doing things ok and being transparent
18:59:31 <dgilmore> and fix any issues you see
19:00:00 <jwb> i think the kernel side of things has been going well.  so thanks for the effort there
19:00:23 <jwb> ok, the clouds are starting to form
19:00:28 <jwb> i think we'll call it a meeting
19:00:30 <jwb> thanks everyone
19:00:33 <jwb> #endmeeting