| === maxb_ is now known as maxb | ||
| 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:12 |
| 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:13 |
| manjo | crimsun, look at the suspend/resume or graphics test | 00:14 |
| crimsun | manjo: thanks for the pointers | 00:15 |
| manjo | crimsun, :) | 00:15 |
| smoser | jjohansen, that issue hasn't cleared itself up. the one with bad dependencies in karmic | 02:55 |
| 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:56 |
| smoser | karmic builds end up with 2 -ec2 and 2 -virtual kernels | 02:57 |
| === hypera1r is now known as hyperair | ||
| === Wellark1 is now known as Wellark | ||
| Wellark | hi! how long does it take for 2.6.31.20 to get from karmic-proposed to main? | 11:23 |
| 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:32 |
| 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? | 12:33 |
| mozmck | is the karmic kernel really just 2.6.31 with some patches or is it 2.6.31.12 with some patches? | 14:48 |
| 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:50 |
| 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:53 |
| 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:54 |
| mozmck | When I was trying to find out a while back I was looking at the package from the repository. | 14:55 |
| === KB1JWQ is now known as PFY | ||
| === PFY is now known as KB1JWQ | ||
| hallyn | i notice that lucid doesn't have CGROUP_DEVICE enabled in the kernel | 17:05 |
| 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:06 |
| cking | apw, ^^ | 17:28 |
| * apw groans | 17:28 | |
| 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:29 |
| 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:30 |
| apw | hallyn, normally the place to ask is here informally and though is kernel-team email list formally | 17:31 |
| 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:32 |
| hallyn | apw: ok, thanks | 17:33 |
| hallyn | (upgrading right now) | 17:33 |
| * hallyn makes a note of the path debian.master/config/config.common.ubuntu for future ref | 17:34 | |
| 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:36 | |
| 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:41 |
| 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:44 |
| apw | cnd cool ... | 17:57 |
| 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:10 | |
| 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:11 |
| hallyn | $(*&R%(*$& | 18:12 |
| hallyn | wrong install cd | 18:12 |
| hallyn | so sorry... | 18:12 |
| 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:13 |
| hallyn | all right, sorry about that, guys, i'm off to install the right *$&(*%& cd. | 18:14 |
| apw | lol | 18:15 |
| 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:00 |
| 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:01 |
| matti | ;] | 20:04 |
| 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:28 |
| smoser | ogasawara, ok. this was on karmic, and obviously of an older package (-304 is now in -updates) | 20:29 |
| ogasawara | smoser: did -304 resolve the update issue you reported? | 20:30 |
| smoser | hmm.. no. just checked. | 20:30 |
| smoser | $ dpkg-query --show linux-image-2.6.31-304-ec2 | 20:31 |
| smoser | linux-image-2.6.31-304-ec22.6.31-304.10 | 20:31 |
| smoser | that demonstrates the issue | 20:31 |
| 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:40 |
| bryceh | apw, sconklin, drm discussion on #dri-devel if you're around. airlied thinks option #2 is the only sensible one to consider | 20:55 |
| cnd | sconklin, by backporting .33, you're talking about the entirety of .33 drm, not just nouveau, ati, and intel? | 21:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| sconklin | bryceh: I'll make a response to the current "Status of kernel X drivers" thread and cover what we just discussed. | 21:21 |
| bryceh | sconklin, great | 21:23 |
| bryceh | sconklin, yeah I think this will simplify a lot of different things (packaging, testing, bug upstreaming) | 21:23 |
| bryceh | sconklin, and having lbm for .34 stuff will address the concern that upstream will stop focusing on .33 after a time | 21:24 |
| 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:26 |
| tjaalton | RAOF: why not include it from the start? | 21:27 |
| 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:28 |
| 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:30 |
| 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:31 |
| 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:32 |
| * 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:33 |
| 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:34 |
| 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:35 |
| RAOF | Ahem. Should go. | 21:36 |
| * 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. | 21:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!