Hi Fedora users, developers, and friends!
It's time to start thinking about Test Days for Fedora 41.
For anyone who isn't aware, a Test Day is an event usually focused
around IRC for interaction and a Wiki page for instructions and results,
with the aim being to get a bunch of interested users and developers
together to test a specific feature or area of the distribution. You can
run a Test Day on just about anything for which it would be useful to do
some fairly focused testing in 'real time' with a group of testers; it
doesn't have to be code, for instance, we often run Test Days for
l10n/i18n topics. For more information on Test Days, see
https://fedoraproject.org/wiki/QA/Test_Days .
Anyone who wants to can host their own Test Day, or you can request that
the QA group helps you out with organization or any combination of the
two. To propose a Test Day, just file a ticket in fedora-qa pagure - here's
an example https://pagure.io/fedora-qa/issue/624 . For
instructions on hosting a Test Day, see
https://fedoraproject.org/wiki/QA/SOP_Test_Day_management .
You can see the schedule at https://pagure.io/fedora-qa/issues?tags=test+days .
There are many slots open right now. Consider the development
schedule, though, in deciding when you want to run your Test Day - for
some topics you may want to avoid
the time before the Beta release or the time after the feature freeze
or the Final Freeze.
We normally aim to schedule Test Days on Thursdays; however, if you want
to run a series of related Test Days, it's often a good idea to do
something like Tuesday / Wednesday / Thursday of the same week (this is
how we usually run the X Test Week, for instance). If all the Thursday
slots fill up but more people want to run Test Days, we will open up
Tuesday slots as overflows. And finally, if you really want to run a
Test Day in a specific time frame due to the development schedule, but
the Thursday slot for that week is full, we can add a slot on another
day. We're flexible! Just put in your ticket the date or time frame you'd
like, and we'll figure it out from there.
If you don't want to run your own Test Day, but you are willing to
help with another, feel free to join one or more of already accepted
Test Days:
GNOME Test Day*
i18n Test Day*
Kernel Test Week(s)*
Upgrade Test Day*
IoT Test Week*
Cloud Test Day*
Fedora CoreOS Test Week*
And don't be afraid, there are a lot of more slots available for your
own Test Day!
[*] These are the test days we run generally to make sure everything
is working fine, the dates get announced as we move into the release
cycle.
If you have any questions about the Test Day process, please don't
hesitate to contact me or any member of the Fedora QA team on test at
lists.fedoraproject.org or in #fedora-qa on IRC. Thanks!
--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
From: Ricardo Robaina on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3070
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.
JIRA: https://issues.redhat.com/browse/RHEL-32987
rh_flags is a mechanism that allows tracking usage of specific kernel
features.
The list of used features is accessible via procfs and is printed in panic
messages. It's meant to provide better customer support making possible for
support engineers to be able to see what specific features were used and steer
the support accordingly.
Ricardo Robaina (11):
add support for rh_features
add rh_features to /proc
rh_features: convert to atomic allocation
rh_features: move rh_features entry to sys/kernel
kernel: rh_features: fix reading empty feature list from /proc
rh_flags: Rename rh_features to rh_flags
rh_flags: Replace strlcpy with strscpy
rh_flags: Replace register_sysctl_table with register_sysctl
rh_flags: Remove unused __read_mostly variable
rh_flags: Hide rh_print_flags call behind CONFIG_RHEL_DIFFERENCES
rh_flags: Move rh_flags.o to obj-$(CONFIG_RHEL_DIFFERENCES) line
include/linux/rh_flags.h | 34 +++++++++++
kernel/Makefile | 2 +-
kernel/module/main.c | 6 ++
kernel/rh_flags.c | 119 +++++++++++++++++++++++++++++++++++++++
4 files changed, 160 insertions(+), 1 deletion(-)
create mode 100644 include/linux/rh_flags.h
create mode 100644 kernel/rh_flags.c
Signed-off-by: Ricardo Robaina <rrobaina(a)redhat.com>
From: Eric Chanudet on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3055
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.
Attend the following warning introduced by a downstream change:
```
drivers/scsi/sd.c:121:20: error: ‘sd_probe_types’ defined but not used
[-Werror=unused-variable]
121 | static const char *sd_probe_types[] = { "async", "sync" };
| ^~~~~~~~~~~~~~
```
Fixes: bc573390ad32 ("scsi: sd: Add "probe_type" module parameter to allow
synchronous probing")
Signed-off-by: Eric Chanudet <echanude(a)redhat.com>
---
drivers/scsi/sd.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
From: Jan Stancek <jstancek(a)redhat.com>
redhat/kernel.spec: _buildvars_variant
This introduces a new macro that allows to override
variant/config to use for standalone tools/tests build.
In SPEC, we support building standalone tools and selftests.
Main user are CKI pipelines, which run a native build.
Over time however, selftests introduced also kmods, so
picking a correct config now matters as well.
This patch allows CKI (or other users) to pick a variant
when doing standalone tools/tests build. Nothing is changing
for builds that include kernel build.
Signed-off-by: Jan Stancek <jstancek(a)redhat.com>
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100644
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -217,6 +217,12 @@ Summary: The Linux kernel
# arm64_64k X X X
# realtime X X X
+# _buildvars_variant - kernel variant used to initialise build variables
+# This variable allows to set variant (and config) that is used when building
+# standalone tools and/or tests (with no kernel and no modules).
+# See variant parameter to BuildKernel() function.
+%define buildvars_variant %{?_buildvars_variant}%{nil}
+
# kernel-doc
%define with_doc %{?_without_doc: 0} %{?!_without_doc: 1}
# kernel-headers
@@ -2809,10 +2815,11 @@ BuildKernel %make_target %kernel_image %{_use_vdso}
%ifnarch noarch i686 %{nobuildarches}
%if !%{with_debug} && !%{with_zfcpdump} && !%{with_up} && !%{with_arm64_16k} && !%{with_arm64_64k} && !%{with_realtime}
-# If only building the user space tools, then initialize the build environment
-# and some variables so that the various userspace tools can be built.
+# If only building the user space tools or selftests, then initialize
+# the build environment and some variables so that the various userspace
+# tools can be built.
%{log_msg "Initialize userspace tools build environment"}
-InitBuildVars
+InitBuildVars %{buildvars_variant}
# Some tests build also modules, and need Module.symvers
if ! [[ -e Module.symvers ]] && [[ -f $DevelDir/Module.symvers ]]; then
%{log_msg "Found Module.symvers in DevelDir, copying to ."}
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3089
Hi, we tested your kernel and here are the results:
Overall result: PASSED
Merge: OK
Compile: OK
Test: OK
Tested-by: CKI Project <cki-project(a)redhat.com>
Kernel information:
Brew / Koji Task ID: 117162762
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:koji-117162762
One or more kernel tests failed:
We also see the following known issues which are not related to your changes:
Issue: NFS Connectathon: SELinux prevents rpcbind
URL: https://bugzilla.redhat.com/1758147
Affected tests:
Filesystem - NFS Connectathon [x86_64]
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
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.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
From: Xin Long <lxin(a)redhat.com>
redhat/rhel_files: move tipc.ko and tipc_diag.ko to modules-extra
JIRA: https://issues.redhat.com/browse/RHEL-23931
Upstream Status: RHEL Specific
There have been a few TIPC CVE bugs and we see no Red Hat customers using
TIPC so far. Per Jianwen's request, move TIPC modules to modules-extra,
and prevent auto-loading TIPC modules just because an user triggered it.
The sysadmin will have to enable it.
Signed-off-by: Xin Long <lxin(a)redhat.com>
diff --git a/redhat/rhel_files/def_variants.yaml.rhel b/redhat/rhel_files/def_variants.yaml.rhel
index blahblah..blahblah 100644
--- a/redhat/rhel_files/def_variants.yaml.rhel
+++ b/redhat/rhel_files/def_variants.yaml.rhel
@@ -505,7 +505,7 @@ rules:
- net/sctp/.*: modules-extra
- net/sunrpc/xprtrdma/rpcrdma.*: modules
- net/sunrpc/.*: modules-core
- - net/tipc/.*: modules-core
+ - net/tipc/.*: modules-extra
- net/tls/.*: modules-core
- net/vmw_vsock/.*: modules-core
- net/xdp/.*: modules-core
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3096