Am 13.04.22 um 20:05 schrieb David Cantrell:
The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work in
Fedora.
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 i
On 14.4.2022 02:23, Demi Marie Obenour wrote:
On 4/13/22 17:11, Jóhann B. Guðmundsson wrote:
On 13.4.2022 08:04, David Bold wrote:
It seems I must be missing something? Why should we not care about a
significant number of our users, just because other OSs have more users?
Could you explain that
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.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
On Thu, Apr 14, 2022 at 10:01:30AM +0200, Ralf Corsépius wrote:
>
>
> Am 13.04.22 um 20:05 schrieb David Cantrell:
>
> > The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work
> > in
> > Fedora.
>
> I do not agree with this statement. Like previous "Legacy SIGs" this is a
No missing expected images.
Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-34-20220413.0):
ID: 1224980 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
Dne 14. 04. 22 v 2:49 Kevin Kofler via devel napsal(a):
Germano Massullo wrote:
This problem was caused because I had misinterpreted official Red Hat
configuration [2].
The documentation was written with interactive use in mind, not for
scripting or packaging. The "scl enable" tool is very imp
On Thu, 14 Apr 2022 12:15:43 +0200
Vít Ondruch wrote:
>
> Dne 14. 04. 22 v 2:49 Kevin Kofler via devel napsal(a):
> > Germano Massullo wrote:
> >> This problem was caused because I had misinterpreted official Red Hat
> >> configuration [2].
> > The documentation was written with interactive use
On 14.4.2022 09:17, Tomasz Torcz wrote:
On Thu, Apr 14, 2022 at 10:01:30AM +0200, Ralf Corsépius wrote:
Am 13.04.22 um 20:05 schrieb David Cantrell:
The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work in
Fedora.
I do not agree with this statement. Like previous "Legac
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
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 th
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
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
> grat
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
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?
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 ove
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 se
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 sh
> 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
> manufac
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 l
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 fro
> 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 th
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
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 changi
> 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 manufactur
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 r
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
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
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
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
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!
>
>
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
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
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 (vi
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
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. Resto
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
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
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
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
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 Cantre
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 BIO
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 r
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 t
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
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
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 t
> 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 i
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 argume
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 s
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 fro
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
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,
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 a
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
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 B
> 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
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
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
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
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 3
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
>
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
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
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
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 u
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
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
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 med
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 ce
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
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 i
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
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 wan
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 block
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
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?
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 Ce
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. I
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 fro
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
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)
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 be
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*
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 l
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
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 t
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, Robbi
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
li
On Thu, Apr 14, 2022 at 11:39 AM Kevin Kofler via devel
wrote:
> 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.
Well, presumably, if you are a member of the SI
> Am 15.04.2022 um 00:24 schrieb Nikolay Nikolov :
>
> 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
> mo
90 matches
Mail list logo
