=== yofel_ is now known as yofel
[12:22] <danvet> dear lazyirc: where's the preferred place to pre-discuss a few topics of the tools-and-processes blueprint for uds?
[12:23] <danvet> more specifically: bringing kernel patches quicker to testers
[12:24]  * danvet is a drm/i915 upstream hacker
[12:25] <tjaalton> danvet: hey, got a link to the blueprint?
[12:26] <danvet> tjaalton, https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-xorg-tools-and-processes
[12:27] <danvet> hm, should I edit the whiteboard?
[12:27]  * danvet has no clue
[12:30] <tjaalton> well, this is the best channel for discussion, i guess :)
[12:32] <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:33] <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:34] <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:35] <danvet> when the fix can only properly be done in userspace, this is a problem
[12:36] <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:37] <tjaalton> there should be a kernel with drm-next already iirc, though I don't know how often it's updated
[12:38] <danvet> well, part of it is certainly there, but likely not yet good enough
[12:39] <tjaalton> true
[12:40] <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:41] <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:42] <tjaalton> hmm, i think these questions are better suited for #ubuntu-kernel, I'm not well versed in those tools yet
[12:43] <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:44] <danvet> well, I think the essential part is xorg-edgers integration. the problem is the mismatch between components, not necessarily slow turn-around ...
[12:45] <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:46] <danvet> tjaalton, ta
[12:47] <tjaalton> looks like edgers already has a kernel, though it's not actively maintained
[12:48] <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:49] <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:51] <danvet> so it would need latest ubuntu kernel for that relase + drm-next patch?
[12:52] <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:58] <tjaalton> indeed :)
[17:19] <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:25] <tjaalton> the size?
[17:26] <Sarvatt> yeah
[17:27] <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:29] <Sarvatt> gonna need a libllvmcore
[17:30] <Sarvatt> will still be a lot of extra space though
[17:31] <Sarvatt> (--enable-gallium-llvm is required in mesa 7.11)
[17:31] <tjaalton> so we win :)
[17:32] <Sarvatt> well we aren't enabling llvm which makes r300g crap for IGP radeons in natty
[17:35] <tjaalton> i meant the oneiric cd-size battles.. we have the high ground if it's required in 7.11 :)
[17:42] <Sarvatt> hopefully we move to 1GB images and it wont be a big deal :)
[17:51] <tjaalton> yep
[17:57] <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?
[18:07] <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:09] <tjaalton> hehe
[19:07] <Sarvatt> x-x-v-intel should probably suggest i965-va-driver eh?
[19:26] <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
[21:06] <LLStarks> w00t. somebody finally has a gpu switching solution for ALL optimus laptops.
[21:06] <LLStarks> mux or no mux
[21:09] <danvet> Sarvatt, can you read todays irc log? it contains some discussion about stuff I'd like to bring up at uds ...
[21:12] <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:13] <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:30] <danvet> Sarvatt, sry, was busy: I was thinking whether restricting the crack to just drm stuff might help
[21:31] <danvet> i.e. some automatic rebasing/backporting of drm-next on shipping stable kernels
[21:32] <danvet> the fundamental problem is really new kernel interfaces for which userspaces is shipping about 6 months ahead
[21:33] <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:39] <Sarvatt> I can get that going for sure, added a work item for it to the blueprint
[21:45] <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
[22:15] <bjsnider> ricotz, i guess with gnome 3 the contents of the desktop directory is not actually displayed on the desktop?
[22:26] <ricotz> bjsnider, this is disabled by default you can enable the nautilus-desktop-handling with gnome-tweak-tool
[23:57] <Sarvatt> bryceh: 119_disable_relaxed_fencing.patch fixed some corruption bugs too apparently