[02:47] <RAOF> Bah.  Stupid overlayfs!  Let me build mesa!
[04:15] <Sarvatt> RAOF: pfft use schroot
[04:15] <Sarvatt> it builds fine here
[04:16]  * Sarvatt totally blames his own lack of using mk-sbuild but oh well, it works
[07:15] <Sarvatt> soo, instead of blacklisting llvmpipe they will try to fix unity?
[07:16] <RAOF> Yup.
[07:16] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nux/+bug/926859 noticed the responses when i was going through invalid 12.04 beta targetted bugs this morning
[07:16] <ubottu> Launchpad bug 926859 in unity "llvmpipe software rendering needs blacklisting in unity-support-test" [High,Confirmed]
[07:16] <RAOF> It is apparently pretty much as easy as not abusing GL.
[07:17] <RAOF> ie: Actually calling GLXSwapBuffers, rather than trying to blit bits of the backbuffer on the frontbuffer.
[07:17] <RAOF> Jason apparently has that already done, and it works.
[07:18] <Sarvatt> works for kvm?
[07:18] <tjaalton> stgraber's comment is valid
[07:18] <tjaalton> indeed, it's killing kvm
[07:19] <RAOF> But that can be trivially worked around by selecting an Ubuntu2D session, right?
[07:19] <Sarvatt> kvm is the main consumer i would care about, thats problably higher than mgi/savage/etc consumers
[07:20] <tjaalton> RAOF: yeah, but needs manual intervention :)
[07:20] <RAOF> How slow is it in kvm?
[07:21]  * RAOF should give it a whirlygig.
[07:21] <Sarvatt> if its slow thats ok more worried about not working at all
[07:21] <tjaalton> it's using 50% cpu
[07:21] <tjaalton> not that nice on the host
[07:21] <Sarvatt> oh cool
[07:21] <tjaalton> hmm, should try it out on the t23 my parents have, but the usb image I have is probably too old..
[07:22] <Sarvatt> crap but working?
[07:22] <broder> is kvm enabling all the interesting SSE instructions and so forth within the guest?
[07:22]  * Sarvatt has 1gb free hdd space, cant even screw with kvm atm
[07:22] <broder> tjaalton: what happens if you pass, uh, -cpu host
[07:23] <tjaalton> broder: dunno, stgraber? :)
[07:23] <RAOF> tjaalton: I guess that depends on what the default experience should be; do we want people, by default, to have the full Unity experience in their virtualised environment at the cost of speed, or do we want people to opt-in to the full Unity for better default CPU usage.
[07:24] <Sarvatt> yeah if it works its totally another question, would be good to hear from people who care
[07:24] <Sarvatt> it wasnt working before
[07:24] <RAOF> Blacklisting llvmpipe would result in people being basically unable to test unity3d in kvm.
[07:24] <tjaalton> RAOF: true. and could be that a _fixed_ unity might not consume that much cpu when idling..
[07:26] <broder> bah. my precise iso is about 2 weeks old
[07:26] <Sarvatt> thats ok nithng changed besides desktop crap
[07:26] <Sarvatt> nothing changed in llvmpipe at least
[07:27] <broder> well, i'm having a hard time managing to start a terminal
[07:27] <RAOF> On unity/llvmpipe?
[07:27] <broder> yeah
[07:27] <RAOF> I'm not sure if Jason's fix is in the distro yet.
[07:27] <broder> i can't tell what's glitch and what's bad performance
[07:28] <RAOF> But everything should basically be working, barring damage events not necessarily resulting in the screen being updated :)
[07:28] <RAOF> Which is a pretty big caveat :)
[07:31] <Sarvatt> good point i have no clue either, living off in the driver world but the unity/compix fixes are important to that :)
[07:31] <broder> oh! right
[07:31] <broder> kvm still has the idiocy to make 128M of ram the default
[07:32] <broder> let's try this again, but this time actually give the VM enough RAM to do anything useful
[07:33] <broder> ok. kvm -cpu host -m 2048 -cdrom Downloads/my-old-precise.iso
[07:33] <broder> compiz seems to hover at about 20% CPU when i'm just running top in a gnome-terminal
[07:34] <broder> but it jumps to 50% or so if i show and then hide the dash
[07:34] <broder> actually, more like 80% if i do it a few times
[07:35] <broder> or just drag the gnome-terminal window around a bunch
[07:41] <RAOF> Yeah, don't show the dash.
[07:42] <RAOF> It'll try to render a gaussian blur of your whole screen.
[07:42] <RAOF> That's not fast on anything that's not massively parallel.
[07:42] <broder> does SSE4.2 not count?
[07:43] <broder> or whatever other fancy instructions i have in my nehalem
[07:44] <ricotz> RAOF, hello
[07:44] <broder> anyway, my gut is that if we'd be using llvmpipe, we should probably switch to unity-2d by default, but it'd be nice if it was still possible to run unity-3d under llvmpipe for the masochists
[07:44] <broder> i'm not totally sure how i would go about swinging that if i was going to try
[07:45] <broder> i guess move you could move llvmpipe back to libgl1-mesa-dri-experimental
[07:45] <ricotz> RAOF, are you planning another mesa upload soon? could you drop the hard-deps-generation of wayland before that?
[07:45] <RAOF> broder: You'd change the unity-greeter check to start unity2d by default when llvmpipe was present, but not override a manual unity3d selection ;)
[07:46] <RAOF> ricotz: I'm not planning on another mesa upload immediately; it's beta 1 freeze.  We can certainly do that in the next upload, though.
[07:47] <ricotz> RAOF, ok, while using wayland releases instead of snapshot it seems reasonable to drop this restriction from the package
[07:47] <RAOF> I agree.
[07:48] <tjaalton> yeah I overlooked that part
[07:48] <ricotz> it only creates issues currently
[07:48] <ricotz> tjaalton, hi :)
[07:49] <tjaalton> ricotz: hi, I did notice your ping yesterday, but replied directly to pitti
[07:49] <tjaalton> shouldn't be an issue anymore?
[07:50] <ricotz> tjaalton, alright, if you update wayland it will be again
[07:51] <tjaalton> ricotz: yeah, let's fix mesa first then
[07:51] <ricotz> tjaalton, ok
[07:53] <tjaalton> hmm, not sure what needs changing though
[07:53] <tjaalton> ah it's wayland
[07:53] <tjaalton>         dh_makeshlibs -V '$(PACKAGE) (= $(V))' -- -c4
[07:54] <ricotz> yes
[08:02] <RAOF> Dear autotools: seriously?!
[08:02] <tjaalton> so they say that 0.9 will be the point where no backwards-incompatible changes will be made anymore, but after 0.85 they still might
[08:06] <Sarvatt> tjaalton: oh with mesa 8.14? cool
[08:06] <Sarvatt> basically never, didnt expect any better :)
[08:07] <Sarvatt> intel guys, living in release+1 forever because who needs anything stable
[08:08] <tjaalton> Sarvatt: huh? speaking of wayland here. mesa build-depends on wayland, not the other way around :)
[08:09] <Sarvatt> tjaalton: who does wayland?
[08:09] <tjaalton> so maybe we need that hard dep until wayland 0.9 is released?
[08:09] <Sarvatt> dont mind me just complaining
[08:09] <tjaalton> heh
[08:09] <tjaalton> ok so we won't drop it ever, thanks for confirming ;)
[08:10] <Sarvatt> http://paste.ubuntu.com/855094/ according to ricotz though
[08:12] <Sarvatt> thats what we do in edgers then build wayland against it
[08:12] <Sarvatt> err build mesa against it
[08:13] <tjaalton> so build mesa every time wayland is updated?
[08:13] <Sarvatt> tjaalton: what the hell are you doing here btw?
[08:13] <tjaalton> writing nonsense as always :)
[08:13] <tjaalton> I might ask you the same!
[08:13] <Sarvatt> nah just one time and it doesnt have a hard dependency
[08:14] <tjaalton> so you don't care about api issues?
[08:14] <Sarvatt> if theres an api issue mesa gets updated to fix it
[08:14] <Sarvatt> it wouldnt be an issue in the distro
[08:14] <Sarvatt> with released versions of wayland and mesa
[08:15] <Sarvatt> its an issue with mesa master for at most a week at a time
[08:16] <Sarvatt> especially now that theres released versions, the hard dependecies were for when it was the same version but changing which shouldn't happen anymore
[08:16] <tjaalton> yeah well we have stable mesa now, so if wayland changes incompatibly and we update it without the hard dep
[08:18] <tjaalton> oh well
[08:18] <Sarvatt> and "stable" wayland that wont get touched against in 12.04, we can revisit problems in 12.10 :P
[08:19] <RAOF> When we're switching to wayland, amiright? :)
[08:19] <Sarvatt> lol
[08:19] <Sarvatt> ohyea i forgot
[08:21] <tjaalton> I'll drop it now so we won't forget
[08:22] <Sarvatt> it'll be fine if we dont touch it again this cycle but might come up again later, screwing up 100+ packages when we update mesa sucks
[08:23] <Sarvatt> all because of wayland nothing uses or cares about except mesa
[08:23] <tjaalton> yeah
[08:24] <tjaalton> i was surprised that it's so tiny
[08:24] <tjaalton> where's all the bloat?1!
[08:25] <Sarvatt> debian/patches/500_pointer_barrier_thresholds.diff duh
[08:26] <RAOF> ?
[08:27] <Sarvatt> joking, nowhere near as bad as the old 500 xi2 patch
[08:34] <RAOF> WE HAVE (mostly, ish) WORKING TESTS FOR 500_pointer_barrier_thresholds!  YAY!
[08:38] <Sarvatt> RAOF: cool, they test twinview too where the problems always are?
[08:39] <RAOF> Absolutely!
[08:39] <Sarvatt> really?!
[08:41] <RAOF> No, I'm lying.
[09:10] <tseliot> :)
[09:12] <Sarvatt> i'm just really surprised considering how much of a hack twinview is :)
[09:12] <Sarvatt> (and how much dx seems to use it)
[09:14] <Sarvatt> breaking twinview is like the ultimate no-go, i get guaranteed 10 pings the next morning every time someone does something i have no clue about
[09:14] <Sarvatt> unity-greeter broke with twinview, ok i obviously broke that
[09:15] <Sarvatt> or have any clue what happened
[09:16] <Sarvatt> yeah i'm bitter, oh well :)
[09:17] <jcristau> "switch to nouveau"
[09:17] <jcristau> or does that answer not work? :)
[09:17] <tjaalton> nouveau is seriously lacking on newer hw though :/
[09:18] <tjaalton> dualhead might work though
[09:18] <RAOF> Also, power management is a really nifty thing to have.
[09:23] <Sarvatt> lol power management? how's that nvd0 support coming for year old laptops? 3.5 kernel maybe?
[09:24] <Sarvatt> at least vesa works in 1.11 still, one benefit to not going to 1.12 in precise
[09:24] <tseliot> who needs power management anyway? It's nice to have something warm beside you in the winter ;)
[09:25] <jcristau> tseliot: people on the wrong side of the world
[09:25] <jcristau> (hi, RAOF)
[09:25] <jcristau> :)
[09:25] <tseliot> :D
[09:25] <RAOF> :P
[09:25] <Sarvatt> tseliot: whats the weather like where you are now? 22C here in winter, ugh!
[09:26] <RAOF> Sarvatt: Where are *you* that it's 22C?
[09:26] <tjaalton> +-0C here
[09:26] <Sarvatt> lol
[09:26] <jcristau> we had -10C a couple weeks ago
[09:26] <Sarvatt> RAOF: i'm in winter
[09:27] <tjaalton> been kinda wet the past few days, still lot of show
[09:27] <tjaalton> snow even
[09:27] <tseliot> Sarvatt: wow, that's warm. It's 11-14 °C during the day here
[09:27] <RAOF> It tops out at 22Cish *here*
[09:27] <Sarvatt> this is the first winter where i didn't see snow ever
[09:28] <Sarvatt> only time it snowed was when we were in budapest :)
[09:28] <tseliot> :)
[09:29] <Sarvatt> :)? you skipped out on budapest, bah! :)
[09:29] <Sarvatt> tseliot: are you going to be in orlando?
[09:30] <tseliot> yes, but at least I got hail twice here ;)
[09:30] <tjaalton> oakland?
[09:30] <tseliot> Sarvatt: do you mean Oakland?
[09:30] <Sarvatt> tseliot: wait, are you moving back to OEM/premium? i havent even asked ya yet
[09:30] <tseliot> Sarvatt: no, I'm not going anywhere
[09:30] <Sarvatt> tseliot: yeah totally, i keep calling oakland orlando, whats wrong with me
[09:31] <Sarvatt> really? ya like it in HWE?
[09:31] <tseliot> Sarvatt: wrong coast ;). But no, unfortunately I won't be able to attend
[09:31] <tseliot> Sarvatt: yes, I really like it :)
[09:31] <Sarvatt> boo, thats 3 you skipped out on in a row! :)
[09:31] <Sarvatt> X team dinner wont be the same
[09:31] <tjaalton> oakland auckland.. only a few km apart
[09:32] <Sarvatt> our crappy cuban sandwiches and guinness :)
[09:32] <tjaalton> i want to witness tseliot drinking guinness
[09:32] <tseliot> Sarvatt: yes, well, hopefully I'll be there in October (in Europe, I assume)
[09:33] <tseliot> tjaalton: oh, you didn't in Dublin. I'll do it again, just for you ;)
[09:33] <tjaalton> tseliot: :)
[09:34] <Sarvatt> tseliot: wait you were in dublin? i dont even remember, they had us segreated off to another floor from the desktop guys
[09:35] <Sarvatt> but we shoulda been near you because you were in OEM then
[09:35] <tseliot> Sarvatt: I spent quite some time in the Desktop team's room though
[09:35] <Sarvatt> lucky! you got crap done
[09:36] <tseliot> Sarvatt: yep :)
[09:39] <Sarvatt> i think tjaalton got the most done in hwe during that sprint because he was sitting at the boring table :)
[09:39] <tjaalton> hah
[09:40] <Sarvatt> updated -ati to work on llano
[09:40] <tjaalton> oh I did?
[09:40] <Sarvatt> yup, i remember asking you to do a git snapshot for that reason
[09:40] <Sarvatt> i was uh
[09:40] <Sarvatt> playing with minimodem
[09:40] <RAOF> cnd: Hey, would you be planning to factor out some of the xorg testing fun in utouch-geis and utouch-frame into xorg-gtest?  I'm thinking particularly of the pump event loop thingy, which I want want want right now.
[09:41] <RAOF> Because stupid async!
[09:41] <tjaalton> oh I committed some wayland upstream-ubuntu branch
[09:41] <Sarvatt> sending 2400 baud messages to other pcs in hopes it'd save me from having to press power thousands of times while state got shoved into the rtc
[09:42] <tseliot> :)
[09:42] <tjaalton> yeah I remember you playing with it.. funny stuff :)
[09:42] <Sarvatt> tjaalton: before that i spent 2 months pressing power
[09:43] <Sarvatt> i was really happy that things might be easier :)
[09:43] <tjaalton> hm no the funny part was manjos irc msg speech synthesizer
[09:43] <Sarvatt> lmao
[09:43] <tjaalton> minimodem was just cool
[09:43] <Sarvatt> i still screw with him now with the speech synthizer
[09:44] <Sarvatt> in #hwe say, I don't like vietnamese women.
[09:44] <tjaalton> rude :)
[09:45] <Sarvatt> his wife hears it, yeah :)
[09:45] <Sarvatt> he's rude, it's fun screwing with him
[09:46] <Sarvatt> tseliot: you're realling going to update wl?
[09:46] <Sarvatt> i wish we could just sync it from debian
[09:46] <Sarvatt> is dkms still not used in debian?
[09:46] <tseliot> Sarvatt: if it doesn't break apw's wireless, then yes
[09:47] <Sarvatt> tseliot: balls, it broke his wireless in october when you tried
[09:47] <tseliot> Sarvatt: I'm not sure, I haven't used debian since Etch...
[09:47] <Sarvatt> probably will break it
[09:47] <tseliot> (which I still have somewhere)
[09:47] <tseliot> yes, this is why I asked him to test it
[09:47] <Sarvatt> yea debian wl uses m-a
[09:47] <Sarvatt> screw that
[09:47] <tseliot> :/
[09:48] <Sarvatt> they keep it up to date really often though
[09:48] <apw> heh ... i have two machines now which can use wl, one now is supported by the main kernel
[09:49] <tseliot> so maybe they haven already broken his wireless in Debian ;)
[09:49] <apw> but this other one still needs it
[09:49] <Sarvatt> "supported" or supported?
[09:49] <tseliot> *have
[09:49] <jcristau> Sarvatt: dkms is used in debian
[09:49] <Sarvatt> is it?
[09:49] <Sarvatt> hmmmmmmmmmm
[09:49] <apw> Sarvatt, one i use for travel, is on the kernel driver 
[09:49] <apw> and is very good
[09:49] <jcristau> dunno about wl though
[09:49] <jcristau> but in general, yeah
[09:50] <jcristau> i haven't used an oot driver since before dkms existed though :)
[09:50] <Sarvatt> brcmsmac spams my dmesg at least 1MB a day
[09:50] <apw> heh that doesn't supprise me :)
[09:52] <Sarvatt> -rw-r----- 1 syslog adm 9.1M Feb 24 04:50 /var/log/kern.log
[09:52] <Sarvatt> its all 
[09:52] <Sarvatt> [29862.537191] ieee80211 phy0: START: tid 1 is not agg'able
[09:52] <Sarvatt> [29867.905498] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[09:52] <Sarvatt> repeat
[09:53] <Sarvatt> means a lot, thanks broadcom
[09:53] <apw> there is indeed a lot of debug level crap emitted at too high a level, thats all the sort of thing that being in staging is meant to beat it out of them
[09:54] <Sarvatt> jcristau: hmm sounds like our brcmwl-kernel-source could be merged to debian to use dkms instead of m-a then
[09:55] <Sarvatt> m-a is the devil
[09:55] <jcristau> oot drivers are the devil ;)
[09:55] <Sarvatt> im fine with it but my wife isn't
[09:55] <jcristau> but, yeah.
[09:55] <Sarvatt> yeah thats true too :)
[09:56] <Sarvatt> automatically building with kernel updates instead of manually rebuilding though..
[09:57] <jcristau> ack
[09:57] <Sarvatt> theres a chunk of nics where it has to happen, brcmsmac doesn't cover some crap like macbooks
[10:00] <RAOF> Dear lord?  Macbooks with poorly supported hardwar?  Now there's a pleasant change of pace.
[10:01]  * apw enjoyed the juxtaposition of "crap" and "macs"
[10:01] <Sarvatt> cmacs!
[10:02] <Sarvatt> 4 people will know what i mean when i call them that next
[10:03] <Sarvatt> (yes i picked an arbitraty number)
[10:03] <Sarvatt> tseliot: brcm-wl from october works fine on my machine, where are you updating to?
[10:05]  * Sarvatt has been manually recompiling against each new kernel
[10:05] <apw> Sarvatt, i note that the phonetic spelling of that should be see-macs
[10:05] <Sarvatt> totally x related
[10:05] <tseliot> Sarvatt: 6.20.55.19
[10:05] <tseliot> oh, where
[10:06] <Sarvatt> tseliot: so i had a problem with your same driver in dkms form that i was compiling manually 5 months ago 
[10:07] <tseliot> Sarvatt: what problem?
[10:07] <Sarvatt> it didnt work
[10:07] <tseliot> oh
[10:07] <Sarvatt> i'll try the new one
[10:07] <tseliot> thanks
[10:08] <Sarvatt> they renamed the driver or something
[10:08] <Sarvatt> i thing that was the issue i had at the time
[10:08] <Sarvatt> think
[10:08] <Sarvatt> bah
[10:08] <Sarvatt> 5 am
[10:09] <tseliot> unfortunately I don't have a device to test the driver any more
[10:10] <Sarvatt> really? ok will absoltely test it, grabbing your source from chinstrap
[10:20] <tseliot> thanks
[10:20] <tseliot> my netbook died
[10:23] <Sarvatt> broadcom drivers kill it?
[10:27] <Lekensteyn> hi, any change that https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/931397 will be fixed before the beta?
[10:27] <ubottu> Launchpad bug 931397 in xorg-server (Ubuntu) "Xorg crashes with AutoAddDevices "false"" [High,Confirmed]
[10:28] <jcristau> send a patch?
[10:32]  * Lekensteyn is downloading the daily image
[14:25] <Lekensteyn> bryceh: ping?
[14:42] <Lekensteyn> Any change that 1.11.5 is going to land in Precise?
[14:42] <cnd> RAOF, yeah, I plan on xorg-gtest being expanded over time
[14:43] <cnd> the tricky part is that utouch-evemu is under CLA
[14:43] <cnd> and some people don't like that
[14:43] <cnd> but maybe they won't notice :)
[14:43] <cnd> I was at the gtk hackfest, and they said they didn't mind it
[14:58] <stgraber> tjaalton: I updated bug 926859
[14:58] <ubottu> Launchpad bug 926859 in unity "llvmpipe software rendering needs blacklisting in unity-support-test" [High,Confirmed] https://launchpad.net/bugs/926859
[14:59] <stgraber> tjaalton: and I'll bring it up at the release meeting, will also be on the next techboard agenda if llvmpipe hasn't been blacklisted in unity-support-test by then...
[15:37] <Lekensteyn> Ubuntu' 1.11.4 != Xorg 1.11.4 right?
=== yofel_ is now known as yofel
[16:41] <technoviking> RAOF: ping
[17:03] <tjaalton> stgraber: ok, good to know (didn't read the bug yet)
[17:04] <tjaalton> Lekensteyn: right, the input stack is from 1.12
[17:07] <Lekensteyn> tjaalton: is that 1.11.99.903?
[17:09] <Lekensteyn> I saw that the InputOption type has changed between 1.11.4 and 1.11.99.902
[17:09] <Lekensteyn> so, carelessly copying changes breaks things
[17:10] <Lekensteyn> it's not a key, value, next struct anymore
[17:12] <tjaalton> merged from master, more likely
[17:31] <bdmurray> RAOF: perhaps a hybrid-gfx tag, set by apport, would be useful?  I'm looking at bug 939283.
[17:31] <ubottu> Launchpad bug 939283 in plymouth (Ubuntu) "[hybrid-gfx] Blank screen on boot due to failure to follow primary framebuffer" [High,New] https://launchpad.net/bugs/939283
[18:27] <bryceh> Lekensteyn, yeah looks like you need cnd to look at that bug #931397
[18:27] <ubottu> Launchpad bug 931397 in xorg-server (Ubuntu) "Xorg crashes with AutoAddDevices "false"" [High,Confirmed] https://launchpad.net/bugs/931397
[18:28] <cnd> bryceh, yeah
[18:28] <cnd> I'm subscribed or assigned
[18:28] <cnd> I think it's a bug introduced by backporting
[18:28] <Lekensteyn> cnd: are you chase douglas?
[18:29] <cnd> Lekensteyn, yep
[18:29] <cnd> Lekensteyn, you can use "/whois cnd" in the future :)
[18:30] <Lekensteyn> true :)
[18:31] <Lekensteyn> Xorg -configure crashes as well
[18:31] <bryceh> cnd, from comment #2 wondering if it still needs the bits from that duplicateDevice call, which converts the pointer type?
[18:32] <Lekensteyn> when debugging I suggest to build with DEB_BUILD_OPTIONS=noopt or gdb will behave weird when setting some breakpoints
[18:33] <cnd> Lekensteyn, I usually use DEB_BUILD_OPTIONS="noopt nostrip noudev nocheck parallel=<n>"
[18:33] <bryceh> Lekensteyn, thanks for doing the extra gdb legwork btw, not many do, but it helps a lot.
[18:33] <cnd> yeah
[18:33] <cnd> +1 :)
[18:34] <Lekensteyn> your welcome, I've received some queries about it from users who have an nVidia Optimus laptop model
[18:34] <Lekensteyn> that needs to be fixed ;)
[18:35] <bdmurray> bryceh: bug 930004 and bug 930839 are both crashes in xcb during distribution upgrades.
[18:35] <ubottu> Launchpad bug 930004 in update-manager (Ubuntu) "update-manager assert failure: python: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed." [Medium,Confirmed] https://launchpad.net/bugs/930004
[18:35] <ubottu> Launchpad bug 930839 in update-manager (Ubuntu) "update-manager crashed with SIGABRT in __assert_fail_base(): Assertion !xcb_xlib_unknown_req_in_deq failed in dequeue_pending_request" [Medium,Confirmed] https://launchpad.net/bugs/930839
[18:36] <bryceh> bdmurray, looking
[18:36] <bryceh> heh, like the description in the latter
[18:36] <bdmurray> yeah, that's a gem
[18:39] <bryceh> bdmurray, often xcb issues are races in threading behaviors, that can be quite challenging to sort out.  So if there's a set of steps to reproducing it, that'd likely help a good bit.
[18:43] <bdmurray> bryceh: is this helpful?
[18:43] <bdmurray> ERROR:root:NvidiaDetection returned a error: __init__() got an unexpected keyword argument 'datadir'
[18:43] <bdmurray> MarkUpgrade() called on a non-upgrable pkg: 'brasero'
[18:43] <bdmurray> ERROR:root:Upgrading 'brasero' failed
[18:43] <bdmurray> [xcb] Unknown sequence number while processing queue
[18:43] <bdmurray> [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[18:43] <bdmurray> [xcb] Aborting, sorry about that.
[18:43] <bdmurray> python: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
[18:43] <bryceh> bdmurray, yeah sounding like a client error
[18:44] <bdmurray> hrm
[18:44] <bryceh> looking in libx11
[18:45] <bryceh> "Most likely this is a multi-threaded client and XInitThreads has not been called" sounds relevant (and familiar...)
[18:49] <bryceh> bdmurray, wonder if it's a protocol mismatch between client app and server?
[18:50] <bdmurray> oh, like if libxcb updated and update-manager hadn't yet?
[18:51] <bryceh> something like that's what I'm wondering.  
[18:52] <bryceh> as you probably already gathered, this fault is happening during the client polling of the X server, and it gets some response it didn't expect
[18:52] <bryceh> if we knew roughly how to trigger this bug, we could probably set up xtrace between the client and server to see  what the communication is between them
[18:54] <bryceh> here's the test that seems to be failing:
[18:54] <bryceh> XLIB_SEQUENCE_COMPARE(req->sequence, >=,
[18:54] <bryceh>                                        dpy->xcb->pending_requests->sequence)
[18:55] <bryceh> actually wait, it's not an unknown request but rather an unknown sequence number
[18:55] <bryceh> not sure what a sequence number is in this context
[18:56] <bryceh> so not that, but this:
[18:56] <bryceh> (XLIB_SEQUENCE_COMPARE(event_sequence, >,
[18:56] <bryceh>                                                   dpy->request)
=== Lekensteyn is now known as Lekensteyn|dinne
[18:57] <bryceh> bdmurray, ok reading further... bunch of warning text regarding threading
[18:57] <bryceh> bdmurray, ok yeah so I'll paste the text into the bug report
[19:00] <bryceh> bdmurray, ok I'm finally remembering.  When we first switched to xcb, we had a huge spate of these types of bugs.  libxcb is more sensitive to how it's called in threading conditions, so the client code needs to be careful to make the calls properly
[19:01] <bryceh> bdmurray, so the assert that's being tripped is not a bug in X but rather is catching a bug in the client code
[19:01] <bryceh> at least, I think.
[19:02] <bryceh> I could be talking out of my ass.  That would hardly be new.
[19:06] <bryceh> bdmurray, ah, so bug 930004 looks like the threading issue I mentioned
[19:06] <ubottu> Launchpad bug 930004 in update-manager (Ubuntu) "update-manager assert failure: python: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed." [Medium,Confirmed] https://launchpad.net/bugs/930004
[19:06] <bryceh> bug 930839 may be the mismatched client/server issue I mentioned previously.
[19:06] <ubottu> Launchpad bug 930839 in update-manager (Ubuntu) "update-manager crashed with SIGABRT in __assert_fail_base(): Assertion !xcb_xlib_unknown_req_in_deq failed in dequeue_pending_request" [Medium,Confirmed] https://launchpad.net/bugs/930839
[19:07] <bryceh> again though, kinda just guessing here.  Both appear to be client errors that XCB is catching (i.e. both are assertion fails), rather than actual segfaults in X
[19:16] <bryceh> bdmurray, #901675 is another similar bug in apport
[19:18] <bdmurray> okay, thanks
[19:18] <bryceh> another in g-s-d - 833694
[19:18] <bryceh> hmm
[19:19] <bryceh> bdmurray, ahh https://bugzilla.gnome.org/show_bug.cgi?id=657255#c8
[19:19] <ubottu> Gnome bug 657255 in gsettings "gnome-settings-daemon assert failure: gnome-settings-daemon: ../../src/xcb_io.c:575: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed." [Critical,Resolved: fixed]
[19:24] <bdmurray> um, where does that leave us?
[19:26] <bryceh> bdmurray, can you raise it with the upstream-manager folks to look into?
[19:26] <bryceh> bdmurray, it's not an X bug
[19:26] <bdmurray> upstream-manager?
[19:27] <bryceh> (I mean, aside from the fact that libxcb is sensitive to threading issues...)
[19:27] <bryceh> update-manager
[19:27] <bdmurray> ah okay
[19:38] <bdmurray> bryceh: but in bug 832513 they say it should be fixed in libglib2.0-0
[19:38] <ubottu> Launchpad bug 832513 in GLib "gnome-settings-daemon assert failure: gnome-settings-daemon: ../../src/xcb_io.c:575: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed." [Critical,Fix released] https://launchpad.net/bugs/832513
[19:40] <bryceh> bdmurray, it's not the same bug, just different codebases making similar coding errors and hitting the same assertion
[19:41] <bryceh> bdmurray, it'd be like two C applications getting the same error message from gcc; it doesn't mean they have the same bug, nor that gcc is broken, just that they both happened to have the same kind of programming error.
[19:45] <bdmurray> bryceh: okay, thanks again for the help
[19:52] <bryceh> bdmurray, sure thing, let me know if you need more help
=== Lekensteyn|dinne is now known as Lekensteyn
=== Lekensteyn is now known as Lekensteyn|off