Tim Gesthuizen <tim.gesthuizen@yahoo.de> writes:

> 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.

Oh, I see!  Sorry for the confusion.

One thing you can try to narrow down the search space is to try
reverting that commit at different points in the repository.

For example, I believe 5318b103f was merged in 49b6dc2b4.  If reverting
on top of 49b6dc2b4 does not work, it means the (other) problem was
introduced somewhere between 5318b103f^..49b6dc2b4.

For starters, can you try to revert 49b6dc2b4 on top of 0d6f84aab and
e0c9aed82?  My gut feeling says the first should work and the second
not :-)

> 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.

Input rewriting seems like a great workaround, however tedious.  It
would be good to provide better tooling for these kinds of cases (maybe
even "guix bisect").