=== bjf is now known as bjf[afk] === kentb is now known as kentb_out [00:59] kentb_out: \o/ [06:45] hey anyone around that can chat with me a little bit about fixing up lirc in the maverick tree? [06:47] particularly what's there right now is going to oops left and right on 2.6.35, and after chatting with jarod wilson about, probably the best thing to do at this point is to rebase it on the stuff he's submitting for 2.6.36 at http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git;a=summary and pull lirc 0.8.7ish userspace into maverick [06:50] so mostly my question is how the best way to handle this is. for the past few releases, lirc has lived in the ubuntu/ directory by hand injected tarballs. would it be better to just stick with that model for now, and grab latest from his git and drop them in place with the intention that they get removed for ubuntu-n since they should be available without this hackery? [06:51] or is there still value in trying to merge/cherry pick/rebase commits out of his tree, shuffle them around and keep all that history if the stuff would only be around for one more release === ericm_ is now known as ericm [08:20] superm1, we've just taken tarballs from you in the past, so i don't think there is any value in doing anything else this time, especially if its coming in mainline in .36 [08:21] * smb waves to apw [08:21] * apw waves [08:24] apw: I did see that radeon+GRUB2+graphics mode bug, but it looked like you and Colin were on it, so I wandered off to less well-tended bugs. Also, I don't think *my* radeon system is affected, although I haven't tried particularly hard to prod the beast. [08:25] ahhh i think its fallen through the cracks [08:26] Also, in Prague the radeon systems that seemed to have problems got magically better once we killed vga16fb with fire. [08:27] RAOF, well thats good at least, that thing is sooooo old i am amazed it can even start [08:46] RAOF, i wonder if you would have any time to cast an eye over that radeon/grub2 thingy, as i am about to vacation [08:47] I shall see if I can reproduce on my local radeon. [08:47] I'm in a radeon bugfixing mood. [08:48] heh thanks man ... [08:57] apw: In return, would you kindly pass your wandering eye over bug #586325 and accept the lucid task for me? [08:57] Launchpad bug 586325 in linux (Ubuntu) (and 1 other project) "[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X (affects: 1) (heat: 57)" [Medium,Triaged] https://launchpad.net/bugs/586325 [08:59] RAOF, ahh your cursor patch finally made it round the houses [08:59] nomination accepted, that sounds like a patch we'd consider for lucid, though its not tiny [09:09] apw: awesome, our customer will be all excited [09:15] heh don't let them get tooo excited [09:16] apw, it seems you were right with your Natty Narwhal naming [09:16] JFo, ? [09:16] when we were discussing what the next release would be named in fun [09:16] I think it was you that said something about natty narwhal [09:17] heh narwhal i may have got, i doubt i'd have gotten natty [09:17] hmmm [09:17] well, we were close anyway :) [09:17] heh ... at last natty is easy to type [09:33] indeed [09:33] for this natty new release [09:41] apw, do you know if we have SRU plans for bug 586325? [09:41] Launchpad bug 586325 in linux (Ubuntu Lucid) (and 2 other projects) "[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X (affects: 1) (heat: 18)" [Undecided,Triaged] https://launchpad.net/bugs/586325 [09:42] I didn't see anything in the bug suggesting we were considering it [09:42] but that doesn't mean we are not [09:55] * abogani waves all! [09:55] FYI I have updated -lowlatency kernel flavour in the git tree on Zinc if anyone could-would want review it. [09:55] Thanks in advance for all! [09:55] hiya abogani === yofel_ is now known as yofel === chrisccoulson_ is now known as chrisccoulson [11:18] JFo: Are you in the UK? [11:18] lag, yep [11:19] in Oxford [11:20] JFo: I wondered why you were on the internet at some ungodly hour this morning :) [11:23] heh [11:23] sprinting with the QA folks for a community of practice meeting [11:23] for the week [11:24] Isn't that like doing community service at an old folks home or special school? [11:25] hah [11:25] :) [12:24] What is "kernel mode setting" generally? https://wiki.ubuntu.com/X/KernelModeSetting: "X/KernelModeSetting: Kernel mode-setting (KMS) shifts responsibility for selecting and setting up the graphics mode from X.org to the kernel." I don't want to know what it does but rather I'd like to know what KMS is. (It occasionally produces error messages on my Ubuntu 10.04.1 computer.) [12:25] luftikuss, it is the changing of the screen resolution of your machine [12:26] it is handled by the kernel now versus X [12:48] JFo: Thank you for your information. [12:49] luftikuss, my pleasure :) [12:54] JFo: If the X server has crashed: Is there all I can do to analyze the cause to access the crashed computer via ssh and read the /var/log/Xor.0.log? [12:55] s/Xor/Xorg/ [12:55] luftikuss, I'm afraid my X knowledge is rather limited. [12:55] this may be a better resource: https://wiki.ubuntu.com/X/Debugging [12:55] have you taken a look there? [13:21] * amitk just compiled a 12Mb kernel! \o/ [13:21] sed -i -e's/=m/=y/' .config [13:48] smb, is master.kernel.org up for you ? [13:48] apw, yep seems ok [13:49] smb, hrm, seems down for me [13:49] apw, I see other people there, too. Must be some weird routing issue [13:51] smb, yeah must be ... can get in there via frylock [13:51] apw, local credentials busted? [13:51] JFo: What is a "paint-by-numbers fashion" in https://wiki.ubuntu.com/X/Debugging? [13:52] smb, its a network level connection timed out [13:52] apw, Weird indeed. Maybe the gov is upon you ;-P [13:52] heh maybe indeed [13:53] JFo: ~$ dict paint-by-numbers [13:53] No definitions found for "paint-by-numbers" [13:54] malen nach Zahlen [13:54] luftikuss, to paint by numbers is a phrase meaning 'the easy way' it comes from books with black and white outline pictures with the number of the colour to use to fill each box [13:54] smb, apw Thank you for your help. [13:55] luftikuss, apologies, I was away at lunch. [13:56] JFo, being "out to lunch" has its own connotations. [13:56] tgardner, :) [13:56] smb, does that .de translation have the same meaning as in english [13:56] in that case, I am always "out to lunch" [13:56] apw, In the literal sense. Its the name for that painting style [13:57] but you wouldn't use it to mean 'easy' generally [13:58] I don't think commonly. You might probably say it is like paining by numbers [14:04] smb, heh ... [14:04] confirmed i've triggered some counter-measure ... by logging in successfully ... changed IP address at home and its all fixed [14:05] *paining* by numbers, is that a freudian slip? [14:05] apw, You must have been bad. [14:05] probabally logged in 100 times today [14:05] diwic, Must be. Or incompetence at the keyboard [14:18] hey there [14:18] have you guys been hearing about lucid block layer issues under kvm and xen? [14:18] https://bugs.launchpad.net/bugs/618529 [14:18] ^ i filed that earlier [14:18] Ubuntu bug 618529 in linux (Ubuntu) "kernel call traces from blk-core.c (affects: 1) (heat: 6)" [Undecided,New] [14:18] there's a link to a debian bug [14:19] i'm having regular freezes on my linode vm [14:19] and it looks like there are references to this being fixed around the place [14:21] jdub, Depends a bit whether it is real freeze or just slow as hell. If things move on after a while (possibly a long while) it probably is the general problem with writeback [14:23] hmm [14:23] ah, well, i don't mean kernel freeze [14:23] just to be clear [14:23] disk, block or vm or something sure [14:24] i can type 'ps afx' over ssh, for instance, but it never* returns ;-) [14:24] * (may not have tested this to the ultimate conclusion of "never") [14:24] Right, so in that case its likely that writeback (block layer) has some issues. We are working on that [14:26] ah, known probs [14:26] lovely [14:26] particularly on xen/kvm? [14:27] Yeah, just not that simple to come by (there is a set of 14 patches or so). No in general on higher io loads its seems and in particular when unmounting [14:28] I saw the same kind of messages just yesterday while compiling kernels === bjf[afk] is now known as bjf [14:56] smb: is it a lucid-worthy issue? [14:58] jdub, Definitely. There are some tests I want to do which are next on my todo list. And then moving forward. But it should get fixed sooner than later. [14:58] sweet! thanks smb [14:59] in the mean time, i will keep an eye on my poor, suffering linde... and perhaps not post more big videos :-) [14:59] quit [15:00] There might be some test kernel mentioned in bug 585092. Though they might be slightly outdated or rather suited for systems not needing dkms packages (like binary gf drivers) [15:00] Launchpad bug 585092 in linux (Ubuntu Maverick) (and 2 other projects) "giant IO delays on unmount (affects: 1) (heat: 65)" [Medium,Fix released] https://launchpad.net/bugs/585092 === sconklin-gone is now known as sconklin [15:11] any reason I cant load backports jaunty with the 2.6.32-24-generic kernel? [15:14] gzerphey, many, many reasons, not the least of which is "it won't work" [15:16] kind of what i thought [15:17] the reason i ask is that used to be a fix for the wireless disconnect problem with 2.6.x kernels but now im not sure what to do [15:17] gzerphey, try a Lucid compat-wireless package? [15:18] tgardner, In Jaunty? [15:18] he has a lucid kernel no ? [15:18] yes im in lucid [15:18] I guess thats why I assumed Lucid [15:18] Ah ok. thought I read jaunty [15:19] i have tried 32-21 and 32-23 with little success [15:23] gzerphey, have you tried linux-backports-modules-wireless-lucid-generic ? [15:24] yes [15:24] that loaded 32-24 [15:24] also no help [15:25] are you guys familiar with the problem i am running into.... the wireless randomly disconnects and I have to disconnect and reconnect to get it operational again. this seems to happen under load [15:49] apw, okay i'll get a patch together that does it that way then soon, thanks [15:49] bjf, do we still have testing images supposed to be building daily? [15:49] or whenever? [15:50] JFo: that's the theory though i don't check on them every day [15:50] looks like they last built on the 5th [15:50] JFo: i accept patches [15:51] bjf :) [15:51] not sure what is broken, but I'll have a look later. just wanted to make sure we actually expected them to be building regularly [15:52] JFo: i've added it to my stack for today [15:55] k, or if you like I can look at it next week [15:56] I do need to get my knowledge together on the testing images anyway [15:56] JFo: whoever gets to it first [15:56] k :) [17:25] * smb -> out === emma is now known as emc44 === emc44 is now known as em [17:47] ogasawara, ok i've started the sync for the ports meta into our tree [17:47] generally we try and keep a vagly recent copy of that in our ports branch, so that it doesn't get lost [17:47] obviously he is maintaining that currently [17:48] apw: sweet, thanks [18:08] JFo: i think i fixed the daily iso image building [18:09] JFo: am testing now [18:09] sweet! [18:15] JFo: but is anyone using them? [18:20] bjf, I am planning on testing them, but I keep getting sidetracked [18:21] I want to make sure we are building them well before I start giving them away [18:50] * tgardner knows its lunchtime somewhere. [20:27] apw: should "linux-linaro" be added to https://wiki.ubuntu.com/Kernel/Dev/ABIPackages ? [20:29] kees, probabally, though i've never seen it before :) [20:30] apw, linux-linaro is a 1000 series, the most recent upload was 2.6.35-1002.6 [20:31] * jjohansen -> lunch [20:33] tgardner, do we have a meta package for l [20:33] linaro ? [20:33] apw, we do, its a branch in the maverick meta repo [20:34] apw, I'd have thought the k-t list traffic would have twigged you to it [20:34] tgardner, i thought it was there, just too lazy to confirm [21:00] tgardner: did i miss my time? [21:01] bjf, we;re in mumble just qwaiting [21:07] pgraner, have you dropped me that goals email ? [21:08] apw, nope in 5 mins or so [21:10] pgraner, ok i'll go grab dinner === bjf is now known as bjf[afk] === sconklin is now known as sconklin-gone [23:24] rebooting