[00:25] RAOF, I realized that my last email about the pointer barrier work didn't make sense in hindsight [00:25] well, it might, but it's only half the picture [00:25] 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] I don't know how to handle that without an extension version bump unless you check for XError messages [00:38] cnd: Right. [00:39] 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] And by you, I of course mean me. [00:48] heh [00:49] can you cram a '~ubuntu1' into an integer version? [00:52] Yes!@ [00:52] You might notice that ~ubuntu1 is 8 bytes :) [01:02] heh [01:02] but really, just poke ajax instead and get it upstream? it's not an input change :) [01:03] 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] Sarvatt, we're well past the closure of the merge window, so it may not get in [01:24] 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] thats gonna be a pain in the ass if it happens [01:28] 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] I'm not going to prod too strenuously until I'm reasonably certain that this is ok for us, though. [01:30] 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] That's XSync. [01:36] You're thinking of the Sync Counter stuff for GLX/X rendering synchronisation. [01:37] oh xext, indeed! [01:42] ok enough anno 2070, uploading wayland/mesa to x-staging now :P [01:45] RAOF, Sarvatt: there are proposals to extend xsync? [01:45] * cnd is trying to debug xsync right now [01:46] its already done and released [01:46] i was remembering old stuff [01:46] Oh, yeah. [01:47] cnd: What are you trying to debug in xsync? [01:47] 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] we set asynchronous timers, but they don't fire until some other event happens [01:48] so you do get a timer event, but it usually occurs well past when it was supposed to [01:48] I've done some debugging in there, for the screensaver stuff. [01:48] RAOF: hmm, now that I look, did you want to enable llvm-3.0 in mesa 8? [01:49] Sarvatt: That seems like the prudent choice. [01:49] Sarvatt: It's already in main, and I believe that more developers use it than 2.9 [01:49] it's in main, lets rock [01:49] glad i didnt upload yet [01:55] need to edit 2 patches and debian/control, nice and easy [01:57] I wonder if anything else is pulling llvm-2.9 onto the cd though, having both might be an issue [01:59] Sarvatt, it would just be the library part of llvm [01:59] maybe that's not too big? [02:00] I guess we're talking about jit though [02:00] so library part == compiler [02:07] cnd: Compressed Size: 7,407 k [02:07] thats kinda big :P [02:07] yeah [02:07] libgl1-mesa-dri pulls in libllvm3.0 [02:07] we got rid of mono :) [02:07] Compressed Size: 6,559 k for 2.9 [02:10] 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] its amazing so many dri drivers were dropped and it grew so much [02:10] maybe libgallium core isn't as optimized as it used to be [02:11] The non-big-three dri drivers were pretty small after dricoreing. [02:11] Like 15-200K [02:12] RAOF: hmm 2.9 is still the default llvm-config in precise [02:12] But we're not using llvm-config, right? [02:13] 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] 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] :) [03:43] Huh. Xserver dying with SIGBUS? That's a new one on my hardware. [03:44] ohhai plymouth [03:45] Wasn't that SIGQUIT? [03:45] * Sarvatt has nightmares about SIGBUS when pressing enter on lucid [03:45] oh yeah it was [03:47] RAOF: netbook? [03:47] Bah, and apport doesn't catch it. [03:47] Sarvatt: SandyBridge. [03:47] of course, apport doesn't catch crap [03:47] except evdev or proprietary driver crashes [03:47] We should totally fix it so apport catches this. [03:47] 100_rethrow_signals.patch really doesn't work since jaunty [03:48] we used to get such nice apport filed bugs against xserver, I miss it :( [03:49] As I say, we should fix it. [03:50] https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/705078 hey moderately recent one [03:50] 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] 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] it's over my head, I really tried [03:50] ...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] I can find the refresh where it broke though [03:51] will just take some time since it was years ago [03:51] broder: Huh, interesting. [03:52] 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] I remember pitti refreshed it when it stopped working, hmmmmmm [03:53] i think most of what i've learned so far is "it sucks" :) [03:53] http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=7d65b7d399f5902cb3a3153b43dd8f3e627b7d08 [03:53] oh that was easy to find [03:54] 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] 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] 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] oh hey - apport has a log file. so yeah, it is getting notified when i core dump [04:00] 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] Right. Modifying the signal handler seems like a more robust solution. [04:01] 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] but i wouldn't swear to it [05:31] Sarvatt: "failed to upload", whatever that means [05:36] tjaalton: looks like debian-experimental branch needs http://lintian.debian.org/tags/data.tar.xz-member-without-dpkg-pre-depends.html [05:37] ok.. [05:37] Rejected: [05:37] Require Pre-Depends: dpkg (>= 1.15.6~) when using xz compression. [05:38] could be wrong, its really late here [05:38] thats what launchpad said about the fail to upload, we used lzma for 7.11.. [05:38] push the release too, btw ;) [05:38] maybe just the ubuntu branch? dunno [05:38] i did [05:39] well except for the s/UNRELEASED/precise/ [05:39] just pushed the llvm change [05:39] right [07:47] RAOF: i'm unlikely to see a fix for bug #861426 that's not "switch GnomeRR to use libxrandr-util", right? [07:47] 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] uploading libxcb to x-staging [08:18] well, "syncing" [12:24] goodmorning. Are there drivers for ubuntu of Radeon HD 6520M? [12:59] Kimal73: have you tried? [15:54] yeah something weird with scrolling [15:54] for instance if I scroll down, it'll first jump up [15:54] sometimes [16:15] mmh libx11 multiarch fail [16:15] hmm? [16:15] changelog different [16:15] might be just ubuntu [16:16] mesa upgrade pulled libx11-xcb1:i386 [16:20] ah, caused by the symlinking [16:20] or not === yofel_ is now known as yofel [16:22] tjaalton: you have libegl1-mesa:i386 installed? [16:23] Sarvatt: no, libgl1-mesa-dri:i386 and some others [16:24] whats aptitude why libx11-xcb1:i386 say? [16:25] libgl1-mesa-glx [16:28] http://paste.ubuntu.com/824024 [16:28] ?? [17:46] ok so the ppa or the main archive mangles the changelogs somehow, resulting in that upgrade error [17:46] I've tried purging the packages and still the same [18:28] Anyway I can get the Ubuntu kernel to not use nouveau? [18:28] Via the kernel command line? [18:31] There we go. [18:32] FYI Nouveau is broken on MacBookPro5,1 in 11.10. [18:37] §#%#§&§#"§#" I see the Keyboard layout select is still a big pile of poo. [18:38] It hangs if you select to many keyboard layouts before selecting the one you want. [18:41] 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] what a pain [18:44] OpenGL version string: 3.0 Mesa 8.0-rc2 [18:44] finally [18:45] Prf_Jakob: looks like nouveau.noaccel=1 is needed on that machine from a quick glance :( [18:45] tjaalton: now try running unigine games! :P [18:46] going to be fun getting all the QA bugs about unigine benchmarks not working after 12.04 releases [18:51] Sarvatt: doesn't it need server support too? [19:00] heh, at least unigine-heaven fails to run [19:16] Hey tjaalton [19:19] 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] orated: don't think so [19:25] tjaalton: So there seems to be no option to use second gfx nor to disable it [19:26] i don't know [19:26] Umm [19:29] try asking on #bumblebee [20:17] Sarvatt: looks like noaccel wasn't needed. [20:21] evening [20:22] no wait I'm using nvidia. [22:59] RAOF: llvm-3.0 transition looks fine [22:59] RAOF, tjaalton: weren't we going to llvmpipe default this time though? [22:59] Sweet. [22:59] its just completely not shipped at all anymore now [23:00] Sarvatt: That's the default software renderer for 8.0, isn't it? [23:00] nope swrast getting shipped [23:00] OpenGL vendor string: Mesa Project [23:00] OpenGL renderer string: Software Rasterizer [23:00] OpenGL version string: 2.1 Mesa 8.0-rc2 [23:00] OpenGL shading language version string: 1.20 [23:01] Huh. I think we do want to be shipping llvmpipe. [23:01] we could put the dri-alternates handling back in and ship it in -experimental at the very least.. [23:02] ah I see the confusion [23:02] http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=commit;h=760ae1c2a9de9c6ac253d357f631b295a2a8b246 [23:02] yep [23:03] 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] Is there a way to just not build classic swrast? [23:05] We don't want to ship it, could we please not build it? :) [23:05] yes, drop it from DRI_DRIVERS [23:06] so it's being copied over the gallium one? [23:06] 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] or move it in rules [23:07] like the others [23:10] well, r300 [23:12] oh wait, there was linux.install.in [23:16] swrast would go in libgl1-mesa-dri.install.in [23:18] Yeah. [23:18] Well, it *also* needs to go in .linux.install.in, because those files aren't cumulative.