On Tue, May 19, 2020 at 10:03 AM Prarit Bhargava <prarit@xxxxxxxxxx> wrote:
> On 5/19/20 10:45 AM, Don Zickus wrote:
> > On Tue, May 19, 2020 at 10:33:52AM -0400, Don Zickus wrote:
> >> On Tue, May 19, 2020 at 01:47:09PM -0000, GitLab Bridge on behalf of
> prarit wrote:
> >>> From: Prarit Bhargava <prarit@xxxxxxxxxx>
> >>>
> >>> The internal make command 'make rh-brew'/'make dist-brew' is failing
> with
> >>>
> >>> Processing
> /home/prarit/git-kernel/kernel-ark/redhat/configs/kernel-aarch64-debug-fedora.config
> ... Error: Mismatches found in configuration files
> >>> Found CONFIG_FORCE_MAX_ZONEORDER=11 after generation, had
> CONFIG_FORCE_MAX_ZONEORDER=13 in Source tree
> >>>
> >>> ARK commit f5ca593e1c2e ("configs: Adjust CONFIG_FORCE_MAX_ZONEORDER
> for
> >>> Fedora") set this to 11, and follow-on ARK commit dd028d261347
> ("[redhat]
> >>> Sync up ARK's Fedora config tree with Fedora's dist-git") erroneously
> >>> overwrote the value back to 13.
> >>>
> >>> Set CONFIG_FORCE_MAX_ZONEORDER back to 11 for aarch64.
> >>
> >> This works for os-build but fails for ark-latest because there is a
> patch in
> >> ark-patches that changes the default to 13.
> >>
> >> The problem is we tried to keep the redhat/ changes separate from the
> >> redhat/fedora only patches in ark-patches. The goal was os-build could
> >> build standalone and the combination of ark-patches into ark-latest
> could
> >> build standalone.
> >>
> >> Because of that arm64 change of the default to 13, we broke the os-build
> >> standalone build. And because the ark-patches does not have the redhat/
> >> area, we can't make config changes on that branch.
> >
> > I forgot to point out the patch that causes this:
> > (git log -p origin/master..origin/ark-patches arch/arm64)
> >
> >
> > commit df97e71c24526cabc6a434d9f35ef493056b1bcf
> > Author: Peter Robinson <pbrobinson@xxxxxxxxx>
> > Date: Wed Feb 26 13:38:40 2020 -0500
> >
> > Add option of 13 for FORCE_MAX_ZONEORDER
> >
> > This is a hack, but it's what the other distros currently use
> > for aarch64 with 4K pages so we'll do the same while upstream
> > decides what the best outcome is (which isn't this).
> >
> > Upstream Status: RHEL only
> > Signed-off-by: Peter Robinson <pbrobinson@xxxxxxxxx>
> > [Add a dependency on RHEL_DIFFERENCES]
> > Signed-off-by: Jeremy Cline <jcline@xxxxxxxxxx>
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 9e87f5847c92..f57bee916600 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -1125,6 +1125,7 @@ config XEN
> > config FORCE_MAX_ZONEORDER
> > int
> > default "14" if (ARM64_64K_PAGES && TRANSPARENT_HUGEPAGE)
> > + default "13" if (ARCH_THUNDER && !ARM64_64K_PAGES &&
> !RHEL_DIFFERENCES)
> > default "12" if (ARM64_16K_PAGES && TRANSPARENT_HUGEPAGE)
> > default "11"
> > help
> >
>
> Got it. But I'm confused and am struggling to figure out somethings with
> the
> new process. I'm still confused how to build a kernel in the kernel-ark
> tree.
>
> Do I use os-build, ark-patches, or ark-latest? And, what commands do I
> issue?
> Also how do I force an eln build if I'm running on Fedora? Right now I'm
> hacking redhat/Makefile.common on the os-build branch to set
> "IS_FEDORA=:0".
>
> I cannot believe this is so complicated. I know there are reasons for it
> but it
> strikes me that I can't figure it out and I've been paying attention.
>
Right, so as a maintainer, trying to build is a *massive* PITA unless you
want to build what is already there. Luckily, there is a script that runs
nightly and takes care of a lot of that PITA, creating ark-latest. To
build from ark-latest, you can do.
git checkout ark-latest
git reset --hard origin/ark-latest
touch localversion
make rh-dist-git-test or (preferred target)
Generally speaking ark-patches should work, and that is where people do
patch work. os-build is really for config/spec/script changes. Sometimes
ark-latest will be required though because ark-latest includes merge
requests which have not been merged yet (labeled with "Include in Releases"
in gitlab). If people could do review and get those merged, they would
appear elsewhere and all of this would be easier. That label allows us to
get a Fedora build done without having to wait for RHEL review, and I
certainly don't have the time to spend chasing people down to make sure
those reviews get done. There are currently 5 of those merge requests
that I will be happy to merge once the reviews are done, Fedora and ELN
have been building with them for a while.
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
