[02:23] when can i get mesa 8.1 in xorg edgers? [02:24] When it consistently builds, I'd guess :) [02:24] oh i see [02:25] wait im looking at the log, and it looks like its building just ine [02:25] https://launchpadlibrarian.net/107031799/buildlog_ubuntu-precise-amd64.mesa_8.1~git20120606.ec19bdd1-0ubuntu0sarvatt~precise_FAILEDTOBUILD.txt.gz [02:26] i mean, i don't see an actual error there [02:26] i'll download it and see if i can coax it... [02:27] That'd be because mesa builds in parallel; you need to scroll a long way up, where you'll see that it's failing to find main/dispatch.h [02:29] oh i see [02:40] well thats an upstream problem [02:40] there is no dispatch at all is that source package ;) [02:40] *dispatch.h [02:40] needs next git version [02:46] that file is autogenerated [02:53] where is the software that checks out from git so i can run it locally? [02:53] cause i just build mesa from git just fine [02:54] oh nvm found it [03:41] ../../../../../src/mesa/libdricore/../main/api_arrayelt.c:45:27: fatal error: main/dispatch.h: No such file or directory [03:41] fffffffffffffffffff [05:14] guess you cant run two mesa's at the same time [06:35] mlankhorst: re; -rendition sync, no it can't since the tarballs don't match [07:40] tjaalton: ? [07:41] tjaalton: no easy way to force it? :s [07:42] no, until there's a new upstream release, which should happen for 1.13 abi [07:44] ok, I'll just manually do it then. [07:45] it's called a fakesync when you take the new version but use our tarball [07:46] with the diff applied it's still the new version then? [07:46] the diff is just the changelog entry [07:47] our diff that is [07:47] so you can take the debian version, bump the revision and build a new package by using our orig.tar.gz [07:55] ok [09:12] RAOF: xorg 1.12 https://launchpad.net/~ubuntu-x-swat/+archive/x-staging/+packages almost done when openchrome and ati are rebuilt [09:36] RAOF: seems to work here with nouveau, I'll try nvidia drivers too [09:55] ok both work [09:57] Woot! Thanks [10:24] RAOF: is this going into quantal or just for testing? :) [10:25] mlankhorst: The packages in the PPA? They'll go into quantal once we've decided that the rest of the madness has settled sufficiently. [10:26] ok :) [10:37] RAOF: in fact could we not wait too long due or alternatively release xserver-xorg-video-nouveau from git to debian-experimental, and sync it? [10:38] Sorry, I don't quite understand what you're saying. [10:38] I think the upshot is that you'd like to sync xservzer-xorg-video-nouveau soon :) [10:38] yeah, I have a fix in debian's git repo too i want to have [10:38] What's libdrm like? The newer nouveau will need the newer ABI, right? [10:39] RAOF: Oh the debian git has a hack for it [10:39] ~ private copy of libdrm-nouveau in the ddx [10:40] Sweet. [14:16] bryceh: Every time I want to leave prime alone some new issue pops up ;) [17:11] hey there, just a quick question for you. I'm currently working on the LXC auto upgrade testing backend to replace our slow Qemu backend for quite a few tests. Obviously after upgrading a desktop system, X tries to start and fails as the container doesn't have any video hardware. [17:11] that's breaking some of our tests as we kind of like having X around. So I was wondering if there's a way of getting X to start but without any hardware or if I should try to dpkg-divert X to Xvfb instead === yofel_ is now known as yofel [17:18] (I tend to prefer dumping an xorg.conf file in my upgraded system rather than moving binaries around to make the system think Xvfb is X) === llstarks is now known as erappleman [21:02] bryceh, regarding the plans to use intel sna in quantal, would hwe take priority over that? airlied expects uxa+nouveau prime offloading to be present in quantal's graphics stack === Azelphur_ is now known as Azelphur [22:59] stgraber: Yes! Install xserver-xorg-{video,input}-dummy in your container's xorg.conf and you'll have a wonderfull headless X server. [23:03] RAOF: sweet, thanks!