[02:20] <zeroprog> hey guys im havin a little trouble learning make files http://codepad.org/Uqn2MCyY....my driver source is in /home/name/Desktop/misc-drivers
[02:20] <zeroprog> http://codepad.org/Uqn2MCyY sorry (...)
[02:58] <zeroprog> now i keep getting invalid format for hello.ko
[08:46] <btQuark> hello everyone
[08:49] <btQuark> i've just tried this one successfully - after quite some time http://www.jan-steinhoff.de/linux/synaptics-usb.html what about bringing that into the kernel -the author obviously at it
[09:35] <Ng> how would I want to go about interpreting the battery consumption part of the checkbox suspend tests? I suppose I should really only use it to compare against results from different kernels on the same machine?
[10:00] <apw> Ng, yeah its a very subjective measure
[10:01] <apw> my feeling is it should be considered only as an indication of maximum suspend time, and if its less than a day or two its fail
[10:01] <apw> before some fixes i had a like 8 hour suspend time, which was definatly wrong
[10:03] <Ng> bah, that means I need to put jaunty back on the machine to get a baseline to support my gut feeling that suspend time has nosedived ;(
[10:03] <Ng> I also need to file a bug somewhere, some of the automated resumes didn't... resume. The LEDs changed, but I had to poke the power button
[13:14]  * popey filed bug 387272 but isn't sure it's a kernel bug or a desktop bug, feedback welcome
[13:14] <ubot3> Malone bug 387272 in linux "[karmic] long boot time on eee 900" [Undecided,New] https://launchpad.net/bugs/387272
[13:22] <rtg> cjwatson: do you have a cross compile environment for karmic ARM? Your patch series for udeb firmware isn't quite right for ARM (and probably other CPU arches without firmware)
[13:22] <cjwatson> rtg: nope
[13:22] <cjwatson> rtg: what's wrong with it?
[13:23] <rtg> cjwatson: it tries to copy a firmware directory that doesn't exist. I'll see if I can fix it later today
[13:23] <cjwatson> is it a bug in linux/debian/rules* or in kernel-wedge/commands/copy-firmware?
[13:24] <cjwatson>         cp debian/d-i/firmware/* $(builddir)/firmware/$(arch)/
[13:24] <rtg> cjwatson: linux/debian/rules
[13:24] <cjwatson> oh, is it that?
[13:24] <rtg> cjwatson: I think so, it was last Friday that I was messing with it
[13:24] <cjwatson> no, that can't be right, that directory does exist
[13:24] <cjwatson> if you can show me the error message I'll be happy to fix it
[13:25] <rtg> cjwatson: I'll get to it later today.
[13:25] <cjwatson> ok
[15:27] <apw> cjwatson, could there be no files in there though?
[15:27] <apw> then it could try and copy a file called '*'
[15:28] <apw> maybe some incantation of cp -r debian/b-i/firmware/ is more appropriate
[15:28] <rtg> apw: thats exactly what is happening. I can repro the problem quite easily, so I ought to be able to fix it justr as soon as I clear up soem other issues.
[15:30] <apw> rtg ack
[15:43] <cjwatson> rtg: did you apply all my patches? one of them creates a file in that very directory
[15:43] <cjwatson> so I don't see how it would be possible for that to be empty
[15:43] <cjwatson> it's not dynamic or anything, it's just a source directory
[15:44] <cjwatson> i.e. in my branch, there exists a file debian/d-i/firmware/nic-modules
[15:45] <rtg> cjwatson: yes, I applied all of the patches. However, I prefer patches that are bisectable so I may collapse the last 2 (once I figure out why they don't work for ARM)
[15:51] <cjwatson> fine by me, perhaps I should have committed them in the opposite order
[16:02] <apw> Keybuk, hey ... did you get to any testing on union mounty stuff 
[16:09] <Kano> hi apw ,do you want to add headers to make external dvb modules compile
[16:09] <apw> which ones are missing
[16:10] <Kano> cp -a drivers/ieee1394/*.h $(indep_hdrdir)/drivers/ieee1394
[16:11] <Kano> and for fglrx it would not hurt to add
[16:11] <Kano> cp -a drivers/acpi/acpica/*.h $(indep_hdrdir)/drivers/acpi/acpica
[16:12] <Keybuk> apw: not yet, was off on Friday
[16:12] <apw> Keybuk, heh no worrie
[16:12] <Kano> apw: firedtv will not compile without
[16:13] <Kano> i have got a test script for dkms
[16:13] <Kano> http://kanotix.com/files/fix/dkms/dvb-s2api-liplianin-dkms.sh
[16:13] <Kano> that compiles all dvb drivers + some additional dvb-s2 drivers
[16:14] <Kano> the same script can be used to update gspca drivers too, just a small change
[16:17] <apw> Kano, that first one seems like a reasonable request, so get that into a bug... will think about the other
[16:17] <apw> let me know the number so
[16:17] <Kano> for the other you need an extra export too
[16:17] <Kano> http://kanotix.com/files/kernel/unused-patches/2.6.30-export-flush_tlb_page.patch
[16:18] <Kano> with both things my fglrx script works with 2.6.30
[16:18] <Kano> with a relatively small patch
[16:18] <Kano> when you dont copy the headers the patch has to contain em, thats not really useful
[16:23] <Kano> btw. i have have got a verified patch for avm draft-n usb sticks, will be most likely in 2.6.31 too
[16:27] <Kano> http://kanotix.com/files/kernel/unused-patches/2.6.30-ar9170-support-1-stage-firmare+avm-fritz.patch
[16:27] <Kano> you only need the firmware
[19:02] <Kano> apw: why dont you set CONFIG_HAVE_KERNEL_LZMA=y 
[19:03] <Kano> that compresses the vmlinuz with lzma
[19:05] <apw> you mean CONFIG_KERNEL_LZMA ... and that is not guarenteed to be a good thing
[19:05] <apw> the kernel is smaller, but slower to extract from the compressed form
[19:05] <Kano> it is 100% a good thing
[19:05] <apw> there is a trade off there dependant on disk and cpu performance characteristics
[19:05] <Kano> decompress is always fast
[19:05] <apw> its 2x the CPU time to decompress over the default compression
[19:06] <apw> as reported by a number of sources
[19:06] <Kano> which means in seconds
[19:06] <Kano> .5s longer or what
[19:06] <apw> which mean double the decompress time 
[19:06] <apw> which with a boot budget of 10s could make a difference
[19:06] <apw> t
[19:07] <apw> the point is that its not a slam dunk to change, as its a trade offf which needs measuring
[19:07] <Kano> the load time to load the kernel is shorter
[19:07] <Kano> so you win
[19:07] <mjg59> I'd be amazed if the difference in size makes up for the difference in compression
[19:08] <apw> the laod time is shorter yes, but on a netbook where the cpu is poor and the disk is ssd
[19:08] <Kano> for live images you gain 5 mb when you compress kernel+initrd with lzma
[19:08] <apw> is it going to be faster
[19:08] <apw> most of that presumably comes from compressing the initrd with it
[19:08] <Kano> i dont have got a netbook
[19:08] <apw> Kano, and how does that affect my decision?
[19:08] <Kano> apw: well when you dont change it, i change it
[19:09] <apw> then you are happy, and i am happy. win
[19:09] <Kano> it is just a patch i want to get rid of
[19:10] <cjwatson> Kano: FWIW our live images only contain the kernel and initrd once, not twice as I saw you saying the other day
[19:10] <apw> cjwatson, it does beg the question if we could use lzma for the initrd on the CD images as they are one time build compress time wise
[19:10] <Kano> cjwatson: you forget the compressed filesystem!
[19:10] <apw> if the kernel understands both of course
[19:11] <cjwatson> if it works, I expect we could; speed is not so critical there
[19:11] <cjwatson> Kano: no, I don't.
[19:12] <Kano> the only way to get rid of storing it twice would be using for example grub2 as bootloader with a squashfs support module that would fetch the file from the squashfs
[19:12] <cjwatson> Kano: false
[19:12] <cjwatson> Kano: by demonstration, in the last several releases of Ubuntu :-)
[19:13] <Kano> you have got no /boot/vmlinuz-... in squashfs?
[19:13] <cjwatson> Kano: that's correct
[19:13] <cjwatson> Kano: the installer knows to copy it from the ISO9660 filesystem rather than from the squashfs
[19:15] <Kano> then you are forced to boot with iso-scan to isntall
[19:15] <cjwatson> no you aren't, we use ubiquity
[19:15] <Kano> well when you boot from network
[19:16] <cjwatson> you can do that with casper/ubiquity too
[19:16] <cjwatson> (might need some fixes since it's not tried very much, but it's basically possible)
[19:16] <cjwatson> and I don't see why iso-scan is a problem - you ought to have /cdrom set up properly during installation from local media anyway, several bits of code assume that and may operate a bit weirdly if it isn't there
[19:17] <Kano> what does happen when you used live-media-path override
[19:17] <Kano> does your installer support it
[19:18] <cjwatson> casper does but if you use that ubiquity will probably fail to understand what's going on. I invite anyone who has a problem with this to submit patches :-) shouldn't be hard to fix
[19:18] <cjwatson> it'd just need to read casper.conf
[19:18] <cjwatson> (casper does> as of karmic anywya)
[19:18] <cjwatson> anyway
[19:43] <cjwatson> Kano: ... indeed, that's simple enough to do that I've just committed support for it
[19:44] <Kano> do you really need the preseed option in order that your installer works correctly
[19:45] <cjwatson> huh?
[19:45] <cjwatson> what preseed option?
[19:47] <Kano> file=/cdrom/preseed/kubuntu.seed for example
[19:47] <cjwatson> it has sensible defaults for Ubuntu
[19:48] <cjwatson> the preseed options arrange for the right packages to be installed appropriate to the flavour you're installing, so that we don't have to ship a separate installer for every flavour
[19:49] <cjwatson> (we actually do ship a preseed file for Ubuntu too; the main relevant thing it does is to arrange to install the desktop automatically. if you don't use that preseed file then (a) you'll get asked the question on alternate/server CDs (b) it makes no difference on desktop CDs)
[19:50] <Kano> so bascially it is useless on the desktop ones?
[19:54] <Kano> when this is the case, why are those files on it then
[20:01] <cjwatson> Kano: I didn't say that, I said that the bit that arranges to install the desktop automatically makes no difference on desktop CDs
[20:02] <cjwatson> Kano: though right now it's true that none of the rest of the preseed file is relevant to desktop CDs, only DVDs; but who cares? it's easier to just tell the image building infrastructure to always include it
[20:02] <cjwatson> premature optimisation => silly
[20:03] <Kano> well it is at least good to know
[20:03] <Kano> if i want to test u live i use currently something like
[20:03] <Kano> http://kanotix.com/files/fix/grub2/config/70_ubuntu_iso
[20:04] <Kano> did you ever see such a code
[20:48] <Keybuk> -9 is not a happy kernel for me
[20:51] <Kano> Keybuk: do you use a dvb-c card
[20:54] <Keybuk> no
[20:56] <Kano> whats your problem with it
[20:57] <Keybuk> hard locks after the screen is switched off
[21:03] <Kano> intel gfx?
[21:14] <Keybuk> yes
[21:52] <awe> sconklin: you have time for a build question?
[23:08] <Mike-DC> Hi everyone. I'm having trouble recompiling the stock 2.6.28-11-generic kernel in 9.04. Everything compiles fine except for the Ubuntu supplied third-party drivers. I'm rebuilding from the tar.bz2 I retrieved through aptitude. Anyone run into this before and/or have any knowledge in this area?