=== clever_ is now known as clever [01:18] I notice that the headers deb created for a x86 32-bit kernel, has a bustem symlink in it: include/asm points to asm-i386 [01:18] any ideas what I should check? === lamont` is now known as lamont [08:16] moin === \sh_away is now known as \sh [09:15] chuck_: Seem to me that this commit (in mainline) 87d034f3139b5f0d93df2ba58f37d6f2c2c7eeb6 should be added in Hardy. [09:28] so is the kernel team the best place to ask about initramfs-tools scripts? [09:31] It is possible but unlikely. [09:32] what on earth is the resume script waiting five seconds for? [09:32] I suggest you to ask on #ubuntu-devel. [09:33] ok then [09:39] is the ML a better place to watch for kernel work? this place always seems so dead [10:08] hi, I'm running gutsy and while debugging something with vanilla .25-rc6 I get dbus errors when logging in in gdm [10:08] is this some known issue ? [10:08] (the error is something like "could not connect to /tmp/dbusXXXX") [10:14] tonfa: Yes [10:15] do you have some pointer ? (is it in launchpad ?) [10:24] Bug #146946 [10:24] Launchpad bug 146946 in gnome-control-center "[gutsy] Gnome settings daemon randomly does not work" [Medium,Incomplete] https://launchpad.net/bugs/146946 [10:27] ok, thanks [10:27] I'll try restarting next time I boot this kernel [10:28] that's weird that it (almost) always happens with .25-rc6 and never with gutsy's kernel [10:29] timing issues are like that [10:29] yup, I'm reading the bug report [10:29] thanks a lot for the pointer :) === \sh is now known as \sh_away === \sh_away is now known as \sh === chuck_ is now known as zul [12:24] tjaalton: any idea why lrm is not loading nvidia-legacy for me at boot, when I should be (and have always been) using nvidia-new [12:25] in fact, I have nvidia-glx-new package installed [12:29] would it be reasonable to target bug 197929 for beta? [12:29] Launchpad bug 197929 in linux "Backlight adjustment no longer works on Thinkpad X61s" [Medium,Triaged] https://launchpad.net/bugs/197929 [12:30] (also affects X300) [12:33] zul: Seem to me that this commit (in mainline) 87d034f3139b5f0d93df2ba58f37d6f2c2c7eeb6 about Xen should be added in Hardy. [12:34] abogani: gitweb url? [12:36] Ng: we can give it a try [12:37] zul: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=34f10fc9886450c2e8a336f7022805c4a73e10f1 [12:37] abogani: thanks [12:38] zul: Hope this helps. [12:38] abogani: we dont use paravirt xen for hardy :) [12:38] abogani: for ibex probably :) [12:38] zul: Opsssss :-) [12:39] zul: What is virt tech supported by Ubuntu Server Team? KVM? [12:39] kvm [12:40] BenC: I'm not sure what the patch was supposed to do, but it's definitely breaking backlight on my laptop, I booted -10 and the backlight works [12:40] Ng: hmm, ok [13:20] tjaalton: oops, I mean it's not loading nvidia-new for me, it's loading nvidia-legacy instead === LifeHacker is now known as tuxmaniac [13:50] BenC: are we still uploading for Beta? [13:50] #147087 is kind of silly [14:24] bug #147087 [14:24] * BenC kicks ubotu [14:24] bug #147087 [14:24] Launchpad bug 147087 in linux "No sound on Aluminium iMac with PCI ID 8086:284b" [Medium,Confirmed] https://launchpad.net/bugs/147087 [14:57] Is there any chance the one-line patch from bug #39414 could be applied? Without this patch, many people won't be able to use bluetooth headsets. [14:57] Launchpad bug 39414 in linux-source-2.6.15 "syslog is flooded with messages after connecting bluetooth usb dongle" [High,Fix released] https://launchpad.net/bugs/39414 [15:29] UBUNTU: custom/rt: Disable toshiba_acpi, since it isn't compatible :-? [16:02] cking, amitk: ping [16:02] hi [16:04] ping [16:04] Ok, welcome to the kernel team IRC meeting [16:05] For those that don't know, meeting information is available here: https://wiki.ubuntu.com/KernelTeam/Meeting [16:05] Since we are closing in on release, and are under kernel freeze, we are going to keep this short so everyone can get back to work [16:05] cking: Can you start off with your status and current focus [16:06] Yep. Been looking a various kernel bugs, ranging from the trivial patch to the more perplexing. [16:07] For example, usplash messing up vgacon driver colors and causing blanking not to work for all colors in the palette. [16:08] cking: ok...you said earlier that you were also moving on to looking after the boot loader for intrepid? [16:08] Yep. I'm getting familiar with the isolinux, grub and so forth. [16:09] Good, be glad to see what we can do with grub2 (if anything) for intrepid [16:09] cking: thanks [16:09] amitk: on to you... [16:09] OK. [16:10] been testing out some hardware for the ubuntu Mobile project [16:10] integrating drivers for them too [16:10] I hope to push out a preliminary Intrepid tree with all the sauce patches next week [16:10] amitk: for ume or kernel in general? [16:11] the intrepid tree that is [16:11] kernel in general - we will move the lpia out of the normal kernel tree though [16:11] as agreed at the kernel sprint [16:12] amitk: excellent...are you working on that tree in tandem, or will that come later? [16:12] the lpia tree [16:13] BenC: tandem. The lpia tree will follow the main kernel tree closely, only have different checkpoints for uploading than the kernel tree. [16:13] s/checkpoints/schedule [16:13] amitk: Are you removing most of the (unneeded) sauce patches for lpia? e.g. I wouldn't think it would need DSDT-from-initramfs loading [16:14] BenC: true, those don't need to be in the lpia tree. [16:14] amitk: ok, great...anything else of note? [16:15] that's it from me.. thanks [16:15] amitk: thanks [16:15] amitk: How will this affect my integration of moblin patches to the hardy-ume? [16:16] jay: it won't. Hardy tree will continue to be maintained as-is, with you and I doing special uploads to the mobile PPA [16:16] amitk:ok [16:17] Intrepid's new kernel is not yet chalked out in the current Ubuntu Mobile plans [16:17] Good thing about the planned separation is that moblin could potentially use an entirely different kernel version in intrepid than we are for mainline [16:18] IOW, it could use 2.6.25 instead of our planned 2.6.26, so it can remain at a stable ABI for much longer during the development cycle [16:18] but that's a discussion for UDS [16:18] BenC: very true. This will be discussed at UDS [16:18] Ok, moving on to bugs for hardy [16:19] The kernel team has discussed some basic guidelines for patches/fixes going into the kernel between now and release... [16:19] For starters, the current kernel in the archive is what is planned for beta, barring any major regressions showing up (which I see as unlikely) [16:19] BenC: Where? [16:20] mjg59: where what? [16:20] Where was it discussed? [16:20] mjg59: on our phone call just before this meeting...and I'm about to outline those guidelines now [16:20] Phone call? [16:20] Yes, we have a conference call once a week just before the IRC meeting [16:21] mostly to discuss NDA issues that can't be discussed here [16:21] Uh. [16:21] But also to discuss bug policies? [16:21] These policies aren't any different than what we've had in past releases [16:21] just noting them now to make sure everyone understands them [16:22] If you're defining the kernel team as the set of people employed by Canonical, I think you're missing the point [16:22] Just the bar for a patch getting in now after kernel freeze is very high...and that needs to be pointed out [16:23] mjg59: I misspoke...we didn't "define" these policies on the call, we simply reviewed the ones we already have in place [16:23] mjg59: we discussed how they were different than the normal policies during the heavy development cycle [16:23] IOW, we are in kernel freeze, and only have one more planned upload [16:23] No, the kernel team didn't. The subset of the kernel team involved in this phone call did. [16:24] I don't see it as a problem to let my employees know what these policies are, especially considering most of them are new [16:24] I also don't think I have to do it in public [16:24] especially since the same policies will be discussed in public [16:25] and especially since they haven't changed, they are just being reiterated at a time when they are pertinent [16:25] No, that's not the point I'm mkaing [16:25] I don't really see a valid point, to be honest [16:25] You're saying that the kernel team discussed this. That's only true if the kernel team is the set of people who work for Canonical. [16:26] Excuse me then, the Canonical Kernel Team discussed this [16:26] Which was not my understanding of how development worked. [16:26] and now I am discussed it with the Ubuntu Kernel Team [16:26] *discussing [16:26] Ok [16:26] mjg59: is that clarification better? [16:26] Yes [16:27] Good, so let's move on... [16:28] The basic points of our current bug policy is that we will mainly focus on bugs that prevent users from booting/installing Ubuntu [16:28] Bugs that fall into this category are mainly graphics and storage related, but generally covers networking as well [16:29] Other bugs will either be deferred to 8.04.1 point release, or for 8.10, depending on the bug [16:30] Exceptions to this can occur, but are not likely...basis for exceptions will be the estimated number of people affected by the bug, and the complexity of the fix (IOW, the trivial fixes with least chances of regression may be considered) [16:30] We only have one more _planned_ kernel upload, as per the kernel release schedule (linked to a google cal from KernelTeam wiki) [16:31] And just for clarification, these policies, and the kernel release schedule itself were discussed at prior UDS's with community members [16:32] Are there any questions concerning this policy? [16:33] No. [16:33] Great...so now I'll just see if anyone has other items they would like discussed at this point... [16:35] No takers? :) [16:35] Ok, thanks everyone [16:35] Meeting adjourned [16:35] thanks [16:35] ta [16:42] BenC: can I bug you for a couple of minutes? or should I rather wait till things settle down after beta? [16:44] alex_joni: depends on the nature of your bugging :) [16:45] asking for some pointers building a custom-flavoured kernel (along with headers, lum, lrm), and some other pointers on tracking a possible bug in make-kpkg [16:47] alex_joni: re: custom kernels/lum/lrm: Check wiki.ubuntu.com...we don't condone it though [16:47] alex_joni: re: kernel-package (make-kpkg), you're on your own, we don't use it or support it :) [16:48] alex_joni: best bet is to talk to the maintainer of that package [16:48] BenC: I started looking at the debian/rules way of building things [16:48] and I think the problem persists [16:48] alex_joni: that's preferred [16:48] basicly the generated headers deb contains a broken asm link (points to asm-i386, not asm-x86) [16:49] but it might be because of a bad incantation to debian/rules [16:50] re: wiki.ubuntu.com, I understand.. already read most of the relevant thigngs, but it's not quite as accurate as I hoped [16:50] re: custom flavour: can't help it, we're using ubuntu as a base for machine control, so we need an ADEOS/IPIPE patch in the kernel [16:51] alex_joni: Can't you use -rt for that? [16:51] abogani: not at the moment [16:51] -rt needs to get way better for that [16:52] atm we're using 5-10 usec interrupts, -rt is a couple magnitudes worse [16:52] -rt is fine for servo controlling motors with custom hardware, but not for the cheap parport control [16:52] abogani: however -rt is getting way better, so I hope one day we can fully switch over [17:45] .26 for ibex? === thegodfather is now known as fabbione [18:46] <_stijn_> hey === kylem_ is now known as kylem === asac_ is now known as asac === Traxer is now known as Traxer|on === Traxer|on is now known as Traxer [20:01] I want to build and distribute a custom kernel flavor (rtai) and be sure that I fulfill my GPL duties to distribute complete, corresponding source code. The page https://help.ubuntu.com/community/Kernel/Compile didn't answer my questions about how to build a linux-source package or a debian source package. What method should I use? [20:40] Is there any chance the one-line patch from bug #39414 could be applied? Without this patch, many people won't be able to use bluetooth headsets. [20:40] Launchpad bug 39414 in linux-source-2.6.15 "syslog is flooded with messages after connecting bluetooth usb dongle" [High,Fix released] https://launchpad.net/bugs/39414 [20:41] The patch disables eSCO, but that's a relatively minor loss compared to not being able to use your headset at all. === Traxer is now known as Traxer|on === Traxer|on is now known as Traxer [21:46] BenC__: right, I think there's a bug report about it [22:10] tjaalton: are you working on it? Seems important for beta [22:10] brb