[02:36] if i send a control file with multiarch in it to lucid/mav/natty ppa will the build system reject it? [02:36] or ignore it? [03:02] bryce, Sarvatt, RAOF: Branch made === yofel_ is now known as yofel [08:03] Prf_Jakob: Sweet! [09:13] Sarvatt: Hey dude. Is there a nice package of the new dri2 protocol anywhere? [09:13] Sarvatt: Oh, presumably it's in edgers. Sorry :) [09:15] RAOF: what exactly are you looking for? [09:16] dri2proto is up to date in the distro [09:16] I'm looking to build libxcb against the newer xcb-proto [09:16] oh no havent done xcb-proto yet [09:16] Oh, *I've* done xcb-proto. [09:16] But it's failing to build, and I thought that would be the problem. Maybe not. Boo. [09:17] (And by "done", I mean "have uupdated the package") [09:17] so you probably need xcb-util updated [09:17] oh nope [09:18] how's it failing? is_switch failure? [09:18] http://paste2.org/p/1863662 [09:21] Any ideas? [09:21] nope haven't seen that one, going to grab it all and check it out [09:21] thats building libxcb 1.8? [09:22] That's building libxcb 1.7. [09:22] with the new xcb-proto installed? [09:23] With the new xcb-proto installed, yes. [09:23] Is there tight coupling between libxcb and xcb-proto? [09:24] Heh. libxcb1.8 *does* die in is_switch :) [09:25] new xcb-proto isn't supposed to break old libxcb afaik [09:25] but, maybe it does... [09:26] jcristau: Incidentally, why does xcb-proto declare a VCS-Git on freedesktop.org? That's not where the packaging is. [09:27] initially it was there [09:28] Yeah; it's got the packaging for up to 1.1. [09:29] It's no longer maintained in git? [09:29] Bah. I missed installing python-xcbgen. Now it's breaking in my stuff :) [09:31] should be in collab-maint [09:31] i thought i'd fixed the vcs-* stuff [09:32] apparently not. [09:32] Unless the Ubuntu packages are behind, no :) [09:32] ah, libxcb has updated vcs-*, xcb-proto not. [09:32] fail [09:33] :) [09:34] soo happy to see new xcb releases.. hope they fix the nasty threading issues that cause all sorts of crashes for some people [09:34] can't link the bug since lp will timeout.. [09:35] yeep AttributeError: 'Struct' object has no attribute 'is_switch', wish i could remember how we worked around that [09:35] * Sarvatt digs through old PPAs [09:35] Sarvatt: I think the new python-xcbgen fixes that. [09:35] oh, bug 905686 is a newer one with less dupes [09:35] Launchpad bug 905686 in nautilus (Ubuntu) (and 1 other project) "nautilus assert failure: nautilus: ../../src/xcb_io.c:528: _XAllocID: Assertion `ret != inval_id' failed. (affects: 19) (dups: 16) (heat: 140)" [Medium,Triaged] https://launchpad.net/bugs/905686 [09:36] this was apparently fixed upstream over a year ago, but near impossible to backport [09:36] think i looked into that, could be wrong.. [09:36] oh helps if i install that deb [09:37] :) [09:38] tjaalton: this stuff is nasty, each fix breaks something else [09:39] jcristau: yeah, hoping it's sorted out by now.. [09:48] RAOF: so, http://anonscm.debian.org/gitweb/?p=collab-maint/xcb-proto.git and http://anonscm.debian.org/gitweb/?p=collab-maint/libxcb.git are where the packaging lives now, if you want to update that [09:48] Why not! [09:49] libxcb symbol updates are always fun [09:49] * RAOF has just passed -C0 for the moment. [09:49] if you don't have write access to collab-maint you can push the update somewhere else and let me/kibi/jd_ know where we can pull from [09:50] I think I've got collab-maint access. [09:50] and me [09:58] http://sarvatt.com/downloads/patches/libxcb-1.8-symbols.patch thats what i've got so far on to build #9 [09:59] Yeah, well, I'm adding protocol so it's changing for me anyway. [09:59] Clearly there are no pointer-barriers clients using XCB. :) [10:34] phew finally http://sarvatt.com/downloads/patches/libxcb-1.8-symbols.patch [10:39] are these sizeof things really meant to be exported? [10:45] also, what does one lose if the symbols file just had "*@Base 0\n*@Base 1.8"? [10:45] i've seen wildcards used like that [10:45] like nss & nspr [10:47] at least it would be much easier to maintain the file.. [10:50] that works if you version your symbols [10:50] xcb doesn't do that [10:51] right, nss does [10:51] i'll get me coat :) [11:15] hi [11:15] has anyone had a chance to look at bug 897436 yet? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/897436 [11:15] Launchpad bug 897436 in xserver-xorg-video-nouveau (Ubuntu) "Screen corrupted without nomodeset on nVidia Corporation GT215 [GeForce GTS 360M] (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/897436 [11:15] inetpro: Error: Bug #897436 is private. [11:16] * inetpro wonders what that means [11:17] inetpro: just try with a newer kernel http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-precise/ [11:17] tjaalton: I'll try again asap, thanks [11:18] but how do I know when to try? [11:21] hm? [11:21] nouveau is a kms-only driver, if it doesn't work you need to test a newer kernel [11:21] that's the first step before wasting time on anything else [11:22] now, I hope lp had a way to tell the bugreporter about that.. [11:22] how often is the kernel updated in the daily builds? [11:23] what daily builds? [11:23] you can test a daily livecd, yes [11:23] precise [11:23] I mean the daily livecd [11:23] it has whatever kernel is the current one on the archive [11:24] so precise has 3.2, while oneiric had 3.0 [11:24] which means there's a chance it's fixed in precise.. [11:25] the last time I tried the daily livecd was on 2011-12-14 and there were no changes [11:26] oh, missed that part of the bug [11:28] ah, there's a kernel with drm-next [11:28] when do I know whether it is worth testing a livecd again? [11:28] http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/current/ [11:28] try that on oneiric [11:29] precise has what it will ship with, there won't be big changes to the kernel anymore [11:29] unless a fix ends up in 3.2.x [11:29] hmm [11:29] but could be that you need to poke upstream devs about this.. [11:29] I got it working perfectly as it is on oneiric but I just want to make sure that things will work out of the box on the next release [11:30] right, so test that kernel to see if it's broken on current upstream code.. [11:30] if it works with it, we can bisect the fix [11:31] tjaalton: I'm not sure I get what you mean with test that kernel, how do I go about testing it [11:31] ? [11:31] install it [11:31] ? [11:32] pick the image deb for your arch, dpkg -i $foo.deb [11:33] tjaalton: I do this after installing the livecd with nomodeset? [11:34] inetpro: no, you have oneiric installed, right? just remove nvidia-current, install the deb and boot your machine... [11:34] well, whatever is easiest for you.. [11:36] ahh, I'll try that asap [11:36] ricotz: anything "special" about wayland updates before i do a new one in edgers? mesa needs latest git wayland again [11:37] Sarvatt, i think wayland should be fine [11:38] weston/wayland-demos might make problem if there were further renames and movings [11:38] Sarvatt, let me push wayland [11:42] Sarvatt, uploaded [12:04] RAOF, bryce: new synaptics uploaded to x-staging and pushed to git branch ubuntu+1 === yofel_ is now known as yofel === JanC_ is now known as JanC [20:45] is cnd's utouch-geis fix in a PPA somewhere? I am getting used to using gnome-terminal as "Launcher" but I miss evince! [20:47] I tried to hand-apply and build myself, but building breaks in xcb dir. missing build dep? [20:53] Had to remove -Werror in configure.ac to get past some unused variable complaints. Now there's a libtool 2.4.2 vs 2.4.2ubuntu1 mismatch... [20:59] "rm aclocal.m4 configure; autoreconf -vi" helped. finally built. [21:02] (all this compiling while an eog was stuck on the CPU). Now with the geis patches, eog and evince segfault instead of looping.