[09:21] <cjwatson> could somebody please do linux and linux-ports uploads with Build-Conflicts: findutils (= 4.4.1-1ubuntu1), so that they're available when lamont starts work on the manual recovery? bug 373214
[09:21] <ubot3> Malone bug 373214 in linux "/usr/include/asm/* is not present in linux-libc-dev" [Critical,In progress] https://launchpad.net/bugs/373214
[09:26] <ramzai> hello all. Is this channel a right place to ask a question related to building & packaging a custom kernel (rather a newbie one)?
[09:29] <ramzai> I've compiled a current intrepid git for generic flavour (2.6.27-14.34), which resulted in two debs: linux-image-2.6.27-14-generic_2.6.27-14.34_i386.deb and linux-headers-2.6.27-14-generic_2.6.27-14.34_i386.deb. The latter one depends on linux-headers-2.6.27-14 package, how can I get one?
[09:41] <smb> ramzai, you have to build binary-headers if you do not build the complete binary-arch
[09:42] <ramzai> I'm following https://help.ubuntu.com/community/Kernel/Compile and compiling with CONCURRENCY_LEVEL=2 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic
[09:43] <ramzai> I need to add binary-headers, correct?
[09:44] <smb> ramzai, You would add a secound step with binary-headers instead of binary-generic. binary-arch would do all (but also -server, which you probably don't want)
[09:45] <ramzai> yes, I don't need -server. Thanks!
[09:51] <cjwatson> smb: don't suppose you could do a karmic upload? it just needs http://paste.ubuntu.com/166616/plain/ applied
[09:51] <smb> cjwatson, By the rights I certainly can do. Let me have a look at it
[09:52] <cjwatson> reasonably urgent as nearly all other builds are broken at the moment :)
[09:52] <smb> cjwatson, Is now reasonable :)
[09:52] <TheMuso> cjwatson: linux-ports going up now, give it half an hour or so for it to be uploaded
[10:25] <cjwatson> TheMuso: kewl, thanks. I'm not sure lamont is up yet anyway, I just want them to be in place when he is ...
[10:28] <cjwatson> findutils patch accepted upstream AFAICT, pending copyright assignment
[10:33] <TheMuso> good to hear
[10:36] <smb> cjwatson, The kernel upload just finished. It is test-compiling in parallel. So I will give another ping if that is successful and you wait until that before pulling the accept(-flush)-chain.
[10:37] <TheMuso> smb: its already on the buildds
[10:37] <TheMuso> smb: how recently have you updated the chroot you are using for the test build?
[10:37] <smb> TheMuso, Should be ok. I normally are a bit parnoid, but it passed the abi check on generic, so it should be fine
[10:38] <smb> TheMuso, Actually I am way too much back
[10:38] <smb> I do not have a karmic chroot yet
[10:38] <smb> Its in a Jaunty chroot
[10:38] <cjwatson> it would be a pain to stop it being automatically accepted on karmic, but it doesn't matter - we expect the automatic build on LP to fail, but lamont will take care of it manually
[10:39] <smb> cjwatson, Oh, well. Seems I am too much used to stable. Nothing is automatic there
[10:40] <cjwatson> so don't worry about the rather explosive failures
[10:40] <cjwatson> good to see that build-conflicts works anyway ;-)
[10:40] <smb> Heh, ok. :)
[10:59] <apw> linux-generic is what makes me keep my generic kernel up to date right?
[10:59] <apw> that being uninstalled would be pretty bad no?
[11:01] <amitk> umm, yes
[11:01] <amitk> it is the meta package
[11:02] <apw> thats what i thought ... somethign is bust out there me thinks
[11:06] <apw> seems having some packages not NEW'd to the archive leads to this ... not good
[11:55] <lamont> g'morning
[12:14] <rokr1> hello all
[12:15] <rokr1> i actually got problem regarding COMPIZ FUSION ... my question is, will it work fine in 2.5.30RC2 kernel??
[12:15] <rokr1> using UBUNTU 9.04 with 2.6.28-11
[12:16] <rokr1> any one??
[12:16] <amitk> rokr1: sounds like a userspace problem.
[12:16] <amitk> try #ubuntu for help
[12:16] <ogra> how is compiz related to the kernel ?
[12:17] <ogra> ogra@osiris:~$ modprobe compiz
[12:17] <ogra> FATAL: Module compiz not found.
[12:17] <ogra> dang ...
[12:17] <amitk> :-D
[12:17] <rokr1> because of the optimization in Intel driver mesa release 2.7 i think i will work fine in latest kernel
[12:17] <rokr1> dats y
[12:18] <ogra> if its about mesa, probably try #ubuntu-x then ...
[12:18] <amitk> rokr1: mesa is still userspace. There are some bugs about performance on intel graphics cards. Try search launchpad for them.
[12:18] <rokr1> ok wats the latest kernel which can b used with UBUNTU 9.04
[12:18] <ogra> 2.6.28-11
[12:19] <rokr1> is 2.6.30RC released
[12:19] <rokr1> ??
[12:19] <ogra> what would you think the RC means ? :)
[12:20] <amitk> rokr1: what ogra said. You can try mainline kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/, but we won't support them.
[12:20] <rokr1> release candidate
[12:20] <ogra> right ... 
[12:20] <rokr1> i know it ogra
[12:20] <ogra> canididate :)
[12:20] <rokr1> wat ever i am poor in englis so i accept ogra
[12:20] <rokr1> well nice meetin u ogra
[12:21] <ogra> :)
[12:21] <rokr1> thanks amitk i will try it
[12:24] <rokr1> i would like to know will there be upgrade kernel version to 2.6.29.2 in ubuntu 9.04??
[12:24] <rokr1> in future
[12:24] <rokr1> ?/
[12:24] <ogra> no
[12:24] <rokr1> why is that so??
[12:25] <ogra> stability
[12:25] <ogra> some bugfixes will be backported to the .28 kernel from .29 or .30 though
[12:26] <rokr1> i am not a geek so i dont know much infos regarding kernels!!;) so dont mind me
[12:26] <ogra> and indeed security fixes ... either will come to you via jaunty-updates or jaunty-security
[12:26] <rokr1> as i know from kernel.org it seems 2.6.29.2 is a stable release
[12:26] <maco> right, but if we change things all willy-nilly, it can make other parts break
[12:26] <ogra> but not tested in context with the rest of the distro
[12:27] <maco> if we keep the same version, we at least know what works & what doesn't then can fix some of the bugs to make that "what works" list increase while "what doesn't" decreases
[12:27] <rokr1> so i can expect it in 9.10 in future!!
[12:27] <maco> yes
[12:27] <ogra> if you change the full kernel you might need to change userspace and test that ... which we do, we call it karmic (9.10) :)
[12:28] <amitk> rokr1: 9.10 will get you a 2.6.30 or 2.6.31 kernel
[12:29] <rokr1> so if we add new kernel and check it in a userspace we need to apply it to all the core programs regarding devices, and other hardware oriented application am i correct ??
[12:30] <amitk> yes
[12:30] <maco> rokr1: for example, changes in the kernel may require rebuilding X or getting a newer X which could in turn require rebuilding large graphical libraries
[12:30] <maco> (someone correct me if that's not how changes to linux-drm work)
[12:31] <amitk> maco: that is correct
[12:31] <ogra> well, there are other dependency chains ... imagine the kernel changes, that induces changes to hal ... which in turn changes gnome-power-manager ... so you also have impact on gui tools in some cases
[12:32] <ogra> even though they dont interact *directly* with hardware or the kernel, the underlying layer might change 
[12:32] <rokr1> humh, Digital Right Management
[12:32] <rokr1> humh, Digital Rights Management
[12:32] <maco> no, the other drm
[12:32] <ogra> heh
[12:32] <amitk> Direct Rendering Management
[12:32] <maco> yeah that one
[12:32] <rokr1> thanks!! to inform me !!
[12:32] <amitk> s/Management/Manager
[12:33] <rokr1> i really dont know those abbre..
[12:33] <ogra> Mopper :)
[12:33] <amitk> heh
[12:33] <maco> heh, i forgot what it stood for, just that it's a "talk to the graphics card" thing
[12:34] <rokr1> to say is system freezing due to kernel
[12:34] <rokr1> ??
[12:34] <rokr1> because of wrong drivers??
[12:35] <rokr1> is wrongly programmed drivers
[12:35] <rokr1> ??
[12:35] <rokr1> correct me
[12:35] <rokr1> plz
[12:36] <rokr1> wats the difference between restricted, nd backport kernel modules
[12:36] <rokr1> ??
[12:39] <maco> rokr1: yes, bad drivers can be a cause of a system lockup. so can bad hardware.
[12:40] <rokr1> then i will have to use bad words to INTEL
[12:40] <maco> usually intel's pretty good, but not necessarily when their hardware is very very new
[12:40] <rokr1> i agree except the processor
[12:41] <rokr1> all the other hardware's are useless
[12:41] <maco> hmm? i meant if you get the newest intel wireless card, it may take 6 months or so for the driver to get up to speed
[12:41] <maco> oh, i only use intel hardware because the support is generally very good
[12:41] <maco> easier to get working than many other vendors
[12:41] <rokr1> i am using 3945 wifi card nd  GMA X3100 which both have lost support by intel
[12:42] <maco> but depending on how that hardware is integrated into your motherboard, you can hit snags
[12:42] <maco> no they haven't
[12:42] <maco> i'm using X3100 right now. enable Option "MigrationHeuristic" "greedy" in xorg.conf if your graphics are locking up. that's one thing i ran into
[12:43] <maco> and my other laptop uses 3945 wireless just fine. the one i'm on right now uses 4965 which was, admittedly, a pain in 8.04 and the early weeks of 8.10
[12:44] <maco> anyway, backports modules contain patches pulled from newer upstream kernels to fix hardware compatibility issues in the one that ubuntu ships
[12:44] <maco> restricted modules contains drivers that are not free/libre open source
[12:45] <maco> because not all hardware vendors are willing to release totally free drivers
[12:45] <rokr1> so is there any new backport for intel graphics available???
[12:46] <maco> try what i just said about that setting
[12:46] <maco> my experience with the X3100 is that it just needs to be using the settings it had in 8.10 to work well, and that means adding: Option "MigrationHeuristic" "greedy"
[12:47] <maco> to the video device part of your xorg.conf
[12:47] <maco> (granted, there are multiple chips out there that are called X3100, but it's worth a try)
[12:47] <laga> my x3100 is slow as hell with jaunty and kde 4. :(
[12:47] <maco> there's also the ~x-swat team on launchpad. they have newer graphics drivers for intel available and somewhere you can get the old drivers from 8.10 recompiled for 9.04
[12:47] <rokr1> ya in 8.10 it worked fine
[12:48] <rokr1> but using compiz slows the performance a bit but it worked
[12:49] <maco> laga: for me in that setup, it was locking up X a few times a day. greedy makes it stable *shrug* and i think that's a bug introduced like 2 weeks before release too
[12:49] <rokr1> had to use nidiswrapper to run 3945
[12:49] <maco> HUH?
[12:49] <rokr1> hate windows
[12:49] <maco> that doesnt make any sense at all
[12:49] <maco> X wasn't locking up on me, then i added greedy and it was still fine. then i did a clean install the day after release and is started getitng X lockups. put greedy back in, and it was stable again
[12:50] <maco> rokr1: 3945's driver is included by defalut
[12:50] <maco> it should've worked out of the box, even from the live cd
[12:50] <rokr1> but it wont work
[12:50] <maco> there's absolutely zero effort required in any ubuntu release at least back to 6.06 for that chip
[12:50] <rokr1> u mean iwl3945??
[12:51] <maco> yes
[12:51] <maco> it used to be ipw3945 and have somewhat better range....
[12:51] <rokr1> i tried it but it was waste of tine
[12:51] <maco> how so?
[12:51] <rokr1> but when i used ndiswrapper it worked out of box
[12:51] <maco> i dont understand
[12:51] <maco> what was a waste of time about iwl3945?
[12:52] <maco> why was there even time involved?
[12:52] <maco> it should've worked as soon as you booted
[12:52] <maco> if it didn't that's VERY weird
[12:53] <rokr1> using the iwl3945, & ipw3945 the device goes to an unstable state i have no control with the device 
[12:53] <maco> unstable state?
[12:54] <rokr1> the becon in device is constant it cannot connect to network!!
[12:54] <maco> if by "no control" you mean you cant do fun things with hacker tools....yeah, iwl3945 didn't have some of the modes ipw3945 had that made it nice for use with wireless cracking tools
[12:54] <rokr1> yes
[12:54] <rokr1> i love to use BT3 nd now BT4b
[12:54] <rokr1> with ipw3945
[12:55] <maco> er...*thinking* i'm about 99% sure i successfully used aircrack-ng with iwl3945 in december
[12:55] <rokr1> but it wont work in UBUNTU
[12:55] <rokr1> ok
[12:55] <rokr1> is kill switch prob solved??
[12:55] <maco> kill switch problem?
[12:55] <maco> i dont use my kill switch...so no idea
[12:56] <rokr1> yes to disable nd enable wifi device
[12:56] <maco> i also dont use that laptop unless this one's being repaired because it's HEAVY
[12:56] <rokr1> its availabe in most of the new laptops
[12:56] <maco> aye, i know what it is, i just dont use the kill switch
[12:56] <rokr1> yes dats y u dont know
[12:57] <maco> i know you can't trust the LED
[12:57] <maco> because there are many devices where you press the kill switch and the LED turns off. you press it again and the device powers back up but the LED stays off so it *looks* like the device is off
[13:08] <maco> rokr1: well, give that xorg.conf thing a shot, and maybe try linux-backports-modules for the wireless (maybe i had that installed when i got aircrack to work with iw3945)
[13:08] <maco> but both of those bits of hardware *should* be well-supported
[13:28] <eagles0513875> update-rc.d: warning: /etc/init.d/linux-restricted-modules-common missing LSB information
[13:48] <tjaalton> I'm trying to debug why the load on one jaunty server (eight-core amd64) periodically gets high, even though there are no processes taking cpu time, nor is the disk-io to blame (it has 64GB of RAM)
[13:50] <tjaalton> so how to find out what's going on? it happens ~every 15min but is not caused by cron
[13:50] <tjaalton> any ideas..
[13:51] <tjaalton> the load jumps to ~3-4, which is not that alarming, but when there are 6x more users than now..
[13:56] <smb> tjaalton, Is it only the load that gets up or any of the other stats?
[13:57] <tjaalton> smb: iotop/iftop both are fairly quiet, just like (h)top
[13:57] <tjaalton> I'm not sure where to look next
[13:59] <smb> Any virtualisation involved?
[13:59] <tjaalton> nope, real hw
[14:00] <smb> Hm, ok...
[14:00] <amitk> tjaalton: I/O or CPU?
[14:00] <tjaalton> amitk: the cpu usage seems to be <10% on all cores
[14:01] <tjaalton> so it's not that
[14:02] <amitk> tjaalton: try 'vmstat 1' to see if it is I/O. Then you could look at sar (sysstat) for more detailed debugging
[14:02] <tjaalton> amitk: cool, thanks
[14:04] <tjaalton> yeah, looks like sar should cut it
[14:04] <tjaalton> I'll investigate...
[14:25] <tjaalton> well, it's not I/O
[14:29] <smb> tjaalton, Which values go up? Only load? 
[14:32] <rokr1> hello all
[14:33] <rokr1> sorry for unexpected disconnection!! all especially maco
[14:33] <rokr1> had power cut !!
[14:36] <tjaalton> smb: yeah
[14:36] <amitk> weird
[14:37] <smb> tjaalton, So nothing seen in syscalls, wait, et all. Hard to tell probably, does it "feel" loaded
[14:39] <tjaalton> smb: well, no. it has plenty of power.. it's just distracting to see it on the graph :)
[14:39] <amitk> tjaalton: how long does the load last?
[14:40] <smb> tjaalton, Yeah, as said, hard to tell on an 8core. I wonder whether just the load number goes nuts
[14:41] <amitk> it _could_ be a bug in load calculations. 8-core machines haven't exactly been popular desktops until a few months ago :)
[14:41] <tjaalton> amitk: it lasts a couple of minutes, enough to keep the long time average above 0.5
[14:41] <smb> Hm, what was the definition of that? The number of processes in the run queue or something like that...
[14:41] <tjaalton> this is a blade server
[14:42] <tjaalton> for ssh shell sessions
[14:42] <amitk> tjaalton: so every 15min for 2mins?
[14:42] <tjaalton> amitk: yeah, something like that
[14:43] <amitk> tjaalton: can you ship me one? I'll fix it ;)
[14:43] <tjaalton> amitk: you'd need the HP blade frame too :)
[14:43] <tjaalton> or what's it called
[14:43] <amitk> hehe... just kidding
[14:43] <smb> tjaalton, is the blade 1U?
[14:43] <tjaalton> smb: yes
[14:43] <smb> amitk, So you ont want it
[14:44] <amitk> tjaalton: try latencytop
[14:44] <amitk> smb: no, not a 1U. I just managed to get rid of the one I had
[14:44] <smb> amitk, yeah, me too
[14:44] <smb> Not very office friendly
[14:45] <amitk> not very head friendly
[14:45] <tjaalton> it's not rack-wide either, so probably not 1U.. there are nine of them besides one another, in an upright position
[14:46] <tjaalton> yeah, the frame isn't that quiet :)
[14:46] <tjaalton> HP BL460c is the blade model
[14:47] <amitk> tjaalton: see if latencytop shows something. I wonder if it is something like kernel IPI (interrupt rescheduling) causing bouncing
[14:47] <amitk> tjaalton: powertop too
[14:48] <tjaalton> (it's replacing an old alphaserver ES40, 4*EV67, which barely ever get's over 0.5 load with ~600 users)
[14:48] <tjaalton> cool, installed both
[14:49] <tjaalton> whoa
[14:49] <tjaalton> Cause                                                Maximum     Percentage
[14:49] <tjaalton> sys_rt_sigsuspend system_call_fastpath            18446744073334896.0 msec        -862
[14:49] <tjaalton> bingo
[14:50] <tjaalton> could be mpath-related?
[14:52] <tjaalton> hmm, powertop suggests enabling usb autosuspend
[14:52] <mistersparks> hi all, I am currently looking for literature/documentation on the internet on the work done on the ubuntu kernel
[14:52] <mistersparks> I am specifically looking for info on how the stock kernel (upstream) is different from the final ubuntu kernel
[14:52] <amitk> tjaalton: lol
[14:52] <mistersparks> anyone that can point me in the right direction ?
[14:53] <tjaalton> amitk: http://pastebin.com/m4098cd96
[14:53] <amitk> mistersparks: https://wiki.ubuntu.com/KernelTeam
[14:53] <mistersparks> amitk thats the page that brought me here
[14:53] <mistersparks> which isnt what im looking for
[14:54] <mistersparks> amitk, oh just read your a kernel engineer , sweet
[14:54] <mistersparks> :D
[14:54] <amitk> tjaalton: let it run over the 15 minute period (to capture the load)
[14:55] <tjaalton> amitk: yeah, should happen within 5min
[14:56] <mistersparks> my final goal is to build a kernel that is more "lighter" than the default
[14:56] <mistersparks> I want it to match my hardware configuration as per lspci
[14:56] <amitk> mistersparks: then you will have to custom compile it
[14:56] <mistersparks> im getting the git tree clone as we speak
[14:57] <mistersparks> and im gonna follow the wiki doc on it
[14:57] <mistersparks> BUT
[14:57] <amitk> mistersparks: though a lot of the stuff is modules these days, so I am unsure of the net gain
[14:57] <mistersparks> is there a way to identify which module corresponds to my entries in lspci automatically ?
[14:59] <amitk> mistersparks: in most cases the names are self-explanatory
[14:59] <mistersparks> ,man I hope i dont screw this up
[14:59] <mistersparks> :)
[15:00] <mistersparks> theoretically would an ubuntu kernel package install on debian ?
[15:00] <amitk> just don't erase the default kernel, so you always have a backup kernel to boot into
[15:00] <amitk> mistersparks: yes, I know several people that use it
[15:00] <mistersparks> they use it for the hw support ?
[15:00] <jpoirier_> mistersparks: you might try, http://kroah.com/lkn and see chapter 8
[15:01] <mistersparks> why do debian ppl use the ubu kernel ? for hw supp?
[15:01] <amitk> mistersparks: sometimes..
[15:02] <mistersparks> I just cant think of another reason to use the ubuntu kernel on debian except hw support and maybe a more desktop-friendly kernel
[15:02] <amitk> and the stable kernel is a bit old IIRC
[15:02] <mistersparks> because essentially my problem is indeed hw support
[15:02] <amitk> I don't really keep track of the debian kernel
[15:03] <mistersparks> btw chapter 8 is exactly what I was looking for
[15:03] <mistersparks> so I download the ubuntu kernel and simply use dpkg to install it ?
[15:03] <jpoirier_> or rather, try chapter 7
[15:03] <mistersparks> Or does it need any special treatment ?
[15:04] <mistersparks> this book is top notch stuff btw
[15:05] <jpoirier_> great, send a check to the author
[15:05] <mistersparks> i wouldnt mind donating :)
[15:05] <mistersparks> im not the cheap mofo that just wants a solution to his problem
[15:07] <mistersparks> so how do I go about getting the ubuntu kernel in debian ? dpkg and thats it ?
[15:09] <amitk> mistersparks: basically, yes. But I've never done it
[15:18] <tjaalton> amitk: nothing new in powertop..
[15:19] <tjaalton> acpi isn't too useful on the machine anyway
[15:19] <amitk> and latencytop?
[15:19] <tjaalton> nothing there either
[15:30] <cjwatson> lpia build verified happier following the findutils fix
[18:31] <rokr1> clear
[18:31] <rokr1> oops working on terminal console made me to type that Apologies!!