[00:26] <jcristau> kees: actually, i think it doesn't matter. if width*height overflows, you don't really know if the error value is height or width
[00:26] <jcristau> so choosing width makes as much sense as the other one
[00:38] <kees> jcristau: heh, yeah, fair point
[00:39] <jcristau> kees: you had me worried for a while ;)
[09:24] <tjaalton> "GEM merging to master"...
[19:11] <tjaalton> bryce: btw, should we branch xorg/xorg-server for hardy?
[19:11] <tjaalton> and merge the current branch with experimental
[19:13] <bryce> perhaps, although I'm not sure if we'll have a lot of changes for the hardy xserver
[19:14] <bryce> (I also find having to give my password 3x to do a git pull to be irritating, but anyway) :-)
[19:14] <bryce> merging the current branch with experimental is a good idea
[19:15] <bryce> at yesterday's meeting, doko and slangasek were talking about giving MoM an ability to do merges of not just Unstable, but also the option of Testing and Experimental.  But I'm guessing that'll be a while.
[19:15] <tjaalton> put an RSA key there, DSA keys don't work :)
[19:16] <bryce> well I don't think I can ssh in anyway
[19:16] <tjaalton> to alioth? you should be able to
[19:17] <tjaalton> you can add the key from the web interface
[19:17] <bryce> ah ok
[19:17] <bryce> last I tried was a couple weeks ago, maybe things have changed
[19:19] <bryce> yeah it just hangs.  I'll try the web interface
[19:20] <tjaalton> hmm that's weird, mine keeps asking for the password without a key
[19:27] <tjaalton> tseliot: I haven't had a chance to look at the package yet :/
[20:06] <Q-FUNK> howdy
[20:06] <Q-FUNK> has there been any report of the -intel that just entered hardy-updates disturbing suspend/hibernate?
[20:07] <Q-FUNK> both pm-utils and -intel received new packages over the last couple of days.
[20:08] <bryce> heya Q-FUNK
[20:08] <Q-FUNK> heya :)
[20:10] <tseliot> ﻿tjaalton:no problem, superm1 reported a few problems but I haven't had the time to fix them today
[20:22] <bryce> Q-FUNK: btw yesterday I was looking again at the -geode pci id fix to xserver and noticed the patch wasn't actually enabled
[20:22] <bryce> Q-FUNK: it's enabled properly on intrepid though.  Have you had a chance to test against intrepid?
[20:23] <Q-FUNK> hm?!
[20:23] <Q-FUNK> not enabled?
[20:23] <Q-FUNK> oh, to x server
[20:24] <Q-FUNK> yes, it turns out that debian completely skips xf86config and instead uses the pic id provided by each driver
[20:24] <Q-FUNK> at least, that's how it appears to me
[20:24] <bryce> sounds right
[20:24] <Q-FUNK> (others are welcome to correct me if I'm wrong)
[20:24] <bryce> ok, so the patch in ubuntu9.1 is irrelevant?
[20:25] <Q-FUNK> probably
[20:25] <bryce> yeah that sounds right to me
[20:25] <bryce> ok cool, I'll update the sru request
[20:25] <Q-FUNK> I haven't entirely figured out whether debian completely skips the content of that file or wheter it complements it with the driver.ids that comes in each chip driver
[20:26] <Q-FUNK> jcristau probably knows better than me, on that issue
[20:27] <Q-FUNK> as for the -nsc fix, pitti pointed out that he'd rather have someone figure out a way to revert the Makefile.am patch that generates nsc.ids and replace it with my static list, rather than accept my completely overhauled package
[20:27] <Q-FUNK> I guess it makes sense.  the delta would be a lot smaller.
[20:28] <Q-FUNK> whoever manages to do it, we can also contribute it to debian.  it would save bgoglin the trouble of figuring out how to do this on his way back from vacations.
[20:36] <bryce> Q-FUNK: ok, then sounds like there should be new bugs opened for those two issues
[20:43] <Q-FUNK> for -geode, though, we pretty much have to move forward and adopt what I have in my PPA as-is.  trying to force-fit the update into the 2.8.0 packaging paradigm won't work.
[20:44] <Q-FUNK> and we cannot upload this without the fixed -nsc being uploaded first, becuase of the versioned conflit
[20:45] <bryce> hmm, in that case maybe it just can't be sru'd to hardy at all
[20:47] <Q-FUNK> pitti tells me that it might be a though case.  however, either we do it or we end up with a broken LTSP in LTS for the next 3 years.
[20:47] <Q-FUNK> and yes, moving those symbolic links to the transtional -amd package is the only clean way to do this
[20:49] <bryce> -geode uploaded
[20:49] <Q-FUNK> erm..... which one?
[20:50] <bryce> the one in your ppa
[20:50] <Q-FUNK> if we don't first upload the fixed -nsc, we actually break what little operativity we had
[20:50] <bryce> I'm doing that one next
[20:50] <Q-FUNK> the -geode in my PPA depends upon the fixed -nsc having been uploaded first
[20:52] <bryce> it seemed to build fine
[20:52] <Q-FUNK> yup, but it deviates from the XSF framework, which is why pitti found it totally unacceptable as an SRU
[20:52] <bryce> howso does it deviate?
[20:53] <bryce> ok, -nsc built... uploading
[20:53] <bryce> ok uploaded
[20:53] <Q-FUNK> debian has the same reservations about my cdbs-based refactoring, which is why both pitti and bgoglin would prefer simply removing the makefile.am patch and replacing it with a simple install of the static nsc.ids I produced
[20:54] <kees> bryce: can you confirm on i386 that the DBE-DoS PoC is fixed in intrepid?  so far it's unfixed for me in hardy and gutsy.
[20:54] <bryce> whoops, you had hardy listed there... need to set that to intrepid
[20:54] <kees> jcristau: did you confirm that DBE-DoS was fixed in your builds?  I'm still seeing a DoS with it
[20:55] <bryce> Q-FUNK: ok well once you have that let me know and we can re-upload the fixed version to intrepid
[20:56] <bryce> kees: unfortunately my intrepid testing box is amd64
[20:56] <bryce> kees: (at your recommendation ironically enough ;-))
[20:56] <bryce> ooh, new -ati release
[20:57] <bryce> erf, first need to finish up the -intel 2.3.1 upload though...
[20:57] <kees> bryce: sure, but you can run an i386 kvm on it, yes?
[20:57] <bryce> dunno, I don't have kvm set up on it at all
[20:58] <bryce> kees: anyway since we're running the same version of xserver, if you can't verify it on hardy it almost certainly is also busted on intrepid.
[20:58] <kees> bryce: well it seems that the DBE stuff isn't fixed, so I'd like to figure out how to get it fixed.
[21:05] <kees> bryce, jcristau: err... it seems actually that there was no fix made for the DBE stuff?
[21:05] <bryce> kees, hrm, I'm not sure what I could do to help there
[21:12] <bryce> I'm not sure what you mean by 'DBE'.  There isn't a reference to "DBE" in the advisory?
[21:12] <kees> bryce: yeah, that's what I'm seeing too.  Perhaps it was skipped for now?
[21:12] <kees> I'll assume so, and get these updates tested for regressions.
[21:13] <bryce> well, what is DBE?
[21:13] <kees> everything else looks great in them -- all the PoCs fail now.  :)
[21:13] <kees> notes in the PoC say: DOUBLE-BUFFER extension
[21:21] <bryce> ok maybe jcristau knows more
[21:25] <kees> yeah, I assume it's an unaddressed issue.
[23:18] <jcristau> kees: the dbe dos wasn't considered a security problem
[23:20] <kees> jcristau: okay, cool.  it certainly is a DoS though.  ;)  owchy on my VMs
[23:20] <kees> filled / before I figured out what was going on.  hehe
[23:21] <jcristau> heh
[23:23] <jcristau> the fix on master is at http://cgit.freedesktop.org/xorg/xserver/commit/?id=23e71ef71a178505494d4b410f9314acfff81524
[23:23] <jcristau> but, it won't apply directly on previous versions, and when an attacker has access to your x server you have other problems anyway
[23:25] <kees> jcristau: yeah, I'm fine with that getting skipped.  :)