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