Re: How to build vanilla kernel from ark (was: Re: [OS-BUILD PATCH] docs: Update docs to reflect newer workflow.)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 04, 2021 at 10:46:47AM +0100, Thorsten Leemhuis wrote:
> Hi Don! Do you still have this "git merge
>  redhat-infra" idea you mentioned a few weeks ago on your radar? Now
> that Fedora starts to use kernel-ark for stable kernels as well it would
> be really nice to have something like that that at hand... At least for
> me. ;-) CU, knurd

I am trying to put it on my radar, unfortunately other priorities keep
bumping it way down.  I just had this conversation the other day with Justin
and he explained to me about how the community would see this as useful.

Let me try to find an hour to sketch a workflow for this.  It shouldn't be
hard, just need to pencil it out.

Just to remind myself of your expectation.

* I take os-build spin off the 'redhat' directory (and other infra pieces)
  into a branch called  'redhat-infra'??? or something better
* that branch is built from scratch daily? weekly?
* a git-merge of said branch on any upstream branch should just work
  * rebasing that branch does prevent a proper 'git merge' update as a
    downside. :-/

Did I capture that right?

Cheers,
Don

> 
> 
> On 25.11.20 18:27, Thorsten Leemhuis wrote:
> > Am 25.11.20 um 15:43 schrieb Don Zickus:
> >> On Wed, Nov 25, 2020 at 06:10:21AM +0100, Thorsten Leemhuis wrote:
> >>> Am 24.11.20 um 23:22 schrieb GitLab Bridge on behalf of dzickusrh:
> >>>> From: Don Zickus <dzickus@xxxxxxxxxx>
> >>>> The workflow has recently changed such that all development is done
> >>>> on the 'os-build' branch.  Update the docs to show how easy it is
> >>>> to make a change, commit it, generate the srpm and upload it to koji.
> >>>> […]
> >>>
> >>> While you are dealing with this a quick question: What's the best way
> >>> to use
> >>> the ark tree to build a vanilla kernel these days? 
> >> My plan at the time was to auto-create another branch say 'redhat-infra'
> > 
> > How about "build-infra" or "rh-build-infra"? (for the record: I find all
> > those redhat and rh terms in ark slightly annoying, because it's sending
> > the wrong message to community contributes, but well, one more "rh" or
> > less now doesn't matter anymore...)
> > 
> >> (bad name I know) that stripped Red Hat patches out of os-build
> >> leaving just
> >> the redhat/ directory on top of upstream 'linus' branch.
> >>
> >> Then you could take any upstream branch and just 'git merge
> >> redhat-infra' to
> >> quickly add in the RH infrastructure pieces.  And that would address your
> >> concern, I believe.
> > 
> > Yes, that should work for me.
> > 
> >> However, that did slip off my radar and I never finished writing that
> >> script
> >> to generate that branch.
> > 
> > Happens, no worries, I might have made more noise earlier if I actually
> > had been using ark as base for my vanilla builds ;-)
> > 
> >> But assuming I did finish that script, would the spirit of that approach
> >> work for you?  (aside from a better name [suggestions welcome])
> > 
> > Afaics yes(¹). And of course I'm willing to test and fine-tune this.
> > 
> > Ciao, Thorsten
> > 
> > (¹) while at please let me state a remotely related general wish, maybe
> > it's something that might be useful for others as well: for my use case
> > it would be ideal if redhat/configs/fedora/ in ark would also contain
> > which config settings ideally need to be set differently when building a
> > kernel for an older release. Right now one of the few differences (apart
> > from new config options) between rawhide and F32 for example is
> > CONFIG_FB_MODE_HELPERS: in rawhide it's not set, in F32 it's enabled.
> > Having this information directly in ark as a override (maybe in
> > redhat/configs/fedora/32/, redhat/configs/fedora/overrides/f32/, or
> > something like that) would be useful for me; and I guess it would be
> > useful for the Fedora's kernel maintainers as well, in case they start
> > building kernels for released Fedora version from ark sooner or later as
> > well (which I assume is the long term plan – or not?).
> _______________________________________________
> 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
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux