On 04.03.21 16:59, Don Zickus wrote:
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.
Yeah, happens, no worries.
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
I'd prefer to not have "redhat" in there (but I can live with it if we
don't find anything better). How about "ark-infra".
something like that?
* that branch is built from scratch daily? weekly?
Daily would be good to pick up the latest changes to the config files
that get merged to ark.
* 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
> Did I capture that right?
FWIW, this is how I hope to use it:
* create a throwaway branch based on mainline, stable or stable-rc kernels
* run something like "make fedora-srpm"
* build this srpm with mock or koji scratch-build
* profit ;-)
>> 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(a)redhat.com>
>>>>>> The workflow has recently changed such that all development is
>>>>>> 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
>>>>> While you are dealing with this a quick question: What's the best
>>>>> to use
>>>>> the ark tree to build a vanilla kernel these days?
>>>> My plan at the time was to auto-create another branch say
>>> 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"
>>> 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
>>>> concern, I believe.
>>> Yes, that should work for me.
>>>> However, that did slip off my radar and I never finished writing that
>>>> 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
>>> 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
>> Fedora Code of Conduct:
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> Do not reply to spam on the list, report it: