[00:01] god yes [00:02] but you can test [00:02] "echo 'foo' | mail -s test raof@example.com" [00:57] how can i add a newer kernel repository on lucid? i need at least 2.6.33 for radeon hdmi audio to work === emma_ is now known as emma === gary_ is now known as Guest34616 [05:20] All right friends romans and countrymen , I have an old piece of gear , an IDE drive caddy (as described in bug 518608) [05:20] This caddy apparently returns a bogus inquiry value indicating a SCSI device. At one time this device was supported I expect [05:20] 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] 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] 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] 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] 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] 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] 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] Malone bug 521967 in linux "support for new atheros wifi chipset" [Unknown,Fix released] https://launchpad.net/bugs/521967 [08:34] Laibsch: send the patch to kernel-team@lists.ubuntu.com [08:34] make sure to point to where it is upstream to show that it is coming from upstream [08:35] thank you for your comment [08:35] do you have experience with this process? [08:36] 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] package [08:36] 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] Laibsch: send the patch so it can get reviewed and acked, without that it won't get in [08:37] I'm not sure you understood my question [08:37] then one of the devs who can commit to linux-backport-modules can pick it up [08:38] there isn't just one single patch, for example, but it depends on the version, etc. [08:38] I want to be sure I pick the right patch [08:38] but I can't do that because I can't create a package myself [08:38] ah, that gets more difficult [08:38] because kernel packages in ubuntu have become somewhat opaque [08:38] I generally do have no problem packaging stuff [08:38] right [08:39] But I don't really understand the kernel packages and the meta-packages anymore [08:39] let me rephrase the question [08:40] when I send in patch abc.diff, what will the devs receiving it do with it? How can I recreate that process? [08:40] ah, well review it, and then suck it into a git tree [08:41] but I am haven't looked at backport modules, I know there is a little more to be done for those [08:44] see, that is exactly the point [08:44] it's not just "suck it into a git tree", it seems [08:44] 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] additions to add new drivers are then only made via linux-backport-modules [08:45] so, I'd like to rehash my question [08:45] 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] Malone bug 521967 in linux "support for new atheros wifi chipset" [Unknown,Fix released] https://launchpad.net/bugs/521967 [08:45] the kernel is frozen but it is still accepting bug fixes [08:46] it will depend on the exactly what the changes are [08:50] 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] but that's not what I've been using [08:50] the changes are to add support for a so far unsupported wifi chip in a popular netbook [08:51] ah, yeah that will have to go into backports I think [08:53] though the patch is small enough it maybe could get sucked in, I would send it [08:54] please listen [08:54] I'm not even sure that patch actually applies correctly or does what it says it does [08:54] so, I'd like to test this first [08:55] Should make sense, no? [08:55] Ah, okay. I would build with the kernel first before ever trying to mess with backports [08:55] but the kernel packages are special beasts, so I'm not sure how this should be done [08:56] I'll have another look [08:56] just a sec [08:56] last time I tried to build a Ubuntu kernel with one additional patch, everything just blew up [08:56] https://wiki.ubuntu.com/KernelTeam/KnowledgeBase [08:56] https://wiki.ubuntu.com/KernelTeam/KernelGitGuide [08:56] https://wiki.ubuntu.com/KernelTeam/KernelMaintenance [08:57] basically what you need to do is get the git tree [08:57] KernelGitGuide covers that [08:57] right now, just an innocent "pull-lp-source linux-image" already blows up [08:57] OK [08:58] I'm afraid that git will offer even more potential for complications [08:58] right you are going to have use git [08:58] I'll try the currently released package first [08:58] though the amount of git needed is very minimal [08:59] basically git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git [08:59] then you need to setup and install enough packages for fakeroot [09:00] if you are building on lucid you don't need to actually setup a chroot environment [09:01] 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] for you the straight up build might be easier as you won't need to setup as much environment [09:02] basically git clone the tree [09:02] cd into ubuntu-lucid [09:02] apply the patch [09:02] copy /boot/config-2.6.32-xxx [09:03] what ever your latest config is [09:03] and do a make [09:03] that kernel can be installed and tested without the deb [09:03] it just not part of the package system [09:04] 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] like you said it is a very different processes [09:05] 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] 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] Laibsch: there are a lot of links but you only need a couple of them [09:08] hehe [09:08] that only helps if you know which ones are relevant [09:08] let me have a look first [09:08] maybe the gitguid and the Maintenance and MaintenanceStarter [09:09] and if you want to use a chroot (optional) BuildKernelWithChroot [09:10] https://wiki.ubuntu.com/KernelTeam/KernelForIdiots [09:10] that's probably what I want [09:12] err no [09:12] that page is a confusing mess [09:13] what you do need to know is to use [09:13] fakeroot debian/rules clean [09:14] before building the kernel [09:14] don't edit the debian.master file like it recommends for skipabi=true [09:14] if you want to skip the abi checks just do [09:15] skipabi=true fakeroot debian/rules binary-generic [09:15] that will build the generic kernel flavour, no need to edit flavours etc. [09:15] thank you for your continuted support [09:16] I'm currently rebasing the git branch I had set up for this about a month ago [09:16] let's see if this time around I'm more successful [09:19] do you have anything on the branch you want to keep? [09:19] if not git fetch ; git reset --hard origin/master [09:19] will give you a clean tree set to the current head [09:24] yes, thanks [09:25] I'm quite familiar with git from another project [09:25] git doesn't scare me at all [09:25] bzr does ;-) [09:26] :) [09:32] I was afraid something like http://paste.debian.net/68112/ would happen [09:32] Ubuntu seems to have patched main.c itself, I'd guess [09:33] Unfortunately, I'm not skilled enough to rebase either of the patches [09:33] what does the reject look like? [09:34] I did --dry-run [09:34] I don't think there is a reject file [09:34] let me redo this [09:34] patch is rather simple, maybe it's possible to rebase [09:35] http://paste.debian.net/68113/ is the reject [09:39] Laibsch: http://paste.debian.net/68114/ [09:39] ah crud nope, wrong tree [09:39] give me a sec [09:46] Laibsch: http://paste.debian.net/68116/ [09:48] thank you [09:48] at least it applies cleanly [09:48] let's try compilation now [10:12] * apw looks agast at just how long a build took: [10:13] Finished 5 minutes ago (took 10 hours, 26 minutes, 22.0 seconds) [10:31] jjohansen: I'm sorry, but again, all this doesn't work [10:31] I've tried the Kernel for idiots page, the KernelMaintenance page and the KernelMaintenanceStarter page [10:32] It seems there is always one step or two missing when following the instructions given there. [10:37] re [10:42] amitk, are you aware of bug #542041? [10:42] Malone bug 542041 in linux-ti-omap "ext4 support broken on omap kernel" [Critical,Confirmed] https://launchpad.net/bugs/542041 [10:42] Laibsch, jj is probabally sleeping [10:43] I see [10:43] Where can I find an idiot's guide to "compile your Ubuntu kernel from the Ubuntu git checkout"? [10:43] Laibsch, those are the simple guides [10:43] I am tracking kernel.ubuntu.com/ubuntu/ubuntu-lucid.git [10:43] apw: it was a one-off thing, I think. ogra have you seen this again? [10:44] it should be three or four simple steps [10:44] apw: but it seems there are steps missing [10:44] here is what I tried from a clean checkout [10:44] 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] i'll update it once i can test installs [10:45] ok, apw ^ [10:45] bash debian/scripts/misc/getabis 2.6.32 19.28 [10:45] it can easily be the fault of that XM kernel [10:45] debian/rules startnewrelease [10:46] the first seems to succeed (although nothing is downloaded) [10:46] the second one already bombs out [10:47] I tried to build the missing debian/control with "fakeroot debian/rules binary-generic", but that doesn't work, either [10:47] That's my understanding of the steps to take (I tried a few other variations) but they fail [10:49] 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] all these instructions seem to be missing the step that creates the files under debian for the following operations [10:53] Laibsch: did you do fakeroot debian/rules clean [10:53] first [10:53] that will build up the debian dir [10:54] I did that now [10:54] apw: hi [10:54] mdz, hi [10:55] 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] apw: I just discovered that you have a blog, and was wondering why it isn't on Planet Ubuntu yet :-) [10:55] Laibsch: you should then only need to do fakeroot debian/rules binary-generic [10:55] no start release or anything like that [10:55] OK [10:55] thanks [10:55] 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] mdz, got a pointer to the instructions ... i'll go fix that [10:56] apw: cool, thanks [10:57] 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] mdz will do ... i suspect we've all thought the otehr was adding us while adding themselves or something silly [11:07] mdz: it was a question of rights, AFAIK for most people. [11:08] amitk: meaning some people are behind on becoming Ubuntu members? [11:09] mdz: right.. [11:09] yeah i though i added mine right at the start, while i was still doing all that stuff ... seems not [11:10] apw: perhaps it would be easier if you subscribed the voices.canonical feed for the kernel team to planet. [11:16] amitk, might that double up some feeds if i did that [11:16] that sounds like it would need to be coordinated [11:18] 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] amitk, perhaps we could sort that out release week [11:19] yeah [13:01] 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] 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] RAOF, pretty easy as i do it often [13:04] I'm not certain the referenced commit fixes the bug, but it'd be nice to check. Thanks. [13:05] RAOF, where did that commit come from, its not an upstream linus commit [13:05] (for the patch description) [13:05] Ah, sorry. nouveau/linux-2.6 [13:06] RAOF, ok .. .building now, takes about an hour to get them built and uploaded, perhaps a little more [13:08] Thanks. I'll be asleep by then; can you point Karl at the kernel when it's done? [13:09] 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] 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] apw: did we find out what happend to ops on this channel? (Pici's question) [14:32] amitk, nope didn't find out ... i think brad is one [14:32] /msg chanserv access #ubuntu-kernel list will tell you. I didn't want to ping any of them specifically. [14:32] 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] apw: It was probably set during freenode's migration to ircd7. [14:33] no answer ... hrm [14:33] Pici: I get nothing with that command [14:33] Pici, maybe ... noone told us we needed to undo it ... hrm [14:34] seems to work if you /query chanserv [14:34] stupid chanserv [14:35] mode +R turned into +q $~a during the migration. [14:35] Anyway, /mode -q $~a just needs to be set. [14:35] i'll try and find someone to sort it out === yofel_ is now known as yofel === bjf is now known as bjf-afk === amitk is now known as amitk-afk === bjf-afk is now known as bjf === sconklin is now known as sconklin-gone