[06:27] <RAOF> BAH!
[06:28] <RAOF> Stupid mesa stupid egl damn broken implementations bah.
[06:31] <tjaalton> what's up?-)
[06:43] <mlankhorst> RAOF: oh hey what was the idea behind the shared gallium patch?
[06:44] <tjaalton> no more rpath issues btw, slangasek fixed it
[06:44] <tjaalton> problem was installing the drivers from the build-tree
[06:44] <mlankhorst> ah ofc
[06:44] <tjaalton> so getting close..
[06:50] <tjaalton> unity works on intel, ship it
[06:50] <mlankhorst> :D
[07:04] <RAOF> tjaalton: EGL is broken on !intel because of wayland changes.
[07:04] <RAOF> And I was playing around with some prototype EGL code.
[07:04] <RAOF> And wondering why it wasn't working...
[07:04] <tjaalton> ah
[07:05] <mlankhorst> :D
[07:05] <RAOF> mlankhorst: The shared gallium patch was basically the same as libdricore - take all the static archives in src/gallium and make a shared library out of them, rather than including them in all the gallium drivers.
[07:05] <mlankhorst> oh so I was moving in the right direction then
[07:05] <mlankhorst> I just get troubles at the linking phase now
[07:06] <RAOF> Yeah, it was pretty frustrating.
[07:06] <mlankhorst> have you seen the preliminary patch I created?
[07:06] <RAOF> Ultimately upstream would like to have a monolithic everything_dri.so, as I understand it. That would be a bigger change, but easier to maintain I think.
[07:06] <RAOF> mlankhorst: No, I didn't - is it on the list, or in git?
[07:07] <mlankhorst> git
[07:07] <tjaalton> oh everything_dri.so..
[07:07] <mlankhorst> it fails to link swrast
[07:07] <tjaalton> i wonder what good did llvm-shared-libs bring
[07:08] <RAOF> tjaalton: Not adding ~20MiB of llvm to each and every gallium driver?
[07:09] <tjaalton> ah, ok then
[07:09] <mlankhorst> Cave johnson here, let me tell you something, when I buy a hard disk, I want to use it. None of this sissy dynamic link everything. I paid for the best and I want the best!
[07:10] <tjaalton> hmm that's what we used to have before too, no?
[07:10] <tjaalton> just not it has to be enabled separately?
[07:10] <tjaalton> *now
[07:10] <RAOF> Yeah, we used to patch that in.
[07:10] <tjaalton> heh, ok
[07:11] <tjaalton> that's good then
[07:12] <tjaalton> the drivers are still huge
[07:12] <tjaalton> radeonsi_dri.so is 35M
[07:13] <RAOF> Yeah, that's without libgallium, right?
[07:13] <tjaalton> all the gallium ones are 27-35M
[07:13] <tjaalton> yep
[07:13] <tjaalton> sounds about right?
[07:13] <RAOF> libgallium factors out ~25 MiB of that.
[07:13] <tjaalton> ok
[07:13] <mlankhorst> 25?
[07:13] <mlankhorst> wow
[07:13] <RAOF> Yeah, sounds about right.
[07:13] <mlankhorst> libgallium.so is only 8 mb..
[07:13] <tjaalton> only 2MB here (precise)
[07:14] <tjaalton> oh wait
[07:14] <tjaalton> hehe
[07:14] <tjaalton> the stripped binaries are much more manageable
[07:14] <RAOF> :)
[07:14] <tjaalton> 4-5M
[07:15] <tjaalton> no point in looking in debian/tmp/dri..
[07:18] <mlankhorst> hm weird
[07:19] <mlankhorst> oh great, make can swallow errors
[07:22] <mlankhorst> I think I accidentally got it to work today, I don't know how
[07:22] <RAOF> Heh
[07:29] <mlankhorst> doing one more test run to see if it's really the case
[07:32] <tjaalton> slangasek also told that libxatracker isn't linked properly, it's missing -ldl -lm
[07:33] <mlankhorst> dh_install: dri/usr/lib/x86_64-linux-gnu/libgallium.so.0.0.0 exists in debian/tmp but is not installed to anywhere
[07:33] <mlankhorst> dh_install: dri/usr/lib/x86_64-linux-gnu/libgallium.so exists in debian/tmp but is not installed to anywhere
[07:33] <mlankhorst> dh_install: dri/usr/lib/x86_64-linux-gnu/libgallium.so.0 exists in debian/tmp but is not installed to anywhere
[07:33] <mlankhorst> scary..
[07:34] <tjaalton> :)
[07:40] <mlankhorst> is he in this channel? he made a mess of the git tree
[07:40] <tjaalton> mess?
[07:41] <tjaalton> builds fine here
[07:41] <mlankhorst> of course it does
[07:41] <jcristau> committed with patches applied?
[07:42] <mlankhorst> jcristau: winner :D
[07:42] <tjaalton> ah :)
[07:42] <jcristau> bad vorlon
[07:42] <tjaalton> quite easy to do that :)
[07:46] <mlankhorst> ah too bad he's not in any channels I'm in, can someone else point and laugh at him for me? :)
[07:46] <tjaalton> you're not on #ubuntu-devel?
[07:47] <mlankhorst> I'm in too many channels already, I cut out at 10 :p
[07:47] <jcristau> 10??
[07:48] <tjaalton> damn, need to run.. installing quantal on the ati box just finished but can't test mesa there until late this evening ./
[07:48] <tjaalton> :/
[07:48] <mlankhorst> jcristau: easier that way
[07:48] <tjaalton> i have 20+
[07:48]  * jcristau has like 80 irssi windows open
[07:48] <mlankhorst> jcristau: professional lurker :)
[07:48] <tjaalton> hah
[07:48] <jcristau> :)
[07:48] <tjaalton> that's a lot
[07:49] <jcristau> bunch of them are privmsg tho
[07:49] <tjaalton> 20 is the limit after which alt+key shortcuts stop working
[07:49] <jcristau> still...
[07:49] <RAOF> tjaalton: I'll run it on this ati box if you like.
[07:50] <tjaalton> RAOF: that would be great, I'll be on the bus for the next 1,5h and can do stuff but not test :)
[07:50] <tjaalton> afk ->
[07:54] <mlankhorst> tjaalton: ok refreshed the patch
[07:55] <mlankhorst> tjaalton: yeah that's why I give up on 10, personal irc comes after that :)
[07:56]  * mlankhorst has ignore on joins/quits from everyone, and nicks on some people who keep dropping out and auto rename
[08:11] <mlankhorst> ok now to figure out how to add version to libgallium
[08:11] <tjaalton> no need
[08:12] <tjaalton> it's internal
[08:12] <mlankhorst> so is libdricore right?
[08:12] <jcristau> yes
[08:12] <tjaalton> yeah but they added a version for some reason
[08:12] <tjaalton> ewll
[08:12] <tjaalton> *well
[08:13] <tjaalton> the reason was probably that you could have several of those installed, but this is strictly a packaging detail right now so I wouldn't bother :)
[08:13]  * mlankhorst bets the symbols would still conflict, leaving fun issues to debug
[08:13] <mlankhorst> ah well I'll leave it the same for now
[08:15] <RAOF> Upstream versioned it to make it easier on developers.
[08:15] <tjaalton> looks like I didn't have that messy commit when I built it locally :)
[08:17] <tjaalton> mlankhorst: adding libgallium.so to .install.in means it'll fail on !x86 !armhf
[08:17] <tjaalton> ugh
[08:17] <tjaalton> now mixing things again
[08:17] <mlankhorst> tjaalton: oh right armel..
[08:17] <tjaalton> or sth
[08:18] <tjaalton> anyway, probably best to copy it in rules
[08:19] <RAOF> We don't build libgallium on armel?
[08:19] <tjaalton> probably, was thinking of llvm again..
[08:19] <mlankhorst> I could upload to my armel ppa
[08:20] <tjaalton> leave it as is, like it was before..
[08:20] <tjaalton> my bad :)
[08:20] <mlankhorst> ah k
[08:21] <tjaalton> so now only the libxatracker linking issues remain
[08:21] <mlankhorst> oh I didn't actually test if it ran or not
[08:21] <mlankhorst> just if it built :p
[08:21] <tjaalton> hehe
[08:22] <tjaalton> needs ati or nvidia hw then
[08:23] <mlankhorst> oh I know, lets netboot that thingy in precise again
[08:23] <mlankhorst> btw other drivers will depend on libgallium.so.0 too
[08:24] <jcristau> which other gallium drivers are there?
[08:24] <jcristau> not counting llvmpipe
[08:25] <mlankhorst> well just simple grep, seems libgbm1, libxatracker1, and libegl1 might depend on it
[08:25] <tjaalton> vmwgfx?
[08:25] <jcristau> tjaalton: ah right.  but that's also x86 :)
[08:25] <mlankhorst> so maybe it needs a libgallium0 package..
[08:26] <tjaalton> jcristau: oh, indeed
[08:26] <tjaalton> mlankhorst: or just drop it, the space savings aren't that critical anymore
[08:26] <jcristau> mlankhorst: dunno about xatracker, but i would sure hope libegl doesn't link in gallium
[08:26] <tjaalton> if it saves 20MB that's still peanuts
[08:26] <mlankhorst> libegl1-mesa-drivers/usr/lib/x86_64-linux-gnu/egl/egl_gallium.so
[08:27] <tjaalton> at this point anyway
[08:27] <jcristau> hrm
[08:27] <tjaalton> if there's risk of breaking something then maybe leave it unenabled for now?
[08:28] <mlankhorst> well lets quantify it
[08:28]  * mlankhorst tries out both
[08:29] <RAOF> egl_gallium.so isn't totally necessary (although it *is* the only way to get OpenVG support)
[08:29] <mlankhorst> I'm just going to compare size
[08:34] <mlankhorst> but would it be worth it trying to upstream it?
[08:34] <tjaalton> not if they have other plans (the monolithic dri.so?)
[08:35] <mlankhorst> $ du -sh ?ummy*
[08:35] <mlankhorst> 39M     dummy
[08:35] <mlankhorst> 233M    dummy2
[08:35] <mlankhorst> 45M     summy
[08:35] <mlankhorst> 287M    summy2
[08:35] <mlankhorst> blegh 6 mb
[08:35] <mlankhorst> 2 contains all the -dev and -dbg files
[08:36] <RAOF> tjaalton: I don't think that rose to the level of a *plan* 
[08:36] <tjaalton> RAOF: ok, so in that case it might be worth it :)
[08:36] <RAOF> That was more “thanks for the dricore patch. I've always wanted to do something like that, but roll everything up into a monolithic dri.so”
[08:37] <RAOF> So it's probably on the TODO list, just after “learn Portuguese”
[08:37] <tjaalton> ahh
[08:37] <mlankhorst> so do we keep the patch or..
[08:38] <seb128> tjaalton, mlankhorst: how much extra space are we talking about on the deb?
[08:38] <tjaalton> keep it, and ship with it if it works, but if there's risk of breaking something maybe spend some more time on it?
[08:38] <mlankhorst> seb128: 6 mb uncompressed if the entirety of mesa was shipped, so less than that
[08:39] <seb128> mlankhorst, how much on the deb? 6mb is quite some
[08:39] <mlankhorst> let me test build one more time
[08:40] <tjaalton> testing the xatracker link fail
[08:41] <mlankhorst> seb128: what debs do you mean specifically? I bet not all of them are shipped
[08:42] <tjaalton> libgl1-mesa-dri
[08:42] <seb128> mlankhorst, I'm trying to figure what would the impact on the CD to drop that optimisation, it was done for a reason ;-)
[08:44] <RAOF> I recall that it nabbed on the order of 10 MiB of CD space when I first did it; the gains may be less now that dricore is upstream.
[08:45] <mlankhorst> RAOF: probably, it's 5 mb saved uncompressed for just libgl1-mesa-dri
[08:46] <mlankhorst> but yeah looks like libgl1-mesa-dri compresses well so it saves like 300 kb compressed..
[08:47] <seb128> well, the liveCD is not deb compressed, it's squashfs compressed I think
[08:47] <seb128> I guess we could try to drop that optimization and wait for the next daily iso and see the difference
[08:49] <mlankhorst> but the total still rounds up to 1.4mb because the other parts need to compress parts of libgallium too
[08:50] <mlankhorst> see http://paste.ubuntu.com/1160450/
[08:51] <tjaalton> the debs are xz-compressed now
[08:52] <seb128> tjaalton, deb compression doesn't matter for the liveCD, they do for the alternate
[08:52] <RAOF> Wah! Nearly 7pm. Time to stop!
[08:52] <tjaalton> seb128: i know, but while comparing deb sizes..
[08:53] <mlankhorst> tjaalton: same compression is used :) but I imagine squashfs compression might be different
[08:53] <seb128> tjaalton, mlankhorst, RAOF: well, your call at the end to see how much work it is and if you think it's worth it, CD space is still a limited resources and some mb can mean we need to drop support for a language spoken by some hundred of million of people
[08:54] <mlankhorst> I think we ought to measure it
[08:54] <seb128> so it's not like there was not a tradeoff
[08:54] <mlankhorst> could I bug someone to master a cd with both debs to see the space difference?
[08:56] <mlankhorst> but I'll post it on mesa-dev
[08:56] <seb128> mlankhorst, well the deb difference probably done a rough estimation, they are not compressed the same way but they are both compressed
[08:56] <tjaalton> mlankhorst: duh, of course. i'll get me coat
[09:07] <mlankhorst> hm, suppose I should test first before posting it
[09:15] <mlankhorst> seb128: I think I'm going to try to get it upstream, if it gets accepted there we wouldn't need to keep it.
[09:16] <seb128> mlankhorst, that would be great
[09:21] <tjaalton> yeah
[09:24] <tjaalton> -modesetting moved to main
[09:32] <tjaalton> meh, no success in getting xatracker linked properly
[09:32] <tjaalton> later ->
[09:45] <UraniumSlug> Hey all, updated my nvidia drivers having xorg dependency issues.
[09:45] <UraniumSlug> Any one else done this too?
[09:49] <mlankhorst> UraniumSlug: it's done on purpose
[09:49] <mlankhorst> new nvidia drivers claim to be compatible, but aren't..
[09:49] <UraniumSlug> mlankhorst, what's the work around?
[09:50] <mlankhorst> not installing new x server :-)
[09:50] <UraniumSlug> I've tried using the xorg-edgers ppa nvidia-current package.
[09:50] <UraniumSlug> Not getting past the login screen with them though.
[09:50] <mlankhorst> yeah they just broke, no good fix right now, depends on new nvidia drivers
[09:51] <mlankhorst> tjaalton: hm glxgears spins
[09:51] <mlankhorst> and login screen comes up right
[09:52] <UraniumSlug> mlankhorst, thanks for the info, much appreciated.
[09:55] <popey> hello Xers!
[09:55] <popey> Is there any technical reason why we couldn't backport nvidia-current in quantal to precise?
[09:56] <popey> I am told there are some compelling features (xrandr support) improved in the version in quantal
[10:05] <mlankhorst> popey: I would imagine that would be for nvidia-current-updates, but no idea when that updates, we mostly deal with the things we can influence here :)
[10:13] <popey> mlankhorst, well, I'm asking because someone on the backports team wanted to know if there was a technical reason we shouldn't backport that driver, I don't know :)
[10:22] <mlankhorst> I don't know if there is any technical reason, but nvidia-current-updates would be the right place to put it, maybe bryceh or Sarvatt know
[10:24] <popey> ok
[10:24] <popey> ta
[10:36] <mlankhorst> popey: but let me know, it would be useful when the quantal server works with nvidia so I could copy it to my q-lts-backports ppa :)
[10:52] <RAOF> popey: nvidia-current-updates is the package deliberately designed to do post-release updates. I don't think we've ever managed to *do* one, but that's what its for :)
[10:52] <popey> hah!
[10:52] <mlankhorst> RAOF: actually the version is newer
[10:53] <mlankhorst> 295.40-0ubuntu1.1 vs 295.49-0ubuntu0.2
[10:53] <popey> is it a time/resource reason for not doing it, technical or some thing else?
[10:56] <mlankhorst> popey: because not updating to newest and shiny all the time is more likely to keep systems running, or because we don't find it a high piority, pick one :)
[10:57] <mlankhorst> it's not 'oh new version, lets update' but more like 'things broke, is there a new version that fixes it?' :-)
[11:01] <popey> well, the specific thing that prompted me asking is because colour profiling seems broken with the nvidia proprietary driver because it doesn't support xrandr 1.2 
[11:02] <mlankhorst> then use that as justification for requesting an update :-)
[11:03] <popey> whats the process? file a bug?
[11:03] <mlankhorst> RAOF: is the process the same for the binary drivers?
[11:06] <tjaalton> just ask tseliot to update it?
[11:06] <mlankhorst> tseliot: ^
[11:09] <tseliot> yes?
[11:09] <tseliot> popey: please file a bug report and feel free to assign it to me
[11:10] <tseliot> (against nvidia-graphics-drivers-updates)
[11:10] <popey> ok!
[12:40] <mlankhorst> yay for nvidia is not completely removed types of bugs..
[17:01] <bryceh> thanks tseliot 
[17:02] <tseliot> :)
[17:48] <mlankhorst> ah great, my libgallium patch might get folded in to the patch for automaking whole of gallium :)
[17:48] <Prf_Jakob> Wouldn't it be better to just fold all the gallium drivers into a single binary.
[17:49] <Prf_Jakob> Enable -fvisibility=false and get an even smaller total binary size.
[17:49] <Prf_Jakob> And faster loading
[17:52] <mlankhorst> Prf_Jakob: in that case you might as well link everything into libGL completely
[17:53] <Prf_Jakob> mlankhorst: there is no real gain for that, since DRI driver only export on symbol.
[17:54] <Prf_Jakob> And doing a mega classic dri driver might be harder.
[17:54] <mlankhorst> but it won't help for vdpau and other gallium drivers that aren't dri :)
[17:55] <Prf_Jakob> At least mega dri drivers would be officially supported, the whole shared thing is hacky as hell since we have no formal ABI or promise of ABI over that boundry.
[17:56] <mlankhorst> true
[17:57] <Prf_Jakob> Loading extra gallium drivers arn't that bad since they are relativly tiny 400-700k
[17:58] <Prf_Jakob> Also why you guys don't just upx all binaries I don't get.
[18:01] <mlankhorst> because it doesn't make the cd smaller :-)