[OS-BUILD PATCH] docs: Update docs to reflect newer workflow.

[GitLab Bridge on behalf of dzickusrh]

From: Don Zickus <dzickus(a)redhat.com&gt;

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.

Also add it a build dep for making a srpm: patchutils (for filterdiff).

Cc: Bastien Nocera <bnocera(a)redhat.com&gt;
Cc: Prarit Bhargava <prarit(a)redhat.com&gt;
Cc: Justin Forbes <jforbes(a)redhat.com&gt;
Signed-off-by: Don Zickus <dzickus(a)redhat.com&gt;
---
 redhat/docs/index.rst                    | 16 +++++-----------
 redhat/docs/repository-layout.rst        |  7 -------
 redhat/docs/submitting-contributions.rst |  4 ++--
 3 files changed, 7 insertions(+), 20 deletions(-)

diff --git a/redhat/docs/index.rst b/redhat/docs/index.rst
index 951845cc7be3..b451b9ba49ca 100644
--- a/redhat/docs/index.rst
+++ b/redhat/docs/index.rst
@@ -36,8 +36,8 @@ Once GitLab finishes forking the repository (this can take a while):
    git remote add -f upstream [e-mail]:cki-project/kernel-ark.git
 
    # Install build dependencies
-   sudo dnf install -y make gcc flex bison bzip2 rpm-build
-   git checkout upstream/ark-latest
+   sudo dnf install -y make gcc flex bison bzip2 rpm-build patchutils
+   git checkout upstream/os-build
    # If you're on Fedora, you need to run:
    # ln -s /usr/bin/python3 /usr/libexec/platform-python
    make dist-srpm
@@ -48,18 +48,11 @@ Building an SRPM
 ----------------
 
 The configuration and build scripts are in the ``os-build`` branch and
-are regularly updated to work with Linus's master branch. To build an
-SRPM, start by checking out the source tree you'd like to build. In this
-example, we'll assume that is Linus's master branch, but it could just
-as easily be Fedora's ``ark-patches`` branch (Linus's tree + Fedora
-patches) , a sub-system maintainer's tree, or your own creation.
+are regularly updated to work with Linus's master branch.
 
 ::
 
-   git checkout linus/master
-   git merge -m "Merge branch 'os-build'"  os-build
-   # Fedora carries a patch to alter this setting, so we need to change the configuration
to build a vanilla tree.
-   # If you're targeting RHEL and have brew/rhpkg installed, use "make
DIST=.elrdy dist-srpm" instead
+   git checkout upstream/os-build
    make dist-srpm
 
 You can now build the SRPM however you like:
@@ -70,6 +63,7 @@ You can now build the SRPM however you like:
    mock redhat/rpm/SRPMS/kernel*src.rpm
    # Build the SRPM in Fedora's Koji
    koji build --scratch rawhide redhat/rpm/SRPMS/kernel*src.rpm
+   koji build --scratch eln redhat/rpm/SRPMS/kernel*src.rpm
 
 Want to add a patch? Just git-cherry-pick it or apply it with git-am and
 re-run ``make dist-srpm``. Change configurations in ``redhat/configs/``
diff --git a/redhat/docs/repository-layout.rst b/redhat/docs/repository-layout.rst
index 5f6dcb08a1bd..851a2c5d715b 100644
--- a/redhat/docs/repository-layout.rst
+++ b/redhat/docs/repository-layout.rst
@@ -63,13 +63,6 @@ along with the configuration and build scripts. They can be checked
out
 and built into RPMs. The ``master`` branch points to the latest version
 of these branches.
 
-rhpatches
-~~~~~~~~~
-
-This branch is no longer used. Previously, it held the Red Hat patches
-for the kernel as a quilt series and remains for historical reasons.
-Patch history up to v5.4 is available in this branch.
-
 Tags
 ----
 
diff --git a/redhat/docs/submitting-contributions.rst
b/redhat/docs/submitting-contributions.rst
index 07b25852ec66..65895a9ce49b 100644
--- a/redhat/docs/submitting-contributions.rst
+++ b/redhat/docs/submitting-contributions.rst
@@ -39,8 +39,8 @@ Patches
 Quick start:
 
 1. ``git fetch upstream``
-2. ``git checkout upstream/os-build && git checkout -b my-build-change``
-3. Make a change to a file or files in ``redhat/``.
+2. ``git checkout -b my-build-change upstream/os-build``
+3. Make a change to a file.
 4. Add your changes with ``git add -A``.
 5. Commit your changes and write a nice commit message that explains the
    change: ``git commit -s``.
-- 
GitLab

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

[Thorsten Leemhuis]

Lo!

Am 24.11.20 um 23:22 schrieb GitLab Bridge on behalf of dzickusrh:
>  From: Don Zickus <dzickus(a)redhat.com&gt;
>  
>  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? When fedora 
rawhide started to use ark that was easy, because all the patches that 
actually modified the kernel code for real where in a separate, optional 
branch (that was only a few month ago, but forgot the name already, 
sorry...). But I lost track how to do that now everything is mixed up in 
the os-build branch and it's something I'd like to use to build my 
kernel vanilla packages 
(https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories ) straight 
from ark.

Ciao, Thorsten

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

[Don Zickus]

On Wed, Nov 25, 2020 at 06:10:21AM +0100, Thorsten Leemhuis wrote:
>  Lo!
>  
>  Am 24.11.20 um 23:22 schrieb GitLab Bridge on behalf of dzickusrh:
>  > From: Don Zickus <dzickus(a)redhat.com&gt;
>  > 
>  > 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? When fedora rawhide
>  started to use ark that was easy, because all the patches that actually
>  modified the kernel code for real where in a separate, optional branch (that
>  was only a few month ago, but forgot the name already, sorry...). But I lost
>  track how to do that now everything is mixed up in the os-build branch and
>  it's something I'd like to use to build my kernel vanilla packages
>  (https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories ) straight from
>  ark. 
Ok. Fair question. :-)  Folks did not like the separate ark-patches branch,
so I combined it with os-build to make development easier, but created a gap
for vanilla kernels as you described.  Other RHEL folks requested the same
thing to apply the redhat/ infra to various upstream submaintainer trees.

My plan at the time was to auto-create another branch say 'redhat-infra'
(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.

However, that did slip off my radar and I never finished writing that script
to generate that branch.

But assuming I did finish that script, would the spirit of that approach
work for you?  (aside from a better name [suggestions welcome])

Cheers,
Don

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

[Thorsten Leemhuis]

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&gt;
> >> 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?).

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

[Thorsten Leemhuis]

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


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&gt;
>>>> 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?).

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

[Don Zickus]

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(a)redhat.com&gt;
>  >>>> 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

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

[Thorsten Leemhuis]

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. 
Thx!

>  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".
"ark-packaging" or
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
>      downside. :-/
> > Did I capture that right? 
Yes afaics.

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 ;-)

CU, knurd

>> 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&gt;
>>>>>> 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
>> 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/[e-mail]
>> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
> 
>

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

[Don Zickus]

On Thu, Mar 04, 2021 at 06:27:04PM +0100, Thorsten Leemhuis wrote:
>  > 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".
> "ark-packaging" or
>  something like that? 
I am not attached to 'redhat', so 'ark-infra' works for me.  Or whatever
is
easier to type. :-)

>  
>  > * 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. 
Ok.

>  
>  > * 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?
>  
>  Yes afaics.
>  
>  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 ;-) 
Perfect.  I can start with this and adjust over time.

Thanks!

Cheers,
Don

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

[Don Zickus]

On Thu, Mar 04, 2021 at 06:27:04PM +0100, Thorsten Leemhuis wrote:
>  > * 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".
> "ark-packaging" or
>  something like that? 
Hi Thorsten,

I pushed 'ark-infra' so you can give it a test.

https://gitlab.com/cki-project/kernel-ark/-/merge_requests/968 adds the
change to the daily rawhide_release job, so it is generated daily.

Let me know if you need some tweaks.  Sorry for the delay!

Cheers,
Don

[Bastien Nocera]

----- Original Message -----
>  From: Don Zickus <dzickus(a)redhat.com&gt;
>  
>  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.
>  
>  Also add it a build dep for making a srpm: patchutils (for filterdiff).
>  
>  Cc: Bastien Nocera <bnocera(a)redhat.com&gt;
>  Cc: Prarit Bhargava <prarit(a)redhat.com&gt;
>  Cc: Justin Forbes <jforbes(a)redhat.com&gt;
>  Signed-off-by: Don Zickus <dzickus(a)redhat.com&gt;
>  ---
>   redhat/docs/index.rst                    | 16 +++++-----------
>   redhat/docs/repository-layout.rst        |  7 -------
>   redhat/docs/submitting-contributions.rst |  4 ++--
>   3 files changed, 7 insertions(+), 20 deletions(-)
>  
>  diff --git a/redhat/docs/index.rst b/redhat/docs/index.rst
>  index 951845cc7be3..b451b9ba49ca 100644
>  --- a/redhat/docs/index.rst
>  +++ b/redhat/docs/index.rst
>  @@ -36,8 +36,8 @@ Once GitLab finishes forking the repository (this can take
>  a while):
>      git remote add -f upstream [e-mail]:cki-project/kernel-ark.git
>   
>      # Install build dependencies
>  -   sudo dnf install -y make gcc flex bison bzip2 rpm-build
>  -   git checkout upstream/ark-latest
>  +   sudo dnf install -y make gcc flex bison bzip2 rpm-build patchutils 
Would still be good if redhat/Makefile checked for filterdiff to be available.

https://gitlab.com/cki-project/kernel-ark/-/issues/34

>  +   git checkout upstream/os-build
>      # If you're on Fedora, you need to run:
>      # ln -s /usr/bin/python3 /usr/libexec/platform-python
>      make dist-srpm
>  @@ -48,18 +48,11 @@ Building an SRPM
>   ----------------
>   
>   The configuration and build scripts are in the ``os-build`` branch and
>  -are regularly updated to work with Linus's master branch. To build an
>  -SRPM, start by checking out the source tree you'd like to build. In this
>  -example, we'll assume that is Linus's master branch, but it could just
>  -as easily be Fedora's ``ark-patches`` branch (Linus's tree + Fedora
>  -patches) , a sub-system maintainer's tree, or your own creation.
>  +are regularly updated to work with Linus's master branch.
>   
>   ::
>   
>  -   git checkout linus/master
>  -   git merge -m "Merge branch 'os-build'"  os-build
>  -   # Fedora carries a patch to alter this setting, so we need to change the
>  configuration to build a vanilla tree.
>  -   # If you're targeting RHEL and have brew/rhpkg installed, use "make
>  DIST=.elrdy dist-srpm" instead
>  +   git checkout upstream/os-build 
Should that be:
git fetch upstream
git rebase upstream/os-build

So that the fork's os-build branch is updated and rebased from the upstream
repo's
os-build branch? Otherwise you end up being on a detached branch.

>      make dist-srpm
>   
>   You can now build the SRPM however you like:
>  @@ -70,6 +63,7 @@ You can now build the SRPM however you like:
>      mock redhat/rpm/SRPMS/kernel*src.rpm
>      # Build the SRPM in Fedora's Koji
>      koji build --scratch rawhide redhat/rpm/SRPMS/kernel*src.rpm
>  +   koji build --scratch eln redhat/rpm/SRPMS/kernel*src.rpm
>   
>   Want to add a patch? Just git-cherry-pick it or apply it with git-am and
>   re-run ``make dist-srpm``. Change configurations in ``redhat/configs/``
>  diff --git a/redhat/docs/repository-layout.rst
>  b/redhat/docs/repository-layout.rst
>  index 5f6dcb08a1bd..851a2c5d715b 100644
>  --- a/redhat/docs/repository-layout.rst
>  +++ b/redhat/docs/repository-layout.rst
>  @@ -63,13 +63,6 @@ along with the configuration and build scripts. They can
>  be checked out
>   and built into RPMs. The ``master`` branch points to the latest version
>   of these branches.
>   
>  -rhpatches
>  -~~~~~~~~~
>  -
>  -This branch is no longer used. Previously, it held the Red Hat patches
>  -for the kernel as a quilt series and remains for historical reasons.
>  -Patch history up to v5.4 is available in this branch.
>  -
>   Tags
>   ----
>   
>  diff --git a/redhat/docs/submitting-contributions.rst
>  b/redhat/docs/submitting-contributions.rst
>  index 07b25852ec66..65895a9ce49b 100644
>  --- a/redhat/docs/submitting-contributions.rst
>  +++ b/redhat/docs/submitting-contributions.rst
>  @@ -39,8 +39,8 @@ Patches
>   Quick start:
>   
>   1. ``git fetch upstream``
>  -2. ``git checkout upstream/os-build && git checkout -b my-build-change``
>  -3. Make a change to a file or files in ``redhat/``.
>  +2. ``git checkout -b my-build-change upstream/os-build`` 
Same problem here with the branch name.

>  +3. Make a change to a file.
>   4. Add your changes with ``git add -A``.
>   5. Commit your changes and write a nice commit message that explains the
>      change: ``git commit -s``.
>  --
>  GitLab
>  _______________________________________________
>  kernel mailing list -- kernel(a)lists.fedoraproject.org
>  To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>

[Don Zickus]

On Tue, Dec 01, 2020 at 10:27:58AM -0500, Bastien Nocera wrote:
>  
>  
>  ----- Original Message -----
>  > From: Don Zickus <dzickus(a)redhat.com&gt;
>  > 
>  > 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.
>  > 
>  > Also add it a build dep for making a srpm: patchutils (for filterdiff).
>  > 
>  > Cc: Bastien Nocera <bnocera(a)redhat.com&gt;
>  > Cc: Prarit Bhargava <prarit(a)redhat.com&gt;
>  > Cc: Justin Forbes <jforbes(a)redhat.com&gt;
>  > Signed-off-by: Don Zickus <dzickus(a)redhat.com&gt;
>  > ---
>  >  redhat/docs/index.rst                    | 16 +++++-----------
>  >  redhat/docs/repository-layout.rst        |  7 -------
>  >  redhat/docs/submitting-contributions.rst |  4 ++--
>  >  3 files changed, 7 insertions(+), 20 deletions(-)
>  > 
>  > diff --git a/redhat/docs/index.rst b/redhat/docs/index.rst
>  > index 951845cc7be3..b451b9ba49ca 100644
>  > --- a/redhat/docs/index.rst
>  > +++ b/redhat/docs/index.rst
>  > @@ -36,8 +36,8 @@ Once GitLab finishes forking the repository (this can take
>  > a while):
>  >     git remote add -f upstream [e-mail]:cki-project/kernel-ark.git
>  >  
>  >     # Install build dependencies
>  > -   sudo dnf install -y make gcc flex bison bzip2 rpm-build
>  > -   git checkout upstream/ark-latest
>  > +   sudo dnf install -y make gcc flex bison bzip2 rpm-build patchutils
>  
>  Would still be good if redhat/Makefile checked for filterdiff to be available.
>  
>  https://gitlab.com/cki-project/kernel-ark/-/issues/34 
Instead of adding more checks, I went the opposite way and remove the need
for it and use native git instead.  I just posted that MR and cc'd you on
it.

I can update these docs to remove the added patchutils.

Cheers,
Don

>  
>  > +   git checkout upstream/os-build
>  >     # If you're on Fedora, you need to run:
>  >     # ln -s /usr/bin/python3 /usr/libexec/platform-python
>  >     make dist-srpm
>  > @@ -48,18 +48,11 @@ Building an SRPM
>  >  ----------------
>  >  
>  >  The configuration and build scripts are in the ``os-build`` branch and
>  > -are regularly updated to work with Linus's master branch. To build an
>  > -SRPM, start by checking out the source tree you'd like to build. In this
>  > -example, we'll assume that is Linus's master branch, but it could just
>  > -as easily be Fedora's ``ark-patches`` branch (Linus's tree + Fedora
>  > -patches) , a sub-system maintainer's tree, or your own creation.
>  > +are regularly updated to work with Linus's master branch.
>  >  
>  >  ::
>  >  
>  > -   git checkout linus/master
>  > -   git merge -m "Merge branch 'os-build'"  os-build
>  > -   # Fedora carries a patch to alter this setting, so we need to change the
>  > configuration to build a vanilla tree.
>  > -   # If you're targeting RHEL and have brew/rhpkg installed, use "make
>  > DIST=.elrdy dist-srpm" instead
>  > +   git checkout upstream/os-build
>  
>  Should that be:
>  git fetch upstream
>  git rebase upstream/os-build
>  
>  So that the fork's os-build branch is updated and rebased from the upstream
> repo's
>  os-build branch? Otherwise you end up being on a detached branch.
>  
>  >     make dist-srpm
>  >  
>  >  You can now build the SRPM however you like:
>  > @@ -70,6 +63,7 @@ You can now build the SRPM however you like:
>  >     mock redhat/rpm/SRPMS/kernel*src.rpm
>  >     # Build the SRPM in Fedora's Koji
>  >     koji build --scratch rawhide redhat/rpm/SRPMS/kernel*src.rpm
>  > +   koji build --scratch eln redhat/rpm/SRPMS/kernel*src.rpm
>  >  
>  >  Want to add a patch? Just git-cherry-pick it or apply it with git-am and
>  >  re-run ``make dist-srpm``. Change configurations in ``redhat/configs/``
>  > diff --git a/redhat/docs/repository-layout.rst
>  > b/redhat/docs/repository-layout.rst
>  > index 5f6dcb08a1bd..851a2c5d715b 100644
>  > --- a/redhat/docs/repository-layout.rst
>  > +++ b/redhat/docs/repository-layout.rst
>  > @@ -63,13 +63,6 @@ along with the configuration and build scripts. They can
>  > be checked out
>  >  and built into RPMs. The ``master`` branch points to the latest version
>  >  of these branches.
>  >  
>  > -rhpatches
>  > -~~~~~~~~~
>  > -
>  > -This branch is no longer used. Previously, it held the Red Hat patches
>  > -for the kernel as a quilt series and remains for historical reasons.
>  > -Patch history up to v5.4 is available in this branch.
>  > -
>  >  Tags
>  >  ----
>  >  
>  > diff --git a/redhat/docs/submitting-contributions.rst
>  > b/redhat/docs/submitting-contributions.rst
>  > index 07b25852ec66..65895a9ce49b 100644
>  > --- a/redhat/docs/submitting-contributions.rst
>  > +++ b/redhat/docs/submitting-contributions.rst
>  > @@ -39,8 +39,8 @@ Patches
>  >  Quick start:
>  >  
>  >  1. ``git fetch upstream``
>  > -2. ``git checkout upstream/os-build && git checkout -b my-build-change``
>  > -3. Make a change to a file or files in ``redhat/``.
>  > +2. ``git checkout -b my-build-change upstream/os-build``
>  
>  Same problem here with the branch name.
>  
>  > +3. Make a change to a file.
>  >  4. Add your changes with ``git add -A``.
>  >  5. Commit your changes and write a nice commit message that explains the
>  >     change: ``git commit -s``.
>  > --
>  > GitLab
>  > _______________________________________________
>  > kernel mailing list -- kernel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
>  > 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/[e-mail]
>  > 
>  _______________________________________________
>  kernel mailing list -- kernel(a)lists.fedoraproject.org
>  To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
>  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/[e-mail]

[Don Zickus]

On Tue, Dec 01, 2020 at 10:27:58AM -0500, Bastien Nocera wrote:
>  > -   git checkout linus/master
>  > -   git merge -m "Merge branch 'os-build'"  os-build
>  > -   # Fedora carries a patch to alter this setting, so we need to change the
>  > configuration to build a vanilla tree.
>  > -   # If you're targeting RHEL and have brew/rhpkg installed, use "make
>  > DIST=.elrdy dist-srpm" instead
>  > +   git checkout upstream/os-build
>  
>  Should that be:
>  git fetch upstream
>  git rebase upstream/os-build
>  
>  So that the fork's os-build branch is updated and rebased from the upstream
> repo's
>  os-build branch? Otherwise you end up being on a detached branch. 
I failed to address the rest of your comments.

I will update the docs to deal with this but you won't need to rebase, you
can fast-forward merge.  I will also set up the 'master' branch to address
your other concern.  Sorry about that.  This time I am running through a
clean clone to verify the steps.


>  
>  >     make dist-srpm
>  >  
>  >  You can now build the SRPM however you like:
>  > @@ -70,6 +63,7 @@ You can now build the SRPM however you like:
>  >     mock redhat/rpm/SRPMS/kernel*src.rpm
>  >     # Build the SRPM in Fedora's Koji
>  >     koji build --scratch rawhide redhat/rpm/SRPMS/kernel*src.rpm
>  > +   koji build --scratch eln redhat/rpm/SRPMS/kernel*src.rpm
>  >  
>  >  Want to add a patch? Just git-cherry-pick it or apply it with git-am and
>  >  re-run ``make dist-srpm``. Change configurations in ``redhat/configs/``
>  > diff --git a/redhat/docs/repository-layout.rst
>  > b/redhat/docs/repository-layout.rst
>  > index 5f6dcb08a1bd..851a2c5d715b 100644
>  > --- a/redhat/docs/repository-layout.rst
>  > +++ b/redhat/docs/repository-layout.rst
>  > @@ -63,13 +63,6 @@ along with the configuration and build scripts. They can
>  > be checked out
>  >  and built into RPMs. The ``master`` branch points to the latest version
>  >  of these branches.
>  >  
>  > -rhpatches
>  > -~~~~~~~~~
>  > -
>  > -This branch is no longer used. Previously, it held the Red Hat patches
>  > -for the kernel as a quilt series and remains for historical reasons.
>  > -Patch history up to v5.4 is available in this branch.
>  > -
>  >  Tags
>  >  ----
>  >  
>  > diff --git a/redhat/docs/submitting-contributions.rst
>  > b/redhat/docs/submitting-contributions.rst
>  > index 07b25852ec66..65895a9ce49b 100644
>  > --- a/redhat/docs/submitting-contributions.rst
>  > +++ b/redhat/docs/submitting-contributions.rst
>  > @@ -39,8 +39,8 @@ Patches
>  >  Quick start:
>  >  
>  >  1. ``git fetch upstream``
>  > -2. ``git checkout upstream/os-build && git checkout -b my-build-change``
>  > -3. Make a change to a file or files in ``redhat/``.
>  > +2. ``git checkout -b my-build-change upstream/os-build``
>  
>  Same problem here with the branch name. 
This should be right.  Basically all the work is done against
upstream/os-build (which acts like a typical 'master' branch).

So you should be able to

git fetch upstream
git checkout -b foo upstream/os-build  #to base the branch on os-build
<hack hack>
git add <files>
git commit -s ...

I might be misunderstanding your comment?

Cheers,
Don

[OS-BUILD PATCHv2] docs: Update docs to reflect newer workflow.

[GitLab Bridge on behalf of dzickusrh]

From: Don Zickus <dzickus(a)redhat.com&gt;

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.

Also add it a build dep for making a srpm: patchutils (for filterdiff).

V2: Fix checkout command and setup master branch

Cc: Bastien Nocera <bnocera(a)redhat.com&gt;
Cc: Prarit Bhargava <prarit(a)redhat.com&gt;
Cc: Justin Forbes <jforbes(a)redhat.com&gt;
Signed-off-by: Don Zickus <dzickus(a)redhat.com&gt;
---
 redhat/docs/index.rst                    | 17 +++++++----------
 redhat/docs/repository-layout.rst        |  7 -------
 redhat/docs/submitting-contributions.rst |  4 ++--
 3 files changed, 9 insertions(+), 19 deletions(-)

diff --git a/redhat/docs/index.rst b/redhat/docs/index.rst
index 951845cc7be3..b3aec8f27a6b 100644
--- a/redhat/docs/index.rst
+++ b/redhat/docs/index.rst
@@ -37,7 +37,8 @@ Once GitLab finishes forking the repository (this can take a while):
 
    # Install build dependencies
    sudo dnf install -y make gcc flex bison bzip2 rpm-build
-   git checkout upstream/ark-latest
+   git branch master --track upstream/master
+   git checkout os-build
    # If you're on Fedora, you need to run:
    # ln -s /usr/bin/python3 /usr/libexec/platform-python
    make dist-srpm
@@ -48,18 +49,13 @@ Building an SRPM
 ----------------
 
 The configuration and build scripts are in the ``os-build`` branch and
-are regularly updated to work with Linus's master branch. To build an
-SRPM, start by checking out the source tree you'd like to build. In this
-example, we'll assume that is Linus's master branch, but it could just
-as easily be Fedora's ``ark-patches`` branch (Linus's tree + Fedora
-patches) , a sub-system maintainer's tree, or your own creation.
+are regularly updated to work with Linus's master branch.
 
 ::
 
-   git checkout linus/master
-   git merge -m "Merge branch 'os-build'"  os-build
-   # Fedora carries a patch to alter this setting, so we need to change the configuration
to build a vanilla tree.
-   # If you're targeting RHEL and have brew/rhpkg installed, use "make
DIST=.elrdy dist-srpm" instead
+   git checkout os-build
+   git fetch upstream
+   git merge upstream/os-build
    make dist-srpm
 
 You can now build the SRPM however you like:
@@ -70,6 +66,7 @@ You can now build the SRPM however you like:
    mock redhat/rpm/SRPMS/kernel*src.rpm
    # Build the SRPM in Fedora's Koji
    koji build --scratch rawhide redhat/rpm/SRPMS/kernel*src.rpm
+   koji build --scratch eln redhat/rpm/SRPMS/kernel*src.rpm
 
 Want to add a patch? Just git-cherry-pick it or apply it with git-am and
 re-run ``make dist-srpm``. Change configurations in ``redhat/configs/``
diff --git a/redhat/docs/repository-layout.rst b/redhat/docs/repository-layout.rst
index 5f6dcb08a1bd..851a2c5d715b 100644
--- a/redhat/docs/repository-layout.rst
+++ b/redhat/docs/repository-layout.rst
@@ -63,13 +63,6 @@ along with the configuration and build scripts. They can be checked
out
 and built into RPMs. The ``master`` branch points to the latest version
 of these branches.
 
-rhpatches
-~~~~~~~~~
-
-This branch is no longer used. Previously, it held the Red Hat patches
-for the kernel as a quilt series and remains for historical reasons.
-Patch history up to v5.4 is available in this branch.
-
 Tags
 ----
 
diff --git a/redhat/docs/submitting-contributions.rst
b/redhat/docs/submitting-contributions.rst
index 07b25852ec66..65895a9ce49b 100644
--- a/redhat/docs/submitting-contributions.rst
+++ b/redhat/docs/submitting-contributions.rst
@@ -39,8 +39,8 @@ Patches
 Quick start:
 
 1. ``git fetch upstream``
-2. ``git checkout upstream/os-build && git checkout -b my-build-change``
-3. Make a change to a file or files in ``redhat/``.
+2. ``git checkout -b my-build-change upstream/os-build``
+3. Make a change to a file.
 4. Add your changes with ``git add -A``.
 5. Commit your changes and write a nice commit message that explains the
    change: ``git commit -s``.
-- 
GitLab

[OS-BUILD PATCHv2] docs: Update docs to reflect newer workflow.

[GitLab Bridge on behalf of Bastien Nocera]

From: Bastien Nocera on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/772#note_46053...

That means that the user will need to update the local master branch
manually, right? Should the scripts reference `upstream/master` instead?

[OS-BUILD PATCHv2] docs: Update docs to reflect newer workflow.

[GitLab Bridge on behalf of Bastien Nocera]

From: Bastien Nocera on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/772#note_46053...

The `git branch` call above doesn't switch to the `master` branch, so
there shouldn't be any need to call `git checkout os-build` here.

[OS-BUILD PATCHv2] docs: Update docs to reflect newer workflow.

[GitLab Bridge on behalf of Don Zickus]

From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/772#note_46540...

I assume you are referring to internal scripts reference to 'master'.
If so, I worry that not everyone will use 'upstream' as their reference
name.  And they may not 'git fetch upstream' frequent enough.   This
leaves them with the same problem as not updating 'master' as you
suggested.

Thoughts?

[OS-BUILD PATCHv2] docs: Update docs to reflect newer workflow.

[GitLab Bridge on behalf of Don Zickus]

From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/772#note_46540...

Yeah, I can remove that. Thanks!

[OS-BUILD PATCHv2] docs: Update docs to reflect newer workflow.

[Don Zickus (via Email Bridge)]

From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/772#note_54404...

@hadess1 - created !995 to address your concerns.  This should allow me
to delete that line from the documentation.  Let me re-push with your
above 2 requests.