[00:00] <barry> yep.  waiting for login screen to come back up
[00:00] <barry> hmm, black screen
[00:01] <Prf_Jakob> try to VT switch to a console.
[00:01] <Prf_Jakob> ctrl+alt+f1
[00:01] <Prf_Jakob> If you are on linux, ctrl+alt+space ctrl+alt+f1
[00:02] <barry> i think it's ctrl-fn-command on os x, but nope, it's not switching
[00:02] <barry> i'm still ssh'd in though
[00:02] <barry> *ctrl-fn-command-f1
[00:03] <barry> however:
[00:03] <barry> % lsmod | grep vmwgfx
[00:03] <barry> vmwgfx                121226  2 
[00:03] <barry> ttm                    83595  1 vmwgfx
[00:03] <barry> drm                   275528  3 vmwgfx,ttm
[00:03] <barry>  
[00:04] <Prf_Jakob> sudo service lightdm start
[00:04] <Prf_Jakob> incase doing it from X killed it.
[00:04] <barry> yep, just did that again.  i hear bongos, so i do think it's restarting
[00:04] <Prf_Jakob> Hmm
[00:08] <Prf_Jakob> Anything interesting in Xorg.0.log?
[00:09] <barry> not too much, perhaps this:
[00:09] <barry> [  1104.435] (WW) Warning, couldn't open module modesetting
[00:09] <barry>  
[00:09] <Prf_Jakob> Don't think so
[00:10] <Prf_Jakob> Is 3D enabled?
[00:10] <Prf_Jakob> on the host?
[00:10] <Prf_Jakob> Does it say it has 3d in Xorg.0.log
[00:10] <barry> grep -i 3d /var/log/Xorg.0.log
[00:10] <barry> [  1104.440] (WW) vmware(0): Failed to initialize Gallium3D Xa. No render acceleration available.
[00:10] <barry> [  1104.440] (--) vmware(0): Direct rendering (3D) is disabled.
[00:10] <barry> [  1104.440] (II) vmware(0): No 3D acceleration. Not setting up textured video.
[00:11] <barry> i definitely have Accelerate 3D Graphics turned on in settings
[00:11] <Prf_Jakob> Ok, thats normal if you don't have 3D turned on.
[00:11] <Prf_Jakob> Oh... hmm.
[00:11] <Prf_Jakob> What does it say drm?
[00:12] <barry> % grep -i drm /var/log/Xorg.0.log
[00:12] <barry> [  1104.412] (II) config/udev: Adding drm device (/dev/dri/card0)
[00:12] <barry> [  1104.436] (--) vmware(0): DRM driver version is 2.4.0
[00:12] <barry> [  1104.746] (II) config/udev: Adding drm device (/dev/dri/card0)
[00:12] <barry>  
[00:12] <Prf_Jakob> looks okay
[00:13] <barry> what do you think about adding vmwgfx to /etc/modules and rebooting?
[00:14] <Prf_Jakob> That might work
[00:14] <barry> worth a try i guess ;)
[00:14] <Prf_Jakob> sudo service lightdm stop
[00:14] <Prf_Jakob> sudo killall Xorg -9
[00:14] <Prf_Jakob> might work as well
[00:14] <Prf_Jakob> and then starting it again.
[00:15] <barry> interesting, no Xorg process found
[00:15] <barry> let's try a reboot
[00:17] <barry> % grep -i 3d /var/log/Xorg.0.log
[00:17] <barry> [     8.737] (II) vmware(0): Gallium3D XA version: 1.0.0.
[00:17] <barry> [     8.737] (--) vmware(0): Direct rendering (3D) is enabled.
[00:17] <barry>  
[00:18] <barry> and yep, the llvm-based corruption seems to be gone, as is the tiny fonts on lightdm
[00:22] <barry> Prf_Jakob: i have to go eod now.  i've updated bug 1039157 with what i know so far.  if you have any other debugging suggestions, please comment on the bug and we can chat tomorrow.  thanks!
[00:25] <Prf_Jakob> barry: ok, thanks
[00:25] <Sarvatt> i'll try to figure out why its not auto loading tomorrow, from the looks of it with my old logs x-x-v-vmware actually did the modprobing before though and its not now under xserver 1.13
[00:25] <Prf_Jakob> Yeah, I was thinking about that.
[00:27] <Sarvatt> would be nice to have it modprobed earlier in the boot though so theres a splash, adding it to /lib/udev/rules.d/78-graphics-card.rules might make that happen
[00:28] <Sarvatt> oh vmwgfx doesn't have any modaliases
[00:28] <Sarvatt> thats why its not auto loaded by udev?
[00:29] <Prf_Jakob> Heh, I don't even know what a modalias is :)
[00:30] <Sarvatt> modinfo i915 lists the devices it auto loads from udev for, nothing on vmwgfx even though theres 1 pci id
[00:30] <Prf_Jakob> Ah
[00:31] <Prf_Jakob> What does the splash use btw?
[00:32] <Prf_Jakob> libkms, OpenGL?
[00:35] <Sarvatt> if theres /dev/fb0 it uses that, theres specific backends written for each kms driver, although i think that changed in 12.10 and it uses the newer dumb ioctls. there is a libkms backend for the drm renderer that would work though thats also in 12.04 though
[00:35]  * Sarvatt passes the heck out, sorry to disappear suddenly :)
[06:08] <tjaalton> RAOF: busy with the baby?-)
[06:09] <RAOF> tjaalton: Yeah; Sam's gone out for an appointment, so I'm holding the baby :)
[06:09] <tjaalton> alrighty
[06:12] <mlankhorst> RAOF: ping
[06:12] <RAOF> Pong
[06:12] <mlankhorst> RAOF: you dropped the core patch and are encouraging -core to be passed, how do you pass that by default?
[06:13] <RAOF> mlankhorst: In lightdm
[06:13] <RAOF> mlankhorst: I should see if that's been uploaded, actually.
[06:13] <tjaalton> RAOF: wondering if the libgallium patch should actually be modified to add the gallium stuff in libdricore, if what you said that's what upstream might take
[06:14] <mlankhorst> RAOF: yeah but could that be sru'd for precise somehow for next lts stack?
[06:14] <tjaalton> also, probably no reason to move libdricore out of libdir to libdir/dri
[06:14] <tjaalton> hmm need to add that to debian
[06:23] <RAOF> mlankhorst: Hm, possibly
[06:24] <RAOF> dvorak is poorly optimised for 1 handed typing!
[06:24] <mlankhorst> use a smartphone :D
[06:25] <mlankhorst> or a dumbphone with t9
[06:25] <tjaalton> or get a carrying sling :)
[06:26] <mlankhorst> or use text to speeds
[06:26] <mlankhorst> it shoot laugh your ascend!
[06:28] <RAOF> No irc on my phone :)
[06:29] <RAOF> I can't find the baby sling, either :(
[06:29] <tjaalton> nasty name for that thing btw :)
[06:30] <RAOF> Not for launching babies at all!
[06:31] <mlankhorst> we never said that
[06:31] <tjaalton> :)
[06:31] <mlankhorst> it looks like the stress of parenting is getting to you if you would think we would think about such cruel things
[06:45] <mlankhorst> do you manage to sleep at nights, even?
[06:48] <RAOF> Yeah; plenty.
[06:48] <RAOF> Zoë's pretty good that way.
[06:49] <RAOF> ...and xserver uploaded.
[07:17] <jcristau> upload with one hand?
[07:17] <tjaalton> git push with the other
[07:18] <jcristau> where's the baby then? :)
[07:18] <tjaalton> damn ;)
[07:18] <RAOF> Up in the air.
[07:18] <RAOF> You throw her up, type something, and then catch her.
[07:24] <mlankhorst> RAOF: lucky you, I have to face the wraith of ttm maintainers :)
[07:27] <mlankhorst> which I guess in a way wouldn't be too unsimilar from a crying baby at night
[07:27]  * mlankhorst ducks
[07:33] <RAOF> Heh
[07:45] <tjaalton> hum, trying to build mesa with --with-llvm-shared-libs, but fails
[07:45] <tjaalton> g++  -L/usr/lib/llvm-3.1/lib  -lpthread -lffi -ldl -lm  lp_test_blend.o lp_test_main.o -o lp_test_blend -Wl,--start-group  -L../../auxiliary/ -lgallium libllvmpipe.a -lLLVM-3.1 -lXext -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb -lXxf86vm   -ldrm   -lm -lpthread -ldl -Wl,--end-group
[07:45] <tjaalton> /usr/bin/ld: ../../auxiliary//libgallium.a(u_dl.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
[07:45] <oyvind> bjsnider: Latest nvidia-settings 304.37 for amd64 has failed to build in X updates PPA. Looks like the archive was distributed in a slightly unclean state. Removing objects under src/libXNVCtrl/ in advance should fix the build..
[07:45] <tjaalton> /usr/bin/ld: note: 'dlclose@@GLIBC_2.2.5' is defined in DSO /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libdl.so so try adding it to the linker command line
[07:45] <tjaalton> /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libdl.so: could not read symbols: Invalid operation
[07:46] <tjaalton> oh, and bumping build-deps like llvm isn't nice for backports, I guess
[08:49] <mlankhorst> your libdl is screwed?
[08:50] <mlankhorst> either that or you forgot -ldl :)
[08:51] <jcristau> he has -ldl there twice
[08:51] <mlankhorst> ah
[08:51] <jcristau> and ld even says it found dlclose there
[09:14] <tjaalton> dunno, fedora has a recent snapshot and they use --with-llvm-shared-libs, so wonder why it fails to build here
[09:16] <mlankhorst> tjaalton: well what if you remove one of those 2 and build it manually?
[09:16] <tjaalton> mlankhorst: still the same
[09:17] <mlankhorst> did you remove the first one or the second one?
[09:17] <tjaalton> tried both
[09:17] <tjaalton> doesn't the error suggest that something is wrong with libgallium.a?
[09:17] <mlankhorst> static libraries are weird
[09:18] <mlankhorst> I think you might need to remove the -Wl,--start-group and -Wl,--end-group and keep the last libdl
[09:20] <tjaalton> broke even harder :)
[09:21] <mlankhorst> sigh
[09:21] <mlankhorst> can you send me what you have?
[09:22] <tjaalton> git pull
[09:22] <tjaalton> no wait
[09:22] <tjaalton> merged master and bumped the version to 9.0~git..
[09:23] <tjaalton> there
[09:24] <tjaalton> it was the same error with the previous snapshot
[09:25] <mlankhorst> blegh needs quantal to build, give me a sec
[09:26] <tjaalton> yup
[09:26] <mlankhorst> updating chroot
[09:29] <mlankhorst> ok i seem to get the same error :)
[09:29] <tjaalton> good :)
[09:30] <mlankhorst>  g++  -L/usr/lib/llvm-3.1/lib  -lpthread -lffi -ldl -lm  lp_test_blend.o lp_test_main.o -o lp_test_blend -Wl,--start-group  -L../../auxiliary/ -lgallium libllvmpipe.a -lLLVM-3.1 -Wl,--end-group -lXext -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb -lXxf86vm   -ldrm   -lm -lpthread -ldl
[09:30] <mlankhorst> seems to work
[09:33] <mlankhorst> but I have no idea where the start-group and end-group are inserted..
[09:33] <tjaalton> src/gallium/Makefile.template
[09:34] <mlankhorst> it should be just protecting llvmpipe and lgallium, not the rest
[09:34] <jcristau> isn't that a ld bug?
[09:35] <mlankhorst> possibly
[09:37] <mlankhorst> seems Sarvatt had already reported it as https://bugassistant.libreoffice.org/show_bug.cgi?id=49504
[09:38] <mlankhorst> and duplicate bug had this attached https://bugassistant.libreoffice.org/attachment.cgi?id=65103
[09:38] <mlankhorst> so maybe just cherry pick that?
[09:39] <tjaalton> it's not in master
[09:39] <tjaalton> but if you mean cherry-pick from bugzilla then yes
[09:39] <mlankhorst> yeah :)
[09:40] <mlankhorst> sigh, why do I know such things are a problem even before finding the bugzilla entry :s
[09:43] <tjaalton> ok I'll add that to the debian branch
[09:43] <tjaalton> and do yet-another merge..
[09:43] <mlankhorst> :>
[09:45] <mlankhorst> wish I had something to push to mesa so you'd immediately rebuild again :p
[09:47] <mlankhorst> I can push to most of X now
[09:47] <tjaalton> me too, never abused it though
[09:48] <tjaalton> once had plans to break -sis, but meh
[09:48] <mlankhorst> the trick is you don't want to see it as 'abuse' :)
[09:48] <tjaalton> touch something and you're the defacto maintainer
[09:49] <mlankhorst> hm lets see about virtualbox then
[10:00] <mlankhorst> yay
[10:00] <mlankhorst> virtualbox won't even netboot despite advertising it? o.O
[10:28] <om26er> my screen' dpi is 138 but its always hardcoded to 96 in ubuntu. is there a way I could change that?
[10:28] <om26er> xrandr --dpi 138/eDP1 seems to have no effect
[10:28] <mlankhorst> tjaalton: surprisingly, works here..
[10:29] <tjaalton> mlankhorst: huh, ok
[10:29] <mlankhorst> virtualbox seems to start fine
[10:29] <mlankhorst> although compiz is corrupted if i try
[10:29] <tjaalton> yeah that's the bug then
[10:30] <tjaalton> but is it general llvmpipe-borkedness or something else..
[10:30] <mlankhorst> no idea
[10:31] <tjaalton> check the log :)
[10:32] <mlankhorst> it's using llvmpipe at least..
[10:32] <tjaalton> there you go
[10:32] <tjaalton> so it's fallout from dropping unity2d
[10:32] <mlankhorst> so.. nothing to worry about then?
[10:32] <tjaalton> right
[10:32] <tjaalton> sry :)
[10:32] <tjaalton> but hey, now you have time to fix the libgallium.so build?-)
[10:33] <mlankhorst> probably
[10:33] <mlankhorst> what needs fixing?
[10:33] <tjaalton> don't know what good --with-llvm-shared-libs brought
[10:33] <tjaalton> make the patch apply and build the .so
[10:33] <mlankhorst> oh that
[10:33] <mlankhorst> you know that would mean the whole llvmpipe patch could be dropped, too
[10:33] <tjaalton> but it might be easier(?) to merge it in libdricore
[10:33] <tjaalton> probably so yeah
[10:34] <tjaalton> wanted to see what it did
[10:34] <tjaalton> and don't see much
[10:35] <mlankhorst> will virtualbox be sru'd to precise for .2?
[10:35] <mlankhorst> since the dkms module will no longer build and the xorg one needs an update
[10:36] <tjaalton> nah
[10:36] <tjaalton> vbox users can stay on .1
[10:36] <tjaalton> i mean the stack on .1
[10:36] <mlankhorst> :/
[10:36] <tjaalton> why not?
[10:37] <tjaalton> it's not like the "hw" needs enabling
[10:37] <mlankhorst> still leaves the kernel build failure, though
[10:37] <tjaalton> wait, what?
[10:37] <mlankhorst> if you enable the 3.5 kernel on precise
[10:38] <tjaalton> make it conflict
[10:38] <tjaalton> it's possible today..
[10:38] <tjaalton> breaking the setup that is
[10:38] <mlankhorst> yeah, I'll ask leann
[10:39] <tjaalton> nah, make vbox conflict with the kernels that it doesn't support
[10:39] <tjaalton> easier
[10:39] <jcristau> conflicting with kernels is teh suck
[10:39] <tjaalton> well :)
[10:39] <mlankhorst> but right i don't care enough today, I'll add a point to backports to think about it later
[10:40] <tjaalton> or sth
[10:42] <mlankhorst> yeah
[10:43] <mlankhorst> ok enough caring for now, I'll look at the gallium patch
[10:43] <tjaalton> great
[10:44] <tjaalton> would take more time if I tried :/
[11:00] <mlankhorst> I kind of want to ask raof about it first, i sort of understand the patch but not the reasoning behind it
[11:00] <tjaalton> sure
[11:01] <tjaalton> seems to be having some network issues
[11:03] <mlankhorst>  seems sort of like since it's using libgallium everywhere anyhow, it could just change libgallium.a to libgallium.so and be done with it
[11:15] <mlankhorst> tjaalton: seems a variant of it was already merged though
[11:15] <tjaalton> oh?
[11:16] <mlankhorst> the patch adds --enable-shared-dricore
[11:17] <tjaalton> there's the libdricore support upstream yes
[11:18] <mlankhorst> oh nm it was just from my first partial apply
[11:19] <tjaalton> :)
[11:28] <mlankhorst> can the entirety of libgallium.a be built shared?
[11:30] <tjaalton> no idea :)
[11:41]  * mlankhorst tries a automake hack
[12:27] <mlankhorst> well looks a bit harder to make it shared than I thought
[12:27] <mlankhorst> it's part autotools and part custom makefiles..
[12:33] <tjaalton> yeah :/
[12:40] <mlankhorst> ok next attempt
[13:46] <mlankhorst> more luck now
[13:46] <tjaalton> how much more? :)
[13:46] <mlankhorst> oh as in 'almost feeling confident it links libgallium.so correctly'
[13:47] <tjaalton> cool
[13:48] <seb128> mlankhorst, hey
[13:48] <seb128> + [ubuntu-x-swat] Detect gfx hardware changes (maybe by checking the modaliases?) and inform users about the change: TODO
[13:49] <seb128> mlankhorst, please try to find somebody rather than a team for workitems, team assignments tend to not work, everybody waits on somebody else to pick the stuff up which often never happens :p
[13:50] <mlankhorst> seb128: yeah unfortunately half of my team went to sleep or didn't wake up yet :)
[13:51] <seb128> fair enough ;-)
[14:09] <mlankhorst> tjaalton: I think libtool leads to aggression in a natural way
[14:20] <mlankhorst> yay.. builds static and shared :)
[14:33] <debfx> mlankhorst: virtualbox upstream requires contributions to be licensed under the MIT license. if you can agree to that posting the patch and a license statement to vbox-dev@virtualbox.org would be great.
[14:35] <mlankhorst> debfx: you send it then, copyright belongs to canonical ;)
[14:37] <debfx> mlankhorst: huh?
[14:38] <mlankhorst> I mean unless I'm mistaken since I did it as part of my work for canonical, the copyright belongs to canonical, not me personally :)
[14:40] <mlankhorst> but shrug it should be fine, I'll send it
[14:51] <mlankhorst> tjaalton: blegh is it really worth it building libgallium shared?
[14:55] <tjaalton> mlankhorst: ask the ones who try to keep the cd image under 700M :)
[14:55] <jcristau> those people still exist?
[14:55] <tjaalton> that said, i'm not sure if we have more to use for quantal
[14:55] <tjaalton> not sure
[14:55] <mlankhorst> shrug I think I'm close
[14:56] <tjaalton> seb128: do you know? ^
[14:56] <mlankhorst> some linking error in llvmpipe :s
[14:57] <seb128> tjaalton, mlankhorst: what's the issue?
[14:58] <tjaalton> is the installer image size still 700M
[15:02] <mlankhorst> lets see if it's just llvmpipe breaking..
[15:04] <mlankhorst> woops, probably made all symbols invisible :)
[15:14] <mlankhorst> *amused* even on his homepage ulrich drepper manages to be ulrich drepper
[15:14] <mlankhorst> "If you have problems with this page it probably means you are using a junk browser. Especially the one from the monopolist. Get something better. Use Firefox or Mozilla."
[15:20] <tjaalton> mlankhorst: ok, we have enough space for mesa, so don't worry about the patch anymore. we can fix it later
[15:20] <tjaalton> stash your changes somewhere :)
[15:23] <tjaalton> mlankhorst: i promised to upload it later today, mind giving it a go on some machine if you have some to spare? since I don't know what the llvm-shared-libs actually did, testing some gallium based driver would be great
[15:23] <tjaalton> I have some radeon card to test with
[15:24] <tjaalton> but can't get to the machine until maybe 3h from now
[15:32] <Prf_Jakob> barry: ping
[15:32] <barry> Prf_Jakob: pong
[15:33] <Prf_Jakob> Ah you are here.
[15:33] <barry> yep, how's it going?
[15:33] <Prf_Jakob> fine, haven't done anything more on the bug.
[15:34] <Prf_Jakob> HAve a interface change for mesa that needs to be done before the stable branch is created.
[15:35] <barry> Prf_Jakob: np, the workaround is getting me thru.  i was thinking about changing the bug title to "vmwgfx kernel module not getting loaded by default".  would that be helpful?  (if not, i'll leave it as is)
[15:35] <mlankhorst> tjaalton: ok
[15:36] <mlankhorst> tjaalton: I can stash it, but it seems to be a pain to get it really working
[15:37] <jcristau> bah, speaking of mesa my fix still hasn't made it in.
[15:37] <Prf_Jakob> barry: that is the real issue.
[15:38] <barry> Prf_Jakob: done
[15:38] <Prf_Jakob> thanks
[15:38] <mlankhorst> tjaalton: I can build libgallium.so just fine, it's the linking that's proving to be a pita :)
[15:40] <mlankhorst> tjaalton: but what do you want me to do, test if it works on a radeon card?
[15:40] <barry> Prf_Jakob: thanks for looking into this and helping me out!
[15:41] <Prf_Jakob> np
[15:43] <mlankhorst> tjaalton: hm, seems to be just swrast failing
[15:45] <mlankhorst> but I'll put the changes together into something almost coherent
[15:50] <mlankhorst> ok lets see if those binaries work on quantal :)
[16:24] <tjaalton> mlankhorst: yeah test the non-libgalliuminized (!) version to see it works, i believe intel is mostly fine
[16:33] <mlankhorst> inte's easiest to test for me right now :p
[16:49] <mlankhorst> tjaalton: not getting a desktop, weird
[16:51] <mlankhorst> oh, old kernel
[16:56] <mlankhorst> just some kernel panics on 3.5.0-11 I suppose, nothing really wrong :p
[17:01] <mlankhorst> tjaalton: I have no idea what's wrong with the drivers but glxgears spins fine, so dno..
[17:01] <mlankhorst> it was broken before too, though
[17:04] <tjaalton> hmm, quantal works on snb for me
[17:05] <tjaalton> though the machine has 3.5.0-8
[18:01] <mlankhorst> tjaalton: yeah but it was broken before too, guessing the ddx was screwy instead
[18:02] <tjaalton> ok
[18:10] <tjaalton> uploaded xorg that adds -modesetting to video-all
[18:12] <mlankhorst> yay \o/
[18:12] <tjaalton> had it in git for some time..
[18:24] <mlankhorst> blegh, updating lts-quantal can wait
[18:34] <Sarvatt> tjaalton: modesetting's in universe :(
[18:35] <tjaalton> Sarvatt: yes, informed -release that it needs to be moved to main
[18:40] <tjaalton> ogra_: is it armhf you care about for llvmpipe?
[19:03] <tjaalton> haha
[19:04] <tjaalton> mesa *.install.in totally messed up
[19:07] <tjaalton> hrm, if we're not going to get swx11 back, maybe it would be best to drop the separate 'dri' build target and have sane paths in *.install.in
[19:09] <mlankhorst> tjaalton: we don't know that yet
[19:10] <tjaalton> it's useful on s390
[19:10] <tjaalton> fedora builds it only on that arch
[19:10] <tjaalton> and nothing else, since it has no gfx hw
[19:10] <mlankhorst> and for all we know there is some insane reason to keep it
[19:11] <mlankhorst> if it has no graphics hardware why would you need it? o.o
[19:11] <tjaalton> fine, I'll mess with the .install files then
[19:11] <tjaalton> running apps remotely?
[19:11] <tjaalton> no idea
[19:12] <mlankhorst> after quantal is released there'll be no objection from me to drop it :)
[19:12] <tjaalton> it's dropped already
[19:12] <tjaalton> in git
[19:13] <mlankhorst> meant the separate dri stuff
[19:13] <tjaalton> ok
[19:13] <mlankhorst> but shrug i suppose in worst case you do it now and it turns out we would have to revert that common
[19:15] <tjaalton> ok correction, fedora builds swrast on s390, no swx11 at all
[19:15] <mlankhorst> I retract all my objections :)
[19:16] <tjaalton> right
[19:16] <tjaalton> I'll take the heat to revert the packaging, it isn't that hard
[19:16] <tjaalton> if it should happen
[19:19] <tjaalton> or maybe I'm just a coward and fix the install files instead
[19:20] <mlankhorst> hey for stable releases it's good to be a coward :)
[19:22] <tjaalton> argh
[19:22] <jcristau> tjaalton: i'd prefer to keep swx11.
[19:23] <jcristau> it's still useful if you don't have glx
[19:23] <jcristau> that's for debian, you can do what you like in U :)
[19:23] <mlankhorst> in that case no point in changing the directory off
[19:23] <tjaalton> yeah I kept it there, it should build again soon
[19:24] <tjaalton> either I change the directory, or edit all install.in to copy the stuff from dri/.. to ..
[19:26] <tjaalton> dunno which makes more sens
[19:26] <tjaalton> e
[19:26] <mlankhorst> whatever gives the smallest delta with debian
[19:27] <tjaalton> ok it's easier to revert the install.in
[19:28] <tjaalton> than to retest big changes to rules
[19:36] <mlankhorst> :-)
[19:37]  * mlankhorst always favors the lazy approach
[19:37] <tjaalton> jcristau: what about the libosmesa build? I ripped those targets, but the downside is that the static libs are gone
[19:39] <jcristau> dunno
[19:42] <mlankhorst> tjaalton: libosmesa is still built right?
[19:42] <tjaalton> mlankhorst: yes, but during the dri target build
[19:42] <mlankhorst> ah good :)
[19:43] <tjaalton> and since you can only build either static or dynamic libs, the static ones are now "lost"
[19:44] <tjaalton> same thing with libglut
[19:44] <tjaalton> libglu, whatever
[19:44] <mlankhorst> yeah, just have no idea what libosmesa does, just know wine can use it :p
[19:47] <tjaalton> E: libgl1-mesa-dri: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/dri/i915_dri.so /mnt/src/git.d.o/lib/mesa/build/dri/src/mesa/libdricore/.libs
[19:47] <tjaalton> wth
[19:48] <mlankhorst> shared dricore probably
[19:48] <tjaalton> oh well, needs fixing then
[19:48] <tjaalton> less lintian errors anyway
[19:48] <mlankhorst> yeah usually the autotools relink before install
[19:48] <tjaalton> getting there
[19:49] <mlankhorst> but those specific ones don't autotool
[19:49] <tjaalton> need a break.. ->
[20:27] <ogra_> tjaalton, yeah, dont bother with armel
[21:31] <tjaalton> mesa-8.0-llvmpipe-shmget.patch on fedora. probably worth checking out at some point