Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On 22/12/2022 21:29, Chris Murphy wrote: This is a rare but real problem. I don't think so. Power outage is a very common problem in some countries. I still remember how unreliable FAT32 was in the Windows 9x era. You needed to run a scandisk check after every power failure or pressing the r

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 05:22:09PM -0500, Steve Grubb wrote: > On Thursday, December 22, 2022 1:29:29 PM EST Adam Williamson wrote: > > 15 seconds feels very aggressive to me. I can think of some cases, like > > libvirtd automatically suspending or cleanly shutting down running VMs, > > that might

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On 12/22/22 14:55, Chris Murphy wrote: > > > On Thu, Dec 22, 2022, at 1:29 PM, Adam Williamson wrote: >> On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote: >>> On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer >

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On 12/22/22 12:00, Luca Boccassi wrote: >> On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering >> > >> Basically, I'm saying that the model of trust is flawed because users >> are unable to work with it. >> >> And besides, each level up is a smaller scope from the previous. A >> cert trusted by shi

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On 12/22/22 12:33, Neal Gompa wrote: > On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi wrote: >> >>> On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering >>> >> >>> Basically, I'm saying that the model of trust is flawed because users >>> are unable to work with it. >>> >>> And besides, each level u

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

On 12/22/22 10:24, Elizabeth K. Joseph wrote: >> This might not be as niche as you might think. I'm one of the >> Linux kernel maintainers for s390. Many of us do the vast majority of >> their development work natively on s390 systems via SSH from Fedora >> laptops. > > I first wanted to echo and

F37 election results

Greetings, all! The elections for the Fedora Linux 37 cycle have completed. ## Fedora Council Aleksandra Fedorova is elected to the Fedora Council ## Fedora Engineering Steering Committee (FESCo) The following candidates are elected to FESCo: * Kevin Fenzi * Miro Hrončok * Zbigniew Jędrzejews

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Thu, Dec 22, 2022, at 5:22 PM, Steve Grubb wrote: > On Thursday, December 22, 2022 1:29:29 PM EST Adam Williamson wrote: >> On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote: >> >> > On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote: >> > >> > > https://fedoraproject.org/wiki/Ch

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Thursday, December 22, 2022 1:29:29 PM EST Adam Williamson wrote: > On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote: > > > On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote: > > > > > https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer > > > > > > This document repres

Golang bundled() Provides generator

Hi Fedorians, A recent PR reminded me that I never properly announced the new (well, four months old) bundled() Provides generator for Golang projects[1]. This can be used to simplify generating these Provides when bundling is justified in Fedora[2] or for (EP)EL. Simply mark the vendor/modules.tx

Re: Orphaned packages looking for new maintainers

On Wed, 2022-12-21 at 12:08 +, Sérgio Basto wrote: > 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 we

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

På Thu, 22 Dec 2022 10:29:29 -0800 Adam Williamson skrev: > On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote: > > On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer > > > > > > This document represents a proposed

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Wed, Dec 21, 2022, at 12:00 PM, 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).

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Wed, Dec 21, 2022, at 6:53 AM, 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 support links,

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 8:55 PM Chris Murphy wrote: > > Also I wonder if there's a way for desktops to opt into this behavior? Or a > way for servers, iot, cloud, and rpm-ostree based systems to opt out? Do you mean like setting the "DefaultTimeoutStopSec" variable in /etc/systemd/system.conf?

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Wed, Dec 21, 2022, at 6:22 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.

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

Vít Ondruch wrote: > Dne 22. 12. 22 v 9:56 Olivier Fourdan napsal(a): > > When the connection fails, the Xserver returns a reason in plain text. > > In that case, the reason for the connection being rejected would be > > „Swapped clients prohibited“. > > Appreciate that there is at least some ex

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Thu, Dec 22, 2022, at 1:29 PM, Adam Williamson wrote: > On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote: >> On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote: >> > https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer >> > >> > This document represents a proposed Change

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On 22/12/2022 19:18, Michael Catanzaro wrote: On Thu, Dec 22 2022 at 10:29:29 AM -0800, Adam Williamson wrote: Could we not go for 30 seconds? Personally I think 30 seconds is way too long for desktop users. But it's a lot better than 2 minutes, so if that's what we settle on, I won't compl

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Thu, Dec 22 2022 at 10:29:29 AM -0800, Adam Williamson wrote: Could we not go for 30 seconds? Personally I think 30 seconds is way too long for desktop users. But it's a lot better than 2 minutes, so if that's what we settle on, I won't complain. libvirtd should probably take an inhibit

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 5:25 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote: > > 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 > > decry

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

> On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi > Your concept only works in *some* enterprise hardware where it's even > possible to have full control without breaking something. Even in my > server gear, I can't do that without breaking the network firmware. If > I can't safely distrust Micros

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Thu, 2022-12-22 at 18:44 +0100, Tomasz Torcz wrote: > On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer > > > > This document represents a proposed Change. As part of the Changes > > process, proposals are publicly anno

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal wil

F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer 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 C

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi wrote: > > > On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering > > > > > Basically, I'm saying that the model of trust is flawed because users > > are unable to work with it. > > > > And besides, each level up is a smaller scope from the previous.

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 02:49:37PM +, Daniel P. Berrangé wrote: > > There are at three ways that are used: 'dracut --uefi', systemd's ukify, > > and a > > manual objcopy invocation. The first two are wrappers around objcopy. I'm > > biased > > because I wrote 'ukify', but I think that's the w

Re: Can't pull fedora rawhide container image

Thanks! I confirmed it works now. On Thu, Dec 8, 2022 at 9:58 PM Clement Verna wrote: > > This is fixed now, happy containering :-D -- Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic See for the timezone. __

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

Because the naming of the tool is upstream decision I opened a discussion https://github.com/rpm-software-management/dnf5/discussions/210. DNF and the new tool is shipped into multiple upstream therefore we have to collect feedback from multiple distribution and upstream discussion channel is th

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 10:52:05AM -0500, Neal Gompa wrote: > On Thu, Dec 22, 2022 at 10:46 AM Lennart Poettering > wrote: > > > > BTW, you keep talking of "these" problems, and are extremely vague > > about those. I think I understood that you hit the NVRAM size limits > > before, by enrolling pr

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

> On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering > > Basically, I'm saying that the model of trust is flawed because users > are unable to work with it. > > And besides, each level up is a smaller scope from the previous. A > cert trusted by shim can execute anything the firmware trusts, a

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 04:24:11PM +0100, Lennart Poettering wrote: > On Do, 22.12.22 14:49, Daniel P. Berrangé (berra...@redhat.com) wrote: > > > When you say it dooesn't get the offsets right, can you elaborate ? > > dracut uses fixed offsets for the sections to be placed in memory > in. The valu

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 10:56 AM Lennart Poettering wrote: > > On Do, 22.12.22 10:52, Neal Gompa (ngomp...@gmail.com) wrote: > 65;6800;1c > > > BTW, you keep talking of "these" problems, and are extremely vague > > > about those. I think I understood that you hit the NVRAM size limits > > > before

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering wrote: > > On Do, 22.12.22 10:43, Neal Gompa (ngomp...@gmail.com) wrote: > > > On Thu, Dec 22, 2022 at 10:39 AM Lennart Poettering > > wrote: > > > > > > On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote: > > > > > > > > I understand

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Do, 22.12.22 10:52, Neal Gompa (ngomp...@gmail.com) wrote: 65;6800;1c > > BTW, you keep talking of "these" problems, and are extremely vague > > about those. I think I understood that you hit the NVRAM size limits > > before, by enrolling private certs? > > Yes. Specifically for dealing with the

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

Hi all, Dne 20. 12. 22 v 16:22 Ben Cotton napsal(a): 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 announced in order to receive community feedback. This proposal will only

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 10:46 AM Lennart Poettering wrote: > > On Do, 22.12.22 06:38, Neal Gompa (ngomp...@gmail.com) wrote: > > > I have to think about what happens when the cat is out of the bag. > > What I want is not necessarily a solution to this now, but a > > commitment that someone will ac

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Do, 22.12.22 10:43, Neal Gompa (ngomp...@gmail.com) wrote: > On Thu, Dec 22, 2022 at 10:39 AM Lennart Poettering > wrote: > > > > On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote: > > > > > > I understand the big issue you have is that the certificate store for > > > > Linux (i.e.

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Do, 22.12.22 06:38, Neal Gompa (ngomp...@gmail.com) wrote: > I have to think about what happens when the cat is out of the bag. > What I want is not necessarily a solution to this now, but a > commitment that someone will actively work on fixing these problems > *before* proposing the next phas

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 10:39 AM Lennart Poettering wrote: > > On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote: > > > > I understand the big issue you have is that the certificate store for > > > Linux (i.e. the mokutil db) is limited in size because EFI variable > > > NVRAM is limite

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 10:35 AM Gerd Hoffmann wrote: > > Hi, > > > Hmm, the updated Change is mostly okay. I disagree that you have any > > real security benefits since all the Secure Boot stuff in Linux is > > still in a bad place. > > It's a step into the right direction, but I agree, it alon

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Do, 22.12.22 05:38, Neal Gompa (ngomp...@gmail.com) wrote: > > I understand the big issue you have is that the certificate store for > > Linux (i.e. the mokutil db) is limited in size because EFI variable > > NVRAM is limited in size? If that's the big issue you are having then > > that's absol

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

Hi, > Hmm, the updated Change is mostly okay. I disagree that you have any > real security benefits since all the Secure Boot stuff in Linux is > still in a bad place. It's a step into the right direction, but I agree, it alone doesn't improve the situation much. I think we need to overthink t

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

> This might not be as niche as you might think. I'm one of the > Linux kernel maintainers for s390. Many of us do the vast majority of > their development work natively on s390 systems via SSH from Fedora > laptops. I first wanted to echo and confirm what Niklas says here. The crux of this issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Do, 22.12.22 14:49, Daniel P. Berrangé (berra...@redhat.com) wrote: > When you say it dooesn't get the offsets right, can you elaborate ? dracut uses fixed offsets for the sections to be placed in memory in. The values are simply hardcoded, literally specified address offsets, that worked for

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 10:58:11AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Dec 21, 2022 at 06:56:05PM +0100, Björn Persson wrote: > > 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

Re: Unannounced SONAME bump: wxGTK

On Thu, Dec 22, 2022 at 8:17 AM Scott Talbert wrote: > On Thu, 22 Dec 2022, Ian McInerney via devel wrote: > > > > > > > On Thu, Dec 22, 2022 at 1:55 PM Richard Shaw > wrote: > > I just had a chance to check out a bug[1] recently submitted > > against trustedqsl and it appears that a

Re: Unannounced SONAME bump: wxGTK

On Thu, 22 Dec 2022, Ian McInerney via devel wrote: On Thu, Dec 22, 2022 at 1:55 PM Richard Shaw wrote: I just had a chance to check out a bug[1] recently submitted against trustedqsl and it appears that a new version of wxGTK with a SONAME bump was built  for f37+ but not a

Re: Unannounced SONAME bump: wxGTK

On Thu, 22 Dec 2022, Richard Shaw wrote: I just had a chance to check out a bug[1] recently submitted against trustedqsl and it appears that a new version of wxGTK with a SONAME bump was built  for f37+ but not all dependencies rebuilt. I'm not too worried about trustedqsl since I'm about to tak

Re: Unannounced SONAME bump: wxGTK

On Thu, Dec 22, 2022 at 1:55 PM Richard Shaw wrote: > I just had a chance to check out a bug[1] recently submitted against > trustedqsl and it appears that a new version of wxGTK with a SONAME bump > was built for f37+ but not all dependencies rebuilt. > > This was announced back in July while F

Unannounced SONAME bump: wxGTK

I just had a chance to check out a bug[1] recently submitted against trustedqsl and it appears that a new version of wxGTK with a SONAME bump was built for f37+ but not all dependencies rebuilt. I'm not too worried about trustedqsl since I'm about to take care of the build but it does have a long

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 7:32 AM Gerd Hoffmann wrote: > > Hi, > > > > If something is proposed for bare metal in the future, then raise > > > the problems at that point. It is unreasonable to demand that we > > > fix problems for a use case that is not in scope for what is being > > > proposed.

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

Hi, > > If something is proposed for bare metal in the future, then raise > > the problems at that point. It is unreasonable to demand that we > > fix problems for a use case that is not in scope for what is being > > proposed. Anything related to bare metal was explicitly out of > > scope, pre

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 7:07 AM Daniel P. Berrangé wrote: > > On Thu, Dec 22, 2022 at 06:57:07AM -0500, Neal Gompa wrote: > > On Thu, Dec 22, 2022 at 6:40 AM Daniel P. Berrangé > > wrote: > > > > > > On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote: > > > > In my case, I

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 06:57:07AM -0500, Neal Gompa wrote: > On Thu, Dec 22, 2022 at 6:40 AM Daniel P. Berrangé > wrote: > > > > On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote: > > > In my case, I have Network Manager config files included in my initrd > > > and bootarg

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

Hi, > > I mean, UEFI has its warts, but I don't see that it's UEFI's fault if > > the way Linux/shim/mokutil implement the cert db is done the way it is > > currently done. Well, UEFI *not* defining some standard way to enroll user certificates actually is part of the problem. It is one of rea

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 6:40 AM Daniel P. Berrangé wrote: > > On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote: > > 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 whi

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 06:38:56AM -0500, Neal Gompa wrote: > On Thu, Dec 22, 2022 at 6:29 AM Daniel P. Berrangé > wrote: > > > > On Thu, Dec 22, 2022 at 05:38:01AM -0500, Neal Gompa wrote: > > > On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering > > > wrote: > > > > > > > > On Di, 20.12.22 17:

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Wed, Dec 21, 2022 at 08:39:25PM +0100, Iñaki Ucar wrote: > 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 (a

Re: Scripts to rebuild dependencies in copr

On Thu, Dec 22, 2022 at 4:46 AM Kevin Fenzi wrote: > > 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.

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote: > 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

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 6:29 AM Daniel P. Berrangé wrote: > > On Thu, Dec 22, 2022 at 05:38:01AM -0500, Neal Gompa wrote: > > On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering > > wrote: > > > > > > On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote: > > > > > > > > SecureBoot may not

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 05:38:01AM -0500, Neal Gompa wrote: > On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering > wrote: > > > > 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 hardwa

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote: > 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

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 5:58 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Dec 21, 2022 at 06:56:05PM +0100, Björn Persson wrote: > > 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 regist

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Wed, Dec 21, 2022 at 06:56:05PM +0100, Björn Persson wrote: > 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- >

Fedora rawhide compose report: 20221222.n.0 changes

OLD: Fedora-Rawhide-20221221.n.1 NEW: Fedora-Rawhide-20221222.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 2 Dropped packages:0 Upgraded packages: 39 Downgraded packages: 0 Size of added packages: 806.30 KiB Size of dropped packages:0

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Wed, Dec 21, 2022 at 6:13 PM Demi Marie Obenour wrote: > [...] > > Does vfat support atomic rename? Is it possible to atomically upgrade > a bootloader/UKI/etc? > -- For Linux, renameat2 RENAME_EXCHANGE is supported in vfat since version v6.0. The relevant commits FYI are: https://git.kern

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Wed, Dec 21, 2022 at 05:44:36PM +0100, Lennart Poettering wrote: > > I mean, sure, if you use the Fedora supplied vanilla signed UKI > without anything else then it won't boot from a network, because that > would be a security hole. But I see no reason why a network boot UKI > couldn't be build

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 5:30 AM Niklas Schnelle wrote: > > Hi All, > > This might not be as niche as you might think. I'm one of the > Linux kernel maintainers for s390. Many of us do the vast majority of > their development work natively on s390 systems via SSH from Fedora > laptops. After all ma

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Wed, Dec 21, 2022 at 1:56 PM Lennart Poettering wrote: > > 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

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

Hi All, This might not be as niche as you might think. I'm one of the Linux kernel maintainers for s390. Many of us do the vast majority of their development work natively on s390 systems via SSH from Fedora laptops. After all mainframes are pretty damn fast at compiling with plenty of memory and

Re: Scripts to rebuild dependencies in copr

Dne 22. 12. 22 v 5:45 Kevin Fenzi napsal(a): 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 incredi

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

Dne 22. 12. 22 v 9:56 Olivier Fourdan napsal(a): Hi On Thu, Dec 22, 2022 at 9:45 AM Peter Boy wrote: How should this be documented so that it can be found by users who want to connect to ppc64 (or s390x) a year from now, when no one has the change proposal in mind anymore? Is there at least

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

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

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

Dne 21. 12. 22 v 18:45 Chuck Anderson napsal(a): 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 nam

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

Hi On Thu, Dec 22, 2022 at 9:45 AM Peter Boy wrote: > > How should this be documented so that it can be found by users who want to > connect to ppc64 (or s390x) a year from now, when no one has the change > proposal in mind anymore? Is there at least a descriptive error message? When the conne

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

> Am 21.12.2022 um 22:49 schrieb Ben Cotton : > > Users with X server and client on two different machines must add the > `xorg.conf.d` snippet shown above on affected systems. How should this be documented so that it can be found by users who want to connect to ppc64 (or s390x) a year from no