[12:42] <Keybuk> apw: when's your next upstream-tree-of-the-day-build due?
[12:42] <apw> they build about 10am
[12:43] <Keybuk> 23-Jul was the last?
[12:43] <Keybuk> oh, no, daily
[12:43] <Keybuk> sorry, mis-understood your directory structure
[12:43] <apw> heh :)
[12:43] <Keybuk> any way to know what the git log/revno of a given build was?
[12:44] <apw> the last -rc was 23rd
[12:44] <apw> at the top of the build log
[12:44] <Keybuk> why the -g ?
[12:44] <apw> long<v2.6.31-rc4-198-g7d3e91b>
[12:44] <apw> thats the form git uses for describing a commit
[12:45] <apw> the short form of the sha1 follows the -g
[12:45] <Keybuk> ah
[12:45] <Keybuk> got it
[12:45] <Keybuk> that has the patches I need to ack
[12:45]  * Keybuk downloads to test
[12:45] <apw> though i also report the full commit after the checkout there
[12:45] <apw> vvv - build head
[13:03] <Timmy2Tall> Home is where the heart is
[13:03] <Timmy2Tall> would you agree?
[13:57] <maks_> hello Keybuk 
[13:57] <maks_> thanks for your write down, will release current state of i-t to have that out of the way and then soonest pick up.
[13:57] <Keybuk> maks_: busy atm, will get back to you in a bit
[13:57] <maks_> no rush needed. Keybuk 
[13:57] <Keybuk> great! :)
[14:52] <dk_> hi
[14:52] <dk_> i have questions
[14:55] <dk_> i have a Netbook acer aspire one, and i want compile the kernel for the  best performace
[14:58] <rtg> dk_, start here: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
[14:59] <rtg> apw, we don't have a single example of request-pull in any of the git recipe pages.
[14:59] <apw> rtg, thats poor, i can fix that
[15:00] <rtg> apw, the reason I was looking is the I cannot get one of my request-pull examples to work, so I was just making sure i didn't have brain damage
[15:00] <apw> whats it doing wrong reporting lots and lots of patches?
[15:01] <rtg> apw, it can't find the repo on zinc.
[15:01] <apw> wanna paste the line here or in /query that you are using
[15:01] <rtg> apw, actually, there is an example: https://wiki.ubuntu.com/KernelTeam/KernelSimpleGuide?highlight=(request\-pull)
[15:02] <rtg> apw, here is my example: git request-pull HEAD~1 git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git
[15:02] <apw> your branch won't be in the ubuntu karmic repo though will it
[15:02] <apw> ?
[15:03] <rtg> apw, I tried my repo as well
[15:03] <apw> normally its in your personal one
[15:03] <rtg> git request-pull f493e5ae7f0799a45f25e6f0595e32e95990c67d git://kernel.ubuntu.com/rtg/ubuntu-karmic
[15:03] <apw> ok so its definatly yours as the last param
[15:03] <apw> and you have pushded the commit as which branch in your repo?
[15:04] <rtg> apw, this is just master, and I'm synced.
[15:04] <rtg> it should be a no-brainer
[15:04]  * apw looks
[15:04] <rtg> apw, how about you, can you get a request-pull to work correctly?
[15:05] <apw> just testing with your repo
[15:07] <apw> rtg ok a request pull can only be for a commit which is the head of a branch
[15:07] <apw> so you'd have to have pushed HEAD~1 as a branch tip
[15:09] <apw> so the one you are trying there f493e5ae7f0799a45f25e6f0595e32e95990c67d is master~2
[15:09] <apw> so if you want to send a request pull for that you need to do like
[15:09] <dk_> rtg:  i was compiling my kernel for acer aspire one, but i  need more help::)
[15:09] <apw> git push zincremote master~2:pullme
[15:09] <apw> and then the request-pull will work
[15:10] <rtg> apw, I don't think thats correct. I just updated against the core repo (I guess I wasn't synched). This works fine (notice I can specify a commit prior to HEAD) : git request-pull HEAD~1 git://kernel.ubuntu.com/rtg/ubuntu-karmic
[15:11] <rtg> dk_, do it the long way first. install devscripts, then 'debuild -b' and follow the bouncing ball.
[15:12] <apw> rtg ok we are both using it wrong
[15:12] <apw> or i am understanding you wrong
[15:12] <apw> git request-pull HEAD~1 git://kernel.ubuntu.com/rtg/ubuntu-karmic
[15:13] <rtg> apw, my understanding of the SHA1 in request-pull is that is where you'd like the pull to start from.
[15:13] <apw> does not ask for HEAD~1 to be the thing to pull, that says list from after HEAD~1..HEAD on the  page, and find HEAD in the repo
[15:13] <apw> ie the HEAD~1 there is the commit before the first one you want mentioned, but it is trying to find your current branch in there
[15:14] <apw> you can add a commit tip as param 3
[15:14] <apw> but either way that needs to be in the pushed repo as a head
[15:14] <apw> git request-pull f493e5ae7f0799a45f25e6f0595e32e95990c67d git://kernel.ubuntu.com/rtg/ubuntu-karmic
[15:14] <apw> arrg
[15:15] <apw> git request-pull rtg/master~1 git://kernel.ubuntu.com/rtg/ubuntu-karmic rtg/master
[15:15] <apw> so that says ... generate a request to pull the commits from rtg/master~1 to rtg/master
[15:15] <apw> the  final param must be a the sha1 of a tip in the repo in param 2
[15:16] <rtg> apw, I think I grok it. I just wasn't properly synced. Its just like forgetting to see if your mixer is plugged in when it won't turn on.
[15:16] <apw> i happen to be using your branches there
[15:17]  * apw notes he got its use wrong again and once again had to read the manual.  its not an obvious interface to me
[15:18] <rtg> apw, true, but at least request-pull tells you when its confused.
[15:18] <dk_> rtg:  speak spanish?
[15:18] <rtg> dk_, nope.
[15:18] <dk_> ok
[15:18] <apw> rtg it should just say, "look read the manual, trust me its quicker"
[15:19] <rtg> :)
[15:34] <apw> Keybuk, how common across distros is the modprobe blacklist stuff?  is it ubuntu specific?
[15:36] <Keybuk> apw: the blacklist files, or the contents of them?
[15:36] <apw> the format and support for the functionality
[15:37] <Keybuk> oh, totally upstream
[15:37] <Keybuk> we have no patches to module-init-tools
[15:37] <apw> so if you can find the right place, then a blacklist config can be added, cool
[15:39] <apw> Keybuk, are we still looking to remove graphics drivers from initramfs?  i was supprised to find i915 in mine
[15:40] <Keybuk> in the common case, yes
[15:41] <apw> whats the uncommon case?
[15:41] <Keybuk> see my mail today ;)
[15:46] <ogra> phew
[15:46]  * ogra is relived that Keybuk agrees we *do need it* :)
[15:48] <apw> Keybuk, thanks ... thats exactly what i needed to know at the moment i needed to know; most fortuitious
[15:48] <ogra> did anyone ever chack how much ot bloats the kernel if we compile all FB drivers in ?
[15:49] <Keybuk> ogra: FB drivers are quite closely linked to the X driver
[15:49] <ogra> or is that breakins
[15:49] <Keybuk> I don't think we want to compile them in
[15:49] <ogra> *g
[15:49] <Keybuk> in fact, in general, I say we should never compile a _driver_ in
[15:49] <ogra> well, we do so for filesystems
[15:49] <ogra> and that was actually a noticeable speedup
[15:49] <Keybuk> only ext4
[15:50] <Keybuk> ext* sorry
[15:50] <Keybuk> and those aren't really drivers
[15:50] <ogra> fuse too
[15:50] <apw> we tend to compile in commonly used filesystems yes
[15:50] <apw> drivers we tend to make modules
[15:50] <ogra> and nfs i think
[15:50] <Keybuk> again, not a driver
[15:50] <apw> Keybuk, have you tried switching the initramfs to lzma ?
[15:50] <Keybuk> driver sits on a bus
[15:51] <ogra> indeed
[15:51] <maks_> -rw-r--r-- 1 root root  6314398 2009-07-29 16:48 /boot/initrd.img-2.6.31-rc4-amd64
[15:51] <maks_> contrast too
[15:51] <maks_> -rw-r--r-- 1 root root 10655820 2009-07-29 10:10 /boot/initrd.img-2.6.31-rc4-amd64.bak
[15:52] <rtg> Keybuk,  so you are arguing that we should only be compiling in drivers that are essential to mount the rootfs. udev can do the rest (for the common case).
[15:52] <ogra> apw, please make that optional, we have massive probs on ARM with lzma 
[15:52] <Keybuk> apw: I'd like to see the benchmarks of decompress time first
[15:52] <Keybuk> rtg: that's what we do
[15:52] <Keybuk> rtg: I think the only driver we compile in, in practice, is the Intel PIIX driver no?
[15:52] <rtg> Keybuk, thats what I though we were doing, just wanted to confirm.
[15:53] <Keybuk> things that it makes sense to compile in
[15:53] <Keybuk>  - modules that we force load for everybody unconditionally
[15:53] <apw> Keybuk, its slower to decompress, but a lot smaller to load
[15:53] <Keybuk>  - core kernel functionality that it makes no sense to be an option (unix.ko, printk.ko, etc. :p)
[15:53] <rtg> Keybuk, actually, we compile in _all_ of the block level drivers that are required for a root fs
[15:53] <apw> so its a trade off between the two
[15:53] <Keybuk> apw: I'd like to see the timings for that
[15:54] <Keybuk> decompress should show up as the populate_rootfs() time
[15:54] <apw> yeah ... and you should just be able to make the initrd which ever way you prefer
[15:55] <apw> the kernel should understand both
[15:55] <ogra> on ARM its like 10x slower to compress/decompress
[15:55] <apw> i would think on netbooks gzip is faster, on faster boxes i would think lzma probabally is
[15:56] <apw> ogra, yep, but as the kernel understands both you can choose the faster one
[15:56] <ogra> in fact we have massive build failures on arm for all packages using lzma because the ddeb compressing times out after 3h
[15:56] <apw> if your initrd is in flash you may decide not to compress it
[15:56] <ogra> its on SD
[15:56] <ogra> or various forms of disks depending on the HW
[15:57] <ogra> we dont use flash on any of the supported SoCs
[15:58] <apw> all i am saying is it is an option ... not trying to make one or the other the right one
[15:58] <apw> was just interested if Keybuk had poked that pile of ants in his review of boot speed
[16:00] <maks_> smaller initramfs also builds faster, as added bonus :)
[17:00] <apw> cking, that kernel i was tlaking about is here: http://people.canonical.com/~apw/lp318942-jaunty/
[17:02] <cking> apw, cheers, will test.
[17:13] <cking> apw, yep some audio, and crackly reboot sound too
[17:14] <apw> so the audio is 'working' but the thingy you said was bust is
[17:14] <cking> apw, yep. Let me do some other tests (headphone, suspend/resume etc) to make sure it's all fine.
[17:15] <apw> Keybuk, sorry to ask yet again, but where might i find info on the vt7->vt1 switch
[17:24] <cking> apw, speakers work, headphones plug in works, headphones unplugged => no sound out of speakers.
[17:24] <apw> crap
[17:24] <cking> lemme have a poke around.
[17:32] <cking> apw, you're 95% the way there. It's just that weird hda pin stuff that needs some massaging
[17:33] <rtg> cking, you mean that 128 bit magic array of bits?
[17:33] <cking> something that way. It's not too difficult when one has the data sheet. However, I don't have the data sheet :-)
[17:37] <rtg> cking, thats what makes it magic. how often can you procure the data sheet for a motherboard?
[17:37] <cking> ..rarely. But there are ways and means...
[18:02] <apw> cking, it is meant to work in karmic if that helps
[18:02] <cking> really? I will give that a try and make sure.
[18:03] <cking> I will pick this up tomorrow. I've got some family deadlines tonight
[18:03] <apw> just the kernel should be sufficient
[18:03] <apw> and thanks for that
[18:04] <cking> I could not apply your 3rd patch onto jaunty, I got:
[18:04] <cking> Applying: UBUNTU: SAUCE: select the patched sigmatel codec for HP mini family
[18:04] <cking> error: sound/pci/hda/Makefile: does not match index
[18:04] <cking> error: sound/pci/hda/hda_codec.c: does not match index
[18:04] <cking> error: sound/pci/hda/hda_patch.h: does not match index
[18:04] <cking> Patch failed at 0001 UBUNTU: SAUCE: select the patched sigmatel codec for HP mini family
[18:05] <cking> ??
[18:06] <cking> rats, my left hand has gone numb, must be my neck pressing on the nerves
[18:07] <apw> cking, third patch would be 0003?
[18:09] <apw> cking,  what base you applying them to?
[18:09] <cking> top of the jaunty repo.
[18:09] <apw> thats where they are in my tree
[18:10] <cking> lemme retry. could be a typo, my left hand is out of action
[18:10] <apw> d2d686f4ff11f7cde54e30ddab3886936f4101d8 is the tip i am on
[18:11] <apw> and remember they apply in numeric order
[18:11] <cking> 0001, 0002, then 0003 -> probs
[18:12] <cking> d2d686f4ff11f7cde54e30ddab3886936f4101d8 is the tip too
[18:13] <apw> cking, sum those patches
[18:13] <apw> as i just applied them from my rookery copy
[18:13] <apw> apw@dm$ git am ~/rookery/lp318942-jaunty/????-*
[18:13] <apw> Applying: UBUNTU: SAUCE: copy the hda sigmatel codec driver for the HP mini family
[18:13] <cking> 5a65225dec284daf299a8d6711e99595  0001-UBUNTU-SAUCE-copy-the-hda-sigmatel-codec-driver-for-.patch
[18:13] <cking> 0a54f072f5a75c199cd866e5be4971f9  0002-ALSA-hda-Rework-on-STAC-IDT-auto-configuration-code.patch
[18:13] <cking> 0195e12abb7b4ff2d5f2a73a2b86baf2  0003-UBUNTU-SAUCE-select-the-patched-sigmatel-codec-for-H.patch
[18:13] <apw> Applying: ALSA: hda - Rework on STAC/IDT auto-configuration code
[18:13] <apw> Applying: UBUNTU: SAUCE: select the patched sigmatel codec for HP mini family
[18:13] <apw> sums match
[18:19] <cking> apw, see my email - got a script of what happens. Most curious.
[18:23] <apw> cking, oddness, could you ensure you are reset to head correctly
[18:28]  * apw will push up my branch too ...
[18:30] <cking_> apw, that fixed it. sorry about that
[18:30] <apw> cking_, np was confused
[18:32]  * cking_ is surprised he missed that one. doh
[18:32] <cking_> I need to go. Family + left hand issues.
[18:33] <apw> np
[18:33] <apw> go
[18:50] <Alaric`> localtime(time()), folks ....   anyone here running 9.04 on an Inspiron 4100?  I have a fan problem I'm seeking a solution for.
[18:50] <Alaric`> capsule summary:  the fans on the laptop never run, causing it to overheat, unless I load the i8k module.  i8k.ko + i8kmon runs the cooling fans properly, BUT i8k.ko disables the keyboard as soon as it loads, and I can't get the keyboard back except by rebooting without i8k.
[18:51] <Alaric`> is there a known solution for this?
[18:52]  * apw hasn't heard of that specific issue
[18:53] <Alaric`> (right now I'm compiling a new kernel with a modified i8k.c patched to never try to touch fn-key status, to see whether that's where it's blowing away the keyboard)
[18:53] <Alaric`> also speculating that it may be an ACPI issue
[18:53] <apw> have you tried later mainline kernels to see if they work?
[18:54] <Alaric`> last time my wife (it's her laptop) checked for updates, it wasn't showing a newer kernel available as a package
[18:55] <apw> no i mean a later mainline build, from the mainline builds archive
[18:55] <Alaric`> mainline builds archive?
[18:55] <apw> https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
[18:55] <apw> those contain builds of later upstream kernels which can be used to see if the issue is fixed later on
[18:55] <Alaric`> but yeah, once I get the build-kernel-on-ubuntu procedure down, I was thinking of building a 2.6.30.3
[18:55] <apw> which can help find it
[18:56] <Alaric`> hm, lemme check that out
[18:56] <apw> there are prepackaged 2.6.30 kernels on there
[18:57] <Alaric`> hm.  in this situation, would you go with 1.6.30.3, or 2.6.31.rc3?
[18:58] <Alaric`> er, s/1.6/2.6/
[18:58] <Alaric`> oh, there's an rc4
[18:58] <Alaric`> missed it at first
[18:58] <apw> i would tend to pick the latest first if that works pick one between the distro and that one and try that
[18:58] <apw> yeah so i'd try -rc4
[18:58] <apw> its not intended as a fix, more as a barometer of that feature being fixed
[18:59] <Alaric`> the linux-source package is equal to the corresponding linux-image plus linux-headers?
[18:59] <apw> i am suspicious it will not fix things as there does not seem to be much
[18:59] <apw> nope thats a source package no use generally
[19:00] <apw> you want the binary and headers and generic headers
[19:00] <Alaric`> so http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc4/linux-image-2.6.31-020631rc4-generic_2.6.31-020631rc4_i386.deb, http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc4/linux-headers-2.6.31-020631rc4_2.6.31-020631rc4_all.deb, http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc4/linux-headers-2.6.31-020631rc4-generic_2.6.31-020631rc4_i386.deb?
[19:01] <Alaric`> oops.  forgot those'd get expanded.  :p  sorry.
[19:01] <apw> looks about right
[19:01] <apw> is there a bug for this on launchpad?
[19:03] <Alaric`> haven't found any reference to it except in way old threads dating from 2.6.8
[19:03] <apw> you should file one then, so it can get tracked
[19:05] <Alaric`> roger that.  soon as I get this kernel-with-patched-i8k built and tested.
[19:07] <Alaric`> if it works, I'll have at least a workaround to attach to the report.
[19:09] <rtg> apw, whats the script you use to rebase master onto a topic branch, e.h., master --> lpia ?
[19:10] <apw> you mean to rebase the netbook branches onto a tag ... rebase-branch in the branch
[19:10] <apw> that reminds me i have a netbook push to do for jaunty
[19:10] <rtg> apw, I guess. where is it located?
[19:11] <apw> ./debian/scripts/misc/rebase-branch
[19:11] <apw> normally you rebase to a tag
[19:12] <rtg> apw,  ah, that script only lives on the netbook branch
[19:12] <apw> yes, its branch specific right now, am working on removing the last couple of branch specific items
[19:12] <apw> then we cna commit it to the master
[19:13] <apw> that reminds me, i have a proposed update to the karmic config system
[19:13] <apw> which makes it a completely overrides based system
[19:13] <apw> ie. each level contains only the options which are changed
[19:13] <rtg> apw, I'd like to use it for the LTS branch, i.e., the hardy branch in the Jaunty tree.
[19:14] <apw> so you can have a default at the top and only mask it with another value on one flavour or arch
[19:14] <apw> rtg makes sense for that use for sure
[19:14] <apw> i will get an email together for this config thing and send it out, prolly in the morning now
[19:15] <rtg> apw, yeah, isn't it time you were off quaffing beers?
[19:15] <apw> heh something like that
[20:08] <]Oscar> does the usb driver send a reset signal to all peripherial while shutting down the pc?
[20:09] <AnAnt> Hello, I got a directory that has a kernel module how can I avoid a binary blob (.o) file from being deleted by clean target ?
[20:09] <AnAnt>  when I run make -C $KERNELSRC -M $(CURDIR) clean, the blob gets deleted that is
[20:09] <AnAnt> isn't there an override that I can add to the makefile ?