Re: Orphaned packages looking for new maintainers

[Jens-Ulrik Petersen]

On Fri, Mar 22, 2024 at 12:22 AM Maxwell G  wrote:

> botan orphan   0 weeks
> ago


Is botan1 still considered safe?  Perhaps the python which causes the FTI
apparently could be removed?
Of course we have botan2 (but not botan3) in Fedora...

(I am asking because of ikiwiki, which doesn't require python.)

Jens
--
___
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] perl-CPAN-Perl-Releases-5.20240321 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
FEDORA-2024-ea406abb46 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2024-ea406abb46`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-ea406abb46

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
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%23c8
--
___
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

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

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
FEDORA-2024-3699640048 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2024-3699640048`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-3699640048

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
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%23c7
--
___
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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-ac18018db8   
tcpreplay-4.4.4-5.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-bf31852fe0   
w3m-0.5.3-63.git20230121.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-f653e0bbf9   
chromium-122.0.6261.128-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-4f9d0665fa   
csmock-3.5.3-1.el8


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

libdivide-5.0-10.el8

Details about builds:



 libdivide-5.0-10.el8 (FEDORA-EPEL-2024-5b93b14834)
 Optimized integer division

Update Information:

Fix a typo in README.md and in the package description; update the License field
to SPDX

ChangeLog:

* Thu Mar 21 2024 Benjamin A. Beasley  - 5.0-10
- Fix a typo in README.md and in the package description
* Thu Mar 21 2024 Benjamin A. Beasley  - 5.0-8
- Update License to SPDX
* Thu Mar 21 2024 Jerry James  - 5.0-7
- Update README.md.


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

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

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
FEDORA-2024-0465fc03b8 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2024-0465fc03b8`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-0465fc03b8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
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%23c7
--
___
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

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

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
FEDORA-2024-1b24d0ba2e has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2024-1b24d0ba2e`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-1b24d0ba2e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
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%23c6
--
___
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

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

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
FEDORA-2024-1d89caddb4 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2024-1d89caddb4`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-1d89caddb4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
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%23c6
--
___
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

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

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
FEDORA-2024-054b591230 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2024-054b591230`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-054b591230

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
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%23c5
--
___
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

[rpms/perl-AnyEvent-I3] PR #1: Fix URL

[Tim Landscheidt]

scfc opened a new pull-request against the project: `perl-AnyEvent-I3` that you 
are following:
``
Fix URL
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-AnyEvent-I3/pull-request/1
--
___
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: Redis will no longer be OSS... now what?

[Carl George]

Redis is not shipped in EPEL9, because it's in RHEL9.  Same with EPEL8
and RHEL8.  It is shipped in EPEL7 at version 3.2, presumably because
updating any further would be an incompatible update.

The license change announcement clearly states it will only be for 7.4
and up.  The prior branches (6.2.x, 7.0.x, and 7.2.x) are still going
to be maintained as per their security policy [0], and I haven't seen
any indication that these maintenance updates will be anything other
than BSD-3-Clause licensed.  The license change commit has only
occurred upstream in their unstable branch (future 7.4), and the 7.2
branch still has the previous license file [1].  This isn't like when
mongodb switched to SSPL for all future versions, including
maintenance/security updates to older branches.  Considering these
factors, F39+ can stay on 7.2.x for quite some time.  F38 can stay on
7.0.x for the rest of its lifecycle. The only thing we can't do is
update any branch to 7.4.x.

Having keydb obsolete redis in Fedora would not be appropriate in my
opinion, because they are still different software, and a user may
want to have both installed at the same time.  Additionally, keydb in
EPEL definitely can't obsolete redis in RHEL.  Maybe at some point
we'll go the obsolete route in Fedora with a change proposal and FESCo
approval, but I don't think we're at that point yet.

[0] https://github.com/redis/redis/security/policy
[1] https://github.com/redis/redis/blob/7.2/COPYING

On Thu, Mar 21, 2024 at 1:19 PM Scott Williams  wrote:
>
> Redis-6 is currently shipped in EPEL9, so it seems like a more obvious 
> step-forward wrt EPEL.
>
>
> > Honestly trying to replace redis with KeyDB in Fedora would be a step
> > backwards and cause headaches so I don't think it's feasible, at least
> > until redis v7 features are merged into KeyDB.
>
> Unfortunately, it's still the best option we have.  Ideally, redis wouldn't 
> have done this, but since redis is no longer license compatible, can we 
> really continue to ship redis-7 in Fedora 40 if we can't patch and maintain 
> it?  If KeyDB were to merge and release a v7 version against the latest BSD 
> code, I agree that it would be a much better target for Fedora 40.  
> Unfortunately, we're in the awful position of having to choose between a 
> breaking change for a small amount of users or shipping something that we 
> can't patch or realistically maintain.  If we have some clue that a v7 
> merge/release is on the very near horizon for KeyDB, then maybe it makes 
> sense to keep redis and obsolete it for KeyDB after GA, but it would be 
> preferable, IMO, to have a clean break on Fedora 40 release if possible, 
> which will also give us a better chance to document it so the small amount of 
> impacted end-users wrt v7-specific things can prepare for it.
> --
> ___
> 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



-- 
Carl George
--
___
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?

[Scott Williams]

Yeah, I was going to say it depends on the dotnet8 runtime.  There are 
containers for it, but that's a lot of extra dependency load.  Otherwise, it 
would be viable.
--
___
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

[Miroslav Suchý]

Dne 21. 03. 24 v 19:47 kloc...@fedoraproject.org napsal(a):

Those trivial substs probably would cover +90% of all packages in time in my 
estimation.


See

https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit#gid=0

The "trivial" conversion is possible for 4996 license tags (you do not want to count packages, you need to count License 
tags). Out of 11k.  That is 45%. For the remaining 55% you have to actually check the text of the license. Or use 
license scanner.



Currently in Fedora is 23ish k packages so to review with greater care ~2.5k 
lets say 30-50/day as afk/warming-up task each day should take for single 
person top few weeks .. not years. And because it would be done by single 
person I'm sure that he/she will be improving that task during that applying 
better and better methodology ans sometimes tools. In that approach I'm 100% 
sure that quality of that review will far greater than with spreading that task 
to all possible maintainers.
Issue only is that this can be done OLNY by proven packager because submission 
PRs/discussing/etc will eat order of magnitude more time to someone without 
such permission.


Do I understand it correctly that you are willing to help? I will help you get the proven packager status and onboard 
you to current state and availale tooling.



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

shogun-data should be retired since shogun is retired

[Sérgio Basto]

Hi, 
Some days ago I notice that shogun-data still in Fedora [1] but shogun
is retired for 4 years [2], just run `fedpkg retire DESCRIPTION` is
enough ? 

Thank you, 

[1]
https://src.fedoraproject.org/rpms/shogun-data 
[2]
https://src.fedoraproject.org/rpms/shogun
-- 
Sérgio M. B.
--
___
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 Linux 40 Beta release is GO

[Aoife Moloney]

The Fedora Linux 40 Beta  RC 1.10 compose is GO and will be shipped
live on Tuesday, 26th March 2024.

For more information please check the Go/No-Go meeting minutes[1] or log[2].

[1] 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-21/f40-beta-go-no-go-meeting.2024-03-21-17.03.html
[2] 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-21/f40-beta-go-no-go-meeting.2024-03-21-17.03.log.html



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

Orphaned packages looking for new maintainers

[Maxwell G]

(NOTE: Some packages in this report were already retired in distgit but
still show up in the orphaned packages list due to
https://pagure.io/releng/issue/12028)

Report started at 2024-03-21 16:05:32 UTC

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in the left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

R-presser @r-maint-sig, orphan 7 weeks ago  
atinout   orphan   6 weeks ago  
botan orphan   0 weeks ago  
deepin-dock   @deepinde-sig, cheeselee,0 weeks ago  
  felixonmars, orphan, zsun 
emacs-htmlize orphan   0 weeks ago  
gnome-shell-extension-freon   orphan   2 weeks ago  
gnome-translate   orphan   7 weeks ago  
golang-github-@go-sig, ngompa, orphan  6 weeks ago  
googlecloudplatform-guest-  
logging 
golang-storj-uplink   @go-sig, orphan  6 weeks ago  
google-compute-engine-guest-  ngompa, orphan   6 weeks ago  
configs 
google-disk-expandorphan   6 weeks ago  
google-guest-agent@go-sig, ngompa, orphan  6 weeks ago  
google-osconfig-agent @go-sig, orphan  6 weeks ago  
kio-upnp-ms   jgrulich, orphan 2 weeks ago  
ktp-contact-runner@kde-sig, orphan, rdieter2 weeks ago  
libmodulemd1  @copr-sig, orphan7 weeks ago  
libtranslate  orphan   7 weeks ago  
lightly   orphan   8 weeks ago  
liquidshell   orphan   3 weeks ago  
loudgain  orphan   1 weeks ago  
mrxvt orphan   1 weeks ago  
ocaml-newtorphan   7 weeks ago  
perl-Git-PurePerl iarnell, orphan  4 weeks ago  
perl-Net-GitHub   jplesnik, lkundrak, orphan,  4 weeks ago  
  ppisar
perl-PDF-Haru orphan   6 weeks ago  
perl-Spreadsheet-ParseExcel-  jplesnik, orphan, ppisar 4 weeks ago  
Simple  
perl-Spreadsheet-WriteExcel-  jplesnik, orphan, ppisar 4 weeks ago  
Simple  
perl-String-Diff  iarnell, orphan  4 weeks ago  
perl-WWW-Google-Contacts  orphan   2 weeks ago  
phosh-mobile-settings orphan   6 weeks ago  
php-doctrine-persistence2 orphan   7 weeks ago  
php-doctrine-persistence3 orphan   7 weeks ago  
php-echonest-api  orphan   7 weeks ago  
php-endroid-qrcodeorphan   7 weeks ago  
php-interfasys-lognormalizer  orphan   7 weeks ago  
php-ircmaxell-random-lib  orphan   7 weeks ago  
php-ircmaxell-security-liborphan   7 weeks ago  
php-kukulich-fshl orphan   7 

[Test-Announce] Fedora Linux 40 Beta release is GO

[Aoife Moloney]

The Fedora Linux 40 Beta  RC 1.10 compose is GO and will be shipped
live on Tuesday, 26th March 2024.

For more information please check the Go/No-Go meeting minutes[1] or log[2].

[1] 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-21/f40-beta-go-no-go-meeting.2024-03-21-17.03.html
[2] 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-21/f40-beta-go-no-go-meeting.2024-03-21-17.03.log.html



-- 
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: SPDX Statistics - Book Smugglers edition

[kloczek]

> On Wed, Mar 20, 2024 at 2:53 PM Tomasz Kłoczko 
>  
> 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.

Re-reviewing is another story/task.
What I wrote was about substing obvious cases.
Those trivial substs probably would cover +90% of all packages in time in my 
estimation.
Currently in Fedora is 23ish k packages so to review with greater care ~2.5k 
lets say 30-50/day as afk/warming-up task each day should take for single 
person top few weeks .. not years. And because it would be done by single 
person I'm sure that he/she will be improving that task during that applying 
better and better methodology ans sometimes tools. In that approach I'm 100% 
sure that quality of that review will far greater than with spreading that task 
to all possible maintainers.
Issue only is that this can be done OLNY by proven packager because submission 
PRs/discussing/etc will eat order of magnitude more time to someone without 
such permission.

Licenses are changing all the time so always will be non-empty set of spec 
files with incorrect Licence: field(s) assignment.
This is like with collecting mushrooms in the forest. Fist group collects "all 
what was possible to find" and went after all home with full buckets. Than 
second one after few days is doing the same .. and so on

kloczek
--
___
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 2270834] New: perl-Pod-Weaver-4.020 is available

[bugzilla]

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

Bug ID: 2270834
   Summary: perl-Pod-Weaver-4.020 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Pod-Weaver
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 4.020
Upstream release that is considered latest: 4.020
Current version/release in rawhide: 4.019-5.fc40
URL: http://search.cpan.org/dist/Pod-Weaver/

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/13868/


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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202270834%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: Redis will no longer be OSS... now what?

[Jonathan Wright via devel]

On Thu, Mar 21, 2024 at 1:28 PM Neal Gompa  wrote:

> On Thu, Mar 21, 2024 at 2:24 PM Scott Williams 
> wrote:
> >
> > >  If we have some clue that a v7 merge/release
> > >  is on the very near horizon for KeyDB
> >
> > This doesn't look promising for v7 in time for Fedora 40 or shortly
> after, unfortunately: https://github.com/Snapchat/KeyDB/issues/420
> >
> > The choice of shipping an ever-stale v7 database versus a maintainable
> v6 one is not a fun one, but leaving it up to Fedora package maintainers to
> have to potentially come up with their own out-of-band patches for CVEs for
> redis-7 seems like the worse choice to me.
>
> I think the immediate fix is pulling in redict once it makes its first
> release: https://codeberg.org/redict/redict


I very much think we should take a wait and see approach for now.  KeyDB,
while slow, has at least published something.  redict is totally unknown.
Maybe it gets a huge following, maybe it doesn't.

We don't have to make any rash decisions since the current versions of
redis are in good shape for the time being.
-- 
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?

[Scott Williams]

My concern there is that it has 7 code contributors with just one person having 
the vast majority of those commits.  That's not a problem for including the 
package, but it could be a concern for replacing redis with it given how young 
the project is and for it having significantly less resources than KeyDB (which 
has over 500 code contributors).
--
___
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?

[Scott Williams]

FYI - It looks like there is a redis-7 to keydb-6 path:  
https://github.com/Snapchat/KeyDB/issues/527#issuecomment-1370606311
--
___
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?

[Onuralp SEZER]

In Addition to that, I would rather wait a little bit and see about another
fork (s) and see ship possible redis-7+ versions instead of downgrading it.
Also PR shows very slow process so I wouldn't go for it.

On Thu, Mar 21, 2024 at 9:24 PM Scott Williams  wrote:

> >  If we have some clue that a v7 merge/release
> >  is on the very near horizon for KeyDB
>
> This doesn't look promising for v7 in time for Fedora 40 or shortly after,
> unfortunately: https://github.com/Snapchat/KeyDB/issues/420
>
> The choice of shipping an ever-stale v7 database versus a maintainable v6
> one is not a fun one, but leaving it up to Fedora package maintainers to
> have to potentially come up with their own out-of-band patches for CVEs for
> redis-7 seems like the worse choice to me.
> --
> ___
> 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
>


-- 





--
Onuralp SEZER
Fedora Ambassadors  EMEA
 Member / Turkey
Fedora Translations Turkish Team Member

Fedora Design Member 
--
___
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]

On Thu, Mar 21, 2024 at 2:24 PM Scott Williams  wrote:
>
> >  If we have some clue that a v7 merge/release
> >  is on the very near horizon for KeyDB
>
> This doesn't look promising for v7 in time for Fedora 40 or shortly after, 
> unfortunately: https://github.com/Snapchat/KeyDB/issues/420
>
> The choice of shipping an ever-stale v7 database versus a maintainable v6 one 
> is not a fun one, but leaving it up to Fedora package maintainers to have to 
> potentially come up with their own out-of-band patches for CVEs for redis-7 
> seems like the worse choice to me.

I think the immediate fix is pulling in redict once it makes its first
release: https://codeberg.org/redict/redict



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

[Scott Williams]

>  If we have some clue that a v7 merge/release
>  is on the very near horizon for KeyDB

This doesn't look promising for v7 in time for Fedora 40 or shortly after, 
unfortunately: https://github.com/Snapchat/KeyDB/issues/420

The choice of shipping an ever-stale v7 database versus a maintainable v6 one 
is not a fun one, but leaving it up to Fedora package maintainers to have to 
potentially come up with their own out-of-band patches for CVEs for redis-7 
seems like the worse choice to me.
--
___
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?

[Scott Williams]

Redis-6 is currently shipped in EPEL9, so it seems like a more obvious 
step-forward wrt EPEL.


> Honestly trying to replace redis with KeyDB in Fedora would be a step
> backwards and cause headaches so I don't think it's feasible, at least
> until redis v7 features are merged into KeyDB.

Unfortunately, it's still the best option we have.  Ideally, redis wouldn't 
have done this, but since redis is no longer license compatible, can we really 
continue to ship redis-7 in Fedora 40 if we can't patch and maintain it?  If 
KeyDB were to merge and release a v7 version against the latest BSD code, I 
agree that it would be a much better target for Fedora 40.  Unfortunately, 
we're in the awful position of having to choose between a breaking change for a 
small amount of users or shipping something that we can't patch or 
realistically maintain.  If we have some clue that a v7 merge/release is on the 
very near horizon for KeyDB, then maybe it makes sense to keep redis and 
obsolete it for KeyDB after GA, but it would be preferable, IMO, to have a 
clean break on Fedora 40 release if possible, which will also give us a better 
chance to document it so the small amount of impacted end-users wrt v7-specific 
things can prepare for it.
--
___
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: Orphaned packages looking for new maintainers

[Davide Cavalca]

On 2024-03-21 09:22, Maxwell G wrote:
gnome-shell-extension-freon   orphan   2 
weeks ago


I've picked this up.

Cheers
Davide
--
___
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?

[Jonathan Wright via devel]

Anything that was new in Redis 7 is not currently in KeyDB.  This is a
decent list of features I found that would be impacted.

https://www.instaclustr.com/blog/redis-7-new-features/

KeyDB has it on their roadmap to merge in the latest features from Redis 7
but that's not complete yet (nor can I find any published status on that).
EPEL doesn't currently provide Redis for 8/9 because it got pulled in
directly by RH.  RHEL 9 does have a module for redis 7 but the default is
6, so that's easy at least.  There should be no problems with adding KeyDB
to EPEL 8/9 - in fact it doesn't even conflict with redis (though
keydb-devel will conflict with redis-devel as keydb-devel still uses
identical names of some libraries it produces).

Honestly trying to replace redis with KeyDB in Fedora would be a step
backwards and cause headaches so I don't think it's feasible, at least
until redis v7 features are merged into KeyDB.

On Thu, Mar 21, 2024 at 1:05 PM Scott Williams  wrote:

> Assuming KeyDB gets accepted (it looks close from the Bugzilla review), we
> should obsolete redis for KeyDB in Fedora 40+ and consider eventually doing
> likewise with EPEL as well, since we aren't going to be able to ship any
> redis patches moving forward.  I feel less strongly about that for EPEL as
> for Fedora.  As a Fedora redis user, personally, having KeyDB in-place
> replace redis on upgrade to Fedora 40 seems like the best possible route
> moving forward to limit end-user disruption and technical debt for Fedora.
>
> As long as KeyDB's multi-threading isn't enabled out of box, it should
> essentially be equivalent to redis-6 as I understand it.  We're currently
> shipping redis-7.2.4 in Fedora 39.  Are there any potential redis-7
> specific compatibility problems with KeyDB migration?
> --
> ___
> 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?

[Scott Williams]

Assuming KeyDB gets accepted (it looks close from the Bugzilla review), we 
should obsolete redis for KeyDB in Fedora 40+ and consider eventually doing 
likewise with EPEL as well, since we aren't going to be able to ship any redis 
patches moving forward.  I feel less strongly about that for EPEL as for 
Fedora.  As a Fedora redis user, personally, having KeyDB in-place replace 
redis on upgrade to Fedora 40 seems like the best possible route moving forward 
to limit end-user disruption and technical debt for Fedora.

As long as KeyDB's multi-threading isn't enabled out of box, it should 
essentially be equivalent to redis-6 as I understand it.  We're currently 
shipping redis-7.2.4 in Fedora 39.  Are there any potential redis-7 specific 
compatibility problems with KeyDB migration?  
--
___
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] perl-CPAN-Perl-Releases-5.20240321 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2024-ea406abb46 (perl-CPAN-Perl-Releases-5.20240321-1.fc39) has been
submitted as an update to Fedora 39.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-ea406abb46


-- 
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%23c3
--
___
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

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

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2024-1d89caddb4 (perl-CPAN-Perl-Releases-5.20240321-1.fc40) has been
submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-1d89caddb4

--- Comment #5 from Fedora Update System  ---
FEDORA-2024-0465fc03b8 (perl-CPAN-Perl-Releases-5.20240321-1.fc38) has been
submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-0465fc03b8


-- 
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%23c5
--
___
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

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

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2024-1d89caddb4 (perl-CPAN-Perl-Releases-5.20240321-1.fc40) has been
submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-1d89caddb4


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

[Mike Rochefort]

On Thu, Mar 21, 2024 at 08:29:09AM +, Richard W.M. Jones wrote:
> just noticed one fork, might be worth keeping eye on:
> https://codeberg.org/redict/redict

On the newly launched "Write Free Software" Discourse[0], Drew noted 
that he is creating and leading this fork due to his reliance on Redis 
in his own projects[1].

[0] https://discourse.writefreesoftware.org
[1] 
https://discourse.writefreesoftware.org/t/redis-switches-to-dual-source-available-licensing-model/154/3

Cheers,
Mike
--
___
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] perl-CPAN-Perl-Releases-5.20240321 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-CPAN-Perl-Releases-5.2
   ||0240321-1.fc41
 Resolution|--- |ERRATA
 Status|MODIFIED|CLOSED
Last Closed||2024-03-21 16:29:19



--- Comment #2 from Fedora Update System  ---
FEDORA-2024-ba14addf62 (perl-CPAN-Perl-Releases-5.20240321-1.fc41) has been
pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Mattia Verga via devel]

Il 21/03/24 03:00, Kevin Kofler via devel ha scritto:

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

Yep, I've messed thing up. So, let's stick to use zstd, which is createrepo_c 
new default anyway.

Mattia--
___
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 packages looking for new maintainers

[Maxwell G]

(NOTE: Some packages in this report were already retired in distgit but
still show up in the orphaned packages list due to
https://pagure.io/releng/issue/12028)

Report started at 2024-03-21 16:05:32 UTC

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in the left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

R-presser @r-maint-sig, orphan 7 weeks ago  
atinout   orphan   6 weeks ago  
botan orphan   0 weeks ago  
deepin-dock   @deepinde-sig, cheeselee,0 weeks ago  
  felixonmars, orphan, zsun 
emacs-htmlize orphan   0 weeks ago  
gnome-shell-extension-freon   orphan   2 weeks ago  
gnome-translate   orphan   7 weeks ago  
golang-github-@go-sig, ngompa, orphan  6 weeks ago  
googlecloudplatform-guest-  
logging 
golang-storj-uplink   @go-sig, orphan  6 weeks ago  
google-compute-engine-guest-  ngompa, orphan   6 weeks ago  
configs 
google-disk-expandorphan   6 weeks ago  
google-guest-agent@go-sig, ngompa, orphan  6 weeks ago  
google-osconfig-agent @go-sig, orphan  6 weeks ago  
kio-upnp-ms   jgrulich, orphan 2 weeks ago  
ktp-contact-runner@kde-sig, orphan, rdieter2 weeks ago  
libmodulemd1  @copr-sig, orphan7 weeks ago  
libtranslate  orphan   7 weeks ago  
lightly   orphan   8 weeks ago  
liquidshell   orphan   3 weeks ago  
loudgain  orphan   1 weeks ago  
mrxvt orphan   1 weeks ago  
ocaml-newtorphan   7 weeks ago  
perl-Git-PurePerl iarnell, orphan  4 weeks ago  
perl-Net-GitHub   jplesnik, lkundrak, orphan,  4 weeks ago  
  ppisar
perl-PDF-Haru orphan   6 weeks ago  
perl-Spreadsheet-ParseExcel-  jplesnik, orphan, ppisar 4 weeks ago  
Simple  
perl-Spreadsheet-WriteExcel-  jplesnik, orphan, ppisar 4 weeks ago  
Simple  
perl-String-Diff  iarnell, orphan  4 weeks ago  
perl-WWW-Google-Contacts  orphan   2 weeks ago  
phosh-mobile-settings orphan   6 weeks ago  
php-doctrine-persistence2 orphan   7 weeks ago  
php-doctrine-persistence3 orphan   7 weeks ago  
php-echonest-api  orphan   7 weeks ago  
php-endroid-qrcodeorphan   7 weeks ago  
php-interfasys-lognormalizer  orphan   7 weeks ago  
php-ircmaxell-random-lib  orphan   7 weeks ago  
php-ircmaxell-security-liborphan   7 weeks ago  
php-kukulich-fshl orphan   7 

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

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2024-ba14addf62 (perl-CPAN-Perl-Releases-5.20240321-1.fc41) has been
submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-ba14addf62


-- 
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%23c1
--
___
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

Fedora 40 compose report: 20240321.n.0 changes

[Fedora Branched Report]

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

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   35
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   260.39 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   801.43 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-40-20240321.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  adwaita-icon-theme-46~rc-1.fc40
Old package:  adwaita-icon-theme-46~beta-2.fc40
Summary:  Adwaita icon theme
RPMs: adwaita-cursor-theme adwaita-icon-theme adwaita-icon-theme-devel
Size: 935.28 KiB
Size change:  191 B
Changelog:
  * Mon Mar 04 2024 David King  - 46~rc-1
  - Update to 46.rc


Package:  at-spi2-core-2.51.91-1.fc40
Old package:  at-spi2-core-2.51.90-1.fc40
Summary:  Protocol definitions and daemon for D-Bus at-spi
RPMs: at-spi2-atk at-spi2-atk-devel at-spi2-core at-spi2-core-devel atk 
atk-devel
Size: 6.48 MiB
Size change:  -1.13 MiB
Changelog:
  * Mon Mar 04 2024 David King  - 2.51.91-1
  - Update to 2.51.91


Package:  bcm283x-firmware-20240229-3.dc94391.fc40
Old package:  bcm283x-firmware-20240229-1.dc94391.fc40
Summary:  Firmware for the Broadcom bcm283x/bcm271x used in the Raspberry Pi
RPMs: bcm2711-firmware bcm2835-firmware bcm283x-firmware 
bcm283x-overlays
Size: 7.00 MiB
Size change:  233 B
Changelog:
  * Mon Mar 18 2024 Peter Robinson  - 
20240229-2.dc94391
  - Update RPi400 firmware DTB
  - Reorder config.txt to be closer to upstream

  * Tue Mar 19 2024 Peter Robinson  - 
20240229-3.dc94391
  - Update RPi400 to upstream fix


Package:  budgie-control-center-1.4.0-1.fc40
Old package:  budgie-control-center-1.3.0-1.fc39
Summary:  A fork of GNOME Control Center for the Budgie 10 Series
RPMs: budgie-control-center budgie-control-center-common
Size: 10.08 MiB
Size change:  -93.20 KiB
Changelog:
  * Fri Jan 19 2024 Fedora Release Engineering  - 
1.3.0-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Tue Jan 23 2024 Fedora Release Engineering  - 
1.3.0-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Wed Mar 06 2024 Gwyn Ciesla  - 1.3.0-4
  - goa-backend rebuild

  * Sun Mar 17 2024 Joshua Strobl  - 1.4.0-1
  - Update to 1.4.0


Package:  cinnamon-control-center-6.0.0-6.fc40
Old package:  cinnamon-control-center-6.0.0-4.fc40
Summary:  Utilities to configure the Cinnamon desktop
RPMs: cinnamon-control-center cinnamon-control-center-devel 
cinnamon-control-center-filesystem
Size: 2.13 MiB
Size change:  -40.04 KiB
Changelog:
  * Wed Mar 06 2024 Gwyn Ciesla  - 6.0.0-5
  - goa-backend rebuild

  * Tue Mar 12 2024 Leigh Scott  - 6.0.0-6
  - Disable goa for f40+


Package:  epiphany-1:46~rc-1.fc40
Old package:  epiphany-1:46~alpha-2.fc40
Summary:  Web browser for GNOME
RPMs: epiphany epiphany-runtime
Size: 11.05 MiB
Size change:  -951 B
Changelog:
  * Thu Mar 07 2024 David King  - 1:46~rc-1
  - Update to 46.rc


Package:  file-roller-44~beta-1.fc40
Old package:  file-roller-44~alpha-1.fc40
Summary:  Tool for viewing and creating archives
RPMs: file-roller file-roller-nautilus
Size: 3.79 MiB
Size change:  944 B
Changelog:
  * Mon Mar 11 2024 David King  - 44~beta-1
  - Update to 44.beta


Package:  gcr-4.2.1-1.fc40
Old package:  gcr-4.2.0-1.fc40
Summary:  A library for bits of crypto UI and parsing
RPMs: gcr gcr-devel gcr-libs
Size: 4.75 MiB
Size change:  4.22 KiB
Changelog:
  * Fri Mar 08 2024 David King  - 4.2.1-1
  - Update to 4.2.1


Package:  gnome-calculator-46~rc-1.fc40
Old package:  gnome-calculator-46~beta-1.fc40
Summary:  A desktop calculator
RPMs: gnome-calculator gnome-calculator-devel
Size: 7.75 MiB
Size change:  -1.64 KiB
Changelog:
  * Mon Mar 04 2024 David King  - 46~rc-1
  - Update to 46.rc


Package:  gnome-calendar-46~rc-1.fc40
Old package:  gnome-calendar-46~beta-2.fc40
Summary:  Simple and beautiful calendar application designed to fit GNOME 3
RPMs: gnome-calendar
Size: 2.14 MiB
Size change:  6.44 KiB
Changelog:
  * Sat Mar 09 2024 David King  - 46~rc-1
  - Update to 46.rc


Package:  gnome-connections-46~rc-1.fc40
Old package:  gnome-connections-46~beta-1.fc40
Summary:  A remote desktop client for the GNOME desktop environment
RPMs: gnome-connections
Size: 1.09 MiB
Size change:  37.13 KiB
Changelog:
  * Mon Mar 04 2024 David King  - 46~rc-1
  - Update to 46.rc


Package:  gnome-control-center-46~rc-1.fc40
Old package:  gnome-control-center-46~beta.2-1.fc40
Summary:  Utilities

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

[Dmitry Belyavskiy]

Dear Jun,

On Thu, Mar 21, 2024 at 2:29 PM Jun Aruga (he / him) 
wrote:

> On Thu, Mar 21, 2024 at 12:16 PM Dmitry Belyavskiy 
> wrote:
> >
> > Dear Jun,
> >
> >
> >
> > On Thu, Mar 21, 2024 at 11:04 AM Jun Aruga (he / him) 
> wrote:
> >>
> >> On Wed, Mar 20, 2024 at 2:36 PM Dmitry Belyavskiy 
> wrote:
> >> >
> >> ...
> >> >> > == 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.
> >>
> >> Hi Dmitry,
> >> Could you provide the upstream OpenSSL project's issue ticket(s) or
> >> pull-request(s) about the feature adding or updating the providers to
> >> cover all the functionalities that engines have?
> >> I would like to track the progress of the work.
> >
> >
> > I'm quite surprised.
> > I'm pretty sure that providers cover all the functionalities that
> engines have.
> > (It doesn't mean that for each an every engine exists a 1:1 replacing
> provider, but it's a question to the authors of these engines)
> >
> > If you are aware of any deficiencies, could you please let upstream or
> me know?
>
> Hi Dmitry,
> Sorry. Maybe I used the terminology "functionality" incorrectly.
> I am talking about some features that engines provided are missing in
> providers. I see the following issue tickets.
>
> * https://github.com/ruby/openssl/issues/722
>   > The Engine API was deprecated in OpenSSL 3 and there seems to be
> no alternatives for it at the moment using Provider API. The providers
> can only be loaded, but there seems to be no way to load keys using an
> uri (for ex. pkcs11 uri scheme)
>

I believe the pkcs11-provider is already capable of it.


> * https://github.com/ruby/openssl/issues/723
>   > GOST engine
>

I can say a lot about it in private. TL;DR - it's almost abandoned for many
reasons.

-- 
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: 20240321.n.0 changes

[Fedora Rawhide Report]

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

= SUMMARY =
Added images:3
Dropped images:  1
Added packages:  5
Dropped packages:0
Upgraded packages:   84
Downgraded packages: 0

Size of added packages:  554.60 KiB
Size of dropped packages:0 B
Size of upgraded packages:   4.58 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   3.11 MiB
Size change of downgraded packages: 0 B

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

= DROPPED IMAGES =
Image: Silverblue ociarchive ppc64le
Path: 
Silverblue/ppc64le/images/Fedora-Silverblue-Rawhide.20240320.n.0.ociarchive

= ADDED PACKAGES =
Package: python-superqt-0.6.2-1.fc41
Summary: Missing widgets and components for PyQt/PySide
RPMs:python3-superqt python3-superqt+pyqt6
Size:223.50 KiB

Package: rust-docker_credential-1.3.1-1.fc41
Summary: Reads a user's docker credentials from config
RPMs:rust-docker_credential+default-devel rust-docker_credential-devel
Size:24.26 KiB

Package: rust-fancy-regex0.11-0.11.0-1.fc41
Summary: An implementation of regexes, supporting a relatively rich set of 
features
RPMs:rust-fancy-regex0.11+default-devel 
rust-fancy-regex0.11+perf-cache-devel rust-fancy-regex0.11+perf-devel 
rust-fancy-regex0.11+perf-dfa-devel rust-fancy-regex0.11+perf-inline-devel 
rust-fancy-regex0.11+perf-literal-devel rust-fancy-regex0.11+track_caller-devel 
rust-fancy-regex0.11+unicode-devel rust-fancy-regex0.11-devel
Size:139.72 KiB

Package: rust-supports-color2-2.1.0-1.fc41
Summary: Detects whether a terminal supports color, and gives details about 
that support
RPMs:rust-supports-color2+default-devel rust-supports-color2-devel
Size:24.84 KiB

Package: rust-tree-sitter0.20-0.20.10-1.fc41
Summary: Rust bindings to the Tree-sitter parsing library
RPMs:rust-tree-sitter0.20+default-devel 
rust-tree-sitter0.20+lazy_static-devel rust-tree-sitter0.20-devel
Size:142.28 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  PDAL-2.7.0-1.fc41
Old package:  PDAL-2.6.3-1.fc40
Summary:  Point Data Abstraction Library
RPMs: PDAL PDAL-devel PDAL-doc PDAL-libs
Size: 45.38 MiB
Size change:  277.32 KiB
Changelog:
  * Wed Mar 13 2024 Sandro Mani  - 2.7.0-1
  - Update to 2.7.0


Package:  alacarte-3.52.0-1.fc41
Old package:  alacarte-3.50.0-3.fc40
Summary:  Menu editor for the GNOME desktop
RPMs: alacarte
Size: 169.17 KiB
Size change:  340 B
Changelog:
  * Thu Mar 21 2024 Yaakov Selkowitz  - 3.52.0-1
  - Update to 3.52.0


Package:  archlinux-keyring-20240313-1.fc41
Old package:  archlinux-keyring-20240208-1.fc40
Summary:  GPG keys used by Arch Linux distribution to sign packages
RPMs: archlinux-keyring
Size: 1.17 MiB
Size change:  -17 B
Changelog:
  * Wed Mar 20 2024 Frantisek Sumsal  - 20240313-1
  - Version 20240313 (rhbz#2269408)


Package:  atomes-1.1.14-1.fc41
Old package:  atomes-1.1.13-1.fc41
Summary:  An atomistic toolbox
RPMs: atomes
Size: 9.20 MiB
Size change:  22.71 KiB
Changelog:
  * Wed Mar 20 2024 S??bastien Le Roux  - 
1.1.14-1
  - Bug corrections and improvements (see: 
https://github.com/Slookeur/Atomes-GNU/releases/tag/v1.1.14)


Package:  aubio-0.4.9-21.fc41
Old package:  aubio-0.4.9-18.fc39
Summary:  An audio labeling tool
RPMs: aubio aubio-devel aubio-lib aubio-python3
Size: 2.69 MiB
Size change:  42.26 KiB
Changelog:
  * Fri Jan 19 2024 Fedora Release Engineering  - 
0.4.9-19
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Mon Jan 22 2024 Fedora Release Engineering  - 
0.4.9-20
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Wed Mar 20 2024 Nils Philippsen  - 0.4.9-21
  - Fix building on F40+ (rhbz#2260997)


Package:  containers-common-5:0.58.0-4.fc41
Old package:  containers-common-5:0.58.0-3.fc41
Summary:  Common configuration and documentation for containers
RPMs: containers-common containers-common-extra
Size: 112.30 KiB
Size change:  364 B
Changelog:
  * Wed Mar 20 2024 Lokesh Mandvekar  - 5:0.58.0-4
  - container-selinux should be a hard Requires


Package:  croaring-3.0.0-1.fc41
Old package:  croaring-2.1.2-3.fc40
Summary:  Roaring bitmaps in C (and C++), with SIMD (AVX2, AVX-512 and 
NEON) optimizations
RPMs: croaring croaring-devel
Size: 1.09 MiB
Size change:  145.38 KiB
Changelog:
  * Wed Mar 20 2024 topazus  - 3.0.0-1
  - update to 3.0.0


Package:  csmock-3.5.3-1.fc41
Old package:  csmock-3.5.2-1.fc41
Summary:  A mock wrapper

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

[Markku Korkeala]

On Thu, Mar 21, 2024 at 08:29:09AM +, Richard W.M. Jones wrote:
> On Wed, Mar 20, 2024 at 06:19:28PM -0400, 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/
> 
> Another alternative is that someone in the community might fork it.
> Can we stick with the last free version for a few months to see how
> the pieces fall?

Hi all,

just noticed one fork, might be worth keeping eye on:
https://codeberg.org/redict/redict

Best regards,
Markku

> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://people.redhat.com/~rjones/virt-top
> --
> ___
> 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)

[Clemens Lang]

Hi Jan,

> On 21. Mar 2024, at 14:28, Jun Aruga (he / him)  wrote:
> 
> 
> * https://github.com/ruby/openssl/issues/722
>> The Engine API was deprecated in OpenSSL 3 and there seems to be
> no alternatives for it at the moment using Provider API. The providers
> can only be loaded, but there seems to be no way to load keys using an
> uri (for ex. pkcs11 uri scheme)


As I understand that ticket, the functionality exists in OpenSSL, but ruby 
OpenSSL module does not expose it.

In any case, some providers are also providing workarounds for this problem. 
See for example https://github.com/latchset/pkcs11-provider/pull/328, which 
allows the PKCS11 provider to work everywhere where a simple PEM private key 
file is currently supported. With this, the Ruby OpenSSL module has all the 
time in the world to make the transition.


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

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

[Jun Aruga (he / him)]

On Thu, Mar 21, 2024 at 12:16 PM Dmitry Belyavskiy  wrote:
>
> Dear Jun,
>
>
>
> On Thu, Mar 21, 2024 at 11:04 AM Jun Aruga (he / him)  
> wrote:
>>
>> On Wed, Mar 20, 2024 at 2:36 PM Dmitry Belyavskiy  
>> wrote:
>> >
>> ...
>> >> > == 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.
>>
>> Hi Dmitry,
>> Could you provide the upstream OpenSSL project's issue ticket(s) or
>> pull-request(s) about the feature adding or updating the providers to
>> cover all the functionalities that engines have?
>> I would like to track the progress of the work.
>
>
> I'm quite surprised.
> I'm pretty sure that providers cover all the functionalities that engines 
> have.
> (It doesn't mean that for each an every engine exists a 1:1 replacing 
> provider, but it's a question to the authors of these engines)
>
> If you are aware of any deficiencies, could you please let upstream or me 
> know?

Hi Dmitry,
Sorry. Maybe I used the terminology "functionality" incorrectly.
I am talking about some features that engines provided are missing in
providers. I see the following issue tickets.

* https://github.com/ruby/openssl/issues/722
  > The Engine API was deprecated in OpenSSL 3 and there seems to be
no alternatives for it at the moment using Provider API. The providers
can only be loaded, but there seems to be no way to load keys using an
uri (for ex. pkcs11 uri scheme)
* https://github.com/ruby/openssl/issues/723
  > GOST engine

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
--
___
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] perl-Module-CoreList-5.20240320 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-Module-CoreList-5.2024
   ||0320-1.fc41
 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
Last Closed||2024-03-21 12:41:18



--- Comment #4 from Fedora Update System  ---
FEDORA-2024-7cb9db3084 (perl-Module-CoreList-5.20240320-1.fc41) has been pushed
to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Kevin Kofler via devel]

Stephen Smoogen wrote:
> There are two parts to this which users will see as 'slowness'. Part one
> is downloading the data from a mirror. Part two is uncompressing the data.
> In work I have been a part of, we have found that while xz gave us much
> smaller files, the time to uncompress was so much larger that our download
> gains were lost. Using zstd gave larger downloads (maybe 10 to 20% bigger)
> but uncompressed much faster than xz. This is data dependent though so it
> would be good to see if someone could test to see if xz uncompression of
> the datafiles will be too slow.

This very much depends on the speed of the local Internet connection vs. the 
speed of the user's CPU, so the tradeoff will unfortunately be different 
from user to user. Back in the delta RPM days, I have seen both sides of the 
tradeoff, with delta RPMs initially helping, then when my ISP gradually 
increased the bandwidth allocations while my computer was still the same, it 
more and more just making things worse. It works the same way for metadata 
compression, though I have not timed how that will work out for me 
personally.

That said, another part of the tradeoff is that, for some users, more to 
download means more money getting charged on their metered bandwidth plan. 
That is of course not an issue for those of us lucky enough to be on a 
flatrate broadband plan.

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

[Neal Gompa]

On Thu, Mar 21, 2024 at 8:20 AM Stephen Smoogen  wrote:
>
>
>
> On Wed, 20 Mar 2024 at 22:01, Kevin Kofler via devel 
>  wrote:
>>
>> 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.
>>
>
> There are two parts to this which users will see as 'slowness'. Part one is 
> downloading the data from a mirror. Part two is uncompressing the data. In 
> work I have been a part of, we have found that while xz gave us much smaller 
> files, the time to uncompress was so much larger that our download gains were 
> lost. Using zstd gave larger downloads (maybe 10 to 20% bigger) but 
> uncompressed much faster than xz. This is data dependent though so it would 
> be good to see if someone could test to see if xz uncompression of the 
> datafiles will be too slow.
>

Fedora has been using optimized zstd compression "by default" since
Fedora 30 anyway with Zchunk metadata:
https://fedoraproject.org/wiki/Changes/Zchunk_Metadata

Regular zstd compression is less optimized due to the lack of
dictionaries, but it's also effectively the fallback path, though much
faster to decompress while providing pretty good compression (which is
why we have been gradually switching *everything* to zstd).



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

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

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2024-1b24d0ba2e (perl-Module-CoreList-5.20240320-1.fc38) has been
submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-1b24d0ba2e


-- 
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%23c3
--
___
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

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

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2024-3699640048 (perl-Module-CoreList-5.20240320-1.fc39) has been
submitted as an update to Fedora 39.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-3699640048


-- 
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%23c2
--
___
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

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

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2024-7cb9db3084 (perl-Module-CoreList-5.20240320-1.fc41) has been
submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-7cb9db3084


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

[Stephen Smoogen]

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

> 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.
>
>
There are two parts to this which users will see as 'slowness'. Part one is
downloading the data from a mirror. Part two is uncompressing the data. In
work I have been a part of, we have found that while xz gave us much
smaller files, the time to uncompress was so much larger that our download
gains were lost. Using zstd gave larger downloads (maybe 10 to 20% bigger)
but uncompressed much faster than xz. This is data dependent though so it
would be good to see if someone could test to see if xz uncompression of
the datafiles will be too slow.




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


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
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

[Fedocal] Reminder meeting : ELN SIG

[sgallagh]

Dear all,

You are kindly invited to the meeting:
   ELN SIG on 2024-03-22 from 12:00:00 to 13:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:



Source: https://calendar.fedoraproject.org//meeting/10568/

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

[Dmitry Belyavskiy]

Dear Zbyszek,

On Thu, Mar 21, 2024 at 12:41 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Thu, Mar 21, 2024 at 12:15:43PM +0100, Dmitry Belyavskiy wrote:
>


> > > Hi Dmitry,
> > > Could you provide the upstream OpenSSL project's issue ticket(s) or
> > > pull-request(s) about the feature adding or updating the providers to
> > > cover all the functionalities that engines have?
> > > I would like to track the progress of the work.
> > >
> >
> > I'm quite surprised.
> > I'm pretty sure that providers cover all the functionalities that engines
> > have.
> > (It doesn't mean that for each an every engine exists a 1:1 replacing
> > provider, but it's a question to the authors of these engines)
> >
> > If you are aware of any deficiencies, could you please let upstream or me
> > know?
>
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MUFNAZT3IIVWPAYVNHP72SRL4XTKJRTY/
> ?
>

Unfortunately I don't agree. It doesn't contain any details: what was
tested and what has failed

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

[Zbigniew Jędrzejewski-Szmek]

On Thu, Mar 21, 2024 at 12:15:43PM +0100, Dmitry Belyavskiy wrote:
> Dear Jun,
> 
> 
> 
> On Thu, Mar 21, 2024 at 11:04 AM Jun Aruga (he / him) 
> wrote:
> 
> > On Wed, Mar 20, 2024 at 2:36 PM Dmitry Belyavskiy 
> > wrote:
> > >
> > ...
> > >> > == 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.
> >
> > Hi Dmitry,
> > Could you provide the upstream OpenSSL project's issue ticket(s) or
> > pull-request(s) about the feature adding or updating the providers to
> > cover all the functionalities that engines have?
> > I would like to track the progress of the work.
> >
> 
> I'm quite surprised.
> I'm pretty sure that providers cover all the functionalities that engines
> have.
> (It doesn't mean that for each an every engine exists a 1:1 replacing
> provider, but it's a question to the authors of these engines)
> 
> If you are aware of any deficiencies, could you please let upstream or me
> know?

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MUFNAZT3IIVWPAYVNHP72SRL4XTKJRTY/
?

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)

[Dmitry Belyavskiy]

Dear Jun,



On Thu, Mar 21, 2024 at 11:04 AM Jun Aruga (he / him) 
wrote:

> On Wed, Mar 20, 2024 at 2:36 PM Dmitry Belyavskiy 
> wrote:
> >
> ...
> >> > == 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.
>
> Hi Dmitry,
> Could you provide the upstream OpenSSL project's issue ticket(s) or
> pull-request(s) about the feature adding or updating the providers to
> cover all the functionalities that engines have?
> I would like to track the progress of the work.
>

I'm quite surprised.
I'm pretty sure that providers cover all the functionalities that engines
have.
(It doesn't mean that for each an every engine exists a 1:1 replacing
provider, but it's a question to the authors of these engines)

If you are aware of any deficiencies, could you please let upstream or me
know?

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

[Stephen Gallagher]

On Thu, Mar 21, 2024 at 6:28 AM Jan Staněk  wrote:

> Stephen Gallagher  writes:
> > That said, I agree that it's completely reasonable to have the default
> > version also `Provides: nodejsXX` and I'll look into it.
>
> Provides is something I did not consider at all, and it looks like the
> easiest way forward! Let me know when you get around to it;
> alternatively, I can throw together a package PR.
>


https://src.fedoraproject.org/rpms/nodejs20/pull-request/11

 I haven’t had time to properly test upgrades with that patch yet, so I’d
appreciate it if you could review the patch and help with upgrade testing.
--
___
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

[Jan Staněk]

Miro Hrončok  writes:
> 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.

Thanks for the suggestion, I did not think about provides at all
when mulling over the problem. Kudos!
--
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: Default NodeJS stream packages with versioned names are not available

[Jan Staněk]

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

Provides is something I did not consider at all, and it looks like the
easiest way forward! Let me know when you get around to it;
alternatively, I can throw together a package PR.

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

I meant having both versioned and unversioned packages for the *same*
(default) stream available. Probably really overkill if the provides
works.

> The overly-simplified answer here is mainly that there are too many
> symlinks to maintain for this to be practical.

Acknowledged; thanks for info.

--
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: Look for help: how to package Rust project

[Fabio Valentini]

On Thu, Mar 21, 2024 at 9:25 AM Richard W.M. Jones  wrote:
>
> On Thu, Mar 21, 2024 at 11:04:13AM +0800, Ming Lei wrote:
> > Hello Richard and Guys,
> >
> > I plan to package rublk to Fedora, and it is one Rust project.
>
> Hi, I'm on holiday at the moment, but please do look at how we
> packaged libblkio in Fedora:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2124697
>
> > 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?
>
> Everything has to start with a source tarball, so normally github
> would be the best source.
>
> > [1] https://github.com/ublk-org/rublk
> > [2] https://crates.io/crates/rublk

If the project is a single "crate" (i.e. one compilation unit) and
will continue to be published on crates.io, I would recommend using
the sources published there instead of GitHub sources. Using files
distributed via crates.io makes packaging a bit easier and avoids some
work that is necessary for non-crate Rust packages.

I would recommend reading the Rust packaging guidelines for this case:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_rust_crates
You should get a working spec file by just running "rust2rpm -s rublk".

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)

[Jun Aruga (he / him)]

On Wed, Mar 20, 2024 at 2:36 PM Dmitry Belyavskiy  wrote:
>
...
>> > == 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.

Hi Dmitry,
Could you provide the upstream OpenSSL project's issue ticket(s) or
pull-request(s) about the feature adding or updating the providers to
cover all the functionalities that engines have?
I would like to track the progress of the work.

Jun

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
--
___
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?

[Richard W.M. Jones]

On Wed, Mar 20, 2024 at 06:19:28PM -0400, 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/

Another alternative is that someone in the community might fork it.
Can we stick with the last free version for a few months to see how
the pieces fall?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
___
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: Look for help: how to package Rust project

[Richard W.M. Jones]

On Thu, Mar 21, 2024 at 11:04:13AM +0800, Ming Lei wrote:
> Hello Richard and Guys,
> 
> I plan to package rublk to Fedora, and it is one Rust project.

Hi, I'm on holiday at the moment, but please do look at how we
packaged libblkio in Fedora:

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

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

Everything has to start with a source tarball, so normally github
would be the best source.

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

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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

Contribute to Podman 5 Test Week 2024-03-21 through 2024-03-27

[Sumantro Mukherjee]

Hey Folks!

Fedora 40 is going to ship with Podman 5[0] and as part of this changeset,
there will be a lot of breaking changes which can affect your
container workflow.
To ensure a smooth transition, the Podman team and the Quality team of
Fedora have
decided to host a test week[1].

The idea is for users to test Podman 5 on a Fedora 40 Pre-release machine
and submit results in the Test Day App[2]. If you have spare cycles or use
Podman as a daily driver, it will be
great to have some folks try out and report bugs right away.


[0] https://fedoraproject.org/wiki/Changes/Podman5
[1] https://fedoraproject.org/wiki/Test_Day:2024-03-21_Podman_5
[2] https://testdays.fedoraproject.org/events/183

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