[12:59] <ubotu> New bug: #133560 in xserver-xorg-driver-via (main) "VIA Chrome 9 HC IGP Not Supported" [Undecided,New]  https://launchpad.net/bugs/133560
[01:44] <bryce> tepsipakki: I've posted a bunch to http://ubuntuforums.org/showthread.php?p=3224316
[06:19] <tepsipakki> bryce: yeah, makes perfect sense
[06:19] <tepsipakki> btw, X.org 7.4 is now scheduled for February 2008
[06:20] <kylem> i wouldn't worry too much about it
[06:21] <kylem> (phoronix etc.)
[06:24] <tepsipakki> me neither
[06:26] <tepsipakki> 1.3.99.0 is now in experimental, since pixman got past NEW.. I'll try it out sometime just for fun
[06:26] <tepsipakki> it also has the patches which make discover obsolete (for xorg)
=== kylem nods
[06:27] <tepsipakki> hey kylem, I've seen you hanging out on #d-x :)
[06:27] <kylem> it's moderately unfortunate ubuntu doesn't yet have something to compare to experimental
[06:27] <tepsipakki> yeah
[06:27] <kylem> :)
[06:29] <tepsipakki> bryce: have you tried compiling your xserver merge with current mesa?
[06:29] <tepsipakki> I remember there were issues with that in the past
[06:34] <bryce> tepsipakki: yeah I've been having some problems there
[06:35] <bryce> it works ok with dsfg-6*, but if I try building against dsfg-11, stuff breaks
[06:40] <tepsipakki> I wonder if it was due to our mesa
[06:41] <tepsipakki> do you have it somewhere so I can test?
[06:54] <bryce> unfortunately I just have it here locally
[06:55] <bryce> I recall jcristau mentioning some issues when he started looking at mesa 7.  Maybe there's some mesa patches we're missing?
[07:20] <bryce> you know, it's not a bad idea to set up a dev environment for us to share.  I think I'll plan on setting up a sandbox here on one of my machines
[07:20] <bryce> or else on one of the canonical machines if it seems better
[07:21] <bryce> kylem: yeah I'm accumulating enough experimental packages in my Testing dir, that it'd be nice to have a more structured way for people to pull and test against them
[07:21] <bryce> I thought maybe PPA would enable something like that, but it also feels a bit clumsy for that
[07:22] <kylem> indeed.
=== Starting logfile irclogs/ubuntu-x.log
=== ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog]  has joined #ubuntu-x
=== Topic for #ubuntu-x: Run /usr/share/bug/xserver-xorg-core/script
=== Topic (#ubuntu-x): set by bryce at Fri May 18 23:35:30 2007
[09:23] <jcristau> bryce: i didn't add any new patches on top of mesa 7.0.1 iirc
[09:23] <bryce> jcristau: ok.
[09:25] <bryce> I've narrowed the issues down a bit.  I took the current ubuntu xorg-server source and copied in all the debian/patch/'es (no other changes other than patches).  I can successfully build now if I disable patch 49_map_keyboard_driver_to_kbd.diff
[09:33] <bryce> 49_map_keyboard_driver_to_kbd.diff was giving a 'fail to patch' error.  Not sure yet why.
[09:33] <jcristau> weird
[09:40] <ubotu> New bug: #133799 in mesa (main) "intel945gm missing support for GL_POINT_SMOOTH and GL_POINT_SMOOTH" [Undecided,New]  https://launchpad.net/bugs/133799
[09:47] <tepsipakki> bryce: could you build a source-package out of it so I could take a look?
[09:47] <bryce> probably my own damn fault I'm sure
[09:47] <tepsipakki> :)
[09:47] <bryce> yup, I've confirmed it's that one patch that's causing the patching failure
[09:48] <bryce> but what's odd is I manually applied the patches in sequence, and patch 49 applied cleanly 
[09:49] <bryce> unfortunately 49_map_keyboard_driver_to_kbd.diff is one of the primary patches I want
[09:50] <bryce> tepsipakki: yeah hang on
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-x
[09:55] <tepsipakki> bryce: I can try merging it here starting from a clean tree, and compare the results
[09:55] <bryce> tepsipakki: ok
[09:56] <bryce> tepsipakki: I'm uploading, should be done shortly
[09:58] <bryce> tepsipakki: http://people.ubuntu.com/~bryce/Testing/xorg-server/
[09:58] <tepsipakki> oh, I thought you were trying to merge with -12
[09:59] <bryce> tepsipakki: actually I am
[10:00] <bryce> tepsipakki: the approach I've taken is to copy in all the patches from -11's debian/patches/ and get them building, in isolation from any other debian/* changes
[10:00] <bryce> so far it builds if I leave out patch 49
[10:01] <bryce> next I'll look at the changes outside debian/patches/.
[10:02] <bryce> the error message I get with patch 49 isn't too helpful:
[10:02] <bryce> 001_ubuntu_add_extra_modelines_from_xorg.patch
[10:02] <bryce> Applying patches...failed! (check stampdir/log/patch for details)
[10:02] <bryce> make: *** [stampdir/patch]  Error 1
[10:02] <bryce> pbuilder: Failed autobuilding of package
[10:02] <bryce> ...
[10:02] <tepsipakki> try debuild, then you can see the log
[10:03] <jcristau> if you take the changes from debian/xsfbs/ it should now cat stampdir/log/patch
[10:03] <tepsipakki> ah
[10:18] <tepsipakki> hmm, could the xvfb Depends: xfonts-base be put as Recommends as it's in Debian (making the diff smaller). Recommends are installed anyway
[10:19] <tepsipakki> also, packages which provide xserver-xorg-video should probably be changed to provide the ABI version of the server they are supposed to be used with
[10:19] <seb128> tepsipakki: when are Recommends installed?
[10:19] <jcristau> they're not installed on buildds, and some packages use xvfb-run at build time
[10:20] <jcristau> and some might (incorrectly) not build-dep on xfonts-base
[10:20] <tepsipakki> hmm, ok I'll leave it then ;)
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-x
=== tehk [n=tehk@c-69-249-157-157.hsd1.nj.comcast.net]  has joined #ubuntu-x
=== mvo [n=egon@p54A67654.dip.t-dialin.net]  has joined #ubuntu-x
[11:14] <ubotu> New bug: #133457 in xorg (main) "[gutsy]  alternate install monitor frequency too high" [Undecided,New]  https://launchpad.net/bugs/133457
[11:32] <tepsipakki> bryce: I've completed the merge, and patch 49 succeeded, but 106 didn't :)
[11:33] <tepsipakki> jcristau: should the xsfbs-changes be in -12?
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-x
[11:40] <tepsipakki> jcristau: nevermind.. it did show the log afterall :)
[11:43] <tepsipakki> uh, something has happened to patch 106.. it used to be readable :)
[11:46] <tepsipakki> there, patches applied fine, some offsets but that's cosmetic
[11:48] <tepsipakki> now trying to build
[11:50] <tepsipakki> Creating destination directories for mesa module ...  error:   Source directory /usr/share/mesa-source/src/mesa/array_cache does not exist
[11:50] <tepsipakki> configure: error: Failed to link Mesa source tree.  Please specify a proper path to Mesa sources, or disable GLX.
[11:51] <jcristau> all references to array_cache should go away
[11:51] <tepsipakki> right.. I disabled patch 127.. need to bring it back
[11:52] <tepsipakki> what about 125/126, safe for mesa7?
[11:52] <tepsipakki> meant for building with 6.5.3
[11:53] <jcristau> yeah, no change to 12[5-7] 
[11:53] <jcristau> i think i just took them from your package
[11:53] <tepsipakki> seems to be so :)
[11:56] <tepsipakki> fedora has added a new patch to their composite hacks..
[11:56] <tepsipakki>  xserver-1.3.0-no-pseudocolor-composite.patch: Refuse to initialize
[11:56] <tepsipakki>   Composite when Render is missing or when the root window is using
[11:56] <tepsipakki>   a pseudocolor visual. (#217388)
[12:02] <tepsipakki> now it seems to build
=== tehk [n=tehk@c-69-249-157-157.hsd1.nj.comcast.net]  has joined #ubuntu-x
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-x
[12:08] <tepsipakki> and finished
[12:11] <tepsipakki> and works
[12:21] <mvo> aha, lots of X hackers here :) does anyone can think of a way to detect when a window is using glx? 
[12:24] <tepsipakki> mvo: lots of noise maybe ;) (sorry, can't think of a way)
[12:25] <mvo> heh :) 
[12:26] <kylem> mvo, what are you trying to do?
[12:27] <tehk> Run it with compiz in gutsy on a nvidia gpu. It will crash and let you know! Just joking. I really do not know.
[12:28] <mvo> kylem: if we turn on compiz-by-default we will have issues with windowed 3d. I want to find a way to detect non-fullscreen glx apps and issue a warning 
[12:29] <mvo> possible even try to workaround some issues
[12:29] <mvo> but a warning would be a good start
[12:36] <ubotu> New bug: #132983 in xserver-xorg-video-ati (main) "video playback is not fluent" [Medium,New]  https://launchpad.net/bugs/132983
[02:00] <ubotu> New bug: #133830 in xorg (main) "1680x1050 not recognized on xubuntu 7.10 tribe4" [Undecided,New]  https://launchpad.net/bugs/133830
[02:16] <ubotu> New bug: #133831 in xserver-xorg-input-synaptics (main) "[Gutsy]  after resume synaptics touchpad goes haywire." [Undecided,New]  https://launchpad.net/bugs/133831
[03:37] <tepsipakki> rock; Build Operating System: Linux Debian (xorg-server 2:1.3.99.0-2ubuntu1)
[03:37] <tepsipakki> oops, didn't change the vendor string
[03:41] <tepsipakki> yeah, G965 works without Device-section
=== tehk [n=tehk@c-69-249-157-157.hsd1.nj.comcast.net]  has joined #ubuntu-x
[05:45] <ubotu> New bug: #133864 in xorg-server (main) "Upgrading from drapper: xserver failes (XGI)" [Undecided,New]  https://launchpad.net/bugs/133864
[05:58] <bryce> tepsipakki: https://bugs.launchpad.net/ubuntu/+bug/126255 - what we were talking about
[05:58] <ubotu> Launchpad bug 126255 in xserver-xgl "FTBFS" [Undecided,Confirmed]  
=== tehk [n=tehk@c-69-249-157-157.hsd1.nj.comcast.net]  has joined #ubuntu-x
[08:26] <tepsipakki> bryce: that's xserver-xgl..
[08:27] <tepsipakki> bryce: I did manage to merge xorg-server though.. and also am testing 1.3.99.0 on couple of machines, a candidate for PPA when it's opened
[08:28] <bryce> I've also made progress with my xorg-server merge - I think the issue I ran into earlier may have been due to a mesa version issue
[08:29] <tepsipakki> my debdiff is here: http://users.tkk.fi/~tjaalton/dpkg/xorg/xorg-server.debdiff
[08:29] <tepsipakki> nothing special there
[08:29] <tepsipakki> patch 106 was broken though
[08:30] <tepsipakki> it was maybe rediffed against a configured tree
[08:36] <bryce> I've wondered if we should drop the -fno-stack-protector
[08:36] <bryce> btw, did you do the merge manually or using MoM?
[08:36] <bryce> yeah I also noticed patch 106 was busted
[08:37] <tepsipakki> manually
[08:37] <bryce> ahhh
[08:37] <tepsipakki> always do
[08:37] <bryce> I think grab-merge fscked things up for me
[08:37] <tepsipakki> only the changelog is something to take from the MoM-generated tree
[08:37] <tepsipakki> grab-merge is handy for fetching the packages too
[08:37] <bryce> btw, I suspect most of the auto* stuff in patch 106 could/should be dropped, as it doesn't seem relevant to the patch
[08:38] <tepsipakki> but otherwise I've done things manually, and then compared the debdiffs etc
=== bryce nods
[08:38] <bryce> grab-merge seems to have worked ok for me on the smaller packages
[08:38] <tepsipakki> 106 only needs the -fPIC lines.. two hunks :)
[08:38] <bryce> yup
[08:39] <tepsipakki> you can see it in the debdiff above
[08:40] <bryce> ah yeah that's a lot nicer
[08:41] <bryce> the only other change I was thinking about is I notice the Build-Depends list libgl1-mesa-dev 6.5.1, and wondered if it should be 6.5.3?
[08:43] <bryce> tepsipakki: since I don't have anything to add beyond what you've done, do you want to put this in for an upload, or would you like me to?
[08:48] <tepsipakki> I can do it :)
[08:48] <bryce> awesome, thank you :-)
[08:48] <tepsipakki> the mesa-dep should be fine I think.. a sec
[08:50] <bryce> also, I've been wondering how best to handle backporting fixes from 1.3.99/1.4.  Do you have thoughts on that?  Would it be worthwhile to go through the changelog and flag fixes we want, or wait until the bug is reported and then search for the fix, or...?
[08:51] <tepsipakki> push them to the right PPA? :)
[08:51] <tepsipakki> just kidding
[08:52] <tepsipakki> I guess they need to be pulled carefully, since some changes need others etc.. it could be an bottomless swamp
[08:53] <tepsipakki> -n
[08:53] <bryce> yeah
[08:57] <tepsipakki> hmm, I'll test without ssp on my ati
[08:58] <tepsipakki> the libgl1-mesa-dev build-dep version is not that important IMO, since mesa-swx11-source build-dep is already versioned
[08:59] <bryce> ok
[09:00] <tepsipakki> and if someone has managed to install mixed versions it's his fault :)
[09:03] <tepsipakki> jcristau: should the libgl1-mesa-dev build-dep version match mesa-swx11-source?
[09:03] <jcristau> tepsipakki: not necessarily, i think
[09:04] <tepsipakki> that's what I thought, since they should match each other anyway..
[09:06] <tepsipakki> bryce: note that patch 108 was not applied for quite some time, so I dropped it from the diff and changelog. Fedora has dropped it as well
[09:06] <bryce> ok
[09:06] <tepsipakki> it's their crack, after all
[09:07] <jcristau> the versioned dep on -source is because the symlinking script and Makefile.am have to be in sync with the mesa source layout
[09:09] <tepsipakki> jcristau: maybe the version from libgl1-mesa-dev could be dropped, no?
[09:30] <jcristau> 6.5.1 is in stable, so that's fine by me
[09:34] <tepsipakki> ah
[09:35] <tepsipakki> fairly cosmetic though
=== alex-weej [n=alex@cpc2-darl3-0-0-cust237.midd.cable.ntl.com]  has joined #ubuntu-x
[09:47] <bryce> heya alex-weej
[09:47] <alex-weej> hi bryce
[09:47] <alex-weej> my resolution-independence plan kinda hit a wall
[09:48] <bryce> oh?
[09:48] <alex-weej> i spoke with Benjamin Berg, upstream gtk engines maintainer, apparently there are a lot of places internally where we'd need to round to integers
[09:48] <alex-weej> which means big huge steps as you scale up or down
[09:48] <bryce> ah
[09:48] <alex-weej> but that's not why i'm here
[09:48] <bryce> what did they suggest?
[09:48] <alex-weej> you can probably help me bryce :)
[09:49] <bryce> hope so :-)
[09:49] <alex-weej> http://rafb.net/p/p58Rw657.html
[09:50] <alex-weej> from ubuntu-devel, couldn't be bothered to type it all out again :P
[09:50] <bryce> heh
[09:50] <bryce> yeah, displayconfig-gtk does not play well with lrm stuff yet
[09:50] <bryce> I'd posted a bug already about how you can't select binary drivers
[09:51] <bryce> can you also enter a bug against it about this issue too?
[09:51] <alex-weej> sure, is it definitely a problem (i haven't actually tested it, i just assumed nothing had changed)
[09:52] <bryce> it might be worthwhile to test displayconfig-gtk from bzr; iirc there's been work on it since what's available in gutsy
[09:53] <alex-weej> bzr :O i've never used it
[09:57] <bryce> alex, it's much like svn or git
[09:57] <bryce> standby
[09:59] <bryce> bzr co http://bazaar.launchpad.net/~displayconfig-gtk/displayconfig-gtk/ubuntu
[10:00] <bryce> then bzr diff to get a diff of any changes you make
[10:05] <tepsipakki> running xserver on ati without specifying no-stack-protector in debian/rules
[10:05] <tepsipakki> so far so good
[10:16] <bryce> tepsipakki, I've just finished reading through the 1.3.99 changelog, and have flagged some of the changes that sound worth investigating:  https://wiki.ubuntu.com/X/Fixes_to_Backport
[10:25] <tepsipakki> that's one hell of a list :)
[10:26] <bryce> yup
[10:26] <bryce> but the number of items of interest is not too huge
[10:27] <bryce> I'm going to write a script to try to identify the commit id's for them from xserver git log
[10:27] <tepsipakki> yes, looks good