[01:27]  * dandel pulls ppa of latest 2.6.29 kernel.
[01:27] <dandel> ><; fun... regression from irq changes from acpi persists.
[01:58] <dandel> 0o fun... should i report the bug pertaining to acpi_irq to the ubuntu launchpad or the bugzilla of the linux kernel?
[02:04] <dandel> does anyone know where i can get the 2.6.25 and 2.6.26 kernels as ubuntu packages?
[02:05] <dtchen> dandel: if the bug is in an Ubuntu kernel, use LP
[02:06] <dandel> dtchan it affects the kernel-ppa also
[02:06] <dandel> 2.6.29 gives a different function error string when compared to 2.6.27 lol
[02:07] <dandel> and i can't use lp for this, my bug i had for it, which is not solved got labeled as duplicate ( although the bug evolved as i found more issues between the 2.6.24 and 2.6.27 kernels )
[02:07] <dtchen> it looks like 2.6.2[56] aren't in /mainline; they're not the base of any supported Ubuntu kernel releases
[02:07] <dtchen> (discounting -ports)
[02:08] <dandel> bug # 294323 is when i first found issue
[02:08] <dandel> i kept it updated as best i could, in hope that it would be unflagged and fixed.
[02:11] <dandel> hmm... actually it's faster than 2.6.27 on responding to change, however it still is not as fast to notice the change in the power plug as 2.6.24
[02:12] <dandel> however, it still has issue of automatically kicking out of suspend when plugged in for some reason
[02:13] <dandel> first suspend attempt always fails, then second one works
[06:53] <amitk> dandel: if the problem is upstream, you could update the LP bug saying so, so that the triager might link it to bugzilla.kernel.org. Or, you could directly report it there.
[10:54] <dandel> amitk, the issue is mainstream and i believe it appeared somewhere in 2.6.25 or 2.6.26
[11:03] <amitk> dandel: I suggest updating the bug with this info _and_ if possible ping ogasawara who is the kernel QA
[11:12] <dandel> amitk, i'll just make a new bug and make sure it refers to the old one on the lp tracker.
[11:15] <dandel> wow... this is a new one 0o
[11:15] <dandel> which lead to corrupted low memory ><;
[11:30] <amitk> apw: is there way to revert things in a git index?
[11:30] <amitk> IOW, revert the results of a 'git add .'
[11:31] <apw> you can update the index as often as you like
[11:31] <apw> if what was in the index was whats in a commit you can get that back
[11:31] <apw> if its was an uncommpitted previous add, then no
[11:32] <amitk> apw: it was uncommitted
[11:32] <apw> so i believe that intermediat there is no longer linked
[11:32] <apw> in theory it will still be in your object store
[11:33] <apw> in a loose object ... so if there is something distinctive in it you might be able to find it
[11:33] <apw> ie. its likely high effort, but it might be important enough
[11:33] <amitk> I did "git am <mbox>; git reset --soft HEAD^;" But this leaves everything cached in the index. I want it to go back to the uncommitted state and allow me to add files interactively
[11:34] <amitk> apw: probably not worth it trying to recover the object
[11:35] <apw> hmm so i think you are saying you want the index to be HEAD^
[11:35] <amitk> 'git add --interactive' allows this, but it is quite cumbersome to do it manually
[11:35] <amitk> apw: yes
[11:35] <apw> so i think you want git reset --mixed
[11:36] <dandel> amitk, reported new bug as bug #338701
[11:36] <ubot3> Malone bug 338701 in linux-meta "acpi_irq is not set properly." [Undecided,New] https://launchpad.net/bugs/338701
[11:36] <apw> if you are already done the --soft
[11:36] <amitk> dandel: thanks
[11:36] <apw> i think a git reset --mixed HEAD might do the trick ... as you have already moved your HEAD back one
[11:36] <dandel> it didn't add the mesg log tho.
[11:37] <apw>        --mixed
[11:37] <apw>            Resets the index but not the working tree (i.e., the changed files
[11:37] <apw>            are preserved but not marked for commit) and reports what has not
[11:37] <apw>            been updated. This is the default action.
[11:37] <apw> so if a git show HEAD shows the commit against which you are trying to work
[11:38] <apw> (now) then i think a git reset --mixed HEAD would reset the index only
[11:38] <amitk> apw: --mixed for the win!
[11:38] <apw> cool
[11:38] <amitk> thanks
[11:38] <apw> i always wondered why you might want that, now i know
[11:38] <amitk> useful split out a patch :)
[11:39] <amitk> *useful to
[11:39] <apw> indeed :)
[11:39] <amitk> apw: apparently it is the default action... Only I wasn't trying to be so smart
[11:40] <apw> heh so it is, i think i use --hard almost exclusivly
[11:40] <apw> i've used --soft rarely, and the default never
[15:05] <Keybuk> apw: we did talk about an intrepid backport of the floppy patch, right?
[15:05] <apw> Keybuk, yep, i am on the case
[15:05] <Keybuk> ok, I'll update the bug
[15:05] <apw> its building in my build far right now
[15:05] <apw> i'll be doing it in a sec anyhow
[15:05] <Keybuk> sure, just to track it for SRU purposes
[15:06] <apw> Keybuk, i'll handle it .. .i am pushing some test kernels for intrepid now
[15:06] <apw> when we have some test acks i'll push it through the SRU process
[15:06] <apw> (of course it cannot fail as its an obvious patch but hey)
[15:10] <apw> cking, battery discharge when suspended ... is there a sensible value we can make as the boundary from failure to success?
[15:13] <cking> apw, not sure.. let me think for a minute about this.
[15:13] <apw> a test isn't much of a test if it doesn't tell you if it was good or bad
[15:14] <cking> probably not. in suspend you are keeping memory alive, and that's dependant on how much memory you have and so forth
[15:14] <apw> yeah i guessed as much
[15:14] <cking> the issue which is important is how much current is being drawn when in hibernation. One expects that to be zero - if it's not then something is not good
[15:15] <apw> very true, so perhaps this test will become more useful once we start doing hib stuff ...
[15:17] <cking> apw, yep. I think it should be on the agenda for hibernation testing. I wonder what horrors one will find...
[15:18] <apw> a whole heap
[15:20] <cking> the tricky part will be to factor out which part of the system is doing the current stealing
[17:07] <rtg> apw: you have positive results on https://bugs.launchpad.net/bugs/193970. please push the patch
[17:07] <ubot3> Malone bug 193970 in linux "iwl3945 | iwl4965: Wireless can't be activated after disabling kill switch" [Medium,Confirmed] 
[17:15] <apw> rtg thanks for the heads up.  i believe one of the testers was a Jaunty user, the other I am unsure.  so i propose pushing the jaunty one and holding intrepid until i have some solid results on there?  ok?
[17:16] <rtg> apw: wfm. Jaunty is the only thing I'm intereted in right now.
[17:16] <apw> fair enough... will get it in shortly
[18:48] <tx2650> Hi. I can`t build promise tx2650 driver for the 8.10 kernel. Has anybody done that?
[18:51] <wmat> tx2650: did you see this -> http://www.colinmackenzie.net/index.php?option=com_content&view=article&id=12:promise-satasas-driver-update-tx4650tx2650&catid=8:rotator&Itemid=7
[18:53] <tx2650> yes. Tryed to build with warious patches, somebody said the .28 kernel supports it so I build that kernel and it didnt detect it, so baiscally I`m running out of optiones.
[18:53] <tx2650> options*
[18:54] <tx2650> from colins site I get  Error 2 on compilation
[18:56] <tx2650> I noticed another one complaining about failed build on .27 kernel, so, it`s not my clumsiness
[18:57] <wmat> I see success reports using 2.6.24-16
[18:57] <wmat> but that doesn't help you much
[18:57] <tx2650> :)
[18:58] <tx2650> I had to upgrade to 8.10....ž
[18:59] <tx2650> is there a way to downgrade to 8.04 or could I just build a .24 kernel?
[19:01] <wmat> tx2650: just download the old kernel via synaptic or apt-get and install it. Then pick the old kernel at boot.
[19:03] <tx2650> I tried that already but it says the package has no available version. I suppose I must set sth in sourcelist
[19:07] <tx2650> how can I tell Intrepid to look for packages in Hardy repositories?
[19:11] <wmat> tx2650: https://help.ubuntu.com/community/DowngradeHowto
[20:40] <ion_> What does SAUCE mean in the changelog?
[20:40] <rtg> ion_: its a patch that is not currently upstream.
[20:40] <ion_> What’s the etymology? :-)
[20:41] <rtg> as in 'special sauce'. I use it too keep track of patches that diverge from upstream
[20:41] <ion_> Alright, thanks.
[21:20]  * bradF is back
[22:44] <NCommander> Are kernel mainline builds available for 2.6.29 kernels?
[22:45]  * NCommander is having issues finding them.
[22:45] <dtchen> NCommander: http://kernel.ubuntu.com/~kernel-ppa/mainline/
[22:47] <NCommander> thank you!
[23:21] <dandel> dtchan, on the 2.6.29 kernel should i report bugs pertaining to that to the linux mainline?
[23:22] <dandel> considering i am using the ppa kernel sources.
[23:24] <dtchen> dandel: yes; please be sure to note the pedigree clearly in the bug report  (also, it's dtchEn)
[23:25] <dandel> shows as all lower case here.
[23:25] <dtchen> yes, it is lowercase, but it's an 'e' not an 'a'. Anyhow, no big deal. My nick-highlight just doesn't trigger if you misspell it.
[23:25] <dandel> i did note the issue on 2.6.27 kernel, however i can't confirm the 2.6.26 and 2.6.25 kernel between long term.
[23:26] <dandel> so it's tougher to track the originating kernel.
[23:26] <dtchen> did you try the mainline .24 base?
[23:26] <dandel> 2.6.24 worked fine
[23:26] <dandel> so i haft to find 2.6.25 and 2.6.26 which are both not on the mainline package list.
[23:26] <dtchen> well, only three kernel versions, then. Not too shabby ;-)
[23:27] <dandel> i posted latest 2.6.29 dmesg but that changed when compared to 2.6.27.
[23:28]  * dandel combs the changelogs as best i can to figure out where the possible change happened.
[23:28] <dandel> !bug 338701
[23:28] <ubot3> Factoid bug 338701 not found
[23:28] <ubot3> Malone bug 338701 in linux "acpi_irq is not set properly." [Undecided,Incomplete] https://launchpad.net/bugs/338701