[00:01] <lifeless> god yes
[00:02] <lifeless> but you can test
[00:02] <lifeless> "echo 'foo' | mail -s test raof@example.com"
[00:57] <sayao> how can i add a newer kernel repository on lucid? i need at least 2.6.33 for radeon hdmi audio to work
[05:20] <drclue> All right friends romans and countrymen , I have an old piece of gear , an IDE drive caddy (as described in bug 518608)
[05:20] <drclue> This caddy apparently returns a bogus inquiry value indicating a SCSI device.  At one time this device was supported I expect 
[05:20] <drclue> that there was some sort of special device entry that remapped it back to ID (just a guess) and somewhere along the line this entry got retired or superseded. I could I guess hack my OS , but in my school bus out here in the middle of nowhere I have a dozen computer bricks and a few mid towers  and it would be a real time burner to make the hack and keep the hack
[05:20] <ubot3> Malone bug 518608 in linux "unable to mount  ID 04ce:0002 ScanLogic Corp. SL11R-IDE IDE Bridge" [Undecided,New] https://launchpad.net/bugs/518608
[05:25] <drclue> I am not in a HUGE hurry, as I did post tis bug back in February , but it would be nice to get at them old drives, as I have screen reader code for the blind I'm trying to open source (on an ancient IDE) and a few other things that I'm aiming to give away from some 30+ years of coding , but all that material is for now locked away
[05:42] <drclue> Shit , all the brilliant people must live in some time zone not related to the USA (smart people would not live here if they had a choice) :)
[06:45] <drclue> Dam , is it still dead in here?  I can but prey that bug 518608 can get some interest as otherwise I need to hack over a dozen machines to give them a special devices entry that used to exist in the distro
[06:45] <ubot3> Malone bug 518608 in linux "unable to mount  ID 04ce:0002 ScanLogic Corp. SL11R-IDE IDE Bridge" [Undecided,New] https://launchpad.net/bugs/518608
[08:16] <Laibsch> Hi, I reported bug 521967 and worked together with upstream to get a fix.  I've been successfully running this fix locally by recompiling the driver.  I'd like to know what it is I can do to make sure that patch finally hits linux-backport-modules?
[08:16] <ubot3> Malone bug 521967 in linux "support for new atheros wifi chipset" [Unknown,Fix released] https://launchpad.net/bugs/521967
[08:34] <jjohansen> Laibsch: send the patch to kernel-team@lists.ubuntu.com
[08:34] <jjohansen> make sure to point to where it is upstream to show that it is coming from upstream
[08:35] <Laibsch> thank you for your comment
[08:35] <Laibsch> do you have experience with this process?
[08:36] <Laibsch> I'm a bit unsure about it all since as far as I understand it, the result will not ship in the linux-image package but in the linux-backport-modules
[08:36] <Laibsch> package
[08:36] <Laibsch> I hope sending the patch only will be sufficient, I wouldn't be 100% sure about where to put the patch to create a debdiff
[08:37] <jjohansen> Laibsch: send the patch so it can get reviewed and acked, without that it won't get in
[08:37] <Laibsch> I'm not sure you understood my question
[08:37] <jjohansen> then one of the devs who can commit to linux-backport-modules can pick it up
[08:38] <Laibsch> there isn't just one single patch, for example, but it depends on the version, etc.
[08:38] <Laibsch> I want to be sure I pick the right patch
[08:38] <Laibsch> but I can't do that because I can't create a package myself
[08:38] <jjohansen> ah, that gets more difficult
[08:38] <Laibsch> because kernel packages in ubuntu have become somewhat opaque
[08:38] <Laibsch> I generally do have no problem packaging stuff
[08:38] <jjohansen> right
[08:39] <Laibsch> But I don't really understand the kernel packages and the meta-packages anymore
[08:39] <Laibsch> let me rephrase the question
[08:40] <Laibsch> when I send in patch abc.diff, what will the devs receiving it do with it?  How can I recreate that process?
[08:40] <jjohansen> ah, well review it, and then suck it into a git tree
[08:41] <jjohansen> but I am haven't looked at backport modules, I know there is a little more to be done for those
[08:44] <Laibsch> see, that is exactly the point
[08:44] <Laibsch> it's not just "suck it into a git tree", it seems
[08:44] <Laibsch> my understanding is that the linux-image package itself will not be updated past a certain point and we're well past that
[08:45] <Laibsch> additions to add new drivers are then only made via linux-backport-modules
[08:45] <Laibsch> so, I'd like to rehash my question
[08:45] <Laibsch> Hi, I reported bug 521967 and worked together with upstream to get a fix.  I've been successfully running this fix locally by recompiling the driver.  I'd like to know what it is I can do to make sure that patch finally hits linux-backport-modules?
[08:45] <ubot3> Malone bug 521967 in linux "support for new atheros wifi chipset" [Unknown,Fix released] https://launchpad.net/bugs/521967
[08:45] <jjohansen> the kernel is frozen but it is still accepting bug fixes
[08:46] <jjohansen> it will depend on the exactly what the changes are
[08:50] <Laibsch> supposedly, http://kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2010-03/AR2427-2.6.32.y.patch are the necessary changes against 2.6.32
[08:50] <Laibsch> but that's not what I've been using
[08:50] <Laibsch> the changes are to add support for a so far unsupported wifi chip in a popular netbook
[08:51] <jjohansen> ah, yeah that will have to go into backports I think
[08:53] <jjohansen> though the patch is small enough it maybe could get sucked in, I would send it
[08:54] <Laibsch> please listen
[08:54] <Laibsch> I'm not even sure that patch actually applies correctly or does what it says it does
[08:54] <Laibsch> so, I'd like to test this first
[08:55] <Laibsch> Should make sense, no?
[08:55] <jjohansen> Ah, okay.  I would build with the kernel first before ever trying to mess with backports
[08:55] <Laibsch> but the kernel packages are special beasts, so I'm not sure how this should be done
[08:56] <Laibsch> I'll have another look
[08:56] <jjohansen> just a sec
[08:56] <Laibsch> last time I tried to build a Ubuntu kernel with one additional patch, everything just blew up
[08:56] <jjohansen> https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
[08:56] <jjohansen> https://wiki.ubuntu.com/KernelTeam/KernelGitGuide
[08:56] <jjohansen> https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
[08:57] <jjohansen> basically what you need to do is get the git tree
[08:57] <jjohansen> KernelGitGuide covers that
[08:57] <Laibsch> right now, just an innocent "pull-lp-source linux-image" already blows up
[08:57] <Laibsch> OK
[08:58] <Laibsch> I'm afraid that git will offer even more potential for complications
[08:58] <jjohansen> right you are going to have use git
[08:58] <Laibsch> I'll try the currently released package first
[08:58] <jjohansen> though the amount of git needed is very minimal
[08:59] <jjohansen> basically git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git 
[08:59] <jjohansen> then you need to setup and install enough packages for fakeroot
[09:00] <jjohansen> if you are building on lucid you don't need to actually setup a chroot environment
[09:01] <jjohansen> once you have the kernel you can either use the debian build scripts (recommended) and it will spit out a deb or you can actually use straight up regular kernel build (make)
[09:02] <jjohansen> for you the straight up build might be easier as you won't need to setup as much environment
[09:02] <jjohansen> basically git clone the tree
[09:02] <jjohansen> cd into ubuntu-lucid
[09:02] <jjohansen> apply the patch
[09:02] <jjohansen> copy /boot/config-2.6.32-xxx
[09:03] <jjohansen> what ever your latest config is
[09:03] <jjohansen> and do a make
[09:03] <jjohansen> that kernel can be installed and tested without the deb
[09:03] <jjohansen> it just not part of the package system
[09:04] <jjohansen> other wise you will need to follow the KernelMaintanence and Starter links from the knowledge base to install the packages you need to build a kernel and get out a dpkg
[09:05] <jjohansen> like you said it is a very different processes
[09:05] <Laibsch> I'm quite familiar with git, that is not the issue.  But git will of course be more unstable than the released package.  Therefore I may hit problems there that I wouldn't in the released version.  That's what I meant.
[09:07] <Laibsch> I'll have a look at the wiki, hoping it won't link to another 1000 or so pages to read before I get to compiling something.
[09:07] <jjohansen> Laibsch: there are a lot of links but you only need a couple of them
[09:08] <Laibsch> hehe
[09:08] <Laibsch> that only helps if you know which ones are relevant
[09:08] <Laibsch> let me have a look first
[09:08] <jjohansen> maybe the gitguid and the Maintenance and MaintenanceStarter
[09:09] <jjohansen> and if you want to use a chroot (optional) BuildKernelWithChroot
[09:10] <Laibsch> https://wiki.ubuntu.com/KernelTeam/KernelForIdiots
[09:10] <Laibsch> that's probably what I want
[09:12] <jjohansen> err no
[09:12] <jjohansen> that page is a confusing mess
[09:13] <jjohansen> what you do need to know is to use
[09:13] <jjohansen> fakeroot debian/rules clean
[09:14] <jjohansen> before building the kernel
[09:14] <jjohansen> don't edit the debian.master file like it recommends for skipabi=true
[09:14] <jjohansen> if you want to skip the abi checks just do
[09:15] <jjohansen> skipabi=true fakeroot debian/rules binary-generic
[09:15] <jjohansen> that will build the generic kernel flavour, no need to edit flavours etc.
[09:15] <Laibsch> thank you for your continuted support
[09:16] <Laibsch> I'm currently rebasing the git branch I had set up for this about a month ago
[09:16] <Laibsch> let's see if this time around I'm more successful
[09:19] <jjohansen> do you have anything on the branch you want to keep?
[09:19] <jjohansen> if not git fetch ; git reset --hard origin/master
[09:19] <jjohansen> will give you a clean tree set to the current head
[09:24] <Laibsch> yes, thanks
[09:25] <Laibsch> I'm quite familiar with git from another project
[09:25] <Laibsch> git doesn't scare me at all
[09:25] <Laibsch> bzr does ;-)
[09:26] <jjohansen> :)
[09:32] <Laibsch> I was afraid something like http://paste.debian.net/68112/ would happen
[09:32] <Laibsch> Ubuntu seems to have patched main.c itself, I'd guess
[09:33] <Laibsch> Unfortunately, I'm not skilled enough to rebase either of the patches
[09:33] <jjohansen> what does the reject look like?
[09:34] <Laibsch> I did --dry-run
[09:34] <Laibsch> I don't think there is a reject file
[09:34] <Laibsch> let me redo this
[09:34] <Laibsch> patch is rather simple, maybe it's possible to rebase
[09:35] <Laibsch> http://paste.debian.net/68113/ is the reject
[09:39] <jjohansen> Laibsch: http://paste.debian.net/68114/
[09:39] <jjohansen> ah crud nope, wrong tree
[09:39] <jjohansen> give me a sec
[09:46] <jjohansen> Laibsch: http://paste.debian.net/68116/
[09:48] <Laibsch> thank you
[09:48] <Laibsch> at least it applies cleanly
[09:48] <Laibsch> let's try compilation now
[10:12]  * apw looks agast at just how long a build took:
[10:13] <apw> Finished 5 minutes ago (took 10 hours, 26 minutes, 22.0 seconds)
[10:31] <Laibsch> jjohansen: I'm sorry, but again, all this doesn't work
[10:31] <Laibsch> I've tried the Kernel for idiots page, the KernelMaintenance page and the KernelMaintenanceStarter page
[10:32] <Laibsch> It seems there is always one step or two missing when following the instructions given there.
[10:37] <Laibsch> re
[10:42] <apw> amitk, are you aware of bug #542041?
[10:42] <ubot3> Malone bug 542041 in linux-ti-omap "ext4 support broken on omap kernel" [Critical,Confirmed] https://launchpad.net/bugs/542041
[10:42] <apw> Laibsch, jj is probabally sleeping
[10:43] <Laibsch> I see
[10:43] <Laibsch> Where can I find an idiot's guide to "compile your Ubuntu kernel from the Ubuntu git checkout"?
[10:43] <apw> Laibsch, those are the simple guides
[10:43] <Laibsch> I am tracking kernel.ubuntu.com/ubuntu/ubuntu-lucid.git
[10:43] <amitk> apw: it was a one-off thing, I think. ogra have you seen this again?
[10:44] <apw> it should be three or four simple steps
[10:44] <Laibsch> apw: but it seems there are steps missing
[10:44] <Laibsch> here is what I tried from a clean checkout
[10:44] <ogra> amitk, well, i have no working image to actually install it yet, it was on a rootstock built image on an XM with your first shot XM kernel
[10:44] <ogra> i'll update it once i can test installs
[10:45] <amitk> ok, apw ^
[10:45] <Laibsch> bash debian/scripts/misc/getabis 2.6.32 19.28
[10:45] <ogra> it can easily be the fault of that XM kernel
[10:45] <Laibsch> debian/rules startnewrelease
[10:46] <Laibsch> the first seems to succeed (although nothing is downloaded)
[10:46] <Laibsch> the second one already bombs out
[10:47] <Laibsch> I tried to build the missing debian/control with "fakeroot debian/rules binary-generic", but that doesn't work, either
[10:47] <Laibsch> That's my understanding of the steps to take (I tried a few other variations) but they fail
[10:49] <Laibsch> https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter#Basic%20system%20setup suggests that I should just run "debuild -b" but that is equally wrong/outdated
[10:49] <Laibsch> all these instructions seem to be missing the step that creates the files under debian for the following operations
[10:53] <jjohansen> Laibsch: did you do fakeroot debian/rules clean
[10:53] <jjohansen> first
[10:53] <jjohansen> that will build up the debian dir
[10:54] <Laibsch> I did that now
[10:54] <mdz> apw: hi
[10:54] <apw> mdz, hi
[10:55] <Laibsch> I had been under the (apparently mistaken) assumption that fakeroot debian/rules binary-generic was the equivalent if one only wanted to build the generic target
[10:55] <mdz> apw: I just discovered that you have a blog, and was wondering why it isn't on Planet Ubuntu yet :-)
[10:55] <jjohansen> Laibsch: you should then only need to do fakeroot debian/rules binary-generic
[10:55] <jjohansen> no start release or anything like that
[10:55] <Laibsch> OK
[10:55] <Laibsch> thanks
[10:55] <apw> mdz, hrm, it isn't i am sure i asked someone to add that for me, back before i had the rights to do it
[10:56] <apw> mdz, got a pointer to the instructions ... i'll go fix that
[10:56] <mdz> apw: cool, thanks
[10:57] <mdz> apw: if you could spread the word to your teammates to get themselves added as well, that would be great. people are missing out on some great content from the kernel team
[10:57] <apw> mdz will do ... i suspect we've all thought the otehr was adding us while adding themselves or something silly
[11:07] <amitk> mdz: it was a question of rights, AFAIK for most people.
[11:08] <mdz> amitk: meaning some people are behind on becoming Ubuntu members?
[11:09] <amitk> mdz: right..
[11:09] <apw> yeah i though i added mine right at the start, while i was still doing all that stuff ... seems not
[11:10] <amitk> apw: perhaps it would be easier if you subscribed the voices.canonical feed for the kernel team to planet.
[11:16] <apw> amitk, might that double up some feeds if i did that
[11:16] <apw> that sounds like it would need to be coordinated
[11:18] <amitk> apw: a single feed subscribed to planet might make it easier in future to add other blogs to voices and make it available on planet.
[11:19] <apw> amitk, perhaps we could sort that out release week
[11:19] <amitk> yeah
[13:01] <RAOF> apw: Good morning!  How easy is it for you to create a test kernel with a git commit cherrypicked on top?  If your kernel-team special sauce makes it easier, could I point you at bug #558657?  If you're busy, I'll prepare a test kernel myself.
[13:01] <ubot3> Malone bug 558657 in linux "mouse usage causes Xorg CPU usage to spike, and mouse pointer becomes less responsive" [High,Incomplete] https://launchpad.net/bugs/558657
[13:02] <apw> RAOF, pretty easy as i do it often
[13:04] <RAOF> I'm not certain the referenced commit fixes the bug, but it'd be nice to check.  Thanks.
[13:05] <apw> RAOF, where did that commit come from, its not an upstream linus commit
[13:05] <apw> (for the patch description)
[13:05] <RAOF> Ah, sorry.  nouveau/linux-2.6
[13:06] <apw> RAOF, ok .. .building now, takes about an hour to get them built and uploaded, perhaps a little more
[13:08] <RAOF> Thanks.  I'll be asleep by then; can you point Karl at the kernel when it's done?
[13:09] <RAOF> Hm.  Interesting.  I see that radeon is flat out disabling MSI on all IGP chips now.  I seem to recall that we've recently done some radeon MSI quirking.
[14:26] <Pici> poke, looks like this channel is set +q $~a  which is preventing unregistered users from talking here.  This probably isn't needed any longer as we're not getting those sort of spam attacks anymore.  
[14:31] <amitk> apw: did we find out what happend to ops on this channel? (Pici's question)
[14:32] <apw> amitk, nope didn't find out ... i think brad is one
[14:32] <Pici> /msg chanserv access #ubuntu-kernel list     will tell you.  I didn't want to ping any of them specifically.
[14:32] <apw> though whoever set that for us, and it was not one of us, really should have unset it when they took it off again gneerally
[14:33] <Pici> apw: It was probably set during freenode's migration to ircd7.
[14:33] <apw> no answer ... hrm
[14:33] <amitk> Pici: I get nothing with that command
[14:33] <apw> Pici, maybe ... noone told us we needed to undo it ... hrm
[14:34] <apw> seems to work if you /query chanserv
[14:34] <apw> stupid chanserv
[14:35] <Pici> mode +R turned into +q $~a  during the migration.
[14:35] <Pici> Anyway, /mode -q $~a   just needs to be set.
[14:35] <apw> i'll try and find someone to sort it out