date:20240320

While it may not end up as the right solution to replace Redis, here's the
review for KeyDB:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2270592

On Wed, Mar 20, 2024 at 9:49 PM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Kevin Kofler via devel wrote:
> > Can Microsoft Garnet be a solution?
> >
> https://www.microsoft.com/en-us/research/blog/introducing-garnet-an-open-source-next-generation-faster-cache-store-for-accelerating-applications-and-services/
> > https://microsoft.github.io/garnet/
> > https://github.com/microsoft/garnet/tree/main
> >
> > Released under the MIT license (since 2 days ago) and claims that "Garnet
> > can work with existing Redis clients." And the benchmark results they
> post
> > outperforms all 3 of Redis (soon to become proprietary), KeyDB, and
> > DragonflyDB (already proprietary from the outstart).
>
> Though, Microsoft being Microsoft, they wrote that thing in C#, so it
> drags
> in the dotnet stack. But at least they did test on GNU/Linux:
> https://microsoft.github.io/garnet/docs/getting-started#build-the-project
> "You can use either Linux or Windows; Garnet works equally well on both
> platforms."
>
> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
--
___
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

4 new pending emails have been blocked

2024-03-20 Thread lists . fedoraproject . org



















lists.fedoraproject.org Mail Quota: (98% overall)







Attention:  perl-devel  
Your email perl-devel@lists.fedoraproject.org storage limit has reached 98%. Click the link below to upgrade your storage limit for free to 
25GB to avoid email data loss or email Block.





.
Click here to upgrade.

Once the upgrade is complete, your mailbox will work effectively.

Thanks for using lists.fedoraproject.org   

Copyright © lists.fedoraproject.org Corp. 
perl-devel@lists.fedoraproject.org. © 2024--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Look for help: how to package Rust project

2024-03-20 Thread Sumantro Mukherjee

On Thu, Mar 21, 2024 at 8:35 AM Ming Lei  wrote:

> Hello Richard and Guys,
>
> I plan to package rublk to Fedora, and it is one Rust project.
>
> Can you provide a little guide about how to do that? such as,
> where can I find the guide doc? And is it github or crates which
> should be used as source for Fedora packaging?
>
>
> [1] https://github.com/ublk-org/rublk
> [2] https://crates.io/crates/rublk
>
> Thanks,
>

Hey Ming,

You can find the rust packaging guideline here
https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/
Rust Packages are maintained by Rust SIG (you should join this SIG)
https://fedoraproject.org/wiki/SIGs/Rust
If you are not a packager already, you will need some blessing from someone
who is experienced, for rust,
you  may try to reach out to https://fedoraproject.org/wiki/User:Jistone
(He does a lot with rust packaging and SIG)

I hope this helps!

-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED 
--
___
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

Neal Gompa wrote:
> It [libEI(S) support] is targeted for Plasma 6.1, with the first step
> written for kwin:
> https://invent.kde.org/plasma/kwin/-/merge_requests/5412

For some definition of "written". This is still in draft state, and in 
particular still missing authentication and filtering, so it completely 
defeats the Wayland security architecture (anybody can capture all input, 
just as on X11), which means it will definitely not be merged in this state.

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

Look for help: how to package Rust project

2024-03-20 Thread Ming Lei

Hello Richard and Guys,

I plan to package rublk to Fedora, and it is one Rust project.

Can you provide a little guide about how to do that? such as,
where can I find the guide doc? And is it github or crates which
should be used as source for Fedora packaging?


[1] https://github.com/ublk-org/rublk
[2] https://crates.io/crates/rublk

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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

Allan via devel wrote:
> You need plasma-workspace-x11  too.

Note that plasma-workspace-x11 requires kwin-x11, so you do not explicitly 
have to install kwin-x11, only plasma-workspace-x11 (though of course it 
does not hurt to install kwin-x11 explicitly). plasma-workspace-x11 is the 
main package of the two, not kwin-x11.

plasma-workspace-x11 contains the session .desktop file and the startplasma-
x11 executable. kwin-x11 contains the kwin_x11 executable which is run (and 
hence required) by startplasma-x11.

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

Re: Redis will no longer be OSS... now what?

Kevin Kofler via devel wrote:
> Can Microsoft Garnet be a solution?
> https://www.microsoft.com/en-us/research/blog/introducing-garnet-an-open-source-next-generation-faster-cache-store-for-accelerating-applications-and-services/
> https://microsoft.github.io/garnet/
> https://github.com/microsoft/garnet/tree/main
>  
> Released under the MIT license (since 2 days ago) and claims that "Garnet
> can work with existing Redis clients." And the benchmark results they post
> outperforms all 3 of Redis (soon to become proprietary), KeyDB, and
> DragonflyDB (already proprietary from the outstart).

Though, Microsoft being Microsoft, they wrote that thing in C#, so it drags 
in the dotnet stack. But at least they did test on GNU/Linux:
https://microsoft.github.io/garnet/docs/getting-started#build-the-project
"You can use either Linux or Windows; Garnet works equally well on both 
platforms."

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

Re: Redis will no longer be OSS... now what?

Neal Gompa wrote:
> It looks like Redis, Inc. has announced that future versions of Redis
> are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a
> fork of Redis coming up, we will likely need to remove Redis from
> Fedora.
> 
> All I can say is... :(

Can Microsoft Garnet be a solution?
https://www.microsoft.com/en-us/research/blog/introducing-garnet-an-open-source-next-generation-faster-cache-store-for-accelerating-applications-and-services/
https://microsoft.github.io/garnet/
https://github.com/microsoft/garnet/tree/main

Released under the MIT license (since 2 days ago) and claims that "Garnet 
can work with existing Redis clients." And the benchmark results they post 
outperforms all 3 of Redis (soon to become proprietary), KeyDB, and 
DragonflyDB (already proprietary from the outstart).

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

Re: Redis will no longer be OSS... now what?

2024-03-20 Thread Richard Fontana

On Wed, Mar 20, 2024 at 6:21 PM Neal Gompa  wrote:
>
> It looks like Redis, Inc. has announced that future versions of Redis
> are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a
> fork of Redis coming up, we will likely need to remove Redis from
> Fedora.

This is quite unfortunate.

We haven't encountered RSAL(v2) before in Fedora AFAIK but I've just
reviewed it and concluded (easily) it should be classified it as
*not-allowed*.
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/497

SSPL of course is already classified as *not-allowed*.

Richard
--
___
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: Change Compose Settings (system-wide)

Aoife Moloney wrote:
> The zstd compression type was chosen to match createrepo_c settings.
> As an alternative, we might want to choose xz,

Since xz consistently compresses better than zstd, I would strongly suggest 
using xz everywhere to minimize download sizes. However:

> especially after zlib-ng has been made the default in Fedora and brought
> performance improvements.

zlib-ng is for gz, not xz, and gz is fast, but compresses extremely poorly 
(which is mostly due to the format, so, while some implementations manage to 
do better than others at the expense of more compression time, there is a 
limit to how well they can do and it is nowhere near xz or even zstd) and 
should hence never be used at all.

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

[Test-Announce] Fedora 40 Candidate Beta-1.10 Available Now!

2024-03-20 Thread rawhide

According to [the schedule][1], Fedora 40 Candidate Beta-1.10 is now
available for testing. Please help us complete all the validation
testing! For more information on 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/40

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_40_Beta_1.10_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.10_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.10_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.10_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.10_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.10_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.10_Security_Lab

All Beta priority test cases for each of these [test pages][2] must
pass in order to meet the [Beta Release Criteria][3].

Help is available on [the Fedora Quality chat channel][4], [the Fedora
Quality tag on Discourse][5], or on [the test list][6].

Current Blocker and Freeze Exception bugs:
 https://qa.fedoraproject.org/blockerbugs/current

[1]: https://fedorapeople.org/groups/schedule/f-40/f-40-quality-tasks.html
[2]: https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3]: https://fedoraproject.org/wiki/Fedora_40_Beta_Release_Criteria
[4]: 
https://matrix.to/#/#quality:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org
[5]: https://discussion.fedoraproject.org/tags/c/project/7/quality-team
[6]: https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
--
___
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

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

2024-03-20 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-a08edbaebf   
amavis-2.12.3-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-27eced8f48   
tcpreplay-4.4.4-5.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-5253d48b14   
w3m-0.5.3-63.git20230121.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-6e2c9aa156   
chromium-122.0.6261.128-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-1c85d457ef   
perl-Data-UUID-1.227-1.el7


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

csmock-3.5.3-1.el7
nagios-plugins-2.4.8-2.el7

Details about builds:



 csmock-3.5.3-1.el7 (FEDORA-EPEL-2024-346421d49b)
 A mock wrapper for Static Analysis tools

Update Information:

update to latest upstream (fixes CVE-2024-2243)

ChangeLog:

* Wed Mar 20 2024 Kamil Dudka  3.5.3-1
- update to latest upstream (fixes CVE-2024-2243)

References:

  [ 1 ] Bug #2270495 - TRIAGE CVE-2024-2243 csmock: command injection 
vulnerability in csmock-plugin-snyk [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2270495
  [ 2 ] Bug #2270496 - TRIAGE CVE-2024-2243 csmock: command injection 
vulnerability in csmock-plugin-snyk [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2270496




 nagios-plugins-2.4.8-2.el7 (FEDORA-EPEL-2024-113ba5a084)
 Host/service/network monitoring program plugins for Nagios

Update Information:

Remove ssl_validity because package perl-Crypt-X509 is not available
It was mistakenly readded some time ago

ChangeLog:

* Wed Mar 20 2024 Guido Aulisi  - 2.4.8-2
- Remove ssl_validity because package perl-Crypt-X509 is not available
- Fix #2270251 #2270252 #2270329

References:

  [ 1 ] Bug #2270251 - nagios-plugins-ssl_validity-2.4.8-1.el7.x86_64 requires 
non-existent perl-Crypt-X509 package
https://bugzilla.redhat.com/show_bug.cgi?id=2270251
  [ 2 ] Bug #2270252 - 2.4.8 update broken in epel 7
https://bugzilla.redhat.com/show_bug.cgi?id=2270252
  [ 3 ] Bug #2270329 - yum update broken due to nagios-plugins-ssl_validity in 
EPEL7
https://bugzilla.redhat.com/show_bug.cgi?id=2270329


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

Re: Redis will no longer be OSS... now what?

2024-03-20 Thread Aaron Rainbolt


On 3/20/24 20:40, Jonathan Wright via devel wrote:
Is this all a misunderstanding? 
https://redis.com/blog/redis-labs-modules-license-changes/ seems to 
claim that redis-core which appears to cover redis-server and 
redis-sentinel will remain BSD-3.
That was a bit over five years ago. This was a change to Redis itself, 
not the modules. 
https://github.com/redis/redis/blob/unstable/LICENSE.txt The words "This 
change has zero effect on the Redis core license, which is and will 
always be licensed under the 3-Clause-BSD." have officially proven to be 
a lie.


On Wed, Mar 20, 2024 at 7:38 PM Jonathan Wright 
 wrote:


DragonflyDB is not an option, they do not use an OSI-approved
license.  I reached out to them a couple of years ago to see if
they would swap to one and they said they don't have an interest
in it.

On Wed, Mar 20, 2024 at 7:13 PM Aaron Rainbolt
 wrote:

On 3/20/24 17:19, Neal Gompa wrote:

Hey everyone,

It looks like Redis, Inc. has announced that future versions of Redis
are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a
fork of Redis coming up, we will likely need to remove Redis from
Fedora.

All I can say is... :(

[1]:https://redis.com/blog/redis-adopts-dual-source-available-licensing/

In addition to KeyDB, there's also DragonflyDB:
https://github.com/dragonflydb/dragonfly I mentioned Redis
going source-available to the KDE devs and one of them linked
this.

-- 
Aaron Rainbolt

Lubuntu Developer
Matrix: @arraybolt3:matrix.org  
IRC: arraybolt3 on irc.libera.chat
GitHub:https://github.com/ArrayBolt3

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



-- 
Jonathan Wright

AlmaLinux Foundation
Mattermost: chat




--
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 

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


--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub:https://github.com/ArrayBolt3
--
___
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: Redis will no longer be OSS... now what?

Is this all a misunderstanding?
https://redis.com/blog/redis-labs-modules-license-changes/ seems to claim
that redis-core which appears to cover redis-server and redis-sentinel will
remain BSD-3.

On Wed, Mar 20, 2024 at 7:38 PM Jonathan Wright 
wrote:

> DragonflyDB is not an option, they do not use an OSI-approved license.  I
> reached out to them a couple of years ago to see if they would swap to one
> and they said they don't have an interest in it.
>
> On Wed, Mar 20, 2024 at 7:13 PM Aaron Rainbolt 
> wrote:
>
>> On 3/20/24 17:19, Neal Gompa wrote:
>>
>> Hey everyone,
>>
>> It looks like Redis, Inc. has announced that future versions of Redis
>> are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a
>> fork of Redis coming up, we will likely need to remove Redis from
>> Fedora.
>>
>> All I can say is... :(
>>
>> [1]: https://redis.com/blog/redis-adopts-dual-source-available-licensing/
>>
>> In addition to KeyDB, there's also DragonflyDB:
>> https://github.com/dragonflydb/dragonfly I mentioned Redis going
>> source-available to the KDE devs and one of them linked this.
>>
>> --
>> Aaron Rainbolt
>> Lubuntu Developer
>> Matrix: @arraybolt3:matrix.org
>> IRC: arraybolt3 on irc.libera.chat
>> GitHub: https://github.com/ArrayBolt3
>>
>> --
>> ___
>> 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
>>
>
>
> --
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat 
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
--
___
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: Redis will no longer be OSS... now what?

DragonflyDB is not an option, they do not use an OSI-approved license.  I
reached out to them a couple of years ago to see if they would swap to one
and they said they don't have an interest in it.

On Wed, Mar 20, 2024 at 7:13 PM Aaron Rainbolt  wrote:

> On 3/20/24 17:19, Neal Gompa wrote:
>
> Hey everyone,
>
> It looks like Redis, Inc. has announced that future versions of Redis
> are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a
> fork of Redis coming up, we will likely need to remove Redis from
> Fedora.
>
> All I can say is... :(
>
> [1]: https://redis.com/blog/redis-adopts-dual-source-available-licensing/
>
> In addition to KeyDB, there's also DragonflyDB:
> https://github.com/dragonflydb/dragonfly I mentioned Redis going
> source-available to the KDE devs and one of them linked this.
>
> --
> Aaron Rainbolt
> Lubuntu Developer
> Matrix: @arraybolt3:matrix.org
> IRC: arraybolt3 on irc.libera.chat
> GitHub: https://github.com/ArrayBolt3
>
> --
> ___
> 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
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
--
___
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: Redis will no longer be OSS... now what?

2024-03-20 Thread Aaron Rainbolt


On 3/20/24 19:23, Neal Gompa wrote:

On Wed, Mar 20, 2024 at 8:13 PM Aaron Rainbolt  wrote:

On 3/20/24 17:19, Neal Gompa wrote:

Hey everyone,

It looks like Redis, Inc. has announced that future versions of Redis
are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a
fork of Redis coming up, we will likely need to remove Redis from
Fedora.

All I can say is... :(

[1]: https://redis.com/blog/redis-adopts-dual-source-available-licensing/

In addition to KeyDB, there's also DragonflyDB: 
https://github.com/dragonflydb/dragonfly I mentioned Redis going 
source-available to the KDE devs and one of them linked this.

DragonFlyDB is not an open source database. It uses the BuSL license.
Gosh... sigh. You're right. I saw it was on GitHub and assumed it was 
FOSS. My mistake.


--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub: https://github.com/ArrayBolt3
--
___
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: Redis will no longer be OSS... now what?

On Wed, Mar 20, 2024 at 8:13 PM Aaron Rainbolt  wrote:
>
> On 3/20/24 17:19, Neal Gompa wrote:
>
> Hey everyone,
>
> It looks like Redis, Inc. has announced that future versions of Redis
> are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a
> fork of Redis coming up, we will likely need to remove Redis from
> Fedora.
>
> All I can say is... :(
>
> [1]: https://redis.com/blog/redis-adopts-dual-source-available-licensing/
>
> In addition to KeyDB, there's also DragonflyDB: 
> https://github.com/dragonflydb/dragonfly I mentioned Redis going 
> source-available to the KDE devs and one of them linked this.

DragonFlyDB is not an open source database. It uses the BuSL license.



-- 
真実はいつも一つ！/ 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: Redis will no longer be OSS... now what?

2024-03-20 Thread Aaron Rainbolt


On 3/20/24 17:19, Neal Gompa wrote:

Hey everyone,

It looks like Redis, Inc. has announced that future versions of Redis
are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a
fork of Redis coming up, we will likely need to remove Redis from
Fedora.

All I can say is... :(

[1]:https://redis.com/blog/redis-adopts-dual-source-available-licensing/
In addition to KeyDB, there's also DragonflyDB: 
https://github.com/dragonflydb/dragonfly I mentioned Redis going 
source-available to the KDE devs and one of them linked this.


--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub:https://github.com/ArrayBolt3
--
___
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: Redis will no longer be OSS... now what?

Looking back at my work on KeyDB, it's basically ready for package review
once we do some de-vendoring work.  I was hoping upstream would do it but
over a year and they haven't, so I guess I'll try to tackle it and PR it
back to them.

https://github.com/Snapchat/KeyDB/issues/493

On Wed, Mar 20, 2024 at 5:29 PM Neal Gompa  wrote:

> On Wed, Mar 20, 2024 at 6:26 PM Jonathan Wright via devel
>  wrote:
> >
> > We can potentially look to https://github.com/Snapchat/KeyDB which I've
> been loosely working on packaging anyway.
> >
>
> I'll want to test this for Pagure at least, since we're going to have
> to switch our recommendations around soon because of this.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
--
___
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

REMINDER: Fedora Linux 40 Beta Go/No-Go Meeting Tomorrow, March 21st

2024-03-20 Thread Aoife Moloney

Hi folks,

A quick reminder that the Fedora Linux 40 Beta Go/No-Go meeting[1]
will be held at 1700 UTC on Thursday 21st March in
#meeting:fedoraproject.org on Matrix.

More information about the Go/No-Go meeting can be found on the wiki[2].


[1] https://calendar.fedoraproject.org/meeting/10764/
[2] https://fedoraproject.org/wiki/Go_No_Go_Meeting

-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Test-Announce] REMINDER: Fedora Linux 40 Beta Go/No-Go Meeting Tomorrow, March 21st

2024-03-20 Thread Aoife Moloney

Hi folks,

A quick reminder that the Fedora Linux 40 Beta Go/No-Go meeting[1]
will be held at 1700 UTC on Thursday 21st March in
#meeting:fedoraproject.org on Matrix.

More information about the Go/No-Go meeting can be found on the wiki[2].


[1] https://calendar.fedoraproject.org/meeting/10764/
[2] https://fedoraproject.org/wiki/Go_No_Go_Meeting

-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
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: Redis will no longer be OSS... now what?

On Wed, Mar 20, 2024 at 6:26 PM Jonathan Wright via devel
 wrote:
>
> We can potentially look to https://github.com/Snapchat/KeyDB which I've been 
> loosely working on packaging anyway.
>

I'll want to test this for Pagure at least, since we're going to have
to switch our recommendations around soon because of this.



-- 
真実はいつも一つ！/ 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: Redis will no longer be OSS... now what?

We can potentially look to https://github.com/Snapchat/KeyDB which I've
been loosely working on packaging anyway.

On Wed, Mar 20, 2024 at 5:21 PM Neal Gompa  wrote:

> Hey everyone,
>
> It looks like Redis, Inc. has announced that future versions of Redis
> are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a
> fork of Redis coming up, we will likely need to remove Redis from
> Fedora.
>
> All I can say is... :(
>
> [1]: https://redis.com/blog/redis-adopts-dual-source-available-licensing/
>
> --
> 真実はいつも一つ！/ 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
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
--
___
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

Redis will no longer be OSS... now what?

Hey everyone,

It looks like Redis, Inc. has announced that future versions of Redis
are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a
fork of Redis coming up, we will likely need to remove Redis from
Fedora.

All I can say is... :(

[1]: https://redis.com/blog/redis-adopts-dual-source-available-licensing/

-- 
真実はいつも一つ！/ 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: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

On Wed, Mar 20, 2024 at 07:15:56PM +0100, Clemens Lang wrote:
> Hi,
> 
> > On 20. Mar 2024, at 18:11, Joe Orton  wrote:
> > 
> > On Wed, Mar 20, 2024 at 02:05:52PM +, Daniel Berrange wrote:
> >> Another alternative is to continue providing fully functional engine
> >> symbols, but remove the header files so in practice you can't compile
> >> something new that uses it. This is still forking the API, but at least
> >> has not forked the ELF ABI, so the upgrade doesn't explode.
> > 
> > This is a really good idea, I hope Daniel's comment is not lost here.
> 
> It isn’t, we are very much aware of this possibility and have already 
> discussed it before.
> 
> The ENGINE API is a source of subtle bugs especially when used together with 
> providers, though, so we would really prefer to disable it completely rather 
> than keeping it around. PKEY objects backed by an ENGINE use a number of 
> different lesser tested code paths in the OpenSSL source code, which lead to 
> all sorts of weird an inconsistent behavior.
> 
> 
> > On 20. Mar 2024, at 16:07, Zbigniew Jędrzejewski-Szmek  
> > wrote:
> > 
> > Sorry, but the idea to drop symbols without changing the SONAME
> > must be rejected. If upstream plans to drop the symbols for 4.0, then
> > that is OK, assuming that the SONAME is bumped then.
> 
> 
> This does already not match reality. OpenSSL provides a number of symbols 
> that are dependent on compile-time options. Take a look at [1, 2]. Every 
> symbol in there that is tagged with EXIST::FUNCTION followed by a string that 
> is not DEPRECATEDIN_3_0 is only present when the associated configure-time 
> option is enabled.
> 
> For example, an OpenSSL configured with no-des will not provide the 
> DES_xcbc_encrypt symbol. The assumption that one specific SOVERSION of 
> OpenSSL will always contain the same symbols on all operating systems is thus 
> incorrect. Obviously this is not a change that can be made during the 
> lifetime of a specific Fedora release, but ahead of a mass rebuild, it should 
> be doable to land a change such as this without changing the SONAME, 
> considering the problem you want to avoid with the SONAME bump *already* 
> exists between different builds of OpenSSL with different configuration.

I expect the following behaviour from Fedora (or any distro that
cares about stability for users):
- For a given SONAME, symbols are only ever added, never removed.
- Ideally, symbol versioning is used.
- ABI stability is also maintained for a given SONAME.
- If support for a given symbol needs to be removed, it can be replaced
  by a stub that is noop or returns an error, as appropriate.
  This approach was discussed earlier in the thread.
  (This can be useful e.g. for functions that implement some optional
   functionality and programs using those functions can still work
   even if those specific functions stop working. For example, a
   library that implements a bunch of compression methods, and one
   of them starts returning an error, and the programs will fall back
   to a different compression method, is a case where this could be
   useful.)
- SONAME changes happen only if absolutely necessary.

This means that if I compile a program against a library in Fedora,
it'll continue to function indefinitely, in the sense of the dynamic
linker loading the program without fuss.

If the SONAME changes, I'll need to either recompile or install the
older version of the library with the old SONAME. Dependent packages,
both from the distro and external, can use rpm dependencies to prevent
upgrades that'd break programs.

Obviously, the items in the list above are much easier if the library
upstream does the right things.

So please, don't ever change compilation options in Fedora in a way
that would cause symbols to disappear. Certainly not during one release.
But even doing this at a release boundary is bad.

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: Retiring Celestia from Fedora due to licensing issues

2024-03-20 Thread Ian Laurie


On 3/21/24 03:36, Mattia Verga via devel wrote:

I will be following the procedure for completely removing a package [3],
however there are a couple of things that I'd like to ask:


I think the Astronomy Labs version of Fedora ships with Celestia so
their group will needs a heads up.

--
Ian Laurie
FAS: nixuser | IRC: nixuser
TZ: Australia/Sydney
--
___
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: SPDX Statistics - Book Smugglers edition

2024-03-20 Thread Miroslav Suchý

Dne 20. 03. 24 v 15:20 Fabio Valentini napsal(a):

Migrating the License tag from Callaway to SPDX identifiers is only
the "easy" part of the transition.
Re-reviewing package contents and re-classifying licenses is the
non-trivial part, and that definitely can't be scripted.

*nod*

1) Trivial example: how would you convert "BSD" string?

2) During past few months I have seen lots of packages that changed their license to something else and only scancode
reports revealed that to them.

3) Lots of license had long discussion if they should be allowed and how. E.g KDE uses LicenseRef-KDE-Accepted-LGPL
which is valide SPDX id, but is not allowed in Fedora and you have to use "|LGPL-2.1-only OR LGPL-3.0-only"|

|4) And you probably missed that every 14 days I include something like "5-10 new license were identified and added (to
SPDX list and to fedora-license-data). For lots of months. That is huge work that AFAIK no one before ever done. Across
whole IT world.

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
--
___
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: Package conflict management advice

2024-03-20 Thread Iñaki Ucar

On Wed, 20 Mar 2024 at 19:37, Iñaki Ucar  wrote:

>
>
> On Tue, 19 Mar 2024 at 12:34, Michael J Gruber 
> wrote:
>
>> Am Di., 19. März 2024 um 11:53 Uhr schrieb Iñaki Ucar <
>> iu...@fedoraproject.org>:
>> >
>> > Dear all,
>> >
>> > I'm looking for options/advice here. See [1], and a bit of context:
>> >
>> > - RStudio (now Posit.co) publishes two packages named rstudio (with
>> RStudio Desktop) and rstudio-server (with RStudio Server). They are
>> independent and have many files in common. Recent versions are based on
>> Electron (for Desktop) and have Quarto support.
>> >
>> > - In Fedora, we decided to package all the common files in the rstudio
>> package, then build rstudio-desktop and rstudio-server for these products,
>> with just the specific files. In our build, we rely on QtWebEngine for the
>> Desktop version and disable Quarto, because it would be a nightmare to
>> package (requires Deno).
>> >
>> > Now the issue [1]: there's always been confusion among users that at
>> some point install the rstudio package provided by Posit (which provides
>> everything), many times because RStudio prompts that there's a new version
>> available and they just go click unknowingly. After some time, the package
>> manager "updates" it to our version when we hit stable, and RStudio Desktop
>> is gone (because rstudio-desktop is not present). Some time ago, I disabled
>> the "new version" notification dialog to mitigate this, but these days this
>> happens more and more frequently because users want Quarto and specifically
>> opt for the package provided by Posit.
>> >
>> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2270191
>> >
>> > What do you think is the best way to mitigate this? Options:
>> >
>> > 1. Keep things as they are, just tell the users to exclude the rstudio
>> package in the dnf configuration. Pros: no changes required. Cons: it's
>> clear that users don't know how to do this. And more documentation rarely
>> solves this kind of problem.
>> >
>> > 2. Make rstudio Requires rstudio-desktop. Pros: When the package
>> manager updates to our version, at least there's a working version of
>> RStudio installed. Cons: Server users shouldn't need Desktop installed.
>> Still confusing to users.
>> >
>> > 3. Rename rstudio as rstudio-common, keep rstudio as a metapackage that
>> just Requires rstudio-desktop. Pros: Same as before + Server doesn't need
>> Desktop. Cons: Still confusing to users.
>> >
>> > 4. Rename rstudio as rstudio-common, make this one Conflicts rstudio.
>> Pros: You either install rstudio from Posit, or rstudio-desktop from
>> Fedora. And I'm not sure about this, but does installing one remove the
>> other? Or does dnf at least show the conflict and the user decides? Cons:
>> `dnf install rstudio` doesn't work anymore, so it's less discoverable. And
>> we have a similar issue with rstudio-server anyways that cannot be easily
>> solved. But I suppose that admins installing rstudio-server know how to
>> prevent package updates.
>> >
>> > 5. Introduce some version component that makes our package versions be
>> sorted < than Posit's. Pros: Upgrades never happen when a user opts for
>> packages provided by Posit. Cons: I don't know how to do this without
>> breaking our updates. Probably other issues?
>> >
>> > Any advice? Other options not considered here?
>>
>> Wow, contrived situation. I guess this shows again that packaging
>> should be left to packagers, not upstream :)
>>
>> 4. seems to be the only solution where "problematic but typical" user
>> behaviour leads to explicit conflicts rather than "funny" behaviour.
>> `dnf` will bail out and explain the conflicts ("cannot install both
>> ...") and even suggest to use "allow-erasing", which cleans things up.
>> dnf will not offer "rstudio" updates if there is no such package in
>> Fedora repos.
>>
>> Even in this case, one can only hope that users don't switch
>> inadvertently between "upstream" and Fedora. At least it requires
>> extra steps with 4 (though I don't now about pkgkit).
>>
>
> Thanks, Michael. Do you find option 5 unadvisable? Because a possible way
> I found is the following.
>
> Upstream versioning is year.month.day-build. Example: 2023.12.1-403. So
> they name their package rstudio-2023.12.1-403. In a way, the build
> identifier works as a release number for them. Our package is
> rstudio-2023.12.1+403-1, so the same version is always sorted > than theirs.
>
> What if, for the next release, I change the versioning scheme to e.g.
> rstudio-2024.04.01~500-1, which would always be sorted < than theirs? Our
> package will be updated nicely, but then, if a user manually installs their
> packages (rstudio or rstudio-server), they will never be updated by our
> packages. Any shortcomings I don't see?
>

I might even do both things. In a first iteration:

- rename rstudio -> rstudio-common
- add "Conflicts: rstudio" to rstudio-common

When a new version is released:

- change the version scheme to using ~ instead of +, so

Re: Retiring Celestia from Fedora due to licensing issues

2024-03-20 Thread Otto Liljalaakso

I do not have the answers to your questions, but when figure out how to 
properly do this, please submit an update for the docs. That section has always 
looked very suspect to me.

20. maaliskuuta 2024 18.36.02 GMT+02:00 Mattia Verga via devel 
 kirjoitti:
>After I requested [1] Celestia project upstream to better define 
>licensing of all the textures and 3d models included in upstream data, 
>it turned out that at least some content is licensed CC-BY-NC-SA-3.0 [2] 
>which is not permitted in Fedora.
>
>Upstream is still working on specify exactly the licenses of each file 
>and, maybe, in future will replace the problematic content with FOSS 
>textures. However, since there's no ETA for those tasks and the main 
>program cannot work by simply stripping out the problematic content, I 
>am forced to retire Celestia from Fedora.
>
>I will be following the procedure for completely removing a package [3], 
>however there are a couple of things that I'd like to ask:
>
>- should I wait for the flatpak maintainer to retire the flatpaks 
>(celestia-gtk and celestia-qt) before retiring the RPMs (celestia and 
>celestia-content)?
>- do I need to ask releng to purge celestia sources from the lookaside 
>cache as well?
>-do the flatpaks need to be added to fedora-obsolete-packages (or 
>something similar for flatpaks)?
>
>Thanks
>Mattia
>
>[1] https://github.com/CelestiaProject/CelestiaContent/issues/138
>[2] https://github.com/CelestiaProject/CelestiaContent/issues/147
>[3] 
>https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#complete_removal
>
>--
>___
>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
--
___
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: Package conflict management advice

2024-03-20 Thread Iñaki Ucar

On Tue, 19 Mar 2024 at 12:34, Michael J Gruber 
wrote:

> Am Di., 19. März 2024 um 11:53 Uhr schrieb Iñaki Ucar <
> iu...@fedoraproject.org>:
> >
> > Dear all,
> >
> > I'm looking for options/advice here. See [1], and a bit of context:
> >
> > - RStudio (now Posit.co) publishes two packages named rstudio (with
> RStudio Desktop) and rstudio-server (with RStudio Server). They are
> independent and have many files in common. Recent versions are based on
> Electron (for Desktop) and have Quarto support.
> >
> > - In Fedora, we decided to package all the common files in the rstudio
> package, then build rstudio-desktop and rstudio-server for these products,
> with just the specific files. In our build, we rely on QtWebEngine for the
> Desktop version and disable Quarto, because it would be a nightmare to
> package (requires Deno).
> >
> > Now the issue [1]: there's always been confusion among users that at
> some point install the rstudio package provided by Posit (which provides
> everything), many times because RStudio prompts that there's a new version
> available and they just go click unknowingly. After some time, the package
> manager "updates" it to our version when we hit stable, and RStudio Desktop
> is gone (because rstudio-desktop is not present). Some time ago, I disabled
> the "new version" notification dialog to mitigate this, but these days this
> happens more and more frequently because users want Quarto and specifically
> opt for the package provided by Posit.
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2270191
> >
> > What do you think is the best way to mitigate this? Options:
> >
> > 1. Keep things as they are, just tell the users to exclude the rstudio
> package in the dnf configuration. Pros: no changes required. Cons: it's
> clear that users don't know how to do this. And more documentation rarely
> solves this kind of problem.
> >
> > 2. Make rstudio Requires rstudio-desktop. Pros: When the package manager
> updates to our version, at least there's a working version of RStudio
> installed. Cons: Server users shouldn't need Desktop installed. Still
> confusing to users.
> >
> > 3. Rename rstudio as rstudio-common, keep rstudio as a metapackage that
> just Requires rstudio-desktop. Pros: Same as before + Server doesn't need
> Desktop. Cons: Still confusing to users.
> >
> > 4. Rename rstudio as rstudio-common, make this one Conflicts rstudio.
> Pros: You either install rstudio from Posit, or rstudio-desktop from
> Fedora. And I'm not sure about this, but does installing one remove the
> other? Or does dnf at least show the conflict and the user decides? Cons:
> `dnf install rstudio` doesn't work anymore, so it's less discoverable. And
> we have a similar issue with rstudio-server anyways that cannot be easily
> solved. But I suppose that admins installing rstudio-server know how to
> prevent package updates.
> >
> > 5. Introduce some version component that makes our package versions be
> sorted < than Posit's. Pros: Upgrades never happen when a user opts for
> packages provided by Posit. Cons: I don't know how to do this without
> breaking our updates. Probably other issues?
> >
> > Any advice? Other options not considered here?
>
> Wow, contrived situation. I guess this shows again that packaging
> should be left to packagers, not upstream :)
>
> 4. seems to be the only solution where "problematic but typical" user
> behaviour leads to explicit conflicts rather than "funny" behaviour.
> `dnf` will bail out and explain the conflicts ("cannot install both
> ...") and even suggest to use "allow-erasing", which cleans things up.
> dnf will not offer "rstudio" updates if there is no such package in
> Fedora repos.
>
> Even in this case, one can only hope that users don't switch
> inadvertently between "upstream" and Fedora. At least it requires
> extra steps with 4 (though I don't now about pkgkit).
>

Thanks, Michael. Do you find option 5 unadvisable? Because a possible way I
found is the following.

Upstream versioning is year.month.day-build. Example: 2023.12.1-403. So
they name their package rstudio-2023.12.1-403. In a way, the build
identifier works as a release number for them. Our package is
rstudio-2023.12.1+403-1, so the same version is always sorted > than theirs.

What if, for the next release, I change the versioning scheme to e.g.
rstudio-2024.04.01~500-1, which would always be sorted < than theirs? Our
package will be updated nicely, but then, if a user manually installs their
packages (rstudio or rstudio-server), they will never be updated by our
packages. Any shortcomings I don't see?

Best,
-- 
Iñaki Úcar
--
___
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: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

2024-03-20 Thread Clemens Lang

Hi,

> On 20. Mar 2024, at 18:11, Joe Orton  wrote:
> 
> On Wed, Mar 20, 2024 at 02:05:52PM +, Daniel Berrange wrote:
>> Another alternative is to continue providing fully functional engine
>> symbols, but remove the header files so in practice you can't compile
>> something new that uses it. This is still forking the API, but at least
>> has not forked the ELF ABI, so the upgrade doesn't explode.
> 
> This is a really good idea, I hope Daniel's comment is not lost here.

It isn’t, we are very much aware of this possibility and have already discussed 
it before.

The ENGINE API is a source of subtle bugs especially when used together with 
providers, though, so we would really prefer to disable it completely rather 
than keeping it around. PKEY objects backed by an ENGINE use a number of 
different lesser tested code paths in the OpenSSL source code, which lead to 
all sorts of weird an inconsistent behavior.

> On 20. Mar 2024, at 16:07, Zbigniew Jędrzejewski-Szmek  
> wrote:
> 
> Sorry, but the idea to drop symbols without changing the SONAME
> must be rejected. If upstream plans to drop the symbols for 4.0, then
> that is OK, assuming that the SONAME is bumped then.

This does already not match reality. OpenSSL provides a number of symbols that 
are dependent on compile-time options. Take a look at [1, 2]. Every symbol in 
there that is tagged with EXIST::FUNCTION followed by a string that is not 
DEPRECATEDIN_3_0 is only present when the associated configure-time option is 
enabled.

For example, an OpenSSL configured with no-des will not provide the 
DES_xcbc_encrypt symbol. The assumption that one specific SOVERSION of OpenSSL 
will always contain the same symbols on all operating systems is thus 
incorrect. Obviously this is not a change that can be made during the lifetime 
of a specific Fedora release, but ahead of a mass rebuild, it should be doable 
to land a change such as this without changing the SONAME, considering the 
problem you want to avoid with the SONAME bump *already* exists between 
different builds of OpenSSL with different configuration.

[1]: https://github.com/openssl/openssl/blob/master/util/libssl.num
[2]: https://github.com/openssl/openssl/blob/master/util/libcrypto.num

-- 
Clemens Lang
RHEL Crypto Team
Red Hat

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

Orphaned emacs-htmlize

2024-03-20 Thread Debarshi Ray via devel

Hello everybody,

I have orphaned the emacs-htmlize [1,2] package.

In its current state, the RPM doesn't work with any non-ancient version
of GNU Emacs.  This needs to be fixed by updating it to a non-ancient
upstream release of emacs-htmlize [3].  I haven't used it for more than
a decade, and don't have any time or motivation to give it the
attention that it needs.

Feel free to pick it up if you want to.

Cheers,
Rishi

[1] https://www.emacswiki.org/emacs/Htmlize
[2] https://src.fedoraproject.org/rpms/emacs-htmlize
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2270140
--
___
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: Disable openSSL Engine Support (system-wide)

2024-03-20 Thread Alexander Sosedkin

On Wed, Mar 20, 2024 at 6:52 PM Ali Erdinc Koroglu
 wrote:
>
>
>
> On 08/03/2024 22:37, Aoife Moloney wrote:
> > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine
> >
> > This is a proposed Change for Fedora Linux.
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> > == Summary ==
> > We disable support of engines in OpenSSL
> >
> > == Owner ==
> > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
> > * Email: dbely...@redhat.com
> >
> > == Detailed Description ==
> > We are going to build OpenSSL without engine support. Engines are not
> > FIPS compatible and corresponding API is deprecated since OpenSSL 3.0.
> > The engine functionality we are aware of (PKCS#11, TPM) is either
> > covered by providers or will be covered soon.
> >
> > == Feedback ==
> >
> >
> > == Benefit to Fedora ==
> > We get rid of deprecated functionality and enforce using up-to-date
> > API. Engine support is deprecated in OpenSSL upstream, and after
> > provider migration caused some deficiencies with engine support. No
> > new features will be added to the engine. So we reduce the maintenance
> > burden and potentially attack surface.
> >
> > It follows the approach planned for CentOS 10.
>
> Hi,
> We're providing the Intel QuickAssist Technology OpenSSL Engine (QAT_Engine)* 
> in Fedora and RHEL.
> I think we shouldn't rush things to have no-engine environment.
>
> * : 
> https://www.redhat.com/en/blog/accelerated-encryption-4th-gen-intelr-xeonr-scalable-processors

QAT can be built with --enable-qat_provider:
https://github.com/intel/QAT_Engine/blob/1d248f28a10123f3a681b9910283d6e66e3f7dc1/configure.ac#L173
--
___
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

[Bug 2270521] New: perl-Module-CoreList-5.20240320 is available

2024-03-20 Thread bugzilla

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

Bug ID: 2270521
   Summary: perl-Module-CoreList-5.20240320 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Module-CoreList
  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, spo...@gmail.com,
st...@silug.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 5.20240320
Upstream release that is considered latest: 5.20240320
Current version/release in rawhide: 5.20240223-1.fc41
URL: https://metacpan.org/dist/Module-CoreList/

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://docs.fedoraproject.org/en-US/package-maintainers/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/3080/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Module-CoreList


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2270521

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202270521%23c0
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

2024-03-20 Thread Ali Erdinc Koroglu

On 08/03/2024 22:37, Aoife Moloney wrote:

Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
We disable support of engines in OpenSSL

== Owner ==
* Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
* Email: dbely...@redhat.com

== Detailed Description ==
We are going to build OpenSSL without engine support. Engines are not
FIPS compatible and corresponding API is deprecated since OpenSSL 3.0.
The engine functionality we are aware of (PKCS#11, TPM) is either
covered by providers or will be covered soon.

== Feedback ==

== Benefit to Fedora ==
We get rid of deprecated functionality and enforce using up-to-date
API. Engine support is deprecated in OpenSSL upstream, and after
provider migration caused some deficiencies with engine support. No
new features will be added to the engine. So we reduce the maintenance
burden and potentially attack surface.

It follows the approach planned for CentOS 10.

Hi,
We're providing the Intel QuickAssist Technology OpenSSL Engine (QAT_Engine)*
in Fedora and RHEL.
I think we shouldn't rush things to have no-engine environment.

* :
https://www.redhat.com/en/blog/accelerated-encryption-4th-gen-intelr-xeonr-scalable-processors

--
Ali Erdinc Koroglu
Intel, SSE | Linux OS Systems Engineering
--
___
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: ld: error: triggering the generation of an executable stack

2024-03-20 Thread Jerry James

On Tue, Mar 19, 2024 at 6:28 PM Orion Poplawski  wrote:
> With a recent update, plplot is failing to build with:
>
> cd
> /builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/examples/fortran
> && /usr/bin/cmake -E cmake_link_script CMakeFiles/x16af.dir/link.txt
> --verbose=1
> /usr/bin/gfortran -Wl,-z,relro -Wl,--as-needed
> -Wl,-z,pack-relative-relocs -Wl,-z,now
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -O2
> -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
> -Wall -Wno-complain-wrong-lang -Werror=format-security
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
> -mno-omit-leaf-frame-pointer -frecursive
> CMakeFiles/x16af.dir/x16af.f90.o -o x16af
> -Wl,-rpath,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/bindings/fortran:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime
> ../libplfortrandemolib.a
> ../../bindings/fortran/libplplotfortran.so.0.2.0
> -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime
> /usr/bin/ld: error: /tmp/cchkMGCX.ltrans0.ltrans.o: is triggering the
> generation of an executable stack (because it has an executable
> .note.GNU-stack section)
> /usr/bin/ld: failed to set dynamic section sizes: No such file or directory
>
> I have no idea what is up here.
>
> Seems to have started with:
>
> gcc 14.0.1-0.7.fc41
> glibc 2.39.9000-3.fc41
> util-linux 2.40-0.9.rc1.fc41
> binutils 2.42.50-4.fc41
>
> and lots of others, but that seems the most likely.

At least one of the Fortran example programs (x09f) really does
require an executable stack.  This PR will work around the build issue
for now, but the reason why it requires an executable stack should be
investigated:

https://src.fedoraproject.org/rpms/plplot/pull-request/6

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

Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

2024-03-20 Thread Joe Orton

On Wed, Mar 20, 2024 at 02:05:52PM +, Daniel Berrange wrote:
> Another alternative is to continue providing fully functional engine
> symbols, but remove the header files so in practice you can't compile
> something new that uses it. This is still forking the API, but at least
> has not forked the ELF ABI, so the upgrade doesn't explode.

This is a really good idea, I hope Daniel's comment is not lost here.

In fact no need to remove the header files - adding the required:

#define OPENSSL_NO_ENGINE 

into  will make the OpenSSL API act as 
if it was built with the no-engine option - this would not be an API 
fork since it's one of many configurations supported upstream.

It will have the desired effect of disabling ENGINE support across most 
of Fedora in the next mass-rebuild. Or at least we can easily track down 
the places where the detection isn't perfect, they will break at compile 
time.

Regards, Joe
--
___
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: Default NodeJS stream packages with versioned names are not available

2024-03-20 Thread Stephen Gallagher

On Wed, Mar 20, 2024 at 12:35 PM Jan Staněk  wrote:
>
> Hello all,
> recently, when trying to spin up a CI for NodeJS in Fedora, I ran into a
> slight problem: when a NodeJS stream is the default one, versioned
> packages (i.e. nodejs20) are not generated and are not installable.
>
> For example, on current rawhide, I cannot install `nodejs20` package,
> only `nodejs`; this will give me the version 20.x as expected.
> The problem is that this complicates the CI setup,
> and requires me to take into account which Fedora I'm currently on.
>
> As an example, when adding tests for nodejs20 dist-git[1],
> I would like to simply specify `requires: nodejs20` into the test
> metadata. However, with the current setup, I would need something akin
> to the following (pseudocode, I did not really test if that would work):
>
> requires:
> - {% if fedora == 40 %}nodejs{% else %}nodejs20{% fi %}
>
> In addition to being more complicated, this will also break if the
> default stream for a given Fedora version ever change
> (which is not unlikely to happen, as the upstream release schedule
> is not really synchronized with the Fedore one).
>

The default version is fixed for the life of each Fedora release. It
works out fine, because we always use whichever is the most recent LTS
release that will be supported through the life of that Fedora
release.

That said, I agree that it's completely reasonable to have the default
version also `Provides: nodejsXX` and I'll look into it.


> ---
>
> I recall that the current status is the result of already existing
> long discussion, with associated debugging, so I would like to have this
> solved with as minimal disruption as possible. That being said,
> what is the reason for having the non-versioned packages (`nodejs`) *in
> stead* of the versioned ones (`nodejs20`), as opposed to *in addition*
> to them?

I'm confused; it *is* in addition to the versioned ones. We just don't
duplicate the default version because it would be a complete waste.

> The non-versioned packages could then require the appropriate versioned
> ones and contain only symlinks (/usr/bin/node → /usr/bin/node-20,
> /usr/lib/node_modules → /usr/lib/node_modules_20, etc.).

The overly-simplified answer here is mainly that there are too many
symlinks to maintain for this to be practical.
--
___
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

[Bug 2270514] New: perl-CPAN-Perl-Releases-5.20240321 is available

2024-03-20 Thread bugzilla

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

Bug ID: 2270514
   Summary: perl-CPAN-Perl-Releases-5.20240321 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-CPAN-Perl-Releases
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
mspa...@redhat.com, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 5.20240321
Upstream release that is considered latest: 5.20240321
Current version/release in rawhide: 5.20240223-1.fc41
URL: https://metacpan.org/dist/CPAN-Perl-Releases/

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://docs.fedoraproject.org/en-US/package-maintainers/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/5881/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-CPAN-Perl-Releases


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2270514

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202270514%23c0
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Test-Announce] Invitation to Contribute to Fedora Test Days: Podman Desktop Testing

2024-03-20 Thread Adam Williamson

On Wed, 2024-03-20 at 23:33 +1100, Philip Rhoades via devel wrote:
> People,
> 
> I am happy to do some testing but what is "Podman Desktop"? - I don't 
> see anything like that to install "dnf list" . . I have been on F40 for 
> a while now and am a regular user of Podman.

It's a GUI for Podman, basically. https://podman-desktop.io/ . That
page and the test cases for the test day should have more info on how
to install and test it. The point of the test day is to make sure
Podman Desktop, installed on Fedora in a recommended way, is working
well with all the underlying bits in Fedora (podman itself and the
things it depends on).
-- 
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: Default NodeJS stream packages with versioned names are not available

2024-03-20 Thread Miro Hrončok


On 20. 03. 24 17:35, Jan Staněk wrote:

Hello all,
recently, when trying to spin up a CI for NodeJS in Fedora, I ran into a
slight problem: when a NodeJS stream is the default one, versioned
packages (i.e. nodejs20) are not generated and are not installable.

For example, on current rawhide, I cannot install `nodejs20` package,
only `nodejs`; this will give me the version 20.x as expected.
The problem is that this complicates the CI setup,
and requires me to take into account which Fedora I'm currently on.

As an example, when adding tests for nodejs20 dist-git[1],
I would like to simply specify `requires: nodejs20` into the test
metadata. However, with the current setup, I would need something akin
to the following (pseudocode, I did not really test if that would work):

 requires:
 - {% if fedora == 40 %}nodejs{% else %}nodejs20{% fi %}

In addition to being more complicated, this will also break if the
default stream for a given Fedora version ever change
(which is not unlikely to happen, as the upstream release schedule
is not really synchronized with the Fedore one).

---

I recall that the current status is the result of already existing
long discussion, with associated debugging, so I would like to have this
solved with as minimal disruption as possible. That being said,
what is the reason for having the non-versioned packages (`nodejs`) *in
stead* of the versioned ones (`nodejs20`), as opposed to *in addition*
to them?

The non-versioned packages could then require the appropriate versioned
ones and contain only symlinks (/usr/bin/node → /usr/bin/node-20,
/usr/lib/node_modules → /usr/lib/node_modules_20, etc.).


Python does this similarly to nodejs (we have python3.11, pytohn3, python3.13 
in rawhide today), with one difference. The python3 package provides 
python3.12. So when you do:


 requires:
 - python3.12

It just works.

I believe nodejs should provide nodejs20, the same way.

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

Retiring Celestia from Fedora due to licensing issues

2024-03-20 Thread Mattia Verga via devel

After I requested [1] Celestia project upstream to better define 
licensing of all the textures and 3d models included in upstream data, 
it turned out that at least some content is licensed CC-BY-NC-SA-3.0 [2] 
which is not permitted in Fedora.

Upstream is still working on specify exactly the licenses of each file 
and, maybe, in future will replace the problematic content with FOSS 
textures. However, since there's no ETA for those tasks and the main 
program cannot work by simply stripping out the problematic content, I 
am forced to retire Celestia from Fedora.

I will be following the procedure for completely removing a package [3], 
however there are a couple of things that I'd like to ask:

- should I wait for the flatpak maintainer to retire the flatpaks 
(celestia-gtk and celestia-qt) before retiring the RPMs (celestia and 
celestia-content)?
- do I need to ask releng to purge celestia sources from the lookaside 
cache as well?
-do the flatpaks need to be added to fedora-obsolete-packages (or 
something similar for flatpaks)?

Thanks
Mattia

[1] https://github.com/CelestiaProject/CelestiaContent/issues/138
[2] https://github.com/CelestiaProject/CelestiaContent/issues/147
[3] 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#complete_removal

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

Default NodeJS stream packages with versioned names are not available

2024-03-20 Thread Jan Staněk

Hello all,
recently, when trying to spin up a CI for NodeJS in Fedora, I ran into a
slight problem: when a NodeJS stream is the default one, versioned
packages (i.e. nodejs20) are not generated and are not installable.

For example, on current rawhide, I cannot install `nodejs20` package,
only `nodejs`; this will give me the version 20.x as expected.
The problem is that this complicates the CI setup,
and requires me to take into account which Fedora I'm currently on.

As an example, when adding tests for nodejs20 dist-git[1],
I would like to simply specify `requires: nodejs20` into the test
metadata. However, with the current setup, I would need something akin
to the following (pseudocode, I did not really test if that would work):

requires:
- {% if fedora == 40 %}nodejs{% else %}nodejs20{% fi %}

In addition to being more complicated, this will also break if the
default stream for a given Fedora version ever change
(which is not unlikely to happen, as the upstream release schedule
is not really synchronized with the Fedore one).

---

I recall that the current status is the result of already existing
long discussion, with associated debugging, so I would like to have this
solved with as minimal disruption as possible. That being said,
what is the reason for having the non-versioned packages (`nodejs`) *in
stead* of the versioned ones (`nodejs20`), as opposed to *in addition*
to them?

The non-versioned packages could then require the appropriate versioned
ones and contain only symlinks (/usr/bin/node → /usr/bin/node-20,
/usr/lib/node_modules → /usr/lib/node_modules_20, etc.).

Let me know what you think!
Best regards,
--
Jan Staněk
Software Engineer, Red Hat
jsta...@redhat.com   irc: jstanek


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

Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

On Wed, Mar 20, 2024 at 11:24 AM Daniel P. Berrangé  wrote:
>
> On Wed, Mar 20, 2024 at 03:27:34PM +0100, Petr Pisar wrote:
> > V Wed, Mar 20, 2024 at 02:05:52PM +, Daniel P. Berrangé napsal(a):
> > > Consider you've built your own app on Fedora 39 that uses these
> > > symbols, and now upgrade to F40. RPM will consider the dependency
> > > still satisfied, as the SONAME hasn't changed on libcrypto. The
> > > app throws linker errors at some point due to the missing symbols.
> > >
> > > Another alternative is to continue providing fully functional engine
> > > symbols, but remove the header files so in practice you can't compile
> > > something new that uses it. This is still forking the API, but at least
> > > has not forked the ELF ABI, so the upgrade doesn't explode.
> > >
> > Another option is remove the symbols, change soname, and rebuild reverse
> > dependencies.
>
> Changing soname is something I don't think distros should ever do. ELF
> soname designation belongs to the upstream project maintainers.
>

I agree with this. It was a royal pain to get us to stop doing that
with OpenSSL 1.1, I don't want to go back to having to field bug
reports about broken OpenSSL sonames again.

While it is technically out of scope to discuss CentOS Stream 10 here,
I am not sure it is wise to drop the engines API there either. It will
result in tremendous problems for consumers and while deprecated,
OpenSSL 4.0 (which removes deprecated APIs) has no currently planned
release date: https://github.com/openssl/openssl/milestone/24

Even if we're being generous and saying it'll arrive in 3 years,
that's still far enough away that we're talking about Fedora 46 (!!)
and RHEL 11.

The amount of damage and breakage for third-parties by disabling
engine support is unconscionable, in my opinion.

From the Fedora perspective, I just see no reason to do this anytime soon.

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

Fedora 40 compose report: 20240320.n.0 changes

2024-03-20 Thread Fedora Branched Report

OLD: Fedora-40-20240319.n.0
NEW: Fedora-40-20240320.n.0

= SUMMARY =
Added images:4
Dropped images:  0
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 =
Image: Cloud_Base_UKI qcow2 x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-UEFI-UKI.x86_64-40-20240320.n.0.qcow2
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-40-20240320.n.0.iso
Image: LXQt live x86_64
Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-40-20240320.n.0.iso
Image: Cloud_Base_UKI qcow2 aarch64
Path: 
Cloud/aarch64/images/Fedora-Cloud-Base-UEFI-UKI.aarch64-40-20240320.n.0.qcow2

= DROPPED IMAGES =

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

Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

2024-03-20 Thread Daniel P . Berrangé

On Wed, Mar 20, 2024 at 03:27:34PM +0100, Petr Pisar wrote:
> V Wed, Mar 20, 2024 at 02:05:52PM +, Daniel P. Berrangé napsal(a):
> > Consider you've built your own app on Fedora 39 that uses these
> > symbols, and now upgrade to F40. RPM will consider the dependency
> > still satisfied, as the SONAME hasn't changed on libcrypto. The
> > app throws linker errors at some point due to the missing symbols.
> > 
> > Another alternative is to continue providing fully functional engine
> > symbols, but remove the header files so in practice you can't compile
> > something new that uses it. This is still forking the API, but at least
> > has not forked the ELF ABI, so the upgrade doesn't explode.
> > 
> Another option is remove the symbols, change soname, and rebuild reverse
> dependencies.

Changing soname is something I don't think distros should ever do. ELF
soname designation belongs to the upstream project maintainers.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
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: Disable openSSL Engine Support (system-wide)

On Wed, Mar 20, 2024 at 02:35:21PM +0100, Dmitry Belyavskiy wrote:
> > > == Benefit to Fedora ==
> > > We get rid of deprecated functionality and enforce using up-to-date
> > > API. Engine support is deprecated in OpenSSL upstream, and after
> > > provider migration caused some deficiencies with engine support. No
> > > new features will be added to the engine. So we reduce the maintenance
> > > burden and potentially attack surface.
> >
> > What is upstream's intention with the 'engine' feature deprecation ?
> >
> > Are they going actively remove this functionality after some
> > period of deprecation ? If so what's upstream timeframe, and
> > should Fedora just wait for that, rather than jumping the
> > gun ?
> >
> 
> As I understand, upstream is going to remove engines but it wouldn't happen
> before OpenSSL 4.0
> I don't think Fedora should wait for that. We definitely want to land
> no-engine in RHEL10 so Fedora should be ready for that.

Sorry, but the idea to drop symbols without changing the SONAME
must be rejected. If upstream plans to drop the symbols for 4.0, then
that is OK, assuming that the SONAME is bumped then.

We can try to rebuild distro packages, but we do not control everything
that is built by users. Removing symbols without bumping SONAME will
break user programs.

> > Should we not preserve the ENGINE_* symbols, but turn
> > their impl into either a no-op, or reporting a runtime
> > error, as appropriate for each API.
> 
> All 100+ symbols? I don't think providing non-working stubs would be a good
> idea...

If we were to do this, this would be the least bad option.
It's not that much work to generate a 100 stubs of the form
  ENGINE* ENGINE_by_id(const char*) { return NULL; }

But I don't think we should do the removal at all.

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: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

2024-03-20 Thread Gary Buhrmaster

On Wed, Mar 20, 2024 at 1:36 PM Dmitry Belyavskiy  wrote:

>
> As I understand, upstream is going to remove engines but it wouldn't happen 
> before OpenSSL 4.0
> I don't think Fedora should wait for that. We definitely want to land 
> no-engine in RHEL10 so Fedora should be ready for that.
>

What is the targeted time frame for release of OpenSSL 4.0?

Last I knew it was not soon(ish).  And (for Fedora), I would
expect for a number of years distros are likely going to
have to ship both openssl 3.x and openssl 4.x libraries for
compatibility (just as many still ship openssl 1.1), and
engine support may be a compatibility requirement.

I would think the OpenSSL 4.0 timeframe is when
engine support should be dropped (I believe the
3.x headers already warn about deprecation, and
people have the option to start porting code now,
although many are likely to not do so until it breaks).
--
___
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: Disable openSSL Engine Support (system-wide)

Dear Daniel,

On Wed, Mar 20, 2024 at 3:06 PM Daniel P. Berrangé 
wrote:

> On Wed, Mar 20, 2024 at 02:35:21PM +0100, Dmitry Belyavskiy wrote:
> > Dear Daniel,
> >
> > On Wed, Mar 20, 2024 at 1:44 PM Daniel P. Berrangé 
> > wrote:
> >
> > > On Fri, Mar 08, 2024 at 08:37:19PM +, Aoife Moloney wrote:
> > > > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine
> > > >
> > > > This is a proposed Change for Fedora Linux.
> > > > This document represents a proposed Change. As part of the Changes
> > > > process, proposals are publicly announced in order to receive
> > > > community feedback. This proposal will only be implemented if
> approved
> > > > by the Fedora Engineering Steering Committee.
> > > >
> > > > == Summary ==
> > > > We disable support of engines in OpenSSL
> > > >
> > > > == Owner ==
> > > > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
> > > > * Email: dbely...@redhat.com
> > > >
> > > > == Detailed Description ==
> > > > We are going to build OpenSSL without engine support. Engines are not
> > > > FIPS compatible and corresponding API is deprecated since OpenSSL
> 3.0.
> > > > The engine functionality we are aware of (PKCS#11, TPM) is either
> > > > covered by providers or will be covered soon.
> > >
> > > "will be covered soon"
> > >
> > > ... so lets wait until that work is actually complete before
> > > removing this from openssl, otherwise there's a window of
> > > brokenness in Fedora where the old feature is removed and
> > > the new feature is not ready.
> > >
> >
> > I am not going to land this change until the tpm2 provider is landed in
> > Fedora.
>
> Lets explicitly note that as a blocking /  pre-requisite dependency
> for landing this change then.
>

Fair point, will do.


> > > Removing symbols is an ABI break, so would imply the need for
> > > an SONAME version bump. This is not normally something that
> > > downstreams should ever touch though - it is an upstream
> > > decision when to bump their SONAME version.
> > >
> > > Should we not preserve the ENGINE_* symbols, but turn
> > > their impl into either a no-op, or reporting a runtime
> > > error, as appropriate for each API.
> > >
> >
> > All 100+ symbols? I don't think providing non-working stubs would be a
> good
> > idea...
>
> Intentionally forking the upstream ABI is worse IMHO.
>
> Consider you've built your own app on Fedora 39 that uses these
> symbols, and now upgrade to F40. RPM will consider the dependency
> still satisfied, as the SONAME hasn't changed on libcrypto. The
> app throws linker errors at some point due to the missing symbols.
>
> Another alternative is to continue providing fully functional engine
> symbols, but remove the header files so in practice you can't compile
> something new that uses it. This is still forking the API, but at least
> has not forked the ELF ABI, so the upgrade doesn't explode.
>

I agree that this option is on the table.
-- 
Dmitry Belyavskiy
--
___
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: Disable openSSL Engine Support (system-wide)

Dear Fabio,

On Wed, Mar 20, 2024 at 3:18 PM Fabio Valentini 
wrote:

> On Wed, Mar 20, 2024 at 3:06 PM Daniel P. Berrangé 
> wrote:
> >
> > On Wed, Mar 20, 2024 at 02:35:21PM +0100, Dmitry Belyavskiy wrote:
>
> (...)
>
> > > As I understand, upstream is going to remove engines but it wouldn't
> happen
> > > before OpenSSL 4.0
> >
> > That makes sense, as it solves the ELF ABI / SONAME change
> > issue with removing the APIs.
> >
> > > I don't think Fedora should wait for that. We definitely want to land
> > > no-engine in RHEL10 so Fedora should be ready for that.
> >
> > Fedora shouldn't neccessarily be rushed into something just because
> > RHEL wants to do it prematurely due to RHEL's long lifecycle.
>
> I fully agree here. Just because something is desirable for RHEL x+1
> doesn't mean that it's desirable for Fedora y+1.
> Also, hasn't CentOS Stream 10 already been branched off of
> ELN-is-Fedora-40, meaning it would be too late if done in Fedora 41
> anyway?
>

I agree that it's not strictly necessary for F41. I'm pretty sure that if
we want it in F42 we have to start now.
At least the feedback is valuable and we can take it into account earlier.

Or is this just about OpenSSL maintainers not wanting to have to keep
> maintaining Engine support in Fedora while it will be phased out in
> RHEL sooner?
>

Yes. We already have quite bad experience of maintaining slightly different
versions of OpenSSL and I'd like to keep the versions as close as possible.

-- 
Dmitry Belyavskiy
--
___
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

Looking for Feedback: Anaconda Web UI partitioning

2024-03-20 Thread Jiri Konecny


Hi everyone,

I would like to use this mail to invite you to the discussion

https://discussion.fedoraproject.org/t/feedback-anaconda-web-ui-partitioning/108995

which was created as reaction on https://pagure.io/fesco/issue/3169 
which is FESCO decision resulted in postponing the web UI from Fedora 
40. Unfortunately, the ticket is missing clear requirements for having 
the FESCO and Fedora users satisfied with the web UI solution. We would 
like to use the discussion above to find out the requirements to satisfy 
FESCO and Fedora users and to be able to propose given change below.


Best Regards,
Jirka
--
___
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: Disable openSSL Engine Support (system-wide)

2024-03-20 Thread Petr Pisar

V Wed, Mar 20, 2024 at 02:05:52PM +, Daniel P. Berrangé napsal(a):
> Consider you've built your own app on Fedora 39 that uses these
> symbols, and now upgrade to F40. RPM will consider the dependency
> still satisfied, as the SONAME hasn't changed on libcrypto. The
> app throws linker errors at some point due to the missing symbols.
> 
> Another alternative is to continue providing fully functional engine
> symbols, but remove the header files so in practice you can't compile
> something new that uses it. This is still forking the API, but at least
> has not forked the ELF ABI, so the upgrade doesn't explode.
> 
Another option is remove the symbols, change soname, and rebuild reverse
dependencies.

-- Petr


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

[HEADS-UP] dracut update 060 coming to Fedora Rawhide

2024-03-20 Thread Pavel Valena

Hello,

please $SUBJ, test if you can:
https://src.fedoraproject.org/rpms/dracut/pull-request/54#comment-190538

Any feedback is appreciated.

Regards,
Pavel
--
___
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: SPDX Statistics - Book Smugglers edition

2024-03-20 Thread Fabio Valentini

On Wed, Mar 20, 2024 at 2:53 PM Tomasz Kłoczko  wrote:
>
> On Sat, 16 Mar 2024 at 10:03, Miroslav Suchý  wrote:
>>
>> Hot news:
>>
>> The last phase has been announce 
>> https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_4 and we will 
>> proceed when approved with FESCO.
>
>
> I think that generally you are wasting your man/hours posting such statistics.
> The same time could be used better by going with a few grep. sort, sed 
> oneliers to co update and align all packages License: fields and commit all 
> those changes across all per packages repos in a few minutes.
> Some of the proven packagers with RW access to all packages repos can apply 
> necessary changes in a few tenths of minutes.
> Subject of SPDX migrations are already IIRC active since July 2022 (soon it 
> will be two years anniversary).
> All those changes should not be applied relying on each package maintainers 
> because that change is from Trival™️ class.

While I agree with some of what you're saying here, the problem is
that it is, in fact, *not trivial* in many cases.
Migrating the License tag from Callaway to SPDX identifiers is only
the "easy" part of the transition.
Re-reviewing package contents and re-classifying licenses is the
non-trivial part, and that definitely can't be scripted.

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: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

2024-03-20 Thread Fabio Valentini

On Wed, Mar 20, 2024 at 3:06 PM Daniel P. Berrangé  wrote:
>
> On Wed, Mar 20, 2024 at 02:35:21PM +0100, Dmitry Belyavskiy wrote:

(...)

> > As I understand, upstream is going to remove engines but it wouldn't happen
> > before OpenSSL 4.0
>
> That makes sense, as it solves the ELF ABI / SONAME change
> issue with removing the APIs.
>
> > I don't think Fedora should wait for that. We definitely want to land
> > no-engine in RHEL10 so Fedora should be ready for that.
>
> Fedora shouldn't neccessarily be rushed into something just because
> RHEL wants to do it prematurely due to RHEL's long lifecycle.

I fully agree here. Just because something is desirable for RHEL x+1
doesn't mean that it's desirable for Fedora y+1.
Also, hasn't CentOS Stream 10 already been branched off of
ELN-is-Fedora-40, meaning it would be too late if done in Fedora 41
anyway?
Or is this just about OpenSSL maintainers not wanting to have to keep
maintaining Engine support in Fedora while it will be phased out in
RHEL sooner?

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: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

2024-03-20 Thread Daniel P . Berrangé

On Wed, Mar 20, 2024 at 02:35:21PM +0100, Dmitry Belyavskiy wrote:
> Dear Daniel,
> 
> On Wed, Mar 20, 2024 at 1:44 PM Daniel P. Berrangé 
> wrote:
> 
> > On Fri, Mar 08, 2024 at 08:37:19PM +, Aoife Moloney wrote:
> > > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine
> > >
> > > This is a proposed Change for Fedora Linux.
> > > This document represents a proposed Change. As part of the Changes
> > > process, proposals are publicly announced in order to receive
> > > community feedback. This proposal will only be implemented if approved
> > > by the Fedora Engineering Steering Committee.
> > >
> > > == Summary ==
> > > We disable support of engines in OpenSSL
> > >
> > > == Owner ==
> > > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
> > > * Email: dbely...@redhat.com
> > >
> > > == Detailed Description ==
> > > We are going to build OpenSSL without engine support. Engines are not
> > > FIPS compatible and corresponding API is deprecated since OpenSSL 3.0.
> > > The engine functionality we are aware of (PKCS#11, TPM) is either
> > > covered by providers or will be covered soon.
> >
> > "will be covered soon"
> >
> > ... so lets wait until that work is actually complete before
> > removing this from openssl, otherwise there's a window of
> > brokenness in Fedora where the old feature is removed and
> > the new feature is not ready.
> >
> 
> I am not going to land this change until the tpm2 provider is landed in
> Fedora.

Lets explicitly note that as a blocking /  pre-requisite dependency
for landing this change then.

> > > == Benefit to Fedora ==
> > > We get rid of deprecated functionality and enforce using up-to-date
> > > API. Engine support is deprecated in OpenSSL upstream, and after
> > > provider migration caused some deficiencies with engine support. No
> > > new features will be added to the engine. So we reduce the maintenance
> > > burden and potentially attack surface.
> >
> > What is upstream's intention with the 'engine' feature deprecation ?
> >
> > Are they going actively remove this functionality after some
> > period of deprecation ? If so what's upstream timeframe, and
> > should Fedora just wait for that, rather than jumping the
> > gun ?
> >
> 
> As I understand, upstream is going to remove engines but it wouldn't happen
> before OpenSSL 4.0

That makes sense, as it solves the ELF ABI / SONAME change
issue with removing the APIs.

> I don't think Fedora should wait for that. We definitely want to land
> no-engine in RHEL10 so Fedora should be ready for that.

Fedora shouldn't neccessarily be rushed into something just because
RHEL wants to do it prematurely due to RHEL's long lifecycle.

> > > == Upgrade/compatibility impact ==
> > > OpenSSL engines will no longer be supported. Engines will not be
> > > supported in openssl configuration files (presumably silently
> > > ignored). Users will have to reconfigure systems to providers if they
> > > use engines.
> > >
> > >
> > > == How To Test ==
> > > OpenSSL libcrypto.so doesn't export any ENGINE_* symbols (~120 lines).
> > > Application is normally built.
> >
> > Removing symbols is an ABI break, so would imply the need for
> > an SONAME version bump. This is not normally something that
> > downstreams should ever touch though - it is an upstream
> > decision when to bump their SONAME version.
> >
> > Should we not preserve the ENGINE_* symbols, but turn
> > their impl into either a no-op, or reporting a runtime
> > error, as appropriate for each API.
> >
> 
> All 100+ symbols? I don't think providing non-working stubs would be a good
> idea...

Intentionally forking the upstream ABI is worse IMHO.

Consider you've built your own app on Fedora 39 that uses these
symbols, and now upgrade to F40. RPM will consider the dependency
still satisfied, as the SONAME hasn't changed on libcrypto. The
app throws linker errors at some point due to the missing symbols.

Another alternative is to continue providing fully functional engine
symbols, but remove the header files so in practice you can't compile
something new that uses it. This is still forking the API, but at least
has not forked the ELF ABI, so the upgrade doesn't explode.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
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: SPDX Statistics - Book Smugglers edition

2024-03-20 Thread Tomasz Kłoczko

On Sat, 16 Mar 2024 at 10:03, Miroslav Suchý  wrote:

> Hot news:
> The last phase has been announce
> https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_4 and we will
> proceed when approved with FESCO.
>

I think that generally you are wasting your man/hours posting such
statistics.
The same time could be used better by going with a few grep. sort, sed
oneliers to co update and align all packages License: fields and commit all
those changes across all per packages repos in a few minutes.
Some of the proven packagers with RW access to all packages repos can apply
necessary changes in a few tenths of minutes.
Subject of SPDX migrations are already IIRC active since July 2022 (soon it
will be two years anniversary).
All those changes should not be applied relying on each package maintainers
because that change is from Trival™️ class.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
--
___
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: Disable openSSL Engine Support (system-wide)

Dear Daniel,

On Wed, Mar 20, 2024 at 1:44 PM Daniel P. Berrangé 
wrote:

> On Fri, Mar 08, 2024 at 08:37:19PM +, Aoife Moloney wrote:
> > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine
> >
> > This is a proposed Change for Fedora Linux.
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> > == Summary ==
> > We disable support of engines in OpenSSL
> >
> > == Owner ==
> > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
> > * Email: dbely...@redhat.com
> >
> > == Detailed Description ==
> > We are going to build OpenSSL without engine support. Engines are not
> > FIPS compatible and corresponding API is deprecated since OpenSSL 3.0.
> > The engine functionality we are aware of (PKCS#11, TPM) is either
> > covered by providers or will be covered soon.
>
> "will be covered soon"
>
> ... so lets wait until that work is actually complete before
> removing this from openssl, otherwise there's a window of
> brokenness in Fedora where the old feature is removed and
> the new feature is not ready.
>

I am not going to land this change until the tpm2 provider is landed in
Fedora.
But the affected packages must start prepare to this change as early as
possible.


>
> > == Benefit to Fedora ==
> > We get rid of deprecated functionality and enforce using up-to-date
> > API. Engine support is deprecated in OpenSSL upstream, and after
> > provider migration caused some deficiencies with engine support. No
> > new features will be added to the engine. So we reduce the maintenance
> > burden and potentially attack surface.
>
> What is upstream's intention with the 'engine' feature deprecation ?
>
> Are they going actively remove this functionality after some
> period of deprecation ? If so what's upstream timeframe, and
> should Fedora just wait for that, rather than jumping the
> gun ?
>

As I understand, upstream is going to remove engines but it wouldn't happen
before OpenSSL 4.0
I don't think Fedora should wait for that. We definitely want to land
no-engine in RHEL10 so Fedora should be ready for that.


>
>
> > == Upgrade/compatibility impact ==
> > OpenSSL engines will no longer be supported. Engines will not be
> > supported in openssl configuration files (presumably silently
> > ignored). Users will have to reconfigure systems to providers if they
> > use engines.
> >
> >
> > == How To Test ==
> > OpenSSL libcrypto.so doesn't export any ENGINE_* symbols (~120 lines).
> > Application is normally built.
>
> Removing symbols is an ABI break, so would imply the need for
> an SONAME version bump. This is not normally something that
> downstreams should ever touch though - it is an upstream
> decision when to bump their SONAME version.
>
> Should we not preserve the ENGINE_* symbols, but turn
> their impl into either a no-op, or reporting a runtime
> error, as appropriate for each API.
>

All 100+ symbols? I don't think providing non-working stubs would be a good
idea...

-- 
Dmitry Belyavskiy
--
___
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

Fedora rawhide compose report: 20240320.n.0 changes

2024-03-20 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20240319.n.0
NEW: Fedora-Rawhide-20240320.n.0

= SUMMARY =
Added images:4
Dropped images:  3
Added packages:  11
Dropped packages:0
Upgraded packages:   91
Downgraded packages: 0

Size of added packages:  27.75 MiB
Size of dropped packages:0 B
Size of upgraded packages:   4.06 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -2.69 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: LXQt live x86_64
Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-Rawhide-20240320.n.0.iso
Image: Cloud_Base_UKI qcow2 aarch64
Path: 
Cloud/aarch64/images/Fedora-Cloud-Base-UEFI-UKI.aarch64-Rawhide-20240320.n.0.qcow2
Image: Cloud_Base_UKI qcow2 x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-UEFI-UKI.x86_64-Rawhide-20240320.n.0.qcow2
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20240320.n.0.iso

= DROPPED IMAGES =
Image: Sericea ociarchive aarch64
Path: Sericea/aarch64/images/Fedora-Sericea-Rawhide.20240319.n.0.ociarchive
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20240319.n.0.iso
Image: Cloud_Base vagrant-virtualbox x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-VirtualBox.x86_64-Rawhide-20240319.n.0.vagrant.virtualbox.box

= ADDED PACKAGES =
Package: crun-vm-0.1.3-1.fc41
Summary: An OCI Runtime that runs VM images
RPMs:crun-vm
Size:4.44 MiB

Package: ncnn-20240102-1.fc41
Summary: A high-performance neural network inference framework
RPMs:ncnn ncnn-devel
Size:17.82 MiB

Package: ofono-2.5-1.fc41
Summary: Open Source Telephony
RPMs:ofono ofono-devel
Size:4.18 MiB

Package: rust-addr-0.14.0-1.fc41
Summary: Library for parsing domain names
RPMs:rust-addr+default-devel rust-addr+psl-devel 
rust-addr+publicsuffix-devel rust-addr+serde-devel rust-addr+std-devel 
rust-addr-devel
Size:126.48 KiB

Package: rust-derive_builder0.12-0.12.0-1.fc41
Summary: Rust macro to automatically implement the builder pattern for 
arbitrary structs
RPMs:rust-derive_builder0.12+default-devel 
rust-derive_builder0.12+std-devel rust-derive_builder0.12-devel
Size:73.39 KiB

Package: rust-derive_builder_core0.12-0.12.0-1.fc41
Summary: Internal helper library for the derive_builder crate
RPMs:rust-derive_builder_core0.12+default-devel 
rust-derive_builder_core0.12-devel
Size:50.32 KiB

Package: rust-derive_builder_macro0.12-0.12.0-1.fc41
Summary: Rust macro to automatically implement the builder pattern for 
arbitrary structs
RPMs:rust-derive_builder_macro0.12+default-devel 
rust-derive_builder_macro0.12-devel
Size:21.64 KiB

Package: rust-fs4-0.8.1-1.fc41
Summary: No libc, pure Rust cross-platform file locks
RPMs:rust-fs4+async-std-devel rust-fs4+async-trait-devel 
rust-fs4+default-devel rust-fs4+sync-devel rust-fs4+tokio-devel rust-fs4-devel
Size:68.44 KiB

Package: rust-test-log-macros-0.2.15-1.fc41
Summary: Supporting procedural macro crate for test-log
RPMs:rust-test-log-macros+default-devel rust-test-log-macros+log-devel 
rust-test-log-macros+trace-devel rust-test-log-macros+unstable-devel 
rust-test-log-macros-devel
Size:44.37 KiB

Package: rust-wasmparser-0.201.0-1.fc41
Summary: Simple event-driven library for parsing WebAssembly binary files
RPMs:rust-wasmparser+default-devel rust-wasmparser-devel
Size:177.00 KiB

Package: timg-1.6.0-4.fc41
Summary: A terminal image and video viewer
RPMs:timg
Size:782.46 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  0ad-0.0.26-21.fc41
Old package:  0ad-0.0.26-20.fc40
Summary:  Cross-Platform RTS Game of Ancient Warfare
RPMs: 0ad
Size: 26.49 MiB
Size change:  -11.30 KiB
Changelog:
  * Tue Mar 19 2024 Dominik Mierzejewski  - 0.0.26-21
  - Rebuild for gloox 1.0.28


Package:  Cython-3.0.9-1.fc41
Old package:  Cython-3.0.8-4.fc41
Summary:  Language for writing Python extension modules
RPMs: python3-cython
Size: 15.59 MiB
Size change:  17.49 KiB
Changelog:
  * Sun Mar 17 2024 Charalampos Stratakis  - 3.0.9-1
  - Update to 3.0.9 (rhbz#2268123)


Package:  arm-none-eabi-gcc-cs-1:13.2.0-5.fc41
Old package:  arm-none-eabi-gcc-cs-1:13.2.0-3.fc40
Summary:  GNU GCC for cross-compilation for arm-none-eabi target
RPMs: arm-none-eabi-gcc-cs arm-none-eabi-gcc-cs-c++
Size: 1.04 GiB
Size change:  -20.55 KiB
Changelog:
  * Tue Mar 19 2024 Michal Hlavinka  - 1:13.2.0-4
  - rebuild with updated newlib

  * Tue Mar 19 2024 Michal Hlavinka  - 1:13.2.0-5
  - drop i686 build as not all i686 requirements are available anymore


Package:  azure-cli-2.58.0-1.fc41
Old package:  azure-cli-2.57.0-1.fc40
Summary:  Microsoft Azure Command-Line Tools
RPMs: azure-cli python3-azure-cli-core python3-azure-cli-telemetry 
python3-azure-cli-testsdk
Size: 12.88 MiB
Size change:  -242.51 KiB
Changelog

Re: [Test-Announce] Fedora 40 Candidate Beta-1.9 Available Now!

2024-03-20 Thread Dan Horák

On Wed, 20 Mar 2024 08:47:14 -0400
Neal Gompa  wrote:

> On Wed, Mar 20, 2024 at 8:45 AM Dan Horák  wrote:
> >
> > On Tue, 19 Mar 2024 12:41:48 + (UTC)
> > rawh...@fedoraproject.org wrote:
> >
> > > According to [the schedule][1], Fedora 40 Candidate Beta-1.9 is now
> > > available for testing. Please help us complete all the validation
> > > testing! For more information on 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/40
> > >
> > > 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_40_Beta_1.9_Summary
> > >
> > > The individual test result pages are:
> > >
> > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Installation
> > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Base
> > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Server
> > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Cloud
> > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Desktop
> > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Security_Lab
> > >
> > > All Beta priority test cases for each of these [test pages][2] must
> > > pass in order to meet the [Beta Release Criteria][3].
> > >
> > > Help is available on [the Fedora Quality chat channel][4], [the Fedora
> > > Quality tag on Discourse][5], or on [the test list][6].
> > >
> > > Current Blocker and Freeze Exception bugs:
> > >  https://qa.fedoraproject.org/blockerbugs/current
> > >
> > > [1]: https://fedorapeople.org/groups/schedule/f-40/f-40-quality-tasks.html
> > > [2]: https://fedoraproject.org/wiki/QA:Release_validation_test_plan
> > > [3]: https://fedoraproject.org/wiki/Fedora_40_Beta_Release_Criteria
> > > [4]: 
> > > https://matrix.to/#/#quality:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org
> > > [5]: https://discussion.fedoraproject.org/tags/c/project/7/quality-team
> > > [6]: 
> > > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
> >
> > the Cloud and Container image filenames miss the "Beta" string in the
> > name, not sure, but someone might have mentioned it already ...
> >
> > for example
> > Fedora-Cloud-Base-Generic.ppc64le-40-1.9.qcow2
> > should be
> > Fedora-Cloud-Base-Generic.ppc64le-40-Beta_1.9.qcow2
> > I believe. The checksum filename is correct.
> >
> 
> This is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=2270197
> 
> We have an upstream fix to kiwi for this, but some code will need to
> be written for the koji plugin and pungi to resolve it.

thanks for the pointer. I have noticed it, because I am using
https://github.com/sharkcz/tools/blob/master/check-compose to check
what artifacts are actually available (limited to my "multi-arch" view).


Dan
--
___
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: [Test-Announce] Fedora 40 Candidate Beta-1.9 Available Now!

On Wed, Mar 20, 2024 at 8:45 AM Dan Horák  wrote:
>
> On Tue, 19 Mar 2024 12:41:48 + (UTC)
> rawh...@fedoraproject.org wrote:
>
> > According to [the schedule][1], Fedora 40 Candidate Beta-1.9 is now
> > available for testing. Please help us complete all the validation
> > testing! For more information on 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/40
> >
> > 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_40_Beta_1.9_Summary
> >
> > The individual test result pages are:
> >
> > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Installation
> > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Base
> > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Server
> > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Cloud
> > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Desktop
> > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Security_Lab
> >
> > All Beta priority test cases for each of these [test pages][2] must
> > pass in order to meet the [Beta Release Criteria][3].
> >
> > Help is available on [the Fedora Quality chat channel][4], [the Fedora
> > Quality tag on Discourse][5], or on [the test list][6].
> >
> > Current Blocker and Freeze Exception bugs:
> >  https://qa.fedoraproject.org/blockerbugs/current
> >
> > [1]: https://fedorapeople.org/groups/schedule/f-40/f-40-quality-tasks.html
> > [2]: https://fedoraproject.org/wiki/QA:Release_validation_test_plan
> > [3]: https://fedoraproject.org/wiki/Fedora_40_Beta_Release_Criteria
> > [4]: 
> > https://matrix.to/#/#quality:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org
> > [5]: https://discussion.fedoraproject.org/tags/c/project/7/quality-team
> > [6]: 
> > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
>
> the Cloud and Container image filenames miss the "Beta" string in the
> name, not sure, but someone might have mentioned it already ...
>
> for example
> Fedora-Cloud-Base-Generic.ppc64le-40-1.9.qcow2
> should be
> Fedora-Cloud-Base-Generic.ppc64le-40-Beta_1.9.qcow2
> I believe. The checksum filename is correct.
>

This is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=2270197

We have an upstream fix to kiwi for this, but some code will need to
be written for the koji plugin and pungi to resolve it.



-- 
真実はいつも一つ！/ 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: [Test-Announce] Fedora 40 Candidate Beta-1.9 Available Now!

2024-03-20 Thread Dan Horák

On Tue, 19 Mar 2024 12:41:48 + (UTC)
rawh...@fedoraproject.org wrote:

> According to [the schedule][1], Fedora 40 Candidate Beta-1.9 is now
> available for testing. Please help us complete all the validation
> testing! For more information on 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/40
> 
> 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_40_Beta_1.9_Summary
> 
> The individual test result pages are:
> 
> https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Installation
> https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Base
> https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Server
> https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Cloud
> https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Desktop
> https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Security_Lab
> 
> All Beta priority test cases for each of these [test pages][2] must
> pass in order to meet the [Beta Release Criteria][3].
> 
> Help is available on [the Fedora Quality chat channel][4], [the Fedora
> Quality tag on Discourse][5], or on [the test list][6].
> 
> Current Blocker and Freeze Exception bugs:
>  https://qa.fedoraproject.org/blockerbugs/current
> 
> [1]: https://fedorapeople.org/groups/schedule/f-40/f-40-quality-tasks.html
> [2]: https://fedoraproject.org/wiki/QA:Release_validation_test_plan
> [3]: https://fedoraproject.org/wiki/Fedora_40_Beta_Release_Criteria
> [4]: 
> https://matrix.to/#/#quality:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org
> [5]: https://discussion.fedoraproject.org/tags/c/project/7/quality-team
> [6]: 
> https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/

the Cloud and Container image filenames miss the "Beta" string in the
name, not sure, but someone might have mentioned it already ...

for example
Fedora-Cloud-Base-Generic.ppc64le-40-1.9.qcow2
should be
Fedora-Cloud-Base-Generic.ppc64le-40-Beta_1.9.qcow2
I believe. The checksum filename is correct.


Dan
--
___
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: Disable openSSL Engine Support (system-wide)

2024-03-20 Thread Daniel P . Berrangé

On Fri, Mar 08, 2024 at 08:37:19PM +, Aoife Moloney wrote:
> Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine
> 
> This is a proposed Change for Fedora Linux.
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
> 
> == Summary ==
> We disable support of engines in OpenSSL
> 
> == Owner ==
> * Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
> * Email: dbely...@redhat.com
> 
> == Detailed Description ==
> We are going to build OpenSSL without engine support. Engines are not
> FIPS compatible and corresponding API is deprecated since OpenSSL 3.0.
> The engine functionality we are aware of (PKCS#11, TPM) is either
> covered by providers or will be covered soon.

"will be covered soon"

... so lets wait until that work is actually complete before
removing this from openssl, otherwise there's a window of
brokenness in Fedora where the old feature is removed and
the new feature is not ready.

> == Benefit to Fedora ==
> We get rid of deprecated functionality and enforce using up-to-date
> API. Engine support is deprecated in OpenSSL upstream, and after
> provider migration caused some deficiencies with engine support. No
> new features will be added to the engine. So we reduce the maintenance
> burden and potentially attack surface.

What is upstream's intention with the 'engine' feature deprecation ?

Are they going actively remove this functionality after some
period of deprecation ? If so what's upstream timeframe, and
should Fedora just wait for that, rather than jumping the
gun ?


> == Upgrade/compatibility impact ==
> OpenSSL engines will no longer be supported. Engines will not be
> supported in openssl configuration files (presumably silently
> ignored). Users will have to reconfigure systems to providers if they
> use engines.
> 
> 
> == How To Test ==
> OpenSSL libcrypto.so doesn't export any ENGINE_* symbols (~120 lines).
> Application is normally built.

Removing symbols is an ABI break, so would imply the need for
an SONAME version bump. This is not normally something that
downstreams should ever touch though - it is an upstream
decision when to bump their SONAME version.

Should we not preserve the ENGINE_* symbols, but turn
their impl into either a no-op, or reporting a runtime
error, as appropriate for each API.


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
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: [Test-Announce] Invitation to Contribute to Fedora Test Days: Podman Desktop Testing

2024-03-20 Thread Philip Rhoades via devel


People,

I am happy to do some testing but what is "Podman Desktop"? - I don't 
see anything like that to install "dnf list" . . I have been on F40 for 
a while now and am a regular user of Podman.


P.


On 2024-03-20 23:14, Sumantro Mukherjee wrote:

Dear Fedora Community Member,

We are excited to invite you to participate in an upcoming Fedora Test
Day focused on testing Podman Desktop. Podman Desktop is an innovative
tool that enables you to manage containers on your desktop with ease.

Date: 2024-03-20

Your feedback and testing are invaluable in ensuring the stability and
functionality of Podman Desktop. By participating, you'll have the
opportunity to:

Test Podman Desktop in various scenarios on your system.
Identify and report bugs, issues, or improvements.
Collaborate with fellow Fedora enthusiasts and developers.

No prior testing experience is necessary. Whether you're a seasoned
tester or new to the process, your contributions are highly valued.

If you're interested in joining us for this Test Day, please reply to
this email or sign up on the Fedora Wiki page[0]. Feel free to reach
out if you have any questions or need assistance getting started.

Thank you for your dedication to improving Fedora, and we look forward
to your participation!

Best regards,

[0] http://fedoraproject.org/wiki/Test_Day:2024-03-20_Podman_Desktop
--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
--
___
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


--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  p...@pricom.com.au
--
___
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: Disable openSSL Engine Support (system-wide)

2024-03-20 Thread Luca Boccassi

There are 2 major issues with this:

1) A lot of site-specific build systems implement signing via 
private/local/proprietary engines, which means those build systems will no 
longer be able to run on Fedora (and if this spreads to CentOS/RHEL, those too)
2) Even open source providers are still mostly broken, missing core 
functionality, and largely in a "developers preview" state and years of work 
away from being anywhere close to stability and reliability of engines. When 
adding engines support to various systemd tools recently, I tried to use the 
tpm2 and pkcs11 providers, and just gave up, as there was simply no way to make 
them work, they are simply not fit for purpose at this stage.
--
___
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

[Test-Announce] Invitation to Contribute to Fedora Test Days: Podman Desktop Testing

2024-03-20 Thread Sumantro Mukherjee

Dear Fedora Community Member,

We are excited to invite you to participate in an upcoming Fedora Test
Day focused on testing Podman Desktop. Podman Desktop is an innovative
tool that enables you to manage containers on your desktop with ease.

Date: 2024-03-20

Your feedback and testing are invaluable in ensuring the stability and
functionality of Podman Desktop. By participating, you'll have the
opportunity to:

Test Podman Desktop in various scenarios on your system.
Identify and report bugs, issues, or improvements.
Collaborate with fellow Fedora enthusiasts and developers.

No prior testing experience is necessary. Whether you're a seasoned
tester or new to the process, your contributions are highly valued.

If you're interested in joining us for this Test Day, please reply to
this email or sign up on the Fedora Wiki page[0]. Feel free to reach
out if you have any questions or need assistance getting started.

Thank you for your dedication to improving Fedora, and we look forward
to your participation!

Best regards,

[0] http://fedoraproject.org/wiki/Test_Day:2024-03-20_Podman_Desktop
-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
--
___
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: F41 Change Proposal: Disable openSSL Engine Support (system-wide)

On Wed, Mar 20, 2024 at 10:04:13AM +0100, Dmitry Belyavskiy wrote:
> > Hi,
> >
> > In systemd, we recently added support for engines in various tools:
> > - systemd-{repart,measure} have --private-key-source=file|engine|provider
> >   (this is C code).
> >
> 
> As `provider` is a possible source, you will have to replace `engine` with
> a particular provider.
> tpm2 provider is on the way to rawhide, and pkcs11 provider has already
> landed, so TPMs and Yubikeys

$ nm build/src/shared/libsystemd-shared-256.so.0 |rg 'ENGINE.*OPENSSL'  
 
 U ENGINE_by_id@OPENSSL_3.0.0
 U ENGINE_free@OPENSSL_3.0.0
 U ENGINE_init@OPENSSL_3.0.0
 U ENGINE_load_private_key@OPENSSL_3.0.0

That's how it looks with the upcoming systemd 256.

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: glibc32 in rawhide is now built from glibc

2024-03-20 Thread Florian Weimer

* Kevin Fenzi:

> However, our filter config is... quite possibly out of date. :)
>
> Currently it is: 
>
> filter_packages = [
> ("^.*$", {
> "*": ["glibc32", "libgcc32"],
> "s390x": ["rust-std-static-wasm*"],
> }),
> ('(Server)$', {
> '*': [
> 'kernel*debug*',
> 'kernel-kdump*',
> 'kernel-tools*',
> 'syslog-ng*',
> 'astronomy-bookmarks',
> 'generic*',
> 'GConf2-dbus*',
> 'bluez-gnome',
> 'java-11-openjdk',
> 'community-mysql*',
> 'jruby*',
> 'gimp-help-*',
> ]
> }),
> ]
>
> Does libgcc32 exist anymore?

I planned to bring this up later. 8-) I requested the addition of
libgcc32 because I thought it was needed.  But it turns out that all the
files that would be part of that package have always been gcc.x86_64.
This means that we don't need a libgcc32 subpackage after all.

I'll comment on the ticket as well.

Thanks,
Florian
--
___
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: Disable openSSL Engine Support (system-wide)

2024-03-20 Thread Alexander Bokovoy


On Срд, 20 сак 2024, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Mar 08, 2024 at 08:37:19PM +, Aoife Moloney wrote:

Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
We disable support of engines in OpenSSL

== Owner ==
* Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
* Email: dbely...@redhat.com

== Detailed Description ==
We are going to build OpenSSL without engine support. Engines are not
FIPS compatible and corresponding API is deprecated since OpenSSL 3.0.
The engine functionality we are aware of (PKCS#11, TPM) is either
covered by providers or will be covered soon.

== Feedback ==


== Benefit to Fedora ==
We get rid of deprecated functionality and enforce using up-to-date
API. Engine support is deprecated in OpenSSL upstream, and after
provider migration caused some deficiencies with engine support. No
new features will be added to the engine. So we reduce the maintenance
burden and potentially attack surface.


Hi,

In systemd, we recently added support for engines in various tools:
- systemd-{repart,measure} have --private-key-source=file|engine|provider
 (this is C code).
- ukify has --signing-engine.
 This is Python code that calls sbsign or pesign to do parts of the
 heavy lifting, and those binaries do not support providers. (At least
 the docs are silent on this, please correct it they do.)

So it seems we'd lose support for signing with keys stored on yubikeys
and tpms and other fancy approaches if the proposed change goes through.

--

Also, what is the impact on:
- kernel module signing in the build system


scrips/sign-file.c would need to migrate from use of ENGINE_* API to
providers. This is trivial as the only use is to find pkcs11 engine and
then load a private key through it:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/sign-file.c#n142
static EVP_PKEY *read_private_key(const char *private_key_name)
{
EVP_PKEY *private_key;

if (!strncmp(private_key_name, "pkcs11:", 7)) {
ENGINE *e;

ENGINE_load_builtin_engines();
drain_openssl_errors();
e = ENGINE_by_id("pkcs11");
ERR(!e, "Load PKCS#11 ENGINE");
if (ENGINE_init(e))
drain_openssl_errors();
else
ERR(1, "ENGINE_init");
if (key_pass)
ERR(!ENGINE_ctrl_cmd_string(e, "PIN", key_pass, 0),
"Set PKCS#11 PIN");
private_key = ENGINE_load_private_key(e, private_key_name,
  NULL, NULL);
ERR(!private_key, "%s", private_key_name);
} else {
BIO *b;

b = BIO_new_file(private_key_name, "rb");
ERR(!b, "%s", private_key_name);
private_key = PEM_read_bio_PrivateKey(b, NULL, pem_pw_cb,
  NULL);
ERR(!private_key, "%s", private_key_name);
BIO_free(b);
}

return private_key;
}

Dmitry, I think it is something your team needs to handle (submit
support for provider vs engine to Linux kernel upstream).


- signing of shim, grub2, fwupd, and the kernel in the build system
- mokutil


mokutil does not use ENGINE_* APIs at all.



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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: Disable openSSL Engine Support (system-wide)

2024-03-20 Thread Peter Robinson

On Wed, 20 Mar 2024 at 09:05, Dmitry Belyavskiy  wrote:
>
> Hi!
>
> On Wed, Mar 20, 2024 at 9:50 AM Zbigniew Jędrzejewski-Szmek 
>  wrote:
>>
>> On Fri, Mar 08, 2024 at 08:37:19PM +, Aoife Moloney wrote:
>> > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine
>> >
>> > This is a proposed Change for Fedora Linux.
>> > This document represents a proposed Change. As part of the Changes
>> > process, proposals are publicly announced in order to receive
>> > community feedback. This proposal will only be implemented if approved
>> > by the Fedora Engineering Steering Committee.
>> >
>> > == Summary ==
>> > We disable support of engines in OpenSSL
>> >
>> > == Owner ==
>> > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
>> > * Email: dbely...@redhat.com
>> >
>> > == Detailed Description ==
>> > We are going to build OpenSSL without engine support. Engines are not
>> > FIPS compatible and corresponding API is deprecated since OpenSSL 3.0.
>> > The engine functionality we are aware of (PKCS#11, TPM) is either
>> > covered by providers or will be covered soon.
>> >
>> > == Feedback ==
>> >
>> >
>> > == Benefit to Fedora ==
>> > We get rid of deprecated functionality and enforce using up-to-date
>> > API. Engine support is deprecated in OpenSSL upstream, and after
>> > provider migration caused some deficiencies with engine support. No
>> > new features will be added to the engine. So we reduce the maintenance
>> > burden and potentially attack surface.
>>
>> Hi,
>>
>> In systemd, we recently added support for engines in various tools:
>> - systemd-{repart,measure} have --private-key-source=file|engine|provider
>>   (this is C code).
>
>
> As `provider` is a possible source, you will have to replace `engine` with a 
> particular provider.
> tpm2 provider is on the way to rawhide, and pkcs11 provider has already 
> landed, so TPMs and Yubikeys
>
>
>>
>> - ukify has --signing-engine.
>>   This is Python code that calls sbsign or pesign to do parts of the
>>   heavy lifting, and those binaries do not support providers. (At least
>>   the docs are silent on this, please correct it they do.)
>
>
> Have no idea but it means we have to change this code
>>
>>
>> So it seems we'd lose support for signing with keys stored on yubikeys
>> and tpms and other fancy approaches if the proposed change goes through.
>
>
> We don't lose this support but we still have to adjust configurations.
>
>>
>> --
>>
>> Also, what is the impact on:
>> - kernel module signing in the build system
>> - signing of shim, grub2, fwupd, and the kernel in the build system
>> - mokutil
>
>
> Does any kernel module rely on OpenSSL?

No but they use openssl for signing kernel modules, you can see
details in the spec [1], search openssl.

[1] https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec
--
___
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: ld: error: triggering the generation of an executable stack

2024-03-20 Thread Fabio Valentini

On Wed, Mar 20, 2024, 01:28 Orion Poplawski  wrote:

> With a recent update, plplot is failing to build with:
>
> cd
> /builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/examples/fortran
> && /usr/bin/cmake -E cmake_link_script CMakeFiles/x16af.dir/link.txt
> --verbose=1
> /usr/bin/gfortran -Wl,-z,relro -Wl,--as-needed
> -Wl,-z,pack-relative-relocs -Wl,-z,now
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -O2
> -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
> -Wall -Wno-complain-wrong-lang -Werror=format-security
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
> -mno-omit-leaf-frame-pointer -frecursive
> CMakeFiles/x16af.dir/x16af.f90.o -o x16af
> -Wl,-rpath,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/bindings/fortran:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime
>
> ../libplfortrandemolib.a
> ../../bindings/fortran/libplplotfortran.so.0.2.0
>
> -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime
> /usr/bin/ld: error: /tmp/cchkMGCX.ltrans0.ltrans.o: is triggering the
> generation of an executable stack (because it has an executable
> .note.GNU-stack section)
> /usr/bin/ld: failed to set dynamic section sizes: No such file or directory
>
> I have no idea what is up here.
>

Isn't this what this change was about?

https://fedoraproject.org/wiki/Changes/Linker_Error_On_Security_Issues

Fabio


> Seems to have started with:
>
> gcc 14.0.1-0.7.fc41
> glibc 2.39.9000-3.fc41
> util-linux 2.40-0.9.rc1.fc41
> binutils 2.42.50-4.fc41
>
> and lots of others, but that seems the most likely.
>
> --
> 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/
> --
> ___
> 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
>
--
___
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: Disable openSSL Engine Support (system-wide)

Hi!

On Wed, Mar 20, 2024 at 9:50 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Fri, Mar 08, 2024 at 08:37:19PM +, Aoife Moloney wrote:
> > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine
> >
> > This is a proposed Change for Fedora Linux.
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> > == Summary ==
> > We disable support of engines in OpenSSL
> >
> > == Owner ==
> > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
> > * Email: dbely...@redhat.com
> >
> > == Detailed Description ==
> > We are going to build OpenSSL without engine support. Engines are not
> > FIPS compatible and corresponding API is deprecated since OpenSSL 3.0.
> > The engine functionality we are aware of (PKCS#11, TPM) is either
> > covered by providers or will be covered soon.
> >
> > == Feedback ==
> >
> >
> > == Benefit to Fedora ==
> > We get rid of deprecated functionality and enforce using up-to-date
> > API. Engine support is deprecated in OpenSSL upstream, and after
> > provider migration caused some deficiencies with engine support. No
> > new features will be added to the engine. So we reduce the maintenance
> > burden and potentially attack surface.
>
> Hi,
>
> In systemd, we recently added support for engines in various tools:
> - systemd-{repart,measure} have --private-key-source=file|engine|provider
>   (this is C code).
>

As `provider` is a possible source, you will have to replace `engine` with
a particular provider.
tpm2 provider is on the way to rawhide, and pkcs11 provider has already
landed, so TPMs and Yubikeys



> - ukify has --signing-engine.
>   This is Python code that calls sbsign or pesign to do parts of the
>   heavy lifting, and those binaries do not support providers. (At least
>   the docs are silent on this, please correct it they do.)
>

Have no idea but it means we have to change this code

>
> So it seems we'd lose support for signing with keys stored on yubikeys
> and tpms and other fancy approaches if the proposed change goes through.
>

We don't lose this support but we still have to adjust configurations.


> --
>
> Also, what is the impact on:
> - kernel module signing in the build system
> - signing of shim, grub2, fwupd, and the kernel in the build system
> - mokutil
>

Does any kernel module rely on OpenSSL?


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


-- 
Dmitry Belyavskiy
--
___
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: Disable openSSL Engine Support (system-wide)