Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[David Airlie]

On Thu, Apr 7, 2022 at 12:33 PM Luya Tshimbalanga
 wrote:
>
> Reading the comments, it seems the overlooked word is “depreciated” meaning 
> users will have time to properly transition their hardware.

Transition to what though, another distro?

moving to new hw won't help maintain things for older stuff.

I want to maintain one distro on the hw I maintain upstream drivers
for, this will stop me doing that with Fedora. I work for Red Hat, I
don't really want to move off Fedora, but having to keep Ubuntu and
Fedora mixtures would be a pita, and CentOS can't even build the newer
driver stacks without serious intervention.

Dave.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Schedule for Thursday's FPC Meeting (2022-04-07 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2022-04-07 16:00 UTC in #fedora-meeting-1 on
irc.libera.chat.

 Local time information (via. uitime):

= Day: Thursday ==
2022-04-07 09:00 PDT  US/Pacific
2022-04-07 12:00 EDT  --> US/Eastern <--
2022-04-07 16:00 UTC  UTC   
2022-04-07 17:00 BST  Europe/London 
2022-04-07 18:00 CEST Europe/Berlin 
2022-04-07 18:00 CEST Europe/Paris  
2022-04-07 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2022-04-08 00:00 HKT  Asia/Hong_Kong
2022-04-08 00:00 +08  Asia/Singapore
2022-04-08 01:00 JST  Asia/Tokyo
2022-04-08 02:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followup Actions =

#topic #pr-814
 * mhroncok
   talk to authors again, having a working example might help a lot

= Followup Issues =

#topic #886 Enable BRP for detecting RPATH 
.fpc 886
https://pagure.io/packaging-committee/issue/886

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

#topic #1058 How to handle %lang files in package owned directories? .fpc 1058
https://pagure.io/packaging-committee/issue/1058

#topic #1132 Mark comments as scriplets for Sources (automation) 
.fpc 1132
https://pagure.io/packaging-committee/issue/1132

#topic #1150 request for clarification wrt. base version / compat package 
naming 
.fpc 1150
https://pagure.io/packaging-committee/issue/1150

#topic #1159 Ban use of %configure in %prep
.fpc 1159
https://pagure.io/packaging-committee/issue/1159

= Followup Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines.
https://pagure.io/packaging-committee/pull-request/814

#topic #pr-1045 WIP: Add discussion of macro names beginning with underscores.
https://pagure.io/packaging-committee/pull-request/1045

#topic #pr-1071 Overhaul the RPATH section of the guidelines.
https://pagure.io/packaging-committee/pull-request/1071

#topic #pr-1097 Use caret in Obsoletes to simplify
https://pagure.io/packaging-committee/pull-request/1097

#topic #pr-1163 Sources: Add section about conditionalization 
https://pagure.io/packaging-committee/pull-request/1163

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * Bring it up at the end of the meeting, during the open floor topic. Note
    that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Revisiting ROCm packaging

[Jeremy Newton]

I made a thread late last year inquirying about interest in ROCm packaging; in 
that time I've introduced a few packages amd updated a few existing packages to 
the latest version.
Right now, Fedora is just short of making good use of ROCm, as it needs a 
frontend like OpenCL or HIP. I have a COPR where I've been experimenting on 
x86_64, aarch64, and ppc64le:
https://copr.fedorainfracloud.org/coprs/mystro256/rocm-opencl/

I would like to know if anyone is interested in maintaining, testing, or 
providing feedback on these packages. They're a bit rough around the edges, but 
ultimately I don't have the ability to be a primary maintainer for these. With 
that said, I encourage anyone to freely take my work as a starting point. I 
would also be intested in non-commitally helping keep packages up to date if 
they land in Fedora.

If you missed the original thread, I am an AMD employee, but my involvement in 
Fedora and packaging ROCm in Fedora is completely unrelated to my employment. 
I've been tinkering with rocm-opencl to make it better to package and I have a 
few patches in my COPR that I've been informally sharing with the developers. I 
didn't try to enable 32bit OpenCL given that 32bit has been falling out of 
favour, but I don't mind attempting to build it if there's a use for it.

HIP has a few more complicate issues to deal with, such as this:
https://src.fedoraproject.org/rpms/clang/pull-request/156

I think the one thing that bugs me the most is the bundling. Both of them 
bundle a static library called "ROCclr" and some older OpenCL headers. HIP also 
bundles some of rocm-opencl, along with a khronos header. If anyone is 
interested, I would like some feedback on how to tackle this.

Anyway thanks for reading :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2072835] New: perl-Encode-3.17 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2072835

Bug ID: 2072835
   Summary: perl-Encode-3.17 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Encode
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 3.17
Current version/release in rawhide: 3.16-484.fc36
URL: http://search.cpan.org/dist/Encode/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/2849/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2072835
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FESCo wants to know what you use i686 packages for

[Jeremy Newton]

It seems like my needs are pretty common: Steam, Wine, misc games (OpenGL, SDL, 
maybe vulkan, XWayland).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Luya Tshimbalanga]

Reading the comments, it seems the overlooked word is “depreciated” 
meaning users will have time to properly transition their hardware.
It seems the proposal suggests an opportunity to revisit the boot-loader 
like the heavily downstream patched grub2 deeming too complex to 
maintain in long term. Additionally, this proposal gives time to explore 
alternative boot loader like  systemd-boot (mainly for x86-64 
architecture and useful for desktop and workstation) and  rEFi (?) to 
further reduce the code burden.


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Dependency issue hwinfo/libx86emu

[Gemneye via epel-devel]

I have recently received dependency issues with a `yum update` on a 
CentOS 7 server.  I believe they are both epel packages (hwinfo and 
libx86emu)


It looks like hwinfo wants to upgrade to hwinfo.x86_64 0:21.68-1.el7 
from hwinfo.x86_64 0:21.47-6.el7.  It looks like libx86emu is a 
dependency for hwinfo.  It looks like libx86emu wants to update to 
libx86emu.x86_64 0:3.5-1.el7.


I believe the problem is hwinfo wants libx86emu.so.1, but 
libx86emu.x86_64 0:3.5-1.el7 wants to provide libx86emu.so.3.


This has been going on for about a week.  I tried uninstalling both 
hwinfo and libx86emu and re-installing, but that did not help.


Below is the actual output from `yum update`:

Error: Package: hwinfo-21.68-1.el7.x86_64 (epel)
   Requires: libx86emu.so.1()(64bit)
   Removing: libx86emu-1.1-2.1.x86_64 
(@/libx86emu-1.1-2.1.x86_64)

   libx86emu.so.1()(64bit)
   Updated By: libx86emu-3.5-1.el7.x86_64 (epel)
  ~libx86emu.so.3()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Any suggestions and help appreciated.

Thank You.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Justin Forbes]

On Wed, Apr 6, 2022 at 6:31 PM Chris Murphy  wrote:
>
> On Wed, Apr 6, 2022 at 10:23 AM Justin Forbes  wrote:
>
> > > Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all
> > > indicate Apple and Microsoft trust the driver itself. It is trusting
> > > the providence of the blob, in order to achieve an overall safer
> > > ecosystem for their users.
> > >
> > > We either want users with NVIDIA hardware to be inside the Secure Boot
> > > fold or we don't. I want them in the fold *despite* the driver that
> > > needs signing is proprietary. That's a better user experience across
> > > the board, including the security messaging is made consistent. The
> > > existing policy serves no good at all and is double talk. If we really
> > > care about security more than ideological worry, we'd sign the driver.
> >
> > At the very least, it would require that Fedora have a separate key
> > that is trusted and not the same one used for shim/grub/kernel.
>
> If Fedora is going to sign it, rather than improving the local signing
> experience, absolutely it should be signed with a separate key. The
> design should assume a revocation is going to happen at some point.
>
> > We
> > certainly aren't proposing that we use the standard Fedora keys to
> > sign a binary blob that runs in kernel space from a company who was
> > most recently hacked last month?
>
> No way.
>
> I don't think there's a mechanism for it, but I'd prefer Fedora sign
> the 3rd party's key rather than their binary. Maybe it's a small
> distinction at the end of the day.


We have not set up an infrastructure for it, but in all honesty, there
is no technical reason that any 3rd party repository building and
packaging the driver could not have done such a thing a couple of
years ago.  The mechanism has been there, pesign can sign modules.
Now, asking Fedora to trust that key is a different issue, but users
have to reboot after installing the nvidia drivers anyway, so clicking
to accept the key isn't too much of a hurdle to jump through at that
point.

Justin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: filesystems and year 2038

[Phillip Lougher]

> On Tue, Apr 5, 2022 at 8:48 AM Dusty Mabe  
> What about squashfs? We use that for the live media, is that affected?

No, Squashfs uses unsigned 32-bit ints, which will roll over in 2106.

Phillip

---
Squashfs author and maintainer.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Chris Murphy]

On Wed, Apr 6, 2022 at 10:23 AM Justin Forbes  wrote:

> > Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all
> > indicate Apple and Microsoft trust the driver itself. It is trusting
> > the providence of the blob, in order to achieve an overall safer
> > ecosystem for their users.
> >
> > We either want users with NVIDIA hardware to be inside the Secure Boot
> > fold or we don't. I want them in the fold *despite* the driver that
> > needs signing is proprietary. That's a better user experience across
> > the board, including the security messaging is made consistent. The
> > existing policy serves no good at all and is double talk. If we really
> > care about security more than ideological worry, we'd sign the driver.
>
> At the very least, it would require that Fedora have a separate key
> that is trusted and not the same one used for shim/grub/kernel.

If Fedora is going to sign it, rather than improving the local signing
experience, absolutely it should be signed with a separate key. The
design should assume a revocation is going to happen at some point.

> We
> certainly aren't proposing that we use the standard Fedora keys to
> sign a binary blob that runs in kernel space from a company who was
> most recently hacked last month?

No way.

I don't think there's a mechanism for it, but I'd prefer Fedora sign
the 3rd party's key rather than their binary. Maybe it's a small
distinction at the end of the day.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Neal Gompa]

On Wed, Apr 6, 2022 at 6:06 PM Brian C. Lane  wrote:
>
> On Tue, Apr 05, 2022 at 06:50:39PM -0600, Chris Murphy wrote:
> > On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton  wrote:
> > >syslinux goes away entirely
> >
> > If the installation media used BIOS GRUB, syslinux could still go
> > away. What consideration has occurred to switch from syslinux to BIOS
> > GRUB for installation media? Is BIOS GRUB being deprecated? Or is it
> > being discontinued in Fedora?
>
> A bit, long time time ago. I *think* wwoods and I discussed this at a
> fudcon at one point but there were reasons not to do it. But since I can
> no longer remember them I'll take a look again :)
>
> But if Anaconda is going to drop BIOS installation support at some point
> in the near future there really is no point in making the effort.
>

It would be useful if we do indeed get a x86 BIOS SIG as Hans de Goede
proposed. I think Fedora Server and Fedora Cloud would be interested
in such a thing, given all the caveats right now with dropping BIOS
support for server-class hardware.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Brian C. Lane]

On Tue, Apr 05, 2022 at 06:50:39PM -0600, Chris Murphy wrote:
> On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton  wrote:
> >syslinux goes away entirely
> 
> If the installation media used BIOS GRUB, syslinux could still go
> away. What consideration has occurred to switch from syslinux to BIOS
> GRUB for installation media? Is BIOS GRUB being deprecated? Or is it
> being discontinued in Fedora?

A bit, long time time ago. I *think* wwoods and I discussed this at a
fudcon at one point but there were reasons not to do it. But since I can
no longer remember them I'll take a look again :)

But if Anaconda is going to drop BIOS installation support at some point
in the near future there really is no point in making the effort.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: filesystems and year 2038

[Neal Gompa]

On Wed, Apr 6, 2022 at 5:52 PM Eric Sandeen  wrote:
>
> On 4/4/22 2:51 PM, Justin Forbes wrote:
> > On Mon, Apr 4, 2022 at 11:47 AM Colin Walters  wrote:
> >>
> >> Hi, creating a thread on this from:
> >> https://github.com/coreos/fedora-coreos-config/pull/1650
> >>
> >> Basically I'd propose that not just our default images have 
> >> y2038-compatible filesystem setups, we ensure that if e.g. XFS is 
> >> explicitly chosen for a Workstation installation then it is set up with 
> >> bigtime=1.
> >>
> >> (Note btrfs uses 64 bit time today, so I think this is mostly about ext4 
> >> and xfs, but perhaps we also need to look at the longer tail too, e.g. 
> >> squashfs.  OTOH, because squashfs is read-only we can just worry about 
> >> that closer to 10 years from now...)
> >>
> >> If no one objects I guess I can look at re-learning Mediawiki syntax again 
> >> and writing a Change.
> >
> > Or, you could ignore it and it will happen anyway:
> >
> > xfsprogs-5.15.0-rc1 (11 Mar 2022)
> > - mkfs: enable inobtcount and bigtime by default (Darrick J. Wong)
>
> *nod*
>
> I just pushed xfsprogs-5.15.0 out today and it'll be built in rawhide shortly.
> If we need this in released Fedoras I'm happy to push 5.15.0 to older
> releases as well.
>
> As for ext4, it might be wise to raise the small-filesystem issue on the
> ext4 list.
>
> OTOH, the ext4 "small" threshold is 512MB so another option might be to
> just be sure to size /boot to at least 512mb to get Y2038-happy inodes.
>
> else if (fs_blocks_count < 512 * meg)
> size_type = "small";
>

Anaconda already creates a one gigabyte ext4 /boot partition by
default for all Fedora variants except Server, where it uses xfs
instead.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: filesystems and year 2038

[Eric Sandeen]

On 4/4/22 2:51 PM, Justin Forbes wrote:
> On Mon, Apr 4, 2022 at 11:47 AM Colin Walters  wrote:
>>
>> Hi, creating a thread on this from:
>> https://github.com/coreos/fedora-coreos-config/pull/1650
>>
>> Basically I'd propose that not just our default images have y2038-compatible 
>> filesystem setups, we ensure that if e.g. XFS is explicitly chosen for a 
>> Workstation installation then it is set up with bigtime=1.
>>
>> (Note btrfs uses 64 bit time today, so I think this is mostly about ext4 and 
>> xfs, but perhaps we also need to look at the longer tail too, e.g. squashfs. 
>>  OTOH, because squashfs is read-only we can just worry about that closer to 
>> 10 years from now...)
>>
>> If no one objects I guess I can look at re-learning Mediawiki syntax again 
>> and writing a Change.
> 
> Or, you could ignore it and it will happen anyway:
> 
> xfsprogs-5.15.0-rc1 (11 Mar 2022)
> - mkfs: enable inobtcount and bigtime by default (Darrick J. Wong)

*nod*

I just pushed xfsprogs-5.15.0 out today and it'll be built in rawhide shortly.
If we need this in released Fedoras I'm happy to push 5.15.0 to older
releases as well.

As for ext4, it might be wise to raise the small-filesystem issue on the
ext4 list.

OTOH, the ext4 "small" threshold is 512MB so another option might be to
just be sure to size /boot to at least 512mb to get Y2038-happy inodes.

else if (fs_blocks_count < 512 * meg)
size_type = "small";

-Eric
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Neal Gompa]

On Wed, Apr 6, 2022 at 5:37 PM Demi Marie Obenour  wrote:
>
> On 4/6/22 16:59, Robbie Harwood wrote:
> > Demi Marie Obenour  writes:
> >
> >> On 4/5/22 12:29, Michael Catanzaro wrote:
> >>> On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood
> >>>  wrote:
>  Users wishing to use NVIDIA hardware have the following options:
> 
>  - Use nouveau (free, open source, cool)
>  - Sign their own copy of the proprietary driver (involves messing with
>    certificates, so not appropriate for all users)
>  - Disable Secure Boot (note that this is still UEFI)
> 
>  The NVIDIA driver is proprietary, so of course it's not going to get
>  signed.
> >>>
> >>> The user experience requirement is: user searches for NVIDIA in GNOME
> >>> Software and clicks Install. No further action should be
> >>> necessary. We didn't make the NVIDIA driver available from the
> >>> graphical installer with the intention that arcane workarounds would
> >>> be required to use it.
> >>
> >> Bingo.  None of the three options Robbie suggested are reasonable for
> >> non-technical users.
> >
> > No, I don't think that's right.  It's been a bit since I've run nvidia
> > hardware, but I'm pretty sure using nouveau is the default.  It's less
> > powerful than the proprietary driver, but if it works out of the box,
> > it's really difficult to argue with that user experience.
>
> Nouveau does not support any graphics acceleration on Ampere, and its
> performance is very poor on Maxwell and later.

Put more concretely in terms of user experience: nouveau causes
regular, random, immediate system freezes with RTX 20 series and RTX
30 series GPUs.

The only safe workaround is to force VGA/VESA mode until the NVIDIA
proprietary driver is installed.

I experienced this problem last week[1] and it's pretty consistent
across the board.

[1]: https://twitter.com/Det_Conan_Kudo/status/1508968025785049088




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Robbie Harwood]

Demi Marie Obenour  writes:

> On 4/6/22 16:59, Robbie Harwood wrote:
>> Demi Marie Obenour  writes:
>> 
>>> On 4/5/22 12:29, Michael Catanzaro wrote:
 On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood 
  wrote:
> Users wishing to use NVIDIA hardware have the following options:
>
> - Use nouveau (free, open source, cool)
> - Sign their own copy of the proprietary driver (involves messing with
>   certificates, so not appropriate for all users)
> - Disable Secure Boot (note that this is still UEFI)
>
> The NVIDIA driver is proprietary, so of course it's not going to get
> signed.

 The user experience requirement is: user searches for NVIDIA in GNOME
 Software and clicks Install. No further action should be
 necessary. We didn't make the NVIDIA driver available from the
 graphical installer with the intention that arcane workarounds would
 be required to use it.
>>>
>>> Bingo.  None of the three options Robbie suggested are reasonable for
>>> non-technical users.
>> 
>> No, I don't think that's right.  It's been a bit since I've run nvidia
>> hardware, but I'm pretty sure using nouveau is the default.  It's less
>> powerful than the proprietary driver, but if it works out of the box,
>> it's really difficult to argue with that user experience.
>
> Nouveau does not support any graphics acceleration on Ampere, and its
> performance is very poor on Maxwell and later.

That may be true, but that has nothing to do with what non-technical
users are capable of doing to their systems.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Demi Marie Obenour]

On 4/6/22 16:59, Robbie Harwood wrote:
> Demi Marie Obenour  writes:
> 
>> On 4/5/22 12:29, Michael Catanzaro wrote:
>>> On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood 
>>>  wrote:
 Users wishing to use NVIDIA hardware have the following options:

 - Use nouveau (free, open source, cool)
 - Sign their own copy of the proprietary driver (involves messing with
   certificates, so not appropriate for all users)
 - Disable Secure Boot (note that this is still UEFI)

 The NVIDIA driver is proprietary, so of course it's not going to get
 signed.
>>>
>>> The user experience requirement is: user searches for NVIDIA in GNOME
>>> Software and clicks Install. No further action should be
>>> necessary. We didn't make the NVIDIA driver available from the
>>> graphical installer with the intention that arcane workarounds would
>>> be required to use it.
>>
>> Bingo.  None of the three options Robbie suggested are reasonable for
>> non-technical users.
> 
> No, I don't think that's right.  It's been a bit since I've run nvidia
> hardware, but I'm pretty sure using nouveau is the default.  It's less
> powerful than the proprietary driver, but if it works out of the box,
> it's really difficult to argue with that user experience.

Nouveau does not support any graphics acceleration on Ampere, and its
performance is very poor on Maxwell and later.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Robbie Harwood]

Demi Marie Obenour  writes:

> On 4/6/22 06:43, Neal Gompa wrote:
>> On Wed, Apr 6, 2022 at 12:04 AM Gary Buhrmaster
>>  wrote:
>>>
>>> On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour
>>>  wrote:

 On 4/5/22 19:38, Chris Murphy wrote:
> We either want users with NVIDIA hardware to be inside the Secure Boot
> fold or we don't. I want them in the fold *despite* the driver that
> needs signing is proprietary. That's a better user experience across
> the board, including the security messaging is made consistent. The
> existing policy serves no good at all and is double talk. If we really
> care about security more than ideological worry, we'd sign the driver.

 I agree with this.  Sign the driver.
>>>
>>> Nvidia has their driver signed for their
>>> Windows drivers.  That they choose
>>> not to do so for Linux is their right,
>>> even if some wish they did.
>>>
>>> It should be noted that while many
>>> might wish nvidia chose a different
>>> way, that is completely orthogonal
>>> to bios vs uefi.
>> 
>> Linux, like Windows, requires the distribution vendor to sign modules
>> for automatic trust. There are a number of complicated issues that
>> make it difficult for us to sign this particular driver, though.
>> Notably, NVIDIA themselves acknowledges that it infringes on the GPL
>> to redistribute built kernel module blobs of nvidia.ko[1], so that means
>> any method of signing it needs to be done locally, which means we
>> *need* the local signing path to be improved.
>> 
>> [1]: https://imgur.com/LUCQ3WW
>
> Can we get NVIDIA to make the module build reproducible?  If so, we
> could distribute a detached signature.

nvidia's module is proprietary.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Robbie Harwood]

Dominik 'Rathann' Mierzejewski  writes:

> On Wednesday, 06 April 2022 at 13:07, Richard Hughes wrote:
>> Dominik 'Rathann' Mierzejewski  wrote:
>>
 and on its way out.  As it ages, maintainability has decreased, and
 the status quo of maintaining both stacks in perpetuity is not viable
 for those currently doing that work.
>>>
>>> Have you tried getting more people involved?
>> 
>> I don't think that's how Open Source works. Realistically the way I
>> see this playing out is that the people responsible for maintaining
>> the legacy boot stack will retire the packages,
>
> I thought they would be orphaned, if anything. Retiring seems rather
> hostile to the people who still need those packages

Assume good intent, please :)

I believe Richard's comment is about a hypothetical future, not what's
written in the change propsal in front of us.  I also don't think
Richard's point in any way hinges on the distinction between orphaning
and retiring.

> (which are those, by the way?).
>
> It's helpful to show the change proponents attitude. As a way of
> "asking more people to get involved", I'd expect a list of packages
> the change proponents no longer whish to maintain and a date when they
> will orphan them, since they've stated they're going to do that
> anyway. Without such list it's difficult to assess the scope of the
> work required to maintain the affected software stack. I don't see any
> such details in the change proposal.

There's no list there because I don't believe that's a helpful way to
view the problem.  For instance, grub2 supports both legacy and UEFI
paths - so one can't cleanly say "this package supports one, this
package supports the other" like when trimming a dependency chain.
(This is especially true when thinking about bootloaders, which tend
toward being small operating systems unto themselves.)  It's more
realistic to consider use cases: legacy is a separate system bringup
path.  The work is the entire path, not a package.

(Lest I be accused of dodging the question: for me, the relevant
packages are parts of grub2 and all of syslinux.)

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Robbie Harwood]

Demi Marie Obenour  writes:

> On 4/5/22 12:29, Michael Catanzaro wrote:
>> On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood 
>>  wrote:
>>> Users wishing to use NVIDIA hardware have the following options:
>>>
>>> - Use nouveau (free, open source, cool)
>>> - Sign their own copy of the proprietary driver (involves messing with
>>>   certificates, so not appropriate for all users)
>>> - Disable Secure Boot (note that this is still UEFI)
>>>
>>> The NVIDIA driver is proprietary, so of course it's not going to get
>>> signed.
>> 
>> The user experience requirement is: user searches for NVIDIA in GNOME
>> Software and clicks Install. No further action should be
>> necessary. We didn't make the NVIDIA driver available from the
>> graphical installer with the intention that arcane workarounds would
>> be required to use it.
>
> Bingo.  None of the three options Robbie suggested are reasonable for
> non-technical users.

No, I don't think that's right.  It's been a bit since I've run nvidia
hardware, but I'm pretty sure using nouveau is the default.  It's less
powerful than the proprietary driver, but if it works out of the box,
it's really difficult to argue with that user experience.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 06, 2022 at 11:02:17AM -0400, Robbie Harwood wrote:
> "Andre Robatino"  writes:
> 
> > Those figures are recommended minimums, not requirements. I have a
> > single core F35 machine which works fine.
> 
> It's important to note here that "works fine" isn't the same as "is
> supported".
> 
> My reading of that document is that if one goes below what's laid out in
> "Minimum System Configuration", here be dragons, trouble may happen, and
> to varying degrees, one is on their own.  And that those dangers are why
> there's a "Recommended System Configuration" in the next section.

I think that's reading too much into the "Recommended Config". In particular
machines with less CPU will be completely usable — just slow. With RAM,
it's more complicated. But in particular with ZRAM we effectively trade
CPU cycles for more memory. So the details of when a machine stop being
"useful" depends immensly on the usecase. The *recommended* configuration
applies to a graphical boot and some typical desktop use. If you use sway or 
xfce
instead of gnome or kde, or you don't use firefox but e.g. just listen to music
on the machine, a machine with a fraction of recommended resources may be
just fine.

I think our users are smart: they will understand — and not complain —
that an old laptop with 2GB of RAM is not a video editing workstation.
Even if many developers personally have newer and beefier hardware, we
should keep in mind that there are geographical regions and non-developer
folks with more varied hardware.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Javier Martinez Canillas]

On Wed, Apr 6, 2022 at 5:51 PM Jared Dominguez  wrote:

[snip]

>
> Per my reply to you yesterday, I would be grateful if you would list out 
> examples here. This is the second time I've heard this, and it's not concrete 
> enough for a constructive conversation on that topic.
>
>> 2. The packages are locked down so there is no way for the community to help
>> 3. At various times, people have explicitly said "patches NOT welcome"
>
>
> Robbie already responded to this, but I would like to add that if any of this 
> ever actually becomes true, I would like to know so that I can address any 
> such issue with this Red Hat team. From what I've seen, we very much welcome 
> community involvement. In fact, we are collaborating on a daily basis with 
> the bootloader community on grub2 and shim development.
>

As Robbied said, I added the /etc/dnf/protected.d/grub2-*.conf to the
grub2 package after Neal filed that BZ and he also mentioned to me
back then that pull requests were disabled for the grub2 dist-git and
I re-enabled it after asking Peter if he was OK with that (and he told
me that sure go ahead).

BTW, Peter also did the same for shim and added
/etc/dnf/protected.d/shim.conf even though the dist-git for shim was
open at the time. So I don't see how grub2 dist-git not having pull
requests enabled (for whatever reasons) could be a blocker since a
change for shim wasn't proposed either. I mean, one could attach a
patch in the BZ, send an email to a maintainer, etc. Is not that PRs
in dist-git is not the only possible way to share a diff...

Anyway, I also personally never said "patches NOT welcome" to anyone.
It may be that I didn't have time to review/apply some proposed but
that's a different thing.

Best regards,
Javier
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Michael Catanzaro]

On Wed, Apr 6 2022 at 03:35:38 PM -0400, Jared Dominguez 
 wrote:
This seems like a strong assumption to me considering that aside from 
the largest cloud providers (with whom Red Hat is directly working 
with on UEFI boot features and bug reports), cloud providers are 
using off-the-shelf hypervisors that support UEFI boot.


I'm going to ask the proposal authors to at least mention this as a 
risk in the Feedback section of the change proposal. Maybe cloud 
providers will all see this as a good opportunity to enable UEFI on 
their platforms, and we'll be perfectly fine. I rather suspect it's not 
going to happen quite so smoothly, though


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Hans de Goede]

Hi,

On 4/6/22 16:23, Neal Gompa wrote:
> On Wed, Apr 6, 2022 at 10:18 AM Hans de Goede  wrote:
>>
>> Hi,
>>
>> >  behalf of my employer (Red Hat)>
>>
>> On 4/5/22 16:52, Ben Cotton wrote:
>>> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>>
>> 
>>
>>> Fedora already requires a 2GHz dual core CPU at minimum (and therefore
>>> mandates that machines must have been made after 2006).
>>
>> But machines made between 2006-2012 generally did not have
>> EFI support, anf for example at home I still have several
>> machines from that era which are BIOS only in active use:
>>
>> 1. My daughter's workstation is an i5-2400 with 8G RAM, this
>> is a 3.1 GHz base-freq quad-core processor very easily
>> matching Fedora's minimal requirements. Currently running
>> Fedora 35 just fine. Making it impossible to keep using this
>> in the future is just causing unnecessary ewaste for no good
>> reason IMHO.
>>
>> 2. My wife's workstation is a Core 2 Duo E6600 2.4 Ghz dual
>> core machine with 4G RAM, which also still works fine for
>> what she uses it for.
>>
>> 3. The living room laptop is another Core 2 Duo machine with
>> 4G RAM.
>>
>> Looking specifically at fixed PCs and not laptops this
>> proposal would (eventually) turn 2/5 PCs in my home
>> unusable, which really is unacceptable IMHO.
>>
>> Also note that all these machines use somewhat older Intel
>> integrated graphics. As he has already mentioned on this
>> this thread, Dave Airlie has just spend a lot of time on
>> making sure those iGPU-s will work with a gallium driver
>> so that the classic mesa code can be removed and it seems
>> rather silly to drop support for this hw after just investing
>> a significant chunk of time to breathe new live into their
>> GPU support.
>>
>> So a big -1 from me for this proposal as it stand.
>>
>> ###
>>
>> But I do completely understand that there is a workload issue
>> for the bootloader team and the proposal also mentions:
>>
>>> == Contingency Plan ==
>>> Leave things as they are.  Code continues to rot.  Community
>>> assistance is required to continue the status quo.  Current owners
>>> plan to orphan some packages regardless of whether the proposal is
>>> accepted.
>>
>> If the current owners no longer want to support some packages
>> which are only necessary for legacy BIOS support, then orphaning
>> these seems completely reasonable to me.
>>
>> Maybe you can provide a list of these pkgs before hand so that
>> people can already volunteer as co-maintainers now and then
>> when they are orphaned, instead of orphaning them they can
>> be directly handed over (using the "give away" button) to the
>> new maintainers ?
>>
>>> Another fallback option could be, if a Legacy BIOS SIG organizes, to
>>> donate the relevant packages there and provide some initial mentoring.
>>
>> I believe that that is a great idea, I hereby volunteer to
>> try and setup such a SIG. If anyone reading this is interested
>> in joining such a SIG please drop me an email.
>>
>> I realize that there have been similar attempts around keeping
>> 32 bit x86 alive and that those have failed, but I believe that
>> this is different for a number of reasons:
>>
>> 1. i686 support required making sure that *all* of Fedora kept
>> working on i686, the problem was not just the kernel breaking
>> sometimes, but also that huge projects like libreoffice would
>> no longer start on i686 (at least on some of my machines).
>>
>> Legacy BIOS boot support is basically only about the image-creation
>> tools + the bootloader. As various people have mentioned in the
>> thread BIOS support is still very much a thing in data-centers,
>> so I expect the upstream kernel community to keep the kernel
>> working with this for at least a couple of years. Where as both
>> the kernel + many userspace apps were breaking on i686.
>>
>> 2. I personally basically gave up on i686 support also because
>> there was very little 32 bit only x86 hw around remaining in
>> active use when it was dropped. And what was still on active
>> use was getting close to unusable from a performance pov.
>> Where as here we are talking about up to 2nd and 3th gen
>> core i5 / i7 machines which are still quite performant.
>>
>> Esp. the 2nd gen core machines (Sandy Bridge) are still
>> quite popular and lots of people have hung on to desktops
>> with those because the CPU performance increase in generations
>> after SNB have been rather underwhelming.
>>
>>> Longer term, packages that cannot be wholly donated could be split,
>>> though it is unclear whether the synchronization thereby required
>>> would reduce the work for anyone.
>>
>> I've been thinking about how this could be done for grub; also
>> because of the issue that the EFI builds of grub need to be
>> signed with Fedora's secure boot keys, which means only a few
>> people can do grub2 builds atm.
>>
>> One option which I think we should consider is sticking with
>> a single downstream git fork (until we have managed to get
>> 

Re: Landing a larger-than-release change (distrusting SHA-1 signatures)

[Stephen Gallagher]

On Wed, Apr 6, 2022 at 10:43 AM Stephen Gallagher  wrote:
>
> On Wed, Apr 6, 2022 at 7:09 AM Alexander Sosedkin  
> wrote:
> >
> > On Wed, Apr 6, 2022 at 1:00 PM Vít Ondruch  wrote:
> ...
> > > Alexander,
> > >
> > > Could this be enabled in ELN? This is not really question but
> > > suggestion. It is unfortunate, that ELN, while intermediate step for c9s
> > > does not have this enabled yet.
> > >
> > > For example, we are working on Ruby 3.1 for c9s [1] just to figure that
> > > while everything just works in Fedora/ELN, it does not work in c9s.
> > > Maybe working with ELN would make the migrations easier also for Fedora.
> > >
> > >
> > > Vít
> >
> > It's on my plans, but it'd take some time as it's not trivial.
> >
>
> Alexander, I can try to help you with this if you need it. Just let me know.

I put together a potential solution for testing this in ELN and
submitted an MR:
https://src.fedoraproject.org/rpms/crypto-policies/pull-request/10

It's a little bit heavy-handed of an approach, but it should work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Batch updates PETSc-3.17 hypre-2.24.0 superlu_dist-7.2.0

[David]

On 4/6/22 18:58, Antonio T. sagitter wrote:

Hi all.

This is the upgrade of some libraries in Rawhide:

petsc-3.17:

$ dnf repoquery --whatrequires 'libpetsc*.so*' --source | sort -u


bout++-4.4.0-2.fc35.src.rpm

dolfin-2019.1.0.post0-21.fc35.src.rpm

getdp-3.3.0-12.fc35.src.rpm


PETSc-3.17 needs superlu_dist-6.3.0 at least, so i prepared a new recent 
release of superlu_dist-7.2.0 that uses CMake as configuration tool 
(https://src.fedoraproject.org/rpms/superlu_dist/pull-request/1):


$ dnf repoquery --whatrequires 'libsuperlu_dist*.so*' --source | sort -u

amg4psblas-1.0.0-4.fc35.src.rpm

hypre-2.18.2-4.fc35.src.rpm

petsc-3.15.3-2.fc35.src.rpm

Current Hypre release does not compile against superlu_dist-7.2, so i 
built Hypre-2.24.0, the last one.


$ dnf repoquery --whatrequires 'libHYPRE*.so*' --source | sort -u

petsc-3.15.3-2.fc35.src.rpm

sundials-5.7.0-3.fc35.src.rpm

The circle of the dependencies should be closed:
https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/builds/

If all maintainers agree, i can create a side-tag for these new builds.



Why not update sundials as well?
Is only BOUT++ blocking that?

Thanks for working on this,
David
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Neal Gompa]

On Wed, Apr 6, 2022 at 4:09 PM Demi Marie Obenour  wrote:
>
> On 4/6/22 06:43, Neal Gompa wrote:
> > On Wed, Apr 6, 2022 at 12:04 AM Gary Buhrmaster
> >  wrote:
> >>
> >> On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour
> >>  wrote:
> >>>
> >>> On 4/5/22 19:38, Chris Murphy wrote:
>  We either want users with NVIDIA hardware to be inside the Secure Boot
>  fold or we don't. I want them in the fold *despite* the driver that
>  needs signing is proprietary. That's a better user experience across
>  the board, including the security messaging is made consistent. The
>  existing policy serves no good at all and is double talk. If we really
>  care about security more than ideological worry, we'd sign the driver.
> >>>
> >>> I agree with this.  Sign the driver.
> >>
> >> Nvidia has their driver signed for their
> >> Windows drivers.  That they choose
> >> not to do so for Linux is their right,
> >> even if some wish they did.
> >>
> >> It should be noted that while many
> >> might wish nvidia chose a different
> >> way, that is completely orthogonal
> >> to bios vs uefi.
> >
> > Linux, like Windows, requires the distribution vendor to sign modules
> > for automatic trust. There are a number of complicated issues that
> > make it difficult for us to sign this particular driver, though.
> > Notably, NVIDIA themselves acknowledges that it infringes on the GPL
> > to redistribute built kernel module blobs of nvidia.ko[1], so that means
> > any method of signing it needs to be done locally, which means we
> > *need* the local signing path to be improved.
> >
> > [1]: https://imgur.com/LUCQ3WW
>
> Can we get NVIDIA to make the module build reproducible?  If so, we
> could distribute a detached signature.
>

Outside of RHEL (which they already do this for), it is not
technically feasible to do so. The mainline Linux kernel lacks a kABI
and symbol churn happens constantly. The modules have to be built
completely from source every time, dealing with kernel churn making
the resulting files different every time.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Demi Marie Obenour]

On 4/6/22 06:43, Neal Gompa wrote:
> On Wed, Apr 6, 2022 at 12:04 AM Gary Buhrmaster
>  wrote:
>>
>> On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour
>>  wrote:
>>>
>>> On 4/5/22 19:38, Chris Murphy wrote:
 We either want users with NVIDIA hardware to be inside the Secure Boot
 fold or we don't. I want them in the fold *despite* the driver that
 needs signing is proprietary. That's a better user experience across
 the board, including the security messaging is made consistent. The
 existing policy serves no good at all and is double talk. If we really
 care about security more than ideological worry, we'd sign the driver.
>>>
>>> I agree with this.  Sign the driver.
>>
>> Nvidia has their driver signed for their
>> Windows drivers.  That they choose
>> not to do so for Linux is their right,
>> even if some wish they did.
>>
>> It should be noted that while many
>> might wish nvidia chose a different
>> way, that is completely orthogonal
>> to bios vs uefi.
> 
> Linux, like Windows, requires the distribution vendor to sign modules
> for automatic trust. There are a number of complicated issues that
> make it difficult for us to sign this particular driver, though.
> Notably, NVIDIA themselves acknowledges that it infringes on the GPL
> to redistribute built kernel module blobs of nvidia.ko[1], so that means
> any method of signing it needs to be done locally, which means we
> *need* the local signing path to be improved.
> 
> [1]: https://imgur.com/LUCQ3WW

Can we get NVIDIA to make the module build reproducible?  If so, we
could distribute a detached signature.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2071865] perl-libwww-perl-6.62 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2071865



--- Comment #7 from Fedora Update System  ---
FEDORA-2022-1bbb291854 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2022-1bbb291854`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-1bbb291854

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2071865
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2062023] [RFE: EPEL9] EPEL9 branch for perl-Net-Netmask

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2062023

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2022-a73255745c has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-a73255745c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2062023
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Jared Dominguez]

On Wed, Apr 6, 2022 at 2:26 PM Michael Catanzaro 
wrote:

> On Wed, Apr 6 2022 at 01:57:00 PM -0400, Neal Gompa
>  wrote:
> > Moving past the Big Three(tm), the actual
> > cloud providers that matter from a Fedora context are the smaller
> > outfits that principally serve Linux users. These are companies like
> > DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
> > graciously do offer Fedora Linux in their platforms. All of their
> > virtualization platforms are BIOS only right now, and getting them to
> > switch requires them to uplift their platforms to support UEFI in the
> > first place.


This seems like a strong assumption to me considering that aside from the
largest cloud providers (with whom Red Hat is directly working with on UEFI
boot features and bug reports), cloud providers are using off-the-shelf
hypervisors that support UEFI boot.


> And again, when UEFI means things like VM snapshots and
>

I've raised this within Red Hat's virtualization team.


> > cloud hibernation don't work, it's not very compelling.
>

AWS, for example has other situations in which this limitation exists:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-hibernate-limitations.html
But this is also something that can be fixed.


> I suppose we should consider that all or most of these platforms are
> likely to drop Fedora as a supported option if we proceed with this
> change proposal.
>

Why? VMware vSphere dropped legacy x86 boot support recently too. We
already know that Windows 11 requires UEFI. We (Red Hat) are actively
working with several cloud providers on UEFI-related features, some of
which are not possible with legacy x86 boot. I find it much more likely
that smaller cloud providers will update their software to support UEFI
rather than drop OS's that require it, at least if they want to remain
competitive.


> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Jared Dominguez (he/him)
Software Engineering Manager
New Platform Technologies Enablement team
RHEL Workstation Engineering
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2071865] perl-libwww-perl-6.62 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2071865



--- Comment #6 from Fedora Update System  ---
FEDORA-2022-e63545a43c has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2022-e63545a43c`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-e63545a43c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2071865
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Florian Weimer]

* Adam Jackson:

> 2 - How is this our problem to solve? NVIDIA are the ones with the
> private source code.

Isn't it Fedora's decision to require kernel module signing when Secure
Boot is active?  So it's actually us who create the problem in the first
place?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Michael Catanzaro]

On Wed, Apr 6 2022 at 01:57:00 PM -0400, Neal Gompa 
 wrote:

Moving past the Big Three(tm), the actual
cloud providers that matter from a Fedora context are the smaller
outfits that principally serve Linux users. These are companies like
DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
graciously do offer Fedora Linux in their platforms. All of their
virtualization platforms are BIOS only right now, and getting them to
switch requires them to uplift their platforms to support UEFI in the
first place. And again, when UEFI means things like VM snapshots and
cloud hibernation don't work, it's not very compelling.


I suppose we should consider that all or most of these platforms are 
likely to drop Fedora as a supported option if we proceed with this 
change proposal.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora Linux 36 Final Go/No-Go meeting next week

[Ben Cotton]

Hi everyone,

The Fedora Linux 36 Final Go/No-Go meeting[1] is scheduled for
Thursday 14 April at 1700 UTC in #fedora-meeting. At this time, we
will determine the status of the F36 Final for the 19 April early
target date[2]. For more information about the Go/No-Go meeting, see
the wiki[3].

[1] https://calendar.fedoraproject.org/meeting/10237
[2] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
[3] https://fedoraproject.org/wiki/Go_No_Go_Meeting

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] Fedora Linux 36 Final Go/No-Go meeting next week

[Ben Cotton]

Hi everyone,

The Fedora Linux 36 Final Go/No-Go meeting[1] is scheduled for
Thursday 14 April at 1700 UTC in #fedora-meeting. At this time, we
will determine the status of the F36 Final for the 19 April early
target date[2]. For more information about the Go/No-Go meeting, see
the wiki[3].

[1] https://calendar.fedoraproject.org/meeting/10237
[2] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
[3] https://fedoraproject.org/wiki/Go_No_Go_Meeting

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1972955] perl-Mail-Sender: retire from epel8

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1972955

Carl George 鸞  changed:

   What|Removed |Added

 Blocks||1998160 (EPEL2RHEL)





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1998160
[Bug 1998160] EPEL to RHEL package removal tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1972955
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Neal Gompa]

On Wed, Apr 6, 2022 at 11:50 AM Jared Dominguez  wrote:
>
>
>
> On Wed, Apr 6, 2022 at 8:20 AM Neal Gompa  wrote:
>>
>> On Wed, Apr 6, 2022 at 8:04 AM Vít Ondruch  wrote:
>> >
>> >
>> > Dne 05. 04. 22 v 17:08 Neal Gompa napsal(a):
>> > > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton  wrote:
>> > >> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>> > >>
>> > >> == Summary ==
>> > >> Make UEFI a hardware requirement for new Fedora installations on
>> > >> platforms that support it (x86_64).  Legacy BIOS support is not
>> > >> removed, but new non-UEFI installation is not supported on those
>> > >> platforms.  This is a first step toward eventually removing legacy
>> > >> BIOS support entirely.
>> > >>
>> > >> == Owner ==
>> > >> * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
>> > >> Konečný]], [[User:bcl| Brian C. Lane]]
>> > >> * Email: rharw...@redhat.com
>> > >>
>> > >>
>> > >> == Detailed Description ==
>> > >> UEFI is defined by a versioned standard that can be tested and
>> > >> certified against.  By contrast, every legacy BIOS is unique. Legacy
>> > >> BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
>> > >> and on its way out.  As it ages, maintainability has decreased, and
>> > >> the status quo of maintaining both stacks in perpetuity is not viable
>> > >> for those currently doing that work.
>> > >>
>> > >> It is inevitable that legacy BIOS will be removed in a future release.
>> > >> To ease this transition as best we can, there will be a period (of at
>> > >> least one Fedora release) where it will be possible to boot using the
>> > >> legacy BIOS codepaths, but new installations will not be possible.
>> > >> While it would be easier for us to cut support off today, our hope is
>> > >> that this compromise position will make for a smoother transition.
>> > >> Additional support with issues during the transition would be
>> > >> appreciated.
>> > >>
>> > >> While this will eventually reduce workload for boot/installation
>> > >> components (grub2 reduces surface area, syslinux goes away entirely,
>> > >> anaconda reduces surface area), the reduction in support burden
>> > >> extends much further into the stack - for instance, VESA support can
>> > >> be removed from the distro.
>> > >>
>> > >> Fedora already requires a 2GHz dual core CPU at minimum (and therefore
>> > >> mandates that machines must have been made after 2006).  Like the
>> > >> already accepted Fedora 37 change to retire ARMv7 support, the
>> > >> hardware targeted tends to be rather underpowered by today’s
>> > >> standards, and the world has moved on from it.  Intel stopped shipping
>> > >> the last vestiges of BIOS support in 2020 (as have other vendors, and
>> > >> Apple and Microsoft), so this is clearly the way things are heading -
>> > >> and therefore aligns with Fedora’s “First” objective.
>> > >>
>> > >> == Feedback ==
>> > >> Dropping legacy BIOS was previously discussed (but not proposed) in 
>> > >> 2020:
>> > >> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/
>> > >>
>> > >> Important, relevant points from that thread (yes, I reread the entire
>> > >> thread) that have informed this change:
>> > >>
>> > >> * Some machines are BIOS-only.  This change does not prevent their use
>> > >> yet, but they are effectively deprecated.  grub2 (our default
>> > >> bootloader) is already capable of both BIOS and UEFI booting.
>> > >> * Drawing a clear year cutoff, let alone a detailed list of hardware
>> > >> this change affects, is basically impossible.  This is unfortunate but
>> > >> unlikely to ever change.
>> > >> * There is no migration story from Legacy BIOS to UEFI -
>> > >> repartitioning effectively mandates a reinstall.  As a result, we
>> > >> don’t drop support for existing Legacy BIOS systems yet, just new
>> > >> installations.
>> > >> * There is no way to deprecate hardware without causing some amount of 
>> > >> friction.
>> > >> * While at the time AWS did not support UEFI booting, that is no
>> > >> longer the case and they support UEFI today.
>> > >>
>> > >> == Benefit to Fedora ==
>> > >> UEFI is required for many desirable features, including applying
>> > >> firmware updates (fwupd) and supporting SecureBoot.  As a standalone
>> > >> change, it reduces support burden on everything involved in installing
>> > >> Fedora, since there becomes only one way to do it per platform.
>> > >> Finally, it simplifies our install/live media, since it too only has
>> > >> to boot one way per arch.  Freedom Friends Features First - this is
>> > >> that last one.
>> > >>
>> > >> == Scope ==
>> > >> * Proposal owners:
>> > >> ** bootloaders: No change (existing Legacy BIOS installations still 
>> > >> supported).
>> > >> ** anaconda: No change (there could be only optional cleanups in the
>> > >> code). However, it needs to be verified.
>> > >> ** Lorax: Code has already been written:
>> > >> 

[Bug 2071865] perl-libwww-perl-6.62 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2071865

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-2022-4f5421b8cc has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2022-4f5421b8cc`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-4f5421b8cc

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2071865
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora CoreOS Meeting Minutes 2022-04-06

[Dusty Mabe]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-04-06/fedora_coreos_meeting.2022-04-06-16.30.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-04-06/fedora_coreos_meeting.2022-04-06-16.30.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-04-06/fedora_coreos_meeting.2022-04-06-16.30.log.html


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:30:58 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-04-06/fedora_coreos_meeting.2022-04-06-16.30.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:31:02)

* Action items from last meeting   (dustymabe, 16:35:33)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/392
(dustymabe, 16:36:08)
  * we will pursue a tactical fix in Ignition for the short-term while
keeping an eye on the systemd change and exploring broader changes
in Ignition  (jlebon, 16:44:32)

* F36: Fedora CoreOS Test Week  (dustymabe, 16:44:54)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1123
(dustymabe, 16:45:01)
  * LINK: https://testdays.fedoraproject.org/events/131   (dustymabe,
16:45:39)
  * LINK: https://hackmd.io/VP65or6ZSwmOwErt7e7JnQ   (dustymabe,
16:46:31)
  * LINK: https://github.com/coreos/fedora-coreos-docs/pull/377/files
(dustymabe, 16:48:39)

* tracker: This Month in Fedora CoreOS March 2022 community  (dustymabe,
  16:50:15)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1117
(dustymabe, 16:50:20)

* open floor  (dustymabe, 16:55:00)
  * LINK:

https://siosm.fedorapeople.org/What_s_new_and_what_s_next_in_Fedora_CoreOS_-_Nest_with_Fedora_2021.pdf
(travier, 17:01:46)

Meeting ended at 17:05:25 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (65)
* zodbot (19)
* jlebon (17)
* bgilbert (6)
* travier (5)
* skunkerk (4)
* jdoss (4)
* mnguyen (1)
* miabbott_ (1)
* miabbott (1)
* walters (1)
* lorbus (1)
* ravanelli (1)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Batch updates PETSc-3.17 hypre-2.24.0 superlu_dist-7.2.0

[Antonio T. sagitter]

Hi all.

This is the upgrade of some libraries in Rawhide:

petsc-3.17:

$ dnf repoquery --whatrequires 'libpetsc*.so*' --source | sort -u


bout++-4.4.0-2.fc35.src.rpm

dolfin-2019.1.0.post0-21.fc35.src.rpm

getdp-3.3.0-12.fc35.src.rpm


PETSc-3.17 needs superlu_dist-6.3.0 at least, so i prepared a new recent 
release of superlu_dist-7.2.0 that uses CMake as configuration tool 
(https://src.fedoraproject.org/rpms/superlu_dist/pull-request/1):


$ dnf repoquery --whatrequires 'libsuperlu_dist*.so*' --source | sort -u

amg4psblas-1.0.0-4.fc35.src.rpm

hypre-2.18.2-4.fc35.src.rpm

petsc-3.15.3-2.fc35.src.rpm

Current Hypre release does not compile against superlu_dist-7.2, so i 
built Hypre-2.24.0, the last one.


$ dnf repoquery --whatrequires 'libHYPRE*.so*' --source | sort -u

petsc-3.15.3-2.fc35.src.rpm

sundials-5.7.0-3.fc35.src.rpm

The circle of the dependencies should be closed:
https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/builds/

If all maintainers agree, i can create a side-tag for these new builds.

--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0xCC1CFEF30920C8AE
GPG key server: https://keyserver1.pgp.com/


OpenPGP_0xCC1CFEF30920C8AE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Heads up: python-redis 4.2.1

[Miro Hrončok]

On 04. 04. 22 10:51, Frantisek Zatloukal wrote:
I'll handle all the rebuilds of packages BuildRequiring and Requiring 
python-redis in a side-tag, I'll reply here with the exact side-tag once it 
gets created if somebody wants to build their package there.


Is there any particular reason why the packages BuildRequiring and Requiring 
python-redis need to be rebuilt? Is there some kind of ABI that is determine 
din the packages at build time? This is not very common for Python packages.


A targeted rebuild of dependent packages is needed when e.g. C library changes 
its soname version or when packages require e.g. perl = was built with>, but are extremely unlikely to be needed for a Python package 
update.


This yields nothing that looks like it could possibly need a rebuild:

$ repoquery -q --repo=rawhide{,-source} --requires -a | grep -iE 'python.+redis'
...
python3-redis
python3-redis >= 2.10.0
python3.10dist(redis)
python3.10dist(redis) >= 2.10
python3.10dist(redis) >= 2.10.5
python3.10dist(redis) >= 3
python3.10dist(redis) >= 3.5
...
python3dist(redis)
python3dist(redis) >= 2.10.5
python3dist(redis) >= 3
python3dist(redis) >= 3.5

(Manually removed false matches, was to lazy to write a proper regex.)

If the only reason is to verify the packages actually still build, you appear 
to have already done that.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Tom Hughes via devel]

On 06/04/2022 15:36, Chris Adams wrote:


One add to that: just because a system has UEFI doesn't mean it supports
all the same boot methods equally.  I do a lot of network installs, and
early UEFI systems I tried had broken PXE support (not sure when this
may have changed, as I then didn't try for a while).

Setting up a UEFI PXE boot server is (in my experience) more
complicated.  UEFI also supports HTTP boot, which is an improvement (the
sooner TFTP can die the better), but it's not a widespread (or at least,
sometimes not as easy to call).


This is certainly why I have a lot of UEFI capable machines
using MBR boot because it's only recently that I got network
booting to work with UEFI and the install would install as MBR
if it was booted from a legacy network book.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: GNOME Online Accounts "Fedora" - Pre-authentication failed

[Michael Catanzaro]

On Wed, Apr 6 2022 at 09:42:42 AM -0400, Christopher 
 wrote:
Is this a problem with GNOME Online Accounts, or is this a problem 
with the KDC, or is this related to the use of 2FA/OTP? For the 
password in the GNOME Online Accounts dialogue box, I entered my 
Fedora password followed by my OTP.


Er, that's not going to work, because your OTP is going to change, but 
the password you enter here gets saved locally and therefore has to be 
static.


I don't know what the solution is.

Myself, I will not enable OTP until there is a way to disable it again. 
Currently, once enabled, you are stuck with it and cannot go back if 
things break, which is too much risk for me. I'd be very sad if I 
couldn't use gnome-online-accounts to manage kerberos anymore. :/


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Robbie Harwood]

Michael Catanzaro  writes:

> Woah, what happened here? Why would any Fedora package ever disable
> pull requests?

I suspect it was an accident.  I can't speak to why - if my
co-maintainers know, maybe they can - but it seems possible it got
toggled while someone was looking for something else in pagure settings.
It appears to just be a toggle in Project Options, so right next to web
hooks configuration or notification adjustment.

A (definitely out of scope) related question is, given this is something
we don't want to Fedora packages to do, whether src.fedoraproject.org
should just not expose the option at all.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Adam Jackson]

On Tue, Apr 5, 2022 at 6:51 PM Demi Marie Obenour  wrote:

> > I'm flattered, but I intend to drop vesa in F37 regardless of the
> > outcome of this particular change. The only supported way to get to
> > graphics with vesa is to use Xorg, and we sincerely want to be out of
> > the business of maintaining Xorg the hardware server. (We'll need an X
> > server forever, Xwayland isn't going away, don't misread me here.)
>
> Does that mean that F37 will only have an Xwayland package, not an
> Xorg package?  And does it mean that XFCE support is being deprecated?
> Qubes OS relies on the latter.

I chose my words carefully, I said "drop vesa" not "drop Xorg". It
means F37 will not have a vesa driver for the Xorg server to use. Xorg
will still be there for at least another release, probably several.

It's likely that the long term plan for preserving X11-only desktop
environments would be to run (say) weston such that its only client is
a fullscreen Xwayland, rather than Xorg driving the hardware directly.

> > And frankly at this point if you seriously want to use vesa it's
> > because you're trying to like reverse engineer some obscure card's
> > VBIOS, and if you're doing that you're probably building your own X
> > server anyway, I know I would be. Its use as an emergency driver on
> > physical GPUs is negligible, we have native drivers for virtually
> > everything made in the last 20 years. Its use as an emergency driver
> > in virtual machines is more statistically significant, maybe, but even
> > there we usually have a drm driver these days, and where we don't we
> > can probably club it into bochs_drm since that's the only rom anyone
> > bothers to use for that.
>
> Do we have DRM drivers for the UEFI framebuffer and the standard
> QEMU-emulated graphics?

Yes.

- ajax
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RFI/RFC: Fedora Linux graphical recovery environment

[Robert Marcano via devel]

On 4/5/22 11:11 AM, Neal Gompa wrote:

On Tue, Apr 5, 2022 at 10:47 AM stan via devel
 wrote:


On Mon, 4 Apr 2022 15:58:14 -0500
Gregory Bartholomew  wrote:


Of topic but related: I wish there was supported option to remove
the current rescue kernel,


Is echo "dracut_rescue_image=no" > /etc/dracut.conf.d/rescue.conf not
sufficient?


That is an interesting option.  It isn't documented in man dracut.conf.
Is it new?  I just manually remove the rescue vmlinuz and initramfs and
then run
/usr/lib/kernel/install.d/51-dracut-rescue.install add $(uname -r) "" 
/lib/modules/$(uname -r)/vmlinuz
in the /boot directory to build a new rescue kernel from the currently
running kernel.  Is there an option to do that also?  i.e. I invoke
dracut from the command line and it automatically does all that if a
rescue_build.conf file is present in /etc/dracut.conf.d/


You could also just remove the "dracut-config-rescue" package from your system.



And this is the magic bit. Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FESCo wants to know what you use i686 packages for

[Nathanael D. Noblet]

One more update.

On Wed, 2022-04-06 at 16:24 +, Nathanael Noblet wrote:
> Hello,
> 
>    I didn't think I needed i386 personally. In fact due to this
> thread I removed many i386 packages left on my machine. Just today I
> plugged in an 'IronKey' device. Its an encrypted USB drive. When
> plugged in a read only like mount is mounted, like a CD. On it is a
> binary to unlock the device. It no longer works, I get an "unable to
> execute ./ironkey: No such file or directory" likely because I'm now
> missing the i386 libraries or other requirements.

Looks like I need 
glibc.i686 (and it installed glibc-gconv-extra.i686, libgcc.i686) for
this ironkey device.

Sincerely,
-- 
Nathanael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Neal Gompa]

On Wed, Apr 6, 2022 at 12:23 PM Justin Forbes  wrote:
>
> On Tue, Apr 5, 2022 at 6:39 PM Chris Murphy  wrote:
> >
> > On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez  wrote:
> >
> > > The security of UEFI systems is immeasurably better. Standardized 
> > > firmware updates, support for modern secure TPMs, OS protection from 
> > > firmware (SMM mitigations), HTTP(S) boot support, largely shared and open 
> > > sourced firmware codebases that aren't a pile of assembly code, and a lot 
> > > of other features are UEFI-only.
> >
> > When users have a suboptimal experience by default, it makes Fedora
> > look bad. We can't have security concerns overriding all other
> > concerns. But it's really pernicious to simultaneously say security is
> > important, but we're also not going to sign proprietary drivers. This
> > highly incentivizes the user to disable Secure Boot because that's so
> > much easier than users signing kernel modules and enrolling keys with
> > the firmware, and therefore makes the user *less safe*.
> >
> >
> > >> And the amount of resistance to improving UEFI experience for hardware
> > >> is amazingly awful. The workstation working group has tried to figure
> > >> out ways to improve the experience, only to be simultaneously stymied
> > >> by the UEFI firmware management tools and unwillingness by anyone
> > >> involved to even consider that we should make this better.
> > >
> > >
> > > Which tools? What specific efforts have been stymied? How is any of this 
> > > specific to UEFI versus trying to deal with things that aren't supported 
> > > by someone?
> >
> > Namely, Fedora signing NVIDIA's proprietary driver.
> >
> > Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all
> > indicate Apple and Microsoft trust the driver itself. It is trusting
> > the providence of the blob, in order to achieve an overall safer
> > ecosystem for their users.
> >
> > We either want users with NVIDIA hardware to be inside the Secure Boot
> > fold or we don't. I want them in the fold *despite* the driver that
> > needs signing is proprietary. That's a better user experience across
> > the board, including the security messaging is made consistent. The
> > existing policy serves no good at all and is double talk. If we really
> > care about security more than ideological worry, we'd sign the driver.
>
> At the very least, it would require that Fedora have a separate key
> that is trusted and not the same one used for shim/grub/kernel.  We
> certainly aren't proposing that we use the standard Fedora keys to
> sign a binary blob that runs in kernel space from a company who was
> most recently hacked last month?
>

I want a secondary key that we can use that's trusted only by the
kernel so that it's easy to revoke/rotate without forcing the whole
mess on everyone.

Having a keyring in the kernel that allows the kernel to trust
certificates without having to import them into firmware drastically
reduces the damage and improves the security of the system by making
it easier to manage trust in the first place.

The whole reason we sign shim with the Microsoft certificate and then
have shim trust our certificate for grub and the kernel is because we
recognize that making people fiddle with the firmware is a horribly
bad idea. That hasn't changed in 20 years. Shim changes very little,
and everything that uses the Fedora cert can change often without
involving the whole mess. I want that principle extended to kernel
modules too.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FESCo wants to know what you use i686 packages for

[Nathanael Noblet]

Hello,

   I didn't think I needed i386 personally. In fact due to this thread I 
removed many i386 packages left on my machine. Just today I plugged in an 
'IronKey' device. Its an encrypted USB drive. When plugged in a read only like 
mount is mounted, like a CD. On it is a binary to unlock the device. It no 
longer works, I get an "unable to execute ./ironkey: No such file or directory" 
likely because I'm now missing the i386 libraries or other requirements.

Sincerely,
-- 
Nathanael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Justin Forbes]

On Tue, Apr 5, 2022 at 6:39 PM Chris Murphy  wrote:
>
> On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez  wrote:
>
> > The security of UEFI systems is immeasurably better. Standardized firmware 
> > updates, support for modern secure TPMs, OS protection from firmware (SMM 
> > mitigations), HTTP(S) boot support, largely shared and open sourced 
> > firmware codebases that aren't a pile of assembly code, and a lot of other 
> > features are UEFI-only.
>
> When users have a suboptimal experience by default, it makes Fedora
> look bad. We can't have security concerns overriding all other
> concerns. But it's really pernicious to simultaneously say security is
> important, but we're also not going to sign proprietary drivers. This
> highly incentivizes the user to disable Secure Boot because that's so
> much easier than users signing kernel modules and enrolling keys with
> the firmware, and therefore makes the user *less safe*.
>
>
> >> And the amount of resistance to improving UEFI experience for hardware
> >> is amazingly awful. The workstation working group has tried to figure
> >> out ways to improve the experience, only to be simultaneously stymied
> >> by the UEFI firmware management tools and unwillingness by anyone
> >> involved to even consider that we should make this better.
> >
> >
> > Which tools? What specific efforts have been stymied? How is any of this 
> > specific to UEFI versus trying to deal with things that aren't supported by 
> > someone?
>
> Namely, Fedora signing NVIDIA's proprietary driver.
>
> Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all
> indicate Apple and Microsoft trust the driver itself. It is trusting
> the providence of the blob, in order to achieve an overall safer
> ecosystem for their users.
>
> We either want users with NVIDIA hardware to be inside the Secure Boot
> fold or we don't. I want them in the fold *despite* the driver that
> needs signing is proprietary. That's a better user experience across
> the board, including the security messaging is made consistent. The
> existing policy serves no good at all and is double talk. If we really
> care about security more than ideological worry, we'd sign the driver.

At the very least, it would require that Fedora have a separate key
that is trusted and not the same one used for shim/grub/kernel.  We
certainly aren't proposing that we use the standard Fedora keys to
sign a binary blob that runs in kernel space from a company who was
most recently hacked last month?

Justin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Self Introduction: Andreas Vögele

[Andreas Vögele via devel]

Hello Fedora developers,

I'm Andreas from Stuttgart in Germany. I'm a system administrator and 
software developer, who moved his computers to Fedora about a year ago. 
I've written a handful of Perl modules that I package at the Open Build 
Service and Copr. I'd like to maintain some of these modules directly in 
Fedora. In the past, I maintained ports of other software at 
SlackBuilds.org and OpenBSD. Occasionally, I contribute patches to free 
software projects. I enjoy programming in C, Perl and recently Kotlin.


Kind regards,
Andreas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Michael Catanzaro]

On Wed, Apr 6 2022 at 11:11:37 AM -0400, Neal Gompa 
 wrote:

The grub2 package had pull requests disabled until last year. That's a
pretty obvious hammer to indicate patches are not welcome. That's why
I couldn't send PRs to add the protected.d files for grub and had to
wait for someone else to do it by filing a BZ.


Woah, what happened here? Why would any Fedora package ever disable 
pull requests?


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Michael Catanzaro]

On Wed, Apr 6 2022 at 08:16:09 AM -0400, Neal Gompa 
 wrote:

This is not a deprecation change, this is effectively a removal
change. By removing the packages and the tooling support for legacy
BIOS, it makes several scenarios (including recovery) harder.
Moreover, it puts the burden on people to figure out if their hardware
can boot and install Fedora when we clearly haven't reached a critical
mass yet for doing so, like we did when we finally removed the i686
kernel build.


What scares me is we have no way to know how many users are using 
legacy BIOS vs. UEFI.


I used legacy BIOS until just a few months ago, when I found some 
obscure setting in my laptop's BIOS (don't remember what) and 
discovered that if set to a non-default value, suddenly UEFI would 
actually work. I actually had this laptop for just over five years 
before discovering that the UEFI support worked. I had previously 
assumed that it was broken.


I wonder if Ubuntu knows what percentage of their users are doing 
legacy BIOS vs. UEFI boot. Lacking any data from Fedora, data from 
another similar distro is going to be the closest proxy we can get for 
this info. I know Ubuntu has installation reports, but I don't know if 
they collect this data.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Jared Dominguez]

On Wed, Apr 6, 2022 at 8:20 AM Neal Gompa  wrote:

> On Wed, Apr 6, 2022 at 8:04 AM Vít Ondruch  wrote:
> >
> >
> > Dne 05. 04. 22 v 17:08 Neal Gompa napsal(a):
> > > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton  wrote:
> > >> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
> > >>
> > >> == Summary ==
> > >> Make UEFI a hardware requirement for new Fedora installations on
> > >> platforms that support it (x86_64).  Legacy BIOS support is not
> > >> removed, but new non-UEFI installation is not supported on those
> > >> platforms.  This is a first step toward eventually removing legacy
> > >> BIOS support entirely.
> > >>
> > >> == Owner ==
> > >> * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
> > >> Konečný]], [[User:bcl| Brian C. Lane]]
> > >> * Email: rharw...@redhat.com
> > >>
> > >>
> > >> == Detailed Description ==
> > >> UEFI is defined by a versioned standard that can be tested and
> > >> certified against.  By contrast, every legacy BIOS is unique. Legacy
> > >> BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
> > >> and on its way out.  As it ages, maintainability has decreased, and
> > >> the status quo of maintaining both stacks in perpetuity is not viable
> > >> for those currently doing that work.
> > >>
> > >> It is inevitable that legacy BIOS will be removed in a future release.
> > >> To ease this transition as best we can, there will be a period (of at
> > >> least one Fedora release) where it will be possible to boot using the
> > >> legacy BIOS codepaths, but new installations will not be possible.
> > >> While it would be easier for us to cut support off today, our hope is
> > >> that this compromise position will make for a smoother transition.
> > >> Additional support with issues during the transition would be
> > >> appreciated.
> > >>
> > >> While this will eventually reduce workload for boot/installation
> > >> components (grub2 reduces surface area, syslinux goes away entirely,
> > >> anaconda reduces surface area), the reduction in support burden
> > >> extends much further into the stack - for instance, VESA support can
> > >> be removed from the distro.
> > >>
> > >> Fedora already requires a 2GHz dual core CPU at minimum (and therefore
> > >> mandates that machines must have been made after 2006).  Like the
> > >> already accepted Fedora 37 change to retire ARMv7 support, the
> > >> hardware targeted tends to be rather underpowered by today’s
> > >> standards, and the world has moved on from it.  Intel stopped shipping
> > >> the last vestiges of BIOS support in 2020 (as have other vendors, and
> > >> Apple and Microsoft), so this is clearly the way things are heading -
> > >> and therefore aligns with Fedora’s “First” objective.
> > >>
> > >> == Feedback ==
> > >> Dropping legacy BIOS was previously discussed (but not proposed) in
> 2020:
> > >>
> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/
> > >>
> > >> Important, relevant points from that thread (yes, I reread the entire
> > >> thread) that have informed this change:
> > >>
> > >> * Some machines are BIOS-only.  This change does not prevent their use
> > >> yet, but they are effectively deprecated.  grub2 (our default
> > >> bootloader) is already capable of both BIOS and UEFI booting.
> > >> * Drawing a clear year cutoff, let alone a detailed list of hardware
> > >> this change affects, is basically impossible.  This is unfortunate but
> > >> unlikely to ever change.
> > >> * There is no migration story from Legacy BIOS to UEFI -
> > >> repartitioning effectively mandates a reinstall.  As a result, we
> > >> don’t drop support for existing Legacy BIOS systems yet, just new
> > >> installations.
> > >> * There is no way to deprecate hardware without causing some amount
> of friction.
> > >> * While at the time AWS did not support UEFI booting, that is no
> > >> longer the case and they support UEFI today.
> > >>
> > >> == Benefit to Fedora ==
> > >> UEFI is required for many desirable features, including applying
> > >> firmware updates (fwupd) and supporting SecureBoot.  As a standalone
> > >> change, it reduces support burden on everything involved in installing
> > >> Fedora, since there becomes only one way to do it per platform.
> > >> Finally, it simplifies our install/live media, since it too only has
> > >> to boot one way per arch.  Freedom Friends Features First - this is
> > >> that last one.
> > >>
> > >> == Scope ==
> > >> * Proposal owners:
> > >> ** bootloaders: No change (existing Legacy BIOS installations still
> supported).
> > >> ** anaconda: No change (there could be only optional cleanups in the
> > >> code). However, it needs to be verified.
> > >> ** Lorax: Code has already been written:
> > >> https://github.com/weldr/lorax/pull/1205
> > >>
> > > This pull request primarily drops legacy BIOS support by dropping
> > > syslinux/isolinux. We don't necessarily have to drop legacy 

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Robert Marcano via devel]

On 4/5/22 10:52 AM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS


...

It is inevitable that legacy BIOS will be removed in a future release.
To ease this transition as best we can, there will be a period (of at
least one Fedora release) where it will be possible to boot using the
legacy BIOS codepaths, but new installations will not be possible.
While it would be easier for us to cut support off today, our hope is
that this compromise position will make for a smoother transition.
Additional support with issues during the transition would be
appreciated.



Many people have already commented on having active and usable computers 
only supporting BIOS and not UEFI. You can count me on that list too. 
but I will really appreciate a clarification.


Is this change only related to install media support for booting with 
BIOS only? Would I be able to install newer Fedora releases using Legacy 
PXE on BIOS only machines?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Robbie Harwood]

Neal Gompa  writes:

> On Wed, Apr 6, 2022 at 10:59 AM Robbie Harwood  wrote:
>> Neal Gompa  writes:
>>
>>> 3. At various times, people have explicitly said "patches NOT
>>> welcome"
>>
>> I see no evidence of this having happened, and it's definitely not
>> something I've said.
>
> The grub2 package had pull requests disabled until last year. That's a
> pretty obvious hammer to indicate patches are not welcome. That's why
> I couldn't send PRs to add the protected.d files for grub and had to
> wait for someone else to do it by filing a BZ.

That change went in in 2020, so we're pushing two years ago.  The patch
was ultimately written by Javier as
8c2cf1c36843a2eb1e52c29f20ef4167463189ec.  While it's not the most
complex thing in the world, it's not trivial either.

The relevant bug was https://bugzilla.redhat.com/show_bug.cgi?id=1874541
which you filed.  You did not mention that sending PRs was broken, nor
did you provide a patch there, nor did you indicate willingness to
provide one.

To turn around after that and say, today, that the grub maintainers have
said "patches NOT welcome" seems more like an assumption of bad faith
than a reasonable characterization to me.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-IoT-36-20220406.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/15 (aarch64)

Old failures (same test failed in Fedora-IoT-36-20220405.0):

ID: 1213994 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1213994

Passed openQA tests: 14/15 (aarch64), 15/15 (x86_64)

New passes (same test not passed in Fedora-IoT-36-20220405.0):

ID: 1214007 Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/1214007
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[stan via devel]

On Wed, 6 Apr 2022 06:28:59 +0200
majid hussain  wrote:

> could someone kindly tell me if my toshiba l750 machine has EFI
> support? i'm blind and efi/bios screens are in accessible.

This question is better suited to the user list rather than
this thread, but if your laptop came with windows 8 or later,
it will have uefi support. Here is a link that explains how to get into
the bios if you want to have someone double check for you.

https://www.4winkey.com/computer-help/how-to-access-enter-bios-on-toshiba-laptop.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-36-20220406.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 6/229 (x86_64), 11/161 (aarch64)

New failures (same test not failed in Fedora-36-20220405.n.0):

ID: 1213505 Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/1213505
ID: 1213649 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1213649
ID: 1213883 Test: aarch64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/1213883
ID: 1213967 Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/1213967
ID: 1213968 Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/1213968

Old failures (same test failed in Fedora-36-20220405.n.0):

ID: 1213571 Test: x86_64 Workstation-live-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1213571
ID: 1213606 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1213606
ID: 1213704 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1213704
ID: 1213705 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1213705
ID: 1213707 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1213707
ID: 1213738 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1213738
ID: 1213741 Test: x86_64 Workstation-upgrade gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1213741
ID: 1213756 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1213756
ID: 1213760 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1213760
ID: 1213762 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1213762
ID: 1213826 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1213826
ID: 1213885 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1213885

Soft failed openQA tests: 6/161 (aarch64), 10/229 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-36-20220405.n.0):

ID: 1213681 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1213681

Old soft failures (same test soft failed in Fedora-36-20220405.n.0):

ID: 1213574 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1213574
ID: 1213578 Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1213578
ID: 1213589 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1213589
ID: 1213599 Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1213599
ID: 1213616 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1213616
ID: 1213621 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1213621
ID: 1213623 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1213623
ID: 1213624 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1213624
ID: 1213630 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1213630
ID: 1213719 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1213719
ID: 1213720 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1213720
ID: 1213724 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1213724
ID: 1213732 Test: x86_64 Workstation-upgrade desktop_browser
URL: https://openqa.fedoraproject.org/tests/1213732
ID: 1213754 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1213754
ID: 1213767 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1213767

Passed openQA tests: 213/229 (x86_64), 144/161 (aarch64)

New passes (same test not passed in Fedora-36-20220405.n.0):

ID: 1213603 Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/1213603
ID: 1213609 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1213609
ID: 1213652 Test: aarch64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1213652
ID: 1213668 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Robbie Harwood]

Neal Gompa  writes:

> On Wed, Apr 6, 2022 at 7:14 AM John Boero  wrote:
>>
>> I can fully understand why this would be done.  As per the original
>> discussion when Peter Robinson mentioned a Spin to deprecate BIOS,
>> would anybody else be interested in helping with a Spin for legacy
>> BIOS support?  I agree with the e-waste comments and it seems a shame
>> to trash some perfectly viable kiosks or old IoT which gave new life
>> to old kit.  I just got done knocking Windows 11 for deprecating
>> support for fairly new hardware but now realize Fedora is doing
>> something similar (though not as drastic).  Is a spin worth
>> exploring?  Volunteers welcome.
>
> The pull request to delete the code for BIOS support in lorax means
> that we can't produce media with BIOS support at all once that's
> merged. They've tied dropping syslinux to dropping BIOS support
> entirely. It is also unclear that they'd take a contribution to rewire
> lorax to produce media with BIOS support using GRUB like we do for
> UEFI.

We're right here - you can just ask.

Brian's PR is to implement the change as written.  If the project
decided to go in the direction of a spin, that would be something other
than what the change proposes, and the PR wouldn't be appropriate.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Robbie Harwood]

Chris Murphy  writes:

> On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton  wrote:
>
>> Legacy BIOS support is not removed, but new non-UEFI installation is
>> not supported on those platforms.  This is a first step toward
>> eventually removing legacy BIOS support entirely.
>
> What is the distinction between "support is not removed" and "removing
> support entirely"?  i.e. what are the additional steps for entirely
> removing support?

A project decision that it's not supported, and to stop building the
bootloader packages for it entirely.

> And what's the approximate time frame for it?

Unclear.  Sooner would be better for us, but I know that's not
realistic.  At least a release, probably multiple.  Reasoned suggestions
(i.e., other than "never") would influence this.

> "Support is not removed" seems incongruent with "new installations are
> not supported." What continues to be supported?

Existing installations.

> Will grub-pc still be built and updated?

Yes.

> Will grub2-install still work on BIOS systems?

Probably - I'm not about to sabotage it.  But it wouldn't be supported
for making new installations.  I'm aware that users comfortable doing
installs outside anaconda (or with customized anaconda) can circumvent
this, and I'm not interested in trying to stop them - that's an
adversarial relationship neither of us want.

>> syslinux goes away entirely
>
> If the installation media used BIOS GRUB, syslinux could still go
> away. What consideration has occurred to switch from syslinux to BIOS
> GRUB for installation media? Is BIOS GRUB being deprecated? Or is it
> being discontinued in Fedora?

(I wasn't involved in the decision of what bootloader to use for legacy
live media and can't speak to it.)

> If security vulnerabilities in BIOS GRUB are discovered, and
> grub2-install doesn't apply the most recently available fixes, I
> consider this an unsupported configuration. We can't say "support is
> not removed" while removing the ability to apply security fixes to the
> embedded bootloader.

I don't think I understand this paragraph, but taking a guess: I don't
intend to break anything about existing installations, including
security update delivery.

> This is removal of support. No mere deprecation.

This is a semantic issue that I don't think it will be useful to argue.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Neal Gompa]

On Wed, Apr 6, 2022 at 10:59 AM Robbie Harwood  wrote:
>
> Neal Gompa  writes:
>
> > This is not a deprecation change, this is effectively a removal
> > change. By removing the packages and the tooling support for legacy
> > BIOS, it makes several scenarios (including recovery) harder.
> > Moreover, it puts the burden on people to figure out if their hardware
> > can boot and install Fedora when we clearly haven't reached a critical
> > mass yet for doing so, like we did when we finally removed the i686
> > kernel build.
>
> I've stated in the change that the intent is to eventually remove legacy
> entirely - so there's no sleight of hand here.  The rest is a semantic
> issue which I don't care to argue.
>
> > 2. The packages are locked down so there is no way for the community to help
>
> I've replied to this when you said it before, but no, this is
> misinformation, and I'd appreciate if you stop spreading it.
>
> Bootloader packages are available for PRs, same as every other package
> in the distro.  Our bugzilla issues are as open as any other package in
> the distro.
>
> Quite simply, being able to make official builds isn't a requirement to
> help with any package in the distro, bootloader or otherwise.  And to
> peek behind the curtain a bit, running `fedpkg build` is not even close
> to the hardest or most time-consuming part of working on bootloader
> packages.
>
> > 3. At various times, people have explicitly said "patches NOT welcome"
>
> I see no evidence of this having happened, and it's definitely not
> something I've said.

The grub2 package had pull requests disabled until last year. That's a
pretty obvious hammer to indicate patches are not welcome. That's why
I couldn't send PRs to add the protected.d files for grub and had to
wait for someone else to do it by filing a BZ.



--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Björn Persson]

JT wrote:
> I realize some will have the attitude of "they can just not upgrade and
> keep using their old Fedora versions".

That's obviously not a solution for any Internet-connected computer.
Even if you communicate only by moving files on USB sticks or
diskettes, it's still dangerous to let known security holes accumulate.

Björn Persson


pgpzXxjDRbutY.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Robbie Harwood]

"Andre Robatino"  writes:

> Those figures are recommended minimums, not requirements. I have a
> single core F35 machine which works fine.

It's important to note here that "works fine" isn't the same as "is
supported".

My reading of that document is that if one goes below what's laid out in
"Minimum System Configuration", here be dragons, trouble may happen, and
to varying degrees, one is on their own.  And that those dangers are why
there's a "Recommended System Configuration" in the next section.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Björn Persson]

laolux laolux via devel wrote:
> I am willing to throw away my still working notebook, producing a little bit 
> electronic waste when the time comes.

I'm not. It remains to be seen how long Fedora will continue to work on
my ten-year-old laptop, but when the time comes I will not trash it and
buy a new one. Unless the hardware breaks first, I'll install some other
distribution when the laptop is no longer welcome in Fedora. I'll
probably go with Debian, which is usually good with not quite brand new
hardware. This may reduce my ability and motivation to contribute to
Fedora.

I use this laptop to develop and test performance measurement tools. It
handles build jobs, testsuites and virtual machines just fine. The days
when a three-year-old computer was too slow to be useful are long gone.

Björn Persson


pgp52J6uYF2PH.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Robbie Harwood]

Neal Gompa  writes:

> This is not a deprecation change, this is effectively a removal
> change. By removing the packages and the tooling support for legacy
> BIOS, it makes several scenarios (including recovery) harder.
> Moreover, it puts the burden on people to figure out if their hardware
> can boot and install Fedora when we clearly haven't reached a critical
> mass yet for doing so, like we did when we finally removed the i686
> kernel build.

I've stated in the change that the intent is to eventually remove legacy
entirely - so there's no sleight of hand here.  The rest is a semantic
issue which I don't care to argue.

> 2. The packages are locked down so there is no way for the community to help

I've replied to this when you said it before, but no, this is
misinformation, and I'd appreciate if you stop spreading it.

Bootloader packages are available for PRs, same as every other package
in the distro.  Our bugzilla issues are as open as any other package in
the distro.

Quite simply, being able to make official builds isn't a requirement to
help with any package in the distro, bootloader or otherwise.  And to
peek behind the curtain a bit, running `fedpkg build` is not even close
to the hardest or most time-consuming part of working on bootloader
packages.

> 3. At various times, people have explicitly said "patches NOT welcome"

I see no evidence of this having happened, and it's definitely not
something I've said.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Robbie Harwood]

Vít Ondruch  writes:

> Maybe I don't correctly understand the "Legacy BIOS support is not 
> removed, but new non-UEFI installation is not supported on those 
> platforms." quoted from the the change description, but if you have your 
> system installed, it should keep working. You just keep updating. IOW as 
> long as you don't reinstall the system, you are fine and you don't have 
> to be concerned.

Just for clarity, this is indeed a correct reading of the intent of the
change.

If there's wording that clarified here, I'm happy to adopt suggestions -
my intent is not to confuse :)

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RFI/RFC: Fedora Linux graphical recovery environment

[stan via devel]

On Tue, 5 Apr 2022 11:35:16 -0500
Gregory Bartholomew  wrote:

> On Mon, Apr 4, 2022 at 9:40 PM Gordon Messmer
>  wrote:
> 
> > The ticket mentions Boot Repair, which is the first thing that
> > comes to mind: https://help.ubuntu.com/community/Boot-Repair  
> 
> 
> Boot repair is obviously tricky because you have to have something
> bootable to initiate the repair. Practically speaking, I think the
> best option is to better support dual-drive installations. It should
> be possible to maintain two EFI partitions in a, b style when the
> user selects to have a mirrored-disk configuration. In fact I've been
> doing this on my Fedora Linux systems and I've even written some
> scripts to support it here:
> https://github.com/gregory-lee-bartholomew/bootsync
> 
> Disclaimer though -- I use systemd boot and zfs, not the default grub
> and btrfs that most Fedora Linux systems are configured with.

This is possible using standard efi boot with the cooperation of the
bios.  Just use two efi partitions, and prioritize the default one in
the bios boot menu.  Not as sophisticated as what you do, but I am
usually not running updates on the rescue system. I install the latest
fedora rawhide once a year, usually, so the rescue system is out of
support. Fine for rescue.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Robbie Harwood]

majid hussain  writes:

> hi,
> could someone kindly tell me if my toshiba l750 machine has EFI support?
> i'm blind and efi/bios screens are in accessible.

Easiest is probably to do:

ls /sys/firmware/efi

This tells you whether the machine booted using UEFI.  anaconda will set
up a UEFI-capable system if booted that way, unless partitioning is
overridden to prevent that.

If it didn't boot using UEFI today, that doesn't mean it can't (you
could check with a live image as well).  UEFI tends to be enabled on
machines made these days by default for Windows logo requirements, but
this is firmware land, and there are no absolutes.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Landing a larger-than-release change (distrusting SHA-1 signatures)

[Stephen Gallagher]

On Wed, Apr 6, 2022 at 7:09 AM Alexander Sosedkin  wrote:
>
> On Wed, Apr 6, 2022 at 1:00 PM Vít Ondruch  wrote:
...
> > Alexander,
> >
> > Could this be enabled in ELN? This is not really question but
> > suggestion. It is unfortunate, that ELN, while intermediate step for c9s
> > does not have this enabled yet.
> >
> > For example, we are working on Ruby 3.1 for c9s [1] just to figure that
> > while everything just works in Fedora/ELN, it does not work in c9s.
> > Maybe working with ELN would make the migrations easier also for Fedora.
> >
> >
> > Vít
>
> It's on my plans, but it'd take some time as it's not trivial.
>

Alexander, I can try to help you with this if you need it. Just let me know.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RFI/RFC: Fedora Linux graphical recovery environment

[stan via devel]

On Tue, 5 Apr 2022 11:26:35 -0500
Gregory Bartholomew  wrote:

> On Tue, Apr 5, 2022 at 9:47 AM stan via devel
>  wrote:

> >   I just manually remove the rescue vmlinuz and initramfs and
> > then run
> > /usr/lib/kernel/install.d/51-dracut-rescue.install add $(uname -r)
> > "" /lib/modules/$(uname -r)/vmlinuz
> > in the /boot directory to build a new rescue kernel from the
> > currently running kernel.  Is there an option to do that also?
> > i.e. I invoke  
>> 
>> dracut from the command line and it automatically does all that if a
> > rescue_build.conf file is present in /etc/dracut.conf.d/
> >  
> 
> Well sort of. If you really want complete control over how the rescue
> kernels are installed one option is to copy
> the /usr/lib/kernel/install.d/51-dracut-rescue.install script
> to /etc/kernel/install.d and tweak it to do whatever you want under
> whatever conditions you want. As long as the script under
> /etc/kernel/install.d has the same name as the script under
> /usr/lib/kernel/install.d, it will override (i.e. run instead of) the
> one under /usr/lib/kernel/install.d.

Thanks for the information.  It will probably be a rainy day project,
as doing it manually is not onerous, since I only do it when the
production kernel version changes.  e.g. 5.17 to 5.18  So, about every
3 months?

I actually might take your suggestion about how to turn off rescue
kernels, since, like you, I have two installations of fedora, and use
one (previous version) as a rescue system.  On the other hand, belt and
suspenders.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Chris Adams]

Once upon a time, Alberto Abrao  said:
> Also, let me state that many machines who'd be UEFI capable on paper
> are *not*: in my experience, many early UEFI machines (2009 up to
> 2014) have a very buggy implementation, to the point of being
> unusable and/or a terrible experience.

One add to that: just because a system has UEFI doesn't mean it supports
all the same boot methods equally.  I do a lot of network installs, and
early UEFI systems I tried had broken PXE support (not sure when this
may have changed, as I then didn't try for a while).

Setting up a UEFI PXE boot server is (in my experience) more
complicated.  UEFI also supports HTTP boot, which is an improvement (the
sooner TFTP can die the better), but it's not a widespread (or at least,
sometimes not as easy to call).

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2062023] [RFE: EPEL9] EPEL9 branch for perl-Net-Netmask

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2062023

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-a73255745c has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-a73255745c


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2062023
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Neal Gompa]

On Wed, Apr 6, 2022 at 10:18 AM Hans de Goede  wrote:
>
> Hi,
>
>   behalf of my employer (Red Hat)>
>
> On 4/5/22 16:52, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>
> 
>
> > Fedora already requires a 2GHz dual core CPU at minimum (and therefore
> > mandates that machines must have been made after 2006).
>
> But machines made between 2006-2012 generally did not have
> EFI support, anf for example at home I still have several
> machines from that era which are BIOS only in active use:
>
> 1. My daughter's workstation is an i5-2400 with 8G RAM, this
> is a 3.1 GHz base-freq quad-core processor very easily
> matching Fedora's minimal requirements. Currently running
> Fedora 35 just fine. Making it impossible to keep using this
> in the future is just causing unnecessary ewaste for no good
> reason IMHO.
>
> 2. My wife's workstation is a Core 2 Duo E6600 2.4 Ghz dual
> core machine with 4G RAM, which also still works fine for
> what she uses it for.
>
> 3. The living room laptop is another Core 2 Duo machine with
> 4G RAM.
>
> Looking specifically at fixed PCs and not laptops this
> proposal would (eventually) turn 2/5 PCs in my home
> unusable, which really is unacceptable IMHO.
>
> Also note that all these machines use somewhat older Intel
> integrated graphics. As he has already mentioned on this
> this thread, Dave Airlie has just spend a lot of time on
> making sure those iGPU-s will work with a gallium driver
> so that the classic mesa code can be removed and it seems
> rather silly to drop support for this hw after just investing
> a significant chunk of time to breathe new live into their
> GPU support.
>
> So a big -1 from me for this proposal as it stand.
>
> ###
>
> But I do completely understand that there is a workload issue
> for the bootloader team and the proposal also mentions:
>
> > == Contingency Plan ==
> > Leave things as they are.  Code continues to rot.  Community
> > assistance is required to continue the status quo.  Current owners
> > plan to orphan some packages regardless of whether the proposal is
> > accepted.
>
> If the current owners no longer want to support some packages
> which are only necessary for legacy BIOS support, then orphaning
> these seems completely reasonable to me.
>
> Maybe you can provide a list of these pkgs before hand so that
> people can already volunteer as co-maintainers now and then
> when they are orphaned, instead of orphaning them they can
> be directly handed over (using the "give away" button) to the
> new maintainers ?
>
> > Another fallback option could be, if a Legacy BIOS SIG organizes, to
> > donate the relevant packages there and provide some initial mentoring.
>
> I believe that that is a great idea, I hereby volunteer to
> try and setup such a SIG. If anyone reading this is interested
> in joining such a SIG please drop me an email.
>
> I realize that there have been similar attempts around keeping
> 32 bit x86 alive and that those have failed, but I believe that
> this is different for a number of reasons:
>
> 1. i686 support required making sure that *all* of Fedora kept
> working on i686, the problem was not just the kernel breaking
> sometimes, but also that huge projects like libreoffice would
> no longer start on i686 (at least on some of my machines).
>
> Legacy BIOS boot support is basically only about the image-creation
> tools + the bootloader. As various people have mentioned in the
> thread BIOS support is still very much a thing in data-centers,
> so I expect the upstream kernel community to keep the kernel
> working with this for at least a couple of years. Where as both
> the kernel + many userspace apps were breaking on i686.
>
> 2. I personally basically gave up on i686 support also because
> there was very little 32 bit only x86 hw around remaining in
> active use when it was dropped. And what was still on active
> use was getting close to unusable from a performance pov.
> Where as here we are talking about up to 2nd and 3th gen
> core i5 / i7 machines which are still quite performant.
>
> Esp. the 2nd gen core machines (Sandy Bridge) are still
> quite popular and lots of people have hung on to desktops
> with those because the CPU performance increase in generations
> after SNB have been rather underwhelming.
>
> > Longer term, packages that cannot be wholly donated could be split,
> > though it is unclear whether the synchronization thereby required
> > would reduce the work for anyone.
>
> I've been thinking about how this could be done for grub; also
> because of the issue that the EFI builds of grub need to be
> signed with Fedora's secure boot keys, which means only a few
> people can do grub2 builds atm.
>
> One option which I think we should consider is sticking with
> a single downstream git fork (until we have managed to get
> everything we need upstream), so stick with:
>
> https://github.com/rhboot/grub2/
>
> As the Source0 provider for the packages and then next to:
>
> 

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Hans de Goede]

Hi,



On 4/5/22 16:52, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS



> Fedora already requires a 2GHz dual core CPU at minimum (and therefore
> mandates that machines must have been made after 2006).

But machines made between 2006-2012 generally did not have
EFI support, anf for example at home I still have several
machines from that era which are BIOS only in active use:

1. My daughter's workstation is an i5-2400 with 8G RAM, this
is a 3.1 GHz base-freq quad-core processor very easily
matching Fedora's minimal requirements. Currently running
Fedora 35 just fine. Making it impossible to keep using this
in the future is just causing unnecessary ewaste for no good
reason IMHO.

2. My wife's workstation is a Core 2 Duo E6600 2.4 Ghz dual
core machine with 4G RAM, which also still works fine for
what she uses it for.

3. The living room laptop is another Core 2 Duo machine with
4G RAM.

Looking specifically at fixed PCs and not laptops this
proposal would (eventually) turn 2/5 PCs in my home
unusable, which really is unacceptable IMHO.

Also note that all these machines use somewhat older Intel
integrated graphics. As he has already mentioned on this
this thread, Dave Airlie has just spend a lot of time on 
making sure those iGPU-s will work with a gallium driver
so that the classic mesa code can be removed and it seems
rather silly to drop support for this hw after just investing
a significant chunk of time to breathe new live into their
GPU support.

So a big -1 from me for this proposal as it stand.

###

But I do completely understand that there is a workload issue
for the bootloader team and the proposal also mentions:

> == Contingency Plan ==
> Leave things as they are.  Code continues to rot.  Community
> assistance is required to continue the status quo.  Current owners
> plan to orphan some packages regardless of whether the proposal is
> accepted.

If the current owners no longer want to support some packages
which are only necessary for legacy BIOS support, then orphaning
these seems completely reasonable to me.

Maybe you can provide a list of these pkgs before hand so that
people can already volunteer as co-maintainers now and then
when they are orphaned, instead of orphaning them they can
be directly handed over (using the "give away" button) to the
new maintainers ?

> Another fallback option could be, if a Legacy BIOS SIG organizes, to
> donate the relevant packages there and provide some initial mentoring.

I believe that that is a great idea, I hereby volunteer to
try and setup such a SIG. If anyone reading this is interested
in joining such a SIG please drop me an email.

I realize that there have been similar attempts around keeping
32 bit x86 alive and that those have failed, but I believe that
this is different for a number of reasons:

1. i686 support required making sure that *all* of Fedora kept
working on i686, the problem was not just the kernel breaking
sometimes, but also that huge projects like libreoffice would
no longer start on i686 (at least on some of my machines).

Legacy BIOS boot support is basically only about the image-creation
tools + the bootloader. As various people have mentioned in the
thread BIOS support is still very much a thing in data-centers,
so I expect the upstream kernel community to keep the kernel
working with this for at least a couple of years. Where as both
the kernel + many userspace apps were breaking on i686.

2. I personally basically gave up on i686 support also because
there was very little 32 bit only x86 hw around remaining in
active use when it was dropped. And what was still on active
use was getting close to unusable from a performance pov.
Where as here we are talking about up to 2nd and 3th gen
core i5 / i7 machines which are still quite performant.

Esp. the 2nd gen core machines (Sandy Bridge) are still
quite popular and lots of people have hung on to desktops
with those because the CPU performance increase in generations
after SNB have been rather underwhelming.

> Longer term, packages that cannot be wholly donated could be split,
> though it is unclear whether the synchronization thereby required
> would reduce the work for anyone.

I've been thinking about how this could be done for grub; also
because of the issue that the EFI builds of grub need to be
signed with Fedora's secure boot keys, which means only a few
people can do grub2 builds atm.

One option which I think we should consider is sticking with
a single downstream git fork (until we have managed to get
everything we need upstream), so stick with:

https://github.com/rhboot/grub2/

As the Source0 provider for the packages and then next to:

https://src.fedoraproject.org/rpms/grub2

Add a:

https://src.fedoraproject.org/rpms/grub2-bios

And moving the build of all sub-packages which are
only necessary for BIOS support to the second src.rpm.

This way the Legacy BIOS SIG could maintain
the grub2-bios src.rpm (and binary pkgs it 

Re: Bodhi 6.0: What's new

[Miroslav Suchý]

Dne 06. 04. 22 v 14:31 Aurelien Bompard napsal(a):

* For other Fedora systems, we use Kerberos authentication, are there some 
plans to add it?

Nope, there's no plan for that at the moment.


FYI We recently added the Kerberos support to Copr cli. You can steal the code 
here:

https://pagure.io/copr/copr/pull-request/1820#

https://pagure.io/copr/copr/pull-request/2151#

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Alberto Abrao]

F

On 2022-04-06 07:16, Neal Gompa wrote:

Moreover, it puts the burden on people to figure out if their hardware
can boot and install Fedora when we clearly haven't reached a critical
mass yet for doing so, like we did when we finally removed the i686
kernel build.


All points by Neal were valid, and I second his post.

Also, let me state that many machines who'd be UEFI capable on paper are 
*not*: in my experience, many early UEFI machines (2009 up to 2014) have 
a very buggy implementation, to the point of being unusable and/or a 
terrible experience.


I run Fedora on a wide variety of machines, including old hardware that 
is plenty capable spec-wise, yet not feasible for UEFI boot.


If we consider Fedora Server, it gets even worse. I have a couple of 
Dual-Socket Nehalem-era Xeon boards in service. Both run Fedora. One is 
not UEFI capable at all, the other is very buggy when using it. My newer 
servers are not as powerful as these two, although they are UEFI capable.


This is to say that age alone does not tell the whole story. This change 
would leave behind a LOT of serviceable hardware even by today's standards.


Ironically, Fedora is one of the distributions out there that allows me 
to extract the most out of older hardware. It would be a terrible loss 
to have to move to a different one, but it's hard to reason purchasing 
new hardware - especially right now, with pandemic-related supply issues 
still ongoing - to keep up with this change.



Kind regards,
Alberto
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[John Boero]

There are other ways to create bootable media, right?  Does everything need to 
be Koji+Lorax?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Fedocal] Reminder meeting : Prioritized bugs and issues

[Luna Jernberg]

Attending today :)

On Tue, Apr 5, 2022 at 3:19 PM Ben Cotton  wrote:

> On Tue, Apr 5, 2022 at 6:07 AM  wrote:
> >
> > You are kindly invited to the meeting:
> >Prioritized bugs and issues on 2022-04-06 from 10:00:00 to 11:00:00
> America/Indiana/Indianapolis
> >At fedora-meetin...@irc.libera.chat
>
> We will review the following nominated bugs
>
> * flathub filtered repo seems missing from F35 install
> - https://bugzilla.redhat.com/show_bug.cgi?id=2011274
>
> * kexec-tools built with gcc 12 will fail kexec/kdump jumping to 2nd
> kernel with kexec_load interface
> - https://bugzilla.redhat.com/show_bug.cgi?id=2057391
>
> * online accounts: can't disable sync on items
> - https://bugzilla.redhat.com/show_bug.cgi?id=2068470
>
> * kernels newer than 5.15.11-200.fc35 cause libgpiod to issue "Unknown
> error 517"
> - https://bugzilla.redhat.com/show_bug.cgi?id=2060490
>
> * GDM login screen does not display all users
> - https://bugzilla.redhat.com/show_bug.cgi?id=2021839
>
>
> If we have time, we'll also review the status of the current accepted bugs:
>
> * SELinux preventing systemd-network-generator from creating files in
> /run/systemd/network/
> - https://bugzilla.redhat.com/show_bug.cgi?id=2037047
>
> * Lenovo ThinkPad T490, unable to boot following clean install, stuck
> at splash screen
> - https://bugzilla.redhat.com/show_bug.cgi?id=1955416
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> triage mailing list -- tri...@lists.fedoraproject.org
> To unsubscribe send an email to triage-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/tri...@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2071590] Upgrade perl-File-Find-Rule-Perl to 1.16

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2071590

Jitka Plesnikova  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
 Status|NEW |CLOSED
   Fixed In Version||perl-File-Find-Rule-Perl-1.
   ||16-1.fc37
Last Closed||2022-04-06 13:46:47




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2071590
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1980686] Upgrade perl-JSON-Path to 0.51

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1980686

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-JSON-Path-0.510-1.fc37
 Resolution|--- |RAWHIDE
Last Closed||2022-04-06 13:48:24



--- Comment #3 from Jitka Plesnikova  ---
Built by eseyman.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1980686
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bodhi 6.0: What's new

[Aurelien Bompard]

> * What is the expiration period? Or, can we set the expiration date ourselves?

What expiration do you mean? The buildroot override setting that 
save_override() gives access to is really unrelated to authentication and you 
probably don't need it if you didn't need it before.
If you mean when OpenID auth will be removed from the server, I'm not sure. I 
guess we can give something like 6 months for people to upgrade to OIDC, but if 
there are blockers with this upgrade I'd be happy to help make the transition.

> * Can we use multiple tokens in parallel to ease the transition before the 
> expiration? Or, in other words, is the token revoked once we generate a new 
> one? If not, can we revoke it?

Yes, you can have multiple tokens. To remove a token, I don't have a clear 
procedure, I'd need to have a look at Ipsilon's docs/code to see how it should 
be done.
Basically when you login you get two tokens, one "access token" and one 
"refresh token". The access token is short lived (like an hour I think) and is 
what the bodhi client will transmit to the bodhi server. When it expires, the 
bodhi client will send the "refresh token" to ipsilon to get a new access 
token. The refresh token is long-lived (months I think), but will only be 
communicated to ipsilon, not to Bodhi or any other apps.
When the refresh token expires, the bodhi client will ask the user to 
re-authenticate. There is currently no process to automate that as far as I can 
tell, so you may need to update the JSON file a couple times a year (I'm not 
sure how long those tokens live in prod, I need to check). It's somewhat like 
renewing a certificate.

Cheers!

Aurélien
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bodhi 6.0: What's new

[Aurelien Bompard]

> I wonder if kerberos going to be supported or not?

Not at this time.


Aurélien
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

GNOME Online Accounts "Fedora" - Pre-authentication failed

[Christopher]

In the past, I have used GNOME Online Accounts "Fedora Account" before to
maintain my Kerberos identity in my Fedora desktop so I can easily access
packager tooling without having to authenticate on the command-line
manually. However, this no longer seems to work. Now, I get
"Pre-authentication failed: Invalid argument".

Is this a problem with GNOME Online Accounts, or is this a problem with the
KDC, or is this related to the use of 2FA/OTP? For the password in the
GNOME Online Accounts dialogue box, I entered my Fedora password followed
by my OTP.

Do I need to do something else to use this method to authenticate for
Fedora packager tools? Or is this permanently broken?

Thanks,
Christopher
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bodhi 6.0: What's new

[Frantisek Lachman]

Thank you for your quick answer Aurélien!

I hope this workflow can work for us.

Maybe a few related questions (sorry if it is documented somewhere, any
link is welcome):
* What is the expiration period? Or, can we set the expiration date
ourselves?
* Can we use multiple tokens in parallel to ease the transition before the
expiration? Or, in other words, is the token revoked once we generate a new
one? If not, can we revoke it?

Thanks!
František

On Wed, Apr 6, 2022 at 2:29 PM Aurelien Bompard  wrote:

> Hey Frantisek!
>
> Excellent questions!
>
> > * Our users can use Packit via CLI and use their identity for Bodhi
> connections. With this, it's not nice, but doable to open a web-browser.
> (Not sure how this works in the containerised use-cases.)
>
> The Bodhi CLI will display a URL that you'll have to open in your web
> browser, and wait for input. After logging in, Ipsilon will give you a
> token that you need to copy/paste in the Bodhi CLI.
>
> > * Is there some way to get/generate some token that can be used instead
> of doing this browser workflow?
>
> Yes, you can do the browser workflow on any host and then copy over
> the ~/.config/bodhi/client.json file on the service's worker(s).
>
> > * Do I get it right from what you wrote about `save_override` that we
> can generate the session token elsewhere and reuse it in the service? Do
> you have some details on how this works so we can start working on the move?
>
> That's not what save_override() does, it's just an API endpoint to
> edit buildroot overrides in Bodhi.
>
> > * For other Fedora systems, we use Kerberos authentication, are there
> some plans to add it?
>
> Nope, there's no plan for that at the moment.
>
> Does this answer your questions?
>
> Aurélien
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Move existing build into side tag?

[Eduardo Lima (Etrunko)]

On Wed, Apr 6, 2022 at 6:59 AM Sérgio Basto  wrote:

> On Tue, 2022-04-05 at 22:34 -0500, Richard Shaw wrote:
>
> On Tue, Apr 5, 2022 at 10:04 PM Neal Gompa  wrote:
>
> On Tue, Apr 5, 2022 at 11:01 PM Richard Shaw  wrote:
> >
> > Google has failed me, how do I go about moving an existing build into a
> side tag I just created?
> >
>
> koji tag-build  
>
>
> Thanks, there's so many options in koji I wasn't sure which was the right
> one.
>
>
>
> I use `koji move-build`
>
> for example
> koji move-build epel8-testing-candidate epel8-build-side-52356
> ImageMagick-6.9.12.44-1.el8
>


move-build will remove the original tag, while tag-build keeps both the old
and the new one.

Thanks,
> RIchard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
>
> --
>
> Sérgio M. B.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Eduardo de Barros Lima ◤✠◢
ebl...@gmail.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-IoT-37-20220406.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Failed openQA tests: 4/15 (aarch64)

Old failures (same test failed in Fedora-IoT-37-20220404.0):

ID: 1213432 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1213432
ID: 1213434 Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/1213434
ID: 1213440 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/1213440
ID: 1213445 Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/1213445

Passed openQA tests: 15/15 (x86_64), 11/15 (aarch64)

New passes (same test not passed in Fedora-IoT-37-20220404.0):

ID: 1213417 Test: x86_64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1213417
ID: 1213418 Test: x86_64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/1213418
ID: 1213419 Test: x86_64 IoT-dvd_ostree-iso base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/1213419
ID: 1213421 Test: x86_64 IoT-dvd_ostree-iso base_system_logging@uefi
URL: https://openqa.fedoraproject.org/tests/1213421
ID: 1213422 Test: x86_64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/1213422
ID: 1213423 Test: x86_64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1213423
ID: 1213424 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/1213424
ID: 1213425 Test: x86_64 IoT-dvd_ostree-iso base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/1213425
ID: 1213426 Test: x86_64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/1213426
ID: 1213427 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi
URL: https://openqa.fedoraproject.org/tests/1213427
ID: 1213428 Test: x86_64 IoT-dvd_ostree-iso iot_greenboot@uefi
URL: https://openqa.fedoraproject.org/tests/1213428
ID: 1213429 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/1213429
ID: 1213430 Test: x86_64 IoT-dvd_ostree-iso base_reboot_unmount@uefi
URL: https://openqa.fedoraproject.org/tests/1213430
ID: 1213431 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/1213431
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[David Both]

I live in a 1st world country and have lots of new computers that this
change would not affect. However I still have some older computers that
fall outside the UEFI range and use only BIOS. I would still like to
keep these computers running and up to date so that they are secure and
have the most recent fixes. I also know many people who only have access
to 2nd or 3rd hand computers.

I do have a strong opinion and I say that it is too early to drop BIOS
support. There will probably be BIOS-only computers out there for years.
And one of the things I tell people when getting them to try Linux is
that it can extend the useful lives of those really old computers.

Thanks for considering my opinion.

--


*
David P. Both, RHCE
He/Him/His
*
www.both.org - My personal web site
www.Linux-Databook.info - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both
*
The value of any software lies in its usefulness
not in its price.

— Linus Torvalds
*

On Wed, 6 Apr 2022, JT wrote:


Date: Wed, 6 Apr 2022 08:50:18
From: JT 
Reply-To: Development discussions related to Fedora

To: Development discussions related to Fedora 
Cc: laolux laolux 
Subject: Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Wed, Apr 6, 2022 at 4:06 AM laolux laolux via devel <
devel@lists.fedoraproject.org> wrote:


I have no strong opinion on this, and not much say anyways, but I thought
I could share my little piece of info.
My currently one and only computer is a 2012 MSI GE60 0ND, with a core
i7-3630QM, 16GB RAM and retrofitted with a SSD.
So I would say fast enough for using Fedora. At least according to
notebookcheck.com the CPU is supposed to be faster than a rather recent
Core i3-1110G4, which is still being used in new notebooks in 2022.
Unfortunately it only supports legacy BIOS, and not UEFI.
Thus I do not like the wording of the change proposal.


Fedora already requires a 2GHz dual core CPU at minimum (and therefore
mandates that machines must have been made after 2006).  Like the
already accepted Fedora 37 change to retire ARMv7 support, the
hardware targeted tends to be rather underpowered by today’s
standards, and the world has moved on from it.  Intel stopped shipping
the last vestiges of BIOS support in 2020 (as have other vendors, and
Apple and Microsoft), so this is clearly the way things are heading -
and therefore aligns with Fedora’s “First” objective.


This seems to imply that only rather old and weak hardware would be
affected, when clearly the cutoff is (at maximum) only 10 years back.
Please don't get me wrong, I am perfectly fine about Fedora dropping "old"
hardware, and I am willing to throw away my still working notebook,
producing a little bit electronic waste when the time comes. But I think
one should be more open and explicit about it.



At the risk of being 'that guy' it's worth pointing out that not everyone
lives in a 1st world country and has access to cheap powerful hardware.  I
have good friends in Namibia and Cote d'Ivoire who are still using Fedora
on Core2Duo systems from pre 2010, because the machines are still perfectly
functional and do what they need them to do.
I realize some will have the attitude of "they can just not upgrade and
keep using their old Fedora versions".  Ok, that's a possible solution,
except that Fedora versions get EOL'd pretty quickly, so we'd basically be
taking the stance of 'buy new hardware if you want updates'.

Fedora has made a big deal about being considered a "Digital Public Good";
and we are right to be proud of that.  But if we're going to be proud of
that, let's not also decide to screw over areas that are not as
economically strong as where most of us are lucky enough to live.  It's
kind of arrogant of us to expect that everyone who uses Fedora is
financially able to go out and replace their hardware all the time even
when there's nothing wrong with it.
Are we only making Fedora for those with lots of spare money or is Fedora
for everyone?
/end being that guy


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Bodhi 6.0: What's new

[Aurelien Bompard]

Hey everyone!

Bodhi 6.0 will be published in a few days, and deployed to production a
couple weeks after the Fedora release. It has backwards-incompatible
changes, here's what you need to know.

== Authentication ==
Bodhi gained support for OpenID Connect (OIDC) authentication, like most of
Fedora's webapps. OpenID still works but is not the default, you can access
it by using `/login?method=openid` as the login URL.

Version 6.0 of the Bodhi client uses only OIDC, plain OpenID support has
been dropped. Version 5.7.5 of the Bodhi client, however, uses the new
OpenID login URL and has been available for about a month now, you'll need
at least version 5.7.5 to use the Bodhi client with the updated server.

The client's API has changed, so if you have a piece of code that imports
from `bodhi.client`, you'll have to update it to use the new API, and in
the meantime use version 5.7.5.

As a user of the `bodhi` CLI, you'll notice that the `--username` and
`--password` options have disappeared. Instead the Bodhi client will ask
you to open your browser to a URL to authenticate. The authentication
tokens will be saved and you'll be able to use the `bodhi` CLI without
authenticating afterwards (or non-interactively).

== Code reorganization ==
The Bodhi source code has been reorganized to drop the hacks used in
`setup.py` to support sub-projects. Instead, `bodhi-server`, `bodhi-client`
and `bodhi-messages` are now actual Python package directories in the repo.
The import path has not changed.

Bodhi's Python project metadata and dependencies are now managed with
Poetry .

== Other changes ==
- Serialized `Release` objects sent in the messages don't contain the
`composes` property anymore
- The `koji-build-group.build.complete` messages now contain an `update`
property
- In the Bodhi client API, the `save_override()` method has been extended
to allow setting the expiration date directly
- Misc bug fixes


If you have any questions, feel free to ask the Bodhi team in our matrix
room: .
If you are importing the bodhi client code in your app/script, or using the
bodhi client in an "unusual" manner, we'll help you migrate.

Thanks!

Aurélien Bompard
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora 36 compose report: 20220406.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-36-20220405.n.0
NEW: Fedora-36-20220406.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  2
Dropped packages:0
Upgraded packages:   45
Downgraded packages: 0

Size of added packages:  55.94 KiB
Size of dropped packages:0 B
Size of upgraded packages:   1.59 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -233.96 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: golang-github-mitchellh-ps-1.0.0-1.fc36
Summary: Find, list, and inspect processes from Go (golang)
RPMs:golang-github-mitchellh-ps-devel
Size:16.28 KiB

Package: python-ast-monitor-0.1.2-1.fc36
Summary: AST-Monitor is a wearable Raspberry Pi computer for cyclists
RPMs:python-ast-monitor-doc python3-ast-monitor
Size:39.67 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  Agda-2.6.2.1-35.fc36
Old package:  Agda-2.6.2-34.fc36
Summary:  A dependently typed functional programming language and proof 
assistant
RPMs: Agda Agda-common ghc-Agda ghc-Agda-devel ghc-Agda-doc 
ghc-Agda-prof ghc-geniplate-mirror ghc-geniplate-mirror-devel 
ghc-geniplate-mirror-doc ghc-geniplate-mirror-prof ghc-murmur-hash 
ghc-murmur-hash-devel ghc-murmur-hash-doc ghc-murmur-hash-prof
Size: 346.86 MiB
Size change:  -6.26 MiB
Changelog:
  * Mon Mar 07 2022 Jens Petersen  - 2.6.2.1-35
  - https://hackage.haskell.org/package/Agda-2.6.2.1/changelog


Package:  Agda-stdlib-1.7.1-1.fc36
Old package:  Agda-stdlib-1.7-2.fc36
Summary:  Agda standard libraries
RPMs: Agda-stdlib Agda-stdlib-docs
Size: 108.54 MiB
Size change:  4.37 KiB
Changelog:
  * Wed Mar 09 2022 Jens Petersen  - 1.7.1-1
  - https://github.com/agda/agda-stdlib/blob/v1.7.1/CHANGELOG.md


Package:  bacula-11.0.6-2.fc36
Old package:  bacula-11.0.5-2.fc35
Summary:  Cross platform network backup for Linux, Unix, Mac and Windows
RPMs: bacula-client bacula-common bacula-console bacula-console-bat 
bacula-devel bacula-director bacula-libs bacula-libs-sql bacula-logwatch 
bacula-storage bacula-traymonitor nagios-plugins-bacula
Size: 26.94 MiB
Size change:  23.29 KiB
Changelog:
  * Tue Sep 14 2021 Sahana Prasad  - 11.0.5-3
  - Rebuilt with OpenSSL 3.0.0

  * Wed Jan 19 2022 Fedora Release Engineering  - 
11.0.5-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Fri Mar 25 2022 Simone Caronni  - 11.0.6-1
  - Update to 11.0.6.

  * Sat Mar 26 2022 Simone Caronni  - 11.0.6-2
  - Update/reorganize patches.


Package:  baresip-2.0.1-1.fc36
Old package:  baresip-2.0.0-1.fc36
Summary:  Modular SIP user-agent with audio and video support
RPMs: baresip baresip-aac baresip-alsa baresip-av1 baresip-codec2 
baresip-ctrl_dbus baresip-g722 baresip-g726 baresip-gsm baresip-gst 
baresip-gst_video baresip-gtk baresip-jack baresip-mpa baresip-mqtt baresip-omx 
baresip-opus baresip-plc baresip-portaudio baresip-pulse baresip-sdl 
baresip-snapshot baresip-sndfile baresip-tools baresip-v4l2 baresip-vp8 
baresip-vp9 baresip-x11
Size: 6.54 MiB
Size change:  8.78 KiB
Changelog:
  * Mon Mar 28 2022 Robert Scheck  2.0.1-1
  - Upgrade to 2.0.1 (#2068919)


Package:  bigloo-4.4c-4.4.fc36
Old package:  bigloo-4.4c-3.2.fc36
Summary:  A compiler for the Scheme programming language
RPMs: bigloo bigloo-doc bigloo-libs
Size: 94.28 MiB
Size change:  -353.46 KiB
Changelog:
  * Mon Mar 28 2022 Jerry James  - 4.4c-4.4
  - Version 4.4c-4


Package:  cli11-2.2.0-1.fc36
Old package:  cli11-2.1.2-2.fc36
Summary:  Command line parser for C++11
RPMs: cli11-devel cli11-docs
Size: 4.51 MiB
Size change:  63.10 KiB
Changelog:
  * Mon Mar 28 2022 Jerry James  - 2.2.0-1
  - Version 2.2.0


Package:  drat-trim-0-0.15.20220212git21296ed.fc36
Old package:  drat-trim-0-0.14.20220104git0c02b4f.fc36
Summary:  Proof checker for DIMACS proofs
RPMs: drat-trim drat-trim-devel drat-trim-tools
Size: 398.42 KiB
Size change:  -599 B
Changelog:
  * Mon Mar 28 2022 Jerry James  - 
0-0.15.20220212git21296ed
  - Update for lrat-check fix


Package:  eclipse-swt-1:4.23-1.fc36
Old package:  eclipse-swt-1:4.22-4.fc36
Summary:  Eclipse SWT: The Standard Widget Toolkit for GTK+
RPMs: eclipse-swt eclipse-swt-javadoc
Size: 12.25 MiB
Size change:  40.57 KiB
Changelog:
  * Wed Mar 16 2022 Nicolas De Amicis  - 1:4.23-1
  - Bump to 4.23


Package:  emacs-iedit-0.9.9.9.9-1.fc36
Old package:  emacs-iedit-0.9.9.9-6.2025git012de2e.fc36
Summary:  Edit multiple regions simultaneously in Emacs
RPMs: emacs-iedit
Size: 123.53 KiB
Size change:  1.38 KiB
Changelog:
  * Mon Mar 28 2022 Jerry James  - 0.9.9.9.9-1
  - Version 0.9.9.9.9
  - BR emacs-nox instead of emacs


Package:  fedora-logos-36.0.0-2.fc36
Old package:  fedora-logos-35.0.0-3.fc36
Summary

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[JT]

On Wed, Apr 6, 2022 at 4:06 AM laolux laolux via devel <
devel@lists.fedoraproject.org> wrote:

> I have no strong opinion on this, and not much say anyways, but I thought
> I could share my little piece of info.
> My currently one and only computer is a 2012 MSI GE60 0ND, with a core
> i7-3630QM, 16GB RAM and retrofitted with a SSD.
> So I would say fast enough for using Fedora. At least according to
> notebookcheck.com the CPU is supposed to be faster than a rather recent
> Core i3-1110G4, which is still being used in new notebooks in 2022.
> Unfortunately it only supports legacy BIOS, and not UEFI.
> Thus I do not like the wording of the change proposal.
>
> > Fedora already requires a 2GHz dual core CPU at minimum (and therefore
> > mandates that machines must have been made after 2006).  Like the
> > already accepted Fedora 37 change to retire ARMv7 support, the
> > hardware targeted tends to be rather underpowered by today’s
> > standards, and the world has moved on from it.  Intel stopped shipping
> > the last vestiges of BIOS support in 2020 (as have other vendors, and
> > Apple and Microsoft), so this is clearly the way things are heading -
> > and therefore aligns with Fedora’s “First” objective.
>
> This seems to imply that only rather old and weak hardware would be
> affected, when clearly the cutoff is (at maximum) only 10 years back.
> Please don't get me wrong, I am perfectly fine about Fedora dropping "old"
> hardware, and I am willing to throw away my still working notebook,
> producing a little bit electronic waste when the time comes. But I think
> one should be more open and explicit about it.
>
>
At the risk of being 'that guy' it's worth pointing out that not everyone
lives in a 1st world country and has access to cheap powerful hardware.  I
have good friends in Namibia and Cote d'Ivoire who are still using Fedora
on Core2Duo systems from pre 2010, because the machines are still perfectly
functional and do what they need them to do.
I realize some will have the attitude of "they can just not upgrade and
keep using their old Fedora versions".  Ok, that's a possible solution,
except that Fedora versions get EOL'd pretty quickly, so we'd basically be
taking the stance of 'buy new hardware if you want updates'.

Fedora has made a big deal about being considered a "Digital Public Good";
and we are right to be proud of that.  But if we're going to be proud of
that, let's not also decide to screw over areas that are not as
economically strong as where most of us are lucky enough to live.  It's
kind of arrogant of us to expect that everyone who uses Fedora is
financially able to go out and replace their hardware all the time even
when there's nothing wrong with it.
Are we only making Fedora for those with lots of spare money or is Fedora
for everyone?
/end being that guy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20220406.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 7/231 (x86_64), 10/161 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20220405.n.2):

ID: 1213061 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1213061
ID: 1213103 Test: aarch64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1213103

Old failures (same test failed in Fedora-Rawhide-20220405.n.2):

ID: 1213026 Test: x86_64 Workstation-live-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1213026
ID: 1213040 Test: x86_64 Workstation-live-iso desktop_printing_builtin
URL: https://openqa.fedoraproject.org/tests/1213040
ID: 1213064 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1213064
ID: 1213126 Test: aarch64 Server-dvd-iso mediakit_repoclosure@uefi
URL: https://openqa.fedoraproject.org/tests/1213126
ID: 1213146 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/1213146
ID: 1213161 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1213161
ID: 1213162 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1213162
ID: 1213164 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1213164
ID: 1213198 Test: x86_64 Workstation-upgrade gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1213198
ID: 1213203 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1213203
ID: 1213213 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1213213
ID: 1213217 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1213217
ID: 1213219 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1213219
ID: 1213283 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1213283
ID: 1213342 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1213342

Soft failed openQA tests: 7/161 (aarch64), 11/231 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-Rawhide-20220405.n.2):

ID: 1213138 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1213138
ID: 1213159 Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1213159
ID: 1213211 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1213211

Old soft failures (same test soft failed in Fedora-Rawhide-20220405.n.2):

ID: 1213029 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1213029
ID: 1213033 Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1213033
ID: 1213044 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1213044
ID: 1213054 Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1213054
ID: 1213071 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1213071
ID: 1213076 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1213076
ID: 1213078 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1213078
ID: 1213079 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1213079
ID: 1213086 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1213086
ID: 1213176 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1213176
ID: 1213177 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1213177
ID: 1213181 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1213181
ID: 1213189 Test: x86_64 Workstation-upgrade desktop_browser
URL: https://openqa.fedoraproject.org/tests/1213189
ID: 1213195 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1213195
ID: 1213224 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1213224

Passed openQA tests: 213/231 (x86_64), 144/161 (aarch64)

New passes (same test not passed in Fedora-Rawhide-20220405.n.2):

ID: 1212961 Test: x86_64 

Re: Bodhi 6.0: What's new

[Vít Ondruch]

I wonder if kerberos going to be supported or not?


Vít



Dne 06. 04. 22 v 12:37 Aurelien Bompard napsal(a):

Hey everyone!

Bodhi 6.0 will be published in a few days, and deployed to production 
a couple weeks after the Fedora release. It has backwards-incompatible 
changes, here's what you need to know.


== Authentication ==
Bodhi gained support for OpenID Connect (OIDC) authentication, like 
most of Fedora's webapps. OpenID still works but is not the default, 
you can access it by using `/login?method=openid` as the login URL.


Version 6.0 of the Bodhi client uses only OIDC, plain OpenID support 
has been dropped. Version 5.7.5 of the Bodhi client, however, uses the 
new OpenID login URL and has been available for about a month now, 
you'll need at least version 5.7.5 to use the Bodhi client with the 
updated server.


The client's API has changed, so if you have a piece of code that 
imports from `bodhi.client`, you'll have to update it to use the new 
API, and in the meantime use version 5.7.5.


As a user of the `bodhi` CLI, you'll notice that the `--username` and 
`--password` options have disappeared. Instead the Bodhi client will 
ask you to open your browser to a URL to authenticate. The 
authentication tokens will be saved and you'll be able to use the 
`bodhi` CLI without authenticating afterwards (or non-interactively).


== Code reorganization ==
The Bodhi source code has been reorganized to drop the hacks used in 
`setup.py` to support sub-projects. Instead, `bodhi-server`, 
`bodhi-client` and `bodhi-messages` are now actual Python package 
directories in the repo. The import path has not changed.


Bodhi's Python project metadata and dependencies are now managed with 
Poetry .


== Other changes ==
- Serialized `Release` objects sent in the messages don't contain the 
`composes` property anymore
- The `koji-build-group.build.complete` messages now contain an 
`update` property
- In the Bodhi client API, the `save_override()` method has been 
extended to allow setting the expiration date directly

- Misc bug fixes


If you have any questions, feel free to ask the Bodhi team in our 
matrix room: .
If you are importing the bodhi client code in your app/script, or 
using the bodhi client in an "unusual" manner, we'll help you migrate.


Thanks!

Aurélien Bompard

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Gary Buhrmaster]

On Wed, Apr 6, 2022 at 12:15 PM Josh Boyer  wrote:

> I agree 100%.  I think this is actually getting to the crux of the
> issue, which is that while we have a lot of people that want BIOS
> support to continue, we effectively have nobody that wants to do the
> work to make it happen.

In a previous thread about bios support, there
was a discussion about (a mythical) someone
resurrecting DUET to provide a transition path.

To the best of my knowledge, no one stepped
up to do that work[0].

Gary


[0] Quite honestly, given that DUET was removed
upstream, I would have thought looking instead
at Clover (which is still supported) would be a
better option, but better only in some theoretical
sense, as there was no one to do that work
either.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bodhi 6.0: What's new

[Aurelien Bompard]

Hey Frantisek!

Excellent questions!

> * Our users can use Packit via CLI and use their identity for Bodhi 
> connections. With this, it's not nice, but doable to open a web-browser. (Not 
> sure how this works in the containerised use-cases.)

The Bodhi CLI will display a URL that you'll have to open in your web browser, 
and wait for input. After logging in, Ipsilon will give you a token that you 
need to copy/paste in the Bodhi CLI.

> * Is there some way to get/generate some token that can be used instead of 
> doing this browser workflow?

Yes, you can do the browser workflow on any host and then copy over the 
~/.config/bodhi/client.json file on the service's worker(s).

> * Do I get it right from what you wrote about `save_override` that we can 
> generate the session token elsewhere and reuse it in the service? Do you have 
> some details on how this works so we can start working on the move?

That's not what save_override() does, it's just an API endpoint to edit 
buildroot overrides in Bodhi.

> * For other Fedora systems, we use Kerberos authentication, are there some 
> plans to add it?

Nope, there's no plan for that at the moment.

Does this answer your questions?

Aurélien
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 06 April 2022 at 13:07, Richard Hughes wrote:
> On Wed, 6 Apr 2022 at 11:20, Dominik 'Rathann' Mierzejewski
>  wrote:
> > > and on its way out.  As it ages, maintainability has decreased, and
> > > the status quo of maintaining both stacks in perpetuity is not viable
> > > for those currently doing that work.
> > Have you tried getting more people involved?
> 
> I don't think that's how Open Source works. Realistically the way I
> see this playing out is that the people responsible for maintaining
> the legacy boot stack will retire the packages,

I thought they would be orphaned, if anything. Retiring seems rather
hostile to the people who still need those packages (which are those,
by the way?).

> some well meaning
> community people take them over, then everything breaks in an
> unexpected way before a Fedora release for some technical reason and

If this change is accepted, then BIOS-based installations will break
and will have to be removed from release blocking criteria because
anaconda will simply not support that use case anymore. That's how I
understand the impact although this is not explicitly written in the
change proposal.

> the new package maintainers have no idea how to fix the underlying
> issue. Then Fedora QA needs to decide if the legacy boot failure is
> actually release blocking. I'm happy to be proved wrong, but asking
> someone "have you tried getting more people involved" is neither
> helpful nor realistic.

It's helpful to show the change proponents attitude. As a way of "asking
more people to get involved", I'd expect a list of packages the change
proponents no longer whish to maintain and a date when they will orphan
them, since they've stated they're going to do that anyway. Without such
list it's difficult to assess the scope of the work required to maintain
the affected software stack. I don't see any such details in the change
proposal.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[PGNet Dev]

I'm shutting up now, because this comment from ngompa is, IMO, very 
well/thoroughly said.
thx Neal!

On 4/6/22 8:16 AM, Neal Gompa wrote:

If you really have a need to reinstall such machine, you'll take the F36
image and upgrade to F37+ and you should still be good.



This is not a deprecation change, this is effectively a removal
change. By removing the packages and the tooling support for legacy
BIOS, it makes several scenarios (including recovery) harder.
Moreover, it puts the burden on people to figure out if their hardware
can boot and install Fedora when we clearly haven't reached a critical
mass yet for doing so, like we did when we finally removed the i686
kernel build.

I'm personally a fan of using UEFI instead of BIOS. Heck, I
implemented support for UEFI in Fedora's cloud images when other
people told me it was not possible, while preserving BIOS support.
I've been trying to figure out the roadmap for BIOS deprecation for a
year now, and the reason *I* didn't propose a Change yet is because I
have not sufficiently determined that it was reasonable to do so.

I'm particularly upset about this Change because it feels like a
hostage change where the proposal owners blithely ignore what we're
saying as unimportant or irrelevant and abuse our principles to do
things that are clearly against what the community feels is right.

I have been trying in the background for years to try to figure out
solutions for usability problems in Fedora Linux on UEFI because *I
want our experience to be good there*. But it's extremely hard when:

1. Bugs and feature requests around UEFI related features are ignored
2. The packages are locked down so there is no way for the community to help
3. At various times, people have explicitly said "patches NOT welcome"

I'm angry because we're doing this without any real thought around the
consequences for the user experience, and we should not do that as a
premier Linux distribution.



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Gary Buhrmaster]

On Wed, Apr 6, 2022 at 1:16 AM Neal Gompa  wrote:
>
> On Tue, Apr 5, 2022 at 9:07 PM Demi Marie Obenour  
> wrote:
> >
> > On 4/5/22 16:09, Neal Gompa wrote:

> > > This problem also makes life miserable for people working with third
> > > party open source kernel modules too. As a live streamer, for example,
> > > I need to use v4l2loopback, which will never exist in mainline because
> > > v4l2 maintainers don't like it at all.

> > Are you sure about that?  There is probably a better place to talk
> > about this, but Qubes OS also will be needing v4l2loopback soon (for
> > Qubes Video Companion) and so I have a strong interest in getting it
> > upstreamed.
> >
>
> Yes. Last I heard, V4L2 folks think it'd be used to bypass making a
> real camera driver for the kernel. That's pretty much why it's not
> there.

Well, I think it was mostly one person, but as
they are the primary maintainer for the subsystem
that opinion carries some weight (although it
should be noted that another co/sub-maintainer
has been somewhat more interested in getting
v4l2loopback upstreamed).  However, last I knew,
there was still some significant work to be
completed on the driver in order to meet current
kernel and subsystem standards before it could
be reconsidered for inclusion.  Those that want
to see the driver upstreamed should likely
contribute to those changes.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Neal Gompa]

On Wed, Apr 6, 2022 at 8:04 AM Vít Ondruch  wrote:
>
>
> Dne 05. 04. 22 v 17:08 Neal Gompa napsal(a):
> > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton  wrote:
> >> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
> >>
> >> == Summary ==
> >> Make UEFI a hardware requirement for new Fedora installations on
> >> platforms that support it (x86_64).  Legacy BIOS support is not
> >> removed, but new non-UEFI installation is not supported on those
> >> platforms.  This is a first step toward eventually removing legacy
> >> BIOS support entirely.
> >>
> >> == Owner ==
> >> * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
> >> Konečný]], [[User:bcl| Brian C. Lane]]
> >> * Email: rharw...@redhat.com
> >>
> >>
> >> == Detailed Description ==
> >> UEFI is defined by a versioned standard that can be tested and
> >> certified against.  By contrast, every legacy BIOS is unique. Legacy
> >> BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
> >> and on its way out.  As it ages, maintainability has decreased, and
> >> the status quo of maintaining both stacks in perpetuity is not viable
> >> for those currently doing that work.
> >>
> >> It is inevitable that legacy BIOS will be removed in a future release.
> >> To ease this transition as best we can, there will be a period (of at
> >> least one Fedora release) where it will be possible to boot using the
> >> legacy BIOS codepaths, but new installations will not be possible.
> >> While it would be easier for us to cut support off today, our hope is
> >> that this compromise position will make for a smoother transition.
> >> Additional support with issues during the transition would be
> >> appreciated.
> >>
> >> While this will eventually reduce workload for boot/installation
> >> components (grub2 reduces surface area, syslinux goes away entirely,
> >> anaconda reduces surface area), the reduction in support burden
> >> extends much further into the stack - for instance, VESA support can
> >> be removed from the distro.
> >>
> >> Fedora already requires a 2GHz dual core CPU at minimum (and therefore
> >> mandates that machines must have been made after 2006).  Like the
> >> already accepted Fedora 37 change to retire ARMv7 support, the
> >> hardware targeted tends to be rather underpowered by today’s
> >> standards, and the world has moved on from it.  Intel stopped shipping
> >> the last vestiges of BIOS support in 2020 (as have other vendors, and
> >> Apple and Microsoft), so this is clearly the way things are heading -
> >> and therefore aligns with Fedora’s “First” objective.
> >>
> >> == Feedback ==
> >> Dropping legacy BIOS was previously discussed (but not proposed) in 2020:
> >> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/
> >>
> >> Important, relevant points from that thread (yes, I reread the entire
> >> thread) that have informed this change:
> >>
> >> * Some machines are BIOS-only.  This change does not prevent their use
> >> yet, but they are effectively deprecated.  grub2 (our default
> >> bootloader) is already capable of both BIOS and UEFI booting.
> >> * Drawing a clear year cutoff, let alone a detailed list of hardware
> >> this change affects, is basically impossible.  This is unfortunate but
> >> unlikely to ever change.
> >> * There is no migration story from Legacy BIOS to UEFI -
> >> repartitioning effectively mandates a reinstall.  As a result, we
> >> don’t drop support for existing Legacy BIOS systems yet, just new
> >> installations.
> >> * There is no way to deprecate hardware without causing some amount of 
> >> friction.
> >> * While at the time AWS did not support UEFI booting, that is no
> >> longer the case and they support UEFI today.
> >>
> >> == Benefit to Fedora ==
> >> UEFI is required for many desirable features, including applying
> >> firmware updates (fwupd) and supporting SecureBoot.  As a standalone
> >> change, it reduces support burden on everything involved in installing
> >> Fedora, since there becomes only one way to do it per platform.
> >> Finally, it simplifies our install/live media, since it too only has
> >> to boot one way per arch.  Freedom Friends Features First - this is
> >> that last one.
> >>
> >> == Scope ==
> >> * Proposal owners:
> >> ** bootloaders: No change (existing Legacy BIOS installations still 
> >> supported).
> >> ** anaconda: No change (there could be only optional cleanups in the
> >> code). However, it needs to be verified.
> >> ** Lorax: Code has already been written:
> >> https://github.com/weldr/lorax/pull/1205
> >>
> > This pull request primarily drops legacy BIOS support by dropping
> > syslinux/isolinux. We don't necessarily have to drop legacy BIOS
> > support there if we reuse GRUB there too. Other distributions
> > (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on
> > live media.
> >
> >> * Other developers:
> >> ** libvirt: UEFI works today, but is