User1: bRoas
User2: User3 http://kernel.ubuntu.com/~sarvatt/patches/116_use_shared_galliumcore.diff actually does work with 8.0 branch, just need to fix up the mesa-egl crap
User3: oh, cool
User2: http://paste.ubuntu.com/823052/ should be the last problem that needs fixing
User3: is this only on the ubuntu branch?
User2: yup
User3: ok, so no need to bug kibi about it :)
User3: oh right, it's due to moving the libs around
User2: maybe ya did something in the merge i'm glossing over and might remember it better :)
User3: you mean i botched the merge? totally plausible
User3: since this shouldn't be any different really
User3: than what it was
User2: oh the mesa-egl crap completely isnt in debian
User2: no wonder it works there
User2: haven't seen that before and thought we inherited it in the merge
User3: well it's possible that I missed something from rules when merging from debian
User2: rules merge looks fine to me frankwright@example.com :(
User3: i bet it's dh_makeshlibs that's to blame
User3: User2 check what's in the mesa-egl/ld.so.conf -file
User2: User3 wait, i just managed to fix it but dont remember what i did
User2: too many context switches
User3: haha
User3: git diff!
User2: reverting this hunk of debian/rules
User2: -       dh_shlibdeps -s -l/usr/lib/$(DEB_HOST_MULTIARCH)/mesa:\
User2: -/usr/lib/$(DEB_HOST_MULTIARCH)/mesa-egl
User2: +       dh_shlibdeps -s \
User2: +               -l/usr/lib/$(DEB_HOST_MULTIARCH)/mesa:\
User2: +               /usr/lib/$(DEB_HOST_MULTIARCH)/mesa-egl
User3: uh oh
User2: yay she built
 * Sarvatt does a happy dance
User3: of course
User3: stupid me
User2: -rw-r--r-- 1 sarvatt sarvatt 4.5M Jan 30 21:19 libgl1-mesa-dri_8.0.0+git20120126+8.0.19f88670-0ubuntu0sarvatt_i386.deb
User2: it grew almost 2MB though
User3: and all that for making it a tad nicer looking :)
User2: still better than the 27MB one without dricore and galliumcore
User2: i'll fix it in git
User3: cool
User2: User3 so mesa's good to go after the merge :)
User3: eeexcellent
User2: merge now or wait for vdpau stuff to go in ya think?
 * Sarvatt would prefer not bothering with vdpau because mesa's build system is already so freaking fragile but oh well
User4: +1
User4: does any app actually use these shiny video apis?
User3: yeah maybe postpone it for now
User3: sure does, but dunno how the gallium drivers work
User3: at least nvidia blob vdpau is widely used (on my PVR for instance ;)
User2: i have no clue either
User2: (if it even works)
User2: User3 oh yeah, you said you had a problem with xa on amd64? i'm building on i386 so didnt notice that
User3: maybe I didn't, can't remember anymore
User3: *did
User5: I we've had some inquiries about whether or not we support vdpau/vaapi; while there's not *that* much that uses it right now, there does seem to be a reasonably complete gstreamer element with support.
User2: User5 you use ati at all to test it?
User2: oh actually I have an ati in a desktop I run headless, can test it out there
User5: I do have an ATI to test it; I need to spin that machine up anyway, to update it.  It'll take *some time*
User2: ah no worries, vdpau stuff isn't in git
User5: What cards does it run on, anyway?
User2: doing the wayland merge
User2: User5 I dunno at all
User5: :)
User2: will look after this, imagine just radeon/nouveau
User2: r300+
User5: Oh, I mean: what chip generations.  Good, my 5450 should cover that :).
User2: should the wayland update wait until after A2 too?
User2: the wiki says soft freeze in effect today but haven't seen any announcements
User2: well yesterday for RAOF :P
User3: wayland is not on the images, so it shouldn't matter
User3: what about libxcb?
User3: it surely is :)
User5: The archive still seems to be open; go for it.
User1: 1177    root         root            1      0.11s       1.34s       172K        0K         0K         0K    --       -     R        1      75%     Xorg
User1: this isn't normal :S
User6: User3 Hey, I heard you wanted a Workstation Key?
User6: Anybody else want one (or Fusion for that matter)?
User3: User6 well, I could test the new stuff yeah
User6: Ok, I'll fix one for you.
User3: I only have precise to run it on though
User6: which hw/driver?
User3: intel
User3: sandybridge
User6: 7.10, 7.11 or 8.0?
User3: oh mesa? 7.11 for the time being, hopefully 8.0 tomorrow
User6: I actually had a reports of 7.10 being slow on sandybridge, 7.11 and 8.0 should be fine.
User6: Oh you are probably good.
User3: as long as the kernel module builds on 3.2 ;)
User2: yeah thats typically the problem I run into, hunting down kernel patches :)
User2: patches so the guest additions build against newer kernels i mean
User6: Running w/o tools work fine, if I have problems its with the host kernel modules Workstation wants to build.
User5: I could do with a key, if you'd like me to test stuff :)
User6: Just WS or does anybody want a Fusion key as well?
User6: Then again I guess nobody here runs Mac on thier computers ;)
 * Sarvatt paid for fusion, its actually decently priced :)
User6: Yeah
User6: WS is a wee bit expensive.
User2: thank you for offering though Prf_Jakob
User2: bryce, RAOF, User3 which ppa should I shove new wayland and mesa in?
User2: x-updates?
User7: User5 would it make any sense if that GPU hang i ran into was connected to the weird hsync/vsync issue with GnomeRR? i seem to only see it if i use GnomeRR to switch from internal-display-only to external-display-only
User5: User7 It would indeed make sense; GnomeRR is a wee bit crazy about that.  In particular, it'll switch the CRTC from internal to external, whereas the xrandr tool generally won't.
User3: User2 x-staging imo
User5: It's entirely plausible that GnomeRR exposes a bug that you would be difficult to trigger in any other way.
User3: and 7.11.2 in x-updates?
User2: oh 7.11.2 in x-updates for oneiric would indeed be a good idea
User5: User2 I concur; we might as well continue using x-staging.
User2: alrighty!
User5: I'd *like* 7.11.2 to be suitable for oneiric-updates; I don't know that it is, though. :/
User8: Sarvatt, x-staging sounds good to me too
 * Sarvatt is seriously sick of looking at mesa for tonight so task for tomorrow or something :)
User3: User2 I can shove stuff somewhere too
User3: also, wayland should be good to push straight to precise, right?
User2: still have to adapt all this crap to mesa master to get xorg-edgers building again, major changes in master after automakification
User2: well the merge is pushed to git, it needs a changelog still
User2: we have a pretty huge diff in debian/, this stuff needs to be pushed to debian
User3: multiarch stuff yep
User2: ok got http://kernel.ubuntu.com/~sarvatt/wayland/ and pushed it to git, totally untested until i eat dinner :)
User3: hum, wonder why we've had to add the COPYING.GPL-2 there
User2: User3 wayland isn't in the images? huh?!
User2: oh
User2: forgot edgers is "special" due to newer cairo
User2: wayland-demos will need an update too, rrgh
User2: libwayland0 (= 0.1.0~0.2-0ubuntu3)
User2: that needs some drastic changes and it's in universe though
User2: with the weston rename
User2: are the cd images going to be in crisis mode if they grow 2MB?
User2: thats how much bigger libgl1-mesa-dri is compressed in 8.0
User5: We can see.
User5: :)
User5: Failing anything else, I believe we've got the leeway to grow to 750MB.
User2: i'll see if any of the other packages increased too
User2: http://paste.ubuntu.com/823262/
User2: thats rc2, i just hadnt bumped the changelog yet
User2: 30-Jan-2012 08:28  712M  Desktop CD for 64-bit PC (AMD64) computers (standard download)
User2: oh cool
User5: Yeah; we're already oversize :)
User2: maybe they should stop calling it "CD" on the download page
User2: and saying its a bug that its oversized :P
 * Sarvatt installs newer mesa to his wife's laptop
User2: that's always a good stress test
User2: lots of reports about nvidia-current being hosed in current precise btw
User2: although two of the people hitting it were hit by busted unity-greeter in the end and blaming nvidia
User2: /X
User2: https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/921998 is pretty nasty
ubuntu-x
Ubuntu IRC