[12:33] <zul_> yay xen has made it into linus git
[12:50] <BenC> zul_: just the paravirt bits, right?
[12:52] <zul_> yep
[12:52] <BenC> better than nothing
[12:53] <zul_> yep now we get to see how other distros will handle it
[12:59] <BenC> and get to let it simmer one release before we take it in gutsy+1
[12:59] <zul_> yep
[01:39] <IntuitiveNipple> Is there any updated Kernel-Build docs aside from the Kernel-Team Wiki, I'm not having much luck building the git ubuntu-feisty tree according to the instructions for Feisty  - "fakeroot debian/rules binary-debs" reports 'no rule to make target' trying to debug a suspend/resume issue on a fresh install of Feisty ?
[01:39] <BenC> IntuitiveNipple: you did checkout the ubuntu-feisty.git from kernel.ubuntu.com, right?
[01:40] <IntuitiveNipple> Yes Ben, and Gutsy too, to compare the differing build methods. So far, no joy. Been trying to find the 'binary-debs' target but not found it. Found 'binary' okay though :)
[01:41] <BenC> just run binary then
[01:41] <IntuitiveNipple> Whats the difference between them? I kind of assumed it was something significant :)
[01:42] <BenC> more stuff gets built with binary
[01:42] <BenC> better more than less
[01:43] <IntuitiveNipple> ok... all I needed to do was enable CONFIG_USB_DEBUG to monitor any stray events during suspend/resume... turned into an 8-hour fight with the build system... strange really, prior to adopting this I was using the 'old make-kpkg' system and apt-get or kernel.org sources with no problems.
[01:45] <BenC> IntuitiveNipple: you could just do apt-get install linux-source-2.6.20, then use the tarball in /usr/src with make-kpkg
[01:45] <BenC> use /boot/config-2.6.20-*-generic
[01:45] <IntuitiveNipple> yeah, I had been doing that... but I thought it was time to catch up with you guys! I did all the debugging/fixing of the intel hda sound bug that way
[01:46] <crimsun> which HDA bug?
[01:47] <BenC> crimsun: hey
[01:47] <crimsun> BenC: 'lo
[01:47] <IntuitiveNipple> dma buffer looping/crackling on resume 
[01:47] <crimsun> which HDA codec?
[01:47] <IntuitiveNipple> intel
[01:47] <crimsun> no, codec.
[01:47] <crimsun> Analog Devices?  Realtek?  Conexant?  Sigmatel?
[01:48] <BenC> crimsun: could I get you to pass the admin flag on to kyle for ubuntu-audio?
[01:48] <IntuitiveNipple> Sigmatel
[01:48] <crimsun> TheMuso: please see above
[01:48] <crimsun> BenC: I made TheMuso the admin of that group and just pinged him
[01:49] <IntuitiveNipple> But, the bug *isn't* in the snd module, its in the kernel itself, but I put a work around in the Fiesty sn-hda-intel code because the kernel bug doesn't affect 2.6.22
[01:49] <crimsun> BenC: he'll need to make that change; I'm no longer a member of that team.  The wiki page is easily edited, though.
[01:49] <IntuitiveNipple> See the last few comments to https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/100114
[01:50] <crimsun> IntuitiveNipple: err, that has nothing to do with snd.ko
[01:50] <crimsun> that's all rolled into snd-hda-intel.ko 
[01:51] <IntuitiveNipple> I didn't mention snd.ko 
[01:51] <BenC> crimsun: When's your last day out in the public?
[01:51] <crimsun> IntuitiveNipple: ok, so you meant something different by "the bug *isn't* in the snd module"
[01:51] <crimsun> IntuitiveNipple: I interpret that to mean snd.ko, because you explicitly use the string "snd"
[01:52] <IntuitiveNipple> 'snd' module as in the snd-hda-intel module I had just mentioned
[01:52] <crimsun> BenC: between Sept and Oct; depends on $boss
[01:52] <crimsun> IntuitiveNipple: sure
[01:53] <IntuitiveNipple> anyhow, it was an issue with the botting of the 2nd CPU/core overwriting random PCI config reg space of the HDA device's TCSEL register, so we check its value on resume and correct it if its bad
[01:53] <TheMuso> crimsun: Will do.
[01:53] <BenC> crimsun: you will be missed :)
[01:53] <zul> yeah sound is going to suck :)
[01:53] <crimsun> IntuitiveNipple: did you send it upstream to alsa-devel@ ?  I haven't seen it.
[01:53] <IntuitiveNipple> botting/booting!
[01:53] <IntuitiveNipple> crimsum... no, didn't see the point seeing as the issue has gone from 2.6.22 (so far!)
[01:54] <crimsun> IntuitiveNipple: ok
[01:54] <TheMuso> Whats Kyle's LP name?
[01:54] <zul> crap he is up
[01:54] <crimsun> TheMuso: kylem
[01:54] <TheMuso> crimsun: Thanks.
[01:54] <kylem> no. kyle.
[01:54] <crimsun> err
[01:54] <IntuitiveNipple> There's nothing wrong with snd-hda-intel, just the kernel non-boot CPU resume being late, after PCI devices had been resumed
[01:54] <crimsun> yeah, for some reason muscle memory defeated me
[01:54] <crimsun> (I really did type kyle)
[01:55] <crimsun> TheMuso: thanks.
[01:55] <TheMuso> crimsun: np
[02:00] <bdmurray> Are MacBook Pros Intel based?
[02:00] <kylem> yes.
[02:00] <bdmurray> cool, thanks
[02:01] <TheMuso> kylem: Done.
[02:02] <kylem> ok.
[02:26] <zul> argh he doesnt sleep
[03:56] <Philip5> i have a little question about the debian-rules that the linux-source-2.6.22_2.6.22-8.18 in gusty use. i would like to make a custom kernel using the debian rules. i have changed the flavours variable in i386.mk to custom, changed and setup a custom.config in debian/config/i386 and everything seam to build ok but after modules and stuff got built it breaks with a error like no rule to make custom
[03:56] <Philip5> looks like it needs to be set some rule or variable for a make file for the custom too
[03:57] <Philip5> does this make any sense?
[03:58] <Philip5> have i missed to define custom somewhere?
[09:05] <kraut> moin
[10:57] <amitk_> lamont: I have now pushed all the changes into gutsy except for ABI since that will be done as part of the kernel release
[10:58] <abogani> What is the best place for set schedutils into Recommends field for rt kernel flavour? linux-rt meta-package or linux-image-2.6.22-8-rt ?
[11:00] <amitk_> I will defer that debian-specific question to cjwatson or benc
[11:10] <abogani> amitk_: Could add -rt to gutsy-meta? Or prefer my diff of the debian/control.d/i386? :-)
[11:11] <amitk_> abogani: I would prefer if you sent a properly formatted patch to kernel-team@lists.ubuntu.com
[11:14] <abogani> amitk_: gutsy-meta.git don't have debian/commit-templates/patch git template. A simple diff is right?
[11:16] <amitk_> abogani: simple diff with a sign-off line is good enough
[11:16] <abogani> amitk_: Ok, Thanks.
[12:04] <abogani> amitk_: How can test rt meta packages building?
[01:17] <abogani> BenC: If i build rt kernel...
[01:17] <abogani> grep "rt[1-9] " debian/binary-custom.d/rt/vars
[01:17] <abogani> target="Ingo Molnar's full real time preemption patch (2.6.22.1-rt4)"
[01:18] <abogani> dpkg -I ../linux-image-2.6.22-8-rt_2.6.22-8.19_i386.deb | grep "rt[1-9] "
[01:18] <abogani> Ingo Molnar's full real time preemption patch (2.6.22.1-rt2)
[01:18] <abogani> :-???
[01:19] <abogani> I already checked debian/binary-custom.d/rt/diff and it is a true rt4 rt patch for Ubuntu..
[02:07] <BenC> abogani: fakeroot debian/rules clean
[02:07] <BenC> abogani: then rebuild
[02:10] <abogani> BenC: I already do this two times... i'm cloning git repo again.
[02:10] <abogani> BenC: Exactly: fakeroot debian/rules clean && make clean && make mrproper && git-checkout -f
[02:10] <BenC> there's your problem
[02:11] <BenC> run "fakeroot debian/rules clean" after git-checkout -f too
[02:11] <BenC> the forced check out overwrites the updated control files
[02:16] <IntuitiveNipple> BenC: sorry to be a bother (what you've just suggested may help me too) but the build of Feisty from git has now failed both using the 'new' and 'old' ways and I'm wondering if you'd take a quick look at the short log-file I've just captured from a ' fakeroot make-kpkg...' build and tell me if it is me or something in the git that could be the root of my issues?
[02:16] <IntuitiveNipple> ( log is at http://paste.ubuntu-nl.org/30429/)
[02:18] <BenC> IntuitiveNipple: I told you that you could only use the make-kpkg method by installing linux-source-2.6.22 package and building from the tarball, not using our git tree
[02:18] <BenC> IntuitiveNipple: if you want to build from a git tree, use stock linux-2.6 tree from linus
[02:19] <BenC> otherwise, you'll need to use the the right "fakeroot debian/rules binary-debs flavours=generic"
[02:19] <IntuitiveNipple> BenC: Oh, I misunderstood then, sorry, I think the various instructions on the Wiki confused me
[02:21] <IntuitiveNipple> BenC: yeah, that was the one I was trying from a virgin install from Feisty git and getting the unknown target 'binary-debs' report... I think I'll install from scratch and try again :)
[03:08] <IntuitiveNipple> BenC: Thanks... a "git checkout -f", edit of debian/config/i386/config, "debian/rules updateconfigs" and now "fakeroot debian/rules binary-debs" is building - somehow I must have managed to mess up the checked-out version between checkout and build attempt. (I've also built the latest git 1.5.2 from source rather than using the 1.4.x from repo)
[03:09] <BenC> IntuitiveNipple: if you ran make mrproper or anything like that, it'll break things most likely
[03:10] <IntuitiveNipple> BenC: I must have, although, to my knowledge, the only kernel builds I'd been doing were in a separate install of the linux-source-2.6.20 I was using to build the snd-hda-intel and alsa core modules for debugging another issue
[03:10] <IntuitiveNipple> Anyhow... I'm happy now... I can get back to focusing on debugging these suspend/resume issues!
[03:33] <lamont> abogani: util-linux 2.13 will deliver schedutils as part of essential... no need to recommend it.
[03:37] <lamont> amitk_: thanks.  I'm still dealing with the minor issue that hppa64 kernels don't boot.  If that causes an abi bump when I fix it, we'll just smash it into existance anyway, since it's clear that no one could possibly be running hppa64 and upgrading to the working one.
[03:38] <amitk_> lamont: sounds good
[03:47] <abogani> lamont: Good, thanks.
[03:52] <BenC> lamont: we may want to force a rebuild for lum at least in that case, because the ones built against previous might not load against the new kernel
[03:55] <lamont> BenC: if I change the hppa32 config in an abi-bumping manner, I'd want the abi change.  current state of hppa64 is that it's a lie: doesn't boot, so there is no abi to break
[03:56] <BenC> lamont: but lum would be built against the non-booting kernel, and if the ABI really changed, then those modules wont load against the new kernel that does boot
[03:56] <lamont> oh.  got it.
[03:57] <lamont> so rebuild lum, rather than rebuilding the kernel for lum. :)  EPARSE
[03:57] <BenC> :)
[03:58] <BenC> not that there's much in lum that hppa would use, unless people are using unionfs/squashfs in some custom way
[04:00] <lamont>  /build/buildd/linux-ubuntu-modules-2.6.22-2.6.22/debian/build/build-hppa32/media/ov511/ov511.c:269: error: 'VIDEO_PALETTE_GREY' undeclared here (not in a function)
[04:00] <lamont> there's not anything in lum that people will use until we fix it. :-
[04:00] <lamont> )
[04:00] <lamont> is lum in git or somesuch somewhere?
[04:03] <amitk_> git://git.kernel.org/ubuntu/ubuntu-gutsy-lum.git
[04:03] <amitk_> oops... that should be kernel.ubuntu.com
[04:46] <abogani> BenC: with a fresh Gutsy git cloned repo problem still persist... :-( 
[04:47] <Philip5> hi again guys.... 
[04:47] <Philip5> i think i paste my question again and hope someone is alive :)
[04:48] <Philip5>  i have a little question about the debian-rules that the linux-source-2.6.22_2.6.22-8.18 in gusty use. i would like to make a custom kernel using the debian rules. i have changed the flavours variable in i386.mk to custom, changed and setup a custom.config in debian/config/i386 and everything seam to build ok but after modules and stuff got built it breaks with a error like no rule to make custom
[04:48] <Philip5> looks like it needs to be set some rule or variable for a make file for the custom too
[04:48] <Philip5> have i missed to define custom somewhere?
[09:22] <lamont> amitk_: I'm about 60 seconds from committing a works-but-sucks config for hppa64.  taht'd be nice for -8.19
[09:22] <amitk_> lamont: i guess it depends on how bad it sucks ;)
[09:23] <lamont> I turned off SMP
[09:24] <amitk_> it recreates the config into base and extras for all flavours of a particular arch
[09:24] <amitk_> s/recreates/splits
[09:24] <lamont> so what should I feed it?
[09:26] <amitk_> you shouldn't have to. Instead do the following:
[09:26] <lamont> http://people.ubuntu.com/~lamont/config.fullhppa64 is the full .config for hppa64....
[09:26] <amitk_> cd debian/config/<arch>; for cfg in config.* do;
[09:26] <lamont> so if it's quick, I can do it now.
[09:27] <amitk_> cat config >> $cfg
[09:27] <amitk_> done
[09:27] <amitk_> rm config; debian/rules updateconfigs <--- this will split out the configs for you
[09:29] <lamont> must run.  I'll do that when I'm back online
[10:20] <bdmurray> So I've tagged a fair number of bugs as kernel-oops
[10:53] <BenC> bdmurray: cool
[10:54] <bdmurray> Some are filed against ndiswrapper but those are easily ignored.
[10:54] <BenC> fyi, ndiswrapper bugs in gutsy should be against lum-2.6.22
[10:55] <BenC> hehe
[10:57] <bdmurray> but pre-gutsy they should be against ndiswrapper?
[10:58] <cno1> need help patching the linux kernel... im following this guide, and i do not understand part 3... somebody please help! :-X
[10:58] <cno1> the guide is here: http://www.pabr.org/sixlinux/sixlinux.en.html
[11:00] <BenC> cno1: this isn't a general kernel help channel
[11:00] <BenC> cno1: try #kernelnewbies
[11:00] <cno1> thanx
[11:01] <BenC> cno1: feisty on ps3 should work for bluetooth ps3 controllers
[11:01] <BenC> save you a lot of patching
[11:02] <cno1> thanx again...
[12:02] <zul> BenC: ping