Fedora rawhide compose report: 20240628.n.1 changes

2024-06-28 Thread Fedora Rawhide Report
OLD: Fedora-Rawhide-20240626.n.0
NEW: Fedora-Rawhide-20240628.n.1

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  17
Dropped packages:8
Upgraded packages:   256
Downgraded packages: 1

Size of added packages:  6.14 MiB
Size of dropped packages:768.68 KiB
Size of upgraded packages:   3.95 GiB
Size of downgraded packages: 102.37 KiB

Size change of upgraded packages:   -99.07 MiB
Size change of downgraded packages: -540 B

= ADDED IMAGES =
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20240628.n.1.iso

= DROPPED IMAGES =
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20240626.n.0.iso

= ADDED PACKAGES =
Package: clean-rpm-gpg-pubkey-0-1.20210505gitebb9ab1.fc41
Summary: Remove old PGP keys from the RPM database
RPMs:clean-rpm-gpg-pubkey
Size:21.00 KiB

Package: fbf-mukti-fonts-3.0.3-2.fc41
Summary: Bangla open source Opentype font
RPMs:fbf-mukti-fonts
Size:191.37 KiB

Package: gap-pkg-typeset-1.2.2-1.fc41
Summary: Automatic typesetting framework for common GAP objects
RPMs:gap-pkg-typeset gap-pkg-typeset-doc
Size:270.32 KiB

Package: python-crick-0.0.6-1.fc41
Summary: High performance approximate and streaming algorithms
RPMs:python3-crick
Size:802.46 KiB

Package: python-distributed-2024.6.2-3.fc41
Summary: Distributed scheduler for Dask
RPMs:python3-distributed
Size:3.55 MiB

Package: python-hsluv-5.0.4-2.fc41
Summary: A Python implementation of HSLuv (revision 4)
RPMs:python3-hsluv
Size:17.60 KiB

Package: rust-cookie_store0.20-0.20.0-1.fc41
Summary: Implementation of Cookie storage and retrieval
RPMs:rust-cookie_store0.20+default-devel 
rust-cookie_store0.20+indexmap-devel 
rust-cookie_store0.20+log_secure_cookie_values-devel 
rust-cookie_store0.20+preserve_order-devel 
rust-cookie_store0.20+public_suffix-devel 
rust-cookie_store0.20+publicsuffix-devel rust-cookie_store0.20-devel
Size:80.66 KiB

Package: rust-libusb1-sys-0.7.0-2.fc41
Summary: FFI bindings for libusb
RPMs:rust-libusb1-sys+default-devel rust-libusb1-sys-devel
Size:26.73 KiB

Package: rust-ouroboros0.17-0.17.2-1.fc41
Summary: Easy, safe self-referential struct generation
RPMs:rust-ouroboros0.17+default-devel rust-ouroboros0.17+std-devel 
rust-ouroboros0.17-devel
Size:33.33 KiB

Package: rust-ouroboros_macro0.17-0.17.2-1.fc41
Summary: Proc macro for ouroboros crate
RPMs:rust-ouroboros_macro0.17+default-devel 
rust-ouroboros_macro0.17+std-devel rust-ouroboros_macro0.17-devel
Size:44.26 KiB

Package: rust-proptest-derive0.4-0.4.0-2.fc41
Summary: Custom-derive for the Arbitrary trait of proptest
RPMs:rust-proptest-derive0.4+default-devel rust-proptest-derive0.4-devel
Size:64.73 KiB

Package: rust-pyo3-build-config0.21-0.21.2-1.fc41
Summary: Build configuration for the PyO3 ecosystem
RPMs:rust-pyo3-build-config0.21+abi3-devel 
rust-pyo3-build-config0.21+abi3-py310-devel 
rust-pyo3-build-config0.21+abi3-py311-devel 
rust-pyo3-build-config0.21+abi3-py312-devel 
rust-pyo3-build-config0.21+abi3-py37-devel 
rust-pyo3-build-config0.21+abi3-py38-devel 
rust-pyo3-build-config0.21+abi3-py39-devel 
rust-pyo3-build-config0.21+default-devel 
rust-pyo3-build-config0.21+extension-module-devel 
rust-pyo3-build-config0.21+resolve-config-devel rust-pyo3-build-config0.21-devel
Size:108.38 KiB

Package: rust-pyo3-ffi0.21-0.21.2-2.fc41
Summary: Python-API bindings for the PyO3 ecosystem
RPMs:rust-pyo3-ffi0.21+abi3-devel rust-pyo3-ffi0.21+abi3-py310-devel 
rust-pyo3-ffi0.21+abi3-py311-devel rust-pyo3-ffi0.21+abi3-py312-devel 
rust-pyo3-ffi0.21+abi3-py37-devel rust-pyo3-ffi0.21+abi3-py38-devel 
rust-pyo3-ffi0.21+abi3-py39-devel rust-pyo3-ffi0.21+default-devel 
rust-pyo3-ffi0.21+extension-module-devel rust-pyo3-ffi0.21-devel
Size:153.73 KiB

Package: rust-pyo3-macros-backend0.21-0.21.2-1.fc41
Summary: Code generation for PyO3 package
RPMs:rust-pyo3-macros-backend0.21+default-devel 
rust-pyo3-macros-backend0.21+experimental-async-devel 
rust-pyo3-macros-backend0.21-devel
Size:72.86 KiB

Package: rust-pyo3-macros0.21-0.21.2-1.fc41
Summary: Proc macros for PyO3 package
RPMs:rust-pyo3-macros0.21+default-devel 
rust-pyo3-macros0.21+experimental-async-devel 
rust-pyo3-macros0.21+experimental-declarative-modules-devel 
rust-pyo3-macros0.21+multiple-pymethods-devel rust-pyo3-macros0.21-devel
Size:44.61 KiB

Package: rust-pyo3_0.21-0.21.2-2.fc41
Summary: Bindings to Python interpreter
RPMs:rust-pyo3_0.21+abi3-devel rust-pyo3_0.21+abi3-py310-devel 
rust-pyo3_0.21+abi3-py311-devel rust-pyo3_0.21+abi3-py312-devel 
rust-pyo3_0.21+abi3-py37-devel rust-pyo3_0.21+abi3-py38-devel 
rust-pyo3_0.21+abi3-py39-devel rust-pyo3_0.21+anyhow-devel 
rust-pyo3_0.21+auto-initialize-devel rust-pyo3_0.21+chrono-devel 
rust-pyo3_0.21+chrono-tz-devel rust-pyo3_0.21+default-devel 
rust-pyo3_0.21+either-devel rust-pyo3_0.21

[Test-Announce]Fedora 41 Rawhide 20240628.n.1 nightly compose nominated for testing

2024-06-28 Thread rawhide
Announcing the creation of a new nightly release validation test event
for Fedora 41 Rawhide 20240628.n.1. 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/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/41

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240628.n.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240628.n.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240628.n.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240628.n.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240628.n.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240628.n.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_41_Rawhide_20240628.n.1_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
-- 
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
-- 
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Guidance on individual packages requiring x86_64-v2 baseline ?

2024-06-28 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Jun 21, 2024 at 12:27:25PM -0400, Stephen Smoogen wrote:
> On Fri, 21 Jun 2024 at 07:27, Vít Ondruch  wrote:
> > So what is the reason to not treat x86_64_v2 as different arch then
> > x86_64_v{1,3}. Why we keep having this discussion instead of fire one
> > more build? Users would need to choose v1 / v2 / v3 ISO but what else?
> 
> I can think of three problems which would need to be dealt with
> 
> 1. Resource limitations in infrastructure hardware. You are going to
> add to the amount of builds on 1 set of hardware which is already
> doing x86_64 and i686. You are going to add to the storage issues that
> Fedora Infrastructure has to juggle on the maximum 100TB koji
> partition (with 90TB causing some amount of degradation) due to extra
> packages and composes.
> 2. Resource limitations in infrastructure staff. Fedora Infra is doing
> more with less and each additional architecture and focus increases
> that load.
> 3. Resource limitations on packagers. Packagers will need to add yet
> another bug set to cover and determine "is it only on VX" or not.

Another reason: is it actually useful at all?

Benchmarking so far hasn't been mention in this thread. But it was
discussed fairly extensively in previous interations on fedora-devel,
and the results were … not impressive.

The first consideration is that many packages already employ multiple
versions of functions and select the optimal version _at runtime_. In
that case, there is no "baseline architecture", the program works on
all µarchitectures, just faster or slower. This includes various BLAS
libraries, but also very importantly glibc itself with IFUNCS, some
compression libraries, etc. This means that for many programs the
heavy number crunching is already optimized, and raising the
µarchitecture level will have negligible effect on performance.

The second consideration is that many packages are not CPU-bound at
all, or don't perform the kind of processing where AVX and other
instructions make a difference.

So overall, there _might_ be some programs which would benefit from
higher µarchitecture requirements. Before starting a huge effort to
recompile the distro, it'd be prudent to do some local compilations
and benchmarking.

But OK, let's jump forward and we identified a subset of Fedora that'd
benefit. For those programs, a runtime approach based on IFUNCS or
equivalent is the most powerful. Only the hot paths need to be
targeted, delivering the same benefits as raising the baseline for the
whole program, while being transparent to the user. Also, this
approach can be more flexible, because it's OK to have many different
variants, rather than just targeting four µarchitecture levels. It
also requires much less resources, because we don't deliver multiple
versions of the package, but instead a few versions of the hot
functions, all in the same binary.

Only for programs where there is potential benefit, but we cannot do
IFUNCS, compiling with a higher baseline is a useful approach.

Overall, I think that we _should_ have more software optimized
for newer CPUs, but the solutions should be targeted at the right
packages and the right parts of the code. Just compiling everything
multiple times is IMO a waste of resources.

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


Re: Fedora Hosted login for mailing lists error

2024-06-28 Thread Adam Williamson
On Fri, 2024-06-28 at 09:42 +0200, Michal Konecny wrote:
> My assumption is that OpenID just checked the client_id server side and 
> not the origin URL.
> I will need to check what are the posibilities in OIDC as it needs 
> different redirect_uri for each instance as well. Maybe it could be 
> defined as template or regex in the definition. I'm not expert on 
> Ipsilon, so I need to check the options.

If each instance has its own client id and expected redirects, can't we
just add more client configs to Ipsilon? One per instance?
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




-- 
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F41 Change Proposal: Switch to DNF5 (system-wide)

2024-06-28 Thread Frank Ch. Eigler
Jan Kolarik  writes:

>[...]
> The dnf-automatic command will still be available, now provided as a
> plugin and functionally compatible with dnf4. Although the
> configuration files' location has changed, it will be documented in
> the dnf4 vs. dnf5 changes documentation.

This configuration file location change is unfortunate.  Could the code
look at the older /etc/dnf/automatic.conf also please?


- FChE

-- 
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: [Fedocal] Reminder meeting : ELN SIG

2024-06-28 Thread Stephen Gallagher
On Thu, Jun 27, 2024 at 9:17 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2024-06-28 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
>

Due to a lack of agenda topics, today's meeting is CANCELED

-- 
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Receiving BZ Outstanding Requests for orphaned package

2024-06-28 Thread Fabio Valentini
On Fri, Jun 28, 2024 at 1:32 PM Sandro  wrote:
>
> On 28-06-2024 13:23, Christiano Anderson wrote:
> > I have orphaned the buildstream package some time ago, but I may not
> > have removed myself from the Bugzilla Assignee option.
> >
> > I am receiving outstanding request notifications related to this
> > package. I couldn't find a way to take myself off the Bugzilla Assignee.
> >
> > Was there a step in the orphaning process that I missed? How to fix it?
>
> It looks like you might need to clear the needinfo flag on
> https://bugzilla.redhat.com/show_bug.cgi?id=2252071.
>
> I believe those are not handled by orphaning a package, but remain open
> as is.

Correct. Additionally, you will remain in the CC of existing bugs,
unless you remove yourself. Only *new* bugs will not be associated
with you.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Receiving BZ Outstanding Requests for orphaned package

2024-06-28 Thread Sandro

On 28-06-2024 13:23, Christiano Anderson wrote:
I have orphaned the buildstream package some time ago, but I may not 
have removed myself from the Bugzilla Assignee option.


I am receiving outstanding request notifications related to this 
package. I couldn't find a way to take myself off the Bugzilla Assignee.


Was there a step in the orphaning process that I missed? How to fix it?


It looks like you might need to clear the needinfo flag on 
https://bugzilla.redhat.com/show_bug.cgi?id=2252071.


I believe those are not handled by orphaning a package, but remain open 
as is.


-- Sandro


--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Receiving BZ Outstanding Requests for orphaned package

2024-06-28 Thread Christiano Anderson

Hello,

I have orphaned the buildstream package some time ago, but I may not 
have removed myself from the Bugzilla Assignee option.


I am receiving outstanding request notifications related to this 
package. I couldn't find a way to take myself off the Bugzilla Assignee.


Was there a step in the orphaning process that I missed? How to fix it?

Thanks

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


Re: Fedora Hosted login for mailing lists error

2024-06-28 Thread Michal Konecny
My assumption is that OpenID just checked the client_id server side and 
not the origin URL.
I will need to check what are the posibilities in OIDC as it needs 
different redirect_uri for each instance as well. Maybe it could be 
defined as template or regex in the definition. I'm not expert on 
Ipsilon, so I need to check the options.


Michal

On 28. 06. 24 9:14, Neal Gompa wrote:

On Fri, Jun 28, 2024 at 9:04 AM Michal Konecny  wrote:

I can see what is happening here, in OIDC we have entry only for
lists.fedoraproject.org.

I created a ticket on infra tracker for you
https://pagure.io/fedora-infrastructure/issue/12013, but I'm not sure
how to solve this as the OIDC entry is shared between all instances and
it doesn't allow us to have more client URLs than one. As workaround you
can use lists.fedoraproject.org for now, the list can be found there as
well
https://lists.fedoraproject.org/archives/list/firewalld-us...@lists.fedorahosted.org/


How did the custom FAS/OpenID plugin work around this? I know it
worked with that deployment...




--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Fedora Hosted login for mailing lists error

2024-06-28 Thread Neal Gompa
On Fri, Jun 28, 2024 at 9:04 AM Michal Konecny  wrote:
>
> I can see what is happening here, in OIDC we have entry only for
> lists.fedoraproject.org.
>
> I created a ticket on infra tracker for you
> https://pagure.io/fedora-infrastructure/issue/12013, but I'm not sure
> how to solve this as the OIDC entry is shared between all instances and
> it doesn't allow us to have more client URLs than one. As workaround you
> can use lists.fedoraproject.org for now, the list can be found there as
> well
> https://lists.fedoraproject.org/archives/list/firewalld-us...@lists.fedorahosted.org/
>

How did the custom FAS/OpenID plugin work around this? I know it
worked with that deployment...


-- 
真実はいつも一つ!/ 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Fedora Hosted login for mailing lists error

2024-06-28 Thread Michal Konecny
I can see what is happening here, in OIDC we have entry only for 
lists.fedoraproject.org.


I created a ticket on infra tracker for you 
https://pagure.io/fedora-infrastructure/issue/12013, but I'm not sure 
how to solve this as the OIDC entry is shared between all instances and 
it doesn't allow us to have more client URLs than one. As workaround you 
can use lists.fedoraproject.org for now, the list can be found there as 
well 
https://lists.fedoraproject.org/archives/list/firewalld-us...@lists.fedorahosted.org/


Michal


On 28. 06. 24 1:56, Kevin Fenzi wrote:

On Thu, Jun 27, 2024 at 04:46:41PM GMT, Nathanael Noblet wrote:

Hello,

I just happened to be looking at
https://lists.fedorahosted.org/accounts/login/?next=/archives/list/firewalld-users%40lists.fedorahosted.org/
to try to sign up, and when I click on "Fedora" to try to use my fedora
account, I get a page telling me they'll redirect. Clicking continue
and I get 400 - Bad Request. "Invalid redirect_uri" and a message
saying to let Fedora Infra know. I don't know how to do that.

There's a link in the message right there. ;)

https://pagure.io/fedora-infrastructure/issues


I've used the "send an email to the special address" way, but just
wasn't sure how else to report the issue.

In this case it's likely fallout from the massive mailman upgrade from
eailer today. We already have a few issues to sort out noted in
https://pagure.io/fedora-infrastructure/issue/8455#comment-916759

I'll add a note that the lists.fedorahosted.org login isn't working
right.

kevin



--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue