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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
