Tim Gesthuizen <tim.gesthui...@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").
signature.asc
Description: PGP signature
