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: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2973#note_1805751441
updated the MR description 珞
--
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to
From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2973#note_1805746484
this should not affect it, as the triggered pipelines run on CKI AWS-based
runners 樂
--
___
kernel mailing list --
From: Vitaly Kuznetsov on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805661115
Exactly: we may want to have an infrastructure for 'external' addons and these
should likely be global, but everything built from kernel srpm can just be
versioned.
--
From: Daniel P. Berrangé on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805650848
One could ask what benefit "global" addons actually provide ? Addons are
tiny, so the saving from only having 1 copy is lost in the noise. Possibly the
only real advantage of
From: Vitaly Kuznetsov on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805638306
What I'm afraid of with "-common" addons is that at some point we will realize
that the particular addon is not really "-common" and we want to update it
only for new ukis but not
From: Daniel P. Berrangé on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805632218
That said, have a separate srpm is not an inherently bad idea. For that matter
there's a potential case to be made that the UKI itself could also be in a
separate srpm, since if
From: Daniel P. Berrangé on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805628801
> Note, creating "-common" sub-package still doesn't give us a way to create
kernel-version-independent addons, we will have to introduce a new srpm for
that.
No we don't. It
From: Vitaly Kuznetsov on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805606318
@eesposit @berrange personally, I'd suggest we don't over-complicate stuff
**now**. Namely, we have only one UKI and only one signing SB key for it
(which, in case of Fedora, is
From: Daniel P. Berrangé on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805563273
> kernel-uki-virt
> kernel-addons-virt-common
> kernel-addons-virt
> kernel-uki-virt-debug
My only thought is around naming to be a common name prefix:
* kernel-uki-virt
*
From: Emanuele Giuseppe Esposito on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805489153
Ok so to make a summary, this could be a possible solution. We want to create
sub-rpms so that:
* `kernel-uki-virt-$uname.$distro.$arch` has the UKI. This is already
12 matches
Mail list logo
