Bug#524280: Display broken beyond recognition after upgrade to 1:6.12.2-1

[Jacek Politowski <jp@jp.pl.eu.org>]

On Tue, Apr 21, 2009 at 11:09:41AM -0400, Alex Deucher wrote:

>Any chance you could try 6.10.0 from the tarballs above and then use
>git bisect to track down what commit broke this?
>It's easy to do and would be a big help.  I can walk you through if need be.

Finally I was able to do some testing with git bisect.

What I managed to find out:

Last working commit is: 
a6561f2ec673b38907f7181235386f32e60c32ba

First commit with corrupted display:
da021c36bbdf3bca31ee50ebe01cdb9495c09b36


I believe all 46 commits between them fail to build from source on my
VirtualBox builder.


All done with simple procedure:
$ git bisect start 'a0dd5d7ee3f038a9bfe051db8dbfac4934a81581' 'c83fbdfa076c107012b7dfbbfbbb2feede00542b'
$ ./autogen.sh --prefix=/usr
$ make
## copy .libs/*so to proper locations on my system with Radeon card
## (except for ati_drv.so - this one was left unchanged all the time)
$ sudo reboot
$ git bisect good/bad
$ ./autogen.sh --prefix=/usr
$ make
... and so on (without any 'make clean' or anything else)


Going upwards, from working to buggy revision, I treated FTBFS
(failing to build from source) commits as "bad" for git bisect. Going
from buggy revision downwards - to working one - I treated FTBFS
commits as "good" for git bisect.


I believe the same error was causing build failures all the time (and
it's also quite late here already), so I haven't checked all the
revisions between working and buggy commit - only those few, that
binary search of git bisect stumbled upon.

If necessary, I can try building revisions between
a6561f2ec673b38907f7181235386f32e60c32ba and
da021c36bbdf3bca31ee50ebe01cdb9495c09b36 on next possible occasion.


-- 
Jacek Politowski