Hello jforbes,
We ran automated tests on the following kernel build:
Kernel package: kernel-5.9.12-200.fc33
Task URL: https://koji.fedoraproject.org/koji/taskinfo?taskID=56604533
The results of these automated tests are provided below.
Overall result: PASSED
Tests:
From: Bruno Meneguele
To avoid warnings during dist-configs we need to explicitly set a value for
this options, which should be disabled.
Signed-off-by: Bruno Meneguele
---
.../ark/generic/{powerpc => }/CONFIG_IMA_APPRAISE_SIGNED_INIT | 0
1 file changed, 0 insertions(+), 0 deletions(-)
r
From: Bruno Meneguele
Both CONFIG_EVM_LOAD_X509 and CONFIG_EVM_X509_PATH are complementary and
should be enabled. It behaves in the same way as the x509 certificates on
IMA, which can be added to '.evm' keyring once they are signed with a
trusted key placed in the '.platform_keyring'.
And, as de
From: Bruno Meneguele
Make it default to all arches on ARK. x86_64 and powerpc already had it
enabled, and keep it disabled elsewhere.
Signed-off-by: Bruno Meneguele
---
redhat/configs/ark/generic/{powerpc => }/CONFIG_EVM_ATTR_FSUUID | 0
redhat/configs/common/generic/CONFIG_EVM_ADD_XATTRS
From: Bruno Meneguele
The same way IMA should be enabled in all arches, EVM also should be.
EVM is independent, but also complementary, from IMA.
Signed-off-by: Bruno Meneguele
---
redhat/configs/ark/generic/powerpc/CONFIG_EVM| 1 -
redhat/configs/ark/generic/x86/x86_64/CONFIG_EVM | 1 -
r
From: Bruno Meneguele
Both options CONFIG_IMA_LOAD_X509 and CONFIG_IMA_X509_PATH are complementary
and should be enabled for all ARK flavors: IBM requested it for powerpc some
time ago on RHEL and others arches should be in sync.
Signed-off-by: Bruno Meneguele
---
redhat/configs/ark/generic/CO
From: Bruno Meneguele
Set SHA256 as the default IMA hash on all arches and flavors.
Signed-off-by: Bruno Meneguele
---
redhat/configs/common/generic/CONFIG_IMA_DEFAULT_HASH | 1 +
1 file changed, 1 insertion(+)
create mode 100644 redhat/configs/common/generic/CONFIG_IMA_DEFAULT_HASH
diff --g
From: Bruno Meneguele
x86 and powerpc have this config to let IMA know it can check for secure
and/or trusted boot state during runtime, allowing other features to be
initialized.
Signed-off-by: Bruno Meneguele
---
.../ark/generic/powerpc/CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT| 1 +
.../ark
From: Bruno Meneguele
It's already enabled for all Fedora arches and has no reason for not be
enabled on ARK.
Signed-off-by: Bruno Meneguele
---
redhat/configs/ark/generic/CONFIG_IMA_READ_POLICY| 1 -
redhat/configs/{fedora => common}/generic/CONFIG_IMA_READ_POLICY | 0
2 files
From: Bruno Meneguele
Fedora and ARK uses different IMA templates, and that's fine, but the
templates should be kept the same across arches in the same flavor (ARK in
this case).
Signed-off-by: Bruno Meneguele
---
redhat/configs/ark/generic/{powerpc => }/CONFIG_IMA_NG_TEMPLATE | 0
redhat/con
From: Bruno Meneguele
IMA default hash was already defaulted to SHA256 on Fedora.
It's time to make it the default for all arches in ARK too.
Signed-off-by: Bruno Meneguele
---
.../configs/ark/generic/powerpc/CONFIG_IMA_DEFAULT_HASH_SHA256 | 1 -
redhat/configs/common/generic/CONFIG_IMA_DEFAU
From: Bruno Meneguele
CONFIG_IMA_DEFAULT_HASH_SHA1 is already disabled for all Fedora arches and
ARK should also drop it and use SHA256 instead.
Signed-off-by: Bruno Meneguele
---
redhat/configs/ark/generic/powerpc/CONFIG_IMA_DEFAULT_HASH_SHA1 | 1 -
redhat/configs/common/generic/CONFIG_IMA_DE
From: Bruno Meneguele
Upstream kernel supports specific architecture IMA policies and has been
requested by IBM on RHEL. With that, enable it on ARK and Fedora too.
Two another options: PPC_SECURE_BOOT and PPC_SECVAR_SYSFS, are brought as
dependency for IMA_ARCH_POLICY on PPC.
Signed-off-by: Br
From: Bruno Meneguele
Fedora was already enabling it to all arches. ARK had it only disabled for
aarch64 because this arch hand't INTEGRITY subsystem enabled. This patch
only make it enabled for all arches and flavors and remove the
pending-common/ referent file.
Signed-off-by: Bruno Meneguele
From: Bruno Meneguele
CONFIG_IMA_APPRAISE_BOOTPARAM was enabled for all Fedora flavor arches. It's
now also being enabled for all ARK supported arches, with that, enable it
by default in all arches and flavors.
Signed-off-by: Bruno Meneguele
---
redhat/configs/ark/generic/CONFIG_IMA_APPRAISE_B
From: Bruno Meneguele
It's one of the basic operations offered by IMA, there isn't any reason to
keep it disabled. Make it enabled by default in all flavors and arches.
Signed-off-by: Bruno Meneguele
---
redhat/configs/ark/generic/powerpc/CONFIG_IMA_APPRAISE| 1 -
redhat/configs/ark/gener
From: Bruno Meneguele
It was disabled when RHEL was experimenting AARCH64 and was left in that way
since then. There is no good reason for keep it disabled on aarch64
architecture today.
Signed-off-by: Bruno Meneguele
---
redhat/configs/ark/generic/arm/aarch64/CONFIG_INTEGRITY | 1 -
1 file c
From: bmeneg on gitlab.com
IMA/EVM has been quite forgotten in the past few releases.
This patchset sync all options (where possible) on ARK supported arches,
following closely what is enabled in RHEL today and also enable/sync
some of
the Fedora options to better match what is being enabled in AR
From: pbrobinson on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/781#note_459201839
Not that according to the kernel this is the preferred method over
update_persistent_clock64 now
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/
kernel/time/ntp.c#n
From: Peter Robinson
Move CONFIG_RTC_NVMEM to common so Fedora is enabled and the same as ARK
kernels.
No changes to ARK kernels
Signed-off-by: Peter Robinson
---
redhat/configs/{ark => common}/generic/CONFIG_RTC_NVMEM | 0
redhat/configs/{ark => common}/generic/s390x/CONFIG_RTC_NVMEM |
From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/issues/35#note_459195031
Ok. Should be resolved with a documentation update
[diffs](https://gitlab.com/cki-project/kernel-
ark/-/merge_requests/772/diffs). Does executing "git branch master
--track upstream/master" resolve
From: Peter Robinson
We already enable RTC_HCTOSYS in common config, this is the inverse
for syncing NTP to HW RTCs, and seems slightly better/preferred on
non x86-style CMOS RTCa than update_persistent_clock.
Set the device to rtc0, the same as we set RTC_HCTOSYS to.
Signed-off-by: Peter Robin
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).
V2
On Tue, Dec 01, 2020 at 10:27:58AM -0500, Bastien Nocera wrote:
> > - git checkout linus/master
> > - git merge -m "Merge branch 'os-build'" os-build
> > - # Fedora carries a patch to alter this setting, so we need to change the
> > configuration to build a vanilla tree.
> > - # If you're
From: Peter Robinson
We already enable RTC_HCTOSYS in common config, this is the inverse
for syncing NTP to HW RTCs, and seems slightly better/preferred on
non x86-style CMOS RTCa than update_persistent_clock.
Signed-off-by: Peter Robinson
---
redhat/configs/common/generic/CONFIG_RTC_SYSTOHC |
On Tue, Dec 01, 2020 at 10:27:58AM -0500, Bastien Nocera wrote:
>
>
> - Original Message -
> > 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
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 Zic
On Wed, Dec 02, 2020 at 04:25:38PM -0500, Josh Boyer wrote:
> On Wed, Dec 2, 2020 at 4:18 PM Paul Bolle wrote:
> >
> > Paul Bolle schreef op wo 02-12-2020 om 21:30 [+0100]:
> > > Currently there seem to be over 6000 texlive packages. (Quick and dirty
> > > measurements, sorry.) So splitting the k
On Wed, Dec 2, 2020 at 4:18 PM Paul Bolle wrote:
>
> Paul Bolle schreef op wo 02-12-2020 om 21:30 [+0100]:
> > Currently there seem to be over 6000 texlive packages. (Quick and dirty
> > measurements, sorry.) So splitting the kernel into an absurd number of
> > packages for (obscure) modules isn'
On Wed, Dec 2, 2020 at 3:32 PM Paul Bolle wrote:
>
> Marcelo Ricardo Leitner schreef op wo 02-12-2020 om 17:11 [-0300]:
> > Maybe, then taking it to the extreme, less common modules can all have its
> > own rpm package ;-)
>
> Vague ideas like this crossed my mind too.
>
> The local build I just f
Paul Bolle schreef op wo 02-12-2020 om 21:30 [+0100]:
> Currently there seem to be over 6000 texlive packages. (Quick and dirty
> measurements, sorry.) So splitting the kernel into an absurd number of
> packages for (obscure) modules isn't a no-no on principle.
If I sort the installed packages on
Marcelo Ricardo Leitner schreef op wo 02-12-2020 om 17:11 [-0300]:
> Maybe, then taking it to the extreme, less common modules can all have its
> own rpm package ;-)
Vague ideas like this crossed my mind too.
The local build I just finished for v5.9.12 generated less than 4000 modules.
Currently
On Wed, Dec 02, 2020 at 02:53:04PM -0500, Josh Boyer wrote:
> On Wed, Dec 2, 2020 at 2:15 PM Matthew Miller
> wrote:
> >
> > On Wed, Dec 02, 2020 at 10:31:17AM -0500, Bastien Nocera wrote:
> > > You should see the hoops people go through to make their controllers work,
> > > either installing use
On Wed, Dec 2, 2020 at 2:15 PM Matthew Miller wrote:
>
> On Wed, Dec 02, 2020 at 10:31:17AM -0500, Bastien Nocera wrote:
> > You should see the hoops people go through to make their controllers work,
> > either installing user-space drivers, or finding out how to solve the
> > problem
> > by inst
On Wed, Dec 02, 2020 at 10:31:17AM -0500, Bastien Nocera wrote:
> You should see the hoops people go through to make their controllers work,
> either installing user-space drivers, or finding out how to solve the problem
> by installing the right package:
> https://rudd-o.com/linux-and-free-softwar
On Tue, 01 Dec 2020 17:32:54 -, GitLab Bridge on behalf of hadess1 wrote:
> From: Bastien Nocera
>
> XBox 360 and XBox One controllers are very common as PC joypads.
> iOS, macOS, Android and Windows all support those joypads out of the
> box, so Fedora should too.
> ---
> redhat/fedora_file
- Original Message -
> On Tue, Dec 1, 2020 at 11:33 AM Bastien Nocera wrote:
> >
> > I didn't get an answer, so I filed:
> > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/779
> >
> > - Original Message -
> > > Hey,
> > >
> > > Is there a particular reason why xpad is
On Tue, Dec 1, 2020 at 11:33 AM Bastien Nocera wrote:
>
> I didn't get an answer, so I filed:
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/779
>
> - Original Message -
> > Hey,
> >
> > Is there a particular reason why xpad isn't in the main kernel modules?
> > It's the driv
38 matches
Mail list logo
