[00:25] <cnd> RAOF, I realized that my last email about the pointer barrier work didn't make sense in hindsight
[00:25] <cnd> well, it might, but it's only half the picture
[00:25] <cnd> if the libxfixes library (or whatever library it is) has the symbol, that still doesn't guarantee that the server supports the request
[00:26] <cnd> I don't know how to handle that without an extension version bump unless you check for XError messages
[00:38] <RAOF> cnd: Right.
[00:39] <RAOF> Well, what you *could* do is something crazy, like bump the extension version to 12.04 and only offer those if the client asks for exactly 12.04.
[00:39] <RAOF> And by you, I of course mean me.
[00:48] <cnd> heh
[00:49] <cnd> can you cram a '~ubuntu1' into an integer version?
[00:52] <RAOF> Yes!@
[00:52] <RAOF> You might notice that ~ubuntu1 is 8 bytes :)
[01:02] <cnd> heh
[01:02] <Sarvatt> but really, just poke ajax instead and get it upstream? it's not an input change :)
[01:03] <RAOF> It turns out we're still doing a little bit more prototyping, now that we've tried it on a variety of hardware :)
[01:23] <cnd> Sarvatt, we're well past the closure of the merge window, so it may not get in
[01:24] <Sarvatt> yeah but march isn't that far away, better to ping now before 6.0 is released without it and having it end up being 7.0
[01:24] <Sarvatt> thats gonna be a pain in the ass if it happens
[01:28] <RAOF> Yeah.  *If* an alternate XFIXES 6.0 is proposed on the list I'll certainly be calling for this stuff to be folded in.
[01:29] <RAOF> I'm not going to prod too strenuously until I'm reasonably certain that this is ok for us, though.
[01:30] <Sarvatt> swear there was new xfixes stuff queued up from nvidia guys for a long time now but heck if i've been able to find it
[01:35] <RAOF> That's XSync.
[01:36] <RAOF> You're thinking of the Sync Counter stuff for GLX/X rendering synchronisation.
[01:37] <Sarvatt> oh xext, indeed!
[01:42] <Sarvatt> ok enough anno 2070, uploading wayland/mesa to x-staging now :P
[01:45] <cnd> RAOF, Sarvatt: there are proposals to extend xsync?
[01:45]  * cnd is trying to debug xsync right now
[01:46] <Sarvatt> its already done and released
[01:46] <Sarvatt> i was remembering old stuff
[01:46] <RAOF> Oh, yeah.
[01:47] <RAOF> cnd: What are you trying to debug in xsync?
[01:47] <cnd> the fact that it doesn't really work? :)
[01:47]  * RAOF also forgot that it was implemented, and Google found the 2010 commit that did it
[01:47] <cnd> we set asynchronous timers, but they don't fire until some other event happens
[01:48] <cnd> so you do get a timer event, but it usually occurs well past when it was supposed to
[01:48] <RAOF> I've done some debugging in there, for the screensaver stuff.
[01:48] <Sarvatt> RAOF: hmm, now that I look, did you want to enable llvm-3.0 in mesa 8?
[01:49] <RAOF> Sarvatt: That seems like the prudent choice.
[01:49] <RAOF> Sarvatt: It's already in main, and I believe that more developers use it than 2.9
[01:49] <Sarvatt> it's in main, lets rock
[01:49] <Sarvatt> glad i didnt upload yet
[01:55] <Sarvatt> need to edit 2 patches and debian/control, nice and easy
[01:57] <Sarvatt> I wonder if anything else is pulling llvm-2.9 onto the cd though, having both might be an issue
[01:59] <cnd> Sarvatt, it would just be the library part of llvm
[01:59] <cnd> maybe that's not too big?
[02:00] <cnd> I guess we're talking about jit though
[02:00] <cnd> so library part == compiler
[02:07] <Sarvatt> cnd: Compressed Size: 7,407 k
[02:07] <Sarvatt> thats kinda big :P
[02:07] <cnd> yeah
[02:07] <Sarvatt> libgl1-mesa-dri pulls in libllvm3.0
[02:07] <cnd> we got rid of mono :)
[02:07] <Sarvatt> Compressed Size: 6,559 k for 2.9
[02:10] <RAOF> Sarvatt: mesa appears to be the only rdepend of libllvm, apart from the openjdk-7-zero runtime, which isn't shipped on the CD.
[02:10] <Sarvatt> its amazing so many dri drivers were dropped and it grew so much
[02:10] <Sarvatt> maybe libgallium core isn't as optimized as it used to be
[02:11] <RAOF> The non-big-three dri drivers were pretty small after dricoreing.
[02:11] <RAOF> Like 15-200K
[02:12] <Sarvatt> RAOF: hmm 2.9 is still the default llvm-config in precise
[02:12] <RAOF> But we're not using llvm-config, right?
[02:13] <RAOF> We're specifying an explicit llvm-config to use; that's probably the right behaviour, as it's not guaranteed to build against anything but the exact versions.
[02:15] <Sarvatt> yepyep, it would just be more future proof to have it call llvm-config --version in the patch instead of hardcoding it but that wont work, dont mind me just thinking out loud
[02:15] <RAOF> :)
[03:43] <RAOF> Huh.  Xserver dying with SIGBUS?  That's a new one on my hardware.
[03:44] <Sarvatt> ohhai plymouth
[03:45] <RAOF> Wasn't that SIGQUIT?
[03:45]  * Sarvatt has nightmares about SIGBUS when pressing enter on lucid
[03:45] <Sarvatt> oh yeah it was
[03:47] <Sarvatt> RAOF: netbook?
[03:47] <RAOF> Bah, and apport doesn't catch it.
[03:47] <RAOF> Sarvatt: SandyBridge.
[03:47] <Sarvatt> of course, apport doesn't catch crap
[03:47] <Sarvatt> except evdev or proprietary driver crashes
[03:47] <RAOF> We should totally fix it so apport catches this.
[03:47] <Sarvatt> 100_rethrow_signals.patch really doesn't work since jaunty
[03:48] <Sarvatt> we used to get such nice apport filed bugs against xserver, I miss it :(
[03:49] <RAOF> As I say, we should fix it.
[03:50] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/705078 hey moderately recent one
[03:50] <ubot4> Launchpad bug 705078 in xorg-server (Debian) (and 2 other projects) "Xorg crashed with SIGSEGV in pixman_image_set_has_client_clip() (affects: 53) (dups: 7) (heat: 145)" [Unknown,Fix released]
[03:50] <broder> i was actually just experimenting with this in one of my programs. it seems like the most reliable way to have a custom sigsegv/sigabrt signal handler and still have it generate a core dump is to use sigaction() with sa_flags == SA_RESETHAND and then just do raise(signum) from the handler
[03:50] <Sarvatt> it's over my head, I really tried
[03:50] <broder> ...but i haven't been able to verify if the core dump makes it to apport yet (i was testing with ulimit -c unlimited)
[03:51] <Sarvatt> I can find the refresh where it broke though
[03:51] <Sarvatt> will just take some time since it was years ago
[03:51] <RAOF> broder: Huh, interesting.
[03:52] <RAOF> I know quite a bit more about posix signal handling since last I touched that code; maybe we can get it to reliably work now :)
[03:53] <Sarvatt> I remember pitti refreshed it when it stopped working, hmmmmmm
[03:53] <broder> i think most of what i've learned so far is "it sucks" :)
[03:53] <Sarvatt> http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=7d65b7d399f5902cb3a3153b43dd8f3e627b7d08
[03:53] <Sarvatt> oh that was easy to find
[03:54] <Sarvatt> actually it might have been http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=history;f=debian/patches/100_rethrow_signals.patch;h=ffbc4b09cd498f0e69cd2ea5480a3ebf0afeeca1;hb=refs/heads/ubuntu
[03:54] <Sarvatt> since i remember it not being 100_rethrow_signals.patch when it did work and thats the first 100 version in git history
[03:57] <Sarvatt> http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=blob;f=debian/patches/135_rethrow_signals.patch;h=271ff49504e46d252175107feb0b19387b5d002d;hb=686f7d30ba19862bced1d8c3a48abfc5e7ed41f6 was the working one that only applied to xserver 1.6
[03:59] <broder> oh hey - apport has a log file. so yeah, it is getting notified when i core dump
[04:00] <broder> i *think* you could drop the patch as it exists now, add SA_RESETHAND to act.sa_flags on line 178 of os/osinit.c, and add raise(signo); to the end of OsSigHandler
[04:00] <RAOF> Right.  Modifying the signal handler seems like a more robust solution.
[04:01] <broder> alternatively, you might be able to not change act.sa_flags and instead do signal(signo, SIG_DFL); raise(signo); from the handler
[04:01] <broder> but i wouldn't swear to it
[05:31] <tjaalton> Sarvatt: "failed to upload", whatever that means
[05:36] <Sarvatt> tjaalton: looks like debian-experimental branch needs http://lintian.debian.org/tags/data.tar.xz-member-without-dpkg-pre-depends.html
[05:37] <tjaalton> ok..
[05:37] <Sarvatt> Rejected:
[05:37] <Sarvatt> Require Pre-Depends: dpkg (>= 1.15.6~) when using xz compression.
[05:38] <Sarvatt> could be wrong, its really late here
[05:38] <Sarvatt> thats what launchpad said about the fail to upload, we used lzma for 7.11..
[05:38] <tjaalton> push the release too, btw ;)
[05:38] <Sarvatt> maybe just the ubuntu branch? dunno
[05:38] <Sarvatt> i did
[05:39] <Sarvatt> well except for the s/UNRELEASED/precise/
[05:39] <Sarvatt> just pushed the llvm change
[05:39] <tjaalton> right
[07:47] <broder> RAOF: i'm unlikely to see a fix for bug #861426 that's not "switch GnomeRR to use libxrandr-util", right?
[07:47] <ubot4> Launchpad bug 861426 in gnome-desktop3 (Ubuntu Oneiric) (and 1 other project) "[Oneiric] [Regression] When disabling onboard LVDS display and just using external VGA screen corruption occurs (affects: 7) (heat: 20)" [High,Triaged] https://launchpad.net/bugs/861426
[08:17] <tjaalton> uploading libxcb to x-staging
[08:18] <tjaalton> well, "syncing"
[12:24] <Kimal73> goodmorning. Are there drivers for ubuntu of Radeon HD 6520M?
[12:59] <tjaalton> Kimal73: have you tried?
[15:54] <tjaalton> yeah something weird with scrolling
[15:54] <tjaalton> for instance if I scroll down, it'll first jump up
[15:54] <tjaalton> sometimes
[16:15] <tjaalton> mmh libx11 multiarch fail
[16:15] <jcristau> hmm?
[16:15] <tjaalton> changelog different
[16:15] <tjaalton> might be just ubuntu
[16:16] <tjaalton> mesa upgrade pulled libx11-xcb1:i386
[16:20] <tjaalton> ah, caused by the symlinking
[16:20] <tjaalton> or not
[16:22] <Sarvatt> tjaalton: you have libegl1-mesa:i386 installed?
[16:23] <tjaalton> Sarvatt: no, libgl1-mesa-dri:i386 and some others
[16:24] <Sarvatt> whats aptitude why libx11-xcb1:i386 say?
[16:25] <tjaalton> libgl1-mesa-glx
[16:28] <tjaalton> http://paste.ubuntu.com/824024
[16:28] <tjaalton> ??
[17:46] <tjaalton> ok so the ppa or the main archive mangles the changelogs somehow, resulting in that upgrade error
[17:46] <tjaalton> I've tried purging the packages and still the same
[18:28] <Prf_Jakob> Anyway I can get the Ubuntu kernel to not use nouveau?
[18:28] <Prf_Jakob> Via the kernel command line?
[18:31] <Prf_Jakob> There we go.
[18:32] <Prf_Jakob> FYI Nouveau is broken on MacBookPro5,1 in 11.10.
[18:37] <Prf_Jakob> §#%#§&§#"§#" I see the Keyboard layout select is still a big pile of poo.
[18:38] <Prf_Jakob> It hangs if you select to many keyboard layouts before selecting the one you want.
[18:41] <tjaalton> ok, so my "multiarch fail" was due to the ubuntu-x/x-staging ppa not mangling the changelogs like the main builders (and canonical-x/) do
[18:42] <tjaalton> what a pain
[18:44] <tjaalton> OpenGL version string: 3.0 Mesa 8.0-rc2
[18:44] <tjaalton> finally
[18:45] <Sarvatt> Prf_Jakob: looks like nouveau.noaccel=1 is needed on that machine from a quick glance :(
[18:45] <Sarvatt> tjaalton: now try running unigine games! :P
[18:46] <Sarvatt> going to be fun getting all the QA bugs about unigine benchmarks not working after 12.04 releases
[18:51] <tjaalton> Sarvatt: doesn't it need server support too?
[19:00] <tjaalton> heh, at least unigine-heaven fails to run
[19:16] <orated> Hey tjaalton
[19:19] <orated> tjaalton: : If you remember helping me with optimus related issue on XPS 15, you said Thinkpad BIOS allows to disable nvidia graphics card. I was wondering if there exist a way to flash open source BIOS or any custom BIOS which could detect hardware properly and allow such features
[19:21] <tjaalton> orated: don't think so
[19:25] <orated> tjaalton: So there seems to be no option to use second gfx nor to disable it
[19:26] <tjaalton> i don't know
[19:26] <orated> Umm
[19:29] <tjaalton> try asking on #bumblebee
[20:17] <Prf_Jakob> Sarvatt: looks like noaccel wasn't needed.
[20:21] <FernandoMiguel> evening
[20:22] <Prf_Jakob> no wait I'm using nvidia.
[22:59] <Sarvatt> RAOF: llvm-3.0 transition looks fine
[22:59] <Sarvatt> RAOF, tjaalton: weren't we going to llvmpipe default this time though?
[22:59] <RAOF> Sweet.
[22:59] <Sarvatt> its just completely not shipped at all anymore now
[23:00] <RAOF> Sarvatt: That's the default software renderer for 8.0, isn't it?
[23:00] <Sarvatt> nope swrast getting shipped
[23:00] <Sarvatt> OpenGL vendor string: Mesa Project
[23:00] <Sarvatt> OpenGL renderer string: Software Rasterizer
[23:00] <Sarvatt> OpenGL version string: 2.1 Mesa 8.0-rc2
[23:00] <Sarvatt> OpenGL shading language version string: 1.20
[23:01] <RAOF> Huh.  I think we do want to be shipping llvmpipe.
[23:01] <Sarvatt> we could put the dri-alternates handling back in and ship it in -experimental at the very least..
[23:02] <Sarvatt> ah I see the confusion
[23:02] <Sarvatt> http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=commit;h=760ae1c2a9de9c6ac253d357f631b295a2a8b246
[23:02] <tjaalton> yep
[23:03] <Sarvatt> it was renamed swrast_dri in the same place instead of swrastg_dri, its still not in the path classic mesa swrast_dri is that we're putting in
[23:04] <RAOF> Is there a way to just not build classic swrast?
[23:05] <RAOF> We don't want to ship it, could we please not build it? :)
[23:05] <tjaalton> yes, drop it from DRI_DRIVERS
[23:06] <tjaalton> so it's being copied over the gallium one?
[23:06] <Sarvatt> yep its an easy change, drop it from DRI_DRIVERS and install build/dri/${DEB_HOST_MULTIARCH}/gallium/swrast_dri.so  usr/lib/${DEB_HOST_MULTIARCH}/dri in libgl1-mesa-dri
[23:07] <tjaalton> or move it in rules
[23:07] <tjaalton> like the others
[23:10] <tjaalton> well, r300
[23:12] <tjaalton> oh wait, there was linux.install.in
[23:16] <tjaalton> swrast would go in libgl1-mesa-dri.install.in
[23:18] <RAOF> Yeah.
[23:18] <RAOF> Well, it *also* needs to go in .linux.install.in, because those files aren't cumulative.