From: Veronika Kabatova
Updated to include schedule jobs and pages deployment (Don Zickus)
Signed-off-by: Veronika Kabatova
---
.gitlab-ci.yml | 179 ++---
1 file changed, 169 insertions(+), 10 deletions(-)
diff --git a/.gitlab-ci.yml
From: Veronika Kabatova
Updated to include schedule jobs and pages deployment (Don Zickus)
Signed-off-by: Veronika Kabatova
---
.gitlab-ci.yml | 179 ++---
1 file changed, 169 insertions(+), 10 deletions(-)
diff --git a/.gitlab-ci.yml
From: Don Zickus
---
.gitlab-ci.yml | 32 +++-
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index f4cf9dff3436..d8cf0256d84c 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -1,10 +1,24 @@
-# CI definitions for
From: Don Zickus
---
.gitlab-ci.yml | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index f4cf9dff3436..2b5a9bcf648c 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -1,10 +1,23 @@
-# CI definitions for
From: Don Zickus
Closes: #34
Long ago, we needed the ability to filter out files and directories
from patches. Now that ability is built into git a few years ago,
let's use that instead of filterdiff.
One less tool to depend on and require.
V2: rebase and fix conflicts
Cc: Bastien Nocera
From: Don Zickus
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).
From: Don Zickus
Long ago, we needed the ability to filter out files and directories
from patches. Now that ability is built into git a few years ago,
let's use that instead of filterdiff.
One less tool to depend on and require.
Cc: Bastien Nocera
Cc: Herton Krzesinski
Signed-off-by: Don
From: Don Zickus
This option is needed to allow the latest features of bpftool
to compile correctly. Currently it was disabled because of
a gcc bug around DWARF info. That has been resolved with the
latest gcc and/or dwarves package. Re-enable.
Signed-off-by: Don Zickus
V2: Add dwarves
From: Don Zickus
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).
From: Don Zickus
This option is needed to allow the latest features of bpftool
to compile correctly. Currently it was disabled because of
a gcc bug around DWARF info. That has been resolved with the
latest gcc and/or dwarves package. Re-enable.
Signed-off-by: Don Zickus
---
From: Don Zickus
There are two parts to this fix. One is using the recommended way
to disable LTO. The other is to make it work for the kernel.spec
file.
Various kernel-tool programs (like perf) can not handle LTO yet, so
they are disabled.
This is done with '%define _lto_cflags {nil}'.
From: Don Zickus
For CKI and its cross-compile environment, it can not cross
compile userspace tools. Instead we will native compiles them.
To allow this split, the kernel.spec needs to support only
building userspace stuff and not the kernel itself.
However the userspace tools need some vars
From: Don Zickus
For CKI and its cross-compile environment, it can not cross
compile userspace tools. Instead we will native compiles them.
To allow this split, the kernel.spec needs to support only
building userspace stuff and not the kernel itself.
However the userspace tools need some vars
From: Don Zickus
While debugging LTO issues, I disabled kernel-selftests
temporarily. This exposed an issue in turbostat that
required libcap to compile. Add the BuildRequires to
the spec file.
I don't expect this scenario to happen at all. This
fix is for completeness and less headaches in
From: Don Zickus
There are two parts to this fix. One is using the recommended way
to disable LTO. The other is to make it work for the kernel.spec
file.
Various kernel-tool programs (like perf) can not handle LTO yet, so
they are disabled.
This is done with '%define _lto_cflags {nil}'.
From: Don Zickus
A few configs changed their dependencies and that affects what options
the configs can be. Two configs can no longer be inline and one brings
in more confgs that are unnecessary. Fix them quickly for a review
later.
Signed-off-by: Don Zickus
---
From: Don Zickus
I created an optimization to speed up the automated scripts when there was
nothing to merge in redhat/scripts/ci/ark-update-configs.sh under
2d1d129bbe310da5a8751e8e8ff4dc2209337d22
The thought was, if 'master' wasn't updated or needed merging, how can there be
any new configs
From: Don Zickus
Based on a suggestion from Thorsten Leemhuis.
Thorsten suggested making it easier to see that individual change
by embedding the url to the commit in the patchlist.changelog file.
This change does exactly that.
Old output:
e338eecf3fe79054e8a31b8c39a1234b5acfdabe PCI:
From: Don Zickus
Based on a suggestion from Thorsten Leemhuis.
Thorsten suggested making it easier to see that individual change
by embedding the url to the commit in the patchlist.changelog file.
This change does exactly that.
Old output:
e338eecf3fe79054e8a31b8c39a1234b5acfdabe PCI:
From: Don Zickus
The ark-update-configs.sh script is written to be executed from the top of the
git tree. However, from a make -C redhat/ command it is executed from the
redhat/ path. This breaks the script when it needs to generate new configs
(redhat/gen_config_patches.sh).
A simple fix is
From: Don Zickus
This in spirit reverts 0409b218390b564c44dd0181c5d0fe177d4c6bc3
and converts the broken out Red Hat patches back into a single diff.
The original idea was to make it easy for the Fedora community to see
what changes Red Hat was making on top of upstream's tarball. The
concept
From: Don Zickus
Now that the merge-upstream stage is separated and working, let's
remove it from the release stage. These scripts are already excuted by the
'merge-upstream' stage. This changes just removes the duplication. Trivial
change.
Signed-off-by: Don Zickus
---
From: Don Zickus
A source git tree's workflow and Fedora's separation of upstream and distro
contributions don't overlap well.
A source git tree is always merging upstream content and downstream content
while avoiding a rebase. By separating the tarballs and patches out, this
effectively
From: Don Zickus
I updated the release code to include more changelog info
in the os-build branch. This resulted in adding upstream
merge commits. This is not interesting for a Fedora tree
as it is covered by a generic 'merge' entry.
Use a simple git trick to filter those upstream commits
From: Don Zickus
As part of splitting the merge-upstream and release stages apart,
the merge upstream wasn't working quite right. These are cleanup
fixes to fix that.
The main change is to drop the ark rebase patches script. Running
that through a Makefile through gitlab CI creates a funky
From: Don Zickus
Signed-off-by: Don Zickus
---
redhat/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/redhat/Makefile b/redhat/Makefile
index 4b64f96d0024..d36ce7450073 100644
--- a/redhat/Makefile
+++ b/redhat/Makefile
@@ -335,6 +335,7 @@ dist-merge-upstream: git-tree-check
From: Don Zickus
Currently, ark-latest is built, version bumped and the gitlab-ci.yml
file secretly copies that changelog back to os-build.
I think we can improve that process, but it requires a change in
the release behaviour, version bump os-build first, then create
ark-latest and version
From: Don Zickus
This is a target that will create the rawhide branch, ark-latest.
It is mostly copied from the gitlab-ci.yml and turned into a
Makefile target for easier understanding and execution.
An optimization is to move some of the duplicate code to
git-tree-check and replace git-status
From: Don Zickus
The dist-release target allows the caller to repeatedly bump
the version in Makefile.rhelver, even though no changes was
added.
Change this behaviour to _only_ bump the version when either
a changelog entry was detected or the marker file was updated,
otherwise skip the version
From: Don Zickus
Today ark-latest is built by starting with ark-patches, merging
os-build and applying 'extra' patches from gitlab, and finally
tagged.
In preparation for a single tree workflow where ark-patches disappears,
lets swap the process to make it easier for ark-patches to be
removed.
From: dzickusrh on gitlab.com
This patchset tweaks how the fedora rawhide release process works in
preparation for the single tree workflow.
The end result of these small changes in behaviour is converting to a
single tree becomes trivial and just a simple merge of the ark-patches
branch and an
From: Don Zickus
I would like to use the TAG variable as input to the make merge and
release targets. This allows the maintainer to control where the
merge or release starts from.
The internal variable TAG conflicts with this when the external TAG
is empty. The Makefile accidentally chooses
From: Don Zickus
Back with commit 3a65b42715c1286fc452df4093ce216eae140b3c, make
dist-git was changed to depend on dist-srpm instead of the spec
file. As a result some legacy optimizations are now redundant,
remove them.
In dist-git, dist-srpm depends on TARBALL, so remove the explict
From: Don Zickus
The dist-release target allows the caller to repeatedly bump
the version in Makefile.rhelver, even though no changes was
added.
Change this behaviour to _only_ bump the version when either
a changelog entry was detected or the marker file was updated,
otherwise skip the version
From: Don Zickus
Today ark-latest is built by starting with ark-patches, merging
os-build and applying 'extra' patches from gitlab, and finally
tagged.
In preparation for a single tree workflow where ark-patches disappears,
lets swap the process to make it easier for ark-patches to be
removed.
From: Don Zickus
Back with commit 3a65b42715c1286fc452df4093ce216eae140b3c, make
dist-git was changed to depend on dist-srpm instead of the spec
file. As a result some legacy optimizations are now redundant,
remove them.
In dist-git, dist-srpm depends on TARBALL, so remove the explict
From: Don Zickus
Currently, ark-latest is built, version bumped and the gitlab-ci.yml
file secretly copies that changelog back to os-build.
I think we can improve that process, but it requires a change in
the release behaviour, version bump os-build first, then create
ark-latest and version
From: Don Zickus
This is a target that will create the rawhide branch, ark-latest.
It is mostly copied from the gitlab-ci.yml and turned into a
Makefile target for easier understanding and execution.
An optimization is to move some of the duplicate code to
git-tree-check and replace git-status
From: dzickusrh on gitlab.com
This patchset tweaks how the fedora rawhide release process works in
preparation for the single tree workflow.
The end result of these small changes in behaviour is converting to a
single tree becomes trivial and just a simple merge of the ark-patches
branch and an
From: Don Zickus
I would like to use the TAG variable as input to the make merge and
release targets. This allows the maintainer to control where the
merge or release starts from.
The internal variable TAG conflicts with this when the external TAG
is empty. The Makefile accidentally chooses
From: Don Zickus
Currently all the magic to sync upstream with os-build and ark-patches
is done through scripts in redhat/scripts/ci and .gitlab-ci.yml.
Make this easier by enabling this routine through a redhat/Makefile.
This allows:
* gitlab-ci.yml and maintainer to use same script
* allows
From: Don Zickus
Avoid constantly running the config update scripts when the merge to
master did not update anything. This means there can be no new
configs to generate.
Same argument for ark-patches.
The only downside I see with this check is if the generate config
scripts fail and this
From: Don Zickus
As a step towards switching away from the os-build branch start by
using more variables.
The patch does 2 things:
* adds a use of PROJECT_ID
* replace os-build with BRANCH in the update configs script
Signed-off-by: Don Zickus
---
redhat/scripts/ci/ark-create-release.sh | 2
From: Don Zickus
In 5.8-rc1, a change was made to not always generate a Module.symvers
file if no modules were built. The s390x zfcpdump variant is a kernel
that is built with no modules enabled.
The kernel.spec file assumes Module.symvers always exists and fails to
build the zfcpdump variant.
From: Don Zickus
I was playing around with SINGLE_TARBALL=1 to workaround an issue and
noticed the patch for breaking out individual patches did not account
for that scenario.
The srpm fails to generate due to the missing Patchlist file, which
is used to track the individual patch files.
Fix
From: Don Zickus
I am not sure why the version number is bumped for rc0, but it causes
the rpm to build with the wrong version number. This puts the kernel
modules in the wrong directory and the booted kernel can't find them.
For example, currently the 5.8-rc1 merge window has 5.7.0 in the top
From: Don Zickus
The kernel workflow is adding complexity. Let's hide some of that complexity
behind git aliases. Instead of having the developer manually add them all
the time, add a make command to 'include' kernel aliases.
A new command 'make rh-gitsetup' runs
git config --local --add
From: Don Zickus
Upstream status: RHEL only
The function rh_check_supported is a RHEL function to limit the
platforms RHEL does not want to support.
To avoid imposing this requirement on Fedora, the function was
wrapped with CONFIG_RHEL_DIFFERENCES so Fedora can disable this.
However, this
From: Don Zickus
Upstream status: RHEL only
The variable x86_hyper_type is hidden behind a macro and not available
when guest mode is not config'd enabled.
Update to use hypervisor_is_type() macro, available since
commit 79cc74155218316b9a5d28577c7077b2adba8e58
Author: Thomas Gleixner
Date:
From: dzickusrh on gitlab.com
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List
From: Don Zickus
Upstream status: RHEL only
The function rh_check_supported is a RHEL function to limit the
platforms RHEL does not want to support.
To avoid imposing this requirement on Fedora, the function was
wrapped with CONFIG_RHEL_DIFFERENCES so Fedora can disable this.
However, this
From: dzickusrh on gitlab.com
Note:
The patch series is too large to sent by email.
To review the series locally, set up your repository to fetch from the GitLab
remote:
$ git remote add gitlab https://gitlab.com/cki-project/kernel-ark.git
$ git config remote.gitlab.fetch
From: Don Zickus
The kernel workflow is adding complexity. Let's hide some of that complexity
behind git aliases. Instead of having the developer manually add them all
the time, add a make command to 'include' kernel aliases.
A new command 'make rh-gitsetup' runs
git config --local --add
From: Don Zickus
ARK used to build against the RHEL-8 buildroots. Going forward,
it will build against the ELN buildroot (Fedora space). Adjust
the spec file to handle these changes.
This change still builds under RHEL-8 as llvm-toolset was a meta
package for clang and llvm.
V2: Remove
From: Don Zickus
The kernel workflow is adding complexity. Let's hide some of that complexity
behind git aliases. Instead of having the developer manually add them all
the time, add a make command to 'include' kernel aliases.
A new command 'make rh-gitconfig' runs
git config --local --add
From: Don Zickus
The kernel workflow is adding complexity. Let's hide some of that complexity
behind git aliases. Instead of having the developer manually add them all
the time, add a make command to 'include' kernel aliases.
A new command 'make rh-gitconfig' runs
git config --local --add
From: Don Zickus
The kernel workflow is adding complexity. Let's hide some of that complexity
behind git aliases. Instead of having the developer manually add them all
the time, add a make command to 'include' kernel aliases.
A new command 'make rh-gitconfig' runs
git config --local --add
From: Don Zickus
ARK used to build against the RHEL-8 buildroots. Going forward,
it will build against the ELN buildroot (Fedora space). Adjust
the spec file to handle these changes.
Still try to support RHEL-8 where possible. That is why the
llvm-toolset is wrapped with el8. This is useful
58 matches
Mail list logo
