[00:07] soren: It's a function of your hardware. Some is accurate, some isn't. 10W sounds entirely plausible for an idle laptop (I can get mine to 8W with the screen on...) [00:36] mjg59: Cool. Thanks. [00:44] soren: It's difficult to accurate measure, too. Several systems will (at the firmware level) enable deeper power saving states on battery, so you can't compare the results with an external power meter. [00:49] Well, the thing is... I stumbled upon some numbers about the power consumption of NSLU2's, and I came to thinking about the usefulness/wattage ratio of it compared to my laptop... I bought the NSLU2 before powertop came around, so I didn't really have any idea how much power a laptop used. [00:50] I guess I just expected it to use enough less power to justify the lack of computing power, but now I'm not so sure. [00:53] Is that just the NSLU2, or is that with a disk as well? [00:54] Bear in mind that the NSLU2 will probably top out at around 6W, while the laptop will easily draw another 10W at load [01:20] mjg59: That was with a disk as well, allegedly. [01:20] soren: 3.5" disks are going to draw much more power than 2.5" ones [01:20] True. The 5W was indeed with a laptop disk. [01:21] That's probably one of the larger differences [01:21] But once you're above 2W, there's much less incentive to be low power [01:21] It's going to be plugged into AC the whole time, so... [01:22] About them laptop using more power under load: That's perfectly alright. It'll be idle 95% of the time. [01:22] Yeah [01:23] Old laptops are often better than high-end embedded hardware [01:23] From a PM point of view, at least [01:23] Oh, really? That's a very interesting data point. I have a few old Fujity Lifebooks collecting dust on a shelf. [01:24] Fujity means Fujitsu. [01:24] Heh [01:24] At least a 2:30 AM. [01:24] Gah.. [01:24] At least *at* 2:30 AM. [01:25] Those things even have a touch screen. They're begging to be put to some sort of use somewhere. So many projects, so little time :( === macd_ is now known as macd === asac_ is now known as asac === lamont` is now known as lamont === pwnguin_ is now known as pwnguin === asac__ is now known as asac [09:44] hi! i'd like to know wether and when bug #199934 will be fixed in 8.04. a working patch is already attached, and i think the icp vortex support is still critical for many people running ubuntu on servers. at least it is for us (a german isp), as we're running all our internal and quite a lot of customer machines on ubuntu (currently 6.06 but would prefer to switch to 8.04 somewhen) [09:47] i wouldn't hold my breath... [09:50] nightwish: look at bug 65631, which is a somewhat similar case, and see how long did it take to get it fixed, despite the trivial patch being attached since the begin. [09:54] :o/ [09:55] nightwish: am I right to assume the patch mentioned in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/199934/comments/4 fixes this issue? [09:59] cking: i used the diff attached to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/199934/comments/8 to patch the ubuntu sources, this one is working fine [10:00] the other one is only a fix for the scsi scan, which was a problem of 2.6.24.2 vanilla [10:00] ah no sorry i'm wrong [10:00] sec. [10:01] nightwish: Not sure why the bug has not been looked at. [10:04] ok i checked both the one in comment 4 and in comment 8. the latter includes more code changes, but as i am not a developer i can't say if that's relevant for the fix. i just know that the diff in comment 8 definately works [10:05] nightwish: OK. - I will see what I can do to get this patch in - I will probably ask you to do some testing before it's accepted though. [10:07] it may need some thought to why it this patch is required and what it's trying to do though. [10:09] cking: ok. i've subscribed to the bug, so if you need my help, feel free to contact me (guido nickels) at any time. [10:10] nightwish: Thanks. I will see what I can do. === asac_ is now known as asac === emgent_ is now known as emgent [15:57] BenC: who is going to do maintenance of the intrepid-ports tree - stuff like rebasing, prepping for uploads, uploading, etc. [15:58] amitk: whoever cares about the ports [15:59] amitk: so far, we've only had interest from a ps3 guy (and he has an account on zinc now) [15:59] BenC: so there is no explicit assumption that the ports tree will be rebased on top of the Ubuntu tree? [16:00] amitk: there's an explicit exception that it will never be rebased on our main tree :) [16:00] I am trying to figure out the best way to establish a mobile tree... [16:02] BenC: ah. So that is not the example I want to follow for the lpia tree. I want a way to keep in sync with the Ubuntu tree but still have ability to do separate uploads when needed. [16:02] BenC: any thoughts? [16:04] amitk: sounds like you want what we planned for the binary-custom flavors [16:04] amitk: basically like xen was in edgy...a package that build-dep'd on linux-source, applied patches and built [16:06] BenC: there is a desire to 'apply' the patches to the git tree rather than have them as a stack of patches applied at build time [16:07] amitk: then the other alternative is a separate source package/git-tree that we will eventually merge back into our main tree [16:07] Then you can rebase on the main tree whenever you want, and upload whenever you want [16:08] So sort of like linux-ports but cloned from the main tree instead of being it's own unique tree [16:09] BenC: true. The only problem being that this tree would contain patches to disable flavours in the main tree (the debian/ dir) and the debian dir will constantly change, making it impossible to rebase. It would be like generating a new patch everytime. [16:09] this tree = lpia tree [16:11] amitk: yeah, it wouldn't be pretty [16:37] BenC: is it possible to have an alternate debian directory inside a package? [16:37] so I can let debian/ from the main tree be and create a debian2/ for all lpia stuff... or am I on crack? [16:38] amitk: git-mv debian debian2 [16:38] amitk: then rebasing will work === mkrufky is now known as mkrufky-lunch === mkrufky-lunch is now known as mkrufky [19:06] hello, i need a favour [19:07] can someone running ubuntu amd64 paste the default kernel config to some pastebin? [19:07] i'd like to compile ubuntu's kernel on another distro [19:08] mikkoc: on YOUR ubuntu box, take a look at /boot/config-`uname -r` [19:08] mkrufky: i dont have an ubuntu box [19:09] nor a live cd [19:10] it doesnt take much time to "cat .config | nopaste" :) [19:10] so, im logged on to an i386 right now, and i have an lpia next to me for testing [19:11] or as an alternative, is there any place where i can find it on the web? [19:11] i recommend you download the livecd and boot it [19:11] btw, im not an ubuntu maintainer -- im a user just like you [19:11] so my answers do not reflect ubuntu as a whole [19:11] there is probably a place to find that info, but i dont know [19:12] the easier answer is to download the cd and find out yourself... unless somebody else has an answer [19:12] im sorry if that isnt helpful enough -- i tried :-/ [19:12] np i appreciate it [19:12] :-) [19:21] mikkoc, If you have the ubuntu sources from git, look at debian/config/amd64/config{,.generic} [19:22] where do i find that? [19:22] mikkoc, you got the kernel sources from ubuntu? [19:22] smb: nope [19:22] http://kernel.ubuntu.com [19:23] just surf gitweb [19:23] you'll find the answer there [19:24] mikkoc, thought you wanted to compile ubuntu's kernel. but mkrufky is right. Either with gitweb or a complete git clone. [19:25] mikkoc, you need to paste together config and config.generic from the debian/config/amd64 directory [19:29] thx guys === mikkoc_ is now known as mikkoc === mkrufky is now known as mkrufky-away === mkrufky-away is now known as mkrufky