From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1862558387
Hi @eesposit,
small nit. While you've updated the name in code the commit message and
comment at the beginning of uki_addons.py still use the old name.
--
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1821173690
+arch = path[-1]
+uki = path[-2]
+distro = path[-3]
+for addon_f in filenames:
+if addon_f.endswith('.addon'):
+addon_name =
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1821173923
Is this print intentional or a leftover from debugging?
--
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1821173795
+cmd = [
+f'{UKIFY_PATH}', 'build',
+f'--stub={CURRENT_SYSTEMD_STUB}'
Do addons need a stub? I thought addons are just data which get parsed by the
stub
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1821173591
You need to do more to make me truly happy. But having the -debug sub-rpm is a
step in the right direction ;-)
Although I don't see a point in shipping unsigned addons at all.
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805849597
Thanks for the pointer
--
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805835205
@berrange I find not having any debug addon way too restrictive. We do need
ways to debug problems that will occur and we really should avoid asking users
to install and maintain their
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1803294332
> Regarding why we are doing this here and not in a separate rpm, @vkuznets
might have a more detailed answer but the main point is that it would be
easier to do it here, because
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1789653760
Hi Emanuele,
your implementation is different to what I originally suggested. But I must
admit that your implementation is better. With my suggestion it would have
been hard to get a
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1789653682
What spec are you referring to? I couldn't find the two paths you are
mentioning neither in the uki spec nor any of the related systemd man pages.
--
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1758222615
This should by Python, shouldn't it.
--
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1758222573
I'm also not convinced that having all the addons in a single config file
makes sense. I'm looking at it from an kdump perspective. There we need to
have the crashkernel= parameter on
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2391#note_1355399566
ping
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora
From: Philipp Rudo
kernel.spec: Fix UKI naming to comply with BLS
The Boot Loader Specification (BLS) [1] suggests that type #2 entries (UKIs)
shall have the same names like type #1 entries with the exception of
the suffix being .efi instead of .conf. In particular this means that
the name for
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2391#note_1348622475
Uninstalling isn't a problem for type 2 entries as they are currently
explicitly removed in %postun. So at least in this case you don't need to have
an entry in %files.
Using a
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2391#note_1348248892
@lgoncalv indeed I missed that line.
I'm seeing two problems with it. 1) %files is determined during build but the
entry token can only be determined during install so we cannot
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1534#note_801910634
Hi Coiby,
the commit looks good to me.
Reviewed-by: Philipp Rudo
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1216#note_620369878
Acked-by: Philipp Rudo
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1216#note_619897346
@bmeneg I'm no longer the partner engineer for s390. Please direct s390
specific questions to @cimbrend in the future. Thanks.
Having that said, the patch looks good to me and I would
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_595925875
sure. BTW I'm joining RH so the email and accounts will still exist in the
future.
Nevertheless I guess it would be better if someone else takes over if we
there's a delay. Don't know
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_595920020
@dzickusrh this MR can be build on any machine with an appropriate compiler
(IIRC GCC10). Only the resulting kernel requires a z14+ to run.
I know that the change is necessary. I was
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_595402767
Hi,
sorry for the late response.
here's the v3 with what I picked up from the discussion, in particular
improve the wording of the first two commit messages and leave the
rest as is.
From: Philipp Rudo
configs/common/s390: Clean up CONFIG_{MARCH,TUNE}_Z*
Most of the configs are identical for fedora and ark so move them to
common/generic/s390x.
While at it move the remaining configs in fedora/generic to
fedora/generic/s390x.
Signed-off-by: Philipp Rudo
diff --git
From: Philipp Rudo
configs/ark/s390: set CONFIG_MARCH_Z14 and CONFIG_TUNE_Z15
Optimize ark for newer machines.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1876435
Signed-off-by: Philipp Rudo
diff --git a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z13
From: Philipp Rudo
configs/process_configs.sh: make use of dummy-tools
Using cc-option adds a dependency on the compiler in the configuration
environment. This usually breaks the config creation when the target
architecture is not the host architecture. As a remedy f88717cf44eb
("Temporarily
From: Philipp Rudo
configs/common: disable CONFIG_INIT_STACK_ALL_{PATTERN,ZERO}
These configs add option -ftrivial-auto-var-init={pattern,zero} to the
CFLAGS. This option are specific to CLANG and thus are not present on
typical developer systems using GCC. By using the dummy-tools the
From: Philipp Rudo
configs/common/aarch64: disable CONFIG_RELR
This config adds option --pack-dyn-relocs=relr to the LDFLAGS. This
option is specific to LLD and thus is not present on typical developer
systems using LD. By using the dummy-tools the cc-option check that
tests if the option is
From: Philipp Rudo on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144
This series aims to update the Architecture Level Set on s390 for ark to
Z14. Unfortunately this collides with a workaround introduced with
f88717cf44eb ("Temporarily switch
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_585640564
Hi Dan,
1. If I need to push an other version I can add the Fedora update as well.
This MR already got way bigger than I expected. So I don't see a problem in
adding one more commit.
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_585239426
best choice would be @dhorak1, @cohuck or @thuth
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_585224768
@dzickusrh yes, that's a fallout from using the dummy-tools. These two configs
only work with clang and thus are usually hidden. Plus they are part of a
choice from which
From: Philipp Rudo
configs/common/s390: disable CONFIG_QETH_{OSN,OSX}
Shipment of the devices required for these options were ceased with z13.
With the ALS set to z14 for ark there is no need to keep the options
enabled.
v2: disable the configs for fedora as well
Bugzilla:
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1149#note_581194256
will do. I also asked our network people. They are in favor to remove
them in fedora as well.
___
kernel mailing list --
From: Philipp Rudo
configs/ark/s390: disable CONFIG_QETH_{OSN,OSX}
Shipment of the devices required for these options were ceased with z13.
With the ALS set to z14 for ark there is no need to keep the options
enabled.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1903201
Signed-off-by:
From: Philipp Rudo
configs/common/s390: Clean up CONFIG_{MARCH,TUNE}_Z*
Most of the configs are identical for fedora and ark so move them to
common/generic/s390x.
While at it move the remaining configs in fedora/generic to
fedora/generic/s390x.
Signed-off-by: Philipp Rudo
diff
From: Philipp Rudo
configs/ark/s390: set CONFIG_MARCH_Z14 and CONFIG_TUNE_Z15
Optimize ark for newer machines.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1876435
Signed-off-by: Philipp Rudo
diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z13
From: Philipp Rudo
configs/common: disable CONFIG_INIT_STACK_ALL_{PATTERN,ZERO}
Using scripts/dummy-tools disables cc-option checks by always returning
'y'. This reveals config options usually hidden on typical developer
systems (x86 + gcc), which again causes process_configs.sh to fail due
to
From: Philipp Rudo
configs/process_configs.sh: make use of dummy-tools
Using cc-option adds a dependency on the compiler in the configuration
environment. This usually breaks the config creation when the target
architecture is not the host architecture. As a remedy f88717cf44eb
("Temporarily
From: Philipp Rudo
configs/common/aarch64: enable CONFIG_RELR
Using scripts/dummy-tools disables cc-option checks by always returning
'y'. This reveals config options usually hidden on typical developer
systems (x86 + gcc), which again causes process_configs.sh to fail due
to new, unset
From: Philipp Rudo on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144
This series aims to update the Architecture Level Set on s390 for ark to
Z14. Unfortunately this collides with a workaround introduced with
f88717cf44eb ("Temporarily switch
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_579786679
ok, I naively thought that pending-common was the staging area and
everything contained in it will be included in the next round of config
review.
What's the correct way to proceed? Not
From: Philipp Rudo
configs/ark/s390: set CONFIG_MARCH_Z14 and CONFIG_TUNE_Z15
Optimize ark for newer machines.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1876435
Signed-off-by: Philipp Rudo
diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z13
From: Philipp Rudo
configs/common/s390: Clean up CONFIG_{MARCH,TUNE}_Z*
Most of the configs are identical for fedora and ark so move them to
common/generic/s390x.
While at it move the remaining configs in fedora/generic to
fedora/generic/s390x.
Signed-off-by: Philipp Rudo
diff
From: Philipp Rudo
configs/process_configs.sh: make use of dummy-tools
Using cc-option adds a dependency on the compiler in the configuration
environment. This usually breaks the config creation when the target
architecture is not the host architecture. As a remedy f88717cf44eb
("Temporarily
From: Philipp Rudo on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144
The last commit addresses
https://bugzilla.redhat.com/show_bug.cgi?id=1876435
and is preceded by two cleanups.
The first commit is strictly speaking independent. If requested I can
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/698#note_538633814
I don't see a reason for keeping them for the zfcpdump kernel. It should
be safe to remove them.
BTW, I guess having CONFIG_MODULES disabled for the zfcpdump kernel is
the reason why
From: Philipp Rudo
[redhat] spec: package decompressor vmlinux for s390
On s390 more and more code from the early boot stage is moved to the
decompressor. With this the code complexity and thus the chances to
introduce bugs increases. In order to be able to debug these early boot
bugs package
From: Philipp Rudo
[redhat] spec: package decompressor vmlinux for s390
On s390 more and more code from the early boot stage is moved to the
decompressor. With this the code complexity and thus the chances to
introduce bugs increases. In order to be able to debug these early boot
bugs package
48 matches
Mail list logo
