Hello!
There are two things to consider, both mean that I can't really ever say
"yes we will do it" for a request like that.
- None of the anaconda devs are qualified enough to decide if we could
accept such a change. It's a bootloader thing. What we would do is delegate
to somebody working with
On Thu, 2023-05-11 at 12:52 -0500, Gregory Bartholomew wrote:
> On Thu, May 11, 2023 at 10:10 AM Lennart Poettering
> wrote:
>
> >
> > (Moreover, read-only access doesn't cut it. If you want boot counting
> > you want write access.)
> >
> >
> Just interjecting a quick thought -- would it be
On Thu, May 11, 2023 at 10:10 AM Lennart Poettering
wrote:
>
> (Moreover, read-only access doesn't cut it. If you want boot counting
> you want write access.)
>
>
Just interjecting a quick thought -- would it be possible to use FAT's
reserved sectors for the boot counting? (You can find a
On Thu, May 11, 2023 at 3:10 PM Lennart Poettering wrote:
>
> On Mi, 10.05.23 17:54, Chris Murphy (li...@colorremedies.com) wrote:
> >
> > Read-only drivers, which are the only drivers under discussion here,
> > aren't a per se problem because they can't modify the file
> > system. So they have
On Do, 11.05.23 03:59, Neal Gompa (ngomp...@gmail.com) wrote:
> On Thu, May 11, 2023 at 3:33 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Wed, May 10, 2023 at 05:54:45PM -0400, Chris Murphy wrote:
> > > I don't know what question you asked them. Any modifications
> > > (writes) performed
On Mi, 10.05.23 17:54, Chris Murphy (li...@colorremedies.com) wrote:
>
>
> On Wed, May 10, 2023, at 5:21 PM, Lennart Poettering wrote:
> > So to add to this. I happen to be at LFSMMBPF at the moment, the Linux
> > File System summit (among other things) where all the Linux FS people
> > meet. I
On Wed, 2023-05-10 at 18:46 +0200, Lennart Poettering wrote:
> On Mi, 10.05.23 11:20, Simo Sorce (s...@redhat.com) wrote:
>
> > It sounds reasonable for sure.
> > The only concern is, given Microsoft creates at most 500MB ESP
> > partitions, are we sure all UEFI systems out there will not choke
On Wed, 2023-05-10 at 12:00 -0400, Neal Gompa wrote:
> On Wed, May 10, 2023 at 11:12 AM Simo Sorce wrote:
> >
> > On Tue, 2023-05-09 at 12:37 -0400, Neal Gompa wrote:
> > > On Tue, May 9, 2023 at 12:31 PM Lennart Poettering
> > > wrote:
> > > >
> > > > On Di, 09.05.23 08:22, Neal Gompa
> On Thu, May 11, 2023 at 6:26 AM Luca Boccassi
> I definitely am, considering how often there's no space and how easy
> it is to brick many systems through it.
Right, and that's the only other way to convey this information to the
bootloader. And that's one of the reasons why in sd-boot we
On Thu, May 11, 2023 at 03:59:33AM -0400, Neal Gompa wrote:
> On Thu, May 11, 2023 at 3:33 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Wed, May 10, 2023 at 05:54:45PM -0400, Chris Murphy wrote:
> > > I don't know what question you asked them. Any modifications
> > > (writes) performed
On Thu, May 11, 2023 at 6:26 AM Luca Boccassi wrote:
>
> > On Thu, May 11, 2023 at 3:33 AM Zbigniew Jędrzejewski-Szmek
> > >
> > We already don't do boot counting from the bootloader side. That
> > happens in the operating system.
>
> boot counting in the bootloader is a good thing to have, as
On Wed, May 10, 2023 at 02:25:07PM +0100, Richard Hughes wrote:
> On Wed, 10 May 2023 at 11:55, Zbigniew Jędrzejewski-Szmek
> wrote:
> > Especially not by making some small change contingent on moonshot proposals.
> > But I think that a) the current proposal is just a band-aid, and
> > b) to make
> On Thu, May 11, 2023 at 3:33 AM Zbigniew Jędrzejewski-Szmek
>
> We already don't do boot counting from the bootloader side. That
> happens in the operating system.
boot counting in the bootloader is a good thing to have, as that's the only
place to catch a few significant failures, and also
On Thu, May 11, 2023 at 3:26 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, May 10, 2023 at 11:54:50AM -0400, Neal Gompa wrote:
> > On Wed, May 10, 2023 at 11:21 AM Simo Sorce wrote:
> > >
> > > On Tue, 2023-05-09 at 18:32 +0200, Lennart Poettering wrote:
> > > > On Di, 09.05.23 09:20,
On Thu, May 11, 2023 at 3:33 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, May 10, 2023 at 05:54:45PM -0400, Chris Murphy wrote:
> > I don't know what question you asked them. Any modifications
> > (writes) performed outside kernel code is not supported, since
> > forever.
>
> > Read-only
On Wed, May 10, 2023 at 05:54:45PM -0400, Chris Murphy wrote:
> I don't know what question you asked them. Any modifications
> (writes) performed outside kernel code is not supported, since
> forever.
> Read-only drivers, which are the only drivers under discussion here,
> aren't a per se problem
On Wed, May 10, 2023 at 11:54:50AM -0400, Neal Gompa wrote:
> On Wed, May 10, 2023 at 11:21 AM Simo Sorce wrote:
> >
> > On Tue, 2023-05-09 at 18:32 +0200, Lennart Poettering wrote:
> > > On Di, 09.05.23 09:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
> > > wrote:
> > >
> > > > > ==
On Wed, May 10, 2023, at 7:36 PM, Owen Taylor wrote:
>
>
> On Wed, May 10, 2023 at 5:34 PM Chris Murphy wrote:
>> __
>>
>>
>> On Wed, May 10, 2023, at 2:24 PM, Owen Taylor wrote:
>>>
>>>
>>> On Wed, May 10, 2023 at 12:02 PM Neal Gompa wrote:
>>> Now, there's a second problem with
On Wed, May 10, 2023, at 7:11 PM, Chris Adams wrote:
> Once upon a time, Chris Murphy said:
>> Read-only drivers, which are the only drivers under discussion here, aren't
>> a per se problem because they can't modify the file system. So they have no
>> complaints about that.
>
> But those
> On Wed, May 10, 2023 at 5:34 PM Chris Murphy wrote:
>
>
> In this idea, the dm-verity parition/file would only be accessed from the
> initrd, once we have enough kernel to ability to interact with physical
> storage, understand partitions, initialize dm-verity, and read *a*
> partition, but
On Wed, May 10, 2023 at 5:34 PM Chris Murphy
wrote:
>
>
> On Wed, May 10, 2023, at 2:24 PM, Owen Taylor wrote:
>
>
>
> On Wed, May 10, 2023 at 12:02 PM Neal Gompa wrote:
>
>
> Now, there's a second problem with reading everything from the ESP - it's
> slow for two reasons. First, because read
Once upon a time, Chris Murphy said:
> Read-only drivers, which are the only drivers under discussion here, aren't a
> per se problem because they can't modify the file system. So they have no
> complaints about that.
But those read-only drivers are incomplete and problematic, especially
as
On Wed, May 10, 2023, at 5:21 PM, Lennart Poettering wrote:
> So to add to this. I happen to be at LFSMMBPF at the moment, the Linux
> File System summit (among other things) where all the Linux FS people
> meet. I spoke to a couple of FS maintainers here, and well, let me
> make this very
On Mi, 10.05.23 14:32, Neal Gompa (ngomp...@gmail.com) wrote:
> On Wed, May 10, 2023 at 2:24 PM Owen Taylor wrote:
> >> As soon as you throw UKIs in the mix, you've completely broken that
> >> because now the absolutely most valuable code for your system is in a
> >> "hostile" environment. At
On Mi, 10.05.23 12:00, Neal Gompa (ngomp...@gmail.com) wrote:
> This proposal isn't better. Neither Windows nor macOS put critical
> operating system code in the ESP, and we shouldn't either.
This is nonsense. I am not sure what definition of "critical" you
have, but the ESP is the entrypoint to
On Wed, May 10, 2023, at 2:24 PM, Owen Taylor wrote:
>
>
> On Wed, May 10, 2023 at 12:02 PM Neal Gompa wrote:
>>
> Now, there's a second problem with reading everything from the ESP - it's
> slow for two reasons. First, because read speeds when going through the
> firmware are much slower
On Mi, 10.05.23 15:13, Lennart Poettering (mzerq...@0pointer.de) wrote:
> > We're generally looking toward encrypting subvolumes individually
> > using the upcoming Btrfs native encryption capability rather than
> > using LUKS. That allows us to
>
> How do you establish trust in the underlying
> On Wed, May 10, 2023 at 2:24 PM Owen Taylor
> fsverity is separate from fscrypt. We can apply filesystem authentication
> today.
fsverity does not protect metadata, and most importantly it does not protect
the filesystem superblock. It has its uses, but this is not it.
> No. It initializes
On Wed, May 10, 2023 at 2:24 PM Owen Taylor wrote:
>
>
>
> On Wed, May 10, 2023 at 12:02 PM Neal Gompa wrote:
>>
>>
>> This proposal isn't better. Neither Windows nor macOS put critical
>> operating system code in the ESP, and we shouldn't either. But you
>> want to put kernels in the ESP?
On Wed, May 10, 2023 at 2:00 PM Chris Murphy wrote:
>
>
>
> On Mon, Apr 24, 2023, at 12:15 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/BiggerESP
>
> > This change will increase the minimum size of the ESP to be 500MB,
> > which is also the same value used by Microsoft for
On Wed, May 10, 2023 at 12:02 PM Neal Gompa wrote:
>
> This proposal isn't better. Neither Windows nor macOS put critical
> operating system code in the ESP, and we shouldn't either. But you
> want to put kernels in the ESP? That's the wrong approach too.
>
> As soon as you throw UKIs in the
On Wed, May 10, 2023, at 9:42 AM, Lennart Poettering wrote:
> You are arguing here into two opposing directions. One one hand you
> want to chainload multiple kernels+initrd (claiming this was a good idea out
> of the problem of sizing ESP/XBOOTLDR sufficientlly), and then on the
> other hand
On Mon, Apr 24, 2023, at 12:15 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/BiggerESP
> This change will increase the minimum size of the ESP to be 500MB,
> which is also the same value used by Microsoft for Windows 10 and
> newer.
Issue 1: Currently anaconda calls mkdosfs
On Wed, May 10, 2023 at 11:37:34AM -0500, Chris Adams wrote:
> Once upon a time, Daniel P. Berrangé said:
> > If the idea to allow a UKI to contain multiple alternate, signed,
> > cmdline line profiles gets accepted
>
> Are those of us who need boot-time kernel options (e.g. for hardware
>
On Mi, 10.05.23 11:20, Simo Sorce (s...@redhat.com) wrote:
> It sounds reasonable for sure.
> The only concern is, given Microsoft creates at most 500MB ESP
> partitions, are we sure all UEFI systems out there will not choke on a
> 1GB one?
Well, I don't really think we have a reason to believe
> On Wed, May 10, 2023 at 03:52:51PM -, Luca Boccassi wrote:
>
> If the idea to allow a UKI to contain multiple alternate, signed,
> cmdline line profiles gets accepted [1], then a "rescue" image
> won't neccessarily need to be a separate image anymore. There could
> just be an alternative
Once upon a time, Daniel P. Berrangé said:
> If the idea to allow a UKI to contain multiple alternate, signed,
> cmdline line profiles gets accepted
Are those of us who need boot-time kernel options (e.g. for hardware
workarounds or such) just screwed in the signed command-line cases?
--
Chris
On Wed, May 10, 2023 at 12:00:36PM -0400, Neal Gompa wrote:
> On Wed, May 10, 2023 at 11:12 AM Simo Sorce wrote:
> >
> > On Tue, 2023-05-09 at 12:37 -0400, Neal Gompa wrote:
> > > On Tue, May 9, 2023 at 12:31 PM Lennart Poettering
> > > wrote:
> > > >
> > > > On Di, 09.05.23 08:22, Neal Gompa
On Wed, May 10, 2023 at 3:56 PM Neal Gompa wrote:
> At least in the upstream kiwi project, we encountered problems making
> bigger ESPs because not all UEFI implementations handle FAT32 (despite
> it being part of the spec). In particular, there were a few server
> boards and especially AWS EC2
On Wed, May 10, 2023 at 11:12 AM Simo Sorce wrote:
>
> On Tue, 2023-05-09 at 12:37 -0400, Neal Gompa wrote:
> > On Tue, May 9, 2023 at 12:31 PM Lennart Poettering
> > wrote:
> > >
> > > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote:
> > >
> > > > I've been asked to consider
On Wed, May 10, 2023 at 03:52:51PM -, Luca Boccassi wrote:
> > On Tue, 2023-05-09 at 18:32 +0200, Lennart Poettering wrote:
> >
> > It sounds reasonable for sure.
> > The only concern is, given Microsoft creates at most 500MB ESP
> > partitions, are we sure all UEFI systems out there will not
On Wed, May 10, 2023 at 11:21 AM Simo Sorce wrote:
>
> On Tue, 2023-05-09 at 18:32 +0200, Lennart Poettering wrote:
> > On Di, 09.05.23 09:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
> > wrote:
> >
> > > > == Summary ==
> > > >
> > > > This change will increase the minimum size of the
> On Tue, 2023-05-09 at 18:32 +0200, Lennart Poettering wrote:
>
> It sounds reasonable for sure.
> The only concern is, given Microsoft creates at most 500MB ESP
> partitions, are we sure all UEFI systems out there will not choke on a
> 1GB one?
>
> Can't we reduce the number of kernels by
Leslie Satenstein
Some end-user feedback.
I believe in the KISS approach (Keep It Simple S).
I would consider /boot as a btrfs volume, and not a sub-volume, but why
bother?
For me, it being a btrfs partition is definitely not a priority or urgency, as
I use rsync for
On Tue, 2023-05-09 at 18:32 +0200, Lennart Poettering wrote:
> On Di, 09.05.23 09:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
> > > == Summary ==
> > >
> > > This change will increase the minimum size of the ESP to be 500MB,
> > > which is also the same value used by Microsoft
On Tue, 2023-05-09 at 12:37 -0400, Neal Gompa wrote:
> On Tue, May 9, 2023 at 12:31 PM Lennart Poettering
> wrote:
> >
> > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > I've been asked to consider converting /boot to a Btrfs subvolume so
> > > that it no longer has a
On Di, 09.05.23 15:22, Chris Murphy (li...@colorremedies.com) wrote:
>
>
> On Tue, May 9, 2023, at 2:47 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, May 09, 2023 at 01:31:01PM -0500, Chris Adams wrote:
> >> Once upon a time, Chris Murphy said:
> >> > What about the increasing growth in
On Di, 09.05.23 15:04, Chris Murphy (li...@colorremedies.com) wrote:
> > This makese no sense. If you want /boot to just be a subvolume of the
> > rootfs btrfs, then this would imply it's also covered by the same
> > security choices, i.e. encryption. We want to bind that sooner or
> > later to
On Wed, 10 May 2023 at 11:55, Zbigniew Jędrzejewski-Szmek
wrote:
> Especially not by making some small change contingent on moonshot proposals.
> But I think that a) the current proposal is just a band-aid, and
> b) to make things better we don't need to make huge changes.
Okay, please open a
On Di, 09.05.23 12:37, Neal Gompa (ngomp...@gmail.com) wrote:
> On Tue, May 9, 2023 at 12:31 PM Lennart Poettering
> wrote:
> >
> > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > I've been asked to consider converting /boot to a Btrfs subvolume so
> > > that it no
On Tue, May 09, 2023 at 01:20:54PM +0100, Richard Hughes wrote:
> On Tue, 9 May 2023 at 10:22, Zbigniew Jędrzejewski-Szmek
> wrote:
> > This is both too much and not enough.
>
> Right; and I think a different Fedora feature proposal would be a good
> idea for the version of Fedora when we switch
> > /boot/efi is clearly not ideal for a number of reasons, but this is what
> > we have today and changing this opens up another can of worms. For
> > starters this will stop working:
> >
> > # rpm -ql shim-x64
> > /boot/efi/EFI/BOOT/BOOTX64.EFI
> > /boot/efi/EFI/BOOT/fbx64.efi
> >
On Tue, May 9, 2023, at 2:47 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, May 09, 2023 at 01:31:01PM -0500, Chris Adams wrote:
>> Once upon a time, Chris Murphy said:
>> > What about the increasing growth in linux-firmware and in particular the
>> > NVIDIA firmware requirements? My reading
On Tue, May 9, 2023, at 12:31 PM, Lennart Poettering wrote:
> On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote:
>
>> I've been asked to consider converting /boot to a Btrfs subvolume so
>> that it no longer has a fixed space allocation to deal with the ever
>> increasing amount of
On Tue, May 9, 2023 at 2:31 PM Chris Adams wrote:
> Once upon a time, Chris Murphy said:
> > What about the increasing growth in linux-firmware and in particular the
> NVIDIA firmware requirements? My reading suggests it's significant and the
> future growth also significant.
>
> Could we use a
On Tue, May 9, 2023 at 12:39 PM Neal Gompa wrote:
> On Tue, May 9, 2023 at 12:31 PM Lennart Poettering
> wrote:
> >
> > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > I've been asked to consider converting /boot to a Btrfs subvolume so
> > > that it no longer has a
On 5/9/23 14:47, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, May 09, 2023 at 01:31:01PM -0500, Chris Adams wrote:
>> Once upon a time, Chris Murphy said:
>>> What about the increasing growth in linux-firmware and in particular the
>>> NVIDIA firmware requirements? My reading suggests it's
On Tue, May 09, 2023 at 01:31:01PM -0500, Chris Adams wrote:
> Once upon a time, Chris Murphy said:
> > What about the increasing growth in linux-firmware and in particular the
> > NVIDIA firmware requirements? My reading suggests it's significant and the
> > future growth also significant.
>
On Tue, May 09, 2023 at 04:04:33PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > And install kernels to /boot/efi in case /boot is not a XBOOTLDR
> > > filesystem?
> >
> > If /boot is not a XBOOTLDR, then we only have one file system which is
> > the ESP. It could be mounted on /boot or on /efi or
Once upon a time, Chris Murphy said:
> What about the increasing growth in linux-firmware and in particular the
> NVIDIA firmware requirements? My reading suggests it's significant and the
> future growth also significant.
Could we use a dumb framebuffer in initrd and get rid of all the GPU
On Tue, May 9, 2023, at 8:08 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, May 09, 2023 at 12:02:26PM +0200, Gerd Hoffmann wrote:
>> Hi,
>>
>> > If we want to change the default here, let's do some proper cleanup:
>> > 1. the split between ESP and XBOOTLDR is only useful in the case where
On Tue, May 9, 2023 at 12:31 PM Lennart Poettering wrote:
>
> On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > I've been asked to consider converting /boot to a Btrfs subvolume so
> > that it no longer has a fixed space allocation to deal with the ever
> > increasing amount of
On Di, 09.05.23 12:08, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> the ESP. It could be mounted on /boot or on /efi or maybe even /boot/efi (*).
> The kernels would then go to /boot/EFI/Linux, /efi/EFI/Linux, or
> /boot/efi/EFI/Linux,
> respectively. (When you write /boot/efi, it's
On Di, 09.05.23 09:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> > == Summary ==
> >
> > This change will increase the minimum size of the ESP to be 500MB,
> > which is also the same value used by Microsoft for Windows 10 and
> > newer.
>
> This is both too much and not enough.
On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote:
> I've been asked to consider converting /boot to a Btrfs subvolume so
> that it no longer has a fixed space allocation to deal with the ever
> increasing amount of firmware required for NVIDIA GPUs[1]. This is
> currently incompatible
Hi,
> > And install kernels to /boot/efi in case /boot is not a XBOOTLDR
> > filesystem?
>
> If /boot is not a XBOOTLDR, then we only have one file system which is
> the ESP. It could be mounted on /boot or on /efi or maybe even /boot/efi (*).
> The kernels would then go to /boot/EFI/Linux,
On Tue, May 9, 2023 at 8:09 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Tue, May 09, 2023 at 12:02:26PM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > If we want to change the default here, let's do some proper cleanup:
> > > 1. the split between ESP and XBOOTLDR is only useful in the case
On Tue, 9 May 2023 at 10:22, Zbigniew Jędrzejewski-Szmek
wrote:
> This is both too much and not enough.
Right; and I think a different Fedora feature proposal would be a good
idea for the version of Fedora when we switch to UKIs. Where we can
just have /boot/efi and not /boot -- but that's not
On Tue, May 09, 2023 at 12:02:26PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > If we want to change the default here, let's do some proper cleanup:
> > 1. the split between ESP and XBOOTLDR is only useful in the case where
> >ESP already existed and was small. If the installer is *creating*
> >
Hi,
> If we want to change the default here, let's do some proper cleanup:
> 1. the split between ESP and XBOOTLDR is only useful in the case where
>ESP already existed and was small. If the installer is *creating*
>an ESP, it should just make it large enough.
And install kernels to
Hi!
Sorry for the late reply, esp. that I need to grumble a bit. I missed
the thread and only came here via the fesco ticket.
On Mon, Apr 24, 2023 at 12:15:12PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/BiggerESP
> == Feedback ==
>
> There is no alternative -- the ESP
On Tue, 25 Apr 2023 at 07:05, Peter Robinson wrote:
> While I believe this to be low impact I do believe it should be a
> system wide change as it impacts all aarch64 and basically all the
> x86_64 we actively care about.
I guess you could argue it both ways -- I figured it was self
contained as
On Mon, 24 Apr 2023 at 18:28, Daniel P. Berrangé wrote:
> This refers to the minimum size being changed, but later it mentions
> the default size being changed. Are the default & minimum sizes
> effectively the same in this case ?
I believe so.
> nitpick - the github change linked is 512 MiB
On Mon, Apr 24, 2023 at 5:15 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/BiggerESP
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be
On Mon, Apr 24, 2023 at 12:15:12PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/BiggerESP
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be
https://fedoraproject.org/wiki/Changes/BiggerESP
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
https://fedoraproject.org/wiki/Changes/BiggerESP
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
77 matches
Mail list logo
