[10:57] <tseliot> tjaalton: now that I think about it we'll have to recreate the orig for the nvidia driver since we're going to update the driver to the latest release. I have already filed a SRU for Hardy for the lrm-envy. This is definitely something we want to have in Intrepid ASAP since it also adds "preliminary support for X.Org server 1.5". What do you think?
[10:58] <tjaalton> tseliot: sure, although 1.5 is not in intrepid yet
[10:58] <tjaalton> and it might take a few weeks
[10:58] <tseliot> the driver is future-proof ;)
[10:59] <tseliot> and we might also take the chance to remove those files which you wanted me to keep
[10:59] <tseliot> since compatibility with Debian will break anyway
[10:59] <tjaalton> why?
[11:00] <tseliot> a different orig tarball
[11:00] <tjaalton> if they are not installed, it's harmless to keep them
[11:00] <tjaalton> debian will update theirs sooner or later
[11:00] <tseliot> and their existence might make things a bit more confusing for any potential contributor
[11:01] <tseliot> not that I think that there will be any ;)
[11:01] <tjaalton> document it
[11:02] <tseliot> shall I write something like "the following files are useless"?
[11:02] <tjaalton> README.Ubuntu or something
[11:04] <tseliot> ok, I can do it as soon as I'm done with the rest of the package.
[11:04] <tseliot> I'm reviewing the diversions
[11:08] <tjaalton> ok
[11:29] <tseliot> tjaalton: shall I replace the list of the supported cards in the control.in with the new cards or just comment them out and add the new list?
[11:30] <tseliot> or maybe I should add it to the changelog
[11:34] <tseliot> also, shall I keep revision ubuntu1 instead of ubuntu2?
[11:41] <tjaalton> ubuntu1
[11:41] <tseliot> ok, and about the control.in?
[11:42] <tjaalton> what do you mean by commenting out?
[11:42] <tjaalton> add the new cards to the list perhaps
[11:43] <tseliot> you told me not to remove lines but to comment them out (i.e. put  a # before a line)
[11:44] <tjaalton> what lines are you talking about?
[11:45] <tjaalton> unless you comment out the whole package, I don't think it would work in control
[11:45] <tseliot> read where it says " The following GPU's are supported:"
[11:45] <tseliot> but yes, I can just add the new cards
[11:46] <tseliot> to the list
[11:47] <tjaalton> so, since nvidia-kernel-source is not needed you can either comment or delete it
[11:49] <tseliot> nvidia-kernel-source = DKMS
[11:49] <tjaalton> I believe the diff didn't have it
[11:49] <tseliot> we still need it
[11:49] <tjaalton> but you know better
[11:49] <tseliot> I didn't remove it
[11:49] <tjaalton> ok, maybe it was the broken diff
[11:50] <tseliot> I will give you the full source once I think it's complete
[11:50] <tseliot> this might happen today, so that we can test it together
[11:50] <tjaalton> ah, it was -ia32
[11:50] <tseliot> right
[11:50] <tjaalton> n-g-ia32
[11:51] <tseliot> of course
[11:52] <tjaalton> so hmm.. commenting out is better in the sense that then you know what has been "removed"
[11:53] <tseliot> aah, without having to read the diff, you mean
[11:53] <tjaalton> yes
[11:54] <tjaalton> well, merge diff against the debian version
[11:54] <tjaalton> diff.gz doesn't show that
[15:51] <tjaalton> nice, security updates for the xserver
[15:56] <jcristau> for some value of 'nice' :)
[15:57] <kees> url?
[15:58] <tjaalton> http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=shortlog;h=server-1.4-branch
[15:58] <tjaalton> kees: ^
[15:58] <jcristau> kees: http://lists.freedesktop.org/archives/xorg/2008-June/036026.html
[15:58] <tjaalton> oh, that's much better :)
[15:58] <tjaalton> right, didn't notice the announce
[15:58] <tjaalton> -ment
[15:59] <jcristau> kees: it wasn't posted to vendor-sec?
[16:00] <kees> jcristau: yeah, found it now -- only 2 days lead time.  whee
[16:00] <kees> (last time we had like a month, weird)
[16:00] <jcristau> kees: it was reported to xorg long ago...
[16:16] <jcristau> kees: i guess next time i can cc you when i send mail to team@security.d.o
[16:18] <kees> jcristau: security@ubuntu.com please, yes.  and bryce, if he's not already on the security.d.o list
[19:19] <bryce> kees: the cve patches built fine for intrepid and hardy, shall I go ahead and upload both of those, or do you want to do some testing first?
[19:20] <kees> bryce: I'll leave it to you for intrepid, but for hardy (and the others) they need to go through the -security queue:
[19:20] <kees> https://wiki.ubuntu.com/SecurityUpdateProcedures
[19:21] <kees> mostly, if you can create debdiffs, I can start testing.  getting reproducers for the problem, or ways to test the affect code paths would be cool too.  :)
[19:21] <kees> it might be easiest to open a bug for it
[19:21] <bryce> yeah  no clue on reproducers
[19:22] <jcristau> there are some on the upstream bug
[19:22] <jcristau> but it's still restricted
[19:23] <jcristau> i'll send it to you
[19:23] <bryce> kees, hardy debdiff:  http://people.ubuntu.com/~bryce/Testing/xorg-server_1.4.1~git20080131-1ubuntu9.2.debdiff
[19:24] <jcristau> {kees,bryce}@u.c?
[19:24] <bryce> that should work
[19:25] <kees> jcristau: security@ubuntu.com for security notices, but yeah
[19:25] <kees> jcristau: that way jdstrand gets them too
[19:25] <jcristau> ok
[19:25] <kees> thx :)
[19:25] <bryce> intrepid debdiff just for completeness - http://people.ubuntu.com/~bryce/Testing/xorg-server_1.4.1~git20080131-1ubuntu12.debdiff
[19:26] <kees> bryce: why is it ubuntu9.2 for hardy?
[19:26] <bryce> ...uploading the intrepid fixes now...
[19:26] <bryce> kees, there is a 9.1 already in hardy-proposed
[19:26] <bryce> although I just spotted an error in it
[19:28] <bryce> feel free to renumber or whatever as appropriate
[19:29] <kees> bryce: ah, righto.  The debdiff itself needs be applied to ubuntu9 (though 9.2 is the correct version).  And the 9.1 needs to be respun to include the security updates and pushed back to -proposed.  (i.e. -security updates only every build on top of things -updates, as -proposed packages haven't officially cleared QA)
[19:29] <kees> error spotting in which thing?
[19:30] <bryce> kees, the patch added in 9.1 for -geode was not actually listed in series (probably my fault)
[19:31] <bryce> erf, that sounds messy - would you be willing to sort those out while I do the patch backports?
[19:34] <jcristau> kees: sent
[19:38] <kees> bryce: sure, I can re-base the hardy debdiff.
[19:38] <kees> jcristau: thanks
[19:41] <bryce> kees: cool thanks.  looks like the patches are applying fairly cleanly except for dapper
[19:42] <jcristau> the patches for dapper shouldn't be too different from etch
[19:43] <jcristau> and i don't think i had any issues with that, hmm
[19:45] <bryce> jcristau: there's just one patch that isn't applying - org-xserver-1.4-cve-2008-2360.diff
[19:45] <bryce> 1 out of 2 hunks FAILED -- saving rejects to file render/glyph.c.rej
[19:46] <jcristau> oh, ok
[19:46] <bryce> I'll take a look in a minute
[19:46] <jcristau> probably the #include <stdint.h>
[19:47] <bryce> kees, gutsy debdiff:  http://people.ubuntu.com/~bryce/Testing/xorg-server_1.3.0.0.dfsg-12ubuntu8.4.debdiff
[19:47] <bryce> for feisty (only), the debdiff is including a bunch of .gitignore deletion garbage
[19:48] <kees> cool
[19:55] <bryce> kees: do you care about these .gitignore bits?  I'm not exactly certain how to exclude those changes... but they're obviously completely harmless, just messy
[19:58] <kees> bryce: while I like cleanliness, I can live with the mess.  :)  I suspect it's due to .devscript settings for the -I options during the build
[19:58] <jcristau> or dpkg-source behaviour change
[19:58] <bryce> ok, feisty debdiff:  http://people.ubuntu.com/~bryce/Testing/xorg-server_1.2.0-3ubuntu8.4.debdiff
[19:59] <bryce>  more ~/.devscripts 
[19:59] <bryce> # debuild
[19:59] <bryce> DEBUILD_PRESERVE_ENVVARS="DISPLAY,GNOME_KEYRING_SOCKET,XAUTHORITY"
[19:59] <bryce> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I.bzr -I.svn"
[19:59] <bryce> is there something there I could/should change to prevent this issue?
[19:59] <bryce> e.g. -I.gitignore ?
[19:59] <kees> see if removing -I.bzr for that debuild makes it go away.  if not, no big deal.  (the bug is that the original released builder didn't use -I.bzr I think)
[19:59] <kees> oh, .git
[20:00] <kees> er
[20:00] <kees> sure, give it a shot.  :P
[20:00] <jcristau> newer dpkg-source filters out .git and .gitignore by default
[20:00] <bryce> ok, well I guess let's not worry about it...  it's just feisty that's affected
[20:17] <tseliot> tjaalton: I've just sent an email with my PPA with the driver to superm1 and CCed you
[20:20] <bryce> hmm, dapper's xserver uses a different patch system
[20:36] <bryce> kees, ok here's dapper:  http://people.ubuntu.com/~bryce/Testing/xorg-server_1.0.2-0ubuntu10.11.debdiff
[20:37] <bryce> kees, I think that should be it for the debdiffs.
[20:37] <kees> bryce: very cool, thanks.
[20:38] <bryce> the broken dapper patch was a pretty trivial conflict, I don't think it'll affect functionality
[21:10] <pwnguin> ah, its so hard to remember that the envy guy albert milone uses the screen name tseliot
[21:11] <tseliot> pwnguin: yes, it's me ;)
[21:14] <bryce> tseliot: so you a poetry fan or is the nick derived from some other source?
[21:15] <tseliot> bryce: yes, I like poetry and my first exam at the university was on T.S. Eliot
[21:16] <bryce> ah cool
[21:16] <tseliot> bryce: so, I received the notification from the spec
[21:17] <tseliot> cjwatson should approve it, right?
[21:18] <tseliot> let me rephrase it. We need his approval, right?
[21:19] <bryce> yes
[21:19] <tseliot> ok
[21:19] <bryce> to be honest the whole blueprint approval process is a tad fuzzy for me, but that's how I understand it
[21:20] <bryce> last time around I don't think my specs got set to Approved, but cj verbally ok'd them so I went ahead and did them.
[21:21] <bryce> since colin was in for the discussion on this and seemed cool with it, getting it set to approved may be more of just a formality but he often has useful comments
[21:21] <tseliot> great, this makes things a lot clearer
[21:23] <tseliot> I'll keep working on it
[21:23] <bryce> I'm also not sure if they need to be set to Review or Pending Approval...  I'll find out and adjust
[21:23] <bryce> cool; I still owe you review comments.  it's on my todo list but after a few other things
[21:24] <tseliot> ok, I wait for your comments then ;)
[22:32] <kees> jcristau: just as a note, in the ProcShmPutImage fix, should the errorValue be totalHeight instead of totalWidth?
[22:54] <bryce> tseliot: I've updated the X/OptionsEditor spec a bit with some thoughts based on the mockup.
[23:03] <tseliot> bryce: great, I'll have a look at the changes tomorrow since it's 00:03 AM here. Good night
[23:04] <bryce> great, 'night
[23:50] <jcristau> kees: hrm. probably, yes