[01:08] <cnd> RAOF, I'm about to upload xorg-gtest 0.2.0 to precise (\o/)
[01:08] <RAOF> Wooo!
[01:08] <cnd> I now have no reservations about the MIR
[01:09] <RAOF> I'll address the final gtest MIR comment today.
[01:09] <cnd> RAOF, oh, I didn't notice any MIR comments for gtest
[01:09] <cnd> RAOF, do you have the bug #?
[01:09] <RAOF> https://bugs.launchpad.net/ubuntu/+source/gtest/+bug/949575
[01:09] <RAOF> Just to run the tests during the build.
[01:12] <cnd> doh, I need to change libxorg-gtest-dev from arch any to arch all
[01:47] <Sarvatt> multiarch certainly made local testing annoying, purging all my humble bundle games every time i want to test local libdrm/mesa builds without using a ppa :)
[01:47] <Sarvatt> since i dont have :i386 versions built too
[01:48]  * Sarvatt starts not caring about making .deb's of upstream crap he tests
[01:50]  * RAOF just builds i386 versions, too.
[01:57] <Sarvatt> oh thats a blast with mesa on laptops
[02:06] <Sarvatt> would be nicer if we didn't support 8 and 16 bit versions of osmesa to cut the build time in half though :)
[02:07] <cnd> RAOF, ok, finally got xorg-gtest uploaded after needing a few more changes
[02:07] <RAOF> Wootness.
[09:26] <tjaalton> hmm, want an intuos5S, the intuos4L is too big
[09:26] <tjaalton> driver support missing, will add it
[15:17] <Sarvatt> bryceh: i'm so confused about https://launchpad.net/ubuntu/+source/mesa/7.11-0ubuntu3.1 -- you added an intel patch instead of the nouveau fix? :P
[15:40] <Sarvatt> bryceh, RAOF: we have to be super careful with intel cherry-picks in mesa now, the symlinks are dereferenced for the tarballs so when we add a patch touching src/mesa/drivers/dri/intel/* it has to be duplicated out to the other places like src/mesa/drivers/dri/i965
[16:45] <Prf_Jakob> Sarvatt: symlink derefes sounds like a bug.
[16:45] <Prf_Jakob> Sarvatt: I'll do the release today btw.
[16:45] <Prf_Jakob> As soon as I get a review on a patch.
[16:45] <tjaalton> it's different in 8.0
[16:45] <Prf_Jakob> Ah ok
[16:46] <tjaalton> i guess the tarball has the same symlinks
[16:46] <tjaalton> whereas 7.11 didn't, so we had to do tricks in order to build a source package from git
[16:47] <tjaalton> since dpkg-source refuses to work if a real file changed to a symlink
[17:04] <ricotz> tjaalton, hi
[17:07] <tjaalton> ricotz: yo
[17:08] <ricotz> tjaalton, the #debian-gnome guy really hoping for libwacom soon ;) they are already doing gnome 3.3/3.4
[17:09] <tjaalton> ricotz: and ready to sponsor it?
[17:09] <ricotz> yeah, mbiebl would upload it
[17:09] <bryceh> Sarvatt, actually, looks like I got two bugs transposed.
[17:10] <tjaalton> ricotz: so you filed the ITP?
[17:10] <ricotz> tjaalton, you want to join #debian-gnome
[17:10] <tjaalton> oh I do? :)
[17:10] <ricotz> tjaalton, no, i havent
[17:10] <tjaalton> what's 659700 then
[17:11] <Sarvatt> bryceh: i'm in the process of working up a SRU for https://launchpad.net/~sarvatt/+archive/sru6 , is it ok if I just remove it from this one? this one will be verified really fast even though its large, its affecting every ivybridge system QA is running tests against
[17:11] <tjaalton> oh it was me
[17:11] <tjaalton> hehe
[17:11] <ricotz> ;)
[17:11] <bryceh> Sarvatt, that's fine
[17:15] <Sarvatt> bryceh: that patch you added for src/mesa/drivers/dri/intel needs to be duplicated into src/mesa/drivers/dri/i965 and src/mesa/drivers/dri/i915 if appropriate to get used though
[17:15] <Sarvatt> because of that symlink problem in 7.11
[17:16] <bryceh> Sarvatt, right, but I'm not sure the patch should be sru'd
[17:17] <bryceh> Sarvatt, it's for 757906, whose oneiric task is set to wontfix
[17:30] <bryceh> mm, think maybe it shouldn't have been set to wontfix though.
[19:29] <Sarvatt> hmm our mesa debs are .gz
[19:29] <Sarvatt> we used lzma for 7.11
[19:30] <Sarvatt>         dh_builddeb -s -- -Zlzma
[19:30] <Sarvatt> vs
[19:30] <Sarvatt>         dh_builddeb $(foreach pkg,$(dbgpkg),-p$(pkg)) -- -Zxz
[19:30] <Sarvatt>         dh_builddeb $(foreach pkg,$(otherpkg),-p$(pkg))
[19:33] <Sarvatt> that might explain the lack of size difference even though all the dri1 stuff was dropped back when i compared it
[19:47] <Sarvatt> -rw-r--r-- 1 sarvatt sarvatt 2.9M Mar 20 15:46 data.tar.xz
[19:47] <Sarvatt> -rw-r--r--  1 sarvatt sarvatt 5.5M Mar 20 15:28 data.tar.gz
[19:47] <Sarvatt> thats a huge chunk of livecd space
[19:48] <Sarvatt> just for libgl1-mesa-dri
[19:49] <Sarvatt> -rw-r--r-- 1 sarvatt sarvatt 2.9M Mar 20 15:48 data.tar.lzma
[19:51] <Sarvatt> so lzma that doesnt need a pre-depends diff for every package, or xz which does? :P
[19:52] <albert23> does deb compression matter on a live cd, as the package is installed?
[19:55] <Sarvatt> good point, dont think it does outside of alternate, i've just always gone under the impression that the compressed deb size is how much approximately is going to be used there but that doesn't make sense :)
[21:44] <bryceh> should we be thinking about pulling in the libX11 1.5 release with keith's fix for those xcb sync bugs?
[21:46] <tjaalton> sure, better than a beta
[21:46] <tjaalton> or rc
[21:57] <RAOF> Yeah, probably a good idea.
[21:57] <bryceh> would likely make seb128 happy
[21:58] <seb128> \o/
[21:58] <seb128> that would be great
[21:59] <seb128> would that fix all the XAlloc assert bugs?
[21:59] <seb128> _XAllocID
[21:59] <bryceh> seb128, it may; it's not widely tested yet tho afaict
[22:00] <FernandoMiguel> Olá
[22:02] <bryceh> seb128, technically I think the bugs are caused by client apps that are using libxcb in non-threadsafe ways
[22:02] <mlankhorst> probably
[22:02] <bryceh> seb128, libxcb is advertised as a single-threaded lib, so when multi-threaded clients use it, they have to be careful.
[22:02] <bryceh> seb128, so I'm not sure if keith's patch is a true fix or may be just papering over bad client coding.
[22:03] <bryceh> but... if it stops the asserts...
[22:03] <seb128> bryceh, I doubt any "client" use xcb
[22:03] <seb128> but maybe a gtk or cairo bug...
[22:03] <jcristau> err
[22:03] <bryceh> seb128, well, they do via libx11
[22:03] <seb128> like "use it directly"
[22:04] <bryceh> ah, right
[22:04] <seb128> bryceh, they use gtk,cairo
[22:04] <jcristau> using libxcb in a multi-threaded app is very much ok.
[22:04] <RAOF> xcb is lovingly threadsafe, what with all the cookies and all.
[22:05] <bryceh> seb128, also fwiw where we've seen this in other apps (there was one in apport a few weeks back), the issue was able to be resolved in the client itself.
[22:05] <RAOF> Doesn't Keith's patch fix a deadlock in libx11?  I'm not sure that's hugely likely to fix the XAllocID asserts.  But it might, things are madness.
[22:06] <jcristau> RAOF: it does.
[22:06] <jcristau> (only fix a deadlock)
[22:07] <RAOF> Which is certainly a fix we want; deadlocking apps isn't exactly brilliant behaviour :)
[22:07] <bryceh> ok, so seb128 go back to being sad
[22:08] <seb128> :-(
[22:08] <mlankhorst> :-o
[22:08] <jcristau> does seb128 have a reproducer for his bug?
[22:09] <bryceh> bug #950222
[22:10] <jcristau> closed worksforme :)
[22:10] <seb128> jcristau, no, we just get hundred of XAllocID assert in random GNOME component and I've no clue what info would be useful since they seem random, no user come with a way to trigger them
[22:11] <seb128> jcristau, bug #905686
[22:11] <seb128> bug #507062
[22:11] <seb128> jcristau, so bug got so dupped you can't open them without getting launchpad to timeout half the time
[22:13] <tjaalton> there was one bug that looked similar which was a flaw in glib
[22:13] <tjaalton> fixed last fall i think
[22:15] <jcristau> it's breaking single threaded apps?
[22:16] <jcristau> looks like https://launchpadlibrarian.net/37855577/ThreadStacktrace.txt only has 1 thread
[22:18] <bryceh> seb128, I think a lot of those shouldn't have been all duped together.  Just because they trigger the same assert doesn't mean it's the same bug.
[22:21] <seb128> bryceh, I would be glad to have any clue how to figure that, what to do with them
[22:22] <bryceh> seb128, well what I do is look in libx11:src/xcb_io.c and grep for the assertion that the bug hit.
[22:22] <bryceh> seb128, often times the XCB guys have left comments explaining what the assertion means
[22:23] <bryceh> seb128, and for many of these bugs, that reveals a coding error somewhere in the client
[22:25] <bryceh> jcristau and RAOF said above that xcb works fine in multithreaded apps, but from all the bugs you and I have seen where xcb assertions get tripped, it seems very sensitive to threading issues in clients.
[22:25] <jcristau> these asserts are in xlib
[22:25] <jcristau> not xcb
[22:26] <bryceh>  __assert_fail_base (fmt=0xb75b1698 <Address 0xb75b1698 out of bounds>, assertion=0x76ad79 "ret != inval_id", file=0x76acea "../../src/xcb_io.c", line=528, function=0x76adfe "_XAllocID") at assert.c:94
[22:26] <bryceh> jcristau, xcb_io.c is not xcb?
[22:26] <jcristau> that's in xlib
[22:28] <bryceh> jcristau, yes, in libx11:src/xcb_io.c like I said
[22:28] <seb128> those XAllocID assert a probably the number 1 bug we get through desktop
[22:28] <seb128> and I've no clue what's the issue or how to debug it
[22:28] <seb128> and it's clients apps all being buggy, or gtk, or x11 or whatever
[22:34] <bryceh> seb128, do you see the issue as being random, or do you know of reliable ways to reproduce it?
[22:34] <bryceh> it/them?
[22:34] <RAOF> Whoopsie doesn't yet have any ability to do fancy client stuff yet, does it?
[22:34] <seb128> bryceh, random, I never hit those bugs
[22:35] <bryceh> seb128, I've hit one once, but never reproduced.
[22:36] <Sarvatt> they're all drawing theme stuff after an app crash while using murrine or clearlooks from a quick look at the bug reports across the other distros
[22:36] <bryceh> seb128, that particular instance I believe was when I was in the middle of upgrading stuff, and wondered if it might have been due to an underlying library getting changed out.
[22:36] <Sarvatt> maybe we only notice it more because of ambiance? :)
[22:37] <seb128> Sarvatt, could be
[22:39] <seb128> then you have bugs like bug #948089
[22:39] <seb128> assert !xcb_xlib_threads_sequence_lost
[22:39] <seb128> I'm pretty sure that one happens when the session doesn't close properly
[22:39] <seb128> i.e gnome-session or xorg segfault
[22:40] <seb128> I wonder if the XAllocID one is a similar red herring
[22:44] <RAOF> Entirely possible.
[22:48] <seb128> bryceh, RAOF: what about bug #926379
[22:48] <seb128> that got enough dups that launchpad timeout to open it
[22:50] <bryceh> seb128, it's unrelated to the assert bugs.  There's a patch to add logging, which has been run and given, so waiting on upstream for a fix
[22:51] <bryceh> seb128, a few more folks testing that and providing logs might help
[22:51] <seb128> bryceh, yeah, I know it's not related to the assert, but that one is concerning because it keeps collecting dups every day on unity
[22:51] <seb128> ok
[22:51] <seb128> so "needs info"
[22:52] <seb128> that seemed like something we should tackle for beta2
[22:53] <bryceh> yeah
[22:56] <bryceh> seb128, I guess the thing blocking it currently is that it's hard to reproduce synthetically
[22:56] <bryceh> or I should say, developers haven't reproduced it synthetically
[22:57] <RAOF> None of us have been able to reproduce it, have we?
[22:58] <Sarvatt> never
[22:58] <RAOF> Because this would sound like a job for apitrace™, even though the actual windows would be blank.
[22:59] <Sarvatt> oh the mesa bug
[22:59] <RAOF> Yeah, the mesa bug.
[22:59] <Sarvatt> sorry, i just popped back on for a minute and thought people were talking about the _XAllocID assert
[22:59] <RAOF> Nope :)
[23:00] <bryceh> Sarvatt, seb128 advanced the topic ;-)
[23:00] <Sarvatt> tjaalton said he hit that one
[23:01] <Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=46739
[23:22] <cnd> bryceh, I was promised warmer weather this time of year... :(
[23:23] <Sarvatt> cnd: lets trade, too freaking hot
[23:23] <cnd> Sarvatt, fine by me :)
[23:23] <cnd> Sarvatt, what have your highs been?
[23:24] <Sarvatt> 87 yesterday
[23:24] <cnd> wow
[23:24] <Sarvatt> 75 or 80 today, im not sure
[23:24] <cnd> Sarvatt, you've seen the temperature map of the US, right?
[23:25] <Sarvatt> i'm jealous every time i look at the portland weather in the indicator
[23:25] <Sarvatt> rain rain rain rain rain snow snow rain snow rain snow, highs in the 40's :P
[23:25] <cnd> I hope you're not serious...
[23:25] <Sarvatt> 100%
[23:26] <bryceh> cnd, heh who promised you nice weather in Portland in March?
[23:26] <cnd> bryceh, no one promised nice weather, but this is awful
[23:26] <cnd> this would be understandable in january
[23:26] <bryceh> cnd, yep.  March is the worst in portland
[23:26] <cnd> but not in spring
[23:26] <cnd> and I'm fine with the rain
[23:26] <cnd> it's just these frigid temperatures
[23:26] <Sarvatt> cnd: where did you move from?
[23:27] <cnd> Sarvatt, columbus, oh
[23:27] <bryceh> the snow is a bit unusual, but depressing rain is all about March in portland
[23:27] <cnd> meh, rain is fine
[23:27] <cnd> if it were in the 50s or 60s I'd have no complaints
[23:27] <bryceh> s/depressing/depressing and cold/
[23:28] <bryceh> in grade school and middle school I used to have to walk to piano lessons and home in this weather (~2 miles).
[23:28] <bryceh> builds character (and makes you want to own a car)
[23:28] <cnd> heh
[23:29] <bryceh> cnd, it'll turn around come april.  We probably won't get "nice" days until May tho
[23:29] <cnd> cool
[23:29] <cnd> well, we're not too far from april :)
[23:29] <bryceh> yep
[23:30] <bryceh> in May, this thing people call  "the Sun" sometimes shows up.  Usually high up in the sky.  Keep an eye out for it.
[23:30] <Sarvatt> my office is like 15 degrees warmer than the rest of the house and hot even with the ac blasting, thats why i'm jealous :)
[23:31] <bryceh> Sarvatt, I can turn every computer on in my office right now, and not get roasted out
[23:31] <bryceh> I can even put on t he projectors, but then I do need to crack a window
[23:32]  * RAOF drops off his car for a service.