On 21.12.22 16:39, Masahiro Yamada wrote: > On Wed, Dec 21, 2022 at 5:23 PM Thorsten Leemhuis > <regressions@xxxxxxxxxxxxx> wrote: >> >> Hi, this is your Linux kernel regression tracker. CCing the regression >> mailing list, as it should be in the loop for all regressions: >> https://docs.kernel.org/admin-guide/reporting-regressions.html >> >> On 18.12.22 21:51, Dennis Gilmore wrote: >>> The changes in https://lore.kernel.org/linux-arm-kernel/166783716442.32724.935158280857906499.b4-ty@xxxxxxxxxx/T/ >>> result in vmlinux no longer having a build-id. >> >> FWIW, that's 994b7ac1697b ("arm64: remove special treatment for the link >> order of head.o") from Masahiro merged through Will this cycle. >> >>> At the least, this >>> causes rpm builds to fail. Reverting the patch does bring back a >>> build-id, but there may be a different way to fix the regression >> >> Makes me wonder if other distros or CIs relying on the build-id are >> broken, too. >> >> Anyway, the holiday season is upon us, hence I also wonder if it would >> be best to revert above change quickly and leave further debugging for 2023. >> >> Masahiro, Will, what's your option on this? Masahiro, many thx for looking into this. > I do not understand why you rush into the revert so quickly. > We are before -rc1. > We have 7 weeks before the 6.2 release > (assuming we will have up to -rc7). > > If we get -rc6 or -rc7 and we still do not > solve the issue, we should consider reverting it. Because it looked like a regression that makes it harder for people and CI systems to build and test mainline. To quote Documentation/process/handling-regressions.rst ( https://docs.kernel.org/process/handling-regressions.html ): """ * Fix regressions within two or three days, if they are critical for some reason – for example, if the issue is likely to affect many users of the kernel series in question on all or certain architectures. Note, this includes mainline, as issues like compile errors otherwise might prevent many testers or continuous integration systems from testing the series. """ I suspect that other distros rely on the build-id as well. Maybe I'm wrong with that, but even if only Fedora and derivatives are effected it will annoy some people. Sure, each can apply the revert, but before that everyone affected will spend time debugging the issue first. A quick revert in mainline (with a reapply later together with a fix) thus IMHO is the most efficient approach afaics. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight.
