On 08.10.2018 20:28, Marius Bakke wrote: > If reverting did not help, I doubt rebasing it away will do a > difference. It also sounds very tedious!
I stopped rebasing. It was too tedious. > Have you been able to find a commit that definitely works? Say, > 0dd91619a597b52bcb5d6d1bb675a9eb65242c44 (0.14)? Now that you have a I could verify that this commit also works. > 0dd91619a597b52bcb5d6d1bb675a9eb65242c44 (0.14)? Now that you have a > good test case, it should be easier to script the bisect (just make sure > to invoke "make clean && make" between runs to avoid ABI issues). But I have bisected already :) On 22.08.2018, Tim Gesthuizen wrote: > This bisect passed without a single skip. It reports that the bug was > first introduced by 5318b103ff277efbac248a066d162589a9083baa (which is > the first commit after a larger merge). Maybe you missed that mail. The problem is that reverting the commit does not solve the bug on the current master branch. So I am searching for a good way of finding another bug through bisecting. This would mean that I would need to apply a patch of some form to make sure that the libepoxy problem is fixed before running the bisect script again. This is why I tried to rebase the master branch to not include commits updating libepoxy. I hope my problem is more clear now. Maybe there is another way that is just too obvious and simple. If you don't have a good idea on how to do it, I will do the bisect again and do an input rewriting for the package I am building to use the old libepoxy and not the one of that revision. This will probably involve tons of package rebuilding so I am open for other approaches. Tim.
signature.asc
Description: OpenPGP digital signature