[00:00] <bjsnider> odd to use both an unstable distro and a ppa
[00:01] <bjsnider> but they knows what they likes i guess
[00:01] <Sarvatt> well its not as big a deal for fglrx because the stuff from amd.com works fine if you build debs, no options on nvidia :)
[00:01] <Sarvatt> outside of learning how to package it yourself
[00:02] <Sarvatt> and 295.20 is severely busted with gnome-shell
[00:02] <Sarvatt> all fixed up in .33
[00:06] <bjsnider> ok, sent in driver and nvidia-settings
[00:06] <Sarvatt> bjsnider: if its a pain in the butt just dont bother, it'll most likely be up on monday
[00:07] <bjsnider> from the looks of the build farm it will be built very quickly
[00:07] <Sarvatt> holy crap, never seen the queue that empty
[00:08] <Sarvatt> must not have been any kernel SRU's this week
[00:08] <Sarvatt> they pull off the buildds to do SRU testing and the queues build up all the time :(
[00:09] <bjsnider> it was backed up hours last night though
[00:09] <cnd> bryceh, just to note, I'm ok with this weather :)
[00:10] <cnd> btw, I may have a fix for bug 931397
[00:10] <cnd> I found a couple input commits that use the new input option abi
[00:10] <bryceh> cnd, told ya it'd turn around ;-)  the ball in the sky's only temporary though
[00:11] <cnd> which bit us because the old input option abi had no type safety /o\
[00:11] <bryceh> cnd, awesome!
[00:11] <bryceh> cnd, aha, yeah we were wondering if something like that could be the case
[00:12] <cnd> everything is passed around as opaque pointers for no good reason
[00:12] <cnd> and then casted to the appropriate type inside the functions
[00:14] <cnd> and the real issue, IIUC, is that the new abi is based on the general xf86Option abi
[00:14] <cnd> rather than an input-specific option api
[00:15] <cnd> so upstream just switched to using the general option api
[00:15]  * bryceh nods
[00:15] <cnd> if they had added or modified the option api, it might have been caught easier
[00:15] <cnd> at least things will be better in the future :)
[00:16] <bryceh> cnd, totally.  Any chance this might solve some of our other xserver bugs in precise?
[00:16] <cnd> dunno?
[00:16] <bryceh> https://bugs.launchpad.net/ubuntu/+source/xorg-server?field.tag=precise&field.tags_combinator=ALL
[00:16] <cnd> this particular bug only manifests at start up
[00:16] <cnd> at device initialization time
[00:16] <cnd> specifically master and Xtest device init time
[00:17] <bryceh> well, once you have a solid patch lemme know and I can troll around a bit for bugs
[00:17] <Sarvatt> cnd: thats freaking awesome, i've been going over the changes between the two abis trying to figure out what changed to make it work in 1.12 and not in ours and drawing frigging blanks
[00:17] <cnd> need to revert these two commits in our packaging branch:
[00:17] <cnd> 7ee1621364d2b6230bb1c02bbdb5b6abb74ad2ff.
[00:17] <cnd> 4b7dd4523c11ef4952b78e4164b2fa7b34588867.
[00:18] <cnd> bryceh, this could be related: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/946028
[00:20] <bryceh> ok
[00:21] <Sarvatt> oh no wonder i had no luck, i was looking for differences in NewInputDeviceRequest from hw/xfree86/common/xf86Xinput.c compared to our patched server
[00:21] <Sarvatt> and am a dunce :)
[00:28] <cnd> bryceh, what do you think we should do with this fix?
[00:28] <cnd> I think it's a candidate for beta 2 freeze exception
[00:30] <bryceh> I do too
[00:31] <bryceh> cnd, is it literally just reverting those two commits?  or is any additional code needed?
[00:31] <bryceh> if it's just reverts I think getting it in asap is the way to go
[00:31] <cnd> just reverting those commits for this particular bug
[00:31] <cnd> I can't guarantee there are no other issues lurking elsewhere though
[00:31] <bryceh> otherwise, we might want to stick it in a ppa for extra testing first
[00:32] <cnd> I think it's an obvious fix
[00:32] <bryceh> cnd, ok
[00:33] <cnd> one would hope that things couldn't get worse
[00:33] <cnd> but we're dealing with type-unsafe pointer passing
[00:33] <cnd> so it's possible that we fix one bug but expose a worse one
[00:33] <bryceh> cnd, well the AutoAddDevices bug I'm actually not too concerned with as it's a really minor corner case
[00:34] <cnd> bryceh, I'm not exactly sure why the autoadddevices option causes the bug though
[00:34] <cnd> it may be that there are multiple ways to trigger it
[00:34] <cnd> multiple conf file options
[00:34] <Sarvatt> cnd: people wont be using xorg.conf's breaking things with the beta for the most part i wouldn't imagine, directly after beta 2 releases sounds good to me personally
[00:34] <bryceh> cnd, but I think it's exposing a deeper problem, and I think you may have a hook into it.  I have a hope that if we can address what causes the xorg.conf problem it might shed light on some of the other SIGABRT bugs we've been getting lately
[00:35] <bryceh> post-beta2 sounds like a good plan to me too
[00:35] <cnd> I guess my main question is: why does it *only* appear when the option is used
[00:35] <cnd> because the core and xtest devices are always created
[00:35] <cnd> which is where this bug hits
[00:35] <Sarvatt> then again, there will be respins up until monday probably
[00:36] <Sarvatt> so maybe it would be ok to get it in, it is a good fix :)
[00:38] <bryceh> yeah commit reverts generally tend to be unlikely to  cause regressions, sort of by definition :-)
[00:38] <cnd> hmm... well, I'm testing it more
[00:38] <cnd> and now my kb won't work :)
[00:39] <cnd> oh right
[00:39] <cnd> I have autoadddevices = false
[00:39] <cnd> imagine that, it works after commenting that out :)
[00:40] <bryceh> hehe
[00:41] <Sarvatt> cnd: you're probably the only one who can judge how risky it is, from what i gathered from #ubuntu-desktop talk earlier it should be ok if you deem it really important before monday :)
[00:41] <cnd> ok, I've committed the changes to the repo
[00:41] <cnd> let me try to reason why it wasn't occurring during normal startup
[00:42] <Sarvatt> i've got it building to test on all my machines just to make sure it doesn't screw up
[00:50] <cnd> ok, I think I see what's going on
[00:51] <cnd> if you don't have AutoAddDevices turned on, the server will instantiate core devices at startup
[00:51] <cnd> oops, I mean it will instantiate a built-in default
[00:51] <cnd> the core devices are always created
[00:52] <cnd> but the issue is the built-in default
[00:52] <cnd> the built-in default mouse driver is noted saved in xf86ConfigLayout.inputs
[00:53] <cnd> then in InitInput, any saved devices are turned into real devices by creating xf86 input options
[00:53] <cnd> and that's where we were using the wrong abi
[00:54] <cnd> however, if we are instantiating devices normally, through hotplug, the built-in default isn't set up, and isn't created in InitInput
[00:54] <cnd> it's created through some other mechanism that is probably *not* broken
[00:55] <cnd> I think this would also apply to anyone who is specifying devices manually in xorg.conf
[00:55] <cnd> are there any use cases for that?
[00:56] <cnd> if not, then I propose leaving this till after beta 2
[00:56] <cnd> bryceh, Sarvatt ^^?
[00:57] <bryceh> cnd, yes leave to post-beta2
[00:57] <bryceh> but yeah I think some of our bugs may well be from people specifying devices manually.  I'd have to review them to be sure though.
[00:58]  * bryceh -> EOD
[01:03] <cnd> bug 954745 is a dupe
[01:28] <FernandoMiguel> Boa noite
[02:56] <Sarvatt> cnd: looks like its absolutely only for people manually using an xorg.conf to me, noone testing a beta 2 livecd or new install there will hit it, upgraders will still hit the same bug they've always had, uploading the day beta 2 releases would be just as good without the hassle IMO
[03:00] <Sarvatt> in the same vein it wont affect autoconfig everyone using the livecd is using so its just as good to go in now though :)
[03:02] <Sarvatt> its just, are the beta 2 livecds final now? i'm not sure how locked down things really are
[03:04] <Sarvatt> the first thing someone installing mythubuntu beta 2 is going to try to do is configure their remote via xorg.conf
[03:06] <FernandoMiguel> nite
[20:14] <Sarvatt> -rw------- 1 sarvatt sarvatt 75M Mar 24 16:13 /home/sarvatt/.xsession-errors oh fun
[20:17] <Sarvatt> almost all grail warnings
[20:18] <Sarvatt> GRAIL WARNING (v3/gesture.cpp:CheckOwned:290): failed to get touch 100 from frame, gesture 1199 marked as not owned
[20:18] <Sarvatt> GRAIL WARNING (v3/slice.cpp:GetValues:199): failed to get touch from frame
[20:18] <Sarvatt> GRAIL WARNING (v3/slice.cpp:GetValues:199): failed to get touch from frame
[20:18] <Sarvatt> GRAIL WARNING (v3/slice.cpp:GetValues:230): failed to get touch from frame
[20:18] <Sarvatt> GRAIL WARNING (v3/slice.cpp:GetValues:230): failed to get touch from frame
[20:18] <Sarvatt> GRAIL WARNING (v3/slice.cpp:CheckGestureEnd:392): failed to get touch from frame by id
[20:18] <Sarvatt> GRAIL WARNING (v3/slice.cpp:CheckGestureEnd:392): failed to get touch from frame by id
[20:28] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/utouch-grail/+bug/964135