[00:41] <bryce> yep, mesa is mucha fun
[01:01] <tjaalton> ok, xserver 1.5 should be looking better. many patches deleted, some need forwarding upstream and some need to be forward ported
[01:02] <tjaalton> umm, getting late. I'll push this tomorrow
[01:02] <tjaalton> night ->
[01:07] <bryce> great
[01:07] <bryce> mesa seems to not be building on amd64 (some pbuilder issue) but looks like it's ok on i386 so far.  I'll push it once it's finished building.
[03:05] <bryce> mesa's pushed.
[03:10] <bryce> tjaalton: I've also gone through a preliminary merge for xorg; I'd appreciate a review if you wouldn't mind:  http://people.ubuntu.com/~bryce/Testing/xorg/
[06:25] <tjaalton> bryce: sure
[06:40] <tjaalton> bryce: fwiw, I think xfonts-utils could've been synced, since the changes were meant for dapper->hardy upgrades
[06:45] <tjaalton> same goes to -vmware, a proper fix has been applied upstream :)
[06:53] <tjaalton> bryce: xorg; I think the x11r6_bin_not_empty_move change can be deleted from templates and preinst
[06:56] <tjaalton> bryce: is this targeted for 1.5?
[08:55] <bryce> tjaalton: ah, that wasn't clear to me from the xfonts-utils changelog.  I did notice -vmware is syncable and will do that later
[08:58] <tjaalton> bryce: sure, great
[09:00] <tjaalton> xorg; radeonhd should already be in included in video-all
[09:17] <tjaalton> and x11-common/xserver-xorg change actually reverts the change done in debian
[09:17] <tjaalton> which is to move stuff from xserver-xorg to x11-common
[09:18] <bryce> both of those are things I'm curious and not sure about
[09:18] <tjaalton> hmm let me check that
[09:18] <tjaalton> radeonhd is listed already though
[09:19] <bryce> ok
[09:20] <tjaalton> rules; it should be x11-common instead of xserver-xorg
[09:21] <bryce> so what should I change?
[09:22] <tjaalton> leave them as they are in debian?-)
[09:23] <bryce> uh, but in this latest set of changes debian is moving them back from x11-common to xserver-xorg
[09:26] <tjaalton> hmm, I don't understand.. I'm looking at the current debian version and the initscript and stuff are in x11-common
[09:28] <tjaalton> my mistake that I thought there was an actual change in debian. seems that not much has moved
[09:28] <tjaalton> debconf has, but not the initscript or Xsession etc
[09:28] <tjaalton> uh, dexconf
[09:31] <bryce> 'X' as well
[09:31] <tjaalton> right
[09:32] <bryce> what I'm unsure of is what this implies for some of the ubuntu-specific changes relating to x11-common
[09:33] <tjaalton> like the apport script and failsafe?
[09:34] <bryce> right, and "Add a dependency to xserver-xorg for each binary built to save disk/livecd space."
[09:34] <tjaalton> that's because we only ship one set of docs
[09:35] <tjaalton> and the rest is symlinked
[09:35] <bryce> right, and I changed the paths from .../x11-common/... to .../xorg-server/... - but is that correct?
[09:35] <tjaalton> xserver-xorg-driver-all could be dropped
[09:37] <tjaalton> why should those be moved?
[09:38] <bryce> exactly my question
[09:38] <tjaalton> hehe
[09:40] <tjaalton> so, if x11-common is not installed by default then yes, they should be moved
[09:44] <tjaalton> but it seems that x11-common is installed if you need _any_ of the X libs, so it should be safe to keep them there
[09:48] <tjaalton> ie. it has many reverse-dependencies, so keeping the changelog etc in x11-common is a safer bet
[09:48] <bryce> ok
[09:48] <tjaalton> xserver-xorg is only installed if you have X installed
[09:53] <tjaalton> btw, there's -12 which has openchrome
[09:53] <tjaalton> and didn't q-funk want to drop amd from the deps?
[09:53] <bryce> ah, didn't see -12 yet
[09:53] <tjaalton> it was released last night :)
[09:54] <bryce> yeah, I need to doublecheck the amd stuff
[09:54] <tjaalton> you'll keep the BPX stuff for the time being?
[09:55]  * bryce nods
[09:56] <bryce> probably not much longer though.
[09:57] <bryce> maybe I should chat with Colin about it when we get together in London first.
[09:57] <tjaalton> ok, so if you plan on moving it, xserver-xorg should C/R x11-common
[09:58] <tjaalton> but if it gets dropped, maybe keep in x11-common until you come up with a plan
[09:59] <tjaalton> colin hasn't replied to the hal-script post.. maybe you'll manage to hack it so it actually works :)
[10:00] <bryce> you might re-email him on that; he recently had a death in the family and was gone for a week and probably fell far behind in email
[10:00] <tjaalton> oh right.. :/
[10:01] <tjaalton> when is the sprint scheduled?
[10:01] <bryce> Jul 14-18
[10:02] <tjaalton> ok
[10:03] <tjaalton> I might re-email after I get back on Jun 29th
[10:03] <tjaalton> after tomorrow I'll be mostly offline, but will check email & irc almost daily
[10:03] <tjaalton> yay for 3G
[10:04] <bryce> :-)
[10:04] <tjaalton> (well, GPRS on rural areas..)
[10:04] <bryce> think xserver 1.5 can be put in by then?
[10:04] <tjaalton> it might get released next week, so when I get back things should be in good shape
[10:05] <tjaalton> regarding mesa & drm too
[10:05] <bryce> is there more I could do to prep the way for it?
[10:06] <bryce> Otherwise, I guess now that packaging is pretty much caught up, I'll go back to focusing on -ati bugs a while.
[10:09] <tjaalton> hmm, I think that the components are still in state of flux, so concentrating on bugwork for a week or two might pay off
[10:10] <tjaalton> btw, there's a new ati that probably should be merged/synced
[10:12] <tjaalton> "should be" meaning that it apparently fixes a ton of bugs
[10:13] <bryce> ok, I'll look at getting that merged in
[10:13] <bryce> I also really need to get my auto-git builder for -intel (and -ati) up and running
[10:13] <bryce> maybe I can finally get that going :-)
[10:13] <tjaalton> heh
[10:14] <tjaalton> hum, should be enough to sync -ati from experimental. we have no changes
[10:31] <tjaalton> Q-FUNK: 146_X86EMU-added-blacklist-for-I-O-port-in-0-0xFF-range.patch is not applied upstream and does not even apply on 1.5, so what should we do about it?
[10:31] <tjaalton> (xorg-server)
[10:32] <Q-FUNK> tjaalton: they eventually reverted the change and applied a more complex one to match GX2 and LX hardware specifically.
[10:33] <Q-FUNK> oh... wait.  blacklist
[10:33] <Q-FUNK> yes, they rejected blacklist.
[10:33] <Q-FUNK> http://www.x.org/wiki/AMDGeodeDriver
[10:33] <Q-FUNK> they accepted only 2 out of 3 patches
[10:36] <tjaalton> ok, so it can be dropped?
[10:37] <Q-FUNK> yes
[10:38] <tjaalton> cool
[11:21] <cody-somerville> Hey
[11:22] <cody-somerville> Can someone please help me with bug #232122 ?
[11:22] <cody-somerville> Or more specifically, bug #232364
[11:25] <cody-somerville> libxcb hangs waiting on the bilateral socket with X
[11:25] <cody-somerville> It only occurs intermittently though
[11:31] <tjaalton> cody-somerville: sounds hairy.. maybe ask the xcb devs?
[11:40] <cody-somerville> : (
[12:34] <tjaalton> joy, nvidia dropped support for GF5 from 177.xx
[12:52] <tseliot> ﻿tjaalton: Kano told me that there are *only* these flavours:
[12:52] <tseliot> ﻿VER_LEGACY_1=71.86.04
[12:52] <tseliot> # DX7 cards since gf2mx and all DX8 cards
[12:52] <tseliot> VER_LEGACY_2=96.43.05
[12:52] <tseliot> # GeForce 5 series
[12:52] <tseliot> VER_LEGACY_3=173.14.09
[12:52] <tseliot> and latest is 177.13 which supports the gtx 260/280
[13:10] <tseliot> tjaalton; I would like to package all the remaining flavours today. I will use our new package as a base rather than waiting for Debian to adopt the latest flavour too
[13:11] <tseliot> ﻿tjaalton; objections?
[14:36] <tjaalton> tseliot: no, go ahead
[14:38] <tseliot> tjaalton: ok, the new flavour will be nvidia-graphics-drivers-legacy-173xx
[14:38] <tseliot> (we can change this later)