=== jjohansen is now known as jj-afk [02:00] back on later === n2diy_ is now known as n2diy [05:37] * lucent waves hands a bit [05:38] I've got a couple of bugs that need attention, the fixes have landed in mainline and I need help tracking whether or not that has trickled down into say, any of the Ubuntu released kernels [05:38] bugs are #660315 and #657081 === _LibertyZero is now known as LibertyZero === smb` is now known as smb === leagris is now known as virtuald === jj-afk is now known as jjohansen [09:19] bug #660315, bug #657081 [09:19] Launchpad bug 660315 in linux (Ubuntu) "U232-P9 USB Serial adapter not working in Ubuntu 10.10 (affects: 1) (heat: 62)" [Undecided,New] https://launchpad.net/bugs/660315 [09:19] Launchpad bug 657081 in linux (Ubuntu) "New firewire stack unreliable with Texas Instruments TSB82AA2 IEEE-1394b (affects: 1) (heat: 58)" [Undecided,New] https://launchpad.net/bugs/657081 [09:19] apw, random bug numbers? [09:20] smb from the last messages in my window (in the wrong format to trigger ubotu [09:20] ah [09:20] no idea what day they were from === doko__ is now known as doko [10:29] lucent, updated both bugs status, both are in the pipe to released, one in -proposed right now and one applied ready for the next upload to -proposed [10:35] apw: back from holiday yet? :) I'd like to talk about vt.handoff again ... [10:35] cjwatson, sure am ... saw you 'numbering' thing ... [10:35] bug 689606 [10:35] Launchpad bug 689606 in linux (Ubuntu) "vt.handoff uses kernel-internal numbering, not conventional user-visible numbering (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/689606 [10:36] i concur that all other interfaces use real VT numbers and as such should be adjusted [10:41] cjwatson, i see if you use =6 that things are even less flickery ... [10:41] which i was not expecting [10:45] * apw suspects cjwatson has been sucked up into the vortex [10:50] apw: right, =6 worked just fine because plymouth goes on vt7 [10:51] I think the default in the patch that adds a flag bit should probably go to vt7 too; although having userspace policy in a kernel patch like that is kind of unfortunate [10:52] apw: I mostly just wanted to check that you did intend to change vt.handoff numbering, since I'm nearly ready to upload a grub2 package that uses it :) [10:52] cjwatson, yep, am spinning a test kernel right now with the requisite changes, will point you to it for testing shortly [10:58] cjwatson, is that grub with a solid background? [11:05] cjwatson, are you handing off via the command line option, i assume you are [11:09] apw: yes and yes [11:09] also with my best effort at autodetecting a decent resolution using VBE [11:09] cjwatson, excellent, can i swap a kernel for a grub package so i can test it ? [11:10] sure, give me a bit to get it built [11:10] cjwatson, i assume you can ship the grub component without the kernel numbering fix, as it will work just not as well with the wrong number [11:11] I was just going to ship it with vt.handoff=7. It works, just not quite as well [11:11] (works> if the new kernel isn't present, I mean) [11:11] yep perfect sense, it looks swish here with it on 7 [11:11] though as i have my own image there is a jerk as the image moves to the right place [11:12] right, just using flat colour should avoid that [11:14] took longer than I expected to get that done in grub, I had a seriously annoying bug where some of the screen was in a slightly different shade of purple [11:14] eventually worked out that red and blue channels were swapped [11:15] cjwatson, woh odd indeed [11:16] cjwatson, i recon if they want something other than solid, that we just put the orange ubuntu circle of friends in the centre, fairly large, and then transition to ubuntu ... being completly different it shouldn't feel odd [11:19] completely different is better than slightly different, but anything that doesn't get the design team on my back is favourite [11:22] apw: can you trigger a rebuild for drm-next in the mainline PPA, please? The last kernel image wasn't built (only the headers are there) [11:23] tseliot, normally that means it failed to build [11:24] tseliot, yeah its failed cause various staging drivers do not build in that kernel [11:25] tseliot, there doesn't seem to have been any activity on that tree for some weeks, have i got the right source? [11:25] apw: easycap_main.c failed... [11:25] its an old 2.6.37-rc3 base it seems ? [11:26] those bugs were shaken out in mainline since then, as mainline is building again [11:26] apw: maybe they're using http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-core-next now? [11:27] tseliot, cirtainly i am not using that one currently [11:27] thats 12 days old too [11:28] apw: yes, maybe they're focusing on drm-fixes now but that's not the point [11:28] apw: could you trigger a build of drm-core-next please? [11:28] that would really help [11:28] tseliot, thats not a tree we normally build, is it one we should ? [11:29] apw: I guess so [11:30] tseliot, instead of drm-next ? [11:30] apw: I need to check this. In the meantime can you simply add it? Or is it too much work compared with a replacement? [11:31] tseliot, its very expensive to build these things in general, so i am not keen to add an additional one if it is not needed, if its really a replacement [11:32] tseliot, this core tree is based on the same base so it will fail t o build with the same errors anyhow [11:33] apw: I'll ask around about drm-core-next but yes, you're right about the build failure [11:34] apw: I guess those commits for the radeon driver are not in the linus branch, right? [11:34] tseliot, they seem to be about the same as well [11:35] there appears to be one commit difference between those two branches [11:36] apw: by linus branch I really mean Linus' branch [11:36] commit acb325062afc09c196f7d3888b81312e6ebcdc35 [11:36] Author: Alex Deucher [11:36] Date: Tue Nov 23 00:41:00 2010 -0500 [11:36] drm/radeon/kms: improve pflip precision on r1xx-r4xx [11:36] thats the only commit which they differ by [11:37] apw: ah, good. Is this available in the mainline PPA? [11:38] (the difference above is between drm-next and drm-core-next, am still investigating whats in mainline) [11:38] aah [11:38] ok [11:39] tseliot, there is a slew of ATI stuff not in linus tree [11:39] tseliot, do you have a commit in mind you need? [11:41] apw: well I'd say at least 9535ab7323351bacf02d82af79921df1d6594969 [11:42] tseliot, i presume thats not slated for .37 but for .38-rc1 given its on the drm-next branch [11:42] tseliot, it doesn't sound like its expected to fix anything? waht you hoping for from it? [11:43] apw: I need to test evergreen urgently but I guess I'll just settle with 2.6.37-rc5 and hope that it works [11:44] tseliot, well i would suggest you start with that yes, that is in the current natty kernel [11:44] apw: ok, thanks [11:44] * tseliot -> lunch [11:50] apw: http://people.canonical.com/~cjwatson/tmp/grub2/ <- haven't tested those specific binaries but ... [11:52] cjwatson, do you have any amd64 binaries? [11:52] though i guess as the source is there i can make my own [11:59] afraid not === jjohansen is now known as jj-afk [12:57] cjwatson, the kernels are here: http://people.canonical.com/~apw/handoff-renumber-natty/ [12:58] and man does it take some cycles to build grub2 [12:58] yeah, it's all the platforms [13:05] apw: is that ABI-compatible with 2.6.37-9.22? [13:06] cjwatson, it should be yes, the code change should not be a bumper [13:08] * apw finally has some amd64 binaries ... woh [13:11] I wouldn't mind being able to get plymouth to fade in the logo over a period of a second or so, at some point :) [13:13] cjwatson, blank is a little odd, i suspect they are not going to be happy [13:16] cjwatson: what are your plans for Natty? Are you going to set the bootsplash in both grub and in plymouth? [13:17] * tseliot is wondering whether grub will use keep_payload [13:17] cjwatson, i note it asked if i wanted your /etc/default/grub file and i said yes, and yet, it maintained some of my changes, specifically to the options on the kernel command line ... was i expecting that? [13:17] apw: there's some ucf configuration file merging going on there [13:18] apw: I thought you said the design team said a purple background was fine? [13:18] tseliot: current plan (testing with apw at the moment) is to set plain background in grub and have plymouth draw the logo [13:18] tseliot: but match up the colour in grub so that it doesn't look like a black screen [13:18] cjwatson, oh don't get me wrong, they did say some colour would be better, and that was my impression ... BUT once they _see_ it you know what happens every time [13:19] apw: yeah - we'll see [13:19] tseliot: grub is already using gfxpayload=keep in natty [13:19] cjwatson, it does transition pretty nice, but i think they will be unhappy none the less [13:19] apw: well, the option to set an image is still there [13:19] cjwatson: are you using vesafb? [13:19] we'll try this first and see [13:19] cjwatson, yeah [13:20] tseliot: grub will enter the kernel in a VBE mode [13:20] cjwatson, its a major step fwd, and wonderful compare to win7 [13:20] tseliot: I understand this will normally involve vesafb being there to start with [13:20] on the same machine [13:20] that's interesting [13:20] though of course it's OS X they're actually comparing with ;-) [13:20] I guess I'll have to talk to AMD and NVIDIA so as to make sure that their drivers work correctly as they used to have problems with gfxpayload=keep [13:20] cjwatson, heh yeah indeed. when i boot win7 on this netbook i have a nice bit of cylon for about 10s, then about 40s with the backlight off [13:20] tseliot: yes please! we have a PCI ID blacklist facility as a stopgap [13:21] apw: though actually, IIRC OS X has solid grey background briefly during boot [13:21] cjwatson, perhaps we should be grey then :) [13:21] it's been a while and the machine with OS X on here is currently unhappy with life [13:22] cjwatson, does this 'draw' the purple? it seems faster than before with an img [13:22] cjwatson: ah, so we could do something like "if nvidia, no gfxpayload"? This would blacklist the open driver too though [13:23] tseliot, i think the rule should be if the packages are installed for nvidia or fgrlx [13:24] cjwatson, now we need to get plymouth to cope with the drm framebuffer appearing in the middle of it doing its thing [13:26] apw: ok, that would doable [13:26] *be [13:27] tseliot, yeah? as currently for me, it sees the vesafb and paints that, then drm appears and mode switches [13:27] tseliot, and then i have blank till X takes over [13:29] apw: with what card/driver? [13:29] tseliot, its some intel thingy here [13:30] tseliot, a basic atom based model [13:30] tseliot, its possible that its actually that X cannot handoff from vesa ... not sure how to tell [13:30] apw: my " that would doable" was in reply to what you said about nvidia and fglrx [13:30] tseliot, ahh [13:30] ignore me then [13:32] apw: if you're seeing a resolution change I guess it's inevitable that the splash is broken [13:32] tseliot, yeah, the panel is not a native VBE mode, so there is inevitably a res change i believe [13:32] cjwatson, ^^ sound right on a netbook? [13:34] cjwatson, oh i meant to ask ... are we displaying the menu by default now? or has that carried over and i need to undo that change manually [13:37] apw: if there's a mode switch I guess it's better if plymouth redraws the background [13:38] tseliot, yeah i think thats what is needed, i hear it just core dumps right now :) [13:38] oh [13:41] tseliot: I'd rather be a bit more delicate than that, since I've had reports of nvidia systems working fine [13:41] apw: the flood-fill is quicker than an image fill - there's optimised code for it [13:41] apw: right, the framebuffer switch is as yet unhandled ... [13:41] apw: resolution change> depends on the BIOS [13:42] apw: we're not displaying the menu by default, no [13:42] cjwatson, am pretty happy with the way it looks to me regardless ... i can cope with a blip to black [13:42] cjwatson, menu> ok so that carried over will try and undo it :) [13:42] VESA BIOSes vary a lot. I'm particularly unimpressed with my laptop listing a preferred mode that doesn't appear in its mode list [13:42] cjwatson: yes, of course I'll try to convince them to get their driver to work properly with our grub first [13:44] tseliot: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/686070/comments/4 for instance says it all works fine with the proprietary driver [13:44] Launchpad bug 686070 in nvidia-graphics-drivers (Ubuntu) (and 2 other projects) "black screen (no more gdm/X server) with nvidia propriatery after gfxpayload=keep activation (affects: 2) (heat: 14)" [Undecided,Invalid] [13:45] cjwatson, ok that looks pretty nice to me, but who am i to argue with design [13:45] cjwatson, i am seeing what appears to be tiling issues with the plymouth text at the bottom [13:45] cjwatson: ah, thanks for the link [13:49] apw: tiling issues? [13:49] cjwatson, thats my interpretation, clearly the text for an fsck or similar, and clearly not right at all, messed up pixels in the rows, like its thinking its tiled and its not [13:51] apw: sounds like another symptom of failing to deal with the fb switching over? [13:51] cjwatson, yeah could be indeed [13:52] cjwatson, suspect we need a plymouth expert on the case [13:52] * apw looks for james :) [13:52] so are you going to go ahead and upload the vt.handoff numbering change? [13:53] cjwatson, yeah it will be in the next upload [13:53] How do you download a *.deb file? [13:53] cjwatson, are you wanting me to expedite it? or as it works with a little extra flick do we not care too much [13:53] lag, ? [13:54] apw: I guess I can just upload grub2 in advance of that [13:54] cjwatson, yeah cirtianly no need to hold back cause of the kernel, its close enough [13:55] I'd like to do something like "apt-get download linux-image-2.6.35-24-generic" [13:55] lag, won't apt-get download linux-image-generic trigger the right thing? [13:56] apw: E: Invalid operation download [13:57] apt-get install -d linux-image [13:58] lag, ^^ [13:58] apw: It seemed to download - no idea where the hell it went :) [13:58] /var/apt/cache/archives [13:59] Close enough [13:59] /var/cache/apt/archives :) [13:59] lag, so i assume you don't want to install it, you may have it scheduled for install now [13:59] You're a star, thanks! [13:59] Ah, balls [13:59] How do you unschedule it? [13:59] so you may need to remove it again afterwards [14:00] that is a good quesiton [14:00] apt-get remove perhaps [14:00] 'aptitude download' [14:00] err, it shouldn't be scheduled for install just because of 'install -d' [14:01] cjwatson, oh then thats good [14:01] lag, ^^ sounds like -d is good enough [14:01] cjwatson: Ah, I knew I'd seen the 'download' option somewhere - I assumed it was removed from apt [14:01] Sounds that way - thanks chaps [14:01] 'apt-get download' was added in natty [14:01] nice [14:01] apt 0.8.9ubuntu1 [14:02] "apt-get install --download-only" would work as well [14:03] It's okay, I have my *.deb now :) [14:04] bguthro: yes, apw said that above [14:04] (-d is short for --download-only) [14:04] cjwatson: apologies, I realized that after I hit 'enter' [14:25] https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/683605 [14:25] Launchpad bug 683605 in util-linux (Ubuntu) "kernel hibernate signature has changed from S1SUSPEND to LINHIB0001 (affects: 3) (dups: 1) (heat: 236)" [Undecided,New] [15:02] brb, need more coffee [15:09] apw, https://bugs.launchpad.net/bugs/690190 [15:09] Launchpad bug 690190 in linux (Ubuntu Natty) (and 1 other project) "HP Mini 10, i915, ftrace faulted on writing [] video_output_register+0x1c/0x12c [output] (affects: 1) (heat: 6)" [Undecided,New] [15:27] I just started getting ftrace faulted on writing [] ahci_softreset+0xf/0x4e0 [libahci] every boot in the last few days too [15:31] Sarvatt, we're beginning to think this is the RO/NX patches (again) [15:35] oh good point, http://www.gossamer-threads.com/lists/linux/kernel/1309290?do=post_view_threaded [15:36] bug 669399 seems to be a dupe of 687750 [15:36] Launchpad bug 669399 in linux (Ubuntu) "Touchpad bottom edge unresponsive in ubuntu 10.10 64-bit (affects: 2) (heat: 20)" [Low,Triaged] https://launchpad.net/bugs/669399 [15:38] bdmurray: yeah thats the bug that led to me sending that synaptics revert to the list, the commit that got SRUed didn't actually fix it for those thinkpad edge's and it needed the further fix === bjf[afk] is now known as bjf === bguthro_ is now known as bguthro [16:27] bjf, whilst you're in a reviewing mood, how about having a look at the maverick-meta SRU I've proposed. [16:28] bug #681727 [16:28] Launchpad bug 681727 in linux-meta (Ubuntu Maverick) (and 1 other project) "linux-backports-modules-wireless-maverick-generic not available for kernel 2.6.35-23 (affects: 9) (heat: 50)" [Undecided,In progress] https://launchpad.net/bugs/681727 === jj-afk is now known as jjohansen [16:29] tgardner, done, looks good [16:30] bjf, thanks [16:31] tgardner, i'm going to be working on that 2.6.35.10 pile [16:31] tgardner, just fyi [16:31] bjf, ejoy [16:31] enjoy even [16:40] <-lunch [17:09] apw: thanks kindly for your help with those updates :) [17:29] kees, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/690190 [17:29] Launchpad bug 690190 in linux (Ubuntu Natty) (and 1 other project) "HP Mini 10, i915, ftrace faulted on writing [] video_output_register+0x1c/0x12c [output] (affects: 1) (heat: 10)" [Undecided,In progress] [17:30] kees, seems that your modules NX patch is still broke [17:30] apw, ah, I was gonna subscribe him to the bug [17:30] tgardner, just did [17:31] apw: yes, there's a fix for that. I will fetch it. [17:31] kees, man ... this code is utter junk :) [17:32] apw: yeah, I agree, we should rip out ftrace. :) [17:32] the kernel has gone way too long without proper memory protections, so there's bound to be pain on this. [17:32] kees, indeed so [17:33] kees, so, you think you have a patch for this particular issue? [17:33] tgardner: I know it for sure, finding the url for it now [17:34] kees, Sarvatt pointed out a fix earlier today, but the code is quite different [17:34] ? [17:34] kees, http://www.gossamer-threads.com/lists/linux/kernel/1309290?do=post_view_threaded [17:35] that's the fix. how is the code different? [17:35] kees, well, a cursory exam of the code in Linus tree appears quite different [17:35] sure, this code is in tip, not Linus's tree [17:36] kees, perhaps we can wait on this until the .38 merge window? [17:36] tgardner: please no; no one else is testing it widely. you always told me to get crazy stuff into the ubuntu kernels asap for wide testing, etc. [17:37] kees, I know, but it _is_ causing a fair amount of grief. [17:37] kees, this fix is over two weeks old ... !!! [17:37] since this issue has a fix, let's just get that in, and see how it stands? [17:37] can you assemble to right commits from tip to fix this? [17:37] apw: yeah, I missed it in my last merge [17:37] kees, got a pointer to an approved patch ? [17:37] http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=shortlog;h=refs/heads/x86/security [17:37] there is much discussion after that [17:38] this is the tip branch. two more fixes are needed (1 is already in ubuntu, 1 is missing, the above url you pasted) [17:38] kees, that tip has less than we do doesn't it ? [17:38] apw: yes, it is missing two fixes. [17:38] kees, so where can we find commited versions of those ? [17:39] (of the second one) [17:39] apw: neither are committed because Gleixner went mia on this topic [17:39] apw: one is our c02d728, the other is http://www.gossamer-threads.com/lists/linux/kernel/1309290?do=post_view_threaded [17:40] kees, ok, lemme look at it again since I have the reproducer. [17:40] tgardner, you'll need to find a version which isn't spanked to death by whitespace dammage [17:41] apw, I know. the patch really just moves a block of code [17:45] tgardner, apw: http://kernel.ubuntu.com/git?p=kees/ubuntu-natty.git;a=commitdiff;h=e90bdb6c9e596fdb3ae56e4fb2868cfbbb49b6f6 [17:46] kees, huh, just about had it coded. I guess I'll get it from your tree. [17:48] tgardner: btw, how did you reproduce that ftrace bug? [17:49] kees, just by booting an HP mini 10 [17:50] what is ftrace doing, I wonder? [17:51] kees, just trying to write some memory in the module. I think apw had it scoped out. [17:51] looks like I get the same one on my aspire one too (the one that can't warm boot with the nx emulation stuff), [ 1.532879] ftrace faulted on writing [] video_output_register+0x9/0x10c [output] [17:52] I'll have a test kernel in 10 minutes or so. we'll know soon enough [17:52] Sarvatt, interesting ... warm boot only for you [17:52] Sarvatt: if you return your BIOS to stock, can you warm boot? [17:53] Sarvatt: I've had testing done on nearly identical hardware and still can't reproduce that bug. :( [17:53] ftrace faulted on writing [] ahci_softreset+0xf/0x4e0 [libahci] on all my non intel machines [17:54] oh hey, I get those warnings about ftrace too. but everything is fine. :P [17:54] Dec 13 20:54:52 gorgon kernel: [ 1.482602] ftrace faulted on writing [] video_output_register+0x1c/0x12c [output] [17:54] kees, it depends which module it gets i think [17:55] kees: sorry I didn't try that first thing but I modified it over 2 years ago and have to figure out how to do it again, don't want to lose AHCI mode :) [17:57] Sarvatt: oh! heh. I thought you'd modded it for hardware NX. [17:57] Sarvatt: because the latest kernels shouldn't need you do mod your BIOS to get hw NX any more. [17:59] s/do/to [18:04] apw, slammed HEAD on Natty master-next [18:06] tgardner, thanks [18:06] apw, perhaps it'll actually build now :) [18:06] tgardner, hehe [18:10] smb, ping [18:11] maybe someone else can answer in smb's absense. https://launchpad.net/ubuntu/+source/linux-ec2 . [18:12] is there a way that i can easily see what needs verification before the lucid-proposed version would get into -updates ? [18:12] smoser, hmm, jfo might be able to help. or look in the changelog for the bug links [18:13] well: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/668380 [18:13] Launchpad bug 668380 in linux (Ubuntu Lucid) (and 1 other project) "Lucid update to 2.6.32.25 stable release (affects: 1) (heat: 73)" [Medium,Fix committed] [18:13] lists dozens of things... so i'm guessing that no one is expecting all those issues fixed to be individually verified. [18:13] smoser, no, only the SRU bugs [18:13] but that bug still has the 'verification-needed' set. wondering overall on the general process here. [18:14] well that is an sru bug [18:14] smoser, yeah, but that bug isn't against -ec2. you need your own tracking bug since -ec2 is a different source package [18:16] well, maybe. (i'm not looking for more work) [18:16] * JFo reads back [18:16] * JFo digs for a link [18:16] but generally, does someone on the kernel team watch over the -proposed kernels ? [18:17] smoser, is the tag 'verification-needed'? [18:17] smoser, smb knows how to drive this one to conclusion. send him an email. [18:17] i need to refresh lucid UEC images, and wondering if i should wait on that -proposed, and thus wondering how long i would be expecting to wait. if its 3 days, i'll wait. if its 15, no. [18:17] err rather... hmmm [18:18] smoser, barring regressions, you should be able to get it promoted by next week [18:18] JFo, yes, that bug that i pointed to has 'verification-needed'. so by normal SRU process, it will not leave -proposed until it says 'verification-done', and someone marks that they've done verification [18:18] ok [18:19] which, for a metabug like that, is generally not going to happen by any single person. so i'm wondering what different process is in place for kernel. [18:19] smoser, but you are looking for those in EC2? [18:19] they're the same for other images also [18:19] ie: https://launchpad.net/ubuntu/+source/linux [18:19] still lists that same bug [18:20] and bug 681132 [18:20] Launchpad bug 681132 in linux (Ubuntu Lucid) (and 1 other project) "Lucid update to 2.6.32.26+drm33.11 stable release (affects: 1) (heat: 160)" [Medium,Fix committed] https://launchpad.net/bugs/681132 [18:20] oh [18:21] JFo, smoser could always add the linux-ec2 source package to that bug [18:21] tgardner, right [18:21] if I understand the question right [18:21] right. (i'm guessing that is what happens in pitti's head before he moves -proposed to -updates) [18:21] so i can do that [18:21] smoser, yep [18:21] but thats not going to get verification actually *done* [18:21] i'm asking how verification is actually done [18:22] cool, I thought you were looking for a link to the tagged bugs such as: https://launchpad.net/ubuntu/+source/linux-ec2/+bugs?&field.tag=verification-needed&field.tags_combinator=ANY [18:22] nope, you need to provide that [18:22] smoser, generally we ask those affected in the bug to test [18:22] well, i can't. as i would suspect that no individual can. [18:22] look at the changes described there. [18:22] smoser, hmmm in that case, I believe we simply test to see if anything related breaks [18:23] smoser, you only need to verify that stable updates have not cause any regressions [18:23] and if not, we consider it "good" [18:23] for loose translations of the word [18:23] right [18:23] what tgardner said [18:23] :) [18:25] so if *I* dont do that, will it get done ? or does that requirement just get ignored and it let into -updates anyway. [18:25] (i represent an extremely small sample set of kernel users) [18:25] tgardner: I'm stepping away for a bit; please let me know if the RO/NX fix works when it's finished building. [18:25] smoser likely not [18:25] sorry, liekly not what ? [18:26] we need some form of acknowledgement that testing for breakage occured [18:26] heh, sorry [18:26] it will likely not get ignored [18:26] read, it won't get done [18:26] i'm just saying, sure, i can use the kernel for a couple hours, and verify it didn't destroy my data, but thats hardly even a useful piece of informatoin. [18:26] in some cases it is all we can get [18:28] smoser, and you think the mainline kernel gets any more testing then that? [18:29] right, most of the time that little bit of feedback is more than they have :) [18:41] kees, apw: ok, that patch appears to have fixed my particular RO/NX issue. [18:41] ok. so, a bit of digging... and i've found that pedro_ from QA team is running tests in lp:qa-regression-testing for this cycle on -proposed kernels. his results for the kernel in question is at http://people.canonical.com/~pedro/kernel/kernel-2.6.35-24.42/ [18:42] smoser, now those are very new :) [18:42] smoser, that is correct, but you're concerned about regressions in a xen hybrid kernel, correct? [18:42] not really, no. [18:43] isn't that what the Lucid -ec2 kernel was? [18:43] i was looking for a general "we run this set of tests, and then mark them verified" [18:43] well, yes, the lucid-ec2 kernel was that. [18:43] and i will now run that set of tests on ec2 and see if anything hits the fan [18:44] apw, I think that RO/NX patch is worthy of an upload. I also pushed an ABI bump [18:44] tgardner, ok i'll so a quick scan and then upload it [18:44] to see if there is anything else we need in there [18:45] apw, how about your grub fix? isn't there a kernel component to that? [18:45] tgardner, yep, i'll just check its in there, and then tie the bows on it [18:46] apw, oh, those are the vt patches, right? [18:46] tgardner, should be yeah. will check they are all thats needed, believe so [18:46] be good to have that out soonest [18:47] apw, ok. if you run out of interest I can do the packaging later today. [18:47] tgardner, will shout if i am bored :) [18:48] apw, well, I was referring more to your EOD, massive beer consumption, general lack of lucidity, etc [18:48] tgardner, heh, i was out to get the car to and from the shop today so my day is a little skewed in your favour [18:49] JFo: got a report from a friend that a lucid kernel update breaks an arduino serial device [18:49] achiang, any bug report on it yet? [18:50] or is he just mentioning? [18:50] achiang, define breaks ... stops being programmed, or slags the device [18:50] JFo: no, shall i file one? the reporter won't be able to do much bisection to help us [18:50] as long as we can get the environment info as well as what apw wants [18:51] we need a good description [18:51] JFo: the knowledge i have is: the usbid / pciid of the breaking device, and the 2 actual kernel revs where it breaks (2.6.32-24.43 good, 2.6.32-25.45 bad) [18:51] cking, did you have an arduino ? [18:51] apw, yep [18:51] why? [18:51] cking, read back about 4 lines [18:51] (from your yep) [18:51] apw: trying to figure out what "breaks" means [18:52] achiang, depending on what cking needs that may be good [18:52] achiang, it is a start :) [18:52] how urgent is it? like I've got more critical bugs than need to be fixed in the next 8 hours than I can remember [18:53] cking: it is not urgent. [18:56] JFo: cool, i've got a test case in C too. [18:56] cking: apw: ^^ [18:56] * achiang will file a bug report. just file against ubuntu-kernel, right? [18:57] * tgardner --> lunch [18:57] achiang, afraid I've only used the USB connector, so I'm not familiar with the serial device on the Arduino. sconklin and hughhalf have Arduino kit [18:58] achiang, against 'linux' [18:58] (if its a kernel issue) [18:59] apw: ok, thanks. although an arduino serial device is a weird, uncommon thing, i wonder if we broke something else in USB. that's my fear [19:01] achiang, indeed, till we know if its more widespread its worrying [19:10] sorry, need to set my client up to ding at me when someone says my name :) [19:10] achiang, looks like apw has you pretty squared away [19:10] JFo: yep, writing report now [19:10] excellent, thank you :) === Sarvatt_ is now known as Sarvatt [19:21] JFo: apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/690798 [19:21] Launchpad bug 690798 in linux (Ubuntu) "arduino USB serial device breaks on lucid kernel upgrade (affects: 1) (heat: 6)" [Undecided,New] [19:23] thanks achiang [19:23] np [20:21] * jjohansen lunch [20:23]