On Mon, Feb 12, 2024 at 7:49 AM Julian Sikorski <belegdol@xxxxxxxxx> wrote: > > Am 12.02.24 um 10:03 schrieb Michael J Gruber: > > Am So., 11. Feb. 2024 um 23:14 Uhr schrieb Julian Sikorski <belegdol@xxxxxxxxx>: > >> > >> Hello, > >> > >> I am trying to bisect an issue which appears to have regressed between > >> 5.18 final and 5.19-rc2. This is somewhat challenging as most of the > >> kernels are since gone from koji, and the ark os-build branch seems to > >> have been rebased after kernel 6.7 release, meaning that the required > >> commits to the redhat folder are not in sync with the commits to the > >> kernel itself. > > > > I'm not sure I'm following this completely - are you saying that (part > > of) the old kernel sources are not there (in git) any more because a > > branch got rebased? > > Well the commits are there in the os-build branch, but they got rebased > on top of 6.7. This means that they are no longer in sync with upstream > kernel commits from the 5.19-rc0 timeframe. > In the meantime I was able to learn that the correct order is still > present in the tags: > > $ git bisect good kernel-5.19.0-0.rc0.fdaf9a5840ac.1 > $ git bisect bad kernel-5.19.0-0.rc0.babf0bb978e3.3 > > I was able to recreate an "os-build-5.19" branch and am finally building > a kernel now. > > > > >> I tried cherry-picking them on top, but it does not apply > >> cleanly either: > >> > >> $ git clone -b os-build git@xxxxxxxxxx:cki-project/kernel-ark.git > >> $ git bisect start > >> $ git bisect bad v5.19-rc2 > >> $ git bisect good v5.18 > >> $ git checkout 2518f226c60d8e04d18ba4295500a5b0b8ac7659 > >> $ git cherry-pick > >> 0dd3ee31125508cd67f7e7172247f05b7fd1753a..6d8a7e484dc667c1094fc90452dee6af30d509f6 > >> > >> Is there a way simpler than trying to fix the cherry-pick conflicts > >> every single time? > > > > `rerere` can be really helpful for something like this. > > > I will have a look if I get stuck again, thanks! > > > I guess you've checked already whether the problem you're trying to > > solve depends on the extra redhat commits. > > I don't think so, there are redhat kernels which both do and do not work. > We do rebase the os-build branch, but I would strongly recommend doing a bisect on Linus' tree (master in kernel-ark) just using the 5.19 config. Doing bisects as rpms are massively time consuming and not worth the effort. If it were a redhat specific patch, you would know that quickly because 5.19-rc2 from Linus' tree would be good instead of bad. In this case, we rarely carry to many patches in any area, you could literally eyeball it and see which patch that we carry is causing the issue. Justin -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
