[01:02] <RAOF> bryceh: Revised mesa with better changelog, debian changelog in source.changes, and actual building on i386 is up on cooperteam.net.
[01:05] <bryceh> RAOF, awesome thanks
[01:06] <RAOF> Oh, and perhaps incidentally, it also works ;)
[01:06] <bryceh> RAOF, btw the previous mesa had been failing to build
[01:06] <bryceh> # Also get rid of other files which aren't installed. Do not
[01:06] <bryceh> # use -f to ensure we notice disappearing files:
[01:06] <bryceh> set -e; for file in dri/usr/include/GL/glfbdev.h dri/usr/include/GL/glu.h dri/usr/include/GL/glu_mangle.h dri/usr/include/GL/mesa_wgl.h dri/usr/include/GL/osmesa.h dri/usr/include/GL/vms_x_fix.h dri/usr/include/GL/wglext.h dri/usr/include/GL/wmesa.h dri/usr/lib/libGL.so dri/usr/lib/pkgconfig/gl.pc usr/include/GL/glext.h usr/include/GL/glfbdev.h usr/include/GL/gl.h usr/include/GL/gl_mangle.h usr/include/GL/glxext.h usr/include/
[01:06] <bryceh> v/pkgconfig/gl.pc ; do rm debian/tmp/$file; done
[01:06] <bryceh> rm: cannot remove `debian/tmp/usr/lib/i686/cmov/libGL.so': No such file or directory
[01:06] <bryceh> make: *** [binary-arch] Error 1
[01:06] <bryceh> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
[01:06] <bryceh> E: Failed autobuilding of package
[01:06] <RAOF> bryceh: Yeah, that's what I fixed for i386.
[01:06] <bryceh> hadn't had a chance to investigate it yet though.  Will try again with your new package
[01:06] <RAOF> if you were to build that package on amd64 it would have built just fine :) 
[01:07] <RAOF> It's becaues Debian build i686 swrast packages on i386 and we don't.
[01:07] <RAOF> Or even because.
[01:08] <bryceh> huh interesting
[01:08] <bryceh> dpkg-source: info: upstream files that have been modified: 
[01:08] <bryceh>  mesa-7.10.1~git20110215.cc1636b6/src/mesa/drivers/dri/common/dri_util.c
[01:08] <bryceh>  mesa-7.10.1~git20110215.cc1636b6/src/mesa/drivers/dri/radeon/radeon_bocs_wrapper.h
[01:08] <RAOF> Yeah.  From debian's cherry-picks.
[01:09] <RAOF> Debian cherry-picks into the debian diff, and I think we should too.
[01:09] <RAOF> It means the cherry-picks get automatically dropped when they get included in the upstream tarball.
[01:12] <RAOF> Hm.  Sam's out at work.  I'll have to make my *own* coffee this morning!
[01:16] <bryceh> heh
[01:16] <bryceh> I will be joining you in a cup, even though it's after 5pm
[01:31] <bryceh> go little processor go, let's get this mesa built
[01:32] <RAOF> I could throw up binaries if you wanted.
[01:35] <bryceh> nah it just finished
[01:35] <bryceh> might not be a bad idea in the future though
[01:36] <bryceh> otoh can't hurt to doublecheck the build
[01:37] <bryceh> I'm installing libgl1-mesa-dri_7.10.1~git20110215.cc1636b6-0ubuntu1_i386.deb libgl1-mesa-glx_7.10.1~git20110215.cc1636b6-0ubuntu1_i386.deb libgles2-mesa_7.10.1~git20110215.cc1636b6-0ubuntu1_i386.deb
[01:38] <bryceh> anything else worth putting in for testing purposes?
[01:38] <bryceh> well, lets start with this... rebooting
[01:39] <RAOF> ...
[01:39]  * RAOF is too slow :)
[01:43] <bryceh> metacity looks fine...
[01:44] <bryceh> ew, unity looks like trash
[01:45] <RAOF> What card?
[01:45] <bryceh> RV770
[01:46] <bryceh> actually it was fine after I did a screen refresh
[01:46] <bryceh> guessing it's a dual-head issue, since only the left screen showed it
[01:47] <RAOF> Ah, yeah, entirely possible.
[01:47] <bryceh> (it redrew the left portion of the screen in the middle of the screen)
[01:47] <bryceh> anyway, otherwise so far so good
[01:47] <RAOF> Nux is easily confused about where things should be.
[01:47] <bryceh> also to be honest I'm not sure that effect might have been there previously
[01:47] <RAOF> Apart from, I presume, alt-tab still segfaulting in mipmap generation code :)
[01:47] <bryceh> oh yeah lemme try that
[01:48] <RAOF> (Still segfaulted here, and also did so on master, so I'm quite confident that yours will segfault too ;))
[01:48] <RAOF> Oh.  That looks ominous!
[01:49] <bryceh> yep sure did
[01:49] <bryceh> also, left screen weirdness reproduces 2-for-2
[01:49] <RAOF> Is there any dynamic xrandr happening?
[01:49] <bryceh> fonts are all stretched out 
[01:50] <RAOF> Is gdm cloned, and on login unity starts before g-s-d sets up the spanned desktop?
[01:50]  * RAOF doesn't see that, possibly because g-s-d sets up the second head before unity has got far enough to care.
[01:50] <bryceh> gdm is not cloned
[01:51] <RAOF> Although it sounds exactly like what happens when I plug or unplug a second head.
[01:51] <bryceh> I set up side-by-side dual head and set as system default
[01:51] <bryceh> so login prompt appears only on the left screen
[01:51] <bryceh> but
[01:51] <bryceh> I have a bunch of apps that start up in my .xprofile
[01:51] <bryceh> and I've found they sometimes will initiate prior to the window manager being "done" loading
[01:52] <bryceh> so I get fun things like xchat not having the themed decorations, and gnome-terminal windows that shift around once the panels launch
[01:53] <bryceh> goodness unity is buggy
[01:54] <bryceh> if the launcher is over a gnome-terminal session, gnome-terminal appears to steal the mouse events
[01:54] <RAOF> I should possibly take up Jason's call and do the (apparently pretty easy) dynamic xrandr integration stuff.
[01:54] <RAOF> Hm, that doesn't happen here :)
[01:55] <bryceh> fwiw I'm also running apw's 2.6.38-4-generic pre-release kernel thingee, although that probably doesn't matter
[01:55] <bryceh> (however now plymouth works all of a sudden)
[01:56] <RAOF> Heh!
[01:56] <cnd> RAOF, bryceh: an update: I've got touch events integrated into the pointer event stream properly now
[01:56] <cnd> after redoing most of the stack
[01:56] <RAOF> cnd: Yay!
[01:56] <bryceh> ironically for ~1-2 min boot it displays the ubuntu logo for barely 1 sec
[01:56] <cnd> I'm now just fixing up touch event handlin
[01:56] <cnd> g
[01:57] <cnd> the code is a bit of a mess right now, so once I have it working I need to clean it up a little
[01:57] <RAOF> cnd: I think it's a fair call that Xserver 1.10 is not being released today; when do you want to incorporate Xi 2.1?L
[01:57] <cnd> but it will still be hairy when it's ready to go, probably early next week
[01:57] <bryceh> cnd, so I take it you wouldn't like to hear that the unity guys want us moved back to xserver 1.9 so -nvidia will work?
[01:57] <cnd> bryceh, (!)?
[01:57] <cnd> as in, roll back for natty?
[01:58] <cnd> or roll back just for right now?
[01:58] <cnd> I had heard the nvidia drivers still worked, but there was some politics with abi versioning and the distro
[01:58] <bryceh> cnd, just kidding (although they did ask...)
[01:58] <cnd> gah!
[01:58] <cnd> if you can't tell, I'm a bit on edge...

[01:59] <cnd> been working the last 11 days straight
[02:00] <cnd> and I've been bashing my head against the wall trying to figure out pointer grabs :)
[02:00] <cnd> took me three days to figure it out
[02:00] <cnd> there can't be many people in the world who understand it...
[02:00] <RAOF> The few, and the proud.
[02:00] <cnd> I'd venture a guess of only 3 now :)
[02:01] <cnd> I can't say I'm very proud
[02:01] <cnd> I'm very afraid
[02:01] <bryceh> that kinda describes a lot on the XInput side of things
[02:01] <cnd> afraid that any time there's a bug in xinput now, I'll have to handle it :)
[02:02] <bryceh> yay!
[02:02] <RAOF> I'm not sure that should be a fear so much as a certainty.
[02:02] <cnd> :(
[02:02] <cnd> ok, it's 9 PM here and I think things are headed in the right direction
[02:03] <cnd> so I'm going to call it quits for the evening
[02:03] <bryceh> night cnd
[02:03] <cnd> bryceh, RAOF: btw, when would you say is drop dead date for getting stuff into ubuntu before feature freeze?
[02:03] <cnd> I'm aiming to have things ready on monday, but just in case
[02:04] <RAOF> Absolutely drop-dead?  Probably wednesday evening, my time.
[02:04] <cnd> RAOF, ok, hopefully it doesn't come to that :)
[02:04] <cnd> btw, I'll be dropping X MT support for trackpads...
[02:05] <cnd> I just don't think the protocol makes sense for trackpads as it is
[02:05] <cnd> so it'll sadly just be touchscreens that get all the gooey xi 2.1 stuff
[02:05] <RAOF> If push comes to shove I can do another FF firedrill.
[02:05] <cnd> RAOF, I don't think anyone wants that again :)
[02:05] <bryceh> hmm, I probably should focus on wayland for a few days and get some stuff updated there before FF
[02:06] <RAOF> Yeah, probably a winner.
[02:06] <RAOF> Hm. I wonder if “doesn't absolutely suck when plugging in monitors” would be regarded as a Unity feature :)
[02:07] <bryceh> RAOF, the real question is do we have any recourse when it does?
[02:07] <bryceh> I mean, aside from classic ;-)
[02:07] <RAOF> Well, that would be a slam-dunk FFe I guess.
[02:12] <RAOF> Does this work now that I'm no longer strnduping a random memory address?  Lets ask Science!
[02:15]  * apw wonders if others have noticed as sudden change in brightness control, i think i am getting 3 brightness changes for each key press ... confirmed there is only on press in the input stream
[02:15] <bryceh> RAOF, I'm going to call this mesa good.  I've run several gl-ish things and am satisfied it's not going to bugger children.  Any last minute regrets?
[02:15] <apw> RAOF, does unity dump core for you if you plug a wide monitor into your intel kit?  if i end up with more than 2k width it just exits
[02:16] <RAOF> bryceh: I haven't thought of any regrets yet :)
[02:16] <bryceh> alrighty here we go
[02:17] <RAOF> apw: I “happily” get above 2k width (modulo the crazy positioning), but this is a GM45 which has a nice big texture limit.
[02:17] <RAOF> Canonical should sponsor me a couple of nice big monitors so I can test other, non-laptop things :)
[02:18] <apw> yeah i hear its a texture limit
[02:19] <RAOF> compiz probably shouldn't dump core, but it also probably won't work.
[02:19] <bryceh> it should refuse to start up in such a case
[02:19] <RAOF> Unless dx feels like making compiz use RandR 1.4 where available.
[02:20] <RAOF> At which point it actually *could* work, as long as no head is individually > any of the texture limits.
[02:20]  * RAOF suspects RandR 1.4 support is *way* down the TODO.
[02:20] <apw> so it sounds like there no plan to fix this?
[02:21] <apw> that common platforms will be working, plug in a projector and blam
[02:21] <RAOF> Does metacity kick in nicely?
[02:21] <apw> nope you end up dead in the water with no window manager, well last i checked
[02:21] <RAOF> If nothing else, that should be fixed.
[02:21] <bryceh> [ubuntu/natty] mesa 7.10.1~git20110215.cc1636b6-0ubuntu1 (Accepted)
[02:22]  * apw sighs, one more thisn to test
[02:22] <RAOF> Woot!  Now that I'm not trying to copy a random piece of memory as a file path this works :)
[02:22] <apw> bryceh, more fun coming down the pipe?
[02:24] <RAOF> Well, it will at least allow nvidia users to test unity :)
[02:25] <apw> ohh that reminds me, i am seeing corruption on scroll in gnome-terminal, sort of foreground stippling over the text
[02:25] <bryceh> alright that's enough unity for me
[02:25] <apw> have been for some time, known?
[02:25] <bryceh> apw, yep new mesa snapshot
[02:25] <apw> heh fun fun fun
[02:26] <bryceh> apw, funny you should ask, I just went through a bunch of terminal corruption bugs today
[02:26] <apw> hopefully that -4 kernel will be accepted tommrrow, seems i missed the AAs today
[02:26] <bryceh> crap, forgot to test that with unity
[02:26] <bryceh> apw, anyway so far there are 3 different terminal corruption bugs we know about (all different)
[02:26] <apw> i see it come and go on scroll up, and at times i have felt it was 'repeatable' such that a scroll down where available would reverse it
[02:27] <apw> heh, then till some of those are gone i'll assume its known :)
[02:27] <apw> is that a compiz issue or more mesa-ery
[02:28] <bryceh> my guess would be you're having this one - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/717114
[02:28] <ubot4> Launchpad bug 717114 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack with terminal programs (affects: 4) (dups: 1) (heat: 22)" [Medium,Incomplete]
[02:29] <bryceh> apw, at this point we don't know what's to blame.  I posted some questions to the bug to help narrow it down
[02:29] <bryceh> apw, any thoughts or insights you can share might help (e.g. maybe you can help rule out the kernel as a suspect)
[02:30] <apw> yeah see them
[02:30] <bryceh> offhand I'm going to guess we have some mesa issues, and I'm curious if raof's new mesa I just uploaded will help
[02:30] <apw> i'd say its improved, is less reproducible recently
[02:31] <apw> i've been ignoring it, i'll try and get a feel for how often i really see it
[02:31] <apw> and then try out the older kernel
[02:33] <apw> bryceh, i assume you know what it looks like.  i have it right now in a wndow where scrolling down one shows it, one more and its ok again and reversing through the same 3 lines seems the same
[02:34] <bryceh> apw, here's what I'm guessing - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/710961/+attachment/1831040/+files/Still-Present.png
[02:34] <ubot4> Launchpad bug 710961 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack (dup-of: 717114)" [Undecided,Incomplete]
[02:34] <ubot4> Launchpad bug 717114 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack with terminal programs (affects: 4) (dups: 1) (heat: 22)" [Medium,Incomplete]
[02:34] <apw> looking closly at it, the 'dammage' is actually a ghost of what was on that line before the scroll, about half the lines vertically have not been cleared
[02:36] <bryceh> apw, is this with compiz or without?  (Classic Desktop w/out effects?)
[02:36] <apw> its more pronnounced than that, but the same range, exactly two lines of fookage each time it occurs
[02:36] <apw> this is with unity, compiz
[02:37] <apw> the example there is also exactly two lines of text which are bust
[02:37] <RAOF> Hm.  That looks a bit like the damage bug that got fixed in -1ubuntu6.
[02:37] <bryceh> alright lemme restart into unity and try reproducing it myself
[02:38] <apw> RAOF, i updated earlier today, whats that version of so i can check
[02:38] <RAOF> xserver-xorg-video-intel; it's quite old, though, so you almost certainly already have it.
[02:39] <apw> 2:2.14.0-1ubuntu9
[02:39] <apw> bryceh, i find that its normally most obvious in a long less
[02:39] <apw> i also note its pretty much output specific
[02:40] <apw> ie if you see it on a couple of lines of a less output, it willl  be there again if you scroll
[02:40] <apw> a few pages away and back to the same point
[02:41] <RAOF> That's a bit strange.  I don't think there's anything Xy that should do that sort of caching except for the glyph cache.
[02:43] <RAOF> And that doesn't look like glyph cache corruption.
[02:45] <bryceh> hmm, not seeing anything weird with xterm+less+kern.log or gnome-terminal+less+kern.log
[02:46] <bryceh> well, with xterm I notice the border seems messed up
[02:46] <bryceh> ah not messed up, just transparent.  Weird.
[02:47] <bryceh> compiz shadow is really irritating
[02:47] <apw> RAOF, ok this corruption is definatly in the window, it can be covered and exposed and its still in there
[02:48] <bryceh> apw do you see it *only* with terminals or does it show up in any other client apps?
[02:48] <bryceh> e.g. scrolling slashdot.org in firefox
[02:48] <apw> i have never notices any corruption of anything else no
[02:49] <apw> not for launchpad pages for instance which i use almost as much
[02:49] <RAOF> Hm.  (a) why is the crda regulatory daemon setting my zone to FR, (b) my, aufs is generating a lot of dmesg backtraces.
[02:50] <bryceh> hmm, unity is significantly more tolerable with gnome-panel manually launched
[02:50] <RAOF> xterm doesn't seem to be having any troubles here.
[02:50] <bryceh> yeah no corruption for me either
[02:51] <bryceh> apw, what video driver, -intel?
[02:51] <apw> http://people.canonical.com/~apw/misc/corruption.png
[02:51] <apw> intel yes
[02:51] <apw> this is a N450 netbook
[02:51] <bryceh> oh you know what, I override the default terminal theme stuff
[02:51] <RAOF> That looks like it's reasonably easy to generate?
[02:52] <RAOF> N450 means... i945?
[02:53] <apw> note that the shadowing is clearly text which is not on the window, but has been visible recently
[02:53] <apw> 00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller
[02:54] <RAOF> The shadowing?  You mean, the interleaved text?  That looks like it's from quite nearby in the buffer.
[02:54] <RAOF> apw: grep "intel(0): Chipset:" /var/log/Xorg.0.log?
[02:54] <apw> yeah its from nearby but not the page above or below
[02:54] <apw> [    13.397] (--) intel(0): Chipset: "Pineview GM"
[02:55] <bryceh> yeah even with default theme, not reproducing on -ati / rv770
[02:55] <RAOF> Not reproducing on GM45
[02:55] <bryceh> although this is with the new mesa and your -rc4 kernel
[02:56] <RAOF> Ok. g33
[02:56] <RAOF> Ah, that's why unity hates big screens, too.
[02:57] <RAOF> (For you).
[02:57] <apw> yeah a very very common platform, we need to replace all those macs in design with soemthing normal people have
[02:57] <apw> so they get some pain from these kinds of bugs
[02:57] <bryceh> mm, this is new:
[02:57] <bryceh> [  685.163321] [drm:subconnector_show] *ERROR* Unable to find subconnector property
[02:57] <bryceh> [  685.163349] [drm:select_subconnector_show] *ERROR* Unable to find select subconnector property
[02:57] <bryceh> [  685.222891] [drm:subconnector_show] *ERROR* Unable to find subconnector property
[02:57] <bryceh> [  685.222917] [drm:select_subconnector_show] *ERROR* Unable to find select subconnector property
[02:58]  * RAOF wonders idly how hard it would be to port compiz to RandR1.4 to stop apw bitching :)
[02:59] <RAOF> Hm.  If I reboot my irc bouncer and flip the bios switch I can also have access to an i915-driven GPU.
[03:00] <apw> RAOF, my plan is to offer my laptop to our leader for a presentation and see how long it takes to get fixed after it explodes
[03:00] <RAOF> :)
[03:01] <apw> bryceh, well none of the code which produces that error is new ... so hrm
[03:01] <Sarvatt> apw: does it go away if you move the mouse to the top left of the screen? :)
[03:01] <apw> Sarvatt, which ?
[03:01] <ScottK> apw: Bigger question is would you still be around to find out?
[03:02] <Sarvatt> apw: the corruption, sorry
[03:02] <apw> ScottK, heh indeed
[03:03] <apw> Sarvatt, heh no, i get a nice unity launcher pop over it, but no change in the corruption
[03:03] <Sarvatt> also curious if it happens on .37
[03:03] <Sarvatt> ah alrighty, saw one case of a corruption problem with a fix just posted on the intel-gfx list but they said it went away when the mouse was in the top left
[03:04] <apw> now that is somewhat odd fix is it not?
[03:04] <apw> yeah .37 is my next test
[03:05] <Sarvatt> nah they fixed it properly, that was just a symptom the guy had
[03:05] <Sarvatt> http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/2949
[03:05] <Sarvatt> 2.6.38 is proving to be all kinds of "fun" on intel
[03:06] <bryceh> tell me about it
[03:07] <apw> ok back ... on .37 ... the triple brightness issue is still here so i can ignore that as a kernel issue
[03:11] <apw> its hard to prove a negative, but i've done more wibbling to reproduce it, i managed to reproduce it 3-4 times in the same period on .38, nothing so far on .37
[03:13] <bryceh> mm interesting
[03:13] <RAOF> Oh, hurrah.
[03:14] <bryceh> apw, btw while we have your attention... any updates on the -intel/vesafb conflicts (bug #702090)?  the bugs keep rolling in daily on that one
[03:14] <ubot4> Launchpad bug 702090 in xserver-xorg-video-intel (Ubuntu Natty) (and 4 other projects) "i965gm GPU lockup if vesafb is left loaded (EIR: 0x00000010 PGTBL_ER: 0x00000100) - *ERROR* EIR stuck: 0x00000010, masking (affects: 36) (dups: 25) (heat: 287)" [High,Triaged] https://launchpad.net/bugs/702090
[03:14] <apw> bryceh, not had a chance to fiddle with the ordering there
[03:14] <apw> mr watson and i were meant to get together to discuss it this week and its nto yet happened hrm
[03:16] <Sarvatt> apw: if 2.6.38-rc1 works too you might want to try https://patchwork.kernel.org/patch/571511/ and https://patchwork.kernel.org/patch/572241/
[03:17] <apw> how the heck does it work without those !
[03:19] <Sarvatt> <3 2.6.38 so far
[03:20] <Sarvatt> broadcom fail in it invalidated 3 days of hibernate testing here, i'm grumpy :)
[03:21] <apw> broadcom is always fail
[03:23] <Sarvatt> apw: those commits are in drm-intel-next too, not sure when you guys build those? could just check in the morning
[03:26] <apw> we rebuild at 10am utc i think it is
[03:28] <apw> ahh awsome that 'skip FDI & PCH enabling for DP_A' fix looks to be on the intel fixes branch, so i assume destined for .38
[03:29] <bryceh> ok EOD'ing
[03:29] <bryceh> apw, btw looks like your kernel solved my nfsv4 woes, thanks
[03:29] <apw> yay for new kernels
[03:31] <RAOF> Yay!  I can now actually interact with the grub menu on my radeon system now!
[03:33] <RAOF> Oh, bother.  My evergreen card doesn't have *any* acceleration without KMS, so I can't test the ums fallback.
[03:41] <RAOF> Whoops.  Moderately easy to crash firefox with WebGL
[04:02] <RAOF> How big a NOT E6510 do you need to have in the bug title before users with E6510 hardware stop posting on it? :)
[05:37] <bryceh> strange, my gnome-terminal sessions all froze up and my music started repeating the same broken lyrics over and over in a loop
[05:37] <bryceh> oh wait, I'm listening to techno, it's supposed to sound like that
[06:57] <bryceh> RAOF, I tried on my i945 dell mini...
[06:57] <bryceh> RAOF, gnome-terminal doesn't show the corruption
[06:58] <bryceh> RAOF, weirdly, I launched xterm and got a >frozen< xterm window.  No cursor, completely unresponsive.
[07:04] <hyperair> hi. does anyone know about ubuntu's x with intel chipsets not sending out XRRNotifyEvents to clients?
[07:04] <hyperair> it seems to work with xorg-edgers, but not with the stock X in maverick
[07:06] <RAOF> bryceh: I'll have the switch-to-gallium stuff ready an hour or so after making, then eating dinner.
[07:10] <bryceh> hyperair, first I've heard of it, but I don't really deal with maverick bugs
[07:11] <bryceh> RAOF, sounds good; ping me when it's ready
[07:11] <hyperair> bryceh: hmm strange. basically i plug in a monitor into the VGA port, and only after manually polling the hardwrae with XRRGetScreenResources does the event come in
[07:11] <hyperair> bryceh: but that X call causes X11 to hang momentarily
[07:12] <lilstevie> I have X dying and respawning, is there a way of getting more detailed logs from what is killing it as Xorg.0.log has nothing about errors
[07:13] <bryceh> lilstevie, I'd look in /var/log/gdm for errors
[07:13] <bryceh> also Xorg.0.log.old
[07:13] <lilstevie> unfortunantly doesnt give me any errors
[07:14] <bryceh> lilstevie, ok then start X up in gdb run it to a crash and then gather a full backtrace
[07:14] <lilstevie> k
[07:15] <bryceh> actually probably easier to start X and then attach gdb to it (pidof X to get X's pid, then run gdb /usr/bin/Xorg, and then attach <pid>)
[07:15] <bryceh> see http://wiki.ubuntu.com/X/Backtracing for more tips
[07:15] <lilstevie> X on its own doesnt crash
[07:15] <lilstevie> just doesnt work
[07:16] <bryceh> hyperair, well the automatic XRR kernel events stuff is fairly new, it may just be a missing feature from maverick
[07:16] <hyperair> bryceh: ah, so it's a kernel events thing? is this a new feature in the kernel, or in X, or somewhere else?
[07:16] <bryceh> lilstevie, I don't know what you mean by "doesn't work"
[07:16] <bryceh> hyperair, yeah
[07:16] <bryceh> hyperair, new kernel drm feature
[07:16] <lilstevie> bryceh: the screen backlight flashes on then off again
[07:16] <hyperair> okay, that narrows down my search a bit, thanks =)
[07:17] <lilstevie> http://pastie.org/1577791 <- this is Xorg.0.log.old
[07:17] <bryceh> hyperair, I'm not sure if the kernel bubbles the event up to X and then that passes it to clients, or if clients listen directly for kernel events
[07:18] <hyperair> bryceh: no, the clients get it via some XRR stuff
[07:18] <bryceh> hyperair, if X passes things along it's conceivable the X we shipped in maverick simply lacked the feature, but I wasn't paying attention to X during maverick so raof would be the one to ask
[07:18] <hyperair> okay thanks.
[07:18] <hyperair> RAOF: ^^ =D
[07:19] <RAOF> hyperair: It requires kernel events (which *were* in Maverick) to be picked up by the DDX and forwarded to X; I'm not sure if the latter was in Maverick.
[07:20] <bryceh> lilstevie, oh you're not running natty?
[07:20] <lilstevie> bryceh: no maverik
[07:20] <lilstevie> maverick
[07:21] <bryceh> lilstevie, dunno then, you might have something misconfigured, hard to say
[07:21] <lilstevie> trying to port to a new device
[07:21] <lilstevie> but struggling to figure out what is broken
[07:21] <bryceh> you're right though that it's not crashing, just exiting.  the log seems to be complaining about input device stuff
[07:22] <lilstevie> hm
[07:22] <bryceh> hard to make any guesses without more info, you could try http://askubuntu.com
[07:22] <hyperair> RAOF: oh so kernel events were in maverick, i.e. kernel <= 2.6.35?
[07:22] <hyperair> RAOF: what's DDX?
[07:22] <lilstevie> the nexus S has the same SoIC and that seems to work with x
[07:22] <bryceh> DDX is the X driver
[07:23] <bryceh> so that would be like xserver-xorg-video-intel as opposed to the intel driver inside the kernel 
[07:23] <bryceh> hyperair, https://wiki.ubuntu.com/X/Glossary
[07:24] <hyperair> bryceh: thanks
[07:24] <hyperair> RAOF: i'm trying to look in the kernel git log for the introduction of this whole hotplug kernel events thing so i can figure out how new a kernel i need.
[07:34] <bryceh> wow http://www.semiaccurate.com/2011/02/15/atom-dead-strangled-slowly-intel/
[07:34] <bryceh> harsh!
[07:34] <bryceh> "The other major problem facing Atom is software, especially drivers. Intel has a track record in making graphics drivers that are simply unmatched in the world of chipmaking. I can honestly say that I can not think of a single company that has made drivers as badly as Intel for as long, even if you take the awful hardware into account. Even a blind dog occasionally finds a bone, unless they work for Intel making graphics driv
[07:34] <bryceh> ers."
[07:34] <lilstevie> lol
[07:34] <lilstevie> but true
[07:35] <RAOF> hyperair: Hm.  I may have had it backwards; the DDX component may have been there but the kernel component not :)
[07:36] <hyperair> RAOF: nah, i just tried upgrading to xorg-edgers on this computer and it suddenly started workgin
[07:36] <bryceh> Sarvatt, ^^ you'll find that link an interesting read I think
[12:14] <RAOF> Dear lord, mesa.  Do you *really* need to take that long to build?
[12:15] <jcristau> maybe we should get rid of some (all?) of the osmesa packages
[12:17] <RAOF> Or at least build only one.
[12:18] <RAOF> I'm sure the user of the 16bit renderer will be *devastated*
[12:19] <RAOF> Of course, it doesn't help that I'm doing an i386 and amd64 build in parallel.
[12:19] <tjaalton> heh
[12:19] <tjaalton> what are those osmesa-stuff for, anyway?
[12:23] <RAOF> It's an offscreen software rasteriser, from what I gather.
[12:24] <RAOF> As for what anyone *uses* that for… well, mesa-dev@ attests to there being at least one dev who notices when it breaks.
[12:25] <tjaalton> heh, ok
[12:30] <RAOF> bryceh, tjaalton: Radeon gallium transition stuff is in http://cooperteam.net/Packages ; build order is mesa -> xserver with -ati going whenever.
[12:32] <RAOF> Note: Due to mesa taking forever to build I haven't actually tested building the xserver against that mesa in a clean chroot.
[12:32] <tjaalton> RAOF: ok, so mesa is good to upload?
[12:33] <tjaalton> and xserver too, since the build-dep is bumped
[12:33] <RAOF> It should be good to upload.
[12:34] <tjaalton> yeah they all are
[12:34] <RAOF> But it's not thoroughly tested here.
[12:34] <tjaalton> bah, it's the weekend anyway :)
[12:34] <tjaalton> soon
[12:34] <RAOF> In some places sooner than others :)
[12:34] <tjaalton> right, so Sarvatt and bryceh can fix the pieces that are left behind :)
[12:35] <RAOF> I'll throw the binaries up on cooperteam, too; save you some bulid time.
[12:36] <tjaalton> ok, thanks
[12:36] <tjaalton> I'm trying to make some sense to this "xinput1 broken" -bug..
[12:36] <tjaalton> but, after the break->
[12:38] <RAOF> Now with bonus binaries.
[12:38] <RAOF> And with that, bed.
[12:51] <tjaalton> ok, lets try mesa then (don't have radeon)
[12:55] <tjaalton> wat, there's no menu in mumble anymore?
[12:56] <tjaalton> +h
[12:56] <tjaalton> duh
[14:18] <seb128> bryceh, there?
[16:34] <seb128> bryceh, let me know if you are around, I want to discuss about the retracers
[16:34] <seb128> I stopped those to investigate that xorg retracing issue but I would need an xorg crash to be submitted to be able to do that
[17:51] <cnd> bryceh, I did a ppa-purge of xorg-edgers (which I should have done a while ago...)
[17:51] <cnd> but now my keyboard doesn't work anymore..
[17:51] <cnd> any ideas?
[17:52] <tjaalton> do you have evdev installed?
[17:52] <cnd> I've debugged in the server, and I know that key events are getting generated
[17:52] <tjaalton> ok
[17:52] <cnd> tjaalton, yes, still installed
[17:52] <cnd> but they seem to get filtered out?
[17:52] <cnd> in _XkbFilterXF86Private
[17:52] <cnd> I don't know anything about how keyboard events work...
[17:53] <cnd> I'm just wondering if there's some magical change to stuff in xorg-edgers
[17:53] <jcristau> nobody does, it's all black magic
[17:53] <tjaalton> xorg-edgers doesn't have much, maybe the ppa-purge removed something vital
[17:53] <tjaalton> well, there's stuff but still
[17:54] <tjaalton> but filtering sounds odd
[17:57] <tjaalton> though it sounds what's happening with mumble (XI1 app)
[17:57] <tjaalton> +like
[17:57] <cnd> yeah, but this isn't even generating core events...
[17:57] <tjaalton> hm
[17:57] <cnd> I'm going to try to purge my xorg-unstable ppa
[17:57] <cnd> then reinstall it
[18:07] <cnd> hmm, still no luck
[18:07] <cnd> I'm going to apt-get dist-upgrade and reboot
[18:07] <tjaalton> oh you aren't on current natty?
[18:07] <cnd> I am
[18:07] <tjaalton> k
[18:07] <cnd> but I haven't updated in a few days
[18:07] <tjaalton> yeah that shouldn't make a difference..
[18:07] <cnd> I know
[18:08] <cnd> but I figure if I'm screwing up the machine
[18:08] <cnd> I might as well go all the way :)
[18:08] <tjaalton> right :)
[18:19] <cnd> grr... still nothing
[18:28] <tjaalton> cnd: you've seen the mumble bug? shouldn't XI1 apps continue working just as before with XI2, or do they need to be ported over?
[18:29] <cnd> tjaalton, I have seen it, haven't had time to investigate
[18:29] <cnd> they should continue to work as normal
[18:29] <cnd> so it's a bug
[18:29] <tjaalton> yeah
[18:30] <tjaalton> best to file it upstream then and discuss it there
[18:34] <cnd> tjaalton: I wonder if it has to do with input methods
[18:34] <cnd> do you know anything about them?
[18:35] <tjaalton> XIM? not really
[18:36] <tjaalton> GlobalShortcutX: Using XInput 2.0
[18:36] <tjaalton> yet the app is for XI1
[18:38] <tjaalton> ah that's not from the app
[18:55] <cnd> btw, I don't think it's XIM
[18:56] <cnd> this all seemed to start when I downgraded from libx11-1.3.4 in xorg-edgers to 1.3.3 in natty
[18:56] <cnd> and there's some xkb stuff in libx11
[18:56] <cnd> so I'm going to try to upgrade back to it
[18:56] <cnd> hmmm... there's no libx11 there anymore...
[18:57] <cnd> I may be screwed :)
[18:58] <tjaalton> you have some self-compiled stuff for multitouch?
[18:59] <tjaalton> eh, so we have an ancient libX11
[19:00] <tjaalton> wonder if 1.4.1 could fix mumble
[19:00] <cnd> I do have stuff for multitouch
[19:00] <jcristau> *cough* klongon crap *cough*
[19:00] <jcristau> klingon, even
[19:00] <cnd> I'm all confused...
[19:00] <tjaalton> jcristau: haha
[19:01] <cnd> I just want my keyboard to work!
[19:01] <tjaalton> cnd: dunno if there's some ABI break doing what you see
[19:01] <cnd> tjaalton, it doesn't work on stock natty packages
[19:01] <cnd> I've ppa-purged everything
[19:01] <cnd> I think some xkb file has been screwed up
[19:02] <cnd> some setting somewhere
[19:02] <tjaalton> what packages does it touch?
[19:02] <cnd> trust me, I've downgraded them all again :)
[19:02] <tjaalton> crap, forgot about RAOF's mesa/xserver/ati
[19:02] <tjaalton> cnd: I know, but if your multitouch'y packages need something to be rebuilt
[19:02] <jcristau> tjaalton: friday, 8pm, what could possibly go wrong.
[19:03] <jcristau> or is it 9 over there
[19:03] <tjaalton> jcristau: right. I'll get another beer
[19:03] <jcristau> :)
[19:03] <tjaalton> (not working anymore btw)
[19:03] <jcristau> cheers
[19:04] <tjaalton> bryceh: do you want to take over mesa/xserver/ati from RAOF? I can test them, but if something breaks after uploading them I'd be either in bed or..
[19:05] <tjaalton> yeah 21:04 here
[19:05] <tjaalton> oops :05
[19:05] <bryceh> tjaalton, sure
[19:06] <tjaalton> bryceh: got the link?
[19:06] <tjaalton> bryceh: http://cooperteam.net/Packages
[19:07] <bryceh> oh cool, debs too
[19:07] <tjaalton> yeah
[19:11] <cnd> tjaalton: GAH! it was libx11-1.3.4
[19:11] <tjaalton> cnd: :)
[19:11] <cnd> so, downgrading from libx11-1.3.4 breaks your keyboard!
[19:12] <tjaalton> good, I'll merge 1.4.1 to see if it helps with mumble
[19:12] <cnd> I'd like 2 hours of my life back now :)
[19:12] <tjaalton> hehe
[19:12] <tjaalton> hmm, libxi 1.4.1 available
[19:12] <tjaalton> we have 1.4.0
[19:13] <tjaalton> nothing too special there
[19:14] <bryceh> cnd, that's weird
[19:15] <tjaalton> but I'll sync the packages that don't have any diff
[19:15] <tjaalton> couple of libs
[19:15] <bryceh> abi change between previous and libx11-1.3.4?
[19:15] <bryceh> tjaalton, yeah probably a bunch that could be sync'd http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/versions-current.html
[19:16] <tjaalton> yeah looking at that now (been a looong time..)
[19:16] <bryceh> there's also drivers that I think the only changes are the rebuilds after the last abi bumpery
[19:17] <tjaalton> ooh and new xbacklight and xbitmaps
[19:17] <jcristau> tjaalton: exciting, right? :)
[19:18] <tjaalton> super-
[19:19] <cnd> bryceh, it can't really be abi
[19:19] <cnd> because I had downgraded everything
[19:19] <cnd> drivers and server
[19:20] <cnd> but I don't have any alternative explanation either...
[19:20] <bryceh> could something have statically linked against it?
[19:20] <tjaalton> you've built something against libx11 1.3.4
[19:20] <cnd> tjaalton, no, I was running stock ubuntu packages
[19:21] <cnd> I had gotten rid of all my stuff
[19:22] <tjaalton> ok
[19:22] <Sarvatt> cnd: libx11 1.3.4 isn't even in xorg-edgers natty?
[19:22] <cnd> Sarvatt, it must have been at one point
[19:22] <tjaalton> confirmed that focus-follows-mouse doesn't dig on unity..
[19:22] <cnd> and it's still there in the maverick and lucid series I believe
[19:22] <Sarvatt> nope can guarantee it hasn't been
[19:23] <tjaalton> or the menubar
[19:23] <Sarvatt> sounds like ya didnt purge edgers before going maverick -> natty?
[19:23] <cnd> Sarvatt, perhaps?
[19:23] <Sarvatt> gotta be it
[19:24] <Sarvatt> to fix that i add xorg-edgers maverick to sources, apt-get update then purge the ppa before upgrading so it knows all the crap in the old release to remove, kind of a pain in the butt :(
[19:25] <cnd> yeah
[19:27] <Sarvatt> thats.. odd
[19:28] <Sarvatt> the libx11 checkout in there was back from when 1.3.x was master
[19:28] <Sarvatt> and it has the XKeysymDB removal in it even though its 1.3.4
[19:28] <Sarvatt> but they didn't remove xkeysymdb until 1.3.6 on the 1.3 branch
[19:35] <bryceh> ok reboot onto new -ati first
[19:35] <tjaalton> damh
[19:35] <tjaalton> damN
[19:36] <tjaalton> forgot to tell bryce about the build order
[19:36] <bryceh> so far so good
[19:37] <tjaalton> quick reboot?
[19:37] <Sarvatt> sandybridge system? :)
[19:37] <tjaalton> bryceh: RAOF said something about the build order, but you're installing the binaries so it doesn't matter really
[19:38] <tjaalton> the xserver does depend on the new mesa though
[19:38] <bryceh> -ati I rebuilt while other stuff was downloading; assumed that bit was safe to do independently, but maybe not?
[19:39] <tjaalton> yeah it should be independent
[19:39] <bryceh> ok the other stuff I'll just load the .debs then
[19:39] <bryceh> think there's an upload dependency?  Do I need to put mesa in and wait for it before sticking xserver in, or vice versa?
[19:40] <tjaalton> no the xserver build-deps on the new mesa, so it'll wait until mesa is ready
[19:40] <bryceh> hrm, wish you could just dpkg -i *.deb with mesa
[19:40] <tjaalton> hehe
[19:40] <tjaalton> there are only a few you need
[19:40] <bryceh> yeah
[19:41] <bryceh> dpkg -i libgl1-mesa-dri_7.10.1~git20110215.cc1636b6-0ubuntu2_i386.deb libgl1-mesa-glx_7.10.1~git20110215.cc1636b6-0ubuntu2_i386.deb libgles2-mesa_7.10.1~git20110215.cc1636b6-0ubuntu2_i386.deb 
[19:42] <bryceh> did I miss anything?  that should be enough
[19:42] <bryceh> actually it looks like I could do everything except libgl1-mesa-swx11  - isn't that the only package that'd screw me up?
[19:42] <tjaalton> that can be installed as well
[19:43] <jcristau> that conflicts with -glx iirc
[19:43] <bryceh> libgl1-mesa-dri-experimental might be "fun" but it shouldn't cause conflicts for installation
[19:43] <jcristau> both provide libGL.so.1
[19:43] <tjaalton> oh
[19:43] <tjaalton> right I was looking at apt-cache search output, duh
[19:43] <bryceh> heck, I'm gonna give a try to install everything but that
[19:44] <bryceh> unhappy
[19:44] <bryceh> oh duh, gotta exclude amd64 pkgs
[19:44] <tjaalton> heh
[19:45] <bryceh> there we go
[19:45] <bryceh> yeah, just rm *swx11*deb ; dpkg -i *.deb
[19:46] <bryceh> reboot time
[19:47] <bryceh> metacity fine
[19:48] <bryceh> unity still crazy, but no crazier
[19:49] <bryceh> aaaa too crazy for me tho, brb
[19:52] <bryceh> aha, most of this craziness is compiz
[19:55] <tjaalton> hum, I wonder where the syncs went
[19:55] <tjaalton> oh, nowhere
[19:57] <Sarvatt> sync freeze was in december, i've done like 40 since then
[19:58] <tjaalton> i thought syncpackage would've uploaded them too, but it just signed them
[19:58] <tjaalton> probably because i didn't specify the release
[19:58] <Sarvatt> oh they might have removed that ability, i think archive admins want to do the syncs?
[19:59] <tjaalton> they can't prevent me from uploading packages signed by me :)
[19:59] <tjaalton> hm
[19:59] <tjaalton> of course they can
[19:59] <tjaalton> by revoking my upload rights :)
[19:59] <Sarvatt> not sure, the guy who used to upload them when I file just acks my sync requests instead of uploading them now so figured there was a policy change along the way
[20:00] <tjaalton> it could recognize packages without ubuntuN in the version
[20:04] <bryceh> ok, -ati, xserver, mesa all tested and uploaded
[20:06] <bryceh> [   175.611] (II) RADEON(0): [DRI2]   DRI driver: r600
[20:06] <bryceh> [   175.618] (II) AIGLX: Loaded and initialized /usr/lib/dri/r600_dri.so
[20:06] <bryceh> hm, shouldn't that be r600g?
[20:06] <bryceh> nope
[20:06] <bryceh> wonder how I tell whether I'm running g?
[20:06] <tjaalton> glxinfo should tell
[20:07] <bryceh> OpenGL renderer string: Gallium 0.4 on AMD RV770
[20:07] <bryceh> bingo, thanks
[20:07] <Sarvatt> r600g default now?
[20:07] <bryceh> hum, I just pulled glxinfo out of the apport hook yesterday... but it occurs to me that maybe useful info for debuggery
[20:08] <bryceh> Sarvatt, yep once the buildds are done
[20:08] <bryceh>  389 N + Feb 18 Ubuntu Installe ( 105) [ubuntu/natty] xserver-xorg-video-ati 1:6.14.0-0ubuntu1 (Accepted)
[20:08] <bryceh>  390 N + Feb 18 Ubuntu Installe ( 148) [ubuntu/natty] mesa 7.10.1~git20110215.cc1636b6-0ubuntu2 (Accepted)
[20:08] <bryceh>  391 N + Feb 18 Ubuntu Installe ( 119) [ubuntu/natty] xorg-server 2:1.9.99.901+git20110131.be3be758-0ubuntu6 (Accepted)
[20:09] <tjaalton> mesa-utils isn't installed by default though
[20:09] <tjaalton> and in universe
[20:09] <tjaalton> because of that
[20:10] <bryceh> tjaalton, yeah that's why I took it out of the apport hook
[20:10] <bryceh> was causing the hook to error when glxinfo wasn't installed
[20:10] <Sarvatt> mesa-utils-extra? what the heck
[20:10] <Sarvatt> someone add more stuff to it and forget it's in debian now? :D
[20:11] <tjaalton> Sarvatt: syncs uploaded and accepted
[20:11] <Sarvatt> tjaalton: \o/ what'd ya get? libxcb?
[20:11] <tjaalton> that too
[20:12] <tjaalton> libxi, libxaw, libxext, libxcb, libxfont, xbacklight, xbitmaps
[20:12] <tjaalton> merged libx11, building it now
[20:12] <tjaalton> but won't upload it until monday
[20:13] <Sarvatt> tjaalton: I missed you man :)
[20:13] <tjaalton> hehe
[20:13] <tjaalton> I've missed these tools
[20:14] <Sarvatt> i had a bug for libxext but it was rejected, forgot to look into it
[20:14] <Sarvatt> think it was header removal, lets see
[20:15] <tjaalton> there was some changes yes.. could that break something?
[20:15] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/libxext/+bug/705010
[20:15] <ubot4> Launchpad bug 705010 in libxext (Ubuntu) "Sync libxext 2:1.2.0-1 (main) from Debian experimental (main) (affects: 1) (heat: 118)" [Wishlist,Incomplete]
[20:15] <Sarvatt> nothing we care about or ship
[20:15] <tjaalton> hah, sorry daniel..
[20:16] <tjaalton> "overruled"
[20:16] <Sarvatt> lbxproxy
[20:16] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/x11-xserver-utils/+bug/102018
[20:17] <tjaalton> yeah moved to liblbxutil
[20:17] <ubot4> Launchpad bug 102018 in x11-xserver-utils (Ubuntu) "[needs-packaging] lbxproxy (affects: 3) (heat: 17)" [Wishlist,Triaged]
[20:31] <tjaalton> bryceh: I've installed mesa here and will reboot in a minute
[20:31] <tjaalton> the new one
[20:31] <bryceh> ok
[20:43] <tjaalton> works
[20:47] <tjaalton> libx11 update didn't fix mumble
[21:11] <Amaranth> anyone seeing excessive wakeups on intel when running compiz?
[21:12] <Amaranth> it used to be 60 wakeups a second if you enabled vsync in compiz but now it's about that either way
[21:13] <Sarvatt> Amaranth: got second hands visible on your clock?
[21:13] <Sarvatt> was reading something about having the clock show seconds kept interrupts enabled all the time with compiz
[21:13] <Amaranth> Sarvatt: I don't even have a panel right now :)
[21:16] <Amaranth> I've got xchat-gnome and gnome-terminal as far as things drawing to the screen
[21:20] <bryceh> heya seb128
[21:20] <bryceh> seb128, you had questions about the retracer?
[21:20] <seb128> hey bryceh
[21:20] <seb128> bryceh, not really questions
[21:21] <seb128> rather I need some xorg crash reported and not retraced to run a retracing and see what is the issue
[21:21] <bryceh> seb128, ok, I'll keep an eye out for one
[21:21] <seb128> but it's getting late for this week now so let's see next week rather
[21:21] <bryceh> seb128, sounds good
[21:21] <Amaranth> Sarvatt: actually vsync on or off in compiz I get 57.2 wakeups
[21:21] <seb128> bryceh, thanks
[21:22] <Sarvatt> Amaranth: terminal cursor blink?
[21:22] <Amaranth> Sarvatt: It's blinking, yeah
[21:22] <bryceh> Sarvatt, ooh that'd be evil
[21:23] <Sarvatt> that did it years ago so i've always disabled it (they mention turning it off on their lesswatts page) :D
[21:23] <Amaranth> I just noticed it's on, could have sworn it was disabled by default
[21:24] <Sarvatt> Amaranth: i'm not sure though, let me see if i can dig up the discussion on the intel-gfx list because I think it had some debugging tips for it
[21:27] <Amaranth> Sarvatt: nope, wasn't the cursor blink :/
[21:28] <Amaranth> wow, actually it does it when running metacity too
[21:59] <bryceh> Sarvatt, hey I was just looking at bug #626967
[21:59] <ubot4> Launchpad bug 626967 in xserver-xorg-video-intel (Ubuntu Natty) (and 2 other projects) "MASTER: Hang in MI_WAIT_FOR_EVENT on framebuffer switch. (affects: 30) (dups: 42) (heat: 184)" [Medium,Fix released] https://launchpad.net/bugs/626967
[21:59] <bryceh> Sarvatt, looks like that is believed fixed for natty, but looks like the patch wasn't sru'd to maverick.  Do you think it'd make sense to do so?
[22:00] <bryceh> or is it too ambiguous what the fix was?
[22:07] <bryceh> bbiab