On 12/21/22 21:08, Neal Gompa wrote:
> On Wed, Dec 21, 2022 at 4:49 PM Ben Cotton wrote:
>>
>> https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients
>>
>> This document represents a proposed Change. As part of the Changes
>> process, proposals are publicly announced in order to
On Wed, Dec 21, 2022 at 09:15:10PM -0700, Orion Poplawski wrote:
> I've been using an old review_pr.py script produced by the Fedora
> Stewardship SIG to rebuild the depedencies of a package in COPR to test
> changes/updates to packages. It's been incredibly useful. However, it
> seems that the g
I've been using an old review_pr.py script produced by the Fedora
Stewardship SIG to rebuild the depedencies of a package in COPR to test
changes/updates to packages. It's been incredibly useful. However, it
seems that the github repo has disappeared.
Is there anything else out there in use
Welcome Hussein!
On Wed, 21 Dec 2022 at 01:23, Sandro Mani wrote:
> Hi
>
> I'd like to mentor Hussein (FAS: blinxen) in learning to become a
> packager. He is a work colleague of mine. In particular, he's helping me
> getting libimagequant updated, which some time ago was ported to rust.
> As su
On Wed, Dec 21, 2022 at 4:49 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal
https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients
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 Engineerin
From the point of view of the workstation experience (with a laptop),
I see no discussion on how this may impact hibernation. Currently, I
have secure boot disabled essentially because I want my laptop to
automatically hibernate (and recover from that state) whenever it is
suspended for a number of
On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote:
> > SecureBoot may not be to your liking but is what is installed on 99% of
> > modern hardware sold, so it is a good idea to first show you can
> > support it. Then if you have interested you can propose "something
> > better".
>
> We
To answer the first question about 'domain decomposition'.. I don't
think it is something that 'most' or 'many' customers deal with.
Fair enough, but for HPC scientific applications it is definitely a
go-to functionality.
In that case, the usual method is 'build it yourself' or 'work with
ot
On Di, 20.12.22 21:32, Neal Gompa (ngomp...@gmail.com) wrote:
> As someone whose day job involves working with teams who develop both
> Windows and Linux drivers (and in the past, even macOS drivers!), I
> can categorically say that Windows driver engineering processes are
> way friendlier than Li
On Di, 20.12.22 11:28, Neal Gompa (ngomp...@gmail.com) wrote:
> I think UKIs are fundamentally flawed and are an idea that came out of
> a group that doesn't really interact with real users enough to
> understand how much of a problem they actually are.
I presume this is supposed to be a comment
On Wed, 21 Dec 2022 at 12:32, Mark Olesen wrote:
> Yup, scotch doesn't seem to be in CBR either.
> Doesn't even seem to be a metis library anymore either. This all seems
> to be a bit odd - how do people manage domain decomposition without
> metis, or scotch (and ptscotch)? Or is it expected that
In my case, I have Network Manager config files included in my initrd
and bootargs to bring up the network so that I get automatic disk
decryption while on my home network, and prompted for a password when
I am not at home. I think this a reasonable enough use case it should
be considered in the lo
On Mi, 21.12.22 12:38, Neal Gompa (ngomp...@gmail.com) wrote:
> > sd-boot implements boot counting by stashing the counter inside the
> > UKI (or bootspec type #1 conf file) file name, so that the counter is
> > impossible to ever get lost, pile up or so.
>
> Because the ESP is intended to be shar
Gerd Hoffmann wrote:
> On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote:
> > And if you chose your HW carefully you may even be able to register
> > your own public keys, generate and sign your own built UKIs and re-
> > enable SecureBoot after that... your choice!
>
> And when your ha
Gerd Hoffmann wrote:
> On Tue, Dec 20, 2022 at 08:42:14PM +0100, Björn Persson wrote:
> > > Switching the whole distro over to unified kernels quickly is not
> > > realistic though. Too many features are depending on the current
> > > workflow with a host-specific initrd (and host-specific kernel
On Mi, 21.12.22 12:35, Neal Gompa (ngomp...@gmail.com) wrote:
> > And similar for server/embedded stuff. If fedora wants to be deployed
> > in such worlds, it's kinda nice if we can automatically recover from
> > hosed updates.
>
> None of those things require us to write data to /boot. Even in yo
On Wed, 2022-12-21 at 18:31 +0100, Mark Olesen via devel wrote:
> Yup, scotch doesn't seem to be in CBR either.
> Doesn't even seem to be a metis library anymore either. This all
> seems
> to be a bit odd - how do people manage domain decomposition without
> metis, or scotch (and ptscotch)? Or is
On Wed, Dec 21, 2022 at 01:32:10PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 21 December 2022 at 12:31, Vít Ondruch wrote:
> [...]
> > Let me put together a few points to sum this up:
> >
> > 1) DNF name is well established, keep the DNF name (and forget about YUM).
> >
> > 2)
On Tue, Dec 20, 2022 at 11:28:48AM -0500, Neal Gompa wrote:
> On Tue, Dec 20, 2022 at 10:22 AM Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
> I think UKIs are fundamentally flawed and are an idea that came out of
> a group that doesn't really interact
On Wed, Dec 21, 2022 at 12:33 PM Lennart Poettering
wrote:
>
> On Mi, 21.12.22 07:40, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > > And journaling actually is more a problem than a solution due to
> > > firmware (or grub) filesystem drivers often not having full support for
> > > the journal. Lu
On Wed, Dec 21, 2022 at 12:29 PM Lennart Poettering
wrote:
>
> On Mi, 21.12.22 12:21, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > > > > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > > > > is used for the same functional pupose as the ESP, which is
> > > > > already going to use
On Mi, 21.12.22 07:40, Neal Gompa (ngomp...@gmail.com) wrote:
> > And journaling actually is more a problem than a solution due to
> > firmware (or grub) filesystem drivers often not having full support for
> > the journal. Luckily this is rarely a problem in practice because /boot
> > is rarely
Yup, scotch doesn't seem to be in CBR either.
Doesn't even seem to be a metis library anymore either. This all seems
to be a bit odd - how do people manage domain decomposition without
metis, or scotch (and ptscotch)? Or is it expected that we should be
rolling this thirdparty software into our
On Mi, 21.12.22 12:21, Neal Gompa (ngomp...@gmail.com) wrote:
> > > > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > > > is used for the same functional pupose as the ESP, which is
> > > > already going to use FAT.
> > >
> > > Doesn't support links, lournaling and ACLs.
> >
> > W
On Wed, 2022-12-21 at 12:11 -0500, Stephen Smoogen wrote:
>
>
> On Wed, 21 Dec 2022 at 12:03, Sérgio Basto wrote:
> > On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote:
> > > Checking my copr log, it seems that centos-stream-8 (and epel-8)
> > has
> > > this:
> > >
> > > ptscotch-o
On Wed, Dec 21, 2022 at 12:15 PM Lennart Poettering
wrote:
>
> On Mi, 21.12.22 12:53, Fedora Development ML (devel@lists.fedoraproject.org)
> wrote:
>
> > On 21/12/2022 12:38, Daniel P. Berrangé wrote:
> > > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > > is used for the same f
On 12/21/22 12:17, Lennart Poettering wrote:
> On Mi, 21.12.22 12:12, Demi Marie Obenour (demioben...@gmail.com) wrote:
>
>>> At least for the systemd stuff, we carefully made sure that our access
>>> patterns to the ESP both from sd-boot/sd-stub and from userspace are
>>> by default as minimal an
On Mi, 21.12.22 14:00, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> > And journaling actually is more a problem than a solution due to
> > firmware (or grub) filesystem drivers often not having full support for
> > the journal. Luckily this is rarely a problem in practice becau
On Mi, 21.12.22 12:12, Demi Marie Obenour (demioben...@gmail.com) wrote:
> > At least for the systemd stuff, we carefully made sure that our access
> > patterns to the ESP both from sd-boot/sd-stub and from userspace are
> > by default as minimal and robust as we can make them, to minimize
> > cha
On Mi, 21.12.22 12:53, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> On 21/12/2022 12:38, Daniel P. Berrangé wrote:
> > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > is used for the same functional pupose as the ESP, which is
> > already going to use FAT.
>
> D
On 12/21/22 12:00, Lennart Poettering wrote:
> On Mi, 21.12.22 10:03, Gerd Hoffmann (kra...@redhat.com) wrote:
>
>> For the general case we need some other option. Could be just stick to
>> grub2 for those cases (we'll continue to need grub2 anyway for bios boot
>> and ppc64le). Or drop an ext4
On Wed, 21 Dec 2022 at 12:03, Sérgio Basto wrote:
> On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote:
> > Checking my copr log, it seems that centos-stream-8 (and epel-8) has
> > this:
> >
> > ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools
> > scotch-devel x86_
On 12/20/22 16:34, Simo Sorce wrote:
> On Tue, 2022-12-20 at 14:56 -0500, Demi Marie Obenour wrote:
>> How do you plan to handle system recovery? For VMs this is much
>> less of a concern, but on bare metal there needs to be a way for
>> a local, authenticated administrator to obtain a root shell
Hi Simo,
On Fri, 14 Oct 2022 18:28:01 +0200,
Simo Sorce wrote:
> At this time, as far as I know, there is no OpenPGP work of any kind on
> supporting PQC algorithms. Furthermore the way we use signatures in RPM
> really has no resemblance to the scenarios OpenPGP was built for.
>
> So we should c
On Mi, 21.12.22 06:27, Neal Gompa (ngomp...@gmail.com) wrote:
> On Wed, Dec 21, 2022 at 6:23 AM Vitaly Zaitsev via devel
> wrote:
> >
> > On 20/12/2022 19:56, Chris Murphy wrote:
> > > Great. The gotcha though is this in effect requires a change in the file
> > > system currently mounted at /boo
On Mi, 21.12.22 12:22, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> On 20/12/2022 19:56, Chris Murphy wrote: > Great. The gotcha though
> is this in effect requires a change in the file system currently
> mounted at /boot, which is ext4. And ext4 isn't supported by sd-boot
> or
On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote:
> Checking my copr log, it seems that centos-stream-8 (and epel-8) has
> this:
>
> ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools
> scotch-devel x86_64 6.0.5-3.el8 powertools
>
> I was mistaken about it workin
On Mi, 21.12.22 10:03, Gerd Hoffmann (kra...@redhat.com) wrote:
> For the general case we need some other option. Could be just stick to
> grub2 for those cases (we'll continue to need grub2 anyway for bios boot
> and ppc64le). Or drop an ext4 driver to /boot/efi/EFI/systemd/drivers,
> for examp
Checking my copr log, it seems that centos-stream-8 (and epel-8) has this:
ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools
scotch-devel x86_64 6.0.5-3.el8 powertools
I was mistaken about it working with epel-9. It also fails to load
there. So I guess my question has now e
On Mi, 21.12.22 10:16, Chris Adams (li...@cmadams.net) wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> > Without an initrd we immediately have the following limitations:
> > - all kernel modules needed to mount root must be compiled in
> > - all that code is always loaded and remai
On Wed, Dec 21, 2022 at 10:16:58AM -0600, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> > Without an initrd we immediately have the following limitations:
> > - all kernel modules needed to mount root must be compiled in
> > - all that code is always loaded and remains
On Di, 20.12.22 13:56, Chris Murphy (li...@colorremedies.com) wrote:
> > * Better secure boot support (specifically the initrd is covered by
> > the signature).
>
> We need to solve the glaring hole that is the initrd. There's no
> question about it. I can't really assess if this feature is the be
On Wed, Dec 21, 2022 at 10:16:58AM -0600, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> > Without an initrd we immediately have the following limitations:
> > - all kernel modules needed to mount root must be compiled in
> > - all that code is always loaded and remains
On Wed, 21 Dec 2022 at 11:05, Michael J Gruber
wrote:
> > The devel package are not included in CentOS repositories unless
> requested
>
> Yes, but Mark reports that his package builds "with EPEL, but not with
> CentOS". As for as I know, we have the following in copr:
>
> chroot "epel 9" has bas
On Di, 20.12.22 20:42, Björn Persson (Bjorn@rombobjörn.se) wrote:
> The root filesystem is also relevant for troubleshooting, when I take a
> storage device out of a broken computer and connect it to another
> computer to inspect it. Suddenly there are two "discoverable" root
> partitions, and the
Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> Without an initrd we immediately have the following limitations:
> - all kernel modules needed to mount root must be compiled in
> - all that code is always loaded and remains in unswappable memory
> - root= syntax is limited to what the kernel
> The devel package are not included in CentOS repositories unless requested
Yes, but Mark reports that his package builds "with EPEL, but not with CentOS".
As for as I know, we have the following in copr:
chroot "epel 9" has base RHEL9 and repos base+AppStream+CRB+Extras+EPEL
chroot "centos str
On Tue, Dec 20, 2022 at 07:22:34PM +, Daniel P. Berrangé wrote:
> On Tue, Dec 20, 2022 at 01:56:57PM -0500, Chris Murphy wrote:
> > Or if we could do enough strict standardization in
> > the boot chain with a possibly larger kernel to avoid
> > needing an initrd, i.e. get to sysroot mount faste
Dne 21. 12. 22 v 16:14 Mark Olesen via devel napsal(a):
I'm using copr for https://copr.fedorainfracloud.org/coprs/openfoam/openfoam/ and now finally also enabled for
building on epel9 and centos-stream-9 (both x86_64).
With the centos-stream-9 I get these messages:
Updating Subscription Manag
On Wed, 21 Dec 2022 14:47:38 +
Sérgio Basto wrote:
> Hi,
>
> Dependencies on glib1 and gtk1 are only bubblemon manedit xconvers ,
> I propose retire it on F38, it's one less burden that we have .
As I've always said when this has come up before, I'll be happy to
retire glib1 and gtk+1 wh
I'm using copr for
https://copr.fedorainfracloud.org/coprs/openfoam/openfoam/ and now
finally also enabled for building on epel9 and centos-stream-9 (both
x86_64).
With the centos-stream-9 I get these messages:
Updating Subscription Management repositories.
Unable to read consumer identity
T
fpc (the Free Pascal Compiler) also ships with units for developing stuff
with gtk1 - so should we retire gtk+, we'll probably want to patch fpc
so said units are not shipped.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe s
Hi
I built qwt-6.2.0 two days ago but missed the fact that the Provides
changed from to libqwt-qt5.so.6() to libqwt-qt5.so.6.2(). I'll proceed
with rebuilding the following packages to fix the resulting broken
dependencies:
COPASI
gazebo
gnuradio
qgis
qsstv
Apologies for the disruption.
Sa
Hi,
Dependencies on glib1 and gtk1 are only bubblemon manedit xconvers , I
propose retire it on F38, it's one less burden that we have .
After start working on GConf2 and after maybe gtk2
Best regards,
--
Sérgio M. B.
___
devel mailing list -- de
Hi
I'll be updating to leptonica-1.83.0, which brings a soname bump. I'll
perform the build in the side tag f38-build-side-61349, rebuilding also
the following dependencies:
mupdf
python-PyMuPDF
tesseract
zathura-pdf-mupdf
Thanks
Sandro
___
devel
* Miro Hrončok:
> On 21. 12. 22 11:02, Florian Weimer wrote:
>> Is there a lightweight tool to take the repository generated by
>> %autosetup -S, with some new commits on to top, and turn that into a
>> spec file update? That is, generated the new patches, and make a
>> conservative change to the
On Wed, Dec 21, 2022 at 12:53:05PM +0100, Vitaly Zaitsev via devel wrote:
> On 21/12/2022 12:38, Daniel P. Berrangé wrote:
> > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > is used for the same functional pupose as the ESP, which is
> > already going to use FAT.
>
> Doesn't supp
On 21/12/2022 13:17, Gerd Hoffmann wrote:
Is that something you need in /boot?
Yes.
And journaling actually is more a problem than a solution due to
firmware (or grub) filesystem drivers often not having full support for
the journal. Luckily this is rarely a problem in practice because /boot
On Wed, Dec 21, 2022 at 7:17 AM Gerd Hoffmann wrote:
>
> On Wed, Dec 21, 2022 at 12:53:05PM +0100, Vitaly Zaitsev via devel wrote:
> > On 21/12/2022 12:38, Daniel P. Berrangé wrote:
> > > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > > is used for the same functional pupose as t
On Wed, Dec 21, 2022 at 6:48 AM Fabio Valentini wrote:
>
> On Wed, Dec 21, 2022 at 11:02 AM Florian Weimer wrote:
> >
> > Is there a lightweight tool to take the repository generated by
> > %autosetup -S, with some new commits on to top, and turn that into a
> > spec file update? That is, genera
On Wednesday, 21 December 2022 at 12:31, Vít Ondruch wrote:
[...]
> Let me put together a few points to sum this up:
>
> 1) DNF name is well established, keep the DNF name (and forget about YUM).
>
> 2) Keep the compatibility on reasonable level. 100% compatibility is myth
> (even between the tin
On Wed, Dec 21, 2022 at 12:53:05PM +0100, Vitaly Zaitsev via devel wrote:
> On 21/12/2022 12:38, Daniel P. Berrangé wrote:
> > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > is used for the same functional pupose as the ESP, which is
> > already going to use FAT.
>
> Doesn't supp
On Mon, 2022-12-19 at 19:45 +, Smith, Stewart via devel wrote:
>
> > On Dec 19, 2022, at 7:43 AM, Miro Hrončok
> > wrote:
> >
> > The following packages are orphaned and will be retired when they
> > are orphaned for six weeks, unless someone adopts them. If you know
> > for sure
> > that th
On 21/12/2022 12:38, Daniel P. Berrangé wrote:
Why shouldn't FAT be used for /boot. In an EFI world, /boot
is used for the same functional pupose as the ESP, which is
already going to use FAT.
Doesn't support links, lournaling and ACLs.
Everyone can do whatever they want with the files, and a
On Wed, Dec 21, 2022 at 11:02 AM Florian Weimer wrote:
>
> Is there a lightweight tool to take the repository generated by
> %autosetup -S, with some new commits on to top, and turn that into a
> spec file update? That is, generated the new patches, and make a
> conservative change to the spec fi
On 21. 12. 22 11:02, Florian Weimer wrote:
Is there a lightweight tool to take the repository generated by
%autosetup -S, with some new commits on to top, and turn that into a
spec file update? That is, generated the new patches, and make a
conservative change to the spec file?
We have this ht
On Wed, Dec 21, 2022 at 12:22:25PM +0100, Vitaly Zaitsev via devel wrote:
> On 20/12/2022 19:56, Chris Murphy wrote:
> > Great. The gotcha though is this in effect requires a change in the file
> > system currently mounted at /boot, which is ext4. And ext4 isn't supported
> > by sd-boot or UEFI f
On 21/12/2022 12:27, Neal Gompa wrote:
We should not endeavor to create more problems by putting more
stuff in the ESP.
These drivers must be located in firmware-readable location, i.e. ESP.
No matter what boot manager we use, we
should not be required to give that up. We already have efifs[1
Dne 21. 12. 22 v 11:40 Jaroslav Mracek napsal(a):
I am really sorry, but could we start the discussion from beginning? We use
many personal opinion but we provide very limited set of facts.
I will try to summary some facts related to the naming topic.
We developed a new software management to
On Wed, Dec 21, 2022 at 6:23 AM Vitaly Zaitsev via devel
wrote:
>
> On 20/12/2022 19:56, Chris Murphy wrote:
> > Great. The gotcha though is this in effect requires a change in the file
> > system currently mounted at /boot, which is ext4. And ext4 isn't supported
> > by sd-boot or UEFI firmware
On 20/12/2022 19:56, Chris Murphy wrote:
Great. The gotcha though is this in effect requires a change in the file system
currently mounted at /boot, which is ext4. And ext4 isn't supported by sd-boot
or UEFI firmware. So if you're going to support sd-boot, the installer needs to
be aware that
I am really sorry, but could we start the discussion from beginning? We use
many personal opinion but we provide very limited set of facts.
I will try to summary some facts related to the naming topic.
We developed a new software management tool to replace DNF, MICRODNF, DNF
libraries and poten
On Tue, Dec 20, 2022 at 08:42:14PM +0100, Björn Persson wrote:
> > Main motivation for this move is to make the distro more robust and more
> > secure.
>
> Improving security would be great, but it must be done in a way that
> allows the sysadmin to configure and repair the system and authorize
>
Hi,
> But why start doing UKI without first fixing the need of host specific
> initrd and commandline.
We are trying to tackle that in parallel. At least when generating
virtual machine images we can temporarily workaround that with short
%post scripts in kickstart files.
> I am sure even non
On Tue, Dec 20, 2022 at 05:11:57PM -0500, Neal Gompa wrote:
> On Tue, Dec 20, 2022, 4:27 PM Simo Sorce wrote:
>
> > On Tue, 2022-12-20 at 14:29 -0500, Neal Gompa wrote:
> > > Yeah, I seriously doubt this. Linux's model for supporting
> > > confidential computing is not user-friendly, so I expect
On Tue, Dec 20, 2022 at 02:29:22PM -0500, Neal Gompa wrote:
> On Tue, Dec 20, 2022 at 2:02 PM Daniel P. Berrangé
> wrote:
> > > In the Fedora case, things are simpler right up until we hit graphics
> > > drivers. This is also a problem for VMs too, because GPU passthrough
> > > is a common case f
On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote:
> On Tue, 2022-12-20 at 20:42 +0100, Björn Persson wrote:
> > I note that taking away the kernel command line is indeed a clearly
> > stated goal, which will limit Fedora to simple, appliance-like uses.
>
> And if you chose your HW carefu
Is there a lightweight tool to take the repository generated by
%autosetup -S, with some new commits on to top, and turn that into a
spec file update? That is, generated the new patches, and make a
conservative change to the spec file?
Thanks,
Florian
_
On Tue, Dec 20, 2022 at 08:42:14PM +0100, Björn Persson wrote:
> > Main motivation for this move is to make the distro more robust and more
> > secure.
>
> Improving security would be great, but it must be done in a way that
> allows the sysadmin to configure and repair the system and authorize
>
On Wed, Dec 21, 2022 at 03:31:10AM +0100, Kevin Kofler via devel wrote:
> PS (adding to my previous reply):
>
> Daniel P. Berrangé wrote:
> > The immediate need for UKIs is indeed related to SecureBoot and
> > TPMs. These are a core technology foundation of the confidential
> > virtual machine sta
On Tue, Dec 20, 2022 at 02:56:41PM -0500, Demi Marie Obenour wrote:
> On 12/20/22 10:22, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
> >
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announ
Hi,
> * Enhance parted/libparted to support arbitrary GUIDs and enhance blivet to
> understand the full listing of GUIDs? Or
parted is done, blivet still todo.
https://bugzilla.redhat.com/show_bug.cgi?id=1075288#c7
> the CLI tool seems not to support it but maybe fdisk does.
sfdisk supports
On 20/12/2022 16:22, Ben Cotton wrote:
The goal is to move away from initrd images being generated on the
installed machine. They are generated while building the kernel
package instead, then shipped as part of a unified kernel image.
+1.
* Add proper systemd-boot support to installers.
+1
On Wed, Dec 21, 2022 at 03:06:26AM +0100, Kevin Kofler via devel wrote:
> Daniel P. Berrangé wrote:
> > That is not correct. There are a number of benefits of UKIs.
> >
> > The most critical is that the initrd content and cmdline is
> > covered by the SecureBoot signature.
>
> From an end user p
On 21/12/2022 03:32, Neal Gompa wrote:
As someone whose day job involves working with teams who develop both
Windows and Linux drivers (and in the past, even macOS drivers!), I
can categorically say that Windows driver engineering processes are
way friendlier than Linux ones, precisely because Wi
Hi,
> I think UKIs are fundamentally flawed and are an idea that came out of
> a group that doesn't really interact with real users enough to
> understand how much of a problem they actually are. I realize that
> this Change is only about VMs, but since it explicitly talks about it
> being "phas
On 20/12/2022 23:11, Neal Gompa wrote:
We have supported Secure Boot for over a decade now. In that timeframe,
literally nobody did anything to make all the workflows you talk about
easier and friendlier.
Microsoft wants to limit[1] the use of non-Windows operating systems on
new hardware:
On 20/12/2022 22:27, Simo Sorce wrote:
SecureBoot may not be to your liking but is what is installed on 99% of
modern hardware sold, so it is a good idea to first show you can
support it. Then if you have interested you can propose "something
better".
Secure Boot with shim and the use of a Micr
On 21/12/2022 03:03, Kevin Kofler via devel wrote:
IIRC, the reason that Fedora does not use graphical GRUB by default is that
it at least used to break the NVidia proprietary driver.
It works fine on modern NVIDIA driver releases.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
90 matches
Mail list logo