xorg-server-devel 1.17 displays in false colours on PPC Tiger and Leopard (Mac OS X 10.4.11/10.5.8)

[ballapete (Peter "Pete" Dyballa)]

The effect is demonstrated by the two attached screenshots from running xorg-server-devel @1.16.99.1_2 resp. xorg-server-devel @1.17.1_0. I think on Leopard the font rendering is OK, but I'll check that later.

[ballapete (Peter "Pete" Dyballa)]

OK from xorg-server-devel 1.16.99.1_2

[ballapete (Peter "Pete" Dyballa)]

Not OK from xorg-server-devel 1.17.1_0

[ryandesign (Ryan Carsten Schmidt)]

Cc Me!

[ballapete (Peter "Pete" Dyballa)]

Not OK from xorg-server-devel 1.16.99.1_3 on Leopard

[ballapete (Peter "Pete" Dyballa)]

Not OK from xorg-server-devel 1.17_0 on Leopard

[ballapete (Peter "Pete" Dyballa)]

Not OK from xorg-server-devel 1.17.1_0 on Leopard

[ballapete (Peter "Pete" Dyballa)]

OK from xorg-server-devel 1.16.99.1_2 on Leopard

[ballapete (Peter "Pete" Dyballa)]

On PPC Leopard (Mac OS X 10.5.8) no cursor is visible. Besides this a few X clients crash. The packages installed on Leopard are:

  xorg-server-devel @1.16.99.1_2 (active)
  xorg-server-devel @1.16.99.1_3
  xorg-server-devel @1.17.0_0
  xorg-server-devel @1.17.1_0

All but the first one are not OK.

[ryandesign (Ryan Carsten Schmidt)]

Oh! So the problem occurred between 1.16.99.1_2 (which was ​cff12936275db2f71f6d24f9ea0985a0d14af454 (2014-07-19)) and 1.16.99.1_3 (which was ​e572bcc7f4236b7e0f23ab762f225b3bce37db59 (2014-10-27)). There were almost 400 commits in that range. We could ​bisect to find the culprit commit.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yes. Peter, I don't see any new information here beyond what you reported to xquartz-dev back in February. Have you determined what caused the regression?

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

Yes. Peter, I don't see any new information here beyond what you reported to xquartz-dev back in February. Have you determined what caused the regression?

No. I started to compile xorg-server-devel from some commit,

git clone ssh://git.freedesktop.org/git/xorg/xserver.git
cd xserver
git bisect start

which went fine, but I don't now how to install and make it launch to see whether the colours are correct. I am just waiting for a recipe…

[ryandesign (Ryan Carsten Schmidt)]

Well before you can install and launch it, you have to configure and compile it, like MacPorts would, except that MacPorts is not integrated with git bisect so you either have to manually reproduce the configuration and build procedure that MacPorts does, each time through the git bisect process, or you have to use the commit hashes git bisect tells you to modify the portfile to use that hash, then use MacPorts to rebuild the port.

[jeremyhu (Jeremy Huddleston Sequoia)]

As I mentioned on the list, you can use the bisection to just determine which commit hash to use and then use that commit hash when rebuilding xorg-server (either 1.16.99.1_2 or 1.16.99.1_3 depending on which set of patches applies cleanly) rather than building it out of the tree, but either way will work.

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign@…:

Well before you can install and launch it, you have to configure and compile it, like MacPorts would,

This is quite clear. And if I can't find out how port would do this job, I can simply force port to start again and copy&paste environment settings, the configure invocation, and then start to make the same target.

or you have to use the commit hashes git bisect tells you to modify the portfile to use that hash, then use MacPorts to rebuild the port.

I have no idea what to do with a "hash"… except maybe in Perl! But this "modify the portfile" sounds very interesting. This would allow me to just invoke port install xorg-server-devel over and over again, after each launch of the X server and decision to classify the build as good or bad. How does this actually work? Is there some log of such a session available?

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

As I mentioned on the list, you can use the bisection to just determine which commit hash to use and then use that commit hash when rebuilding xorg-server

I don't think I've seen a "commit hash" and how to determine that some text output or some part of a text output is such a "commit hash". And therefore I don't know how to continue. You could try to re-write your explanation in Japanese or in cuneiform, and I wouldn't be able to understand much more…

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to Peter_Dyballa@…:

Replying to ryandesign@…:

Well before you can install and launch it, you have to configure and compile it, like MacPorts would,

This is quite clear. And if I can't find out how port would do this job, I can simply force port to start again and copy&paste environment settings, the configure invocation, and then start to make the same target.

or you have to use the commit hashes git bisect tells you to modify the portfile to use that hash, then use MacPorts to rebuild the port.

I have no idea what to do with a "hash"… except maybe in Perl! But this "modify the portfile" sounds very interesting. This would allow me to just invoke port install xorg-server-devel over and over again, after each launch of the X server and decision to classify the build as good or bad. How does this actually work? Is there some log of such a session available?

See my discussion about how do do this in ​https://lists.macosforge.org/pipermail/xquartz-dev/2015-March/003866.html which includes the commands you would need to invoke. In that example, the commit has is 35dc7c75150733dbcef8a18b6796f49a7c48ebee and you would set it on the git.branch line in the Portfile.

From the email:

git clone ssh://git.freedesktop.org/git/xorg/xserver.git
cd xserver
git bisect start
git bisect bad e572bcc7f4236b7e0f23ab762f225b3bce37db59
git bisect good cff12936275db2f71f6d24f9ea0985a0d14af454

It will then report something like this:

Bisecting: 169 revisions left to test after this (roughly 8 steps)
[35dc7c75150733dbcef8a18b6796f49a7c48ebee] Merge branch 'modesetting-import' into master

Hope fully the above is clear

So try 35dc7c75150733dbcef8a18b6796f49a7c48ebee and then run 'git bisect good' or 'git bisect bad' as appropriate and try the next one until you've determined what commit introduced the problem.

I assume this is what you don't understand.

Starting with a checkout of 1.16.99.1_2 or 1.16.99.1_3 (try one; if patches don't apply, try the other one), edit the Portfile and change the git.branch line to 35dc7c75150733dbcef8a18b6796f49a7c48ebee. Then build and install the port:

sudo port -v -s -n upgrade --force xorg-server-devel

Depending on if it works or not, run 'git bisect good' or 'git bisect bad' in your git checkout to get the next commit hash to try. If there are *other* errors that prevent you from testing that version (eg: build failures you don't know how to fix or crashes that happen before you get to test), use 'git bisect skip' to mark that hash as unknown.

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

From the email:

git clone ssh://git.freedesktop.org/git/xorg/xserver.git
cd xserver
git bisect start
git bisect bad e572bcc7f4236b7e0f23ab762f225b3bce37db59
git bisect good cff12936275db2f71f6d24f9ea0985a0d14af454

I started to work again on the problem but have no right to do so. The git step ends with:

debug1: Host 'git.freedesktop.org' is known and matches the RSA host key.
debug1: Found key in /Users/pete/.ssh/known_hosts:11
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/pete/.ssh/identity
debug1: Offering public key: /Users/pete/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/pete/.ssh/id_dsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
fatal: Could not read from remote repository.

[jeremyhu (Jeremy Huddleston Sequoia)]

Then use ​git://people.freedesktop.org/~jeremyhu/xserver

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

Then use ​git://people.freedesktop.org/~jeremyhu/xserver

This went fine! Before I'm going to configure I would like to know If I have to apply these patches too that were applied when xorg-server-devel-1.16.99.1 was built:

--->  Applying 5000-sdksyms.sh-Use-CPPFLAGS-not-CFLAGS.patch
--->  Applying 5001-Workaround-the-GC-clipping-problem-in-miPaintWindow-.patch
--->  Applying 5002-Use-old-miTrapezoids-and-miTriangles-routines.patch
--->  Applying 5003-fb-Revert-fb-changes-that-broke-XQuartz.patch
--->  Applying 5004-fb-Revert-fb-changes-that-broke-XQuartz.patch

And in which sequence. Port actually performed a /opt/local/bin/git checkout -q e572bcc7f4236b7e0f23ab762f225b3bce37db59 and then started to patch files. So when can I

git bisect start

and state

git bisect bad e572bcc7f4236b7e0f23ab762f225b3bce37db59

?

[jeremyhu (Jeremy Huddleston Sequoia)]

yes, you should apply some version of those patches, but you will need to deal with conflicts (likely by having a few different sets of patches available for different eras)

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

yes, you should apply some version of those patches, but you will need to deal with conflicts (likely by having a few different sets of patches available for different eras)

Since git presumingly works by applying patches it's probably best to remove the manually applied patches before I tell it to bisect, right? (And afterwards apply them again. Until the whole breaks due to conflicts…)

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

yes, you should apply some version of those patches, but you will need to deal with conflicts (likely by having a few different sets of patches available for different eras)

The first patch in xorg-server-devel/files/5002-Use-old-miTrapezoids-and-miTriangles-routines.patch seems to be obsolete:

Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git server-1.16-branch/fb/fbpict.c server-1.16-branch/fb/fbpict.c
|index e7a3811..276ff06 100644
|--- server-1.16-branch/fb/fbpict.c
|+++ server-1.16-branch/fb/fbpict.c
--------------------------
checking file fb/fbpict.c
Using Plan A...
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] 
Skipping patch.

[jeremyhu (Jeremy Huddleston Sequoia)]

Like I said, you would need to use your judgement as to what to apply. There are many different versions of those patches as they have been rebased on evolving master.

You should be able to use the ones that are available in MacPorts at different times. Checkout different revisions, stash them somewhere, and try the appropriate set for the appropriate era that your bisect point is in.

[ballapete (Peter "Pete" Dyballa)]

Replying to Peter_Dyballa@…:

The first patch in xorg-server-devel/files/5002-Use-old-miTrapezoids-and-miTriangles-routines.patch seems to be obsolete:

I think I understand now a bit better how git works. What I cloned is some future set of sources. So at least one of the patches is already incorporated. By invoking

git bisect start
git bisect bad e572bcc7f4236b7e0f23ab762f225b3bce37db59
git bisect good cff12936275db2f71f6d24f9ea0985a0d14af454

I mark this up-to-date version bad and return to a set one change (set) ahead of the last known good one, so that I can start to work on bisecting.

It's not satisfying that patches for the same file are contained in more than one patch file. This turns saving backup files with patch as useless.

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

Starting with a checkout of 1.16.99.1_2 or 1.16.99.1_3 (try one; if patches don't apply, try the other one), edit the Portfile and change the git.branch line to 35dc7c75150733dbcef8a18b6796f49a7c48ebee.

Trying port to build the X server fails because it seems that it can't change to the mentioned set. The build fails early because it can't patch source files.

The Portfile in use has

  3 PortSystem 1.0
  4 
  5 name            xorg-server-devel
  6 conflicts       xorg-server
  7 set my_name     xorg-server
  8 version         1.17.1
  […]
 18 git.url         git://anongit.freedesktop.org/xorg/xserver
 19 git.branch      35dc7c75150733dbcef8a18b6796f49a7c48ebee

[ballapete (Peter "Pete" Dyballa)]

main.log from trying to build git.branch 35dc7c75150733dbcef8a18b6796f49a7c48ebee

[ballapete (Peter "Pete" Dyballa)]

Replying to Peter_Dyballa@…:

Replying to jeremyhu@…:

Starting with a checkout of 1.16.99.1_2 or 1.16.99.1_3

I don't know what I actually cloned or checked out, but set #35dc7c75150733dbcef8a18b6796f49a7c48ebee produces, when manually configured, compiled, and installed the reported error.

I can attach the logs from the build process and also logs from crashes of fluxbox, gkrellm, or GNU Emacs 23.4.

[ballapete (Peter "Pete" Dyballa)]

Performing a git bisect bad I get errors:

Bisecting: 112 revisions left to test after this (roughly 7 steps)
error: Your local changes to the following files would be overwritten by checkout:
	fb/fb.h
	fb/fbpict.c
	fb/fbpict.h
	fb/fbscreen.c
	hw/xfree86/Makefile.am
	mi/miexpose.c
	render/mipict.c
	render/mipict.h
Please, commit your changes or stash them before you can switch branches.
Aborting

although I 'undid' any changes to these patched files by copying over the original un-patched versions. And when I try to handle a newly cloned set with

git bisect start
git bisect bad e572bcc7f4236b7e0f23ab762f225b3bce37db59
git bisect good cff12936275db2f71f6d24f9ea0985a0d14af454
git bisect bad

all files except the hw/xfree86/drivers/modesetting/ are removed…

[ballapete (Peter "Pete" Dyballa)]

Replying to Peter_Dyballa@…:

Performing a git bisect bad I get errors:

Bisecting: 112 revisions left to test after this (roughly 7 steps)
error: Your local changes to the following files would be overwritten by checkout:
	fb/fb.h
	fb/fbpict.c
	fb/fbpict.h
	fb/fbscreen.c
	hw/xfree86/Makefile.am
	mi/miexpose.c
	render/mipict.c
	render/mipict.h
Please, commit your changes or stash them before you can switch branches.
Aborting

Is there a way to "stash" these files and continue to work on the bug?

[ballapete (Peter "Pete" Dyballa)]

XQuartz 2.7.7 (xorg-server 1.17.2) from xorg-server-devel @1.17.2_0 (active) shows correct colours on PPC Tiger, Mac OS X 10.4.11.

[ballapete (Peter "Pete" Dyballa)]

XQuartz 2.7.7 (xorg-server 1.17.2) from xorg-server @1.17.2_0 (active) on PowerPC Leopard, Mac OS X 10.5.8, displays colours OK.

[jeremyhu (Jeremy Huddleston Sequoia)]

so this is fixed then?

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

so this is fixed then?

Yes, it is!