[OS-BUILD PATCH] redhat: add documentation about the os-build rebase process
From: Herton R. Krzesinski redhat: add documentation about the os-build rebase process We have been rebasing os-build lately on each new major Linux upstream release. Add general instructions/guideline on how to do the rebase process on top of last upstream tag/commit. Signed-off-by: Herton R. Krzesinski diff --git a/redhat/docs/maintaining.rst b/redhat/docs/maintaining.rst index blahblah..blahblah 100644 --- a/redhat/docs/maintaining.rst +++ b/redhat/docs/maintaining.rst @@ -128,6 +128,58 @@ above Fedora build. To kick off manually run +Rebasing + + +When a new major version of Linux is released upstream, we can rebase the +os-build branch. Keeping the process of merging from upstream without rebases +might make a future rebase more time consuming or harder to do, due growing +number of conflicts which happens with the ever growing changing of the tree, +which makes this periodic rebasing more desirable, and moves any needed conflict +resolution back into our patches on top of upstream and not on upstream merges +only. + +To do the os-build rebase, the following steps can be done: + +:: + + # Create a rebase branch from latest os-build branch and start the process + # For any conflicts that arise, check and fix them, following git instructions + git fetch origin + git checkout -b rebase origin/os-build + marker=$(cat redhat/marker) + git rebase $marker + + # After you finish the rebase, check the results against the current os-build + git diff origin/os-build.. + # If there are differences shown, you might have fixed conflicts wrongly or + # in a different way. To fix, you may want to add extra on top commits and + # rebase again interactively +&& git add + # create dummy commit + git commit + # You may need to create more than one commit, if changes are related to + # more than one previous commit. Then squash commits into the existing + # previous commits related to the change with: + git rebase -i $marker + + # Now cleanup any commits that we might have reverted, and release commits. + # When editor opens with the commit list in interactive mode, search for any + # commits starting with "Revert " in the subject and if they match a previous + # commit which is being reverted, you can remove both. For release commits, + # search commits with subject starting with "[redhat] kernel-" and delete/ + # remove them. + git rebase -i $marker + + # Check results again doing a diff against os-build branch. Because of cleanup + # in the previous step, some differences will appear now, and that's ok + # because of the removal of the release commits. The only differences that + # should appear are on Makefile.rhelver, redhat/kernel.changelog and + # redhat/marker + git diff origin/os-build.. + + # If differences shown are expected, we are ok and rebase is done. + :: TODO FILL ME IN -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1387 ___ 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 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
Re: [OS-BUILD PATCH] Enable e1000 in rhel9 as unsupported
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1382#note_679632977 This should be wrapped in CONFIG_RHEL_DIFFERENCES so that it does not impact Fedora. It should probably also use mark_driver_unsupported rather than TAINT_SUPPORT_REMOVED. ___ 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 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
Re: [OS-BUILD PATCH] redhat/configs: enable SYSTEM_BLACKLIST_KEYRING which is already enabled in rhel8 and Fedora 34
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1385#note_679294724 Acked-by: Justin M. Forbes (via approve button) ___ 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 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
❌ FAIL: Test report for kernel 5.13.17-200.fc34 (fedora-34)
Hello, We ran automated tests on the following kernel build: Kernel package: kernel-5.13.17-200.fc34 Task URL: https://koji.fedoraproject.org/koji/taskinfo?taskID=75736884 The results of these automated tests are provided below. Overall result: FAILED (see details below) Tests: FAILED One or more kernel tests failed: ppc64le: ❌ LTP - sched All kernel binaries, config files, and logs are available for download here: https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?prefix=datawarehouse-public/2021/09/16/371564819 Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. For the full detail on our testing procedures, please scroll to the bottom of this message. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' __ Hardware testing We booted each kernel and ran the following tests: aarch64: Host 1: ✅ Boot test ✅ Reboot test ✅ xfstests - ext4 ✅ xfstests - xfs ✅ Storage: swraid mdadm raid_module test ✅ xfstests - btrfs ✅ Storage blktests - blk ✅ Storage blktests - nvme-tcp ✅ Storage blktests - nvmeof-mp ✅ Storage blktests - srp ✅ Storage block - filesystem fio test ✅ Storage block - queue scheduler test ✅ storage: software RAID testing ✅ stress: stress-ng Host 2: ✅ Boot test ✅ Reboot test ✅ ACPI table test ✅ LTP - cve ✅ LTP - sched ✅ LTP - syscalls ✅ LTP - can ✅ LTP - commands ✅ LTP - containers ✅ LTP - dio ✅ LTP - fs ✅ LTP - fsx ✅ LTP - math ✅ LTP - hugetlb ✅ LTP - mm ✅ LTP - nptl ✅ LTP - pty ✅ LTP - ipc ✅ LTP - tracing ✅ CIFS Connectathon ✅ Loopdev Sanity ✅ Memory: fork_mem ✅ Memory function: memfd_create ✅ AMTU (Abstract Machine Test Utility) ✅ Ethernet drivers sanity ✅ xarray-idr-radixtree-test ✅ NFS Connectathon ppc64le: Host 1: ✅ Boot test ✅ Reboot test ✅ LTP - cve ❌ LTP - sched ✅ LTP - syscalls ✅ LTP - can ✅ LTP - commands ✅ LTP - containers ✅ LTP - dio ✅ LTP - fs ✅ LTP - fsx ✅ LTP - math ✅ LTP - hugetlb ✅ LTP - mm ✅ LTP - nptl ✅ LTP - pty ✅ LTP - ipc ✅ LTP - tracing ✅ CIFS Connectathon ✅ Loopdev Sanity ✅ Memory: fork_mem ✅ Memory function: memfd_create ✅ AMTU (Abstract Machine Test Utility) ✅ Ethernet drivers sanity ✅ xarray-idr-radixtree-test ✅ NFS Connectathon Host 2: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ✅ Boot test ✅ Reboot test ✅ xfstests - ext4 ✅ xfstests - xfs ✅ Storage: swraid mdadm raid_module test ✅ xfstests - btrfs ✅ Storage blktests - blk ✅ Storage blktests - nvme-tcp ✅ Storage blktests - nvmeof-mp ⚡⚡⚡ Storage blktests - srp ⚡⚡⚡ Storage block - filesystem fio test ⚡⚡⚡ Storage block - queue scheduler test ⚡⚡⚡ Storage: lvm device-mapper test - upstream ⚡⚡⚡ storage: software RAID testing s390x: Host 1: ✅ Boot test ✅ Reboot test ✅ Storage: swraid mdadm raid_module test ✅ Storage blktests - blk ✅ Storage blktests - nvme-tcp ✅ Storage blktests - nvmeof-mp Storage blktests - srp ⚡⚡⚡ stress: stress-ng Host 2: ✅ Boot test ✅ Reboot test ✅ LTP - cve ✅ LTP - sched ✅ LTP - syscalls ✅ LTP - can ✅ LTP - commands ✅ LTP - containers ✅ LTP - dio ✅ LTP - fs ✅ LTP - fsx ✅ LTP - math ✅ LTP - hugetlb ✅ LTP - mm ✅ LTP - nptl ✅ LTP - pty ✅ LTP - ipc ✅ LTP - tracing ✅ CIFS Connectathon ✅ Loopdev Sanity ✅ Memory: fork_mem ✅ Memory function: memfd_create ✅ AMTU (Abstract Machine Test Utility) ✅ Ethernet drivers sanity ❌ xarray-idr-radixtree-test ✅ NFS Connectathon x86_64: Host 1: ✅ Boot test ✅ Reboot test ✅ ACPI table test ✅ LTP - cve ✅ LTP - sched ✅ LTP - syscalls ✅ LTP - can ✅ LTP - commands ✅ LTP - containers ✅ LTP - dio ✅ LTP - fs ✅ LTP - fsx ✅ LTP - math ✅ LTP - hugetlb ✅ LTP - mm ✅ LTP - nptl ✅ LTP - pty ✅ LTP - ipc
Re: [OS-BUILD PATCH] redhat/configs: enable SYSTEM_BLACKLIST_KEYRING which is already enabled in rhel8 and Fedora 34
From: Ondrej Mosnáček on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1385#note_678987603 Acked-by: Ondrej Mosnáček (via approve button) ___ 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 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
