On Tue, Mar 23, 2021 at 10:47:28PM +0100, Fabiano FidĂȘncio wrote:
> > I don't have a problem with this particular use case, it is not a
> > "kernel" package, and would not be mistaken as the proper kernel in any
> > sort of a real context.
>
> Perfect!
> With this in mind, I guess we can simply
Justin,
On Tue, Mar 23, 2021 at 10:30 PM Justin Forbes wrote:
>
> On Mon, Mar 22, 2021 at 4:23 AM Sergio Lopez wrote:
> >
> > Hi,
> >
> > Now that libkrun, libkrunfw and krunvm have landed in openSUSE
> > Tumbleweed [1], I think it's a good time to reopen this discussion. I
> > also had plenty
On Mon, Mar 22, 2021 at 4:23 AM Sergio Lopez wrote:
>
> Hi,
>
> Now that libkrun, libkrunfw and krunvm have landed in openSUSE
> Tumbleweed [1], I think it's a good time to reopen this discussion. I
> also had plenty of time to think about it, and my thoughts are now
> clearer, so please let me
Matthew,
On Tue, Mar 23, 2021 at 8:31 PM Matthew Miller wrote:
>
> On Mon, Mar 22, 2021 at 10:23:24AM +0100, Sergio Lopez wrote:
> > So, for the reasons stated above, I'd would like to reopen this
> > question to see if together we can find a compromise that would work
> > for all of us.
>
>
On 3/22/21 05:23, Sergio Lopez wrote:
Hi,
Now that libkrun, libkrunfw and krunvm have landed in openSUSE
Tumbleweed [1], I think it's a good time to reopen this discussion. I
also had plenty of time to think about it, and my thoughts are now
clearer, so please let me explain again why bundling
Hi,
Now that libkrun, libkrunfw and krunvm have landed in openSUSE
Tumbleweed [1], I think it's a good time to reopen this discussion. I
also had plenty of time to think about it, and my thoughts are now
clearer, so please let me explain again why bundling a custom kernel
with patches is a
On Mon, Mar 22, 2021 at 10:23:24AM +0100, Sergio Lopez wrote:
> So, for the reasons stated above, I'd would like to reopen this
> question to see if together we can find a compromise that would work
> for all of us.
This all sounds good to me. What are we blocked on?
--
Matthew Miller
Fedora
Hi,
Now that libkrun, libkrunfw and krunvm have landed in openSUSE
Tumbleweed [1], I think it's a good time to reopen this discussion. I
also had plenty of time to think about it, and my thoughts are now
clearer, so please let me explain again why bundling a custom kernel
with patches is a
Hey all. This is a Fedora project mailing list, and as such, we expect
discourse to be friendly at all times, even when we disagree. Please
remember to be excellent to each other. Thank you.
--
Matthew Miller
Fedora Project Leader
___
kernel mailing
On Fri, 13 Nov 2020 11:55:17 +0100, Sergio Lopez wrote:
> On Fri, Nov 13, 2020 at 11:51:47AM +0100, Jiri Benc wrote:
> > On Fri, 13 Nov 2020 11:42:32 +0100, Sergio Lopez wrote:
> > > Is it acceptable to package non-bootable kernels in Fedora?
> >
> > Based
On Fri, Nov 13, 2020 at 11:51:47AM +0100, Jiri Benc wrote:
> On Fri, 13 Nov 2020 11:42:32 +0100, Sergio Lopez wrote:
> > Is it acceptable to package non-bootable kernels in Fedora?
>
> Based on what you described, I'd say no?
OK. Thanks for your prompt response.
On Fri, 13 Nov 2020 11:42:32 +0100, Sergio Lopez wrote:
> Is it acceptable to package non-bootable kernels in Fedora?
Based on what you described, I'd say no?
Jiri
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an em
within the security boundary of the VMM/VM, and the
> > latter under the security context of the original application (in
> > fact, a stricter context with a better seccomp profile).
>
> I don't think that downplaying security issues i
On Fri, 13 Nov 2020 10:50:53 +0100, Sergio Lopez wrote:
> Let me clear here, there's absolutely no intention of keeping things
> downstream, but there may be changes that won't be accepted upstream
> because they only make sense for this particular use case.
If they are not accepted upstream,
On Fri, Nov 13, 2020 at 10:09:04AM +0100, Jiri Benc wrote:
> On Thu, 12 Nov 2020 21:56:55 +0100, Sergio Lopez wrote:
> > The intention is to keep the gap as small as possible by trying
> > to upstream all changes. Probably there will be a some of them that
> > won't make upstream, but those will
On Thu, 12 Nov 2020 21:56:55 +0100, Sergio Lopez wrote:
> The intention is to keep the gap as small as possible by trying
> to upstream all changes. Probably there will be a some of them that
> won't make upstream, but those will be super-small changes (such as
> not complaining loudly if init
On Thu, Nov 12, 2020 at 01:18:21PM -0600, Justin Forbes wrote:
> On Thu, Nov 12, 2020 at 2:38 AM Sergio Lopez wrote:
> >
> > (This message was originally sent to the Packaging mailing list, where
> > Jason Tibbitts pointed that this is a restriction requested by the
> > Kernel team, and it'll be
On Thu, Nov 12, 2020 at 2:38 AM Sergio Lopez wrote:
>
> (This message was originally sent to the Packaging mailing list, where
> Jason Tibbitts pointed that this is a restriction requested by the
> Kernel team, and it'll be your opinion the one that will prevail here)
>
> Hi,
>
> The document
(This message was originally sent to the Packaging mailing list, where
Jason Tibbitts pointed that this is a restriction requested by the
Kernel team, and it'll be your opinion the one that will prevail here)
Hi,
The document "What can be packaged" from "Fedora Packaging
Guidelines", in the
19 matches
Mail list logo