I consider this as spam that serves no purpose!
--
___
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-co
Could you by any chance link to the commit that introduces this issue? I'd like
to bring this to the awareness of core devs in Ubuntu.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproj
MULTIMEDIA
Jean-Baptiste Kempf released Dav1d 1.4.2 as the newest version of this speedy
CPU-based AV1 video decoder. With this new dav1d 1.4.2 update are yet more
performance optimizations for modern systems.
Dav1d 1.4.2 brings more AVX2 and AVX-512 performance optimizations to benefit
newer A
On Thu, Jun 13, 2024 at 1:35 AM Kevin Kofler via devel
wrote:
> But it is the ONLY approach that is compatible with Fedora policies, and as
> such should be required. ESPECIALLY for a package like QEMU that many people
> are using.
Please provide your audited (by a 3rd party) data that shows
tha
> This change proposal aims at removing NetworkManager support for ifcfg
> files in Fedora.
[snip]
> * Proposal owners: drop the following packages:
> ** `NetworkManager-initscripts-ifcfg-rh` containing the ifcfg plugin
Huh? This contradicts the following paragraph in the simultaneously filed
htt
Daniel P. Berrangé wrote:
> It isn't as simple as changing the CFLAGS. QEMU used to check for
> the CPU feature at startup, set a flag, and then later use that flag
> to choose different codepaths, but this logic was removed. Avoiding
> the flag check in hot-paths makes a perf difference.
>
> So w
Chris Adams wrote:
> Once upon a time, Neal Gompa said:
>> We may also want to start having a conversation about moving to
>> x86_64-v2 RPM arch for x86_64 across the board if we're going to start
>> encountering stuff like this.
>
> Is there a good decoder ring for which CPUs are which level? L
Once upon a time, Neal Gompa said:
> We may also want to start having a conversation about moving to
> x86_64-v2 RPM arch for x86_64 across the board if we're going to start
> encountering stuff like this.
Is there a good decoder ring for which CPUs are which level? Looking at
all my systems, I
Announcing the creation of a new nightly release validation test event
for Fedora 41 Rawhide 20240612.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki
On Wed, Jun 12, 2024 at 9:15 PM Przemek Klosowski via devel
wrote:
>
> On 6/12/24 14:07, Ben Cotton wrote:
> > Yeah, maintaining that long-term seems like a bad idea. [...] But it
> > would at least buy us some time so that we don't end up with the
> > "surprise, you can't use this release on your
On 6/12/24 14:07, Ben Cotton wrote:
Yeah, maintaining that long-term seems like a bad idea. [...] But it
would at least buy us some time so that we don't end up with the
"surprise, you can't use this release on your hardware if you want to
use QEMU!" situation.
The root cause seems to be the QEM
On Wed, Jun 12, 2024 at 6:08 PM Ben Cotton wrote:
> But it
> would at least buy us some time so that we don't end up with the
> "surprise, you can't use this release on your hardware if you want to
> use QEMU!" situation.
Since we don't have complete instrumentation, we
really don't know ho
* Daniel P. Berrangé:
> On Wed, Jun 12, 2024 at 09:59:25AM -0400, Stephen Gallagher wrote:
>> OK, that's a situation that will lead to annoying and unresolvable bug
>> reports. Would it be possible to put something in place that would
>> check processor capabilities early in execution before hitti
On Wed, Jun 12, 2024 at 12:35 PM Daniel P. Berrangé wrote:
>
> It isn't as simple as changing the CFLAGS. QEMU used to check for
> the CPU feature at startup, set a flag, and then later use that flag
> to choose different codepaths, but this logic was removed. Avoiding
> the flag check in hot-path
On Wed, Jun 12, 2024 at 4:00 PM Stephen Gallagher wrote:
>
> On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé
> wrote:
> >
> > On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote:
> > > On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé
> > > wrote:
> > > > IOW, if [when] we re
Minutes:
https://meetbot-raw.fedoraproject.org//meeting-1_matrix_fedoraproject-org/2024-06-12/fedora-coreos-meeting.2024-06-12-16.36.html
Minutes (text):
https://meetbot-raw.fedoraproject.org//meeting-1_matrix_fedoraproject-org/2024-06-12/fedora-coreos-meeting.2024-06-12-16.36.txt
Log:
https://me
On Wed, Jun 12, 2024 at 05:35:24PM +0100, Daniel P. Berrangé wrote:
> It isn't as simple as changing the CFLAGS. QEMU used to check for
> the CPU feature at startup, set a flag, and then later use that flag
> to choose different codepaths, but this logic was removed. Avoiding
> the flag check in ho
On Wed, Jun 12, 2024 at 11:50:00AM -0400, Ben Cotton wrote:
> On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé
> wrote:
> >
> > The context is that QEMU has recently merged changes upstream that force
> > use of the x86-64-v2 baseline for QEMU, in order get more efficient code
> > in the TCG em
On Wed, Jun 12, 2024 at 3:50 PM Ben Cotton wrote:
> Neither "Functional" nor "eFficient" are in the Fedora Foundations,
> but in general, I think we should prefer the former over the latter.
> It's better for the project overall to be a little less efficient than
> it could be than to surprise pe
On Wed, Jun 12, 2024 at 5:47 PM Daniel P. Berrangé wrote:
>
> On Wed, Jun 12, 2024 at 10:05:13AM -0400, Ben Beasley wrote:
> > This never made it to the packaging guidelines, but FESCo made a relevant
> > decision a few years ago:
> >
> > Libraries packaged in Fedora may require ISA extensions, ho
On Wed, Jun 12, 2024 at 04:58:57PM GMT, David Abdurachmanov wrote:
> On Mon, Jun 10, 2024 at 5:53 PM Andrea Bolognani wrote:
> > On Wed, May 29, 2024 at 02:56:01PM GMT, Kevin Fenzi wrote:
> > > yeah, I've seen this pattern before, but it's not a great way to do
> > > things. ;(
> > >
> > > Probibl
On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé wrote:
>
> The context is that QEMU has recently merged changes upstream that force
> use of the x86-64-v2 baseline for QEMU, in order get more efficient code
> in the TCG emulator. The changes were made in QEMU's global CFLAGS so this
> will affe
On Wed, Jun 12, 2024 at 10:05:13AM -0400, Ben Beasley wrote:
> This never made it to the packaging guidelines, but FESCo made a relevant
> decision a few years ago:
>
> Libraries packaged in Fedora may require ISA extensions, however any
> packaged application must not crash on any officially supp
Thank you to everyone involved!
--
Gwyn Ciesla
she/her/hers
in your fear, seek only peace
in your fear, seek only love
-d. bowie
Sent with Proton Mail secure email.
On Wednesday, June 12th, 2024 at 4:29 AM, Karolina Surma
wrote:
> On 6/12
On Wed, Jun 12, 2024 at 10:07 AM Daniel P. Berrangé wrote:
>
> On Wed, Jun 12, 2024 at 09:59:25AM -0400, Stephen Gallagher wrote:
> > On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé
> > wrote:
> > >
> > > On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote:
> > > > On Wed, Jun 1
On Wed, Jun 12, 2024 at 09:59:25AM -0400, Stephen Gallagher wrote:
> On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé
> wrote:
> >
> > On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote:
> > > On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé
> > > wrote:
> > > > IOW, if [when
This never made it to the packaging guidelines, but FESCo made a
relevant decision a few years ago:
Libraries packaged in Fedora may require ISA extensions, however any
packaged application must not crash on any officially supported
architecture, either by providing a generic fallback implemen
On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé wrote:
>
> On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote:
> > On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé
> > wrote:
> > > IOW, if [when] we rebase Fedora to the next QEMU upstream release, users
> > > with older x86_6
On Mon, Jun 10, 2024 at 5:53 PM Andrea Bolognani wrote:
>
> On Wed, May 29, 2024 at 02:56:01PM GMT, Kevin Fenzi wrote:
> > yeah, I've seen this pattern before, but it's not a great way to do
> > things. ;(
> >
> > Probibly filing a bug is a good idea.
> >
> > It looks like there's only 2 packages
On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote:
> On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé
> wrote:
> > IOW, if [when] we rebase Fedora to the next QEMU upstream release, users
> > with older x86_64 hardware would likely be unable to run QEMU, from F41
> > onwards, un
On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé wrote:
>
> There have been various change proposals & associated mailing list threads
> over the years about the possibility of moving Fedora compiler toolchain
> to build with a newer x86_64 baseline ABI, which have ended up rejected,
> with some
There have been various change proposals & associated mailing list threads
over the years about the possibility of moving Fedora compiler toolchain
to build with a newer x86_64 baseline ABI, which have ended up rejected,
with some quite strong negative feedback.
Regardless of the Fedora general po
On Tue, Jun 11, 2024 at 01:52:19PM +0100, Sérgio Basto wrote:
> On Tue, 2024-06-04 at 14:26 +0200, Jiri Konecny wrote:
> > You should be able to install from Live ISO which we are not
> > modifying
> > (depends on environment set by SIG owners). However, we won't support
> > X11 together with Wayl
On 6/12/24 00:10, Miro Hrončok wrote:
On 10. 06. 24 17:34, Karolina Surma wrote:
Hello,
The Python 3.13 rebuild is in progress. We plan to merge the side tag
soon.
I requested the side tag to be merged.
https://pagure.io/releng/issue/12155
If you build for f41-python now, there is a risk
34 matches
Mail list logo
