=== maxb_ is now known as maxb [00:12] crimsun, you are more than welcome to write :) [00:12] crimsun, git clone git://kernel.ubuntu.com/manjo/kernel-qa.git kernel-qa [00:12] crimsun, and send patches [00:12] manjo: ok, I'll try and look at that this weekend [00:12] cool [00:12] crimsun, its all in shell [00:13] and adding a test is pretty easy [00:13] write your shell script that outputs no noise, wrap it up in the test harness and submit the patch [00:14] crimsun, look at the suspend/resume or graphics test [00:15] manjo: thanks for the pointers [00:15] crimsun, :) [02:55] jjohansen, that issue hasn't cleared itself up. the one with bad dependencies in karmic [02:56] bug 520015 [02:56] Malone bug 520015 in linux-meta-ec2 "bad dependencies on karmic linux-ec2, linux-image-ec2" [Undecided,New] https://launchpad.net/bugs/520015 [02:56] smoser: okay, I'll hit up apw and smb when they come online tonight and we will get it sorted out [02:56] i shoudl verify for sure that the recreate is still valid [02:56] but the issue that my builds were having due to it is still present. [02:57] karmic builds end up with 2 -ec2 and 2 -virtual kernels === hypera1r is now known as hyperair === Wellark1 is now known as Wellark [11:23] hi! how long does it take for 2.6.31.20 to get from karmic-proposed to main? [12:32] Wellark, presumably you mean from -proposed to -updates? [12:32] Wellark, As its a big change at least two weeks. And the more feedback there is on the specific bugs the better [12:33] Wellark, it cannot move until the various bugs it fixes have been tested and verified by the reporters [12:33] you can of course just add -proposed to your sources and get it anyhow? [14:48] is the karmic kernel really just 2.6.31 with some patches or is it 2.6.31.12 with some patches? [14:50] or something in between? [14:50] Its 2.6.31.7 or .9 with some patches. Depending whether you look on -updates or -proposed [14:53] how does one tell? I've got the git tree and have looked in the changelog, but I just see tags like 2.6.31-xx.xx [14:54] The git tree itself is now at 2.6.31.12 when you take master. Simplest thing to look is Makefile [14:54] EXTRAVERSION is the stable version included [14:54] oh, duh! should have thought of that. [14:55] When I was trying to find out a while back I was looking at the package from the repository. === KB1JWQ is now known as PFY === PFY is now known as KB1JWQ [17:05] i notice that lucid doesn't have CGROUP_DEVICE enabled in the kernel [17:06] is there some particular place i should go to request that that be turned on (for whatever release it's feasible for, be that lucid or the next one)? [17:28] apw, ^^ [17:28] * apw groans [17:29] why can't everyone ask for the CGROUP things all at once? [17:29] smb, when you pull from -stable, do you pull all the commits, or do you sometimes leave some out? [17:30] apw, That should have been in the stuff you added lately... [17:30] hallyn, yeah that seems to be on already [17:30] debian.master/config/config.common.ubuntu:CONFIG_CGROUP_DEVICE=y [17:31] hallyn, normally the place to ask is here informally and though is kernel-team email list formally [17:32] cnd, Normally all (until 3 month after release (of a series like Karmic). After that only critical stuff. Though on LTS it will be always everything. Just very very few exceptions. I think once I decided that the upstream change was too much risking regression without need [17:32] cking, can you check if your outputs are muted in alsamixer ... all mine were [17:32] apw: hmm, i just installed a lucid image this morning and it didn't have it - recon' i have to update? [17:32] headphone and speaker channels on MM [17:32] apw, checking... [17:32] smb, ok [17:32] thats from the config for lucid [17:33] apw: ok, thanks [17:33] (upgrading right now) [17:34] * hallyn makes a note of the path debian.master/config/config.common.ubuntu for future ref [17:36] apw, I just needed to pull in some more updates that came in over the past hour or so - audio now OK [17:36] * cking checks skype + BT [17:41] apw, smb, I did more research and found that the card for bug 505808 is actually an r690 part, which is hit directly by the other of the two commits I was looking at [17:41] Malone bug 505808 in linux "Can't boot with last linux kernels from 2.6.32.10 to 2.6.32.12" [Medium,In progress] https://launchpad.net/bugs/505808 [17:44] cnd, err sorry I am a bit lost [17:44] smb, don't worry [17:44] just an aha moment for me [17:44] aha [17:44] ;) [17:57] cnd cool ... [18:10] apw: hmm, after an upgrade i still dont' have CGROUP_DEVICES - i see it shouldve gone in dec 3, is that recent enough to not have made it into updates? [18:10] (or is it being masked by some other file - i don't know how configs are generated) [18:10] * apw is confused, we have no -updates in lucid [18:11] CONFIG_CGROUP_DEVICE=y [18:11] in my insgtalled config [18:11] hallyn, how are you checking if it is available [18:12] $(*&R%(*$& [18:12] wrong install cd [18:12] so sorry... [18:13] [ 0.013607] Initializing cgroup subsys devices [18:13] yeah, apparently i installed karmic. [18:13] for karmic the changes are not yet in any pocket, they are still out for review [18:13] now what the heck that does for me is another question [18:13] which? [18:13] They will be uploaded but that is not before this proposed is done [18:14] all right, sorry about that, guys, i'm off to install the right *$&(*%& cd. [18:15] lol [20:00] jjohansen, ping [20:00] i just did a 'apt-get --purge remove linux-image-2.6.31-302-ec2' and get an error: [20:00] dpkg: warning: while removing linux-image-2.6.31-302-ec2, directory '/lib/modules/2.6.31-302-ec2' not empty so not removed. [20:01] I'm guessing this is something that is not a problem with the other kernel packages (i did not see similar error for -virtual and removed it) [20:01] Not really and error ;] Unless you expect this to be deleted as well. [20:01] well, the content in it is [20:01] $ ls /lib/modules/2.6.31-302-ec2 [20:01] modules.alias.bin modules.dep.bin modules.symbols.bin [20:01] so no, not an error, but those were definitely generated by the package and should be removed with it (and I believe are removed in other linux-image packages) [20:04] ;] [20:28] smoser: I think a fix recently was committed for that issue, can't remember the bug number off the top of my head though [20:29] ogasawara, ok. this was on karmic, and obviously of an older package (-304 is now in -updates) [20:30] smoser: did -304 resolve the update issue you reported? [20:30] hmm.. no. just checked. [20:31] $ dpkg-query --show linux-image-2.6.31-304-ec2 [20:31] linux-image-2.6.31-304-ec2 2.6.31-304.10 [20:31] that demonstrates the issue [20:40] ogasawara, ^^ do you want me to open a bug ? [20:40] smoser: yes please, and let me know the bug #. we can get it on our weekly bug list we'll review on monday [20:55] apw, sconklin, drm discussion on #dri-devel if you're around. airlied thinks option #2 is the only sensible one to consider [21:12] sconklin, by backporting .33, you're talking about the entirety of .33 drm, not just nouveau, ati, and intel? [21:13] cnd: that would remain to be seen. Based on what I know now, I think intel and radeon for sure, and I'll defer to the nouveau experts [21:13] And the X people will handle their part. [21:14] sconklin, I just wonder if there aren't skew issues if we're backporting parts of .33 drm but not all of .33 drm [21:14] For the rest, I think it makes sense to take it all, unless we run into some strange dependencies on recent kernel features [21:14] yeah [21:14] best to pull it all in [21:14] I think we should try to take it all [21:14] agreed [21:14] I thoguht .33 was required for nouveau as well, anyways [21:14] yes [21:15] it's the piecemeal nature of the current backporting situation that makes it risky and painful - we want to minimize that [21:15] for lucid, are we targetting nouveau ddx or 3d as well? [21:15] and Lucid kernel would then be able to support Wayland, which some people are interested in [21:15] the effort done on lbm would not be lost though, since that can be used for pulling proposed patches and letting people test those [21:15] cnd: no 3d [21:15] that'd need mesa 7.89 [21:15] 7.8* [21:16] or maybe the classic dri for the old chips, dunno [21:16] tjaalton, so I assume that's probably for lucid+1? [21:16] all this needs to be run by apw of course [21:16] cnd: yes. though fedora has it I don't think they want bugreports from us :) [21:16] at least that's the current upstream policy about nouveau 3d [21:17] ok [21:17] cnd: we may put it in a ppa or something [21:17] cnd, seems like a perfect thing to provide in xorg-edgers for example [21:17] bryceh, I might actually be interested in helping with that [21:17] cnd, cool [21:18] I only need up to compiz support, so based on phoronix's tests I'm guessing that would be mature enough to play around with in a ppa for lucid [21:18] sure [21:18] oh wait, I'm getting ahead of myself... [21:18] cnd, are you experienced with packaging? touch base with the other xorg-edgers fellows on ubuntu-x [21:18] nouveau doesn't support 9400m yet [21:19] or at least not when I last tried [21:19] cnd, particularly RAOF and sarvatt [21:19] bryceh, I've got my own ppa for rinputd, my side project I've been working on [21:19] so I've got a bit of experience [21:19] cnd, excellent [21:20] but I'm not sure if I'd be the best to work on it if I can't even get nouveau ddx working :) [21:21] bryceh: I'll make a response to the current "Status of kernel X drivers" thread and cover what we just discussed. [21:23] sconklin, great [21:23] sconklin, yeah I think this will simplify a lot of different things (packaging, testing, bug upstreaming) [21:24] sconklin, and having lbm for .34 stuff will address the concern that upstream will stop focusing on .33 after a time [21:26] As long as .34 lbm does not contain nouveau, or we revert the API break it would introduce. [21:26] bryceh: yes. and honestly, spending effort backporting .33 makes more sense than wading into a pile of backports for individual features [21:27] RAOF: why not include it from the start? [21:28] hmmm... I see someone else with exact same hw as me got nouveau to work 4 days after me [21:28] tjaalton: If we're ok with pulling from drm-next (or the nouveau tree itself; I'm not sure if that's been pushed to drm-next yet) and upgrade to libdrm 2.4.18, that'd be fine. [21:28] maybe it'll work now [21:30] tjaalton: It *would* make cherry picking fixes easier. [21:30] RAOF: we'll be backporting from there anyway, so sooner or later some nouveau fix will need that commit [21:30] or need backporting [21:30] uh [21:30] I mean, more work to backport [21:30] ahh cnd == chase douglas [21:31] yep! [21:31] we shook hands in portland [21:31] cnd, ok sorry for my lame question about if you knew packaging ;-) [21:31] well, it's not really that lame [21:31] I didn't know packaging until a few months ago :) [21:31] tjaalton: Yeah. It wouldn't be too long before we ran into something that touched that commit. [21:32] cnd, :-) [21:32] bryceh, I've been doing rpm packaging at IBM for a few years though [21:32] cnd: Sarvatt has, or had, a build of mesa in xorg-edgers which built the nv3x+ nouveau gallium component and the classic mesa driver for older cards. [21:32] so just a shift in process :) [21:32] RAOF, I've got libdrm 2.4.18 on my todo list to merge either with or without the API change [21:32] bbl, testing if blade runner on 1080p looks ok with the optoma :P [21:33] * RAOF wonders if the slightly odd X behaviour he's seeing is because he's got both drm.ko and lbm_drm.ko loaded. [21:33] RAOF, so does that mean just boot into lucid, install Sarvatt's packages, and there *could* be 3d support? [21:33] or is something else needed? [21:34] cnd: Just that. Install, boot, run. [21:34] bryceh, looks like your suggestion has already been done :) [21:34] cnd: Last time I tried nv4x gallium had broken, both from the packages and from git. nv5x gallium seems to be the new sweet-spot :( [21:34] hmmm... what do I have again? [21:35] Geforce 8 or newer? nv5x. [21:35] 6/7 - nv4x [21:35] geforce 9400m [21:35] so that sounds good [21:35] In your swankypants shiny macbook, yes. [21:35] I'll probably try that later on [21:35] heh :) [21:35] While everyone's here, we also need to work out where the hook for installing nouveau.ko in the initramfs. [21:36] Ahem. Should go. [21:37] * bryceh lunching [21:37] Unless nouveau's going to end up in drivers/gpu/drm, we'll need an initramfs hook to pull it onto the initramfs so nvidia users get the same KMS experience as everyone else. And to prevent vga16fb loading, and messing everything up.