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.