From: 小田喜陽彦 on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2105 NOTE: Truncated patchset due to missing public @redhat.com email address on your GitLab profile at https://gitlab.com/-/profile. Once that is fixed, close and reopen the merge request to retrigger sending the emails.
This reverts commit 54c43855f14951c610ce71cb500f024cf7a51ac6.
Unfortunately `git apply` only works in a Git tree, and the tarball `redhat/scripts/create-tarball.sh` creates does not contain a Git repository.
Upstream Status: RHEL only Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
--- redhat/genspec.sh | 3 ++- redhat/kernel.spec.template | 4 ++-- 2 files changed, 4 insertions(+), 3 deletions(-)
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2105#note_1137086...
Thanks for finding this, I was just trying to figure out why an issue was popping up in the 6.0 test week.
From: Ondrej Mosnáček on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2105#note_1137494...
Unfortunately `git apply` only works in a Git tree, and the tarball
`redhat/scripts/create-tarball.sh` creates does not contain a Git repository.
Where did you get that from? `git-apply(1)` says:
With the --index option the patch is also applied to the index, and with the
--cached option the patch is only applied to the index. Without these options, the command applies the patch only to files, and **does not require them to be in a Git repository**.
Also if I clone a dummy repo, create a patch, then remove the `.git` directory, I am able to apply the patch with `git apply` without an issue (all on Fedora 36 with `git-2.37.3-1.fc36.x86_64`). Can you share more details on what issue you observed? Can you share an SRPM that triggers the issue?
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2105#note_1137946...
The issue I observed is that after a "fedpkg prep" there is no error around git-apply, but the patch itself is not applied. This is actually quite visible in the fact that we have some config options which are invalid without patches that we carry. So the current rawhide dist-git, a `fedpkg --release eln prep` from the current rawhide dist-git will complain that:
``` Error: Mismatches found in configuration files for powerpc ppc64le Found CONFIG_IO_URING=y after generation, had CONFIG_IO_URING=is not set in Source tree ```
This is because the patch b8ad8a5cb7f8c which allows IO_URING to be turned off without CONFIG_EXPERT is not applied, but you can just as easily select any change line in patch-6.1-redhat.patch and look at the "prepared tree" to see that it is not applied.
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2105#note_1137974...
Interestingly, if I switch into that directory, and try to git apply manually, it doesn't complain at all, but doesn't apply. git apply --verbose shows that it skips every patch.
``` ~/git/kernel/rawhide/kernel-6.0-11990-g9c9155a3509a/linux-6.1.0-0.rc0.20221014 git9c9155a3509a.11.eln122.x86_64 (rawhide)]>git apply --verbose ../../patch-6.1-redhat.patch Skipped patch 'Documentation/admin-guide/kernel-parameters.txt'. Skipped patch 'Kconfig'. Skipped patch 'Kconfig.redhat'. Skipped patch 'Makefile'. Skipped patch 'arch/arm/Kconfig'. Skipped patch 'arch/arm64/Kconfig'. Skipped patch 'arch/arm64/kernel/acpi.c'. Skipped patch 'arch/s390/include/asm/ipl.h'. Skipped patch 'arch/s390/kernel/ipl.c'. Skipped patch 'arch/s390/kernel/setup.c'. Skipped patch 'arch/x86/kernel/cpu/common.c'. Skipped patch 'arch/x86/kernel/setup.c'. Skipped patch 'drivers/acpi/apei/hest.c'. ``` Which continues. Of course inspecting the files, the patches are not already applied.
From: Ondrej Mosnáček on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2105#note_1137994...
Oh, I think I know what is going on now... Git searches all the parent directories looking for the first one containing `.git` and tries to apply the patch there. In the case of local `%prep` it finds the dist-git's `.git` and ends up trying to apply the patch there instead of the current directory. Setting `patch_command` to `git --git-dir=. apply` fixes it on my end.
From: Ondrej Mosnáček on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2105#note_1138000...
Correction: `--work-tree=.` would be more correct. While `--git-dir` also works, it specifies the path to the `.git` directory, not the "repository" root dir, which is what we really want to set.
From: Ondrej Mosnáček on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2105#note_1138076...
I opened !2107 with the `--work-tree` fix.
From: 小田喜陽彦 on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2105#note_1138090...
It seems the more correct way to fix the issue. Thanks for the careful review and better fix.
kernel@lists.fedoraproject.org