[07:58] ddebs.u.c doesn't have l-i-debug for 2.6.28-11, is there a way to build it myself? [07:59] (I'd like to use oprofile to find out what causes the extra load every ~15min) [09:16] vertix: for developers: check out http://cppgoldmine.uuuq.com programmer's goldmine library to find the answers on any of your issues or problems in C++ [09:19] btw, no marketing or any other adds on those collections. it is totally clean site containing only articles in 100+ categories, nothing else === Lure_ is now known as Lure === thunderstruck is now known as gnomefreak [16:56] hi, still no aufs2 in there yet? [16:56] every other live cd is created via aufs(2) nowadays... [16:58] Kano, heh, nope as strangly we have not yet had the UDS discussions on this matter, as they occur in a week [16:59] and you expect another result, do you [17:01] Kano: probably not, but who knows :) [17:01] thats basically impossible [17:03] Kano: but you welcome to attend the session at UDS where we discuss the issue [17:03] you can even dial in [17:04] the thing is, when you add aufs2 in the kernel + squashfs 4 userspace then your tools would already create working test images === jjohansen is now known as jj_lunch [20:53] how can I build just the debug debs from the kernel source? been trying to do that, since there's no ddeb for 2.6.28-11 [20:54] tjaalton: you pretty much have to build the whole damn thing in order to get the debug debs [20:56] rtg: right, so changing 0-common-vars.mk so that it doesn't skip ddeb's should be enough? [20:56] and then debuild -b? [20:56] tjaalton: you could just 'sudo mkdir /CurrentlyBuilding' as well [20:57] heh, ok [20:57] then 'debuild -b' [20:57] either way should work [20:58] ok, let's see [20:59] rtg: I think /CurrentlyBuilding is just a file, not a dir [20:59] but probably will still work [20:59] BenC: I think it can be either, make just looks at the wildcard, doesn't it? [21:00] rtg: yeah, I think it's just an existence test [21:03] rtg: are then good pointers on the kernel team's wiki pages for debugging crashes / restarts? my machine (mbpro3 / amd64 ) reboots an awful lot after updating to jaunty. [21:03] s/then/there/ [21:04] awe: cold boots with no warning? [21:04] yea [21:04] usually re-sizing windows, but not always [21:04] those are tough. [21:04] awe: i915 ? [21:04] nvida [21:05] geforce 8600M GT [21:05] there is a section on debugging in https://wiki.ubuntu.com/KernelTeam/KnowledgeBase [21:06] all i could find was the suspend/resume debugging page, but i'll look again [21:06] awe: using nvidia proprietary driver, or open source one? [21:06] prop [21:07] awe: --> screwed [21:07] awe: best bet is to see if nvidia can help...I'd try switching to open source driver for a bit to see if it still happens though [21:07] well, it's not like i wasn't told "it's recommended". ;) [21:07] i'll switch back and see how that works... [21:08] awe: I've had to switch back to 2d before. the 3d driver was flickering and getting real annoying. [21:09] alright, i'll give it a whirl [21:09] hmm, so my kernel (karmic) spends most of the time in read_hpet [21:09] rtg: It's definitely a file, not a directory. [21:09] infinity: the rule is 'ifeq ($(wildcard /CurrentlyBuilding),)' [21:10] rtg: Yeah, should work for anything, then. [21:10] rtg: Just pointing out that it's a file, should you ever do something with it in shell (say -f or -d) === bradf is now known as bradf__afk