| === yofel_ is now known as yofel | ||
| danvet | dear lazyirc: where's the preferred place to pre-discuss a few topics of the tools-and-processes blueprint for uds? | 12:22 |
|---|---|---|
| danvet | more specifically: bringing kernel patches quicker to testers | 12:23 |
| * danvet is a drm/i915 upstream hacker | 12:24 | |
| tjaalton | danvet: hey, got a link to the blueprint? | 12:25 |
| danvet | tjaalton, https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-xorg-tools-and-processes | 12:26 |
| danvet | hm, should I edit the whiteboard? | 12:27 |
| * danvet has no clue | 12:27 | |
| tjaalton | well, this is the best channel for discussion, i guess :) | 12:30 |
| danvet | ok, here we go: the problem upstream is having is a massive testing turn-around-time mismatch between the kernel stuff and userspace | 12:32 |
| tjaalton | yeah | 12:33 |
| danvet | thanks to xorg-edgers ppa, stuff gets tested essentially within days even by users who can't compile | 12:33 |
| danvet | kernel patches up to 6 months (and more) to progress from -next to the testers boxes | 12:33 |
| danvet | for features which cross kernel/userspace we routinely end up discovering bugs a few months after stable releases of the corrensponding userspace part is already out the door | 12:34 |
| danvet | when the fix can only properly be done in userspace, this is a problem | 12:35 |
| danvet | so the question is: what's need to bring the drm-next testing turnaround-time down to the level of the userspace components? | 12:36 |
| danvet | just delaying userspace releases doesn't sound great ;-) | 12:36 |
| tjaalton | there should be a kernel with drm-next already iirc, though I don't know how often it's updated | 12:37 |
| danvet | well, part of it is certainly there, but likely not yet good enough | 12:38 |
| tjaalton | true | 12:39 |
| danvet | ideally is should be more-or-less in lockstep with the xorg-edgers ppa | 12:40 |
| tjaalton | we've talked about creating tools that build a new kernel with a given (set of) commit(s) | 12:40 |
| danvet | yeah, that's been my idea, too: a kernel tree base on latest stable with the most recent drm-next stuff added in | 12:40 |
| danvet | then fry xorg-edgers with it ;-) | 12:40 |
| danvet | question is: what support does ubuntu have for such a thing and what should/must upstream provide? | 12:41 |
| danvet | preferably fully automated ;-) | 12:41 |
| tjaalton | hmm, i think these questions are better suited for #ubuntu-kernel, I'm not well versed in those tools yet | 12:42 |
| tjaalton | there's certainly enough horsepower to rebuild new kernels, but how to integrate it with edgers & lp is beyond me | 12:43 |
| tjaalton | apw: ^ | 12:43 |
| tjaalton | Sarvatt should be online in a couple of hours too, he's the one making edgers rock | 12:43 |
| danvet | well, I think the essential part is xorg-edgers integration. the problem is the mismatch between components, not necessarily slow turn-around ... | 12:44 |
| danvet | tjaalton, is #ubuntu-x logged somewhere? | 12:45 |
| * danvet is too lazy to retype it ... | 12:45 | |
| tjaalton | danvet: yep, irclogs.ubuntu.com | 12:45 |
| danvet | tjaalton, ta | 12:46 |
| tjaalton | looks like edgers already has a kernel, though it's not actively maintained | 12:47 |
| tjaalton | well, obviously | 12:48 |
| apw | tjaalton, are you asking for a kernel from drm-next uploaded into xorg-efgers as it changed | 12:48 |
| tjaalton | apw: yeah, something along those lines | 12:48 |
| apw | tjaalton, we do upload other source packages to pre-proposed for instance, may be possible with those hmmm | 12:48 |
| tjaalton | apw: the current devel version + drm-next. or the current stable one + drm-next, whichever is less prone to break during build :) | 12:48 |
| apw | they tend to not have ubuntu specific patches which is the issue | 12:49 |
| tjaalton | i meant the current ubuntu devel/stable version | 12:49 |
| danvet | so it would need latest ubuntu kernel for that relase + drm-next patch? | 12:51 |
| tjaalton | probably would be the least pain for the tester | 12:52 |
| danvet | yeah, the real drm-next contains linus -rc stuff so more chances for (unrelated) breakage | 12:52 |
| danvet | which probably reduces the testers willingness to fry their box | 12:52 |
| tjaalton | indeed :) | 12:58 |
| Sarvatt | -rw-r--r-- 1 root root 11M 2011-04-30 18:08 r300_dri.so | 17:19 |
| Sarvatt | -rw-r--r-- 1 root root 11M 2011-04-30 18:08 r600_dri.so | 17:19 |
| Sarvatt | yay --enable-gallium-llvm | 17:19 |
| tjaalton | the size? | 17:25 |
| Sarvatt | yeah | 17:26 |
| Sarvatt | -rw-r--r-- 1 root root 3.2M 2011-04-19 06:53 r300_dri.so | 17:27 |
| Sarvatt | -rw-r--r-- 1 root root 3.1M 2011-04-19 06:53 r600_dri.so | 17:27 |
| Sarvatt | gonna need a libllvmcore | 17:29 |
| Sarvatt | will still be a lot of extra space though | 17:30 |
| Sarvatt | (--enable-gallium-llvm is required in mesa 7.11) | 17:31 |
| tjaalton | so we win :) | 17:31 |
| Sarvatt | well we aren't enabling llvm which makes r300g crap for IGP radeons in natty | 17:32 |
| tjaalton | i meant the oneiric cd-size battles.. we have the high ground if it's required in 7.11 :) | 17:35 |
| Sarvatt | hopefully we move to 1GB images and it wont be a big deal :) | 17:42 |
| tjaalton | yep | 17:51 |
| Sarvatt | looks like our plymouth doesn't have http://cgit.freedesktop.org/plymouth/commit/?id=22a1273bb2c9dc0d3188b8ed11b0c97bfca6d3ef yet and I sure as heck dont want to screw with plymouth, I guess leave the linux-any libdrm-intel1 change for the 2.4.25 merge? | 17:57 |
| Sarvatt | ok this is going to take a while, my packaging foo is not good enough to multiarchify libdrm with xsfbs removed without some research :) | 18:07 |
| tjaalton | hehe | 18:09 |
| Sarvatt | x-x-v-intel should probably suggest i965-va-driver eh? | 19:07 |
| bryceh | Sarvatt, tjaalton, RAOF: I've started a workqueue page for oneiric here: http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/workqueue-oneiric.html | 19:26 |
| bryceh | I added 'oneiric' tags to some of the natty bugs that looked to me like they'd be worth continued work on | 19:26 |
| LLStarks | w00t. somebody finally has a gpu switching solution for ALL optimus laptops. | 21:06 |
| LLStarks | mux or no mux | 21:06 |
| danvet | Sarvatt, can you read todays irc log? it contains some discussion about stuff I'd like to bring up at uds ... | 21:09 |
| Sarvatt | danvet: yeah I read it, it sounds good. I'd like to know what'd be most useful, I could always throw crack kernels in there but I try to keep things working and there is a lot more than just intel in there. I'm thinking a crack kernel with an optional metapackage that can be installed to automatically pull in the updates | 21:12 |
| Sarvatt | danvet: usually once the next release archive opens up I start copying the kernel to the older release, and that gets updated every -rc | 21:13 |
| Sarvatt | but I know linus rc's are too old to be useful for you guys working on intel.. :) | 21:13 |
| danvet | Sarvatt, sry, was busy: I was thinking whether restricting the crack to just drm stuff might help | 21:30 |
| danvet | i.e. some automatic rebasing/backporting of drm-next on shipping stable kernels | 21:31 |
| danvet | the fundamental problem is really new kernel interfaces for which userspaces is shipping about 6 months ahead | 21:32 |
| danvet | then when the stuff finally hits stable, we notice that there are problems | 21:33 |
| danvet | hilarity ensues because we can't fix the userspace in the wild anymore | 21:33 |
| Sarvatt | I can get that going for sure, added a work item for it to the blueprint | 21:39 |
| danvet | Sarvatt, cool, getting something going in that direction could be really useful | 21:45 |
| danvet | btw, still a scheduling conflict with linaro-mm, but I hope there'll be another autosched-run | 21:45 |
| bjsnider | ricotz, i guess with gnome 3 the contents of the desktop directory is not actually displayed on the desktop? | 22:15 |
| ricotz | bjsnider, this is disabled by default you can enable the nautilus-desktop-handling with gnome-tweak-tool | 22:26 |
| Sarvatt | bryceh: 119_disable_relaxed_fencing.patch fixed some corruption bugs too apparently | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!