[01:21] <VampyreDragon> Good Evening
[08:56] <amitk> morning pgraner 
[09:02] <pgraner> amitk: good morning. I see you made it back ok
[09:07] <amitk> pgraner: yeah... wasn't too bad on the way back
[09:09] <pgraner> amitk: cool. 
[16:29] <nir> join #ubuntu-helpteam
[16:29] <nir> hi
[17:02] <BenC> amitk, smb_tp, cking, rtg: ping a ling
[17:02] <smb_tp> BenC, There I am
[17:02] <cking> BenC, me too
[17:02] <rtg> BenC: dude
[17:02]  * zul lurks
[17:02] <BenC> sweet
[17:02] <amitk> BenC: ping
[17:02] <cr3> hey dudes, I'll be joining today
[17:02] <BenC> ogasawara, slangasek: alive?
[17:03] <slangasek> hi
[17:03]  * ogasawara waves
[17:03] <smb_tp> cr3, hey dude :)
[17:03] <BenC> The gangs all here
[17:03] <zul> hi cr3
[17:03] <BenC> Call the meeting to order then
[17:03] <BenC> Primary agenda for today, which we will dive right into, is whether we should start the move to 2.6.27 for intrepid
[17:03] <cr3> smb_tp: yo mama!
[17:04] <BenC> If we do it, it has to start now
[17:04] <zul> BenC: that would be nice 
[17:04] <BenC> Luckily, I've been maintaining a synced 2.6.27 tree that is pretty much a drop in replacement for 2.6.26
[17:04] <BenC> so the "doing it" part is pretty much "done"
[17:04] <smb_tp> As you said the volume of new stuff went down, so the main window might be over
[17:05] <BenC> Other than the upload
[17:05] <cking> I think the benefits (additional drivers, etc) outweigh the risks.
[17:05] <BenC> The drawbacks we face, and have to decide whether it is worth the effort are:
[17:05] <BenC> 1) 2.6.27 timeline may leave us with a pre-released kernel at intrepid release time
[17:06] <BenC> 2) The possibility that the kernel will be less stable due to it being so fresh (even if it is final 2.6.27 at intrepid release)
[17:06] <amitk> BenC: bugs(2.6.26 + backport of alsa+wireless) > bugs(2.6.27-rcX)
[17:07] <BenC> As cking and amitk have pointed out, we are already considering moving to a newer wireless and alsa stack in 2.6.26, which we would get for free moving to 2.6.27
[17:07] <rtg> amitk: I'm beginning to become convinced that backporting the wireless pile is not feasible.
[17:08] <BenC> One of the main reasons for alsa and wireless is newer device support that isn't easy to backport in bits
[17:08] <slangasek> and if the timeline leaves us with a pre-release at intrepid release, is the intent that it be updated to 2.6.27 release in SRU?
[17:08] <BenC> slangasek: yes
[17:08] <BenC> slangasek: if we are left with -rc at release, the amount of delta to final wont be much
[17:09] <BenC> slangasek: so we should be able to evaluate every commit that will be there
[17:09] <rtg> slangasek: I also think we (the kernel team) should follow the stable tree updates until upstream stops maintaining it.
[17:09] <slangasek> that's not an answer I like very much, just because SRUs take time away from working on the next dev release
[17:10] <BenC> slangasek: hardy SRU's are already taking up time, and we didn't do this for hardy
[17:10] <slangasek> for an LTS it's understandable that there are going to be SRUs
[17:10] <slangasek> for intrepid, which isn't an SRU, I think that's spreading ourselves rather thin
[17:10] <BenC> slangasek: I don't think it will incur a long period of overhead...just a one shot deal
[17:10] <slangasek> er, isn't an LTS
[17:11] <BenC> slangasek: and because we are on a continuous move, we'll be able to get started on intrepid+1 kernel pretty quickly
[17:11] <slangasek> no SRU is a "one-shot deal" for the SRU team :)
[17:11] <BenC> slangasek: IOW, we wont have the huge burden of forward porting all of our patches across two versions of the kernel before starting...we'll have a kernel ready on day zero of intrepid+1 opening
[17:12] <BenC> our work on intrepid+1 wont really start until after UDS, so we have that time frame
[17:13] <BenC> slangasek: we usually have a month or so of SRU's for the kernel, even on non-LTS...do you think this one would incur more overhead than usual?
[17:13] <BenC> (and note, most of those SRU's are lum/lbm work for supporting newer drivers, which will be moot because of the move to 2.6.27)
[17:14] <slangasek> well, my work on intrepid+1 has to start significantly earlier than UDS in order to get the archive opened, so having to spend additional time on SRUs would be resource contention :)
[17:14] <BenC> slangasek: plus we have to consider how much work it will be for us if we stick to 2.6.26
[17:14] <slangasek> right, that's fair
[17:14] <smb_tp> It also depends on the policy. If it is agreed to follow the stable kernel updates it is less overhad to process...
[17:14] <amitk> it would also help to move kerneloops package to default install if we decide to go with 2.6.27 to help upstream bug identification
[17:14] <BenC> amitk: sounds like a volunteer has stepped in to do that ;)
[17:14] <slangasek> OTOH, it also seems to imply that the kernel is going to be undergoing significant changes well past FeatureFreeze?
[17:15] <amitk> BenC: ack
[17:15] <slangasek> which can have a destabilizing effect on bits of userspace, as things are deprecated etc
[17:15] <zul> I guess from the server team perspective there is additonal features that we want for the virtualization stuff that we do (xen64 and more kvm features)
[17:15] <BenC> slangasek: well, the kernel updates past feature freeze will be limited to bug fixing by upstream's process
[17:15] <slangasek> ok
[17:15]  * soren agrees with zul and drools over mmu notifiers
[17:15] <BenC> zul: xen64 is in .27?
[17:15] <slangasek> you seem to have addressed all the objections I can think of, then
[17:15] <amitk> slangasek: things don't really get deprecated in -rc6/rc7, it is only bug fixing
[17:16] <zul> BenC: yep
[17:16] <BenC> another reason to add to the list, thanks
[17:16] <BenC> slangasek: I've been watching .27 tree since it opened, and the churn has already dropped to bug fixing only
[17:16] <zul> also so we dont have to carry a different flavour for redhat's xen64 patchset
[17:17] <slangasek> I'd appreciate it if this plan can be floated by more people than just me (i.e., cjwatson/Keybuk) before we're committed to it
[17:17] <BenC> slangasek: I'll post the summary of this discussion and our reasoning to -devel to get feedback
[17:18] <BenC> slangasek: If we do it, I'd like to hit next Alpha
[17:18] <slangasek> given that next alpha is after FF, I agree :)
[17:18] <BenC> when is next alpha?
[17:18] <BenC> two weeks from thu?
[17:18] <slangasek> Sep 
[17:18] <slangasek> so, yes
[17:19] <BenC> If we can commit to this by next week, same time, we should be good then
[17:20] <BenC> Ok, so action: Me: post summary for discussion on ubuntu-devel list
[17:20] <BenC> Will do that today
[17:20] <BenC> That's the only topic I had formally set for this
[17:20] <BenC> slangasek, zul, soren: Thanks for input
[17:20] <zul> np
[17:21] <smb_tp> Ok, then we might discuss quickly about the -security fixes
[17:21] <BenC> Anyone have anything they want to bring up now?
[17:21] <BenC> smb_tp: Ok, podium's yours then :)
[17:21] <smb_tp> It seems quity urgent for at least Gutsy to have something out
[17:21] <cr3> BenC: I would like to mention that all daily iso images for ubuntu (alternate), kubuntu, mythbuntu, xubuntu, ubuntu-server are being tested
[17:21] <smb_tp> I checked those asn fixes upstream and they disagree how to fix
[17:22] <smb_tp> One is fixed by ULONG to UINT
[17:22] <slangasek> BenC: n/p, thanks for the invite :)
[17:22] <cr3> BenC: this is all done automatically, so I would like to take this opportunity to ask whether the kernel team might have special requests for tests to run. I'll be integrating ltp and autotest, but I'm wondering what might be your priorities
[17:22] <smb_tp> the other (better as I guess) by making size to be size_t
[17:22] <BenC> cr3: excellent!
[17:23] <BenC> cr3: let's let smb finish this topic, and we'll open to that discussion
[17:23] <BenC> smb_tp: Ok...is it easy to cherry pick the upstream fixes?
[17:24] <smb_tp> Ok, quite simple, yes. And if upstream is happy with that.
[17:24] <BenC> smb_tp: Ok, can you resubmit the upstream versions to kernel-team for ACK?
[17:24] <smb_tp> ASAP
[17:25] <BenC> I don't see a problem with ACK'ing them, but just to keep the process rolling...
[17:25] <BenC> smb_tp: thanks
[17:25] <BenC> cr3: Ok, on to your topic
[17:25] <BenC> cr3: what are you currently running as testing right now?
[17:25] <cr3> BenC: so, I would like to know what the kernel team would find most urgen, preferably in order of priority, to test in my automated suite
[17:26] <cr3> BenC: it's rather pathetic right now, I'm simply making sure that the image installs and then making sure that a few processes relating to specific packages are running
[17:26] <ogasawara> cr3: can you refresh my memory what specific kernel tests autotest provides?
[17:27] <rtg> cr3: device support, virtualization issues, tests that focus on kernel stuff.
[17:27] <cr3> ogasawara: I don't recall, sorry
[17:27] <cr3> rtg: for device support, I have hardware to help me automate audio testing but it still requires a bit of work, I have also thought of a way to automate webcam testing and I need to perform some exploration for modem testing.
[17:27] <cking> cr3: autotest covers ~
[17:28] <cr3> rtg: for those devices and potentially other devices, what might be your priorities?
[17:28] <cking> cr3: try again..  ltp covers 3000+ tests, fs, memory, scheduler, disk I/O, networks, syscalls 
[17:28] <rtg> cr3: disk, wireless, video
[17:28] <BenC> cr3: a check for /proc/asound/card0 existing
[17:28] <cr3> BenC: noted
[17:29] <BenC> cr3: checking that there is an interface for every PCI device that is of network class
[17:29] <amitk> cr3: how many machines and what kinds do you test on?
[17:29] <cking> cr3: maybe consider dbench, aio-stress, aio-cp, hackbench, vmmstress, kernbench
[17:29] <BenC> cking: one thing we have to remember is "daily testing" and the time it takes to run tests :)
[17:30] <rtg> cr3: are you doing anything with lvm and/or RAID stuff?
[17:30] <BenC> cr3: is this geared at testing the dist, or specific hardware?
[17:30] <cking> BenC: true.. 
[17:30] <cr3> amitk: I have about 100 machines ranging from laptops, desktops, servers and a few thin clients I'm not testing very well
[17:30] <cking> cr3: How much time does the current testing take?
[17:31] <cr3> amitk: the automated tests right now are very poor, the most relevant being simply testing the installation. however, I'm now in a position to add more tests since the whole process is completely automated so I get test results when I come in the office in the morning :)
[17:31] <rtg> cr3: wow, you just about need a test profile for each machine 'cause some of the tests aren't relevant.
[17:31] <cking> cr3: I will send you some info from OLS on testing that I may be useful. 
[17:32] <cr3> cking: I'm reluctant to test the hardware with benchmark tools rather than the compatibility of ubuntu with the hardware. what do you think is the particular relevance of benchmark tools?
[17:32] <amitk> cr3: if you can simultaneously test on all of them, then I'd like to know if every PCI and USB device has a driver associate with it.
[17:32] <cr3> rtg: nothing with lvm or raid right now, but noted
[17:32] <smb_tp> cr3, benchmarks usually are doing some stress test
[17:32] <rtg> cr3: per amitk's suggestion, you should definitely note unsupported devices.
[17:33] <cr3> BenC: now that certification is under QA, the tests are geared towards both hardware and software. basically, everything :)
[17:33] <smb_tp> cr3, and some problems show up on procesing high volumes of traffic network or storage
[17:33] <BenC> cr3: Ok...just wanted to make sure the comments I was making fell under the scope you were working toward :)
[17:33] <cr3> cking: current testing takes about the time of installation, so about 20 minutes. So, I get test results between 20 and 1h20 minutes after a new ISO images is made available on cdimage.ubuntu.com
[17:34] <cr3> rtg: the relevance of some tests is currently detected on the machine itself. so, if hal detects that there's an audio controller, then the audio tests are run
[17:34] <rtg> cr3: makes sense
[17:34] <cr3> rtg: however, this doesn't always work. for example, there might be two network controllers in a machine but only one is detected
[17:35] <cr3> rtg: so, I will be introducing the concept of profiles but I have no timeline for this
[17:35] <cking> cr3: It would be interesting to see how much coverage these tests actually do on the entire kernel - I believe that LTP only covers a few percent of the kernel
[17:36] <cr3> smb_tp: true, but there's a difference between running a cpuburn and compiling the kernel with num_processors + 1 processes. I think the former is irrelevant because it only tests the hardware whereas the latter is relevant because it tests smp
[17:36] <BenC> Ok. I say we take this up more in depth over email...sounds like we have some good ideas, and cr3 is probably going to get swamped :)
[17:37] <cr3> cking: I think ltp in combination with autotest and lsb might cover a good portion of the kernel
[17:37] <smb_tp> cr3, I would rather think of iobench or netbench or how they are named
[17:38] <cr3> smb_tp: noted, I actually used to have those as part of my suite, but I removed them eventually because I figured the provided little bang for the buck: some of these benchmarks take a long time to run which delays test results
[17:38] <cr3> smb_tp: one solution might be to dispatch test results incrementally, instead of in a batch, but there are no real plans for this yet
[17:40] <BenC> cr3: Are these results going to be made available for others?
[17:40] <cr3> ok, I think I have plenty to work on until the meeting next week. I will try to keep you guys posted
[17:40] <cr3> BenC: yes. this is currently done under the certification framework which is gradually being opened to the community since the department is now under QA
[17:41] <BenC> cr3: great, thanks
[17:41] <BenC> If no one else has anything to discuss....
[17:41]  * BenC pauses for slow typers
[17:41] <amitk> cr3: what's your annual HW upgrade budget to keep with the current fashion? ;-p
[17:42] <BenC> amitk: we don't stock Mac's, so we're not into fashion ;)
[17:42] <amitk> hehe
[17:42] <cr3> amitk: I have no budget, this is all hardware sent to us by hardware vendors
[17:43] <amitk> good to know
[17:44] <cr3> amitk: if you think we should have specific devices, let me know and I could raise this issue with heno
[17:44]  * BenC calls the meeting adjourned
[17:44] <cr3> personally, I would rather invest my budget in testing infrastructure such as some telephone switch for testing modems
[17:44] <BenC> Thanks everyone. See you next week
[17:45] <cr3> thanks for all the suggestions folks, much appreciated!
[18:53] <zul> BenC: where are the 2.6.27 kernels again?
[18:55] <BenC> zul: http://kernel.ubuntu.com/pub/next/
[18:59] <zul> thanks
[19:14] <rtg> soren: bug #257569, can you think of a use case for IP filter and connection tracking in the virtual kernel?
[19:15] <elmo> rtg: kernels without those options are useless to me, FWIW
[19:16] <rtg> elmo, yeah, but a virtual kernel?
[19:16] <elmo> rtg: well, I use the -xen kernel, but yes ;-)
[19:20] <_ruben> virtualized routers arent that uncommon
[19:20] <_ruben> especially for testing purposes, but also live environments
[20:01] <soren> rtg: Yes. I use it all the time.
[20:02] <soren> rtg: My vpn endpoint is a virtual machine.
[20:02] <rtg> soren: I'm talking about the virtual flavour.
[20:02] <soren> rtg: Yes...
[20:03] <soren> rtg: I thought I was too.
[20:04] <soren> rtg: My vpn server is a virtual machine, which would be running the virtual kernel if there were an amd64 version of it.
[20:04] <rtg> soren: config.virtual:# CONFIG_NF_CT_NETLINK is not set
[20:04] <soren> rtg: The only difference between the server kernel and the virtual kernel really should be device drivers.
[20:05] <rtg> soren: ok, I'll enable it for -virtual.
[20:05] <soren> rtg: In Intrepid?
[20:05] <rtg> soren: Hardy for now. I'll make sure Intrepid is consistent
[20:05] <soren> Don't worry about intrepid.
[20:05] <soren> It's handled quite differently.
[20:06] <rtg> soren: I want to make sure the main kernel flavors have it enabled.
[20:06] <soren> rtg: all my vm's are amd64 ones, so I don't actually use the virtual kernel flavour much.
[20:06] <soren> rtg: (the production ones are running hardy)
[20:06] <soren> Yes, they should all have the same ip filtering capabilities.
[20:07] <rtg> soren: Intrepid has connection tracking enabled for all flavours.
[20:07] <soren> Right.
[20:20] <perfector> will increasing the kernel shared memory improve overall performance?
[21:36] <arturo-xinerama> hey everyone. I'm trying to follow online instructions to use my Microsoft Ergonomic Keyboard, but modprobe usbnek4k says no such module found
[21:36] <arturo-xinerama> running kernel 2.6.24-19-generic
[21:36] <arturo-xinerama> last thing I read this module was included in the 2.6.24 kernel release
[23:05] <chris_goe> arturo-xinerama: you can use "/sbin/modprobe -l" to see which kernel modules are available