[06:38] <tjaalton> RAOF: hey, have you had time to test the new mesa with ati yet?
[06:38] <RAOF> Sorry, no.
[06:38] <tjaalton> ok, no worries, I just need to build another test rig for that :)
[06:38] <tjaalton> actually, got one on the floor somewhere..
[06:39] <tjaalton> will test nouveau too
[08:03] <mlankhorst> tjaalton: i think the corruption was due to incorrect drivers and having vesafb loaded before radeon
[08:14] <tjaalton> mlankhorst: which bug?
[08:17] <mlankhorst> tjaalton: well when I did a smoke test on radeon yesterday
[08:17] <tjaalton> ahh ok
[08:17] <tjaalton> I'll reboot this box now to see how it goes
[08:18] <tjaalton> then swap it with gf8600
[08:32] <tjaalton> hd6450 worked
[08:38] <tjaalton> omg it only gave ~59fps in glxgears where gf8600gt gives 1800
[08:38] <tjaalton> so, both work
[08:38] <tjaalton> now only need to fix xatracker linking
[08:49] <Prf_Jakob> yes please
[08:50] <tjaalton> :)
[08:50] <tjaalton> Prf_Jakob: it's missing -ldl and -lm somwhere
[08:50] <tjaalton> actually not -lm
[08:50] <Prf_Jakob> Hmm ok
[08:50] <tjaalton> at least my builds have it
[08:51] <tjaalton> not sure where to add it..
[10:09] <tjaalton> hmm, how do I check if a lib has unresolved symbols?
[10:09] <tjaalton> ie. not linked properly
[10:12] <tjaalton> since with libgallium patch applied libxatracker links to it, but would check if it uses libdl/libm directly
[10:12] <tjaalton> (libgallium is linked to libdl/libm)
[10:13] <jcristau> tjaalton: ldd -r
[10:13] <jcristau> (after the fact)
[10:13] <jcristau> or link with -Wl,-z,defs to make it fail on unresolved symbols
[10:17] <tjaalton> jcristau: thanks
[10:18] <tjaalton> not getting the result I was expecting :)
[10:19] <tjaalton> ldd run on the same system mesa was built on shows libdl & libm, but -r gives unresolved symbols for drm*
[10:20] <tjaalton> it's the same for 8.0.x though, so not a regression \o/
[10:21] <tjaalton> libxatracker1 would depend on libgl1-mesa-dri though because of libgallium, but that's fine I guess..
[10:21] <tjaalton> somehow doesn't depend on libllvm-3.1
[10:22] <tjaalton> libgl1-mesa-dri does, is dh_shlibdeps trying to be clever?
[11:57] <tjaalton> ok, think it's time to upload mesa
[11:58] <tjaalton> or should we split libgallium out of -dri..
[11:58] <tjaalton> mmh, can be done later
[12:07] <tjaalton> huh, fails to sbuild
[12:27] <tjaalton> sigh, parallel building can make it fail
[12:27] <mlankhorst> tjaalton: have you read the upstream comments?
[12:27] <tjaalton> what where?
[12:27] <mlankhorst> on mesa-dev
[12:27] <tjaalton> i know the one email from airlied that got no replies
[12:28] <mlankhorst> meant about libgallium
[12:28] <tjaalton> ah
[12:28] <tjaalton> yes
[12:28] <mlankhorst> so maybe better to drop it for now :)
[12:29] <tjaalton> ok, will disable it
[12:37] <tjaalton> looks like the patch might affect parallel builds too, at least it built without it just fine
[12:44] <mlankhorst> maybe the depends are fucked
[12:44] <mlankhorst> although make loves to eat errors there so I never know for sure if a build succeeds or not :p
[14:23] <tjaalton> testing if weston builds now..
[14:23] <tjaalton> nope
[14:38] <tjaalton> ricotz, Sarvatt: so how have you ignored the test failures in weston on xorg-edgers?`the diff is too large to handle
[14:39] <Sarvatt> http://bazaar.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/view/head:/hooks/weston.patch
[14:41] <tjaalton> ah, thanks
[14:44] <ogra_> tjaalton, not sure you have seen it, rsalveti just uploaded an -omap driver with proper probing support, do you think we could include it in the deps of -all on arm builds ?
[14:50] <tjaalton> ogra_: I uploaded it, but yes sounds good
[14:50] <Sarvatt> hmm wonder if modesetting should be there too
[14:52] <mlankhorst> Sarvatt: it should be there on x86 now at least
[14:52] <Sarvatt> yeah its missing on arm though
[14:52] <mlankhorst> do you know any sane arm then?
[14:52] <mlankhorst> that would support it
[14:53] <Sarvatt> your panda?
[14:53] <mlankhorst> already works with omap driver..
[14:54] <Sarvatt> exynos, displaylink?
[14:54] <Sarvatt> arm might want displaylink support
[14:55] <mlankhorst> oh right
[14:55] <mlankhorst> let me move it to -all then
[14:56] <ogra_> ++
[14:56] <tjaalton> bumping the weston build-deps on mesa bits to 9.0~ sounds sane?
[14:57]  * mlankhorst wonders why ati driver is built on arm..
[14:57] <tjaalton> don't look too closely :)
[14:57] <mlankhorst> is cirrus needed too? would be better with modesetting required..
[14:58] <tjaalton> cirrus on arm?
[14:58] <Sarvatt> i was wondering too and apparently there are arm boards with pcie
[14:59] <Sarvatt> (re ati and nouveau on arm)
[14:59]  * ogra_ isnt sure which insane qemu implementations are out there, might be that there are arm based machines with cirrus ... but unlikely 
[14:59] <ogra_> right, the recent marvell server boards have pcie 
[14:59] <mlankhorst> doubt it has anything resembling vga
[15:00] <ogra_> its not very likely that anyone uses them with graphics cards though
[15:00] <mlankhorst> tjaalton: can we drop cirrus and request modesetting to be used?
[15:00] <tjaalton> mlankhorst: x86?
[15:00] <mlankhorst> any
[15:00] <tjaalton> probably
[15:00] <ogra_> i would leave cirrus, noouveau and ati out of arm
[15:01] <mlankhorst> I think cirrus should be moved out of main to universe :)
[15:01] <ogra_> all arm boards i have seen in my life default to xfbdev anyway ... most of the time going beyond that means an unpackaged binary blob 
[15:01] <ogra_> only for omap and tegra we have exceptions in teh archive yet 
[15:02] <tjaalton> if kvm is now using the kms driver with -modesetting, then yes
[15:02] <tjaalton> not kvm but quantal
[15:03] <mlankhorst> i believe it would be the case, but didn't check yet :p
[15:05] <tjaalton> weston uploaded
[15:11] <mlankhorst> it's doing something
[15:12] <mlankhorst> oh right
[15:18] <mlankhorst> ok this old kernel seems to lack cirrus at least
[15:30]  * mlankhorst gave up on kvm and used qemu straight :)
[15:42] <mlankhorst> virt-manager is a lot harder than kvm -hda quantal-vb.vmdk (originally a virtualbox image)
[16:10] <mlankhorst> tjaalton: after a lot of effort (sigh llvmpipe) it seems cirrus uses modesetting :)
[16:12] <mlankhorst> so I think it could be dropped safely
[16:19] <mlankhorst> ogra_: what is the tegra one then?
[16:21] <ogra_> in the nvidia-tegra package, we're still waiting for an abi 13 release from nvidia (they are workin on it)
[16:22] <ogra_> you dont want that included anywhere 
[16:22] <ogra_> its a binary blob like the x86 nvidia packages
[16:22] <mlankhorst> oh right
[16:23] <mlankhorst> what about omap, is that good enough to move to -all or should it stay in universe
[16:57] <tjaalton> mlankhorst: omap for arm.. that's where you started, right? :)
[16:57] <tjaalton> adding it to video-all for arm
[16:59] <mlankhorst> tjaalton: yeah how do we get it in main?
[17:00] <tjaalton> mlankhorst: ask on #ubuntu-devel I guess
[17:01] <tjaalton> before pushing xorg to the archive, so it won't block installer builds
[17:05] <tjaalton> it won't need a MIR
[17:10] <mlankhorst> ogra_: thanks :)
[17:14] <mlankhorst> tjaalton: feel free to push, mir done
[17:20] <mlankhorst> nm ill hand it off :)
[20:29] <tjaalton> Sarvatt: x11-apps ready for quantal?
[20:30] <Sarvatt> tjaalton: oh it was released, let me fix that, sorry
[20:33] <tjaalton> so it seems, versions_current is lagging behind
[20:34] <tjaalton> the changelog doesn't mention rendercheck :)
[20:35] <tjaalton> non-issue
[20:37] <mlankhorst> bryceh/tjaalton: can we kick cirrus to universe and stop building ati/nouveau on arm?
[20:37] <Sarvatt> oops :(
[20:38] <tjaalton> mlankhorst: yes
[20:38] <tjaalton> kvm was the only reason to keep cirrus around
[20:38] <tjaalton> Sarvatt: don't worry about it :)
[20:39] <mlankhorst> tjaalton: yeah i want to keep it because the old cd i was using didn' t enable it yet, could probably be dropped from main later
[20:40] <mlankhorst> s/main/universe/
[20:41] <bryceh> mlankhorst, yeah
[20:41] <mlankhorst> or leave it in for the release until r :)
[20:42] <mlankhorst> I dumped all my work wrt ttm and dma-buf synchronization on my git tree, friday is last day before vacation :p
[20:42] <bryceh> tjaalton, are you using http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/package_status.html ?
[20:43] <mlankhorst> im not going to check my corporate mail so only if it's really important mail my personal one :)
[20:43] <tjaalton> bryceh: http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/package_status.html
[20:43] <bryceh> fdo has been up and down this past week so that's affected this script, although it *should* be current presently; lemme know if not
[20:44] <tjaalton> mlankhorst: have fun :)
[20:44] <bryceh> tjaalton, yeah I believe those are aliased together; should be same data
[20:44] <tjaalton> bryceh: looks like it yep
[20:44] <mlankhorst> bryceh: all in all looks really green 
[20:44] <tjaalton> I just skimmed through the list to see if there's anything to update before ff
[20:44] <bryceh> mlankhorst, congrats on vaca, how long you going to be gone?
[20:44] <mlankhorst> 2 weeks
[20:45] <bryceh> nice
[20:46] <bryceh> tjaalton, I tuned down the frequency it runs to not impact fdo as much.  Some day I'll rewrite it so it can update from LP more frequently and FDO less frequently, but right now it does all the updates synchronously...
[20:47] <bryceh> it currently updates once every 6 hours
[20:47] <mlankhorst> and after that resync clock for a week then xdc2012 :)
[20:47] <tjaalton> bryceh: yeah that's fine, we're mostly green anyway, and debian is frozen :)
[21:15] <bryceh> I notice we have nvidia-current-updates at 295.49 in precise, but x-updates is up to 304, as is quantal and -edgers.  Should we consider putting that in precise's -updates package?
[21:19] <bryceh> https://launchpad.net/~xorg-edgers/+archive/drivers-only looks like it's no longer used; maybe we should delete that PPA?  ddx-only driver updates aren't really that helpful anymore
[21:20] <ricotz> bryceh, i guess disable should be enough
[21:21] <mlankhorst> bryceh: i think someone already opened a bug for that against -current
[21:21] <bryceh> true; easy enough to revert if someone thinks it's needed
[21:21]  * bryceh switches off the drivers-only ppa
[21:23] <bryceh> mlankhorst, nvidia-current is a binary package so no bugs against it.  I did skim through the nvidia precise bugs but didn't spot anything; let me take a closer look.
[21:24] <mlankhorst> hm current-updates?
[21:25] <bryceh> aha https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-updates
[21:26] <bryceh> bug 1037483
[21:26] <mlankhorst> ah there we go
[21:26] <bryceh> thanks
[21:29] <mlankhorst> g' night :)
[21:31] <bryceh> cya
[21:37] <mlankhorst> 15