date:20220414

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

Gary Buhrmaster  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
  Flags||needinfo?(marianne@tuxette.
   ||fr)



--- Comment #1 from Gary Buhrmaster  ---
Are you going to be able to build perl-XML-TreePP in epel9?


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2031448
___
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: Unannounced .so version bump in libcerf

2022-04-14 Thread Orion Poplawski


On 4/11/22 20:41, Christoph Junghans wrote:

On Mon, Apr 11, 2022 at 9:50 AM Ben Beasley  wrote:


The libcerf package was updated to version 2.1 in Rawhide yesterday[1],
which included an unannounced .so version bump from “1” to “2”.

My mistake, I thought I did a "dnf repoquery --whatrequires
libcerf.so.1", but it only showed libecpint.


If you are on x86_64 you would want:

dnf repoquery --whatrequires 'libcerf.so.2()(64bit)'
Last metadata expiration check: 0:14:59 ago on Thu 14 Apr 2022 08:23:49 
PM MDT.

LabPlot-0:2.8.1-6.fc37.x86_64
gnuplot-0:5.4.3-3.fc37.x86_64
gnuplot-minimal-0:5.4.3-3.fc37.x86_64
gnuplot-wx-0:5.4.3-3.fc37.x86_64
libcerf-devel-0:2.1-1.fc37.x86_64
libecpint-0:1.0.7-4.fc37.x86_64

dnf repoquery --whatrequires libcerf.so.2
Last metadata expiration check: 0:14:35 ago on Thu 14 Apr 2022 08:23:49 
PM MDT.

libcerf-devel-0:2.1-1.fc37.i686
libecpint-0:1.0.7-4.fc37.i686

only gets you the 32-bit deps.

--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic 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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Nikolay Nikolov



On 4/15/22 04:01, Jóhann B. Guðmundsson wrote:

On 14.4.2022 23:25, Nikolay Nikolov wrote:


On 4/15/22 01:53, Jóhann B. Guðmundsson wrote:

On 14.4.2022 22:24, Nikolay Nikolov wrote:


On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:

On 14.4.2022 18:20, Chris Adams wrote:

Once upon a time, Robbie Harwood  said:

Given there is consensus that legacy BIOS is on its way out
I don't think this statement is true, unless Fedora doesn't want 
to be
considered for a bunch of popular VM hosts (e.g. Linode and such) 
that

have no stated plans to support UEFI.

Maybe "legacy BIOS on physical hardware" is on its way out



It's not an maybe, it is on it's way out either physically or 
simply via firmware update [1]


"In the bios, upgraded to 810 the option to enable legacy boot is 
greyed out"


So how do people propose the situation to be handled when firmware 
from vendors, disables the legacy boot option via firmware update.


Is Fedora supposed to block/blacklist those firmware updates via 
some plugin in lvfs based on user feedback when their legacy boot 
mode suddenly stops working or is it expected that upstream lvfs 
team looks into this or what?


Fedora doesn't install these updates. Users install these updates, 
when they have a problem



In the past they did, today users ( including the novice ones ) 
update it as Gnome notifies them about available update just like 
they do when they receive anyother software update notification.


Really? I didn't know that. At least on my computers, Gnome has never 
notified me about a BIOS update from my motherboard vendor. Besides, 
it's proprietary software, so I wouldn't expect Fedora to be offering 
it by default. Doesn't it need adding an extra software repository?



It's fwup/lvfs [1] and nope you dont need to jump through any 
additional hoops for that, it just work ( or it does not if the vendor 
is not part of lfvs ).


Oh, wow! Yeah, my new desktop has an ASRock motherboard and my laptop is 
an HP and, and while both vendors (HP and Asus) participate in lvfs, 
they don't seem to upload a lot of firmware updates (HP has uploaded 34 
firmware files, for comparison Dell has uploaded 2033 firmware files). 
But I'm still surprised that Fedora by default downloads and updates 
proprietary firmware, downloaded from the Internet. Btw, does this work 
in legacy boot mode as well? If I recall correctly, someone in the 2020 
thread mentioned that fwupd requires boot in UEFI mode, but I don't 
remember the exact details.








And besides, non-UEFI systems don't normally receive BIOS updates 
that break legacy boot, because legacy boot is the only boot option 
available, so what is your point, exactly?



Obviously this was for dual bios mode ( legacy and uefi ) ( 
otherwise the option to disable it would not be there ) in which the 
vendor himself seemingly decided to disable the legacy part of the 
bios via firmware update which highlight the fact that we somehow 
need to deal with that situation if we want to continue to support 
the legacy bios option.


How I have no clue, which is why I pointed at an potential lvfs 
plugin or the lvfs team.


I think we should check the BIOS date in the installer and deprecate 
(as in, print warnings to the user in the installer) legacy boot on 
newer systems (e.g. newer than 2017 or some other cutoff date, when 
we decide that UEFI becomes more stable), an by deprecate, I mean, 
show warnings to the user and suggest that they continue on their own 
risk. Of course, we should also check for virtual machines, like e.g. 
QEMU/SeaBIOS, that are known to be stable in legacy BIOS mode and not 
show the warning in them, even if the BIOS date is new (although 
SeaBIOS seems to use an old date - 06/23/99).



That's something that needs to be worked out with the Anaconda team 
but I think Javier already provide the best path forward with regards 
to Anaconda when I started the dialog two years ago but for whatever 
reason that's not part of Robbie's proposal.



What was Javier's proposal?

Best regards,

Nikolay



JBG

1. https://fwupd.org/


___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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___
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:

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Samuel Sieb


On 4/14/22 15:53, Jóhann B. Guðmundsson wrote:

On 14.4.2022 22:24, Nikolay Nikolov wrote:


On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:

On 14.4.2022 18:20, Chris Adams wrote:

Once upon a time, Robbie Harwood  said:

Given there is consensus that legacy BIOS is on its way out

I don't think this statement is true, unless Fedora doesn't want to be
considered for a bunch of popular VM hosts (e.g. Linode and such) that
have no stated plans to support UEFI.

Maybe "legacy BIOS on physical hardware" is on its way out



It's not an maybe, it is on it's way out either physically or simply 
via firmware update [1]


"In the bios, upgraded to 810 the option to enable legacy boot is 
greyed out"


So how do people propose the situation to be handled when firmware 
from vendors, disables the legacy boot option via firmware update.


Is Fedora supposed to block/blacklist those firmware updates via some 
plugin in lvfs based on user feedback when their legacy boot mode 
suddenly stops working or is it expected that upstream lvfs team 
looks into this or what?


Fedora doesn't install these updates. Users install these updates, 
when they have a problem



In the past they did, today users ( including the novice ones ) update 
it as Gnome notifies them about available update just like they do when 
they receive anyother software update notification.


That only applies to a UEFI system, so it doesn't matter if legacy mode 
gets disabled by the update since it's already using UEFI to boot.

___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?


On 15.4.2022 00:44, Kevin Kofler via devel wrote:

One of the reasons people use GNU/Linux is exactly to escape the hardware
manufacturers' planned obsolescence treadmill.


True but that does not mean Fedora is the best distro for that + it 
looks like hw vendors are taking lessons from the Apple playbook and 
starting to vendor lock parts for their hw.



JBG
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?


On 14.4.2022 23:25, Nikolay Nikolov wrote:


On 4/15/22 01:53, Jóhann B. Guðmundsson wrote:

On 14.4.2022 22:24, Nikolay Nikolov wrote:


On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:

On 14.4.2022 18:20, Chris Adams wrote:

Once upon a time, Robbie Harwood  said:

Given there is consensus that legacy BIOS is on its way out
I don't think this statement is true, unless Fedora doesn't want 
to be
considered for a bunch of popular VM hosts (e.g. Linode and such) 
that

have no stated plans to support UEFI.

Maybe "legacy BIOS on physical hardware" is on its way out



It's not an maybe, it is on it's way out either physically or 
simply via firmware update [1]


"In the bios, upgraded to 810 the option to enable legacy boot is 
greyed out"


So how do people propose the situation to be handled when firmware 
from vendors, disables the legacy boot option via firmware update.


Is Fedora supposed to block/blacklist those firmware updates via 
some plugin in lvfs based on user feedback when their legacy boot 
mode suddenly stops working or is it expected that upstream lvfs 
team looks into this or what?


Fedora doesn't install these updates. Users install these updates, 
when they have a problem



In the past they did, today users ( including the novice ones ) 
update it as Gnome notifies them about available update just like 
they do when they receive anyother software update notification.


Really? I didn't know that. At least on my computers, Gnome has never 
notified me about a BIOS update from my motherboard vendor. Besides, 
it's proprietary software, so I wouldn't expect Fedora to be offering 
it by default. Doesn't it need adding an extra software repository?



It's fwup/lvfs [1] and nope you dont need to jump through any additional 
hoops for that, it just work ( or it does not if the vendor is not part 
of lfvs ).








And besides, non-UEFI systems don't normally receive BIOS updates 
that break legacy boot, because legacy boot is the only boot option 
available, so what is your point, exactly?



Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise 
the option to disable it would not be there ) in which the vendor 
himself seemingly decided to disable the legacy part of the bios via 
firmware update which highlight the fact that we somehow need to deal 
with that situation if we want to continue to support the legacy bios 
option.


How I have no clue, which is why I pointed at an potential lvfs 
plugin or the lvfs team.


I think we should check the BIOS date in the installer and deprecate 
(as in, print warnings to the user in the installer) legacy boot on 
newer systems (e.g. newer than 2017 or some other cutoff date, when we 
decide that UEFI becomes more stable), an by deprecate, I mean, show 
warnings to the user and suggest that they continue on their own risk. 
Of course, we should also check for virtual machines, like e.g. 
QEMU/SeaBIOS, that are known to be stable in legacy BIOS mode and not 
show the warning in them, even if the BIOS date is new (although 
SeaBIOS seems to use an old date - 06/23/99).



That's something that needs to be worked out with the Anaconda team but 
I think Javier already provide the best path forward with regards to 
Anaconda when I started the dialog two years ago but for whatever reason 
that's not part of Robbie's proposal.



JBG

1. https://fwupd.org/
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

Justin Forbes wrote:
> The i686 SIG was given multiple releases to organize. The original
> proposal which triggered the SIG to form was for F27, the proposal to
> finally kill it and declare the SIG inactive was F31.

But, the way I remember it, the SIG was declared inactive just because of 
*one* unfixed kernel bug (the primary platforms have hundreds) and perceived 
lack of mailing list activity (IIRC, the complaints were that there were too 
few messages, but that limit is arbitrary, and that the bug was not 
discussed on the mailing list, which is normal because that is what Bugzilla 
is for).

> But this is different from the i686 kernel SIG in some critical ways.

But is this going to help, if the SIG will be held to unreasonable standards 
just to have an excuse to kill it at the next opportunity?

Kevin Kofler
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?


On 15.4.2022 00:38, Kevin Kofler via devel wrote:

Jóhann B. Guðmundsson wrote:

Trying to support that legacy scenario where certain hw may or may not
work is a nightmare for developers, support teams and Fedora since
Fedora is not a distribution with a long term support, LTS distributions
are better suited to support legacy hw then Fedora ever will.

Nobody is asking Fedora to provide support for fixing old hardware if it
breaks. All we are asking for is for Fedora to continue running on old
hardware that is *not* broken.



Yes I got that it's the hw version of "if it builds let's ship it, even 
if upstream is dead" approach.


The thing is we could elimination so much of technical debt in Fedora if 
we would drop the legacy bios support and could move the distro quite a 
bit forward in coming releases if we did but from the looks of it, it 
seems to have been already decided to "form a sig" and drop this 
proposal so meh Fedora 40 then...



JBG
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

Jóhann B. Guðmundsson wrote:
> No but it does mean that they cant run indefinitely

Only if the spare parts that are not available actually fail (and if you 
cannot find the spare parts through less official channels, such as buying 
another broken computer where the part you need is still working). And, as 
explained elsewhere in this thread, the parts most likely to fail can 
actually be replaced with generic replacements.

Also keep in mind that many Fedora users have one or two computers, not 
hundreds. That makes it much less likely to run into a hardware failure in a 
given time interval, and there is very little incentive to "fix" what is not 
broken.

> And there needs to be a number on this to adjust users expectation and
> 10 years is a reasonable number from a business, parts and
> recycle/re-use availability,

10 years is *not* a reasonable number when a notebook still runs great after 
14 years.

> What is unreasonable is to be expecting that it's supported indefinitely
> from OS and or HW vendors.

One of the reasons people use GNU/Linux is exactly to escape the hardware 
manufacturers' planned obsolescence treadmill.

Kevin Kofler
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

Jóhann B. Guðmundsson wrote:
> Trying to support that legacy scenario where certain hw may or may not
> work is a nightmare for developers, support teams and Fedora since
> Fedora is not a distribution with a long term support, LTS distributions
> are better suited to support legacy hw then Fedora ever will.

Nobody is asking Fedora to provide support for fixing old hardware if it 
breaks. All we are asking for is for Fedora to continue running on old 
hardware that is *not* broken.

Some parts are hard to swap, others are easy. My soon 14-year-old notebook 
has a relatively new hard disk (standard SATA laptop/notebook HDD, thinner 
than the original one, but the screws hold it in the correct position, so 
that does not matter and actually improves cooling airflow) and power supply 
adapter (cheap generic universal power supply, one of the offered plugs is 
both physically and electrically compatible with my notebook). The old HDD 
might even have worked longer, I replaced it after the first failed sector, 
with a faster (7200 rpm instead of 5400 rpm) one with twice the capacity 
(512 GB instead of 256 GB, though, if I had waited a bit longer, I could 
have gotten an SSD of the same size instead for that price, but now I do not 
want to replace the storage again in that ancient notebook). The power 
supply adapter was the only thing I *had* to replace, as the old one had 
failed completely.

(And, realistically speaking, the HDD and the power supply are statistically 
among the parts most likely to fail to begin with.)

Kevin Kofler
___
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: UEFI net boot, shim, Fedora, and CentOS

2022-04-14 Thread Chris Adams

Once upon a time, Neal Gompa  said:
> On Thu, Apr 14, 2022 at 8:27 PM Chris Adams  wrote:
> > Is there any way around this?  Does the Fedora shim only support Fedora
> > kernels, and the CentOS shim only support CentOS kernels, and since shim
> > is loaded first, there's no way to net-boot both from the same system?
> 
> That is correct. You will need to have distinct shims for each
> distribution on the same system. That should be possible by loading
> the shim binaries from EFI//shimx64.efi.

I don't see any way to do that on the same net-boot server, since that's
a DHCP server option, not something in grub.cfg.
-- 
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

Re: UEFI net boot, shim, Fedora, and CentOS

On Thu, Apr 14, 2022 at 8:27 PM Chris Adams  wrote:
>
> So after all the boot discussion, I was updating my net boot setup to
> handle all the modes (BIOS PXE, UEFI PXE, UEFI HTTP, with UEFI loading
> shim for Secure Boot support).  I got it all working for Fedora, then I
> tried to boot CentOS.  It looks like the Fedora-supplied shim doesn't
> recognize the CentOS kernel signature.
>
> Is there any way around this?  Does the Fedora shim only support Fedora
> kernels, and the CentOS shim only support CentOS kernels, and since shim
> is loaded first, there's no way to net-boot both from the same system?
>

That is correct. You will need to have distinct shims for each
distribution on the same system. That should be possible by loading
the shim binaries from EFI//shimx64.efi.



-- 
真実はいつも一つ！/ 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

UEFI net boot, shim, Fedora, and CentOS

2022-04-14 Thread Chris Adams

So after all the boot discussion, I was updating my net boot setup to
handle all the modes (BIOS PXE, UEFI PXE, UEFI HTTP, with UEFI loading
shim for Secure Boot support).  I got it all working for Fedora, then I
tried to boot CentOS.  It looks like the Fedora-supplied shim doesn't
recognize the CentOS kernel signature.

Is there any way around this?  Does the Fedora shim only support Fedora
kernels, and the CentOS shim only support CentOS kernels, and since shim
is loaded first, there's no way to net-boot both from the same system?

-- 
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

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

Jóhann B. Guðmundsson wrote:
> Then there is the fact that clinging to legacy bios is working against
> Fedora's own foundation "First" in which is stated "Fedora always aims
> to provide the future, first".

How is it against "First" to continue providing the future also for hardware 
of the past? "First" means that Fedora *delivers* the latest, not 
that it *requires* the latest Doing the latter actually goes 
against the "Freedom" (where is my Freedom Zero, run the software as I 
wish?), "Features" (desupporting old hardware = removing a feature) and 
"Friends" (people dropping support for my hardware are not my friends!) 
foundations.

As I already pointed out once, continued support for old hardware does *not* 
preclude shipping the latest software first. You keep bringing up this false 
dichotomy. The repetition does not make it any truer.

Kevin Kofler
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Nikolay Nikolov



On 4/15/22 01:53, Jóhann B. Guðmundsson wrote:

On 14.4.2022 22:24, Nikolay Nikolov wrote:


On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:

On 14.4.2022 18:20, Chris Adams wrote:

Once upon a time, Robbie Harwood  said:

Given there is consensus that legacy BIOS is on its way out

I don't think this statement is true, unless Fedora doesn't want to be
considered for a bunch of popular VM hosts (e.g. Linode and such) that
have no stated plans to support UEFI.

Maybe "legacy BIOS on physical hardware" is on its way out



It's not an maybe, it is on it's way out either physically or simply 
via firmware update [1]


"In the bios, upgraded to 810 the option to enable legacy boot is 
greyed out"


So how do people propose the situation to be handled when firmware 
from vendors, disables the legacy boot option via firmware update.


Is Fedora supposed to block/blacklist those firmware updates via 
some plugin in lvfs based on user feedback when their legacy boot 
mode suddenly stops working or is it expected that upstream lvfs 
team looks into this or what?


Fedora doesn't install these updates. Users install these updates, 
when they have a problem



In the past they did, today users ( including the novice ones ) update 
it as Gnome notifies them about available update just like they do 
when they receive anyother software update notification.


Really? I didn't know that. At least on my computers, Gnome has never 
notified me about a BIOS update from my motherboard vendor. Besides, 
it's proprietary software, so I wouldn't expect Fedora to be offering it 
by default. Doesn't it need adding an extra software repository?





And besides, non-UEFI systems don't normally receive BIOS updates 
that break legacy boot, because legacy boot is the only boot option 
available, so what is your point, exactly?



Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise 
the option to disable it would not be there ) in which the vendor 
himself seemingly decided to disable the legacy part of the bios via 
firmware update which highlight the fact that we somehow need to deal 
with that situation if we want to continue to support the legacy bios 
option.


How I have no clue, which is why I pointed at an potential lvfs plugin 
or the lvfs team.


I think we should check the BIOS date in the installer and deprecate (as 
in, print warnings to the user in the installer) legacy boot on newer 
systems (e.g. newer than 2017 or some other cutoff date, when we decide 
that UEFI becomes more stable), an by deprecate, I mean, show warnings 
to the user and suggest that they continue on their own risk. Of course, 
we should also check for virtual machines, like e.g. QEMU/SeaBIOS, that 
are known to be stable in legacy BIOS mode and not show the warning in 
them, even if the BIOS date is new (although SeaBIOS seems to use an old 
date - 06/23/99).


Nikolay


JBG

___
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

___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

If people are wondering how it looks like when Fedora's code of conduct 
is violated when people partaking in community discussions and receive 
attacks in private as an result of that here's an example of that.


This individual has already sent at least me death threats ( privately 
), been blocked on other projects ( non fedora related ) mailinglist ( 
not involving me in those ) shown questionable behavior on the ISC 
mailinglist and now two years later he's at it again.


Word of advice when attack like these happen in private the best way to 
deal with it first and foremost try not let it discourage you, secondly 
expose the attacker to the broader community ( which I'm doing with this 
post and did last time as well ) since Fedora CoC is powerless to deal 
with this ( Often these attackers frequently change email addresses ) 
and the attacker knows it, like his response to me in private when I 
exposed him last time here on devel.


"little idiot: the Fedora COC don't apply for pruvate mails just because 
the topic is fedora relevant"



On 14.4.2022 21:46, Reindl Harald (privat) wrote:



Am 14.04.22 um 22:49 schrieb Jóhann B. Guðmundsson:
"In the bios, upgraded to 810 the option to enable legacy boot is 
greyed out"


So how do people propose the situation to be handled when firmware 
from vendors, disables the legacy boot option via firmware update.


Is Fedora supposed to block/blacklist those firmware updates via some 
plugin in lvfs based on user feedback when their legacy boot mode 
suddenly stops working or is it expected that upstream lvfs team 
looks into this or what?

are you mentally ill?

there are tons of physical hardware and virtual machines which don't 
give a shit and just work in BIOS mode


and smome are installed that way because UEFI has no fucking way to 
keep /boot on RAID1 over multiple disks



JBG
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?


On 14.4.2022 22:24, Nikolay Nikolov wrote:


On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:

On 14.4.2022 18:20, Chris Adams wrote:

Once upon a time, Robbie Harwood  said:

Given there is consensus that legacy BIOS is on its way out

I don't think this statement is true, unless Fedora doesn't want to be
considered for a bunch of popular VM hosts (e.g. Linode and such) that
have no stated plans to support UEFI.

Maybe "legacy BIOS on physical hardware" is on its way out



It's not an maybe, it is on it's way out either physically or simply 
via firmware update [1]


"In the bios, upgraded to 810 the option to enable legacy boot is 
greyed out"


So how do people propose the situation to be handled when firmware 
from vendors, disables the legacy boot option via firmware update.


Is Fedora supposed to block/blacklist those firmware updates via some 
plugin in lvfs based on user feedback when their legacy boot mode 
suddenly stops working or is it expected that upstream lvfs team 
looks into this or what?


Fedora doesn't install these updates. Users install these updates, 
when they have a problem



In the past they did, today users ( including the novice ones ) update 
it as Gnome notifies them about available update just like they do when 
they receive anyother software update notification.



And besides, non-UEFI systems don't normally receive BIOS updates that 
break legacy boot, because legacy boot is the only boot option 
available, so what is your point, exactly?



Obviously this was for dual bios mode ( legacy and uefi ) ( otherwise 
the option to disable it would not be there ) in which the vendor 
himself seemingly decided to disable the legacy part of the bios via 
firmware update which highlight the fact that we somehow need to deal 
with that situation if we want to continue to support the legacy bios 
option.


How I have no clue, which is why I pointed at an potential lvfs plugin 
or the lvfs team.



JBG

___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Nikolay Nikolov

On 4/14/22 23:49, Jóhann B. Guðmundsson wrote:

On 14.4.2022 18:20, Chris Adams wrote:

Once upon a time, Robbie Harwood said:

Given there is consensus that legacy BIOS is on its way out

I don't think this statement is true, unless Fedora doesn't want to be
considered for a bunch of popular VM hosts (e.g. Linode and such) that
have no stated plans to support UEFI.

Maybe "legacy BIOS on physical hardware" is on its way out

It's not an maybe, it is on it's way out either physically or simply
via firmware update [1]

"In the bios, upgraded to 810 the option to enable legacy boot is
greyed out"

So how do people propose the situation to be handled when firmware
from vendors, disables the legacy boot option via firmware update.

Is Fedora supposed to block/blacklist those firmware updates via some
plugin in lvfs based on user feedback when their legacy boot mode
suddenly stops working or is it expected that upstream lvfs team looks
into this or what?

Fedora doesn't install these updates. Users install these updates, when
they have a problem, which they need to resolve. Most people never
update their BIOS [1], because their system is working just fine. Only
power users do, and they know how to read changelogs and how to backup
their previous working BIOS. So, no, it's not Fedora's problem if a
users installs a BIOS update that bricks their system, or renders it
unbootable (for whatever reasons, doesn't matter whether they're related
to legacy boot or not). We have no obligation to prevent that. The right
approach to BIOS update is "don't do it, unless you have to". If it
ain't broke, don't fix it. I've been burned so many times, due to buggy
BIOS updates, most of them unrelated to legacy boot. We don't prevent
BIOS updates that break UEFI or secure boot, or which brick the system,
so why should we prevent BIOS updates that break legacy boot?

And besides, non-UEFI systems don't normally receive BIOS updates that
break legacy boot, because legacy boot is the only boot option
available, so what is your point, exactly?

If you want to deprecate legacy boot on new installs on UEFI-capable
BIOS-es, that's another story. E.g. if the installer detects that the
BIOS is modern (e.g. later than 2017-2018) and UEFI capable, but is
running in legacy boot mode, it could prints a warning and suggest to
the user to restart and turn off legacy boot from the BIOS setup. The
installer promises better hardware support, firmware updates and happier
times to the user if the operating system is installed in UEFI mode.
Finally user decides whether to do that, or choose to continue on their
own risk. That is totally reasonable, IMHO. But it is a completely
different thing than dropping legacy BIOS support completely.

1. It is indeed still universally called BIOS, even though it's UEFI:
https://www.asrock.com/support/BIOSIG.asp?cat=BIOS10

Best regards,

Nikolay

JBG

1.
https://forum-en.msi.com/index.php?threads/msi-pro-dp20z-5m-legacy-boot-how-to-enable-legacy-boot.374479/

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

___
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 2075690] New: perl-Locale-Maketext-1.31 is available

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

Bug ID: 2075690
   Summary: perl-Locale-Maketext-1.31 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Locale-Maketext
  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: 1.31
Current version/release in rawhide: 1.30-1.fc37
URL: http://search.cpan.org/dist/Locale-Maketext/

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/3034/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2075690
___
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: grub2 BIOS booting iso and code

2022-04-14 Thread Brian C. Lane

On Thu, Apr 14, 2022 at 08:59:28PM +0200, Hans de Goede wrote:
> Hi Brian,
> 
> On 4/14/22 01:52, Brian C. Lane wrote:
> > A huge thanks to Thomas Schmitt for posting xorrisofs arguments :)
> > 
> > Here is a lorax PR switching to grub2 for BIOS and changing the layout
> > of the iso as described in his post:
> > 
> > https://github.com/weldr/lorax/pull/1226
> > 
> > And a Fedora 36 iso:
> > 
> > https://bcl.fedorapeople.org/boot-grub2-f36.iso
> > 
> > I've tested this with:
> > 
> > - qemu bios -cdrom
> > - qemu uefi -cdrom
> > - qemu bios -hda
> > - qemu uefi -hda
> > - USB stick on uefi PC hardware with SB off
> > - USB stick on UEFI PC hardware with SB on
> > - USB stick on Apple hardware UEFI
> >   2010 Macbook Air and 2012 Macbook Pro
> > - Media test works on all of the above
> > 
> > I have not tested it on CD or DVD physical media. I have a stack of
> > blank discs but apparently have unplugged all my drives to use their
> > SATA ports for SSDs :)
> 
> Thank you so much for working on this.
> 
> I've dd-ed the boot-grub2-f36.iso to an USB stick and successfully
> tested it on the following machines:
> 
> 1. Siemens PC with an i5-2400 with 8G RAM
> 2. Fujitsu-Siemens PC with a Core 2 Duo E6600 2.4 Ghz dual core with 4G RAM
> 3. Dell Latitude E6400 (core 2 duo) with 4G RAM
> 4. Acer One AO532 netbook with a N450 + 2G RAM
> 
> The image booted fine on all 4 machines, so from a machine
> compatibility pov this looks good to me.

Thanks for testing!

> There were 2 minor issues with machine 2:
> 
> 1. After the "Welcome to GRUB" text the 3.5" floppy drive
> was searched repeatedly before showing the grub bootmenu.
> It also took like 5-10 seconds to show the menu.
> I guess that grub is using a minimal grub.cfg which is looking
> for the actual grub.cfg based on the partition uuid or some such
> and it is also checking the floppy drive. I wonder if we can
> tweak grub.cfg on the bootmedia to not do this?

Interesting, it's probably because the eltoritio.img doesn't include a
config. I'd need to figure out what to include that would exclude
floppies but keep it working everywhere else. I'll ask around and see if
there is a generic solution, but I'd rather err on the side of
unplugging the floppy drive at this point ;)


> 2. Booting the kernel once making the selection in the menu
> takes forever (I walked away after 1 minute). But it does boot
> eventually and I just tried with a Fedora 36 nightly, thus using
> syslinux and the same happens. I believe that the USB stack of the
> BIOS on this machine simply is terribly slow and reading the
> big kernel + ramdisk files one sector at a time. So there is
> nothing we can do here. Since this also happens with syslinux
> this is not something to worry about.

I remember a bug about slow booting a while back, where someone
complained that CHS settings in parted were making their boot slow.  It
ends up grub2 uses INT13 to get the disk geometry, and uses that info
for the buffer size. So if the BIOS is reporting something small it
might take longer to boot.

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

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: adding GCC Toolset usage docs

2022-04-14 Thread Otto Urpelainen


Germano Massullo kirjoitti 13.4.2022 klo 20.08:
Hello, in my opinion we should add to Fedora Packaging Guidelines, a 
paragraph concerning GCC Toolset usage.


I recently experienced some problems in building darktable for 
epel8/epel8-next due bad configuration of gcc-toolset-11 in the spec 
file. In a few words, gcc-toolset-11 was not really enabled, so the 
builder was still using GCC 8.5.


Since this is about EPEL only, the right place to update would be EPEL 
docs [1].


[1]: https://docs.fedoraproject.org/en-US/epel/
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?


On 14.4.2022 18:29, Peter Boy wrote:



Maybe "legacy BIOS on physical hardware" is on its way out, but it
doesn't seem that it is true across the board in VM environments.

That’s maybe true for desktops, but in the server world any server needs to be 
able to do bios boot, because of the data center requirements.



Interesting I would assume that those data center requirements would 
make it a requirement for example to be using uefi's native http 
protocol to address the shortcomings of traditional (i)pxe, so which 
data center requirement are those and where can I find documentation 
about them?



JBG

___
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: grub2 BIOS booting iso and code

2022-04-14 Thread John Reiser


https://bcl.fedorapeople.org/boot-grub2-f36.iso


I installed successfully using physical CD-R and physical DVD+R
on American Megatrends Inc version 1613 BIOS of 12/03/2008
running on Intel Core2 Duo (E8400, 3GHz, 8GB).  The USB reade
was LG Slim Portable DVD Writer GP50NB40 (August 2014).
The media check took 5 minutes on CD and 2.5 minutes on DVD.
On the installed system, "dd if=/dev/sr0 bs=32k of=/dev/null"
was 48 seconds faster than the media check for CD,
and 24 seconds faster than the media check for DVD.
___
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: F36 Final blocker status summary

2022-04-14 Thread Ben Cotton

We are currently targeting the target date #1 (2022-04-26), which
means we'd want to have blockers fixed by 18 April in order to provide
time for validation testing prior to the Go/No-go meeting on 21 April.

Action summary


Accepted blockers
-

1. kf5-kirigami2 — The About button sends Discover into loop and the
application stops responding. — VERIFIED
ACTION: none

2. anaconda — "Installing software" and other strings displayed during
installation are untranslated — VERIFIED
ACTION: Matainers to package upstream patch

3. gnome-initial-setup — gnome-initial-setup hangs when I try to setup
a google/microsoft online account — ASSIGNED
ACTION: selinux-policy maintainers to package upstream PR

4. openssl — [tr_TR] curl: (35) error:0372:digital envelope
routines::decode error with LANG=tr_TR.utf8 — NEW
ACTION: Maintainers to package upstream PR

5. container-selinux — selinux-policy is preventing flatpak from
updating / installing / removing flatpaks — NEW
ACTION: Maintainers to rebuild against updated selinux-policy packages

6. gnome-control-center — online accounts: can't disable sync on items — NEW
ACTION: Upstream to diagnose and fix issue

7. gnome-shell — interrupted dimming partly locks window switching — POST
ACTION: Maintainers to package upstream PR

8. fedora-repos — disable updates-testing, create a final release — VERIFIED
ACTION: none

9. gnome-software — Enabling "Fedora Flathub Selection" repo doesn't
show included apps in gnome-software until re-login — NEW
ACTION: Maintainers to package upstream MR

10. selinux-policy — After upgrade to F36 several packages fail to
update due to selinux-related errors — ASSIGNED
ACTION: container-selinux, osbuild, snapd, flatpak maintainers to
rebuild against latest selinux-policy

11. spin-kickstarts —
pyanaconda.modules.common.errors.installation.StorageInstallationError:
device is active — NEW
ACTION: KDE SIG to disable automount of storage devices in live image

Proposed blockers
-

1. xorg-x11-server — Basic graphics mode broken for X11 with Nvidia
GPU and UEFI — NEW
ACTION: QA to verify upstream MR

Bug-by-bug detail
=

Accepted blockers
-

1. kf5-kirigami2 — https://bugzilla.redhat.com/show_bug.cgi?id=2057563
— VERIFIED
The About button sends Discover into loop and the application stops responding.

Clicking the About button causes a loop which renders Discover
unresponsive (except when the window is maximized). Fix verified in
FEDORA-2022-120719a555.

2. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=2071098 — VERIFIED
"Installing software" and other strings displayed during installation
are untranslated

Available translations are not displayed because LC_ALL was set in the
environment of DBus modules, overriding the value in LANG.
FEDORA-2022-92570f3943 contains a verified fix.

3. gnome-initial-setup —
https://bugzilla.redhat.com/show_bug.cgi?id=2071259 — ASSIGNED
gnome-initial-setup hangs when I try to setup a google/microsoft online account

Setting up a Google or Microsoft account causes g-i-s to apparently
hang, although tty switching works. This appears to be an SELinux
policy issue. https://github.com/fedora-selinux/selinux-policy/pull/1151
contains a candidate fix.

4. openssl — https://bugzilla.redhat.com/show_bug.cgi?id=2071343 — POST
[tr_TR] curl: (35) error:0372:digital envelope routines::decode
error with LANG=tr_TR.utf8

curl coredumps when using the Turkish locale because of a string
comparison in OpenSSL that can't handle some unique character case
features in the Turkish alphabet. Upstream has a PR with a candidate
fix: https://github.com/openssl/openssl/pull/18069

5. container-selinux —
https://bugzilla.redhat.com/show_bug.cgi?id=2070764 — ON_QA
selinux-policy is preventing flatpak from updating / installing /
removing flatpaks

SELinux prevents flatpak from accessing a variety of
files/directories, including `/etc/passwd` and
`/var/lib/flatpak/exports/share`. This, in turn, prevents flatpak from
modifying flatpaks on the system. FEDORA-2022-ee2ba7ba12 contained a
fix for F36. container-selinux will need to be rebuilt against
selinux-policy-35.17-1.fc35 and selinux-policy-35.27-1.fc34 for
supported releases.

6. gnome-control-center —
https://bugzilla.redhat.com/show_bug.cgi?id=2068470 — NEW
online accounts: can't disable sync on items

Attempting to disable sync on items in Online Accounts appears to
succeed, but sync still shows as enabled on re-launch. Reported
upstream as https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1721

7. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=2073206 — POST
interrupted dimming partly locks window switching

Typing or using the mouse while the screen begins blanking results in
the screen being unresponsive to mouse input. Keyboard input still
works. Upstream PR for mutter contains a candidate fix:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2333

8. fedora-repos

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?


On 14.4.2022 18:20, Chris Adams wrote:

Once upon a time, Robbie Harwood  said:

Given there is consensus that legacy BIOS is on its way out

I don't think this statement is true, unless Fedora doesn't want to be
considered for a bunch of popular VM hosts (e.g. Linode and such) that
have no stated plans to support UEFI.

Maybe "legacy BIOS on physical hardware" is on its way out



It's not an maybe, it is on it's way out either physically or simply via 
firmware update [1]


"In the bios, upgraded to 810 the option to enable legacy boot is greyed 
out"


So how do people propose the situation to be handled when firmware from 
vendors, disables the legacy boot option via firmware update.


Is Fedora supposed to block/blacklist those firmware updates via some 
plugin in lvfs based on user feedback when their legacy boot mode 
suddenly stops working or is it expected that upstream lvfs team looks 
into this or what?



JBG

1. 
https://forum-en.msi.com/index.php?threads/msi-pro-dp20z-5m-legacy-boot-how-to-enable-legacy-boot.374479/

___
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: grub2 BIOS booting iso and code

2022-04-14 Thread Brian C. Lane

FWIW I've now added a commit that makes the same changes for
livemedia-creator created isos and tested it with QEMU.

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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?


On 14.4.2022 16:38, Ben Beasley wrote:

I’m not talking about refurbished parts or new old stock. I’m talking about the 
brand-new SATA HDDs and SSDs, ATX power supplies, case fans, and other 
components that are backwards-compatible in systems pushing twenty years old 
(SATA) or older (PSUs, fans). Maybe I misunderstand, but your argument seems to 
be based on the idea that all replacement parts are custom designs tied to OEM 
support policies rather than commodities based on long-lived standards.


I'm talking about the entire hw range in the computer, every single 
component which can break not just the nuts and bolts on the computer 
case, or the PSU fans etc. ( It's interesting how you always avoid 
mentioning motherboard/GPU failures etc ).


As much as people may dislike it, the fact is those long lived standards 
have been replaced with a newer standards and not all replacement parts 
are backwards compatible like for example for a video device to work on 
a motherboard with a legacy BIOS, or in CSM mode, it needs a VGA option 
ROM to initialize the card.


Most video cards/IGPs for the last few years have dropped legacy BIOS 
support and only have UEFI ROMs ( which means they wont work on legacy 
bios or in CSM mode ) so we already are in an era when people are buying 
replacement parts which either needs to be old enough or legacy-friendly 
enough to work on that legacy hardware and as much as I dislike it, 
entering an era of vendor locked replacement parts ( Like AMD epyc CPU's 
getting locked to computer vendors. AMD epyc CPU's from Dell HW wont 
work on Lenovo HW and visa versa even if those are the exact same CPU 
models etc. )


Trying to support that legacy scenario where certain hw may or may not 
work is a nightmare for developers, support teams and Fedora since 
Fedora is not a distribution with a long term support, LTS distributions 
are better suited to support legacy hw then Fedora ever will.



JBG
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Matthew Miller

On Thu, Apr 14, 2022 at 12:18:12PM +, JadoNena via devel wrote:
> All of this discussion waves a red flag at us.
[...]
> But only a few people are talking about the real costs to users.

Please don't read too much into everything you see in big mailing list
threads like this, especially as you go into the their deep depths. We
absolutely do care about these things!


-- 
Matthew Miller

Fedora Project Leader
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Justin Forbes

On Thu, Apr 14, 2022 at 6:39 AM Kevin Kofler via devel
 wrote:
>
> Ralf Corsépius wrote:
> > I do not agree with this statement.  Like previous "Legacy SIGs" this is
> > a red herring to obfuscate RHATs lack of disinterest with topics, which
> > do not match into their business objectives.
>
> I am also worried that this is just a delayed retirement, as it was for 32-
> bit i686, where the SIG was very quickly declared a failure, without even
> being given time to organize.

The i686 SIG was given multiple releases to organize. The original
proposal which triggered the SIG to form was for F27, the proposal to
finally kill it and declare the SIG inactive was F31.  But this is
different from the i686 kernel SIG in some critical ways.  First, the
rate of churn around the boot code is massively smaller than the churn
in kernel code. Second, it seemed that most of the people who showed
interest in the i686 SIG had little to no kernel experience, while
Hans and others interested should be capable of doing the work as long
as they are willing.  And lastly, many of the i686 issues which popped
up were issues which kept the kernel from building, so there was more
urgency around them.  While I don't have plans to participate in the
BIOS boot SIG, I do think it is in capable hands provided the people
who have commented interest in participating continue to do so.

Justin

> Still, it is better than retiring it immediately. But like you, I am worried
> that this is not really a long-term commitment and that people will be
> attempting to kill BIOS support again at even the smallest dent in SIG
> activity.
>
> Kevin Kofler
> ___
> 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
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On Thu, Apr 14, 2022 at 2:29 PM Peter Boy  wrote:
>
>
>
> > Am 14.04.2022 um 20:20 schrieb Chris Adams :
> >
> > Once upon a time, Robbie Harwood  said:
> >> Given there is consensus that legacy BIOS is on its way out
> >
> > I don't think this statement is true, unless Fedora doesn't want to be
> > considered for a bunch of popular VM hosts (e.g. Linode and such) that
> > have no stated plans to support UEFI.
>
> 1++
>
>
> > Maybe "legacy BIOS on physical hardware" is on its way out, but it
> > doesn't seem that it is true across the board in VM environments.
>
> That’s maybe true for desktops, but in the server world any server needs to 
> be able to do bios boot, because of the data center requirements.
>

This is not completely true for servers either. Proprietary BMCs like
iDRAC and iLO both have transitioned to UEFI in the past few years. At
least the first one I got my hands on that didn't mark EFI support as
experimental (and worked properly) was in 2016. Supermicro IPMI has
supported UEFI boot on most servers since about 2018, so it's
certainly in place in a number of places. The Redfish standard became
supported in EDK2 in 2019 as well.

Server adoption is definitely *much* slower than desktop adoption
because servers are much more expensive to deal with and replace. Not
to mention, Microsoft just didn't bother making it matter for Windows
Server certification until last year (even though Windows is a small
part of the market relative to Linux).

The tooling is there, it's just going to take the next decade to catch
up to desktops.

--
真実はいつも一つ！/ 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: grub2 BIOS booting iso and code

Hi Brian,

On 4/14/22 01:52, Brian C. Lane wrote:
> A huge thanks to Thomas Schmitt for posting xorrisofs arguments :)
> 
> Here is a lorax PR switching to grub2 for BIOS and changing the layout
> of the iso as described in his post:
> 
> https://github.com/weldr/lorax/pull/1226
> 
> And a Fedora 36 iso:
> 
> https://bcl.fedorapeople.org/boot-grub2-f36.iso
> 
> I've tested this with:
> 
> - qemu bios -cdrom
> - qemu uefi -cdrom
> - qemu bios -hda
> - qemu uefi -hda
> - USB stick on uefi PC hardware with SB off
> - USB stick on UEFI PC hardware with SB on
> - USB stick on Apple hardware UEFI
>   2010 Macbook Air and 2012 Macbook Pro
> - Media test works on all of the above
> 
> I have not tested it on CD or DVD physical media. I have a stack of
> blank discs but apparently have unplugged all my drives to use their
> SATA ports for SSDs :)

Thank you so much for working on this.

I've dd-ed the boot-grub2-f36.iso to an USB stick and successfully
tested it on the following machines:

1. Siemens PC with an i5-2400 with 8G RAM
2. Fujitsu-Siemens PC with a Core 2 Duo E6600 2.4 Ghz dual core with 4G RAM
3. Dell Latitude E6400 (core 2 duo) with 4G RAM
4. Acer One AO532 netbook with a N450 + 2G RAM

The image booted fine on all 4 machines, so from a machine
compatibility pov this looks good to me.

There were 2 minor issues with machine 2:

1. After the "Welcome to GRUB" text the 3.5" floppy drive
was searched repeatedly before showing the grub bootmenu.
It also took like 5-10 seconds to show the menu.
I guess that grub is using a minimal grub.cfg which is looking
for the actual grub.cfg based on the partition uuid or some such
and it is also checking the floppy drive. I wonder if we can
tweak grub.cfg on the bootmedia to not do this?

2. Booting the kernel once making the selection in the menu
takes forever (I walked away after 1 minute). But it does boot
eventually and I just tried with a Fedora 36 nightly, thus using
syslinux and the same happens. I believe that the USB stack of the
BIOS on this machine simply is terribly slow and reading the
big kernel + ramdisk files one sector at a time. So there is
nothing we can do here. Since this also happens with syslinux
this is not something to worry about.

Regards,

Hans
___
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 2074594] perl-Math-BigRat-0.2621 is available

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-4e37a8c4f8 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-4e37a8c4f8`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-4e37a8c4f8

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=2074594
___
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 2075210] perl-Math-BigRat-0.2622 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-4e37a8c4f8 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-4e37a8c4f8`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-4e37a8c4f8

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=2075210
___
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 2071593] Upgrade perl-Net-OpenSSH to 0.82

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-4be2e4101d 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-4be2e4101d`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-4be2e4101d

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=2071593
___
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 2074633] perl-bignum-0.65 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-45dfbb843a 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-45dfbb843a`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-45dfbb843a

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=2074633
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

That’s a step into the right direction, but needs some corrections:

> Am 14.04.2022 um 20:02 schrieb Robbie Harwood :
> 
> 
> The overall goal of the SIG needs to be to reduce load on existing
> bootloader contributors.  If it is not doing this, it needs to be
> dissolved.

The first overall goal is to maintain bios boot and by doing this to expand the 
existing boot loader contributors.
> 
> ## SIG package maintenance
> 
> If the SIG wants to maintain any BIOS-only packages, that's up to them.
> Assuming Brian's change to use grub2 instead of syslinux on legacy
> install media ( https://github.com/weldr/lorax/pull/1226 ), the only
> other packages in question here would be those to support VESA/fbdev:
> 
> - xorg-x11-drv-vesa
> - xorg-x11-drv-fbdev
> - xorg-x11-server-Xorg

Somewhere else I read these are going to vanish because nothing is still using 
it?

> - syslinux
> 
> ## Fedora deliverables
> 
> Given there is consensus that legacy BIOS is on its way out, we think
> Fedora release criteria in this area should be re-evaluated.  Not only
> does support change from "fully supported" to "best effort", but we
> should re-evaluate what is/isn't release blocking, and probably clarify
> who owns what parts.

The goal is not to touch or modify the release criteria and blocking issues


> 
> ## grub2
> 
> By default, the Legacy SIG is expected to perform contributions in the
> form of triage and PRs.  Normal “upstream first” rules apply here (i.e.,
> send it wherever possible, otherwise send to the downstream rhboot
> repo).
> 
> Current grub2 maintainers consider splitting the package (probably grub2
> and grub2-pc, to match current naming, or grub2-legacy or something)
> undesirable for a number of reasons.  A nonexhaustive list of what would
> need to be satisfactorily resolved before a split could considered:
> 
> - There needs to be a primary (and probably secondary) package owner
>  from the SIG as a prerequisite for a new bugzilla component.
> 
> - Everything in grub2-common, grub2-tools, and grub2-tools-extra is
>  available on both UEFI and legacy.  In most cases, the content is in
>  fact shared: one file works on both.
> 
> - The new grub2-bios is secondary to the main grub2 package, which means
>  that the Legacy SIG is responsible for not conflicting with any grub2
>  subpackage, and nothing in grub2 can depend on anything in the legacy
>  package.

Both groups cooperate in a way that best fits the goal to keep Fedora able to 
boot from any of the supported media (for a probably limited time, e.g. 5 years)


> 
> - More generally, problems with the shared core can and will manifest
>  primarily on one platform.  

The maintainer of that platform lead the problem solving.


> - Feature incompatibilities can and will occur.  (Maybe this is okay, or
>  just the Legacy SIG's responsibility to sort out in all cases.)

Feature incompatibilities will get resolved by the lead of the  part that is 
affected most with support from each other.

It is the common responsibility to resolve issues. Responsibility ping-pong 
needs to be avoided. 

> - Current maintainers do not have much capacity for mentoring, and since
>  the point is to be rid of legacy, we can't help much at all with
>  bugfixes.

In the initial phase, the "Bios-Boot-Maintainers" receive a detailed briefing 
to ensure their working preconditions.

___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

Hi Robbie,

On 4/14/22 20:02, Robbie Harwood wrote:
> Hans de Goede  writes:
> 
>> What I envision for the SIG is:
>>
>> 1. I'm not sure if it is possible to setup group ownership
>> of pkgs in pagure? So to keep things simple the few packages which
>> are only necessary for BIOS boot can be handed over to me and then
>> I'll just add other people willing to help out as co-maintainers.
> 
> As I've mentioned multiple times elsewhere, this isn't about packages,
> and I don't think it's helpful to think in terms of them.
> 
>> And I would also like to have a discussion about splitting
>> the BIOS boot grub bits out into a separate src.rpm
>> (using the same Source0 as the main grub) so that this can
>> be build by the SIG without needing help from the bootloader
>> team (the main grub package can only be built by a few people
>> because of secureboot signing). The idea is to avoiding
>> bottlenecking on the bootloader team when some BIOS boot bugs
>> in grub need to be fixed, quoting from my original email about
>> this:
> 
> Trying to avoid re-hashing our lengthy off-list conversation, here are
> some thoughts (mine and other interested parties's):
> 
> At minimum, we need a Legacy BIOS SIG to provide:
> 
> - a "place" to assign bugs (e.g., email address)
> - a means to fix issues
> 
> By default, we understand the former to be the SIG's email address, and
> the latter to be PRs to dist-git of relevant packages.
> 
> The overall goal of the SIG needs to be to reduce load on existing
> bootloader contributors.

Ack I agree that bugzilla triage of BIOS boot bugs +
fixing them once identified needs to be the main focus
of the SIG.

That and regularly testing N + 1 boot media BIOS booting
to catch any regressions early on.

> If it is not doing this, it needs to be
> dissolved.
> 
> ## SIG package maintenance
> 
> If the SIG wants to maintain any BIOS-only packages, that's up to them.
> Assuming Brian's change to use grub2 instead of syslinux on legacy
> install media ( https://github.com/weldr/lorax/pull/1226 ), the only
> other packages in question here would be those to support VESA/fbdev:
> 
> - xorg-x11-drv-vesa
> - xorg-x11-drv-fbdev
> - xorg-x11-server-Xorg

I personally do not believe that it will be necessary to keep
maintaining VESA support, I agree that without legacy BIOS
support it definitely is not needed though. I believe that ajax
has submitted a separate change proposal for this, so this is
best discussed there.

> - syslinux

As you say it looks like this one may no longer be necessary and
otherwise the SIG can pick it up.

> ## Fedora deliverables
> 
> Given there is consensus that legacy BIOS is on its way out, we think
> Fedora release criteria in this area should be re-evaluated.  Not only
> does support change from "fully supported" to "best effort", but we
> should re-evaluate what is/isn't release blocking, and probably clarify
> who owns what parts.

Given what the server product folks have indicated that BIOS
boot support is quite important for them I'm not sure if changing the
release criteria is in order. I do agree that any blocker bugs related
to legacy BIOS booting should be assigned to; and taken care of by
the legacy BIOS boot SIG.

> ## grub2
> 
> By default, the Legacy SIG is expected to perform contributions in the
> form of triage and PRs.  Normal “upstream first” rules apply here (i.e.,
> send it wherever possible, otherwise send to the downstream rhboot
> repo).
> 
> Current grub2 maintainers consider splitting the package (probably grub2
> and grub2-pc, to match current naming, or grub2-legacy or something)
> undesirable for a number of reasons.  A nonexhaustive list of what would
> need to be satisfactorily resolved before a split could considered:
> 
> - There needs to be a primary (and probably secondary) package owner
>   from the SIG as a prerequisite for a new bugzilla component.
> 
> - Everything in grub2-common, grub2-tools, and grub2-tools-extra is
>   available on both UEFI and legacy.  In most cases, the content is in
>   fact shared: one file works on both.
> 
> - The new grub2-bios is secondary to the main grub2 package, which means
>   that the Legacy SIG is responsible for not conflicting with any grub2
>   subpackage, and nothing in grub2 can depend on anything in the legacy
>   package.
> 
> - More generally, problems with the shared core can and will manifest
>   primarily on one platform.  Bugzilla ping-pong needs to not be played.
> 
> - Feature incompatibilities can and will occur.  (Maybe this is okay, or
>   just the Legacy SIG's responsibility to sort out in all cases.)
> 
> - Current maintainers do not have much capacity for mentoring, and since
>   the point is to be rid of legacy, we can't help much at all with
>   bugfixes.

Ok, if you prefer going through PR-s then lets give that a try,
I'm a bit worried that always needing to go through the bootloader team
may get in the way of expedient fixing of BIOS related bugs and that
this may cause

Re: F38 Change: Major upgrade of Microdnf (Self-Contained Change proposal)

2022-04-14 Thread Chris Snyder

For dnf plugin writers, what will the migration path look like to switch
over to be compatible with microdnf?

On Thu, Apr 14, 2022 at 8:05 AM Neal Gompa  wrote:

> On Thu, Apr 14, 2022 at 7:40 AM Kevin Kofler via devel
>  wrote:
> >
> > Gordon Messmer wrote:
> > > I've gotta ask... How much memory does the new dnf daemon take while
> idle?
> >
> > As I understand it, the new DNF daemon would mostly only replace/upgrade
> the
> > already existing dnfdaemon, for users of tools like Dnfdragora. It would
> not
> > be required otherwise, or would it?
> >
>
> Yes. Applications need to directly use the dnfdaemon API to use the
> dnfdaemon.
>
>
>
> --
> 真実はいつも一つ！/ 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
>


-- 

Christopher Snyder, RHCSA

he, him, his

Associate Manager, Software Engineering

Red Hat 

IRC: csnyder

___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?



> Am 14.04.2022 um 20:20 schrieb Chris Adams :
> 
> Once upon a time, Robbie Harwood  said:
>> Given there is consensus that legacy BIOS is on its way out
> 
> I don't think this statement is true, unless Fedora doesn't want to be
> considered for a bunch of popular VM hosts (e.g. Linode and such) that
> have no stated plans to support UEFI.

1++


> Maybe "legacy BIOS on physical hardware" is on its way out, but it
> doesn't seem that it is true across the board in VM environments.

That’s maybe true for desktops, but in the server world any server needs to be 
able to do bios boot, because of the data center requirements.


___
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 2062562] [RFE: EPEL9] EPEL9 branch for perl-Proc-ProcessTable

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



--- Comment #2 from Pat Riehecky  ---
Can perl-Proc-ProcessTable be branched for EPEL9?


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2062562
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Chris Adams

Once upon a time, Robbie Harwood  said:
> Given there is consensus that legacy BIOS is on its way out

I don't think this statement is true, unless Fedora doesn't want to be
considered for a bunch of popular VM hosts (e.g. Linode and such) that
have no stated plans to support UEFI.

Maybe "legacy BIOS on physical hardware" is on its way out, but it
doesn't seem that it is true across the board in VM environments.
-- 
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

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Robbie Harwood

Hans de Goede  writes:

> What I envision for the SIG is:
>
> 1. I'm not sure if it is possible to setup group ownership
> of pkgs in pagure? So to keep things simple the few packages which
> are only necessary for BIOS boot can be handed over to me and then
> I'll just add other people willing to help out as co-maintainers.

As I've mentioned multiple times elsewhere, this isn't about packages,
and I don't think it's helpful to think in terms of them.

> And I would also like to have a discussion about splitting
> the BIOS boot grub bits out into a separate src.rpm
> (using the same Source0 as the main grub) so that this can
> be build by the SIG without needing help from the bootloader
> team (the main grub package can only be built by a few people
> because of secureboot signing). The idea is to avoiding
> bottlenecking on the bootloader team when some BIOS boot bugs
> in grub need to be fixed, quoting from my original email about
> this:

Trying to avoid re-hashing our lengthy off-list conversation, here are
some thoughts (mine and other interested parties's):

At minimum, we need a Legacy BIOS SIG to provide:

- a "place" to assign bugs (e.g., email address)
- a means to fix issues

By default, we understand the former to be the SIG's email address, and
the latter to be PRs to dist-git of relevant packages.

The overall goal of the SIG needs to be to reduce load on existing
bootloader contributors.  If it is not doing this, it needs to be
dissolved.

## SIG package maintenance

If the SIG wants to maintain any BIOS-only packages, that's up to them.
Assuming Brian's change to use grub2 instead of syslinux on legacy
install media ( https://github.com/weldr/lorax/pull/1226 ), the only
other packages in question here would be those to support VESA/fbdev:

- xorg-x11-drv-vesa
- xorg-x11-drv-fbdev
- xorg-x11-server-Xorg
- syslinux

## Fedora deliverables

Given there is consensus that legacy BIOS is on its way out, we think
Fedora release criteria in this area should be re-evaluated.  Not only
does support change from "fully supported" to "best effort", but we
should re-evaluate what is/isn't release blocking, and probably clarify
who owns what parts.

## grub2

By default, the Legacy SIG is expected to perform contributions in the
form of triage and PRs.  Normal “upstream first” rules apply here (i.e.,
send it wherever possible, otherwise send to the downstream rhboot
repo).

Current grub2 maintainers consider splitting the package (probably grub2
and grub2-pc, to match current naming, or grub2-legacy or something)
undesirable for a number of reasons.  A nonexhaustive list of what would
need to be satisfactorily resolved before a split could considered:

- There needs to be a primary (and probably secondary) package owner
  from the SIG as a prerequisite for a new bugzilla component.

- Everything in grub2-common, grub2-tools, and grub2-tools-extra is
  available on both UEFI and legacy.  In most cases, the content is in
  fact shared: one file works on both.

- The new grub2-bios is secondary to the main grub2 package, which means
  that the Legacy SIG is responsible for not conflicting with any grub2
  subpackage, and nothing in grub2 can depend on anything in the legacy
  package.

- More generally, problems with the shared core can and will manifest
  primarily on one platform.  Bugzilla ping-pong needs to not be played.

- Feature incompatibilities can and will occur.  (Maybe this is okay, or
  just the Legacy SIG's responsibility to sort out in all cases.)

- Current maintainers do not have much capacity for mentoring, and since
  the point is to be rid of legacy, we can't help much at all with
  bugfixes.

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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Gary Buhrmaster

On Thu, Apr 14, 2022 at 2:08 PM Vitaly Zaitsev via devel
 wrote:
>
> On 14/04/2022 15:31, John Reiser wrote:
> > Some of them even have "without data loss" in the page title.
>
> Without moving data to another physical drive this operation is too
> dangerous.
>
> I tried on my testing VM and lost all data from that VM. Restored snapshot.

There are certainly cases where this can happen
given the power of the tools that can be used.

There are also cases where it has been shown
to have worked without issue (if one follows all
the steps).

Having a backup (and testing it) before one
modifies your disk partition is certainly one of
the recommended steps.

Given that one is far more likely to report the
failures than the successes, there is no way to
draw any real conclusion about how many
failures and successes there are, and their
causes, if you are one of those that lost their
system you tend to get a strong opinion.
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?


On 14.4.2022 15:53, Peter Boy wrote:



Am 14.04.2022 um 17:33 schrieb Jóhann B. Guðmundsson :

It should be quite apparent prevent the hw support lifecycle dialog from ever 
occurring again we need a rigid planned supported hw lifecycle.


Again, the legacy BIOS discussion is not about hardware, as implied by the 
name. It is software and support and management software infrastructure.



Bios is a software that is directly tied to hw lifecycle from vendors so 
it most certainly is (in)directly related to hw support discussion in 
Fedora.


Then there is the fact that clinging to legacy bios is working against 
Fedora's own foundation "First" in which is stated "Fedora always aims 
to provide the future, first".



JBG


JBG
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Martin Jackson

It happens that way in some places but not everywhere. I believe someone 
earlier mentioned how this whole discussion is security theater - some 
companies know this to be true and have fiscal policies that reflect that.

I have direct experience working for a large organization where 3-5 years was 
more a guideline than a rule. Please be aware of that, is all I am asking here. 
7 years is common and some assets I saw in use for well over 10. Hardware 
security is a factor but by no means the overriding one.

Thanks,

> On Apr 14, 2022, at 10:47 AM, Jóhann B. Guðmundsson  
> wrote:
> 
> On 14.4.2022 14:07, Martin Jackson wrote:
>> In many industrial and retail use cases, 10 years is the low end. 3-5 years 
>> is an accounting timeline (for depreciation) not necessarily the useful life 
>> of the asset. If the asset can be used after it’s done depreciating that is 
>> a bonus for the company using it.
> 
> 
> HW security is one reason the companies are replacing their hw after 3-5 
> years and in those cases the assets being deprecated are removed from the 
> premise.
> 
> 
> JBG
> ___
> 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
___
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] Fedora EPEL 8 updates-testing report

2022-04-14 Thread updates

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-740d836cc1   
cacti-1.2.20-1.el8 cacti-spine-1.2.20-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-7aca455c41   
pdns-4.6.2-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

csdiff-2.4.0-1.el8
festival-freebsoft-utils-0.10-3.el8
lua-sec-1.1.0-1.el8
openbgpd-7.3-1.el8
packit-0.49.0-1.el8
swift-lang-5.6.1-1.el8

Details about builds:



 csdiff-2.4.0-1.el8 (FEDORA-EPEL-2022-79e55322da)
 Non-interactive tools for processing code scan results in plain-text

Update Information:

- update to latest upstream release - add support for the `SARIF` data format

ChangeLog:

* Wed Apr 13 2022 Kamil Dudka  2.4.0-1
- update to latest upstream release




 festival-freebsoft-utils-0.10-3.el8 (FEDORA-EPEL-2022-6a3a9bf070)
 Utilities that enhance Festival with some useful features

Update Information:

Install to /usr/share/festival rather than /usr/share/festival/lib

ChangeLog:

* Wed Apr 13 2022 Benjamin A. Beasley  0.10-3
- Install to /usr/share/festival (fix RHBZ#2017994)

References:

  [ 1 ] Bug #2017994 - speech-dispatcher.scm problem with festival and 
speech-dispatcher
https://bugzilla.redhat.com/show_bug.cgi?id=2017994




 lua-sec-1.1.0-1.el8 (FEDORA-EPEL-2022-862069d56f)
 Lua binding for OpenSSL library

Update Information:

# LuaSec 1.1.0* Fix missing DANE flag   * Remove unused parameter in
`https.lua`

ChangeLog:

* Thu Apr 14 2022 Robert Scheck  1.1.0-1
- Upgrade to 1.1.0 (#2075354)
* Thu Jan 20 2022 Fedora Release Engineering  - 
1.0.2-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Tue Sep 14 2021 Sahana Prasad  - 1.0.2-2
- Rebuilt with OpenSSL 3.0.0

References:

  [ 1 ] Bug #2075354 - lua-sec-1.1.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2075354




 openbgpd-7.3-1.el8 (FEDORA-EPEL-2022-cd757979fd)
 OpenBGPD Routing Daemon

Update Information:

# OpenBGPD 7.3  This release includes the following changes to the previous
release:* Macro expansion in the config file is improved. It is now possible
to expand `set large-community $myAS:$location:$transit`.   * Add initial FIB
support for Linux. Routes can be added and removed. Nexthop tracking and dynamic
interface detection are not yet implemented.   * Major refactoring in the RIB
codebase to add multipath support in an upcoming release.

ChangeLog:

* Wed Apr 13 2022 Robert Scheck  7.3-1
- Upgrade to 7.3 (#2075138)
* Thu Jan 20 2022 Fedora Release Engineering  - 7.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

References:

  [ 1 ] Bug #2075138 - openbgpd-7.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2075138




 packit-0.49.0-1.el8 (FEDORA-EPEL-2022-f681c4b4f1)
 A tool for integrating upstream projects with Fedora operating system

Update Information:

New upstream release: 0.49.0

ChangeLog:

* Wed Apr 13 2022 Packit  - 0.49.0-1
- A new configuration option `downstream_branch_name` has been added, which is 
meant to be used in source-git projects and allow users to customize the name 
of the branch in dist-git

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

2022-04-14 Thread Thomas Schmitt

Hi,

Brian C. Lane wrote:
> https://bcl.fedorapeople.org/boot-grub2-f36.iso
> [...]
> I have not tested it on CD or DVD physical media.

I can confirm that it boots to a GRUB 2.06 menu via real iron EFI from
real plastic DVD+RW.
The menu offers me to install Fedora 36. So the boot lures for EFI from
optical media continue to work after the layout change.

The medium type should not matter. Every readable optical medium is
supposed to work the same at boot time.

Regrettably my old test machine with only legacy BIOS is currently
lacking components, which serve at other places. So i cannot yet test
that boot path from DVD.
The report of Brian C. Lane that it works with "qemu bios -cdrom" gives
hope that it will work with real iron and plastic, too. Other than OVMF
SeaBIOS is not known of not distinguishing CD-ROM and HDD.

Have a nice day :)

Thomas
___
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

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
   Fixed In Version||perl-Net-Netmask-2.0001-5.e
   ||l9
 Status|ON_QA   |CLOSED
Last Closed||2022-04-14 17:08:41



--- Comment #6 from Fedora Update System  ---
FEDORA-EPEL-2022-a73255745c has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Robbie Harwood

Hans de Goede  writes:

> On 4/13/22 21:27, David Cantrell wrote:
>
>> OK, given this proposal, I'd like the original change proposal
>> amended to essentially say "transfer legacy BIOS boot support to
>> newly formed Legacy BIOS SIG" or something like that.  The logistics
>> at that point can be sorted out as the SIG sees fit.  I'd like to see
>> the original proposal advance forward and this gives a plan for the
>> legacy BIOS piece.
>
> TBH I'm not sure if that is the direction in which the proposal owner
> (Robbie) wants to go, Robbie ?

More complicated than that.  As alluded to elsewhere in the thread, a
SIG doesn't actually require a change proposal (
https://fedoraproject.org/wiki/Creating_a_Fedora_SIG ) and I'd feel
weird proposing the creation of a SIG that I'm not going to participate
in.  I don't oppose others stepping forward if they wish.

Regarding the change proposal itself, there seems to be consensus that
legacy bios booting will be going away "eventually", even if for my
purposes "eventually" means "we have this mudslinging again in x
releases".  Absent a formal date or even consensus around what
"deprecation" means, I'm not sure what purpose a revised/new proposal
would serve at this juncture.

> I've send Robbie an offlist email asking him to weigh in here.

My pronouns are they/them.

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

[EPEL-devel] Fedora EPEL 7 updates-testing report

2022-04-14 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-14d598751d   
libbson-1.3.5-7.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4a24f39c87   
blender-2.68a-9.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-10b278795b   
cacti-1.2.20-1.el7 cacti-spine-1.2.20-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

composer-1.10.26-1.el7
csdiff-2.4.0-1.el7
distgen-1.12-1.el7
lua-sec-1.1.0-1.el7
openbgpd-7.3-1.el7

Details about builds:



 composer-1.10.26-1.el7 (FEDORA-EPEL-2022-a970a526cb)
 Dependency Manager for PHP

Update Information:

**Version 1.10.26** -  2022-04-13  * Security: Fixed command injection
vulnerability in HgDriver/GitDriver (GHSA-x7cr-6qr6-2hh6 / CVE-2022-24828)  
**Version 1.10.25** - 2022-01-21* Fixed selfupdate on Windows + PHP 8.1
regression (#10446)    **Version 1.10.24** - 2021-12-09* Added v1
deprecation warning when running install. Please make sure you upgrade to
Composer 2, see https://blog.packagist.com/deprecating-composer-1-support/   *
Fixed PHP 8.1 compatibility   * Fixed some more Windows CLI parameter escaping
edge cases    **Version 1.10.23** - 2021-10-05* Security: Fixed command
injection vulnerability on Windows (GHSA-frqg-7g38-6gcf / CVE-2021-41116)

ChangeLog:

* Thu Apr 14 2022 Remi Collet  - 1.10.26-1
- update to 1.10.26




 csdiff-2.4.0-1.el7 (FEDORA-EPEL-2022-68e1cadb32)
 Non-interactive tools for processing code scan results in plain-text

Update Information:

- update to latest upstream release - add support for the `SARIF` data format

ChangeLog:

* Wed Apr 13 2022 Kamil Dudka  2.4.0-1
- update to latest upstream release




 distgen-1.12-1.el7 (FEDORA-EPEL-2022-cf99083f9c)
 Templating system/generator for distributions

Update Information:

Rebase to upstream version 1.12

ChangeLog:

* Thu Apr 14 2022 Zuzana Miklankova  - 1.12-1
- new upstream release, https://github.com/devexp-db/distgen/releases/tag/v1.12




 lua-sec-1.1.0-1.el7 (FEDORA-EPEL-2022-2bc1596aa7)
 Lua binding for OpenSSL library

Update Information:

# LuaSec 1.1.0* Fix missing DANE flag   * Remove unused parameter in
`https.lua`

ChangeLog:

* Thu Apr 14 2022 Robert Scheck  1.1.0-1
- Upgrade to 1.1.0 (#2075354)
* Thu Jan 20 2022 Fedora Release Engineering  - 
1.0.2-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Tue Sep 14 2021 Sahana Prasad  - 1.0.2-2
- Rebuilt with OpenSSL 3.0.0

References:

  [ 1 ] Bug #2075354 - lua-sec-1.1.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2075354




 openbgpd-7.3-1.el7 (FEDORA-EPEL-2022-f216f61bfd)
 OpenBGPD Routing Daemon

Update Information:

# OpenBGPD 7.3  This release includes the following changes to the previous
release:* Macro expansion in the config file is improved. It is now possible
to expand `set large-community $myAS:$location:$transit`.   * Add initial FIB
support for Linux. Routes can be added and removed. Nexthop tracking and dynamic
interface detection are not yet implemented.   * Major refactoring in the RIB
codebase to add multipath support in an upcoming release.

ChangeLog:

* Wed Apr 13 2022 Robert Scheck  7.3-1
- Upgrade to 7.3 (#2075138)
* Thu Jan 20 2022 Fedora Release Engineering  - 7.2-2
- Rebuilt for

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Ben Beasley

I’m not talking about refurbished parts or new old stock. I’m talking about the 
brand-new SATA HDDs and SSDs, ATX power supplies, case fans, and other 
components that are backwards-compatible in systems pushing twenty years old 
(SATA) or older (PSUs, fans). Maybe I misunderstand, but your argument seems to 
be based on the idea that all replacement parts are custom designs tied to OEM 
support policies rather than commodities based on long-lived standards.

It also feels like this is an argument in favor of intentionally forcing people 
to retire old hardware “for their own good” because it is too unreliable or 
hard to fix. That isn’t a goal of this Change as far as I can tell, and if you 
are in fact suggesting that removal of hardware support should be an objective 
rather than an unfortunate necessity based on limited resources, I don’t think 
you’ll find much community support for that position.

On Thu, Apr 14, 2022, at 11:33 AM, Jóhann B. Guðmundsson wrote:
> On 14.4.2022 13:09, Ben Beasley wrote:
>> For desktop-class hardware, the parts that are most likely to fail around 
>> the decade mark are storage drives, power supplies, and perhaps fans. All of 
>> these are fully standardized and in plentiful supply; there is no reason 
>> that first-party hardware vendor support should be required to keep old 
>> desktop systems in service. 
>
>
> We need to actually see some real hard data involving those fail parts 
> from the manufactures themselves and or official repair shops since 
> there are plethora of "refurbished" hw out there ranging from "cosmetic 
> imperfections" to outright "motherboard replacements".  I've experience 
> and seen plethora of spectacular computer failures as part of my dayjob 
> and in my own hw.
>
>
>
>> 
>> Dropping support for old hardware in Fedora should always be based on the 
>> costs and benefits, not on a rigid planned lifecycle. 
>
>
> Well here's the thing this is one of these reoccurring long threaded 
> discussion ( which means they are stuck in status quo ) that happen 
> every once in a while, back in the day it used to be Alan Cox that was 
> advocating for lifetimes support of steam powered devices, today the 
> dialog involves deprecating legacy bios. 
>
> It should be quite apparent prevent the hw support lifecycle dialog 
> from ever occurring again we need a rigid planned supported hw 
> lifecycle.
>
> That can be 10 years project wide or simply something that each WG 
> tailors for their own target audience ( shorter, longer that's for them 
> to decide since they should be doing all the work involving their 
> "products" and their maintenance ) but as I said we need a rigid 
> planned supported hw lifecycle, leaving this things are one more time 
> just means that we will have this dialog again further down the line.
>
>
>
> JBG
>
>
> ___
> 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
___
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

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-libwww-perl-6.62-1.fc3 |perl-libwww-perl-6.62-1.fc3
   |4   |4
   ||perl-libwww-perl-6.62-1.fc3
   ||5



--- Comment #9 from Fedora Update System  ---
FEDORA-2022-1bbb291854 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
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 2071865] perl-libwww-perl-6.62 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
   Fixed In Version||perl-libwww-perl-6.62-1.fc3
   ||4
 Status|ON_QA   |CLOSED
Last Closed||2022-04-14 16:06:48



--- Comment #8 from Fedora Update System  ---
FEDORA-2022-e63545a43c has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?



> Am 14.04.2022 um 17:33 schrieb Jóhann B. Guðmundsson :
> 
> It should be quite apparent prevent the hw support lifecycle dialog from ever 
> occurring again we need a rigid planned supported hw lifecycle.
> 

Again, the legacy BIOS discussion is not about hardware, as implied by the 
name. It is software and support and management software 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

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Vitaly Zaitsev via devel


On 14/04/2022 16:21, John Reiser wrote:
Please show what "sudo fdisk $DEVICE_NAME" says for the 'p' (print) 
command (then 'q' to quit),

both before and after the attempted conversion.


I no longer have legacy BIOS configurations. VMs have been reinstalled 
from scratch after trying to convert them.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?


On 14.4.2022 14:07, Martin Jackson wrote:

In many industrial and retail use cases, 10 years is the low end. 3-5 years is 
an accounting timeline (for depreciation) not necessarily the useful life of 
the asset. If the asset can be used after it’s done depreciating that is a 
bonus for the company using it.



HW security is one reason the companies are replacing their hw after 3-5 
years and in those cases the assets being deprecated are removed from 
the premise.



JBG
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?


On 14.4.2022 13:09, Ben Beasley wrote:
For desktop-class hardware, the parts that are most likely to fail 
around the decade mark are storage drives, power supplies, and perhaps 
fans. All of these are fully standardized and in plentiful supply; 
there is no reason that first-party hardware vendor support should be 
required to keep old desktop systems in service.



We need to actually see some real hard data involving those fail parts 
from the manufactures themselves and or official repair shops since 
there are plethora of "refurbished" hw out there ranging from "cosmetic 
imperfections" to outright "motherboard replacements".  I've experience 
and seen plethora of spectacular computer failures as part of my dayjob 
and in my own hw.





Dropping support for old hardware in Fedora should always be based on 
the costs and benefits, not on a rigid planned lifecycle.



Well here's the thing this is one of these reoccurring long threaded 
discussion ( which means they are stuck in status quo ) that happen 
every once in a while, back in the day it used to be Alan Cox that was 
advocating for lifetimes support of steam powered devices, today the 
dialog involves deprecating legacy bios.


It should be quite apparent prevent the hw support lifecycle dialog from 
ever occurring again we need a rigid planned supported hw lifecycle.


That can be 10 years project wide or simply something that each WG 
tailors for their own target audience ( shorter, longer that's for them 
to decide since they should be doing all the work involving their 
"products" and their maintenance ) but as I said we need a rigid planned 
supported hw lifecycle, leaving this things are one more time just means 
that we will have this dialog again further down the line.



JBG

___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Fabio Valentini

On Thu, Apr 14, 2022 at 5:09 PM Hans de Goede  wrote:
>
> Hi Michel,
>
> On 4/13/22 22:29, Michel Alexandre Salim wrote:
> > On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >>
> >> 1. I'm not sure if it is possible to setup group ownership
> >> of pkgs in pagure? So to keep things simple the few packages which
> >> are only necessary for BIOS boot can be handed over to me and then
> >> I'll just add other people willing to help out as co-maintainers.
> >>
> > yup, Python, Rust, and Go SIG does this all the time
> >
> >> 2. Setup a mailinglist for this and have that in bugzilla + PR
> >> Cc for all the relevant packages.
> >>
> > The group will get emailed just like a normal maintainer, IIRC. Someone
> > will need to register that group's email in Bugzilla just like a normal
> > account
>
> Interesting, so how does this work. I just realized that to allow
> adding a list to the Cc in pagure (src.fedoraproject.org) it probably
> needs a FAS account too and then log in with that account and then
> hit the "watch" button ?

No, that's not how this usually works. The steps would be something like:

1. request a FAS dist-git group (not a fake-group user, but an actual group!)
2. request a mailing list for this group
3. create a bugzilla account, using the email address of the mailing list
4. set the bugzilla account of the FAS group to be the address of the
mailing list

This is what we did for the Rust SIG, and the - now defunct -
Stewardship SIG and Java Maintainers SIG:
https://pagure.io/fedora-infrastructure/issue/7638
https://pagure.io/fedora-infrastructure/issue/8902

Fabio
___
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 2073893] CVE-2022-22624 webkit2: use after free issue

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


--- Doc Text *updated* by RaTasha Tillery-Smith  ---
A use-after-free issue was found in WebKitGTK and WPE WebKit. This flaw allows 
a remote attacker to process maliciously crafted web content, leading to 
arbitrary code execution. 



-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073893
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

Hi,

On 4/13/22 23:11, Matthew Miller wrote:
> On Wed, Apr 13, 2022 at 12:56:11PM -0700, Kevin Fenzi wrote:
>> If that proves acceptable for change owners here that would perhaps take
>> care of the short term problem. What about longer term though? Would the
>> thought be that the BIOS sig would remain around for the forseeable
>> future maintaining BIOS boot? Or would there be some kind of roadmap to
>> retirement?
> 
> I think it would make sense for the group to be set up with with some sort
> of "retirement becomes the default if the SIG stops being active" policy. I
> mean, not as a surprise, but so the situation is clear.

That is fair, although I hope that if the SIG runs out of steam for this,
that at least it will still have enough life in it to send out a proper
notice about BIOS boot support is really going away.

Regards,

Hans
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

Hi Michel,

On 4/13/22 22:29, Michel Alexandre Salim wrote:
> On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
>> Hi,
>>
>>
>> 1. I'm not sure if it is possible to setup group ownership
>> of pkgs in pagure? So to keep things simple the few packages which
>> are only necessary for BIOS boot can be handed over to me and then
>> I'll just add other people willing to help out as co-maintainers.
>>
> yup, Python, Rust, and Go SIG does this all the time
> 
>> 2. Setup a mailinglist for this and have that in bugzilla + PR
>> Cc for all the relevant packages.
>>
> The group will get emailed just like a normal maintainer, IIRC. Someone
> will need to register that group's email in Bugzilla just like a normal
> account

Interesting, so how does this work. I just realized that to allow
adding a list to the Cc in pagure (src.fedoraproject.org) it probably
needs a FAS account too and then log in with that account and then
hit the "watch" button ?

So does this require creating a "fake" FAS account for the SIG ?

So the steps would be:

1. Request mailinglist
2. Create FAS account using mailinglist address as email 
3. Create bugzilla account using mailinglist address as email

?

All I can find on this is:
https://docs.fedoraproject.org/en-US/fesco/Policy_for_encouraging_comaintainers_of_packages/#current_solution

Which does not describe haivng actual groups at all ?

And I don't see how I can put the mailinglist in the Cc
for bugs + PRs without creating a FAS account for it ?

Regards,

Hans
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

Hi David,

On 4/13/22 21:27, David Cantrell wrote:
> On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 4/13/22 18:07, David Cantrell wrote:
>>> On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote:
 On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell
  wrote:
> The core issue still comes down to having resources to continue
> maintaining
> BIOS boot support in Fedora and so far no one has come forward to work
> on
> that.

 It's not true, although you can be forgiven for missing it in such a 
 massive
 thread. Hans proposed to start a BIOS SIG to handle this. This seems like a
 very credible proposal.
>>>
>>> Ah, yes.  I do remember the post from Hans, but thought he was more 
>>> outlining
>>> how a Legacy BIOS SIG could work and what would need to happen rather than
>>> volunteering to set one up and do that.  But I went back and reread that 
>>> post
>>> and yes, he did volunteer to do just that.
>>
>> Correct.
>>
>>> If a video call happens to discuss this feature proposal, ensure Hans can
>>> attend.
>>
>> FWIW, ATM I think everything which can be said about
>> this has been said and I'm not sure if having a video
>> call about this will add anything new.
> 
> Agreed.
> 
>> As for setting up the SIG if necessary, my plan is to
>> try to keep the SIG lite weight on the process side
>> and focus on the practical things.
>>
>> What I envision for the SIG is:
>>
>> 1. I'm not sure if it is possible to setup group ownership
>> of pkgs in pagure? So to keep things simple the few packages which
>> are only necessary for BIOS boot can be handed over to me and then
>> I'll just add other people willing to help out as co-maintainers.
>>
>> 2. Setup a mailinglist for this and have that in bugzilla + PR
>> Cc for all the relevant packages.
>>
>> 3. Have people from the SIG regularly test Fedora N and
>> Fedora N + 1 (after branching) on machines which only support
>> BIOS booting and file bugs (if any) + report the results to
>> the mailinglist.
>>
>> 4. Have people from the SIG try to regularly do bugzilla
>> triage of relevant packages.
>>
>> And I would also like to have a discussion about splitting
>> the BIOS boot grub bits out into a separate src.rpm
>> (using the same Source0 as the main grub) so that this can
>> be build by the SIG without needing help from the bootloader
>> team (the main grub package can only be built by a few people
>> because of secureboot signing). The idea is to avoiding
>> bottlenecking on the bootloader team when some BIOS boot bugs
>> in grub need to be fixed, quoting from my original email about
>> this:
>>
>> """
>> 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 builds).
>> The SIG _must_ then of course still submit pull-reqs to:
>> https://github.com/rhboot/grub2/ for any changes.
>>
>> But in case of e.g. a beta blocking BIOS only bug they
>> could solve that with a patch in the src.rpm and kickof
>> a build right away without blocking on the bootloader
>> team and thus without causing a spike in
>> work-pressure/load for the bootloader team.
>>
>> And then once the pull-req is merged (possibly
>> a revised version of it) the next build of
>> the grub2-bios src.rpm can pull in the new Source0
>> and drop its local changes (IOW grub2-bios _must_
>> not become a separate fork).
>> """
> 
> OK, given this proposal, I'd like the original change proposal amended to
> essentially say "transfer legacy BIOS boot support to newly formed Legacy BIOS
> SIG" or something like that.  The logistics at that point can be sorted out as
> the SIG sees fit.  I'd like to see the original proposal advance forward and
> this gives a plan for the legacy BIOS piece.

TBH I'm not sure if that is the direction in which the proposal owner
(Robbie) wants to go, Robbie ?

> Can you followup with the proposal owners to make that amendment?

I've send Robbie an offlist email asking him to weigh in here.

Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:

Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Ralf Corsépius




Am 14.04.22 um 13:39 schrieb Kevin Kofler via devel:

Ralf Corsépius wrote:

I do not agree with this statement.  Like previous "Legacy SIGs" this is
a red herring to obfuscate RHATs lack of disinterest with topics, which
do not match into their business objectives.


I am also worried that this is just a delayed retirement, as it was for 32-
bit i686, where the SIG was very quickly declared a failure, without even
being given time to organize.


IMO, the 32bit "retirement" never was a serious "retirement" nor a 
serious attempt "to pass it to the community", either. Some people will 
find this rude, but I perceived as a long term planned assassination!


Ralf
___
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-20220414.n.0 compose check report

2022-04-14 Thread Fedora compose checker

No missing expected images.

Failed openQA tests: 10/229 (x86_64), 16/152 (aarch64)

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

ID: 1225357 Test: x86_64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1225357
ID: 1225380 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home
URL: https://openqa.fedoraproject.org/tests/1225380
ID: 1225412 Test: x86_64 Workstation-live-iso evince
URL: https://openqa.fedoraproject.org/tests/1225412
ID: 1225421 Test: x86_64 Workstation-live-iso desktop_printing_builtin
URL: https://openqa.fedoraproject.org/tests/1225421
ID: 1225490 Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1225490
ID: 1225491 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/1225491
ID: 1225493 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/1225493
ID: 1225504 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1225504
ID: 1225525 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/1225525
ID: 1225546 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1225546
ID: 1225658 Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/1225658
ID: 1225708 Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1225708
ID: 1225721 Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1225721

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

ID: 1225407 Test: x86_64 Workstation-live-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1225407
ID: 1225442 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1225442
ID: 1225517 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1225517
ID: 1225531 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1225531
ID: 1225532 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1225532
ID: 1225534 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1225534
ID: 1225565 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1225565
ID: 1225568 Test: x86_64 Workstation-upgrade gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1225568
ID: 1225583 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1225583
ID: 1225587 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1225587
ID: 1225589 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1225589
ID: 1225653 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1225653
ID: 1225712 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1225712

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

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

ID: 1225410 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1225410
ID: 1225414 Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1225414
ID: 1225425 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1225425
ID: 1225435 Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1225435
ID: 1225452 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1225452
ID: 1225457 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1225457
ID: 1225459 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1225459
ID: 1225460 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1225460
ID: 1225466 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1225466
ID: 1225547 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1225547
ID: 1225551 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1225551
ID: 1225559 Test: x86_64 Workstation-upgrade desktop_browser

Re: gcc + llvm + annobin mess in f36-updates-testing

2022-04-14 Thread Fabio Valentini

On Thu, Apr 14, 2022 at 4:34 PM Tom Stellard  wrote:
>
> On 4/13/22 17:48, Fabio Valentini wrote:
> > On Sat, Apr 9, 2022 at 12:48 PM Fabio Valentini  
> > wrote:
> >>
> >> Hi all,
> >>
> >> Looks like there's a little bit of a mess around LLVM 14 / GCC /
> >> annobin updates brewing in f36-updates-testing.
> >>
> >> Right now, there's *two* updates in "testing" state that contain
> >> builds of annobin:
> >>
> >> - https://bodhi.fedoraproject.org/updates/FEDORA-2022-c43760a865
> >> - https://bodhi.fedoraproject.org/updates/FEDORA-2022-3dd2ddf4ab
> >
> > And, lo and behold, now there's a third update for annobin:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2022-3dd2ddf4ab
> >
> > The update for LLVM 14 was pushed to stable due to a freeze exception,
> > but the GCC+annobin update is still in "testing".
> > And now there's a new version of annobin in an additional update.
> >
> > Please, given that we're *this close* to F36 release, coordinate
> > better on updates for such "unimportant packages" as the default
> > compiler toolchain ..
> >
>
> Is there some way for Bodhi to warn about this kind of problem or a
> CI test that could be added to prevent these updates from being pushed
> to testing?  This is a common problem that happens (not just  to annobin)
> when there is an LLVM update.  Even if maintainers are aware of the update,
> it can be easy to forget that it's there especially if it sits for a while.

This is actually mostly a problem for multi-build updates that have
been created from side tags. They aren't obsoleted / superseded when a
newer build of a package is submitted to bodhi, so multiple updates
for the same package can be in-flight at the same time, which leads to
all kinds of "fun" race conditions (including the "older" build
getting composed into "stable" repositories, depending on the order in
which the updates are submitted to stable).

Fabio
___
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: gcc + llvm + annobin mess in f36-updates-testing

2022-04-14 Thread Tom Stellard


On 4/13/22 17:48, Fabio Valentini wrote:

On Sat, Apr 9, 2022 at 12:48 PM Fabio Valentini  wrote:


Hi all,

Looks like there's a little bit of a mess around LLVM 14 / GCC /
annobin updates brewing in f36-updates-testing.

Right now, there's *two* updates in "testing" state that contain
builds of annobin:

- https://bodhi.fedoraproject.org/updates/FEDORA-2022-c43760a865
- https://bodhi.fedoraproject.org/updates/FEDORA-2022-3dd2ddf4ab


And, lo and behold, now there's a third update for annobin:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-3dd2ddf4ab

The update for LLVM 14 was pushed to stable due to a freeze exception,
but the GCC+annobin update is still in "testing".
And now there's a new version of annobin in an additional update.

Please, given that we're *this close* to F36 release, coordinate
better on updates for such "unimportant packages" as the default
compiler toolchain ..



Is there some way for Bodhi to warn about this kind of problem or a
CI test that could be added to prevent these updates from being pushed
to testing?  This is a common problem that happens (not just  to annobin)
when there is an LLVM update.  Even if maintainers are aware of the update,
it can be easy to forget that it's there especially if it sits for a while.

-Tom


Fabio
___
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

___
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] epel9-next cleanup

2022-04-14 Thread Troy Dawson

Hello All,
Because of the wonderful enthusiasm of our epel maintainers, we have many
packages (119) in epel9-next that are also in regular epel9.[1]   All of
the current epel9-next packages are equal to, or superseded by the current
epel9 packages, thus there is no need for them to be in epel9-next.

I am going to be clearing those out by untagging them from epel9-next.
This will give us a clean slate so that we can see what packages are really
in epel9-next.

Full disclosure.  I plan on doing some KDE work that will land with RHEL
9.1.  So cleaning things out now is the best time.

Troy

[1] - This is because we started on epel9-next and then shifted to just
epel9.
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread John Reiser


On 4/14/22 07:07, Vitaly Zaitsev via devel wrote:

On 14/04/2022 15:31, John Reiser wrote:
Some of them even have "without data loss" in the page title. 


Without moving data to another physical drive this operation is too dangerous.

I tried on my testing VM and lost all data from that VM. Restored snapshot.


Please show what "sudo fdisk $DEVICE_NAME" says for the 'p' (print) command 
(then 'q' to quit),
both before and after the attempted conversion.
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Martin Jackson

In many industrial and retail use cases, 10 years is the low end. 3-5 years is 
an accounting timeline (for depreciation) not necessarily the useful life of 
the asset. If the asset can be used after it’s done depreciating that is a 
bonus for the company using it.

Thanks,

> On Apr 14, 2022, at 7:24 AM, Jóhann B. Guðmundsson  wrote:
> 
> On 14.4.2022 11:42, Kevin Kofler via devel wrote:
>> Jóhann B. Guðmundsson wrote:
>> 
>>> For example EU has regulation that requires vendors to have spare parts
>>> available for 7–10 years after date of manufacturing so it makes sense
>>> for the project to support hw no longer than a decade from the date of
>>> it's manufacturing. ( which makes the oldest hw being support being
>>> manufactured in 2012 ) and every process,workflows and decision being
>>> bound by that.
>> Lack of availability of original spare parts does not mean that the hardware
>> suddenly magically stops working for everybody.
>> 
> No but it does mean that they cant run indefinitely
> 
> And there needs to be a number on this to adjust users expectation and 10 
> years is a reasonable number from a business, parts and recycle/re-use 
> availability,
> 
> What is unreasonable is to be expecting that it's supported indefinitely from 
> OS and or HW vendors.
> 
> JBG
> ___
> 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
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Vitaly Zaitsev via devel


On 14/04/2022 15:31, John Reiser wrote:
Some of them even have "without data loss" in the page title. 


Without moving data to another physical drive this operation is too 
dangerous.


I tried on my testing VM and lost all data from that VM. Restored snapshot.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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: gcc + llvm + annobin mess in f36-updates-testing

2022-04-14 Thread Michael Catanzaro

On Thu, Apr 14 2022 at 01:33:17 PM +0200, Kevin Kofler via devel 
 wrote:
Both these ideas would not have fixed the race condition between the 
GCC
update with one annobin rebuild and the LLVM update with another 
annobin
rebuild. We would just have had two conflicting annobin updates 
instead of

three, still one too many.

In addition, if bugs come up in the annobin plugin itself, it needs 
to be

fixed.


OK, you're right... I suppose the only way this could work is if GCC 
maintainers and LLVM maintainers both coordinate to ensure they never 
have updates pending at the same time.


Toolchain maintainers, annobin maintainers, please comment here and let 
us know what you think.


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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread John Reiser


On 4/14/22 02:01, Vitaly Zaitsev via devel wrote:

On 13/04/2022 23:11, Matthew Miller wrote:

It'd be cool to see if we can make a bios-to-uefi thing like Clover work.


I don't think it's possible because the MBR -> GPT conversion will destroy all 
partitions on the original drive.


An internet search for "convert MBR to GPT" yields many results,
including some from authoritative sources including Microsoft and Dell.
Some of them even have "without data loss" in the page title.
I myself have done this at least twice in 5 years with no data loss,
using the 'gdisk' utility (man 8 gdisk) in Fedora.
The conversion is particularly easy when the MBR partitions
do not cover the first and last 1MB of the drive,
which has been a prevalent practice for many years.
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On Thu, Apr 14, 2022 at 8:58 AM JadoNena  wrote:
>
> Hello,
>
> > On Thursday, April 14th, 2022 at 8:43 AM, Neal Gompa  
> > wrote:
>
> Thank you very much for your reply.  You are one of those several people that 
> we have been reading has some good sense for users!
>
> > First: do not panic!
>
> Of course panic is a bad idea.
> I am just observing this largest ever (?), very loud public thread.
> Our response is to start planning.  It it our "anti-panic" approach and we 
> work to never kick the can too far along.
>
> > Second: This is not a foregone conclusion yet. It's merely a
>
> Yes that is a possibility too.
>
> But I do not even now see it as a choice to NOT begin to plan and act.
> Not with this discussion, even if there are some user-supporting voices.
>
> > Third: You pay for enterprise support from Red Hat, Inc. That means
> > you have the ability to inform Red Hat through your business
> > relationship of your needs.
>
> It is good advice.  Of course we are doing that too.
> They listen to be sure. The usual action if not the answer is that RedHat is 
> not Fedora. So use more RedHat.
> Of course it is many @redhat voices here, in this Fedora discussion, that 
> look like they are making these proposals.
> It is a circle of logic that we have not so much luck with.
> In our experience there is there also a disconnection too often between 
> revenue, customer requirements, and developers.  That is a different 
> discussion and, today, it does not really matter what "we" think about it, it 
> is just the way of things.
>

I've heard this before in the past too. Thankfully nowadays, it's much
easier to refute that. While it is true that RHEL is not Fedora and
they can (and sometimes do) make substantially different choices for
RHEL than Fedora did, they largely don't (especially since they've
been burned fairly recently doing that once).

With Fedora ELN providing that RHEL-ish build of Fedora Rawhide
continuously[1], the goal is to be able to take that to build the next
major version of CentOS Stream faster, which directly becomes Red Hat
Enterprise Linux[2].

With this information in hand, it's easy to see that Fedora Changes
are a good proxy for how future RHEL might evolve, and it's worth
giving feedback early about those changes to your Red Hat account
team. I certainly know of others who do that with decent success. :)

[1]: https://docs.fedoraproject.org/en-US/eln/
[2]: https://www.redhat.com/en/resources/centos-stream-datasheet




--
真実はいつも一つ！/ 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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Ben Beasley

For desktop-class hardware, the parts that are most likely to fail 
around the decade mark are storage drives, power supplies, and perhaps 
fans. All of these are fully standardized and in plentiful supply; there 
is no reason that first-party hardware vendor support should be required 
to keep old desktop systems in service.


Dropping support for old hardware in Fedora should always be based on 
the costs and benefits, not on a rigid planned lifecycle.


– Ben

On 4/14/22 08:25, Jóhann B. Guðmundsson wrote:

On 14.4.2022 11:42, Kevin Kofler via devel wrote:

Jóhann B. Guðmundsson wrote:


For example EU has regulation that requires vendors to have spare parts
available for 7–10 years after date of manufacturing so it makes sense
for the project to support hw no longer than a decade from the date of
it's manufacturing. ( which makes the oldest hw being support being
manufactured in 2012 ) and every process,workflows and decision being
bound by that.
Lack of availability of original spare parts does not mean that the 
hardware

suddenly magically stops working for everybody.


No but it does mean that they cant run indefinitely

And there needs to be a number on this to adjust users expectation and 
10 years is a reasonable number from a business, parts and 
recycle/re-use availability,


What is unreasonable is to be expecting that it's supported 
indefinitely from OS and or HW vendors.


JBG
___
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

___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread JadoNena via devel

Hello,

> On Thursday, April 14th, 2022 at 8:43 AM, Neal Gompa  
> wrote:

Thank you very much for your reply.  You are one of those several people that 
we have been reading has some good sense for users!

> First: do not panic!

Of course panic is a bad idea.
I am just observing this largest ever (?), very loud public thread.
Our response is to start planning.  It it our "anti-panic" approach and we work 
to never kick the can too far along.

> Second: This is not a foregone conclusion yet. It's merely a

Yes that is a possibility too.

But I do not even now see it as a choice to NOT begin to plan and act.
Not with this discussion, even if there are some user-supporting voices.

> Third: You pay for enterprise support from Red Hat, Inc. That means
> you have the ability to inform Red Hat through your business
> relationship of your needs.

It is good advice.  Of course we are doing that too.
They listen to be sure. The usual action if not the answer is that RedHat is 
not Fedora. So use more RedHat.
Of course it is many @redhat voices here, in this Fedora discussion, that look 
like they are making these proposals.
It is a circle of logic that we have not so much luck with.
In our experience there is there also a disconnection too often between 
revenue, customer requirements, and developers.  That is a different discussion 
and, today, it does not really matter what "we" think about it, it is just the 
way of things.

> As for anyone else looking at this thread with RHEL-tinted lenses as
> more activist RHEL customers, please direct your feedback to your
> account managers.

We cross fingers that like you advise maybe those voices that pay the bills 
will have some effect.

Jado
___
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 compose report: 20220414.n.0 changes

2022-04-14 Thread Fedora Rawhide Report

OLD: Fedora-36-20220413.n.0
NEW: Fedora-36-20220414.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

Size change of upgraded packages:   0 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-36-20220413.n.0.aarch64.raw.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

On Thu, Apr 14, 2022 at 8:18 AM JadoNena via devel
 wrote:
>
> > The question is: how many users do we want to leave behind? Or: how many 
> > users must we leave behind because we can’t do the job.
>
> We are just users.  Our expert development is for other professions than 
> writing drivers and operating systems.
>
> My company has about 200 Fedora user PCs around the world.
> Plus about 20 servers in real hardware and 30-50 in virtual.
> More are in RedHat too but I am not talking about those here.
>
> We had decided on the RH+Centos+Fedora Eco system.
>
> All desktops and some laptops (that equals about 170) use NVidia graphics.  
> In every case we use the NVidia drivers.  They are built with the DKIM 
> software.  It is not convenient but it is worth the effort.  We can rely on 
> the NVidia software to work all the time. And we have access to the CUDA code 
> and so on.
>
> For the servers plus the user PCs about 60% are on BIOS boot not UEFI.  May 
> be half of those are BIOS only.
>
> My company has a budget.  We do the planning for 2-3 years.
> It pays for developers salarys.  And for new hardware.  And for VPS rental 
> costs.  And for user training.
> And for our Enterprise support products and services like RedHat.
>
> Unplanned and unexpected changes cost to my company a very large amount.
> We always plan our strategy to control and best minimize that cost.
> We must operate successfully for to pay those salarys and to purchase that 
> hardware and services.
>
> All of this discussion waves a red flag at us.
> We think we hear that Fedora has philosophy arguments about opensource and 
> propietary and BIOS and UEFI.
> We read the crazy mathematics about numbers of users based on I don't know 
> what.
>
> But only a few people are talking about the real costs to users.
>
> Okay, the developers here are interested only in what makes the life easier 
> for them.
> And want to not have "3rd party vendors now dictate" decisions.
> I can understand that theory too.
>
> But for here we deal with the real world where budgets require plans and 
> hardware exists for years.
> With this decision making the red flag means that "today & now" we must start 
> with planning for alternatives to the RH+Centos+Fedora Eco system.
>
> We did not expect this from the RH+Centos+Fedora Eco system.
> That maybe is our mistake?
>
> And that is all just one person at one company's opinion.
>

First: ***do not panic!***

Second: This is not a foregone conclusion yet. It's merely a
***proposal***, and one that most of the community has reacted
negatively to. It may happen someday, but we *do* care about our
larger ecosystem and user community. Chances are pretty good we'll
have the capability to work with legacy BIOS boot on x86_64 machines
for a few more years.

Third: You pay for enterprise support from Red Hat, Inc. That means
you have the ability to inform Red Hat through your business
relationship of your needs. That subscription you pay for your RHEL
systems allows you a direct relationship and influence over *their*
roadmap. If you tell them that this would be a problem if it made its
way into RHEL, they will account for that in their roadmap planning.
Take advantage of that capability and talk to your account manager
about it. It's their job to listen to your concerns and ensure that is
accounted for. That's the value of the Red Hat Enterprise Linux
subscription you pay for!

As for anyone else looking at this thread with RHEL-tinted lenses as
more activist RHEL customers, please direct your feedback to your
account managers.


-- 
真実はいつも一つ！/ 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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?


On 14.4.2022 12:18, JadoNena via devel wrote:

But for here we deal with the real world where budgets require plans and 
hardware exists for years.



If you are dealing with the real world with real businesses then you 
should be aware of the fact that businesses are usually on a 3 - 5 year 
hw replacement cycle since it save costs as studies like these have 
found [¹].


After 3 - 5 years those computers are introduced into the re-use/recycle 
ecosystem and re-purposed elsewhere with the hw vendors being forced to 
support that cycle.


With 10 years of hw support in fedora it would fit nicely into that cycle.


That said obviously companies will lose that cost saving if they end up 
having to spend it in a license cost elsewhere, be it Red Hat, Microsoft 
or something else..



JBG


1. 
https://news.microsoft.com/en-nz/2018/10/16/true-cost-of-not-replacing-computers-revealed-in-microsoft-study-more-than-4000-each/

___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?



> Am 14.04.2022 um 14:05 schrieb Jóhann B. Guðmundsson :
> 
> On 14.4.2022 11:53, Peter Boy wrote:
>> 
>>> Am 14.04.2022 um 12:57 schrieb Jóhann B. Guðmundsson :
>>> 
>>> For example EU has regulation that requires vendors to have spare parts 
>>> available for 7–10 years after date of manufacturing so it makes sense for 
>>> the project to support hw no longer than a decade from the date of it's 
>>> manufacturing. ( which makes the oldest hw being support being manufactured 
>>> in 2012 ) and every process,workflows and decision being bound by that.
>>> 
>>> Is Fedora an distribution that does not revert but always transforms, rolls 
>>> out and moves forward or is it an distribution that is stuck in the past ( 
>>> from a software and hardware point of view )?
>> Sorry, you simple didn’t get the point. It is not just about hardware. Some 
>> Cloud providers doesn’t support UEFI boot at the moment - so said various 
>> voices from Cloud WG. And some data center insist ob BIOS boot because of 
>> whatever, presumably management infrastructure. So, the hardware does or 
>> does not support UEFI, doesn’t matter in these cases.
> 
> 
> So you are saying that 3rd party vendors ( cloud providers ) now dictate and 
> decide the direction of the project?
> 

Nobody dictates anything. The provider has its good reasons, whatever it is. 
And Fedora has its own reasons. As I said, it’s just our decision: how many 
users do we want to leave behind. Or can we think of a good solution and find 
the strength to organize it so that we don't lose any users or as few as 
possible. It's our problem, not anyone else's. 

Or: how much do we care about our users? And how connected do we feel to our 
users? 



___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Tomasz Torcz

On Thu, Apr 14, 2022 at 01:42:26PM +0200, Kevin Kofler via devel wrote:
> Jóhann B. Guðmundsson wrote:
> > In this case that SIG would be created for no good reason since the
> > outcome is inevitable.
> 
> I still do not see what is inevitable about the outcome. Keeping legacy, no 
> longer changing, interfaces working forever should require next to no 
> effort.

  So the SIG would have next to no work to do. Great!
In reality, distribution around BIOS booting change, compilers change,
there is always some effort required even to maintain status quo.

-- 
Tomasz Torcz   “Never underestimate the bandwidth of a station
to...@pipebreaker.plwagon filled with backup tapes.”  — Jim Gray
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?


On 14.4.2022 11:42, Kevin Kofler via devel wrote:

Jóhann B. Guðmundsson wrote:


For example EU has regulation that requires vendors to have spare parts
available for 7–10 years after date of manufacturing so it makes sense
for the project to support hw no longer than a decade from the date of
it's manufacturing. ( which makes the oldest hw being support being
manufactured in 2012 ) and every process,workflows and decision being
bound by that.

Lack of availability of original spare parts does not mean that the hardware
suddenly magically stops working for everybody.


No but it does mean that they cant run indefinitely

And there needs to be a number on this to adjust users expectation and 
10 years is a reasonable number from a business, parts and 
recycle/re-use availability,


What is unreasonable is to be expecting that it's supported indefinitely 
from OS and or HW vendors.


JBG
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread JadoNena via devel

> The question is: how many users do we want to leave behind? Or: how many 
> users must we leave behind because we can’t do the job.

We are just users.  Our expert development is for other professions than 
writing drivers and operating systems.

My company has about 200 Fedora user PCs around the world.
Plus about 20 servers in real hardware and 30-50 in virtual.
More are in RedHat too but I am not talking about those here.

We had decided on the RH+Centos+Fedora Eco system.

All desktops and some laptops (that equals about 170) use NVidia graphics.  In 
every case we use the NVidia drivers.  They are built with the DKIM software.  
It is not convenient but it is worth the effort.  We can rely on the NVidia 
software to work all the time. And we have access to the CUDA code and so on.

For the servers plus the user PCs about 60% are on BIOS boot not UEFI.  May be 
half of those are BIOS only.

My company has a budget.  We do the planning for 2-3 years.
It pays for developers salarys.  And for new hardware.  And for VPS rental 
costs.  And for user training.
And for our Enterprise support products and services like RedHat.

Unplanned and unexpected changes cost to my company a very large amount.
We always plan our strategy to control and best minimize that cost.
We must operate successfully for to pay those salarys and to purchase that 
hardware and services.

All of this discussion waves a red flag at us.
We think we hear that Fedora has philosophy arguments about opensource and 
propietary and BIOS and UEFI.
We read the crazy mathematics about numbers of users based on I don't know what.

But only a few people are talking about the real costs to users.

Okay, the developers here are interested only in what makes the life easier for 
them.
And want to not have "3rd party vendors now dictate" decisions.
I can understand that theory too.

But for here we deal with the real world where budgets require plans and 
hardware exists for years.
With this decision making the red flag means that "today & now" we must start 
with planning for alternatives to the RH+Centos+Fedora Eco system.

We did not expect this from the RH+Centos+Fedora Eco system.
That maybe is our mistake?

And that is all just one person at one company's opinion.

Jado
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?


On 14.4.2022 11:53, Peter Boy wrote:



Am 14.04.2022 um 12:57 schrieb Jóhann B. Guðmundsson :

For example EU has regulation that requires vendors to have spare parts 
available for 7–10 years after date of manufacturing so it makes sense for the 
project to support hw no longer than a decade from the date of it's 
manufacturing. ( which makes the oldest hw being support being manufactured in 
2012 ) and every process,workflows and decision being bound by that.

Is Fedora an distribution that does not revert but always transforms, rolls out 
and moves forward or is it an distribution that is stuck in the past ( from a 
software and hardware point of view )?

Sorry, you simple didn’t get the point. It is not just about hardware. Some 
Cloud providers doesn’t support UEFI boot at the moment - so said various 
voices from Cloud WG. And some data center insist ob BIOS boot because of 
whatever, presumably management infrastructure. So, the hardware does or does 
not support UEFI, doesn’t matter in these cases.



So you are saying that 3rd party vendors ( cloud providers ) now dictate 
and decide the direction of the project?



JBG
___
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: F38 Change: Major upgrade of Microdnf (Self-Contained Change proposal)

On Thu, Apr 14, 2022 at 7:40 AM Kevin Kofler via devel
 wrote:
>
> Gordon Messmer wrote:
> > I've gotta ask... How much memory does the new dnf daemon take while idle?
>
> As I understand it, the new DNF daemon would mostly only replace/upgrade the
> already existing dnfdaemon, for users of tools like Dnfdragora. It would not
> be required otherwise, or would it?
>

Yes. Applications need to directly use the dnfdaemon API to use the dnfdaemon.



-- 
真実はいつも一つ！/ 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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?



> Am 14.04.2022 um 12:57 schrieb Jóhann B. Guðmundsson :
> 
> For example EU has regulation that requires vendors to have spare parts 
> available for 7–10 years after date of manufacturing so it makes sense for 
> the project to support hw no longer than a decade from the date of it's 
> manufacturing. ( which makes the oldest hw being support being manufactured 
> in 2012 ) and every process,workflows and decision being bound by that.
> 
> Is Fedora an distribution that does not revert but always transforms, rolls 
> out and moves forward or is it an distribution that is stuck in the past ( 
> from a software and hardware point of view )?

Sorry, you simple didn’t get the point. It is not just about hardware. Some 
Cloud providers doesn’t support UEFI boot at the moment - so said various 
voices from Cloud WG. And some data center insist ob BIOS boot because of 
whatever, presumably management infrastructure. So, the hardware does or does 
not support UEFI, doesn’t matter in these cases.

And there is obviously some hardware around younger than 10 years that don’t 
support UEFI, at least not without problems.

And yes, there is some hardware older than 10 years. Currently Linux is known 
to support older hardware. Do we want to ditch that? 

Nevertheless, old or new hardware is not the issue.

The question is: how many users do we want to leave behind? Or: how many users 
must we leave behind because we can’t do the job.

___
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 2073893] CVE-2022-22624 webkit2: use after free issue

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


--- Doc Text *updated* by Sandipan Roy  ---
A use after free issue was found in WebKitGTK and WPE WebKit. A remote attacker 
may be able to process maliciously crafted web content may lead to arbitrary 
code execution. . The highest threat from this vulnerability is to data 
confidentiality and integrity as well as system availability.



-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073893
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

Jóhann B. Guðmundsson wrote:
> In this case that SIG would be created for no good reason since the
> outcome is inevitable.

I still do not see what is inevitable about the outcome. Keeping legacy, no 
longer changing, interfaces working forever should require next to no 
effort.

> For how long should fedora support any given hardware ( electric
> components do not last forever ) ?

Ideally, as long as there is at least one person still using it. In 
practice, it probably requires more than one person, but the user base for 
legacy BIOS is still large judging from the feedback in the thread.

> For example EU has regulation that requires vendors to have spare parts
> available for 7–10 years after date of manufacturing so it makes sense
> for the project to support hw no longer than a decade from the date of
> it's manufacturing. ( which makes the oldest hw being support being
> manufactured in 2012 ) and every process,workflows and decision being
> bound by that.

Lack of availability of original spare parts does not mean that the hardware 
suddenly magically stops working for everybody.

> Is Fedora an distribution that does not revert but always transforms,
> rolls out and moves forward or is it an distribution that is stuck in
> the past ( from a software and hardware point of view )?

Running on both old and new hardware does not preclude in any way shipping 
the most recent software. This is a false dichotomy.

Kevin Kofler
___
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 2073893] CVE-2022-22624 webkit2: use after free issue

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


--- Doc Text *updated* by Sandipan Roy  ---
A use after free issue was found in WebKitGTK and WPE WebKit. A remote attacker 
may be able to process maliciously crafted web content may lead to arbitrary 
code execution. The highest threat from this vulnerability is to data 
confidentiality and integrity as well as system availability.



-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073893
___
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)

2022-04-14 Thread Demi Marie Obenour

On 4/11/22 14:18, Peter Boy wrote:
> 
> 
>> Am 10.04.2022 um 04:50 schrieb Gary Buhrmaster :
>>
>> On Wed, Apr 6, 2022 at 6:01 PM 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.
> 
> I want to reiterate, it's not just about cloud platforms! if we remove BIOS 
> boot (too early), we also kick Fedora servers, installed on hardware, out of 
> these data centers.  And the reason is not that this server hardware does not 
> support UEFI, but the management infrastructure of the data centers.
> 
> And kicking ourselves out, really doesn't strike me as a brilliant idea. 
> 
>> They may only support Linux users today, but if
>> they want to grow (and while it is possible to
>> survive as a niche service, many see growth
>> as the way to increased revenue/profits (go
>> big or go home)), they are going to get pushed
>> (perhaps kicking and screaming) to support
>> UEFI as at least an alternative …
> 
> It’s not so much about kicking and streaming, but about time, man power and 
> financial resources.

Given how large a company Red Hat is, I presume that they could come up
with these resources.  The cost to Red Hat of maintaining legacy BIOS
support is much less than the cost to the community of not doing so.

-- 
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Miro Hrončok


On 13. 04. 22 22:29, Michel Alexandre Salim wrote:

On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote:

Hi,


1. I'm not sure if it is possible to setup group ownership
of pkgs in pagure? So to keep things simple the few packages which
are only necessary for BIOS boot can be handed over to me and then
I'll just add other people willing to help out as co-maintainers.


yup, Python, Rust, and Go SIG does this all the time


No, Python SIG does not. Each package needs a primary maintainer. The SIG 
co-maintains it. There are some exceptions when somebody set Python SIG as the 
primary point of contact, but pagure still tracks the "main admin" user/person 
-- this cannot be a group.


--
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: F38 Change: Major upgrade of Microdnf (Self-Contained Change proposal)

Gordon Messmer wrote:
> I've gotta ask... How much memory does the new dnf daemon take while idle?

As I understand it, the new DNF daemon would mostly only replace/upgrade the 
already existing dnfdaemon, for users of tools like Dnfdragora. It would not 
be required otherwise, or would it?

Kevin Kofler
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

Ralf Corsépius wrote:
> I do not agree with this statement.  Like previous "Legacy SIGs" this is
> a red herring to obfuscate RHATs lack of disinterest with topics, which
> do not match into their business objectives.

I am also worried that this is just a delayed retirement, as it was for 32-
bit i686, where the SIG was very quickly declared a failure, without even 
being given time to organize.

Still, it is better than retiring it immediately. But like you, I am worried 
that this is not really a long-term commitment and that people will be 
attempting to kill BIOS support again at even the smallest dent in SIG 
activity.

Kevin Kofler
___
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: gcc + llvm + annobin mess in f36-updates-testing

Michael Catanzaro wrote:
> Thing is, Kevin has a point here.

You are simulating agreement here, but you are still opposed to the solution 
I am actually proposing, so we are still actually in diametral disagreement.

> I've lost track of the number of times annobin troubles have resulted in
> gratuitous toolchain breakage. Sure seems like this happens more than it
> should.

Annobin is just a pain by design due to having to be rebuilt for each and 
every package update in the toolchain.

> It probably is time to consider special rules for this package. Perhaps
> annobin should not be updated unless both GCC and LLVM are also updated
> in the same bodhi update? Or, if this is difficult for some reason,
> maybe annobin should only be updated in rawhide and not in branched
> releases? Just brainstorming

Both these ideas would not have fixed the race condition between the GCC 
update with one annobin rebuild and the LLVM update with another annobin 
rebuild. We would just have had two conflicting annobin updates instead of 
three, still one too many.

In addition, if bugs come up in the annobin plugin itself, it needs to be 
fixed.

> Rebuilding packages makes it much less useful

I still have not seen any convincing argument why, if you are going to 
unpack all packages and scan their annobin annotations for "bad" build 
flags, it would be any less useful to do this on a side repository with 
packages rebuilt with annobin enabled than to do this directly on the main 
repository. There is a one-time effort to set up the rebuilding bot, but the 
quality of the resulting analysis should be exactly the same. Rebuilding 
with annobin enabled will not magically change the GCC flags used to build 
the package.

> and increases delta between Fedora and RHEL.

Fedora should be optimized for Fedora users' needs, not for RHEL users' 
needs.

> Minimally-increased package size is a silly concern. The problem here is
> just broken updates.

IMHO, both are issues, but I agree that the broken updates are the bigger 
issue.

Kevin Kofler
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

2022-04-14 Thread Gary Buhrmaster

On Wed, Apr 13, 2022 at 9:12 PM Matthew Miller  wrote:

> It'd be cool to see if we can make a bios-to-uefi thing like Clover work.
> That might be something interesting for the SIG to do. But, I don't think
> that's really a small project!

This is mostly off topic, and while I have not
carefully tracked the project in recent years,
the clover uefi emulator has been said to
work a lot of the time out of the box, but due
to some of the ways that vendors choose to
implement bios features/tables it can require
complex configuration, typically unique for
that particular system (type).  I also seem to
recall there were some utilities to try to
assist figuring out that configuration, but
those were not always for the faint of heart.
The hard part (as is usually the case) was
dealing with those edge cases, even as the
clover project has a lot of documentation
trying to help.
___
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: adding GCC Toolset usage docs

Vít Ondruch wrote:
> The sourcing trick is generally very dangerous. It might be OKish in RPM
> scriptlets, but otherwise it might result in unpredictable behavior of
> the system.

It is generally the right thing to do for shell scripts. Those run in a 
subshell, so the sourcing will not affect the calling shell. It should be 
documented somewhere.

Kevin Kofler
___
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 2073893] CVE-2022-22624 webkit2: use after free issue

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

Sandipan Roy  changed:

   What|Removed |Added

 Depends On||2075493, 2075492




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073893
___
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

Trivial opencsg license change

2022-04-14 Thread Miro Hrončok


opencsg was updated to 1.5.0 in Rawhide and the license was updated:

- License:GPLv2 with exceptions
+ License:GPLv2+ and zlib

The zlib bit appears to existed even with the previous version but was 
forgotten.

The change from GPLv2 to GPLv2+ was a deliberate change upstream and the 
exception (linking with CGAL) is no longer needed.


--
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?