[01:33] <bryceh> heya
[01:33] <RAOF> Good morning!
[01:33] <RAOF> Or possibly evening?
[01:34] <RAOF> You crazy past-livers :)
[01:34] <bryceh> heh, yeah it's Sunday evening, just got back from trip to the park with my son
[01:35] <RAOF> Sounds fun!
[01:35] <bryceh> RAOF, btw I disabled the gestures patch (101) in -evdev.  It was causing major X crashing fun
[01:35] <RAOF> bryceh: Yeah, I noticed the bug.
[01:35] <bryceh> seems to be an amd64 specific bug, which may explain why I didn't see it when I tested
[01:35] <RAOF> Pity the backtrace is so anaemic :(
[01:36] <RAOF> I tested on amd64
[01:36] <bryceh> hm
[01:36] <bryceh> if you look at the bug report, one of the commenters suggested the issue was an abi incompatibility.  you might take a peek at the comments
[01:36] <bryceh> it was a bit speculative, I decided to just flip it off until someone could investigate more thoroughly
[01:37] <RAOF> Yeah, I agree with that call.
[01:37] <bryceh> probably best to leave it off until post-alpha-2
[01:37] <RAOF> It'd be nice if cnd would pop up, be a dear, and look at his gesture patches :)
[01:38] <bryceh> fwiw, I didn't see the synaptics misbehavior LLStarks mentioned, but did mention the possibility for issues in the a2 release notes
[01:38] <bryceh> RAOF, yah
[01:38] <LLStarks> duly noted
[01:38] <RAOF> Their problem is that synaptics just isn't being loaded for their touchpad.  I'm not sure why.
[01:39] <LLStarks> btw guys, is tty broken? i can't drop to tty1 or tty2.
[01:39] <LLStarks> blinking cursor only
[01:39] <RAOF> Not broken on any of my systems.
[01:40] <bryceh> was talking to the AMD guys friday, they're a bit concerned if xserver 1.10 goes in today, and there are any respins required for subsequent bug fixes, it could throw off their build schedule
[01:40] <LLStarks> can't kill x by killing gdm either
[01:40] <bryceh> LLStarks, are you running xorg-edgers?
[01:40] <LLStarks> no
[01:40] <bryceh> LLStarks, natty current has been working fine for me
[01:41] <LLStarks> i flip-flop as needed
[01:41] <RAOF> bryceh: As in - if there are any further ABI respins required?
[01:41] <bryceh> RAOF, as in, any bug fix uploads to xserver or mesa
[01:42] <RAOF> How do non-ABI-changing bugfix uploads interfere with their build schedule?
[01:43] <bryceh> they have to start it over
[01:43] <RAOF> Because they need to certify it against a particular upload?
[01:43] <bryceh> I guess so; they were complaining about it but was hard for me to get specifics
[01:44] <RAOF> That's… awkward.  How have they handled these things in past releases?  We upload bugfixes all the time!
[01:44] <RAOF> Perhaps they're wary about further ABI breaks?  There's an ABI break between RC1 and master, and *possibly* another one between master and RC2.
[01:44] <bryceh> nah, there's always been a window where we're frozen for a day or so leading up to the alpha release
[01:45] <bryceh> apparently arm builds take longer than x86 ones
[01:45] <LLStarks> why can't ati devs be less anal and put out more releases like nvidia?
[01:45]  * RAOF will take specs and full-time open-source devs over a more responsive binary driver team anyday.
[01:46] <bryceh> RAOF, anyway as a compromise I took out some of the drivers from the video-all arm script 
[01:46] <LLStarks> waiting for their advance releases less than 2 weeks from an ubuntu release isn't fun
[01:47] <bjsnider> RAOF, you mean like the way intel handles things. that works really well.
[01:47] <bryceh> RAOF, anyway my feeling is if we need a bug fix in, we need a bug fix in.  But I suppose if we can batch up patches and minimize uploads it might make them a little happier :-)
[01:47] <RAOF> Yeah.
[01:47] <bryceh> I think the key thing is to get xserver in asap before the alpha-2 freeze is announced
[01:49] <bryceh> RAOF,  btw it looks like the .38 kernel upload Thurs/Fri nuked fglrx
[01:50] <RAOF> I'm a bit concerned about further ABI breakage in xserver now.  Keith's ‘I'm sick’ email promised to pull an ABI-breaking DGA branch sometime; I need to see how much that breaks ABI we care about.
[01:50] <bryceh> hrm
[01:51] <RAOF> If it *is* ABI breakage we need to care about, is it worth uploading Xserver pre A2, only to need another rebuild of the world post A2?
[01:52] <bryceh> well, it simplifies a few things if we postpone xserver update 'til after alpha2
[01:52] <bryceh> but it somewhat reduces testing coverage we'll get
[01:54] <bryceh> RAOF, how much is left to do to get xserver in?
[01:54] <RAOF> Finish updating the gesture extension patch, or getting one from Chase.
[01:56] <RAOF> I wonder if he's jetsetting, or just not checking email/irc :/
[01:59] <bryceh> RAOF, aside from that, any other packaging work to do or is the xserver git tree good for upload?
[01:59] <RAOF> It needs a changelog entry; that's it.
[02:01] <bryceh> RAOF, I'm leaning towards just leaving the gesture stuff disabled if we don't hear from him by, say, morning my time, and uploading
[02:01] <bryceh> then when 1.10 is officially released we can do another mega-driver rebuild
[02:02] <RAOF> bryceh: Wilco.  I'll have a package ready for you then, then :)
[02:02] <bryceh> alrighty, I can upload if you want to do it now
[02:03] <RAOF> Nah, I'll give cnd until your morning.
[02:03] <bryceh> ok
[02:03] <bryceh> wow take a gander - http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
[02:03] <RAOF> Incidentally, were you planning to push wayland and/or libxkbcommon to pkg-xorg git?
[02:04] <bryceh> Spikey McSpike visited our graph
[02:04] <RAOF> Is that Maverick trend the line at the same stage of release?
[02:04] <bryceh> no, I might put it in bzr
[02:04] <bryceh> yeah
[02:04] <RAOF> Why do we have so many fewer open bugs?!  Hurray!
[02:05] <bryceh> I credit that to there being 2 X guys ;-)
[02:05] <RAOF> Looks like Spikey McFglrx happened :)
[02:05] <RAOF> And I see we've got some intel testers finally :)
[02:06] <bryceh> I've been going through all the open natty bugs every morning, so that's kept things better under control than any release before
[02:06] <RAOF> Aaah, yeah.  That'll do it.
[02:06] <bryceh> yeah the fglrx bugs are all dupes of "kernel broke it"
[02:06] <bryceh> a bunch are probably from the evdev crash
[02:07] <bryceh> we may also have a few of "xchat shows corruption with latest intel
[02:07] <RAOF> KiBi's doing some wayland/xkbcommon packaging in pkg-xorg git; it might be nice to help him if you've got time.
[02:07] <RAOF> Oh, yeah.  That intel bug.
[02:07] <cnd> RAOF, I'm popping up :)
[02:08] <bryceh> ah no, looks like mostly GPU lockup bugs
[02:08] <cnd> got back from bangalore yesterday
[02:08] <RAOF> cnd: Time to make good on those “you'll not need to forward-port patches for us” promises :)
[02:08] <cnd> still beating back the remnants of a fever suffered while there
[02:08] <bryceh> RAOF, is KiBi aware of my packaging?
[02:08] <RAOF> Oh, sucks.
[02:08] <cnd> RAOF, yeah, so, things have changed recently in the utouch world
[02:08] <RAOF> bryceh: Yeah, I think so.
[02:09] <cnd> rydberg is unfortunately no longer on contract with us
[02:09] <cnd> so we've had to scrap our plans to put the gesture recognition on the client side of X
[02:10] <RAOF> Oh.  So we'll still have a gesture extension for 1.10?
[02:10] <cnd> we will be forward porting the maverick gesture patches for xorg-server and xserver-xorg-input-evdev to 11.04
[02:10] <cnd> I have begun this work
[02:10] <cnd> got started while I was in india
[02:10] <cnd> so here's the good news: everything forward ports pretty easily
[02:11] <cnd> here's the not as good news: it needs to be reworked a little if it's going to sit along side XI 2.1
[02:11] <cnd> though mostly that rework sits in utouch-grail
[02:11] <cnd> not in any x components
[02:11] <RAOF> (Although *my* attempt at forward-porting it in evdev results in Xserver crashes on hardware that isn't mine)
[02:12] <cnd> RAOF, my forward port was also based on evdev master
[02:12] <cnd> which has a *huge* masked valuators patch from me in it now :)
[02:12] <cnd> well, series of three patches
[02:12] <RAOF> So we need a newer snapshot of evdev also?
[02:13] <cnd> RAOF, lets first go over what we need to accomplish, and by when
[02:13] <cnd> when are you wanting to push things to ubuntu?
[02:13] <RAOF> We'd like to push xserver in before A2 freeze, so soon.
[02:13] <cnd> RAOF, can you be more specific?
[02:13] <cnd> just so I know
[02:14] <RAOF> A2 freeze will be Tuesday.
[02:14] <bryceh> *early* Tuesday
[02:14] <cnd> oh, so soon really means about 24 hrs :)
[02:15] <bryceh> cnd, yep, preferrably more like 15 hrs
[02:15] <cnd> so here's two routes:
[02:15] <cnd> a. gestures in xorg-server and evdev
[02:15] <cnd> b. gestures and xi 2.1 in xorg-server and evdev
[02:15] <cnd> I feel about the same confidence in both at this point
[02:16] <cnd> mostly because I haven't tried a
[02:16] <RAOF> b. also requires an xi 2.1 patch series, right?
[02:16] <cnd> however, b would require a new min version of utouch-grail, which would need to be pushed in as well
[02:16] <cnd> yes
[02:17] <cnd> RAOF, I would be happy to add the patches to xorg-server and evdev myself
[02:17] <cnd> to the git repo
[02:17] <cnd> so you would only need to verify and upload
[02:17] <RAOF> That would be nice.  I'm perfectly happy to apply patches myself if that's easier.
[02:18] <cnd> it's probably easier if I do it anyways
[02:18] <cnd> and I don't mind
[02:18] <RAOF> Is the utouch-grail min version the one in bug #702637 ?
[02:18] <ubot4> Launchpad bug 702637 in utouch-grail (Ubuntu) "Upload utouch-grail 1.0.18 to Ubuntu (affects: 1) (heat: 186)" [Undecided,Confirmed] https://launchpad.net/bugs/702637
[02:18] <cnd> no, it would need to be 1.0.19, which doesn't even exist yet
[02:19] <cnd> without changes I made, touchscreen devices would no longer work
[02:19] <cnd> they wouldn't move the pointer
[02:19] <cnd> but they aren't huge changes
[02:19] <cnd> I can try to make the packages tonight
[02:20] <cnd> what do you think? a or b?
[02:20] <cnd> it's really ok if you want a for alpha 2
[02:20] <cnd> the xi 2.1 work isn't final yet either
[02:21] <cnd> still some bits needing implementation
[02:21] <RAOF> Are we more likely to get more useful testing out of (b) than (a)?  I think we will, but I think that's the main criterion at this point.
[02:21] <LLStarks> bryceh, any news about the 16-bit color appearance on intel with .38?
[02:21] <bryceh> LLStarks, news?
[02:21] <cnd> RAOF, there's already someone on our multitouch mailing list asking about xi 2.1 for games
[02:21] <cnd> he's just waiting for it to hit
[02:21] <LLStarks> x session-wide color banding
[02:22] <RAOF> That sounds fun.  Would you *like* his testing at this point?
[02:22] <cnd> the sooner the better :)
[02:22] <bryceh> cnd, are a and b about the same level of risk of breakage?
[02:22] <RAOF> LLStarks: Sounds like a failure to set an appropriate dither mode.
[02:22] <cnd> bryceh, b would be slightly more risky for MT touchscreens
[02:23] <cnd> I don't think it should be any more for MT touchpads
[02:23] <bryceh> LLStarks, since it's the weekend I've only been looking at critical bugs, but don't recall seeing that one.  bug #?
[02:23] <cnd> and should not be a factor for non-mt devices
[02:23] <LLStarks> ****
[02:23] <LLStarks> i never filed one
[02:23] <bryceh> LLStarks, ah, then that would be your next step
[02:23] <LLStarks> i'll do it after the ppv ends
[02:23] <LLStarks> need to boot into .38 anyway
[02:23] <bryceh> ok
[02:24] <RAOF> LLStarks: FWIW I don't get it on my 6-bit panel.
[02:24] <bryceh> .
[02:25] <LLStarks> i'd post camera pics, but it's kinda hard even with a 14mp one
[02:25] <cnd> bryceh, if we go with b and find it breaks things, we should be able to revert to a before alpha 2 actually ships
[02:25] <RAOF> cnd: And the risk on those MT touchscreens is that the pointer doesn't work on the touchscreen, yes?  Rather than it causing puppies to combust?
[02:25] <cnd> RAOF, yes
[02:25] <cnd> so you could just use a mouse or trackpad if something is awry
[02:26] <RAOF> As someone without access to a MT touchscreen, that sounds an acceptable risk :)
[02:26] <cnd> it's just cause of the interaction between utouch-grail and xi 2.1
[02:26] <bryceh> yeah at this stage the risks we're mostly averse to is risks of widespread breakages (ala the -evdev breakage)
[02:27] <cnd> bryceh, which evdev breakage?
[02:27] <bryceh> but also we want to minimize the number of times we upload xserver between now and alpha-2, so the fewer bug fixes needed the better
[02:27] <RAOF> I forward-ported the gesture patch to 2.6 in such a way that caused flaming destruction on !my hardware.
[02:27] <cnd> ahh, that breakage :)
[02:27] <bryceh> cnd, oh yeah you need to take a look - the gestures patch hosed the evdev upload
[02:27] <RAOF> (bug #709977 for your delectation)
[02:27] <ubot4> Launchpad bug 709977 in xserver-xorg-input-evdev (Ubuntu Natty) (and 1 other project) "Xorg crashed with SIGSEGV in RemoveDevice() - segfault at 1010 error 4 in evdev_drv.so (affects: 37) (dups: 15) (heat: 210)" [Critical,Fix released] https://launchpad.net/bugs/709977
[02:28] <cnd> RAOF, ahh yes, I know exactly where the forward port went wrong :)
[02:28] <bryceh> unfortunately I didn't catch it before uploading (but I *did* test this time!)
[02:29] <RAOF> I tested on multiple machines, none of which exploded.
[02:29] <RAOF> On the other hand, none of which had anything multitouch, either.
[02:29] <cnd> anyways, if you guys give me the thumbs up I'll go make gesture + xi 2.1 packages for you
[02:29] <RAOF> You have a go from me.
[02:30] <bryceh> yeah I'm ok if we can get it in quickly
[02:30] <cnd> RAOF, would it be reasonable to collapse all the xi 2.1 git commits into one big uber-patch in our package?
[02:30] <cnd> that uber-patch would then be updated as we update xi 2.1 work
[02:31] <RAOF> I don't have any real feelings either way.  I expect that you'll be the one dealing with any fallout from that patch, so I think do whatever is most convenient for you.
[02:31] <cnd> k
[02:31] <cnd> that would be it
[02:31] <cnd> I will go cook some packages
[02:32] <RAOF> Thanks.
[02:32] <cnd> btw, don't announce xi 2.1 support if it does go in
[02:32] <bryceh> alright, gonna go play with some blocks and crayons.  I'll check back in later.
[02:32] <RAOF> We should stop getting you to jetset around.
[02:32] <cnd> heh, talk to marketing :)
[02:33] <cnd> and I found out after the fact that qatar airlines isn't actually in star alliance, so I don't get my 16,000 status miles either...
[02:33] <RAOF> Or maybe hire a clone of you.  Or, maybe, even Rydberg.
[02:34] <RAOF> cnd: I was discouraged to find that I'm the person with the most miles logged in the Canonical tripit group :)
[02:34] <cnd> heh, no comment on that, other than that I wish we still had him around
[02:34] <cnd> RAOF, you're in australia!
[02:34] <cnd> every time you travel for canonical it's gotta be 20,000+ miles
[02:35] <RAOF> Not quite, but close :)
[02:35] <cnd> RAOF, how long are your longest flights in hrs?
[02:35] <RAOF> 16, I think.
[02:36] <cnd> from washington, dc to doha qatar was 13:30 for me, the longest I've ever been on
[02:36] <cnd> eek
[02:36] <RAOF> That's longest *continual* flight.  Sydney→Heathrow is like 22
[02:36] <RAOF> But with a stop in Singapore.
[02:37] <cnd> yeah
[02:38] <RAOF> I suspect I'll beat that if we go to Dallas again.  Qantas now flies Sydney→Dallas direct.
[02:40] <cnd> cool
[02:41] <RAOF> Yeah.  That'll be much more fun than SYD→LAX→DFW
[02:55] <cnd> RAOF, bryceh: I realized that the new grail depends on a new package called utouch-frame
[02:55] <cnd> it would require an upload, a review, a MIR request and review, etc
[02:55] <cnd> hmmm
[02:55] <RAOF> …which isn't all going to get done before A2 freeze.
[02:56] <RAOF> Is that a new source package, or new binary package?
[02:56] <cnd> I might need to branch off utouch-grail 1.0.16
[02:56] <cnd> which is in maverick
[02:56] <cnd> and I guess currently in natty
[02:57] <RAOF> Right.
[02:57] <RAOF> Is utouch-frame a new source package, or a new binary package of the existing utouch sources?
[02:58] <RAOF> If the latter, that'd only require an upload + archive admin prod.
[03:00] <cnd> new source package
[03:00] <cnd> I'm not sure I like the proliferation of utouch source packages
[03:00] <RAOF> Urgh.  Ok, that's not going to fly.
[03:00] <cnd> but I was apparently the only one on the team who felt so
[03:02] <cnd> as I look more closely at all this, I don't think the xi 2.1 + gesture work will be well tested enough
[03:03] <cnd> due to requiring some last minute changes
[03:03] <cnd> if we go with just gesture support
[03:03] <cnd> then I just need to add the gesture patches into xorg-server and evdev
[03:03] <cnd> I would like to update evdev to master though
[03:04] <RAOF> How risky is that?
[03:04] <cnd> which part?
[03:04] <RAOF> evdev → master.
[03:04] <RAOF> I'll look at the git log.
[03:04] <cnd> let me check what's all in there
[03:05] <RAOF> Hm.  Looks to me like master is 2.6.0.
[03:06] <RAOF> Lucky you!  That's what we've got in Natty.
[03:06] <cnd> hmm... I guess peter hasn't pushed my patches yet
[03:06] <cnd> then I would like to add my patches in
[03:06] <cnd> they're the foundation of xi 2.1, and have been working well for quite some time now
[03:07] <RAOF> On lots of MT and non-MT hardware?
[03:07] <cnd> RAOF, take a look at whot's evdev repo
[03:07] <cnd> RAOF, yes, both
[03:07] <cnd> at least, on trackpads and touchscreens
[03:07] <cnd> and if it breaks others I'd rather know sooner than later
[03:08] <RAOF> Wow.  That's a lot of deletions.
[03:08] <cnd> heh
[03:08] <cnd> actually, what is the server at for input abi
[03:09] <RAOF> Yeah, Mr Remove Support for ABI < 12.2
[03:09] <cnd> it's at 12.2 in 1.10 right now I think
[03:09] <cnd> I just want to be sure
[03:09] <cnd> anyways, I'll double check it
[03:09] <cnd> the patches add in masked valuator support
[03:10] <cnd> in xi 2.1 you can give incremental updates on valuators
[03:10] <cnd> so if the pressure hasn't changed, then that valuator axis isn't sent in the device event
[03:10] <RAOF> That makes sense.
[03:10] <cnd> it's mostly a bandwidth save in the x protocol
[03:10] <cnd> not huge for ST devices
[03:11] <cnd> but pretty good for MT devices that support tens or more pointer
[03:11] <cnd> points
[03:11] <RAOF> Woah!  I just managed to crash zsh.
[03:11] <cnd> heh
[03:11] <cnd> did it give you a quip out of a dungeon crawler game?
[03:12] <cnd> I can't remember what utility does that, maybe screen?
[03:12] <RAOF> No, it just SEGVd
[03:12] <RAOF> Screen, in nethack mode?
[03:12] <cnd> I'm unaware of a nethack mode
[03:12] <cnd> but if screen crashes it gives a nethack-like message
[03:12] <RAOF> Hm.  1.10RC1 has input ABI 12.0, master as of not a long time ago has 12.1, and I'm fetching a fresh master...
[03:13] <cnd> RAOF, well, if we're using 1.10RC1, then I'll just leave the patches alone for now
[03:13] <RAOF> We're not using 1.10
[03:13] <cnd> it would be nice to have, but I don't want to deal with breakage
[03:13] <RAOF> RC1
[03:13] <cnd> what are we using?
[03:13] <cnd> some snapshot of master?
[03:13] <RAOF> Yeah.
[03:13] <RAOF> Master as current as possible.
[03:14] <cnd> ok
[03:14] <RAOF> Because there are ABI breaks between 1.10 and master, and I don't particularly want to rebuild the world more times than necessary.
[03:14] <cnd> yeah
[03:14] <cnd> in that case, it may be easier for me to give you an updated gesture patch
[03:14] <cnd> unless you've already forward ported it
[03:14] <RAOF> I have not.
[03:14] <cnd> that one forward ported with ease
[03:15] <cnd> just conflicts in configure.ac that wiggle handled
[03:15] <cnd> hmm... master is still at 12.1
[03:15] <RAOF> Ah, yes.
[03:15] <cnd> I think peter has been meaning to bump it to 12.2, and the stuff in evdev is in xserver master
[03:16] <cnd> but it's just not worth fiddling with that much
[03:16] <cnd> if I can't git format-patch and shove it in debian/patches, it's too much work :)
[03:16] <RAOF> Looking at the patch, it didn't seem to actually check for 12.2, just use things unconditionally.
[03:17] <RAOF> Which means that if you're right, and master has what evdev needs, it'll just build?
[03:17] <cnd> hmmm, let me double check
[03:18] <cnd> RAOF, no, check evdev.h
[03:18] <RAOF> Yeah, just saw it.
[03:18] <RAOF> Although if you don't feel like fixing *that* up, I'd suggest you're feeling quite lazy :)
[03:18] <cnd> heh
[03:18] <cnd> well, I don't want to be patching things in and out as numbers change upstream
[03:19] <cnd> and it's 10:18 pm here
[03:19] <cnd> RAOF, so here's what I suggest:
[03:19] <cnd> I can forward port the gesture patch for xorg-server and xserver-xorg-input-evdev tonight
[03:20] <cnd> are the debian git repos up to date?
[03:20] <cnd> if so, I can push the updated patches in there once I've got them working
[03:20] <RAOF> Evdev is up to date, xserver is a couple of commits behind.  If you push to xserver I can happily just merge those changes in, though.
[03:21] <cnd> ok
[03:21] <RAOF> Oh, no.  It's not based on RC1+git in git.  I'll push that for you first.
[03:27] <cnd> gah, apt-get is useless if you have broken deps
[03:27] <cnd> anyone know how to tell it to stfu and do what I say?
[03:29] <RAOF> No, sadly.
[03:29] <RAOF> I either apt-get -f install to resolve things, or just apt-get download + dpkg --install
[03:29] <cnd> RAOF, so what's going on with vmmouse and wacom?
[03:30] <cnd> they still seem to have broken depends in xorg-edgers
[03:30] <RAOF> Oh, really?
[03:30] <cnd> at least on my computer
[03:30] <cnd> which just as xorg-edgers and I just ran apt-get update
[03:30]  * RAOF checks.
[03:31] <cnd> vmmouse depends on xorg-input-abi-12.1
[03:31] <cnd> wacom depends on xorg-input-abi-11.0
[03:33] <RAOF> Aaah, yeah.  I see what's happened there.
[03:33] <RAOF> wacom in edgers has been superceded by the archive version, which unsurprisingly isn't build against ABI 12.1
[03:33] <cnd> yeah, I just noticed that too :)
[03:34] <cnd> ok, I can get around this
[03:34] <RAOF> Remove wacom?
[03:34] <RAOF> And, looking at that list, I suspect synaptics, too?
[03:34] <cnd> no, not good enough
[03:35] <cnd> because xserver-xorg-input-all
[03:35] <cnd> yada yada
[03:35] <RAOF> Just remove -input-all
[03:35] <cnd> but that's a dependency of something else
[03:36] <cnd> hmm... maybe not
[03:36] <cnd> maybe things just got in such an inconsistent state that I had to install it for some reason
[03:37] <cnd> anyways, my machine is back to what it should be again
[04:44] <cnd> RAOF, looks like there's another abi breakage
[04:45] <cnd> I can't build the xorg-server package that exists in git.debian.org
[04:45] <RAOF> cnd: In master right now, or the upcoming DGA thingy?
[04:45] <cnd> in the ubuntu branch
[04:45] <cnd> I'm hitting a build error in hw/vfb/InitOutput.c
[04:46] <RAOF> That's odd.  It's *just* finished building right now locally.
[04:46] <cnd> struct _Screen has no member named index
[04:46] <cnd> RAOF, from the ubuntu branch?
[04:46] <RAOF> Yeah.
[04:46] <cnd> hmm...
[04:46] <RAOF> I, um, think so?
[04:46] <cnd> RAOF, what's your top commit hash?
[04:46] <RAOF> fbfe7a1ec506
[04:46] <cnd> that's not what I have...
[04:47] <cnd> I have ef7a6ac...
[04:47] <cnd> Set UNRELEASED; this isn't yet releaseable
[04:47] <RAOF> You may have pulled before I pushed the update to the master snapshot?
[04:47] <RAOF> Ah, yeah.  That's it.
[04:47] <cnd> oh, ok
[04:47] <RAOF> Hm.  To make it easy I should import the orig into the pristine-tar branch.
[04:49] <RAOF> There you go.  Now with pristine-tar goodness.
[04:51] <cnd> ok, hopefully I will finally have a tree that will build
[04:57] <cnd> RAOF, I'm still hitting that doxygen bug
[04:57] <cnd> how are you able to build it?
[04:57] <RAOF> If you use git-buildpackage it should pull the .orig.tar.gz out of the pristine-tar branch?
[04:58] <cnd> so I need to git fetch origin
[04:58] <cnd> to get the new branch
[04:58] <RAOF> Yeah.
[04:58] <cnd> then do I need any options for git-buildpackage?
[04:59] <cnd> I've never used it before
[04:59] <RAOF> It should just work.
[04:59] <RAOF> Although you might want to pass --git-ignore-new to it, otherwise it gets narky if you're not in an absolutely pristine git tree.
[05:02] <RAOF> How's that going?
[05:03] <cnd> well, it's still building
[05:03] <cnd> but the doxygen isn't till the end
[05:03] <RAOF> Ah.  You're not building in a chroot?
[05:04] <RAOF> That *might* be why it built for me, then.
[05:04] <RAOF> That'll be annoying if it is the case.
[05:04] <cnd> no, I don't usually bother
[05:04] <cnd> and it might explain it
[05:05] <RAOF> I have a tmpfs chroot, which makes it nice and fast to sbuild, so that's what I tend to do.
[05:05] <cnd> well, I can work around it for tonight
[05:05] <cnd> so I can test and push
[05:05] <RAOF> Yeah.
[05:18]  * cnd is turning off his alarm tomorrow
[05:18] <RAOF> Sorry for pulling you into a firedrill :(
[05:18] <cnd> heh, this is basically payback
[05:19] <cnd> remember when we pulled your out of your sleep for maverick feature freeze?
[05:19] <RAOF> Yeah.
[05:19] <cnd> really sorry bout that one
[05:20] <cnd> :)
[05:20] <cnd> got some wrong info and it caused a big mess
[05:20] <RAOF> That's ok.
[05:20] <RAOF> It didn't end up being *that* late for me.
[05:20] <RAOF> I can pull through 2am once a cycle :)
[05:21] <cnd> heh
[05:21] <cnd> so, ubuntu doesn't use udebs anymore
[05:21] <cnd> what would you think about patching out building them
[05:21] <cnd> ?
[05:21] <RAOF> We don't use udebs?  When?
[05:21] <RAOF> Or do you mean -dbg packages.
[05:22] <cnd> our installer isn't based on debian-installer
[05:22] <cnd> hasn't been for quite some time
[05:22] <RAOF> Even our alternate-cd?
[05:22] <cnd> according to cjwatson
[05:22] <cnd> hmm, don't know, but he said we didn't actually need utouch udebs
[05:22] <cnd> and without those, you'd get no X evdev either
[05:23] <RAOF> Maybe we don't use *X* in our alternate installer, and so don't need *X* udebs?
[05:23] <RAOF> That would make sense.
[05:23] <cnd> that could be?
[05:23] <cnd> anyways, building these udebs all the time is annoying
[05:23] <RAOF> So, you can avoid building the udebs with an environment variable...
[05:23] <cnd> so if we don't need them, maybe we should set a work item for O
[05:24] <cnd> yeah, I can
[05:24] <cnd> if I remember
[05:24] <RAOF> Indeed.
[05:24] <cnd> but the buildd's can't
[05:24] <cnd> it just sucks power and time
[05:24] <RAOF> Yeah.  If we really don't need the udebs, then that's a reasonably small diff to carry for quite a lot of buildd time.
[05:25] <cnd> ok, I got some debs for the server now
[05:26] <RAOF> In a chroot, or does it build outside now?
[05:26] <cnd> nah, I hacked it
[05:26] <RAOF> Heh.
[05:26] <cnd> gah!
[05:27] <cnd> the xf86CoordinatesToWindow patch is fubar'd
[05:27] <cnd> gotta fix it and redo it all again
[05:27] <RAOF> Fubar'd, or just sticks the function definition way out in nowhere?
[05:27] <RAOF> (In the header)
[05:27] <cnd> yeah
[05:28] <cnd> but in a location that breaks things
[05:28] <RAOF> :(
[05:28] <RAOF> At least ccache?
[05:29] <cnd> hmmm... I don't think I have it installed...
[05:29] <cnd> but I will use noudeb this time :)
[05:29] <RAOF> Better than ccache!
[05:33] <cnd> did you know that patch has been misnamed this whole time!
[05:33] <cnd> 202_xf86CoordinationsToWindows.patch
[05:33] <cnd> Coordinations?!
[05:33] <RAOF> What, really?
[05:33]  * RAOF loks
[05:33] <cnd> yeah
[05:33] <cnd> I'm fixing it
[05:34] <RAOF> that's awesome.
[05:51] <cnd> hrm, odd linking issue:
[05:51] <cnd> /usr/bin/Xorg: symbol lookup error: /usr/lib/xorg/modules/input/evdev_drv.so: undefined symbol: grail_open
[05:53] <cnd> I might know what's wrong though
[06:04] <cnd> RAOF, success!
[06:04] <cnd> I tested with ntrig touchscreen and magic trackpad
[06:04] <cnd> including adding and removing the trackpad
[06:06] <cnd> I just pushed the changes
[06:06] <cnd> I hope they work for you :)
[06:06] <cnd> cause I'm going to bed
[06:07] <cnd> good night!
[06:14] <RAOF> cnd: Awesomesauc.
[06:14] <RAOF> cnd: Sleep well!
[07:23] <RAOF> Um, what the hell?  I think I'm going to declare the inablility to click anywhere on the left-most ~150px of my dual head setup as a part of unity's general hatred of xrandr.
[07:24] <RAOF> Since it goes away in metacity, and doesn't re-occur once I run ‘unity --replace’
[08:17] <RAOF> Man.  We are the masters of not quite making 1.10's video ABI work.
[08:53] <bryceh> RAOF, heya
[08:53] <bryceh> RAOF, what's the problem?
[09:17] <RAOF> bryceh: Oh, my plymouth patches cause xserver 1.10 to SIGSEGV because of stupidity and your ati patch FTBFS because you missed a semicolon :)
[09:19] <RAOF> Bah.  I *hate* the way git doesn't update local branches unless you go crazy on it.
[09:22] <tjaalton> RAOF: like, running 'git pull'?-)
[09:23] <RAOF> tjaalton: No, like “git checkout ubuntu ; git pull ; git checkout debian-unstable ; git pull ; git checkout debian-experimental ; git pull ; …”
[09:23] <tjaalton> riight, that coulde be more straightforward
[09:24] <tjaalton> -e
[09:29] <RAOF> It's particularly annoying when you go “git merge debian-unstable ; hack hack hack ...”…
[09:30] <RAOF> Whoops, obsolete branch!
[10:46] <lool> Hi folks
[10:47] <lool> I get corruption in xterm with latest natty packages
[10:47] <lool> I guess it could be a -intel bug
[10:49] <RAOF> There's a damage bug with -intel, I think.  It could be the same one.
[10:50] <jcristau> there's https://bugs.freedesktop.org//show_bug.cgi?id=33253
[10:50] <lool> RAOF: Sounds likely
[10:50] <ubot4> Freedesktop bug 33253 in Driver/intel "[945] Left over damage in Emacs under Compiz" [Normal,New]
[10:50] <lool> I found LP #665711 this morning, but the reporter says it's fixed for him and it's from November
[10:50] <ubot4> Launchpad bug 665711 in xserver-xorg-video-intel (Ubuntu) "rendering bugs with xserver-xorg-video-intel (affects: 1) (heat: 33)" [Undecided,New] https://launchpad.net/bugs/665711
[10:50] <lool> plus it's 10.10
[10:50] <lool> closing this bug
[10:52] <seb128> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/707236
[10:52] <ubot4> Launchpad bug 707236 in xserver-xorg-video-intel (Ubuntu Natty) (and 2 other projects) "corruption in xchat-gnome window (affects: 1) (heat: 802)" [High,Confirmed]
[10:52] <seb128> speaking of corruption
[10:54] <lool> jcristau: Thanks, could be the same thing
[10:54] <lool> LP #707236 is actually forwarded to http://bugs.freedesktop.org/show_bug.cgi?id=33650
[10:54] <ubot4> Launchpad bug 707236 in xserver-xorg-video-intel (Ubuntu Natty) (and 2 other projects) "corruption in xchat-gnome window (affects: 1) (heat: 802)" [High,Confirmed] https://launchpad.net/bugs/707236
[10:54] <ubot4> Freedesktop bug 33650 in Driver/intel "[965GM] Relocation beyond target object bounds" [Major,New]
[10:55] <lool> seb128: Actually don't get these lines in dmesg
[10:59] <RAOF> Oh!  Where did Bryce go?
[11:00] <lool> I also have a 35M /var/log/gdm/:0.log full of:
[11:00] <lool> (WW) intel(0): I830DRI2GetMSC:1062 get vblank counter failed: Invalid argument
[11:00] <lool> (WW) intel(0): I830DRI2ScheduleWaitMSC:1118 get vblank counter failed: Invalid argument
[11:01] <RAOF> Odd.
[13:25] <kvalo> hi, I'm trying update a maveric laptop to natty, but get "E:Couldn't configure pre-depend x11-common for x11-xkb-utils, probably a dependency cycle."
[13:26] <kvalo> I saw that this was already happening with maverick: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/639933
[13:26] <ubot4> Launchpad bug 639933 in x11-xkb-utils (Ubuntu) (and 2 other projects) "10.04 -> 10.10beta: could not install the upgrades - Couldn't configure pre-depend x11-common for x11-xkb-utils, probably a dependency cycle. (affects: 41) (dups: 23) (heat: 288)" [High,Invalid]
[13:28] <kvalo> I guess best workaround is to force remove x11-xkb-utils?
[15:22] <cnd> RAOF, I don't imagine you're still up?
[17:09] <bryceh> rats, system froze up again at 2:30am last night.  Did I miss anything?
[17:16] <LLStarks> there was a sexy party
[17:16] <LLStarks> you missed it
[17:16] <bryceh> Sarvatt, uh oh - http://techreport.com/discussions.x/20326
[17:17] <LLStarks> just read about that
[17:17] <LLStarks> intel dun goofed
[17:17] <LLStarks> might as well just wait for ivy bridge now
[17:37] <LLStarks> "Intel said it expects to deliver the updated version of the chip set to customers in late February and expects a full recovery of production volumes by April. Intel said it would accept the return of the Cougar Point chip sets."
[17:37] <LLStarks> ouch
[17:54] <cnd> bryceh, what would you think of manually bumping the input abi to 13.0 in alpha 2?
[17:54] <cnd> the reason I suggest this is so when we actually push in the xi 2.1 work all the drivers don't need to be rebuilt at once
[17:55] <cnd> there won't be any backwards compat breakage
[17:55] <cnd> right now the input abi is a huge test and development issue, as I have to tell people to apt-get remove xserver-xorg-input-all and all the old drivers other than evdev when they test
[17:56] <cnd> at least, I think it should work ok
[18:00] <cnd> there's a couple very minor changes in the abi that I don't think would be used by any drivers
[18:00] <bryceh> cnd, hmm, couldn't that just be staged in a ppa?
[18:00] <cnd> bryceh, I would have to stage every package
[18:00] <cnd> though maybe that's not so hard
[18:01] <cnd> I can copy the package from natty and tell the ppa to rebuild it
[18:01] <cnd> yeah, that's probably a better solution
[18:01] <bryceh> cool
[18:02] <bryceh> could be less risky, and may give you a bit more flexibility in rolling out changes you need
[18:02] <cnd> yeah
[18:52] <LLStarks> bryceh, how can i force my touchpad to use synaptics instead of evdev?
[18:58] <bryceh> llstarks, I'd set it in xorg.conf
[19:13] <bryceh> hmm
[19:13] <bryceh> The following packages have been kept back:
[19:13] <bryceh>   libplymouth2 plymouth xserver-xorg-video-nouveau
[19:42] <tjaalton> hmm, how do I change the address for ubuntu-x-swat -mail?
[19:43] <tjaalton> it doesn't seem to obey the "normal" lp mail rules
[19:43] <bryceh> tjaalton, I set it to send to a mailing list, which you can sub/unsub from
[19:44] <bryceh> tjaalton, I just use procmail to filter it down myself
[19:44] <tjaalton> bryceh: ah, looks like I got it now.. will see
[22:04] <RAOF> cnd: Your 2am ping is unlikely to rouse me :)
[22:05] <cnd> heh, no worries :)
[22:05] <cnd> I can't even remember what I pinged you for now
[22:05] <RAOF> For the Xi 2.1 transition, as that breaks the input ABI, right?
[22:05] <cnd> yeah
[22:05] <cnd> slightly
[22:05] <cnd> iirc, just a few struct element rearrangements
[22:05] <RAOF> Everything needs a rebuild?
[22:06] <RAOF> Oh, goodie. *Silent* corruption :)
[22:06] <cnd> yes, it will need it since all the dpkgs depend on a specific abi
[22:06] <cnd> but I think we're ok for now
[22:07] <RAOF> Yeah.  When we do that, if we need to rebuild all the input drivers, we should add a Breaks: on abi-12 and set the server input abi to something like 12+multitouch.
[22:08] <bryceh> morning RAOF
[22:08] <cnd> I'd say 12.99.1
[22:08] <cnd> if you want to go with X numbering :)
[22:08] <cnd> but I don't think that works
[22:08] <cnd> so lets say 12.901
[22:08] <RAOF> bryceh: Morning :)
[22:08] <RAOF> I was actually just thinking of the input abi as specified in xorg-server/debian/inputabi
[22:09] <RAOF> Rather than the actual searchable #define.
[22:09] <cnd> RAOF, the abi is gathered from the x source code
[22:09] <RAOF> Not the one in debian/inputabi.
[22:09] <cnd> oh, you're thinking of *that* one
[22:09] <cnd> well, that one will need to be bumped too
[22:09] <cnd> but there's the other virtual package for input abi
[22:10] <cnd> based on the source code
[22:10] <RAOF> Yeah.
[22:11] <RAOF> Oh, right.  And the one I'm thinking of isn't the one that produces the dependencies.
[22:11] <cnd> well, as I found out today, it does produce some dependencies
[22:12] <cnd> that are rather hard to track down :)
[22:12] <RAOF> From memory, debian/inputabi is used to generate the Provides:
[22:13] <cnd> yes, but what good is a provides if there's no depends? :)
[22:13] <cnd> it turns out that the xorg-server binary package depends on those provides
[22:13] <RAOF> It allows the xserver to Breaks on that provides.
[22:13] <cnd> that may be too
[22:14] <LLStarks> raof, that synaptics issue seems to have disappeared
[22:14] <LLStarks> it had been bugging me for a few days though
[22:14] <RAOF> Hurray!
[22:15] <LLStarks> there was no obvious update that would've fixed this though
[22:15] <RAOF> cnd: Oh, yeah.  xserver-xorg (prior to the most recent upload) Depended on x-x-{input,video}
[22:15] <RAOF> cnd: Oh, yeah.  xserver-xorg (prior to the most recent upload) Depended on x-x-{input,video}-all | xserver-xorg-{input,video}-$ABI
[22:16] <LLStarks> nonetheless, i think it's still worth keeping in the a2 notes. it could come back and i was even affected by it until about an hour ago.
[22:17] <LLStarks> i didn't do anything beyond my normal laptop use routine
[22:18] <RAOF> Is it now persistent across X server starts?
[22:24] <RAOF> bryceh: So where are we vis-a-vis the xserver?
[22:27] <bryceh> RAOF, I've got the packages built and have reviewed changelogs.  Tested some of them.  Trying to install xserver manually but having to force things a bit
[22:28] <RAOF> Ah, of course.  Because I added a Breaks: to xserver-xorg-video-8 it won't install while you've got a video driver installed.
[22:29] <bryceh> yeah
[22:29] <bryceh> tried --force-breaks but that seems to have dug my hole deeper :-)
[22:29] <RAOF> Just uninstall all your video drivers :)
[22:29] <bryceh> ok
[22:30] <RAOF> Hm.  --force-breaks *should* work.
[22:30] <RAOF> Let me try again on a cleanish system...
[22:32]  * cnd waits patiently too
[22:32] <cnd> I'd like to move off of depending on xorg-edgers
[22:32] <bryceh> making progress...
[22:32] <cnd> and then I can just add patches in debian/patches for changes
[22:38] <bryceh> cnd, that's a good idea
[22:38] <bryceh> hmm, I seem to be in a dependency mess
[22:42] <bryceh> ahh there we go
[22:44] <bryceh> dah nope
[22:45] <bryceh>  xserver-xorg-core (2:1.9.99.901+git20110131.be3be758-0ubuntu1) breaks xserver-xorg-video-8 and is unpacked but not configured.
[22:45] <bryceh>   xserver-xorg-video-intel (2:2.14.0-1ubuntu3) provides xserver-xorg-video-8.
[22:49] <bryceh> hmm I probably should have shoved all this into a ppa
[22:51] <bryceh> it's like xserver doesn't want to install without a video driver, but the video drivers don't want to install without the xserver, and they won't install all-togther
[22:53] <bryceh> http://paste.ubuntu.com/560766/
[22:53] <Sarvatt> bryceh: need to rebuild everything against that new xserver's dev packages
[22:55] <bryceh> Sarvatt, ah right, the pbuilder would have built -intel against the repo xserver
[22:55] <bryceh> hrmm
[22:56] <bryceh> but if I can't install it, how can I rebuild the driver?
[22:58] <Sarvatt> bryceh: I use schroot to make it easier instead of pbuilder, you could add a local package repository to the pbuilder though
[22:59]  * bryceh --force-depends
[23:01] <lool> Hmm xserver-xorg-video-intel Recomends python-dev, isn't that a bit strong?
[23:01] <lool> This pulls libssl-dev, zlib1g-dev...
[23:02] <bryceh> lool, it might be overmuch; it's for the gpu freeze apport hook
[23:02] <bryceh> lool, is there a better dependency for "this package has a python script"?
[23:05] <RAOF> Shouldn't we actually declare a depends on apport instead?
[23:05] <RAOF> And then override that lintian warning?
[23:06] <bryceh> or we could move that script I guess
[23:06] <bryceh> put it with the xorg apport hook
[23:08] <lool> bryceh: python script should just be python?
[23:08] <lool> bryceh: But apport implies that already
[23:08] <lool> I mean, if people run apport, by definition they have support for apport hooks
[23:09] <lool> I basically wouldn't declare any dep; just ask people to run apport / ubuntu-bug
[23:10] <bryceh> lool, no the gpu hook fires off automatically when the gpu freezes
[23:11] <lool> The intel_gpu_dump Recommends seems more adequate
[23:11] <bryceh> at least, it's supposed to; it doesn't seem to work in all cases
[23:11] <lool> bryceh: Where is this gpu hang hook?
[23:11] <lool> Is it debian/apport-gpu-error-intel.py ?
[23:16] <bryceh> lool, yes
[23:17] <lool> SUBSYSTEM=="drm", ACTION=="change", ENV{ERROR}=="1", RUN+="/usr/share/apport/apport-gpu-error-intel.py"
[23:18] <lool> bryceh: Yeah, so you definitely want an apport dep of some sort
[23:19] <lool> It doesn't really matter too much that you use Suggests or Recommends; it only makes a difference for the case where people install their system without Ubuntu tasks like the desktop task since the task will pull apport
[23:20] <lool> But since you will want to be the package pulling intel-gpu-tools by default, I'd probably recommends apport + intel-gpu-tools
[23:20] <bryceh> RAOF, ok the -intel and -radeon packages look fine and boot into the old xserver ok (on two machines), I can upload those directly.  Not sure how to test mtdev but that looks safe to go in too.
[23:20] <lool> and you could add an explicit python Recommends since the script is /usr/bin/python
[23:20] <RAOF> I think mtdev has already happened.
[23:20] <bryceh> lool, ok thanks
[23:21] <RAOF> bryceh: Yup.  Someone's sponsored mtdev already.
[23:21] <bryceh> RAOF, yep
[23:24] <bryceh> RAOF, I can't easily test -nouveau but it looks sane, I can upload that too
[23:25] <bryceh> looks like the same change as done in the others
[23:26] <RAOF> Yeah.
[23:26] <RAOF> I'll do some more testing on my other nouveau system.
[23:27] <bryceh> alright, the three drivers are uploaded
[23:32] <bryceh> -evdev seems not to have done anything obviously bad on my systems, I'll upload that too
[23:44] <bryceh> [ubuntu/natty] xserver-xorg-video-intel 2:2.14.0-1ubuntu3 (Accepted)
[23:44] <bryceh> [ubuntu/natty] xserver-xorg-video-nouveau 1:0.0.16+git20110107+b795ca6e-0ubuntu2 (Accepted)
[23:44] <bryceh> [ubuntu/natty] xserver-xorg-video-ati 1:6.13.2+git20110124.fadee040-0ubuntu2 (Accepted)
[23:54] <LLStarks> is nouveau gallium scheduled for natty or natty+1?
[23:55] <LLStarks> *gallium 3d
[23:55] <RAOF> It's already available in the form of libgl1-mesa-dri-experimental.
[23:55] <RAOF> And has been for some time :)
[23:57] <LLStarks> default seed?
[23:57] <LLStarks> or rather, used by default?