Skip to content

Conversation

@PlaidCat
Copy link
Collaborator

This is the attempt at a re-builder built on Cron and some internal tools, but the same process is as follows as previous rebuilds

  • Download all unprocessed src.rpm
  • for each src,pm
    • Find all commits in changelog up to last known tag ... in this case 5.14.0-570
    • Re-play commits in reverse order (oldest in change log to newest) with git cherry-pick
    • After replay replace ENTIRE code in branch with rpmbuild -bp from corresponding src.rpm.
    • Tag Rebuild branch

Rebuild Splat Inspection

kernel-5.14.0-570.58.1.el9_6

[jmaple@devbox kernel-src-tree]$ cat ciq/ciq_backports/kernel-5.14.0-570.58.1.el9_6/rebuild.details.txt
Rebuild_History BUILDABLE
Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50%
Number of commits in upstream range v5.14~1..kernel-mainline: 324124
Number of commits in rpm: 20
Number of commits matched with upstream: 14 (70.00%)
Number of commits in upstream but not in rpm: 324110
Number of commits NOT found in upstream: 6 (30.00%)

Rebuilding Kernel on Branch rocky9_6_rebuild_kernel-5.14.0-570.58.1.el9_6 for kernel-5.14.0-570.58.1.el9_6
Clean Cherry Picks: 14 (100.00%)
Empty Cherry Picks: 0 (0.00%)
_______________________________

__EMPTY COMMITS__________________________

__CHANGES NOT IN UPSTREAM________________
Porting to Rocky Linux 9, debranding and Rocky branding'
Ensure aarch64 kernel is not compressed'
smb: client: fix wrong index reference in smb2_compound_op()
smb: client: handle unlink(2) of files open by different clients
smb: client: fix file open check in __cifs_unlink()
smb: client: fix filename matching of deferred files
========================================
Timing Summary:
  auto_history_rebuild.sh: 4m 28s
  history_rebuild_orchestration.sh: 54m 30s
  Total execution time: 58m 58s
========================================

Build

[jmaple@devbox code]$ egrep -B 5 -A 5 "\[TIMER\]|^Starting Build" $(ls -t kbuild* | head -n1)
/mnt/code/kernel-src-tree-build
Running make mrproper...
  CLEAN   scripts/basic
  CLEAN   scripts/kconfig
  CLEAN   include/config include/generated
[TIMER]{MRPROPER}: 5s
x86_64 architecture detected, copying config
'configs/kernel-x86_64-rhel.config' -> '.config'
Setting Local Version for build
CONFIG_LOCALVERSION="-rocky9_6_rebuild-d852b554e1b6"
Making olddefconfig
--
  HOSTCC  scripts/kconfig/util.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
Starting Build
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_64.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_32.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_x32.h
  SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
  SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h
--
  LD [M]  sound/xen/snd_xen_front.ko
  BTF [M] sound/usb/usx2y/snd-usb-usx2y.ko
  BTF [M] sound/virtio/virtio_snd.ko
  BTF [M] sound/x86/snd-hdmi-lpe-audio.ko
  BTF [M] sound/xen/snd_xen_front.ko
[TIMER]{BUILD}: 1513s
Making Modules
  INSTALL /lib/modules/5.14.0-rocky9_6_rebuild-d852b554e1b6/kernel/arch/x86/crypto/blake2s-x86_64.ko
  INSTALL /lib/modules/5.14.0-rocky9_6_rebuild-d852b554e1b6/kernel/arch/x86/crypto/blowfish-x86_64.ko
  INSTALL /lib/modules/5.14.0-rocky9_6_rebuild-d852b554e1b6/kernel/arch/x86/crypto/camellia-aesni-avx-x86_64.ko
  INSTALL /lib/modules/5.14.0-rocky9_6_rebuild-d852b554e1b6/kernel/arch/x86/crypto/camellia-aesni-avx2.ko
--
  SIGN    /lib/modules/5.14.0-rocky9_6_rebuild-d852b554e1b6/kernel/sound/x86/snd-hdmi-lpe-audio.ko
  SIGN    /lib/modules/5.14.0-rocky9_6_rebuild-d852b554e1b6/kernel/sound/virtio/virtio_snd.ko
  SIGN    /lib/modules/5.14.0-rocky9_6_rebuild-d852b554e1b6/kernel/sound/xen/snd_xen_front.ko
  SIGN    /lib/modules/5.14.0-rocky9_6_rebuild-d852b554e1b6/kernel/sound/usb/usx2y/snd-usb-usx2y.ko
  DEPMOD  /lib/modules/5.14.0-rocky9_6_rebuild-d852b554e1b6
[TIMER]{MODULES}: 10s
Making Install
sh ./arch/x86/boot/install.sh 5.14.0-rocky9_6_rebuild-d852b554e1b6 \
        arch/x86/boot/bzImage System.map "/boot"
[TIMER]{INSTALL}: 21s
Checking kABI
kABI check passed
Setting Default Kernel to /boot/vmlinuz-5.14.0-rocky9_6_rebuild-d852b554e1b6 and Index to 0
Hopefully Grub2.0 took everything ... rebooting after time metrices
[TIMER]{MRPROPER}: 5s
[TIMER]{BUILD}: 1513s
[TIMER]{MODULES}: 10s
[TIMER]{INSTALL}: 21s
[TIMER]{TOTAL} 1555s
Rebooting in 10 seconds

KSelfTests

[jmaple@devbox code]$ ~/workspace/auto_kernel_history_rebuild/Rocky10/rocky10/code/get_kselftest_diff.sh
kselftest.5.14.0-jmaple_fips-9-compliant_5.14.0-570.52.1.el9_6-e165cc8+.log
315
kselftest.5.14.0-rocky9_6_rebuild-e9f8d0801b38.log
320
kselftest.5.14.0-rocky9_6_rebuild-fd38949dcaa2.log
320
kselftest.5.14.0-rocky9_6_rebuild-d852b554e1b6.log
320
Before: kselftest.5.14.0-rocky9_6_rebuild-fd38949dcaa2.log
After: kselftest.5.14.0-rocky9_6_rebuild-d852b554e1b6.log
Diff:
-ok 7 selftests: timers: raw_skew # SKIP
+ok 7 selftests: timers: raw_skew

jira LE-4603
Rebuild_History Non-Buildable kernel-5.14.0-570.58.1.el9_6
commit-author Ming Lei <ming.lei@redhat.com>
commit 26064d3

>4GB folio is possible on some ARCHs, such as aarch64, 16GB hugepage
is supported, then 'offset' of folio can't be held in 'unsigned int',
cause warning in bio_add_folio_nofail() and IO failure.

Fix it by adjusting 'page' & trimming 'offset' so that `->bi_offset` won't
be overflow, and folio can be added to bio successfully.

Fixes: ed9832b ("block: introduce folio awareness and add a bigger size from folio")
	Cc: Kundan Kumar <kundan.kumar@samsung.com>
	Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
	Cc: Christoph Hellwig <hch@lst.de>
	Cc: Luis Chamberlain <mcgrof@kernel.org>
	Cc: Gavin Shan <gshan@redhat.com>
	Signed-off-by: Ming Lei <ming.lei@redhat.com>
	Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Link: https://lore.kernel.org/r/20250312145136.2891229-1-ming.lei@redhat.com
	Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 26064d3)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4603
Rebuild_History Non-Buildable kernel-5.14.0-570.58.1.el9_6
commit-author Wengang Wang <wen.gang.wang@oracle.com>
commit 58f8807

A user with a completely full filesystem experienced an unexpected
shutdown when the filesystem tried to write the superblock during
runtime.
kernel shows the following dmesg:

[    8.176281] XFS (dm-4): Metadata corruption detected at xfs_sb_write_verify+0x60/0x120 [xfs], xfs_sb block 0x0
[    8.177417] XFS (dm-4): Unmount and run xfs_repair
[    8.178016] XFS (dm-4): First 128 bytes of corrupted metadata buffer:
[    8.178703] 00000000: 58 46 53 42 00 00 10 00 00 00 00 00 01 90 00 00  XFSB............
[    8.179487] 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[    8.180312] 00000020: cf 12 dc 89 ca 26 45 29 92 e6 e3 8d 3b b8 a2 c3  .....&E)....;...
[    8.181150] 00000030: 00 00 00 00 01 00 00 06 00 00 00 00 00 00 00 80  ................
[    8.182003] 00000040: 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 82  ................
[    8.182004] 00000050: 00 00 00 01 00 64 00 00 00 00 00 04 00 00 00 00  .....d..........
[    8.182004] 00000060: 00 00 64 00 b4 a5 02 00 02 00 00 08 00 00 00 00  ..d.............
[    8.182005] 00000070: 00 00 00 00 00 00 00 00 0c 09 09 03 17 00 00 19  ................
[    8.182008] XFS (dm-4): Corruption of in-memory data detected.  Shutting down filesystem
[    8.182010] XFS (dm-4): Please unmount the filesystem and rectify the problem(s)

When xfs_log_sb writes super block to disk, b_fdblocks is fetched from
m_fdblocks without any lock. As m_fdblocks can experience a positive ->
negative -> positive changing when the FS reaches fullness (see
xfs_mod_fdblocks). So there is a chance that sb_fdblocks is negative, and
because sb_fdblocks is type of unsigned long long, it reads super big.
And sb_fdblocks being bigger than sb_dblocks is a problem during log
recovery, xfs_validate_sb_write() complains.

Fix:
As sb_fdblocks will be re-calculated during mount when lazysbcount is
enabled, We just need to make xfs_validate_sb_write() happy -- make sure
sb_fdblocks is not nenative. This patch also takes care of other percpu
counters in xfs_log_sb.

	Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
	Reviewed-by: Darrick J. Wong <djwong@kernel.org>
	Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
(cherry picked from commit 58f8807)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4603
Rebuild_History Non-Buildable kernel-5.14.0-570.58.1.el9_6
commit-author Benjamin Coddington <bcodding@redhat.com>
commit 9976523

If the NFS client is doing writeback from a workqueue context, avoid using
__GFP_NORETRY for allocations if the task has set PF_MEMALLOC_NOIO or
PF_MEMALLOC_NOFS.  The combination of these flags makes memory allocation
failures much more likely.

We've seen those allocation failures show up when the loopback driver is
doing writeback from a workqueue to a file on NFS, where memory allocation
failure results in errors or corruption within the loopback device's
filesystem.

	Suggested-by: Trond Myklebust <trondmy@kernel.org>
Fixes: 0bae835 ("NFS: Avoid writeback threads getting stuck in mempool_alloc()")
	Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
	Reviewed-by: Laurence Oberman <loberman@redhat.com>
	Tested-by: Laurence Oberman <loberman@redhat.com>
	Reviewed-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/f83ac1155a4bc670f2663959a7a068571e06afd9.1752111622.git.bcodding@redhat.com
	Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
(cherry picked from commit 9976523)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4603
cve CVE-2025-39751
Rebuild_History Non-Buildable kernel-5.14.0-570.58.1.el9_6
commit-author Lucy Thrun <lucy.thrun@digital-rabbithole.de>
commit a409c60

The 'sprintf' call in 'add_tuning_control' may exceed the 44-byte
buffer if either string argument is too long. This triggers a compiler
warning.
Replaced 'sprintf' with 'snprintf' to limit string lengths to prevent
overflow.

	Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202506100642.95jpuMY1-lkp@intel.com/
	Signed-off-by: Lucy Thrun <lucy.thrun@digital-rabbithole.de>
Link: https://patch.msgid.link/20250610175012.918-3-lucy.thrun@digital-rabbithole.de
	Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit a409c60)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4603
cve CVE-2025-39819
Rebuild_History Non-Buildable kernel-5.14.0-570.58.1.el9_6
commit-author Shuhao Fu <sfual@cse.ust.hk>
commit ab529e6

A possible inconsistent update of refcount was identified in `smb2_compound_op`.
Such inconsistent update could lead to possible resource leaks.

Why it is a possible bug:
1. In the comment section of the function, it clearly states that the
reference to `cfile` should be dropped after calling this function.
2. Every control flow path would check and drop the reference to
`cfile`, except the patched one.
3. Existing callers would not handle refcount update of `cfile` if
-ENOMEM is returned.

To fix the bug, an extra goto label "out" is added, to make sure that the
cleanup logic would always be respected. As the problem is caused by the
allocation failure of `vars`, the cleanup logic between label "finished"
and "out" can be safely ignored. According to the definition of function
`is_replayable_error`, the error code of "-ENOMEM" is not recoverable.
Therefore, the replay logic also gets ignored.

	Signed-off-by: Shuhao Fu <sfual@cse.ust.hk>
	Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
	Cc: stable@vger.kernel.org
	Signed-off-by: Steve French <stfrench@microsoft.com>
(cherry picked from commit ab529e6)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4603
Rebuild_History Non-Buildable kernel-5.14.0-570.58.1.el9_6
commit-author Paulo Alcantara <pc@manguebit.org>
commit 90f7c10

The encryption layer can't handle the padding iovs, so flatten the
compound request into a single buffer with required padding to prevent
the server from dropping the connection when finding unaligned
compound requests.

Fixes: bc925c1 ("smb: client: improve compound padding in encryption")
	Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
	Reviewed-by: David Howells <dhowells@redhat.com>
	Cc: linux-cifs@vger.kernel.org
	Cc: stable@vger.kernel.org
	Signed-off-by: Steve French <stfrench@microsoft.com>
(cherry picked from commit 90f7c10)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4603
Rebuild_History Non-Buildable kernel-5.14.0-570.58.1.el9_6
commit-author Paulo Alcantara <pc@manguebit.org>
commit c5ea306

Rename of open files in SMB2+ has been broken for a very long time,
resulting in data loss as the CIFS client would fail the rename(2)
call with -ENOENT and then removing the target file.

Fix this by implementing ->rename_pending_delete() for SMB2+, which
will rename busy files to random filenames (e.g. silly rename) during
unlink(2) or rename(2), and then marking them to delete-on-close.

Besides, introduce a FIND_WR_NO_PENDING_DELETE flag to prevent open(2)
from reusing open handles that had been marked as delete pending.
Handle it in cifs_get_readable_path() as well.

	Reported-by: Jean-Baptiste Denis <jbdenis@pasteur.fr>
Closes: https://marc.info/?i=16aeb380-30d4-4551-9134-4e7d1dc833c0@pasteur.fr
	Reviewed-by: David Howells <dhowells@redhat.com>
	Cc: stable@vger.kernel.org
	Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
	Cc: Frank Sorenson <sorenson@redhat.com>
	Cc: Olga Kornievskaia <okorniev@redhat.com>
	Cc: Benjamin Coddington <bcodding@redhat.com>
	Cc: Scott Mayhew <smayhew@redhat.com>
	Cc: linux-cifs@vger.kernel.org
	Signed-off-by: Steve French <stfrench@microsoft.com>
(cherry picked from commit c5ea306)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4603
Rebuild_History Non-Buildable kernel-5.14.0-570.58.1.el9_6
commit-author Trond Myklebust <trond.myklebust@primarydata.com>
commit ce60ab3

We need to be able to track more than 32 attributes per inode.

	Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
	Signed-off-by: Lance Shelton <lance.shelton@hammerspace.com>
	Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
	Reviewed-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/1e3405fca54efd0be7c91c1da77917b94f5dfcc4.1748515333.git.bcodding@redhat.com
	Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
(cherry picked from commit ce60ab3)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4603
Rebuild_History Non-Buildable kernel-5.14.0-570.58.1.el9_6
commit-author Anne Marie Merritt <annemarie.merritt@primarydata.com>
commit 1c7ae2d

Add tracking of the create time (a.k.a. btime) along with corresponding
bitfields, request, and decode xdr routines.

	Signed-off-by: Anne Marie Merritt <annemarie.merritt@primarydata.com>
	Signed-off-by: Lance Shelton <lance.shelton@hammerspace.com>
	Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
	Reviewed-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/1e3677b0655fa2bbaba0817b41d111d94a06e5ee.1748515333.git.bcodding@redhat.com
	Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
(cherry picked from commit 1c7ae2d)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4603
Rebuild_History Non-Buildable kernel-5.14.0-570.58.1.el9_6
commit-author Trond Myklebust <trond.myklebust@hammerspace.com>
commit 4b54274

If the server supports the NFSv4.x "create_time" attribute, then return
it as part of the statx results.

	Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
	Reviewed-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/eae27d6467e08aaa67e0ac6ae7119263a0f83349.1748515333.git.bcodding@redhat.com
	Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
(cherry picked from commit 4b54274)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4603
cve CVE-2025-39730
Rebuild_History Non-Buildable kernel-5.14.0-570.58.1.el9_6
commit-author Trond Myklebust <trond.myklebust@hammerspace.com>
commit ef93a68

The function needs to check the minimal filehandle length before it can
access the embedded filehandle.

	Reported-by: zhangjian <zhangjian496@huawei.com>
Fixes: 20fa190 ("nfs: add export operations")
	Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
(cherry picked from commit ef93a68)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4603
Rebuild_History Non-Buildable kernel-5.14.0-570.58.1.el9_6
commit-author Jonathan Curley <jcurley@purestorage.com>
commit dd2fa82

Typo in ff_lseg_match_mirrors makes the diff ineffective. This results
in merge happening all the time. Merge happening all the time is
problematic because it marks lsegs invalid. Marking lsegs invalid
causes all outstanding IO to get restarted with EAGAIN and connections
to get closed.

Closing connections constantly triggers race conditions in the RDMA
implementation...

Fixes: 660d1eb ("pNFS/flexfile: Don't merge layout segments if the mirrors don't match")
	Signed-off-by: Jonathan Curley <jcurley@purestorage.com>
	Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
(cherry picked from commit dd2fa82)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4603
cve CVE-2025-39718
Rebuild_History Non-Buildable kernel-5.14.0-570.58.1.el9_6
commit-author Will Deacon <will@kernel.org>
commit 0dab924

When receiving a vsock packet in the guest, only the virtqueue buffer
size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately,
virtio_vsock_skb_rx_put() uses the length from the packet header as the
length argument to skb_put(), potentially resulting in SKB overflow if
the host has gone wonky.

Validate the length as advertised by the packet header before calling
virtio_vsock_skb_rx_put().

	Cc: <stable@vger.kernel.org>
Fixes: 71dc9ec ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")
	Signed-off-by: Will Deacon <will@kernel.org>
Message-Id: <20250717090116.11987-3-will@kernel.org>
	Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
	Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
(cherry picked from commit 0dab924)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4603
cve CVE-2023-53331
Rebuild_History Non-Buildable kernel-5.14.0-570.58.1.el9_6
commit-author Enlin Mu <enlin.mu@unisoc.com>
commit fe8c362

After commit 3069637 ("pstore/ram: Do not treat empty buffers as
valid"), initialization would assume a prz was valid after seeing that
the buffer_size is zero (regardless of the buffer start position). This
unchecked start value means it could be outside the bounds of the buffer,
leading to future access panics when written to:

 sysdump_panic_event+0x3b4/0x5b8
 atomic_notifier_call_chain+0x54/0x90
 panic+0x1c8/0x42c
 die+0x29c/0x2a8
 die_kernel_fault+0x68/0x78
 __do_kernel_fault+0x1c4/0x1e0
 do_bad_area+0x40/0x100
 do_translation_fault+0x68/0x80
 do_mem_abort+0x68/0xf8
 el1_da+0x1c/0xc0
 __raw_writeb+0x38/0x174
 __memcpy_toio+0x40/0xac
 persistent_ram_update+0x44/0x12c
 persistent_ram_write+0x1a8/0x1b8
 ramoops_pstore_write+0x198/0x1e8
 pstore_console_write+0x94/0xe0
 ...

To avoid this, also check if the prz start is 0 during the initialization
phase. If not, the next prz sanity check case will discover it (start >
size) and zap the buffer back to a sane state.

Fixes: 3069637 ("pstore/ram: Do not treat empty buffers as valid")
	Cc: Yunlong Xing <yunlong.xing@unisoc.com>
	Cc: stable@vger.kernel.org
	Signed-off-by: Enlin Mu <enlin.mu@unisoc.com>
Link: https://lore.kernel.org/r/20230801060432.1307717-1-yunlong.xing@unisoc.com
[kees: update commit log with backtrace and clarifications]
	Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit fe8c362)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
Rebuild_History BUILDABLE
Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50%
Number of commits in upstream range v5.14~1..kernel-mainline: 324124
Number of commits in rpm: 20
Number of commits matched with upstream: 14 (70.00%)
Number of commits in upstream but not in rpm: 324110
Number of commits NOT found in upstream: 6 (30.00%)

Rebuilding Kernel on Branch rocky9_6_rebuild_kernel-5.14.0-570.58.1.el9_6 for kernel-5.14.0-570.58.1.el9_6
Clean Cherry Picks: 14 (100.00%)
Empty Cherry Picks: 0 (0.00%)
_______________________________

Full Details Located here:
ciq/ciq_backports/kernel-5.14.0-570.58.1.el9_6/rebuild.details.txt

Includes:
* git commit header above
* Empty Commits with upstream SHA
* RPM ChangeLog Entries that could not be matched

Individual Empty Commit failures contained in the same containing directory.
The git message for empty commits will have the path for the failed commit.
File names are the first 8 characters of the upstream SHA
@PlaidCat PlaidCat requested a review from a team October 30, 2025 19:44
@PlaidCat PlaidCat self-assigned this Oct 30, 2025
Copy link
Collaborator

@bmastbergen bmastbergen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥌

@PlaidCat PlaidCat requested a review from a team October 31, 2025 12:21
Copy link

@jdieter jdieter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚢

@PlaidCat PlaidCat merged commit d852b55 into rocky9_6 Nov 3, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants