[00:12] <manjo> crimsun, you are more than welcome to write :)
[00:12] <manjo> crimsun, git clone git://kernel.ubuntu.com/manjo/kernel-qa.git kernel-qa
[00:12] <manjo> crimsun, and send patches 
[00:12] <crimsun> manjo: ok, I'll try and look at that this weekend
[00:12] <manjo> cool
[00:12] <manjo> crimsun, its all in shell
[00:13] <manjo> and adding a test is pretty easy
[00:13] <manjo> write your shell script that outputs no noise, wrap it up in the test harness and submit the patch 
[00:14] <manjo> crimsun, look at the suspend/resume or graphics test 
[00:15] <crimsun> manjo: thanks for the pointers
[00:15] <manjo> crimsun, :)
[02:55] <smoser> jjohansen, that issue hasn't cleared itself up. the one with bad dependencies in karmic
[02:56] <smoser> bug 520015
[02:56] <ubot3> 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] <jjohansen> smoser: okay, I'll hit up apw and smb when they come online tonight and we will get it sorted out
[02:56] <smoser> i shoudl verify for sure that the recreate is still valid
[02:56] <smoser> but the issue that my builds were having due to it is still present.
[02:57] <smoser> karmic builds end up with 2 -ec2 and 2 -virtual kernels
[11:23] <Wellark> hi! how long does it take for 2.6.31.20 to get from karmic-proposed to main?
[12:32] <apw> Wellark, presumably you mean from -proposed to -updates?
[12:32] <smb> Wellark, As its a big change at least two weeks. And the more feedback there is on the specific bugs the better
[12:33] <apw> Wellark, it cannot move until the various bugs it fixes have been tested and verified by the reporters
[12:33] <apw> you can of course just add -proposed to your sources and get it anyhow?
[14:48] <mozmck> is the karmic kernel really just 2.6.31 with some patches or is it 2.6.31.12 with some patches?
[14:50] <mozmck> or something in between?
[14:50] <smb> Its 2.6.31.7 or .9 with some patches. Depending whether you look on -updates or -proposed
[14:53] <mozmck> 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] <smb> The git tree itself is now at 2.6.31.12 when you take master. Simplest thing to look is Makefile 
[14:54] <smb> EXTRAVERSION is the stable version included
[14:54] <mozmck> oh, duh!  should have thought of that.
[14:55] <mozmck> When I was trying to find out a while back I was looking at the package from the repository.
[17:05] <hallyn> i notice that lucid doesn't have CGROUP_DEVICE enabled in the kernel
[17:06] <hallyn> 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] <cking> apw, ^^
[17:28]  * apw groans
[17:29] <apw> why can't everyone ask for the CGROUP things all at once?
[17:29] <cnd> smb, when you pull from -stable, do you pull all the commits, or do you sometimes leave some out?
[17:30] <smb> apw, That should have been in the stuff you added lately...
[17:30] <apw> hallyn, yeah that seems to be on already
[17:30] <apw> debian.master/config/config.common.ubuntu:CONFIG_CGROUP_DEVICE=y
[17:31] <apw> hallyn, normally the place to ask is here informally and  though is kernel-team email list formally
[17:32] <smb> 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] <apw> cking, can you check if your outputs are muted in alsamixer ... all mine were
[17:32] <hallyn> apw: hmm, i just installed a lucid image this morning and it didn't have it - recon' i have to update?  
[17:32] <apw> headphone and speaker channels on MM
[17:32] <cking> apw, checking...
[17:32] <cnd> smb, ok
[17:32] <apw> thats from the config for lucid
[17:33] <hallyn> apw: ok, thanks
[17:33] <hallyn> (upgrading right now)
[17:34]  * hallyn makes a note of the path debian.master/config/config.common.ubuntu for future ref
[17:36] <cking> 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] <cnd> 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] <ubot3> 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] <smb> cnd, err sorry I am a bit lost
[17:44] <cnd> smb, don't worry
[17:44] <cnd> just an aha moment for me
[17:44] <smb> aha
[17:44] <smb> ;)
[17:57] <apw> cnd cool ...
[18:10] <hallyn> 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] <hallyn> (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] <apw> CONFIG_CGROUP_DEVICE=y
[18:11] <apw> in my insgtalled config
[18:11] <apw> hallyn, how are you checking if it is available
[18:12] <hallyn> $(*&R%(*$&
[18:12] <hallyn> wrong install cd
[18:12] <hallyn> so sorry...
[18:13] <apw> [    0.013607] Initializing cgroup subsys devices
[18:13] <hallyn> yeah, apparently i installed karmic.
[18:13] <apw> for karmic the changes are not yet in any pocket, they are still out for review
[18:13] <apw> now what the heck that does for me is another question
[18:13] <hallyn> which?
[18:13] <smb> They will be uploaded but that is not before this proposed is done
[18:14] <hallyn> all right, sorry about that, guys, i'm off to install the right *$&(*%& cd.
[18:15] <apw> lol
[20:00] <smoser> jjohansen, ping
[20:00] <smoser> i just did a 'apt-get --purge remove linux-image-2.6.31-302-ec2' and get an error: 
[20:00] <smoser> 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] <smoser> 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] <matti> Not really and error ;] Unless you expect this to be deleted as well.
[20:01] <smoser> well, the content in it is 
[20:01] <smoser> $ ls /lib/modules/2.6.31-302-ec2
[20:01] <smoser> modules.alias.bin  modules.dep.bin  modules.symbols.bin
[20:01] <smoser> 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] <matti> ;]
[20:28] <ogasawara> 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] <smoser> ogasawara, ok. this was on karmic, and obviously of an older package (-304 is now in -updates)
[20:30] <ogasawara> smoser: did -304 resolve the update issue you reported?
[20:30] <smoser> hmm.. no. just checked.
[20:31] <smoser> $ dpkg-query --show linux-image-2.6.31-304-ec2
[20:31] <smoser> linux-image-2.6.31-304-ec2	2.6.31-304.10
[20:31] <smoser> that demonstrates the issue
[20:40] <smoser> ogasawara, ^^ do you want me to open a bug ?
[20:40] <ogasawara> 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] <bryceh> apw, sconklin, drm discussion on #dri-devel if you're around.  airlied thinks option #2 is the only sensible one to consider
[21:12] <cnd> sconklin, by backporting .33, you're talking about the entirety of .33 drm, not just nouveau, ati, and intel?
[21:13] <sconklin> 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] <sconklin> And the X people will handle their part.
[21:14] <cnd> 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] <sconklin> 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] <cnd> yeah
[21:14] <tjaalton> best to pull it all in
[21:14] <sconklin> I think we should try to take it all
[21:14] <cnd> agreed
[21:14] <cnd> I thoguht .33 was required for nouveau as well, anyways
[21:14] <tjaalton> yes
[21:15] <sconklin> it's the piecemeal nature of the current backporting situation that makes it risky and painful - we want to minimize that
[21:15] <cnd> for lucid, are we targetting nouveau ddx or 3d as well?
[21:15] <sconklin> and Lucid kernel would then be able to support Wayland, which some people are interested in
[21:15] <tjaalton> 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] <tjaalton> cnd: no 3d
[21:15] <tjaalton> that'd need mesa 7.89
[21:15] <tjaalton> 7.8*
[21:16] <tjaalton> or maybe the classic dri for the old chips, dunno
[21:16] <cnd> tjaalton, so I assume that's probably for lucid+1?
[21:16] <sconklin> all this needs to be run by apw of course
[21:16] <tjaalton> cnd: yes. though fedora has it I don't think they want bugreports from us :)
[21:16] <tjaalton> at least that's the current upstream policy about nouveau 3d
[21:17] <cnd> ok
[21:17] <bryceh> cnd: we may put it in a ppa or something
[21:17] <bryceh> cnd, seems like a perfect thing to provide in xorg-edgers for example
[21:17] <cnd> bryceh, I might actually be interested in helping with that
[21:17] <bryceh> cnd, cool
[21:18] <cnd> 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] <tjaalton> sure
[21:18] <cnd> oh wait, I'm getting ahead of myself...
[21:18] <bryceh> cnd, are you experienced with packaging?  touch base with the other xorg-edgers fellows on ubuntu-x
[21:18] <cnd> nouveau doesn't support 9400m yet
[21:19] <cnd> or at least not when I last tried
[21:19] <bryceh> cnd, particularly RAOF and sarvatt
[21:19] <cnd> bryceh, I've got my own ppa for rinputd, my side project I've been working on
[21:19] <cnd> so I've got a bit of experience
[21:19] <bryceh> cnd, excellent
[21:20] <cnd> 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] <sconklin> bryceh: I'll make a response to the current "Status of kernel X drivers" thread and cover what we just discussed.
[21:23] <bryceh> sconklin, great
[21:23] <bryceh> sconklin, yeah I think this will simplify a lot of different things (packaging, testing, bug upstreaming)
[21:24] <bryceh> sconklin, and having lbm for .34 stuff will address the concern that upstream will stop focusing on .33 after a time
[21:26] <RAOF> As long as .34 lbm does not contain nouveau, or we revert the API break it would introduce.
[21:26] <sconklin> bryceh: yes. and honestly, spending effort backporting .33 makes more sense than wading into a pile of backports for individual features
[21:27] <tjaalton> RAOF: why not include it from the start?
[21:28] <cnd> hmmm... I see someone else with exact same hw as me got nouveau to work 4 days after me
[21:28] <RAOF> 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] <cnd> maybe it'll work now
[21:30] <RAOF> tjaalton: It *would* make cherry picking fixes easier.
[21:30] <tjaalton> RAOF: we'll be backporting from there anyway, so sooner or later some nouveau fix will need that commit
[21:30] <tjaalton> or need backporting
[21:30] <tjaalton> uh
[21:30] <tjaalton> I mean, more work to backport
[21:30] <bryceh> ahh cnd == chase douglas
[21:31] <cnd> yep!
[21:31] <cnd> we shook hands in portland
[21:31] <bryceh> cnd, ok sorry for my lame question about if you knew packaging ;-)
[21:31] <cnd> well, it's not really that lame
[21:31] <cnd> I didn't know packaging until a few months ago :)
[21:31] <RAOF> tjaalton: Yeah.  It wouldn't be too long before we ran into something that touched that commit.
[21:32] <bryceh> cnd, :-)
[21:32] <cnd> bryceh, I've been doing rpm packaging at IBM for a few years though
[21:32] <RAOF> 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] <cnd> so just a shift in process :)
[21:32] <bryceh> RAOF, I've got libdrm 2.4.18 on my todo list to merge either with or without the API change
[21:32] <tjaalton> 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] <cnd> RAOF, so does that mean just boot into lucid, install Sarvatt's packages, and there *could* be 3d support?
[21:33] <cnd> or is something else needed?
[21:34] <RAOF> cnd: Just that.  Install, boot, run.
[21:34] <cnd> bryceh, looks like your suggestion has already been done :)
[21:34] <RAOF> 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] <cnd> hmmm... what do I have again?
[21:35] <RAOF> Geforce 8 or newer?  nv5x.
[21:35] <RAOF> 6/7 - nv4x
[21:35] <cnd> geforce 9400m
[21:35] <cnd> so that sounds good
[21:35] <RAOF> In your swankypants shiny macbook, yes.
[21:35] <cnd> I'll probably try that later on
[21:35] <cnd> heh :)
[21:35] <RAOF> While everyone's here, we also need to work out where the hook for installing nouveau.ko in the initramfs.
[21:36] <RAOF> Ahem.  Should go.
[21:37]  * bryceh lunching
[21:37] <RAOF> 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.