From: Don Zickus dzickus@redhat.com
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@redhat.com Cc: Prarit Bhargava prarit@redhat.com Cc: Justin Forbes jforbes@redhat.com Signed-off-by: Don Zickus dzickus@redhat.com --- 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 git@gitlab.com: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``.
Lo!
Am 24.11.20 um 23:22 schrieb GitLab Bridge on behalf of dzickusrh:
From: Don Zickus dzickus@redhat.com
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
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@redhat.com
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
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@redhat.com 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?).
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@redhat.com 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?).
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@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@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/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@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/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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
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
----- Original Message -----
From: Don Zickus dzickus@redhat.com
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@redhat.com Cc: Prarit Bhargava prarit@redhat.com Cc: Justin Forbes jforbes@redhat.com Signed-off-by: Don Zickus dzickus@redhat.com
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 git@gitlab.com: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:
- ``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@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@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/kernel@lists.fedoraproject.org
On Tue, Dec 01, 2020 at 10:27:58AM -0500, Bastien Nocera wrote:
----- Original Message -----
From: Don Zickus dzickus@redhat.com
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@redhat.com Cc: Prarit Bhargava prarit@redhat.com Cc: Justin Forbes jforbes@redhat.com Signed-off-by: Don Zickus dzickus@redhat.com
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 git@gitlab.com: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.
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:
- ``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@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@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/kernel@lists.fedoraproject.org
kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@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/kernel@lists.fedoraproject.org
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:
- ``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
From: Don Zickus dzickus@redhat.com
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@redhat.com Cc: Prarit Bhargava prarit@redhat.com Cc: Justin Forbes jforbes@redhat.com Signed-off-by: Don Zickus dzickus@redhat.com --- 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``.
From: Bastien Nocera on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/772#note_46053917...
That means that the user will need to update the local master branch manually, right? Should the scripts reference `upstream/master` instead?
From: Bastien Nocera on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/772#note_46053917...
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.
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/772#note_46540042...
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?
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/772#note_46540056...
Yeah, I can remove that. Thanks!
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/772#note_54404378...
@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.
kernel@lists.fedoraproject.org