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
https://bugzilla.redhat.com/show_bug.cgi?id=2031448
Gary Buhrmaster changed:
What|Removed |Added
Doc Type|--- |If docs needed, set a value
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
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,
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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,
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
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
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
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
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.
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
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
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,
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 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
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
>
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=2075210
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #2 from
https://bugzilla.redhat.com/show_bug.cgi?id=2071593
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #2 from
https://bugzilla.redhat.com/show_bug.cgi?id=2074633
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #2 from
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 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
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
> 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
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
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
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
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
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,
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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=2062023
Fedora Update System changed:
What|Removed |Added
Resolution|--- |ERRATA
Fixed In Version|
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
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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=2071865
Fedora Update System changed:
What|Removed |Added
Resolution|--- |ERRATA
Fixed In Version|
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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 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
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!
>
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
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
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
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
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
> 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
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
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
> 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
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
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
> 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
>
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
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
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
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
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
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?
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
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
>
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=2073893
Sandipan Roy changed:
What|Removed |Added
Depends On||2075493, 2075492
--
You are
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
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
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
1 - 100 of 114 matches
Mail list logo
