On Tue, May 12, 2020 at 10:01 AM Justin Forbes <jmforbes@xxxxxxxxxxx> wrote: > > On Tue, May 12, 2020 at 8:58 AM Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote: > > > > Am 12.05.20 um 14:45 schrieb Justin Forbes: > > > On Tue, May 12, 2020 at 1:50 AM Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote: > > >> Am 11.05.20 um 20:20 schrieb Don Zickus: > > >>> On Mon, May 11, 2020 at 09:52:43AM -0700, stan wrote: > > >>>> On Mon, 11 May 2020 09:44:54 -0700 > > >>>> stan <upaitag@xxxxxxxx> wrote: > > >>>> arch/x86/kernel/setup.c:820:13: warning: 'rh_check_supported' defined but not used [-Wunused-function] > > >>>> 820 | static void rh_check_supported(void) > > >>>> | ^~~~~~~~~~~~~~~~~~ > > >>> Odd, the ELN build didn't fail for that reason. > > >>> In theory, an ELN build should have failed, someone noticed it was related > > >>> to a specific RH patch, we revert it temporarily until it is fixed and then > > >>> re-apply. Still some kinks. > > >> While at it: I noticed the number of patches that are applied to the > > >> kernel sources went up from nearly 40 to about 75 with the kernel-ark > > >> transition. Among those 35 additional patches are afaics quite a few > > >> that are really specific to RHEL (like the one that caused this) and not > > >> needed for Fedora apart from the ELN. The one that caused this afaics is > > >> one of them. > > >> Is that intentional or just something that will get cleaned up? > > > > > > Actually, the number of patches has not changed so much as the number > > > of files containing those patches has. […] > > > Breaking them out individually also makes it much easier when say 1 > > > patch from a series got pulled in, or needs to be rebased. > > > > Okay, yeah, that's true, thx for clarifying. I just reacted to patches > > like these (and some others that depend on it or are related): > > > > https://src.fedoraproject.org/rpms/kernel/blob/master/f/0001-Add-Red-Hat-tainting.patch > > https://src.fedoraproject.org/rpms/kernel/blob/master/f/0001-add-Red-Hat-specific-taint-flags.patch > > https://src.fedoraproject.org/rpms/kernel/blob/master/f/0001-kernel-add-SUPPORT_REMOVED-kernel-taint.patch > > https://src.fedoraproject.org/rpms/kernel/blob/master/f/0001-rh_kabi-introduce-RH_KABI_EXCLUDE.patch > > https://src.fedoraproject.org/rpms/kernel/blob/master/f/0001-redhat-rh_kabi-introduce-RH_KABI_EXTEND_WITH_SIZE.patch > > > > Most of them look a bit pointless to me, as they from a quick look > > shouldn't have any effect on the Fedora (non-ELN!) kernel. That why my > > head came up with "so why add them in the first place then" and "that > > violates the patch guidelines for Fedora, which were developed for a > > reasons"? > > > > But whatever, I can see how it helps making lives easier for RH > > developers. I don't really like that, but I can live with that. > > > > CU, knurd > > I would say the KABI patches really don't matter at all for Fedora, > and there is not really any particular reason to exclude them. The > taint patches could send the wrong message, though in all honesty, it > just means we have to watch it on bug reports. By policy, tainted bug > reports are basically ignored, but these are not. As these use > different taint flags, that is not difficult to do, but perhaps I can > come up with a way to only apply those for ELN. It is going to take > some thinking. We could probably split the RHEL only flag to really > mean RHEL only, and add another flag for all Red Hat builds, and then > make sure that the RHEL only patches are only applied for non Fedora > builds. The downside to this is I do 100% of my work on Fedora, and > would not see if there were a problem with these specific patches. I > will put some thought into it. > Looking at these type patches again, and the dependencies on them, they are all wrapped in CONFIG_RH_DISABLE_DEPRECATED or CONFIG_RHEL_DIFFERENCES. If they are not, that is a bug. So the patches are there, but the config options are turned off for Fedora. The Fedora kernels should always build as though they are not there. The ELN kernel does build with them enabled. The original build failure here was due to one not being wrapped, and it should be fixed. As all of this work is now happening in the public, we will have better options to make sure that future patches of this nature do not get missed. I would still like the upstream status tag to change from RHEL to RH or similar though. Justin _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-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/kernel@xxxxxxxxxxxxxxxxxxxxxxx
