Re: Three steps we could take to make supply chain attacks a bit harder

[Carlos Rodriguez-Fernandez]

I was hesitant to have MFA for a while. Imagine losing a phone with tons 
of tokens. What a hassle to recover from that. I found it less than 
ideal for practical reasons.


However, I decided instead to buy two Yubikey (primary and backup), and 
I add the QRs to both of them with the Yubico App. I also screenshot my 
QRs, tar them, encrypt them with openssl and gpg, and upload them to two 
cloud locations also protected by MFA, and remove them from my computer. 
I repeat that when I add a new QR. I also have a txt together with the 
encrypted tars documenting the commands used to encrypt/decrypt so I 
remember the parameters to use. The reason I do that is to be able to 
load them into a new Yubikey in case I lose one.


There are alternative to Yubikeys if they are too expensive for some. I 
do find them a good investment in general, though. I found having 
Yubikeys (at least two), or other similar devices cheaper than phones, 
to be the most practical way to do MFA. You can even use those same 
Yubikeys to unlock hard drives (luks), and go passwordless for some 
applications.


On 4/11/24 17:09, Gary Buhrmaster wrote:

On Mon, Apr 1, 2024 at 1:10 AM Kilian Hanich via devel
 wrote:


2FA in a lot of cases is just access to a different account (e.g. email
or even SMS) and these normally aren't unique. Sure, there are other
ways like FIDO2, but these are not necessarily used (or liked, quite
frankly I know a lot of people who would loose them on a monthly basis,
but still are quite smart about other stuff).


Given that FIDO2 credentials can be stored
on your mobile device (and exchanged with
other devices), if those people are losing their
mobile devices every month they likely have
other issues (including a very expensive
mobile device replacement budget) for which
there is likely no viable solution.

FAS' use of TOTP 2FA is not a great solution
compared to FIDO2, and there are well known
attacks against TOTP 2FA, but even TOTP
2FA can reduce the doorknob rattling exploits.
As TOTP 2FA generators exist for most
mobile devices one will tend to have a
TOTP 2FA generator with one most of the
time.


To the Fedora leadership:

What is the best way to formally propose
that 2FA is required for packagers after
some date (I suppose we could have
different dates for PPs vs others if we
wanted to do that in order to get started
sooner).  Do we need a formal Change
Proposal to be voted on by someone?
It does not really seem like a FESCo
issue to me, but more of a policy issue
that might need to go to the Council?
I have no doubt that such a proposal
will be controversial with some, and
all those issues should get a (re-)airing
in front of those making the decision.
--
___
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


OpenPGP_signature.asc
Description: OpenPGP digital 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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-3cb841c5f0   
chromium-123.0.6312.105-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-a8b1cd8e52   
perl-Clipboard-0.29-1.el7


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

baresip-3.11.0-1.el7
libre-3.11.0-1.el7
nagios-plugins-2.4.9-1.el7

Details about builds:



 baresip-3.11.0-1.el7 (FEDORA-EPEL-2024-188537fb0b)
 Modular SIP user-agent with audio and video support

Update Information:

Baresip v3.11.0 (2024-04-09)
account: read catchall flag from accounts file
vp8/encode: optimizations and target_bitrate fix
vp8,vp9: fix deprecated decode codec init
aureceiver: fix mtx_unlock on discard
release v3.10.1
message: return 403 instead of 488
netroam/cmake: add optional netlink detection
ci/sanitizers: add mmap rnd_bits workaround
account: set inreq_allowed=yes as default
account: use correct format %zu for printing outbound
stream: fix empty rtcp_stats for rtx.ssrc reception reports
stream: avoid sanitizer warnings for strm->tx
avcodec: remove re_h264 extra header
play: err handling and ensure eof
stream: add stream_jbuf_stats()
sndfile: write correct sample rate to WAV header
tls: add session resumption setter
avcodec: use util function to decode H.264 STAP-A
mixausrc: fix ausrc resampling
ci/build: remove obsolete for loop
libre v3.11.0 (2024-04-09)
ci/clang-analyze: bump clang version and fix status-bugs
main: Flush list of deleted fhs on fd_poll errors
main: Use slist for fhs delete list
http/server: fix wrong sizeof in verify_msg
ci/sanitizers: add mmap rnd_bits workaround
rtcp: add printing of TWCC packet
include: add re_h264.h to re.h
sdp: add sdp media lattr apply function the same way as for rattr
av1: improve packetizer
test: minor H.264 improvements
tls: add session resumption setter
thread/posix: optimize handler and fix gcc arm32 warning
h264: fix for Annex-B bitstreams with 4-byte startcode
ci/arch: add armv7 check
main,httpauth: fix different from the declaration
httpauth: fix doxygen comment

ChangeLog:

* Thu Apr 11 2024 Robert Scheck  3.11.0-1
- Upgrade to 3.11.0 (#2274242)

References:

  [ 1 ] Bug #2274242 - baresip-3.11.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2274242
  [ 2 ] Bug #2274320 - libre-3.11.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2274320




 libre-3.11.0-1.el7 (FEDORA-EPEL-2024-188537fb0b)
 Generic library for real-time communications

Update Information:

Baresip v3.11.0 (2024-04-09)
account: read catchall flag from accounts file
vp8/encode: optimizations and target_bitrate fix
vp8,vp9: fix deprecated decode codec init
aureceiver: fix mtx_unlock on discard
release v3.10.1
message: return 403 instead of 488
netroam/cmake: add optional netlink detection
ci/sanitizers: add mmap rnd_bits workaround
account: set inreq_allowed=yes as default
account: use correct format %zu for printing outbound
stream: fix empty rtcp_stats for rtx.ssrc reception reports
stream: avoid sanitizer warnings for strm->tx
avcodec: remove re_h264 extra header
play: err handling and ensure eof
stream: add stream_jbuf_stats()
sndfile: write correct sample rate to WAV header
tls: add session resumption setter
avcodec: use util function to decode H.264 STAP-A
mixausrc: fix ausrc resampling
ci/build: remove obsolete for loop
libre v3.11.0 (2024-04-09)
ci/clang-analyze: bump clang version and fix status-bugs
main: Flush list of deleted fhs on fd_poll errors
main: Use slist for fhs delete list
http/server: fix wrong sizeof in verify_msg
ci/sanitizers: add mmap rnd_bits workaround
rtcp: add printing of TWCC packet
include: add re_h264.h to re.h
sdp: add sdp media lattr apply function the same way as for rattr
av1: improve packetizer
test: minor H.264 improvements
tls: add session resumption setter
thread/posix: optimize handler and fix gcc arm32 warning
h264: fix for Annex-B bitstreams with 4-byte startcode
ci/arch: add armv7 check
main,httpauth: fix different from the declaration
httpauth: fix doxygen comment

ChangeLog:

* Thu Apr 11 2024 Robert Scheck  3.11.0-1
- Upgrade to 3.11.0 (#2274320)

References:

  [ 1 ] Bug #2274242 - baresip-3.11.0 is available
   

Re: RFC: Django latest vs LTS maintenance plan

[Michel Lind]

On Fri, Apr 12, 2024 at 12:53:52AM +0200, Miro Hrončok wrote:
> 
> 
> On 11. 04. 24 22:41, Michel Lind wrote:
> > The different Django stacks are in the process of being updated so they
> > can be swapped without affecting dependents, by providing and
> > conflicting with the virtual `python-django-impl`; not only will this
> > allow us to swap one Django LTS for another in EPEL when the older one
> > EOLs, but it also allows those with dependencies that are not qualified
> > for the latest Django to swap to the LTS in Fedora
> 
> I saw this and I meant to ask: Why `python-django-impl`? Why not `Conflicts:
> pytohn3dist(django)`?
> 
Oh good point, that would work too. We'd still need to come up with
names for the bash-completion and doc subpackages though.

Best regards,

-- 
 _o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

Re: RFC: Django latest vs LTS maintenance plan

[Michel Lind]

On Fri, Apr 12, 2024 at 12:53:52AM +0200, Miro Hrončok wrote:
> 
> 
> On 11. 04. 24 22:41, Michel Lind wrote:
> > The different Django stacks are in the process of being updated so they
> > can be swapped without affecting dependents, by providing and
> > conflicting with the virtual `python-django-impl`; not only will this
> > allow us to swap one Django LTS for another in EPEL when the older one
> > EOLs, but it also allows those with dependencies that are not qualified
> > for the latest Django to swap to the LTS in Fedora
> 
> I saw this and I meant to ask: Why `python-django-impl`? Why not `Conflicts:
> pytohn3dist(django)`?
> 
Oh good point, that would work too. We'd still need to come up with
names for the bash-completion and doc subpackages though.

Best regards,

-- 
 _o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

[EPEL-devel] Re: EPEL-ANNOUNCE Incompatible Upgrade of singularity-ce in EPEL 7 / 8 / 9

[Jonathan Wright via epel-devel]

Thank you for the followup.

On Thu, Apr 11, 2024 at 7:51 PM David Trudgian via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> The singularity-ce incompatible upgrade has now been pushed to stable.
>
> This is the final announcement prescribed by the EPEL Incompatible
> Upgrades Policy:
>
>
> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
>
> Cheers,
>
> DT
>
>
> On 9 Feb 2024, at 10:45, David Trudgian  wrote:
> >
> > After approval in the last EPEL meeting [1], I have submitted an
> incompatible upgrade of singularity-ce to testing for EPEL 7, 8 & 9.
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-cbd86d2020
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-f299fbc570
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-05e20edbbf
> >
> > These updates upgrade singularity-ce from v3.11.5 to v4.1.1.
> >
> > The following incompatibilities should be noted by users:
> >
> > 1) Some functionality previously provided by the `singularity remote`
> command is split into new `singularity registry` and `singularity
> keyserver` commands.
> > 2) The `singularity remote add` command now sets a newly added remote as
> the default (unless suppressed). Previously the user had to set the default
> remote manually.
> > 3) The deprecated and unmaintained `—vm` flag to start singularity
> inside a Virtual Machine has been removed.
> >
> > 4) Bind mounts are now performed in the order in which they are
> specified. Previously, image based bind mounts were performed before others.
> > 5) Current working directory on the host is now created in the
> container, restoring a behaviour from Singularity <3.6.0 unless suppressed.
> > 6) If the current directory paths on the container and host contains
> symlinks to different locations, the current working directory is not
> mounted.
> >
> > Changes 1,2,3 are expected to have minimal impact, and 4,5,6 are likely
> to be considered bug fixes by many users.
> >
> > No changes are required to existing configuration files for this update.
> >
> > A complete description of changes and additions between v3.11 and v4.1.1
> is available in the upstream documentation at https://sylabs.io/docs/
> >
> > In the absence of any issues, the updates will be pushed to stable after
> a one week testing period has passed, with a follow-up notification here.
> >
> > Cheers,
> >
> > David Trudgian
> >
> >
> > [1] https://pagure.io/epel/issue/265#comment-894790
> > --
> > ___
> > epel-announce mailing list -- epel-annou...@lists.fedoraproject.org
> > To unsubscribe send an email to
> epel-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/epel-annou...@lists.fedoraproject.org
> > Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
> --
> ___
> 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
>


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

[EPEL-devel] Incompatible update of llhttp from 9.1.3 to 9.2.1 in EPEL9

[Ben Beasley]

I have just submitted for testing 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-ce142428af, 
which updates llhttp in EPEL9 from 9.1.3 to 9.2.1 and fixes 
CVE-2024-27982[1], an HTTP request smuggling vulnerability. Version 
9.2.0 also included a number of bug fixes[2]. This is an 
ABI-incompatible update, and the SONAME version changes.


Because the EPEL Steering Committee has previously approved a permanent 
exception for incompatible upgrades of llhttp, I have bypassed the usual 
proposal and discussion of this update on the epel-devel mailing list. 
However, I am following the other parts of the incompatible updates 
process: this announcement, at least one week in testing with auto-push 
disabled, and a follow-up announcement on this list once I have pushed 
the update to stable.


The only package in EPEL9 that uses llhttp is python-aiohttp; the update 
also backports support for llhttp 9.2.1 to the current aiohttp release, 
3.9.3. I expect that the aiohttp project will soon release a compatible 
patch release 3.9.4 that directly supports llhttp 9.2.1.


If you have software not packaged in EPEL9 that depends directly on 
llhttp, you will need to rebuild it due to the ABI changes. It is 
possible that source code changes may be required if (like 
python-aiohttp) you use almost the entire API of llhttp, or if you have 
very thorough tests that reveal small changes in llhttp’s behavior. 
Straightforward uses of llhttp are very likely to recompile without 
modification.


I have no plans to attempt a build of llhttp or any update of 
python-aiohttp in EPEL8.


[1] 
https://nodejs.org/en/blog/vulnerability/april-2024-security-releases/#http-request-smuggling-via-content-length-obfuscation---cve-2024-27982---medium


[2] https://github.com/nodejs/llhttp/releases/tag/release%2Fv9.2.0
--
___
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

[EPEL-devel] Re: EPEL-ANNOUNCE Incompatible Upgrade of singularity-ce in EPEL 7 / 8 / 9

[David Trudgian via epel-devel]

The singularity-ce incompatible upgrade has now been pushed to stable.

This is the final announcement prescribed by the EPEL Incompatible Upgrades 
Policy:

https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ 

Cheers,

DT


On 9 Feb 2024, at 10:45, David Trudgian  wrote:
> 
> After approval in the last EPEL meeting [1], I have submitted an incompatible 
> upgrade of singularity-ce to testing for EPEL 7, 8 & 9.
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-cbd86d2020
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-f299fbc570
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-05e20edbbf
> 
> These updates upgrade singularity-ce from v3.11.5 to v4.1.1.
> 
> The following incompatibilities should be noted by users:
> 
> 1) Some functionality previously provided by the `singularity remote` command 
> is split into new `singularity registry` and `singularity keyserver` commands.
> 2) The `singularity remote add` command now sets a newly added remote as the 
> default (unless suppressed). Previously the user had to set the default 
> remote manually.
> 3) The deprecated and unmaintained `—vm` flag to start singularity inside a 
> Virtual Machine has been removed.
> 
> 4) Bind mounts are now performed in the order in which they are specified. 
> Previously, image based bind mounts were performed before others.
> 5) Current working directory on the host is now created in the container, 
> restoring a behaviour from Singularity <3.6.0 unless suppressed.
> 6) If the current directory paths on the container and host contains symlinks 
> to different locations, the current working directory is not mounted.
> 
> Changes 1,2,3 are expected to have minimal impact, and 4,5,6 are likely to be 
> considered bug fixes by many users.
> 
> No changes are required to existing configuration files for this update.
> 
> A complete description of changes and additions between v3.11 and v4.1.1 is 
> available in the upstream documentation at https://sylabs.io/docs/
> 
> In the absence of any issues, the updates will be pushed to stable after a 
> one week testing period has passed, with a follow-up notification here.
> 
> Cheers,
> 
> David Trudgian
> 
> 
> [1] https://pagure.io/epel/issue/265#comment-894790
> --
> ___
> epel-announce mailing list -- epel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to epel-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/epel-annou...@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Adam Williamson]

On Fri, 2024-04-12 at 00:09 +, Gary Buhrmaster wrote:
> 
> What is the best way to formally propose
> that 2FA is required for packagers after
> some date

There is already a FESCo ticket. https://pagure.io/fesco/issue/3186 /
Please don't discuss there, discuss here; FESCo will vote in that
ticket or a meeting when they feel it appropriate.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Re: Three steps we could take to make supply chain attacks a bit harder

[Gary Buhrmaster]

On Mon, Apr 1, 2024 at 1:10 AM Kilian Hanich via devel
 wrote:

> 2FA in a lot of cases is just access to a different account (e.g. email
> or even SMS) and these normally aren't unique. Sure, there are other
> ways like FIDO2, but these are not necessarily used (or liked, quite
> frankly I know a lot of people who would loose them on a monthly basis,
> but still are quite smart about other stuff).

Given that FIDO2 credentials can be stored
on your mobile device (and exchanged with
other devices), if those people are losing their
mobile devices every month they likely have
other issues (including a very expensive
mobile device replacement budget) for which
there is likely no viable solution.

FAS' use of TOTP 2FA is not a great solution
compared to FIDO2, and there are well known
attacks against TOTP 2FA, but even TOTP
2FA can reduce the doorknob rattling exploits.
As TOTP 2FA generators exist for most
mobile devices one will tend to have a
TOTP 2FA generator with one most of the
time.


To the Fedora leadership:

What is the best way to formally propose
that 2FA is required for packagers after
some date (I suppose we could have
different dates for PPs vs others if we
wanted to do that in order to get started
sooner).  Do we need a formal Change
Proposal to be voted on by someone?
It does not really seem like a FESCo
issue to me, but more of a policy issue
that might need to go to the Council?
I have no doubt that such a proposal
will be controversial with some, and
all those issues should get a (re-)airing
in front of those making the decision.
--
___
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: [Rust] Re: Rust Stack Spring Cleaning - 2024 Edition

[Fabio Valentini]

On Thu, Apr 11, 2024 at 9:09 PM Michel Lind  wrote:
>
> > | rust-atomic-traits   | 2022-09-02 |   587 | salimma   
> >|
> Still trying to package mmtk, please keep this one for now

Then please follow up, the review request for mmtk was closed due to inactivity:
https://bugzilla.redhat.com/show_bug.cgi?id=2040994

> > | rust-signal  | 2023-02-23 |   413 | salimma   
> >|
> Not sure about this one. Looks like psutil depends on it, and ytop
> depends on psutil, but ytop is almost 4 years old... probably retire it

https://bugzilla.redhat.com/show_bug.cgi?id=2048155
Looks like pipewire bindings version < 0.7 depended on this, but
dropped the dependency with v0.7.

> > | rust-sptr| 2023-03-28 |   380 | salimma   
> >|
> This is needed by portable-atomic which is needed by pyo3, right?

sptr is a dev-dependency for portable-atomic only, and portable-atomic
tests can no longer be run from the published tarbals.
It might be ok to drop sptr.

> > | rust-xcb | 2023-05-10 |   337 | salimma   
> >|
> We can kill this I guess. Death to X

Looks like this used to be a dependency of x11-clipboard <0.7, but no
longer is as of v0.7.0.

> > | rust-powierza-coefficient| 2023-06-16 |   300 | salimma   
> >|
> I wonder what used it in the past. crates.io now only lists kn ... so
> yeah kill it

This was packaged for nu-command, but the dependency has since been dropped:
https://bugzilla.redhat.com/show_bug.cgi?id=2211278

> > | rust-wayland-commons | 2024-01-02 |   100 | salimma   
> >|
> Looks like wayland-{client,server} no longer needs this (since > 0.29).
> Kill.

Agree, this crate seems to have been dropped from wayland-rs.

> > | rust-nom-supreme | 2024-01-04 |98 | salimma   
> >|
> Can't find what's actually using it, maybe kill

This was packaged for wax:
https://bugzilla.redhat.com/show_bug.cgi?id=2174116
And was was packaged for nu-command:
https://bugzilla.redhat.com/show_bug.cgi?id=2174146

But wax no longer depends on nom-supreme as of v0.6.0.

> > | rust-vec1| 2024-01-04 |98 | salimma   
> >|
> Ditto - not sure what I needed this for, probably dropped upstream

Same here:
https://bugzilla.redhat.com/show_bug.cgi?id=2174097
This used to be a dependency of wax, but it was dropped as of v0.6.0

> > | rust-rlimit  | 2024-01-17 |85 | salimma   
> >|
> Ditto

Can't tell - the review request isn't marked as blocking anything.
https://bugzilla.redhat.com/show_bug.cgi?id=2258271

At least it's a dependency of "bsdutils":
https://crates.io/crates/bsdutils

So maybe it was part of the coreutils dependency tree for some of the
missing uu_* tools?

> > | rust-base32  | 2024-01-20 |82 | salimma   
> >|
> rbw needs this, still in progress

Noted, thank you for checking!

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: Rust Stack Spring Cleaning - 2024 Edition

[Fabio Valentini]

On Thu, Apr 11, 2024 at 7:45 PM Ben Beasley  wrote:
>
> The rust-circular-buffer crate was packaged as a dependency for bpftop,
> https://github.com/Netflix/bpftop.
>
> I won’t necessarily be packaging bpftop myself, but I know several
> parties are interested in doing so, and I expect it will happen soon one
> way or the other.

Thanks! I forgot about that, it's good to have this in writing.

> A few existing dependencies still need to be updated first:
>
>   Problem 1: nothing provides requested (crate(anyhow/default) >= 1.0.81
> with crate(anyhow/default) < 2.0.0~)
>   Problem 2: nothing provides requested (crate(libbpf-rs/default) >=
> 0.23.0 with crate(libbpf-rs/default) < 0.24.0~)
>   Problem 3: nothing provides requested (crate(libbpf-sys/default) >=
> 1.4.0 with crate(libbpf-sys/default) < 2.0.0~)
>   Problem 4: nothing provides requested (crate(ratatui) >= 0.26.1 with
> crate(ratatui) < 0.27.0~)
>   Problem 5: nothing provides requested (crate(ratatui/crossterm) >=
> 0.26.1 with crate(ratatui/crossterm) < 0.27.0~)
>   Problem 6: nothing provides requested (crate(tui-input/default) >=
> 0.8.0 with crate(tui-input/default) < 0.9.0~)

I can update anyhow tomorrow, that should be a simple update.
Michel said he'll be looking at libbpf-rs / libbpf-sys soon.
ratatui can be updated too, though it might require a compat package
for the current version
tui-input seems to be a new dependency.

Thank you for checking,
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: RFC: Django latest vs LTS maintenance plan

[Miro Hrončok]

On 11. 04. 24 22:41, Michel Lind wrote:

The different Django stacks are in the process of being updated so they
can be swapped without affecting dependents, by providing and
conflicting with the virtual `python-django-impl`; not only will this
allow us to swap one Django LTS for another in EPEL when the older one
EOLs, but it also allows those with dependencies that are not qualified
for the latest Django to swap to the LTS in Fedora


I saw this and I meant to ask: Why `python-django-impl`? Why not `Conflicts: 
pytohn3dist(django)`?


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

Re: RFC: Django latest vs LTS maintenance plan

[Miro Hrončok]

On 11. 04. 24 22:41, Michel Lind wrote:

The different Django stacks are in the process of being updated so they
can be swapped without affecting dependents, by providing and
conflicting with the virtual `python-django-impl`; not only will this
allow us to swap one Django LTS for another in EPEL when the older one
EOLs, but it also allows those with dependencies that are not qualified
for the latest Django to swap to the LTS in Fedora


I saw this and I meant to ask: Why `python-django-impl`? Why not `Conflicts: 
pytohn3dist(django)`?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] RFC: Proposing incompatible upgrade of python-asgiref from 3.4.1 to 3.7.2

[Michel Lind]

Dear all,

Django 4.2 (the only currently supported LTS series) requires asgiref >=
3.6, so I would like to propose updating python-asgiref in EPEL 9 at
least to 3.6.0, but ideally to 3.8.1 for future proofing.

The affected packages (maintainers bcc:ed) are python-django3 (which I
maintain, and has just reached EOL) and python-opentelemetry

❯ fedrq whatrequires 'python3dist(asgiref)' -b epel9
python-django3-3.2.20-3.el9.src   
python-opentelemetry-1.12.0-8.el9.src

❯ fedrq pkgs --src -P python-django3 -F requires -b epel9 | grep asgi
python3dist(asgiref) >= 3.3.2
(python3dist(asgiref) < 4~~ with python3dist(asgiref) >= 3.3.2)

❯ fedrq pkgs --src -P python-opentelemetry -F requires -b epel9 | grep asgi
(python3dist(asgiref) >= 3 with python3dist(asgiref) < 4)

The relevant breaking changes seem to be (starting from the safest
option of upgrading only to 3.6.0)

https://github.com/django/asgiref/blob/main/CHANGELOG.txt

* 3.6.0
  Support for the ``ASGI_THREADS`` environment variable, used by
  ``SyncToAsync``, is removed. In general, a running event-loop is not
  available to `asgiref` at import time, and so the default thread pool
  executor cannot be configured. Protocol servers, or applications, should set
  the default executor as required when configuring the event loop at
  application startup.

I don't see anything that could be breaking in 3.7.x and 3.8.x, but PTAL

Note that Fedora's opentelemetry 1.24 has not bumped its asgiref
requirement, so we are probably OK leaving it as is

❯ fedrq pkgs --src -P python-opentelemetry -F requires | grep asgi
python3dist(asgiref)
(python3dist(asgiref) >= 3 with python3dist(asgiref) < 4)

❯ fedrq pkgs --src python-opentelemetry 
python-opentelemetry-1.24.0-3.fc41.src

Best regards,

-- 
 _o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

Re: Merging /usr/sbin to /usr/bin

[Brian C. Lane]

On Thu, Apr 11, 2024 at 01:39:32PM +, Zbigniew Jędrzejewski-Szmek wrote:
>https://src.fedoraproject.org/rpms/filesystem/pull-request/11

The commit "Symlink /usr/sbin to /usr/bin if possible" would wipe out
any symlinks in /usr/sbin that point someplace other than /usr/bin when
everything becomes a symlink. It should make sure they all point to
where you expect before removing them all.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
--
___
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

RFC: Django latest vs LTS maintenance plan

[Michel Lind]

Hi all,

With the recent EOL of the Django 3.2 LTS series[^1], and Django being a
key component of our mailing list infra for both Fedora and CentOS, I
would like to propose the following plan to maintain Django in both
Fedora and EPEL:

- Fedora: `python-django` maintained as currently, not tracking any LTS
  series
  - **but** also fork off `python-django` each time it hits an LTS
series to make a new `python-djangoX.Y` (e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=2274198)
- LTS packages are introduced in Fedora first, until they either reach
  EOL or no longer build, at which point they are retired in Rawhide.
  See below for the EOL case.
- EPEL: we will only branch LTS packages (as is the case now, with
  `python-django3` - though under the new naming scheme it should have
  been `python-django3.2`)
- Handling EOL
- not an issue for `python-django` - we just keep rebasing it
- for LTS releases in Fedora, retire in Rawhide if the series will
  EOL before the EOL of the upcoming Fedora release
- for LTS releases in EPEL, once it is EOL (like `python-django3`)
  we mark it as `Provides: deprecated()` and retire it if there is a
  replacement that works with add-on packages, *and* there is a CVE
  that is not fixed
- Package ACL: cc-ing the current maintainers of python-django here.
  Please let me know if
  - you want to be added to the LTS packages as well
  - you want to be removed from python-django
  - you're not currently involved but want to help out
  - I'll also add infra-sig to the ACL for the LTS packages, as in
practice they might need access to fix any issue affecting Mailman

The different Django stacks are in the process of being updated so they
can be swapped without affecting dependents, by providing and
conflicting with the virtual `python-django-impl`; not only will this
allow us to swap one Django LTS for another in EPEL when the older one
EOLs, but it also allows those with dependencies that are not qualified
for the latest Django to swap to the LTS in Fedora

Let me know if this makes sense, or if you have ideas of how to handle
some of these better.

[^1]: https://www.djangoproject.com/weblog/2024/apr/03/bugfix-release/

Best regards,

-- 
 _o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

[EPEL-devel] RFC: Django latest vs LTS maintenance plan

[Michel Lind]

Hi all,

With the recent EOL of the Django 3.2 LTS series[^1], and Django being a
key component of our mailing list infra for both Fedora and CentOS, I
would like to propose the following plan to maintain Django in both
Fedora and EPEL:

- Fedora: `python-django` maintained as currently, not tracking any LTS
  series
  - **but** also fork off `python-django` each time it hits an LTS
series to make a new `python-djangoX.Y` (e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=2274198)
- LTS packages are introduced in Fedora first, until they either reach
  EOL or no longer build, at which point they are retired in Rawhide.
  See below for the EOL case.
- EPEL: we will only branch LTS packages (as is the case now, with
  `python-django3` - though under the new naming scheme it should have
  been `python-django3.2`)
- Handling EOL
- not an issue for `python-django` - we just keep rebasing it
- for LTS releases in Fedora, retire in Rawhide if the series will
  EOL before the EOL of the upcoming Fedora release
- for LTS releases in EPEL, once it is EOL (like `python-django3`)
  we mark it as `Provides: deprecated()` and retire it if there is a
  replacement that works with add-on packages, *and* there is a CVE
  that is not fixed
- Package ACL: cc-ing the current maintainers of python-django here.
  Please let me know if
  - you want to be added to the LTS packages as well
  - you want to be removed from python-django
  - you're not currently involved but want to help out
  - I'll also add infra-sig to the ACL for the LTS packages, as in
practice they might need access to fix any issue affecting Mailman

The different Django stacks are in the process of being updated so they
can be swapped without affecting dependents, by providing and
conflicting with the virtual `python-django-impl`; not only will this
allow us to swap one Django LTS for another in EPEL when the older one
EOLs, but it also allows those with dependencies that are not qualified
for the latest Django to swap to the LTS in Fedora

Let me know if this makes sense, or if you have ideas of how to handle
some of these better.

[^1]: https://www.djangoproject.com/weblog/2024/apr/03/bugfix-release/

Best regards,

-- 
 _o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


signature.asc
Description: PGP signature
--
___
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

RFC: Django latest vs LTS maintenance plan

[Michel Lind]

Hi all,

With the recent EOL of the Django 3.2 LTS series[^1], and Django being a
key component of our mailing list infra for both Fedora and CentOS, I
would like to propose the following plan to maintain Django in both
Fedora and EPEL:

- Fedora: `python-django` maintained as currently, not tracking any LTS
  series
  - **but** also fork off `python-django` each time it hits an LTS
series to make a new `python-djangoX.Y` (e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=2274198)
- LTS packages are introduced in Fedora first, until they either reach
  EOL or no longer build, at which point they are retired in Rawhide.
  See below for the EOL case.
- EPEL: we will only branch LTS packages (as is the case now, with
  `python-django3` - though under the new naming scheme it should have
  been `python-django3.2`)
- Handling EOL
- not an issue for `python-django` - we just keep rebasing it
- for LTS releases in Fedora, retire in Rawhide if the series will
  EOL before the EOL of the upcoming Fedora release
- for LTS releases in EPEL, once it is EOL (like `python-django3`)
  we mark it as `Provides: deprecated()` and retire it if there is a
  replacement that works with add-on packages, *and* there is a CVE
  that is not fixed
- Package ACL: cc-ing the current maintainers of python-django here.
  Please let me know if
  - you want to be added to the LTS packages as well
  - you want to be removed from python-django
  - you're not currently involved but want to help out
  - I'll also add infra-sig to the ACL for the LTS packages, as in
practice they might need access to fix any issue affecting Mailman

The different Django stacks are in the process of being updated so they
can be swapped without affecting dependents, by providing and
conflicting with the virtual `python-django-impl`; not only will this
allow us to swap one Django LTS for another in EPEL when the older one
EOLs, but it also allows those with dependencies that are not qualified
for the latest Django to swap to the LTS in Fedora

Let me know if this makes sense, or if you have ideas of how to handle
some of these better.

[^1]: https://www.djangoproject.com/weblog/2024/apr/03/bugfix-release/

Best regards,

-- 
 _o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

[Test-Announce] Fedora Linux 40 Final NO-GO

[Aoife Moloney]

Due to outstanding blocker bugs[1], the Fedora Linux 40 Final RC -1.13
was declared NO-GO in today's meeting[2][3].

The next Fedora Linux 40 Final Go/No-Go meeting[4] will be held at
1700 UTC on Thursday 18th April in #meeting:fedoraproject.org on
Matrix.

The new target date for the F40 Final release is now Tuesday 23rd
April. The schedule[5] has been updated accordingly.


[1] https://qa.fedoraproject.org/blockerbugs/milestone/40/final/buglist
[2] HTML Log:
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-11/f40-final-go-no-go-meeting.2024-04-11-17.00.log.html
[3] Text Log(minutes):
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-11/f40-final-go-no-go-meeting.2024-04-11-17.00.txt
[4] https://calendar.fedoraproject.org/meeting/10791/
[5] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.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: Rust Stack Spring Cleaning - 2024 Edition

[Michel Lind]

On Thu, Apr 11, 2024 at 01:45:26PM -0400, Ben Beasley wrote:
> The rust-circular-buffer crate was packaged as a dependency for bpftop,
> https://github.com/Netflix/bpftop.
> 
> I won’t necessarily be packaging bpftop myself, but I know several parties
> are interested in doing so, and I expect it will happen soon one way or the
> other.
> 
> A few existing dependencies still need to be updated first:
> 
>  Problem 1: nothing provides requested (crate(anyhow/default) >= 1.0.81 with
> crate(anyhow/default) < 2.0.0~)
>  Problem 2: nothing provides requested (crate(libbpf-rs/default) >= 0.23.0
> with crate(libbpf-rs/default) < 0.24.0~)
>  Problem 3: nothing provides requested (crate(libbpf-sys/default) >= 1.4.0
> with crate(libbpf-sys/default) < 2.0.0~)
>  Problem 4: nothing provides requested (crate(ratatui) >= 0.26.1 with
> crate(ratatui) < 0.27.0~)
>  Problem 5: nothing provides requested (crate(ratatui/crossterm) >= 0.26.1
> with crate(ratatui/crossterm) < 0.27.0~)
>  Problem 6: nothing provides requested (crate(tui-input/default) >= 0.8.0
> with crate(tui-input/default) < 0.9.0~)
> 
Speaking of all the bpf* - I have a TODO (will ping the chat too) to
update below, which I expect will require a lot of libbpf-* to be
updated.

For ratatui -- nu-explore >= 0.91.0 needs 0.26, but I dropped it to 0.25
instead, trying to remember why.

Ah... because dua-cli, gimoji, and tui-react needs the old one

❯ fedrq-cratedeps-verbose.sh ratatui
rust-dua-cli : (crate(ratatui) >= 0.25.0 with crate(ratatui) < 0.26.0~)
rust-gimoji : (crate(ratatui/default) >= 0.25.0 with crate(ratatui/default) < 
0.26.0~)
rust-nu-explore : (crate(ratatui/default) >= 0.25.0 with crate(ratatui/default) 
< 0.26.0~)
rust-tui-react : (crate(ratatui) >= 0.25.0 with crate(ratatui) < 0.26.0~)

Best,

-- 
 _o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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: Rust Stack Spring Cleaning - 2024 Edition

[Michel Lind]

Hi Fabio,

On Thu, Apr 11, 2024 at 03:26:13PM +0200, Fabio Valentini wrote:
> If you know of a reason why a leaf package where I am the primary
> maintainer should not be retired, please let me know, and I will
> exclude it from the list.
>
Thanks for organizing the cleanup!

> 
> +--++---+--+
> | Package  | Leaf since | Leaf days | Maintainer  
>  |
> +--++---+--+
> | rust-atomic-traits   | 2022-09-02 |   587 | salimma 
>  |
Still trying to package mmtk, please keep this one for now

> | rust-signal  | 2023-02-23 |   413 | salimma 
>  |
Not sure about this one. Looks like psutil depends on it, and ytop
depends on psutil, but ytop is almost 4 years old... probably retire it

> | rust-sptr| 2023-03-28 |   380 | salimma 
>  |
This is needed by portable-atomic which is needed by pyo3, right?

> | rust-xcb | 2023-05-10 |   337 | salimma 
>  |
We can kill this I guess. Death to X

> | rust-powierza-coefficient| 2023-06-16 |   300 | salimma 
>  |
I wonder what used it in the past. crates.io now only lists kn ... so
yeah kill it

> | rust-wayland-commons | 2024-01-02 |   100 | salimma 
>  |
Looks like wayland-{client,server} no longer needs this (since > 0.29).
Kill.

> | rust-nom-supreme | 2024-01-04 |98 | salimma 
>  |
Can't find what's actually using it, maybe kill

> | rust-vec1| 2024-01-04 |98 | salimma 
>  |
Ditto - not sure what I needed this for, probably dropped upstream

> | rust-async-process   | 2024-01-07 |95 | decathorpe  
>  |
> | rust-notify-debouncer-mini   | 2024-01-07 |95 | decathorpe  
>  |
> | rust-safetensors | 2024-01-07 |95 | thunderbirdtr   
>  |
> | rust-unidecode   | 2024-01-15 |87 | decathorpe  
>  |
> | rust-rlimit  | 2024-01-17 |85 | salimma 
>  |
Ditto

> | rust-base32  | 2024-01-20 |82 | salimma 
>  |
rbw needs this, still in progress

> 
> - salimma (10): rust-atomic-traits, rust-base32, rust-nom-supreme,
> rust-powierza-coefficient, rust-rlimit, rust-signal, rust-sptr,
> rust-vec1, rust-wayland-commons, rust-xcb
> 
Best,

-- 
 _o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

[Bug 2257224] perl-Clipboard: clipbrowse command execution with multi-line clipboard text including "| sh" [epel-all]

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-EPEL-2024-6ebc36e81d has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-6ebc36e81d

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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202257224%23c9
--
___
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: Rust Stack Spring Cleaning - 2024 Edition

[Ben Beasley]

The rust-circular-buffer crate was packaged as a dependency for bpftop, 
https://github.com/Netflix/bpftop.


I won’t necessarily be packaging bpftop myself, but I know several 
parties are interested in doing so, and I expect it will happen soon one 
way or the other.


A few existing dependencies still need to be updated first:

 Problem 1: nothing provides requested (crate(anyhow/default) >= 1.0.81 
with crate(anyhow/default) < 2.0.0~)
 Problem 2: nothing provides requested (crate(libbpf-rs/default) >= 
0.23.0 with crate(libbpf-rs/default) < 0.24.0~)
 Problem 3: nothing provides requested (crate(libbpf-sys/default) >= 
1.4.0 with crate(libbpf-sys/default) < 2.0.0~)
 Problem 4: nothing provides requested (crate(ratatui) >= 0.26.1 with 
crate(ratatui) < 0.27.0~)
 Problem 5: nothing provides requested (crate(ratatui/crossterm) >= 
0.26.1 with crate(ratatui/crossterm) < 0.27.0~)
 Problem 6: nothing provides requested (crate(tui-input/default) >= 
0.8.0 with crate(tui-input/default) < 0.9.0~)


Some of these might just reflect over-aggressive bounds from dependabot 
that could be loosened downstream, but other minimum versions are likely 
real.


On 4/11/24 9:26 AM, Fabio Valentini wrote:

Hello Rust packagers,

I'm continuously working on reducing unnecessary accumulation of cruft
in the Rust package stack in Fedora, and I have been keeping track of
unused library packages for almost three years now.

Some of these packages have been unused leaves for over two years!

I will again start being more proactive with orphaning / retiring
affected packages where I am the primary maintainer, starting
incrementally from the packages which have been unused for the longest
time - unless I know of a reason to keep a specific package, for
example:

- something that depends on the package is still going through package review
- the package was updated to a "breaking" release and a compat package
was created, and now the "main" package is not depended on while the
compat package is in use

If you know of a reason why a leaf package where I am the primary
maintainer should not be retired, please let me know, and I will
exclude it from the list.

For packages where I am *not* the primary maintainer, I need help:

- Is this package still required for something that I don't know
about, or can it be dropped?
- Was it added as a dependency for something else, but packaging this
"something else" was abandoned?
- Was it needed at the time, but is the library no longer needed now?

Keeping unused packages around only makes maintenance of the Rust
stack more difficult due to the more "dense" dependency graph that
needs to be considered when pushing "breaking" changes. Over the past
year or so, the number of Rust packages in Fedora has grown by almost
50% from about 2200 to over 3000, which is making this issue worse.

Full report included below (view in monospace font for correct formatting).

Thank you for your help,
Fabio

+--++---+--+
| Package  | Leaf since | Leaf days | Maintainer   |
+--++---+--+
| rust-curve25519-dalek| 2021-11-18 |   875 | dcavalca |
| rust-gstreamer-editing-services  | 2021-11-18 |   875 | atim |
| rust-gstreamer-player| 2021-11-18 |   875 | atim |
| rust-rand_jitter | 2021-11-18 |   875 | jistone  |
| rust-rand_os | 2021-11-18 |   875 | jistone  |
| rust-tower-test  | 2021-11-18 |   875 | decathorpe   |
| rust-tower-util  | 2021-11-18 |   875 | decathorpe   |
| rust-partial-io  | 2022-02-06 |   795 | decathorpe   |
| rust-minimad | 2022-02-18 |   783 | dcavalca |
| rust-libhandy| 2022-02-20 |   781 | decathorpe   |
| rust-tiger   | 2022-02-20 |   781 | decathorpe   |
| rust-rand_hc | 2022-02-21 |   780 | jistone  |
| rust-benfred-read-process-memory | 2022-02-27 |   774 | dcavalca |
| rust-custom_error| 2022-02-27 |   774 | dcavalca |
| rust-madvr_parse | 2022-02-27 |   774 | dcavalca |
| rust-os-release  | 2022-02-27 |   774 | dcavalca |
| rust-strict  | 2022-02-27 |   774 | dcavalca |
| rust-subprocess  | 2022-02-27 |   774 | dcavalca |
| rust-libxml  | 2022-04-07 |   735 | decathorpe   |
| rust-snake_case  | 2022-04-25 |   717 | decathorpe   |
| rust-openat-ext  | 2022-04-28 |   714 | walters  |
| rust-log-mdc | 2022-05-05 |   707 | decathorpe   |
| 

Re: Self Introduction: Aditi Mishra

[Dan Horák]

Hello Aditi,

On Thu, 11 Apr 2024 22:31:41 +0530
Aditi Mishra  wrote:

> Hello everyone,
> 
> I'm very new to open-source world however I'm willing and passionate 
> candiate to work with you all. I had worked in the field of linux 
> scheduler area as an intern. Willing to learn fedora packing and wants 
> to contribute my work in future journey of fedora.
> 
> Looking forward for your help.

welcome in the community :-) Feel free to reach me in case of any
Fedora related questions.


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

Self Introduction: Aditi Mishra

[Aditi Mishra]

Hello everyone,

I'm very new to open-source world however I'm willing and passionate 
candiate to work with you all. I had worked in the field of linux 
scheduler area as an intern. Willing to learn fedora packing and wants 
to contribute my work in future journey of fedora.


Looking forward for your help.

Thanks and regards,

Aditi
--
___
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: Merging /usr/sbin to /usr/bin

[Zbigniew Jędrzejewski-Szmek]

On Thu, Apr 11, 2024 at 04:29:19PM +0200, David Sastre wrote:
> Not sure if SELinux policy needs to learn about the merge as well.
> Currently, `sudo semanage fcontext -l | rg bin.*=` shows:
> 
> ```
> /sbin = /usr/sbin
> /bin = /usr/bin
> ```
> 
> And there are executables in both /usr/bin and /usr/sbin with specific
> labels

Oh, SELinux. I filed this is a dicusssion starter:
https://github.com/fedora-selinux/selinux-policy/pull/2077

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: convert everything to rpmautospec?

[Pierre-Yves Chibon]

On Thu, Apr 11, 2024 at 09:18:09AM +0200, Ondrej Mosnáček wrote:
> On Wed, 10 Apr 2024 at 16:30, Pierre-Yves Chibon  wrote:
> [...]
> > Let's look at it in another way: would you say that the people who leaved 
> > in the
> > 14th century were liars for saying that the earth is flat?
> > No, they just didn't know.
> 
> Off-topic and not really affecting the validity of your point, but the
> idea that people in the 14th century / Middle Ages generally believed
> that the earth was flat is a myth. I recently read about it in the
> book "Fake History: 101 Things that Never Happened" by Jo Teeuwisse
> (great book, BTW!), but also Wikipedia happens to have a decent
> article about it: https://en.wikipedia.org/wiki/Myth_of_the_flat_Earth

I stand corrected, maybe "we believed earth was the center of the universe"
would have worked better?
Or something related to medicine?

Anyway, as you said, the point was: context changes and that doesn't make
what someone said a lie.


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

soname bump: mupdf 1.24.1 coming to rawhide and F40

[Michael J Gruber]

Hi there,

1.24.0 was followed by a mostly bugfix minor release 1.24.1, which
bumped soname, though. I have been using this locally (first on F39,
then on F40 beta) for a while now so that I'm confident we can bring
it to both rawhide and F40. (Also, upstream has slowed down since...).

I built mupdf in a side-tag for rawhide and F40, and will rebuild the following
dependencies:

python-PyMuPDF
zathura-pdf-mupdf

There is one more dependency that I'm aware of. Since I don't have
commit rights I filed a PR:

https://src.fedoraproject.org/rpms/qpdfview/pull-request/5

In case I missed a dependency feel free to:

fedpkg build --target=f41-build-side-87501
fedpkg build --target=f40-build-side-87511

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

Fedora 40 compose report: 20240411.n.0 changes

[Fedora Branched Report]

OLD: Fedora-40-20240410.n.0
NEW: Fedora-40-20240411.n.0

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

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

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

= ADDED IMAGES =
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-40-20240411.n.0.aarch64.raw.xz

= DROPPED IMAGES =
Image: Kinoite ociarchive ppc64le
Path: Kinoite/ppc64le/images/Fedora-Kinoite-40.20240410.n.0.ociarchive
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-40-20240410.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

Re: Idea: pynose as drop-in replacement for nose

[Sandro]

On 11-04-2024 15:30, Sandro wrote:

I see "# Package doesn't provide any tests" in the %check section.
That certainly feels a bit dodgy. This successor of a test framework 
decided to ditch all of the tests it used to have? That is certainly a 
red flag.


More like a chicken and egg story, maybe? If I were to provide a testing 
framework, I'd very much like to use that testing framework for testing.




Anyway, I'll contact upstream asking them about it. It's the least I can 
do. I'll also ask about the documentation link on PyPI, which points to 
the RTD page of ye olde .


Upstream uses GitHub Actions for testing. I haven't looked into how 
those are set up. Apparently they also test with pynose on SeleniumBase 
(same maintainer, see elsewhere in this thread).


While this still not provides us with the ability to test downstream, 
all tests I've run while investigating the feasibility of my idea so far 
haven't brought up any issues.


If anyone wants to chime in, here is the ticket:

https://github.com/mdmintz/pynose/issues/25

Last but not least, the documentation link on PyPI was fixed right away 
and will be in the next release.


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

Re: Idea: pynose as drop-in replacement for nose

[Sandro]

On 11-04-2024 15:49, Ben Beasley wrote:
For a proposed nose successor, pynose doesn’t seem to have gained much 
community traction so far: it has seven stars on GitHub[1] (compared to 
770 for nose2, which itself was never that widely adopted and has fewer 
than ten dependent packages in Fedora); and the imperfect but fairly 
useful reverse dependency index at Wheelodex[2] shows only three 
packages that explicitly depend on it.


Well, Wheelodex doesn't show pysb. They have just switched from nose to 
pynose. When looking into updating the package to the latest release the 
noses were no longer aligned (pun intended). That's how I started 
looking into pynose.


As far as I can tell, pynose exists because SeleniumBase[3] found it 
easier to fork nose than to port away from it. I’m *definitely* not 
saying we should only package things with a bunch of GitHub stars, but I 
do have some concerns about whether or not pynose is going to remain a 
generally-useful project in the medium-to-long term.


I think you are right there. The current maintainer of pynose is also 
a/the maintainer of SeleniumBase.


Currently, pynose is seeing regular releases - seven since May 2023. 
When I just inquired regarding unit tests, I received a response within 
minutes. This might just be coincidence. But it shows the project is alive.


Regarding usefulness, almost all packages in Fedora still depending on 
nose worked out of the box when I tested with a build of pynose 
mimicking nose also in the Python meta data. Two packages I couldn't 
test since they are currently FTBFS. One package, pycdio, is using 
`%python3 setup.py nosetests`. I have not yet looked into why that works 
with nose but not with pynose. But that line could simply be changed 
back to `nosetests -v`.


I think the takeaway here is swapping an unmaintained package for a 
maintained package. How widely it will get adopted seems lees important 
to me. The future will tell.



[1] https://github.com/mdmintz/pynose/stargazers

[2] https://www.wheelodex.org/projects/pynose/rdepends/

[3] https://github.com/seleniumbase/SeleniumBase


-- Sandro

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

Re: Merging /usr/sbin to /usr/bin

[David Sastre]

Not sure if SELinux policy needs to learn about the merge as well.
Currently, `sudo semanage fcontext -l | rg bin.*=` shows:

```
/sbin = /usr/sbin
/bin = /usr/bin
```

And there are executables in both /usr/bin and /usr/sbin with specific
labels, e.g. `sudo semanage fcontext -l | rg bin/.*virt`

```
/usr/bin/imagefactory  regular file
system_u:object_r:virtd_exec_t:s0
/usr/bin/imgfac\.pyregular file
system_u:object_r:virtd_exec_t:s0
/usr/bin/nova-compute  regular file
system_u:object_r:virtd_exec_t:s0
/usr/bin/qemu-ga   regular file
system_u:object_r:virt_qemu_ga_exec_t:s0
/usr/bin/qemu-pr-helperregular file
system_u:object_r:virtd_exec_t:s0
/usr/bin/qemu-storage-daemon   regular file
system_u:object_r:virtd_exec_t:s0
/usr/bin/vios-proxy-guest  regular file
system_u:object_r:virtd_exec_t:s0
/usr/bin/vios-proxy-host   regular file
system_u:object_r:virtd_exec_t:s0
/usr/bin/virt-who  regular file
system_u:object_r:virtd_exec_t:s0
/usr/sbin/condor_vm-gahp   regular file
system_u:object_r:virtd_exec_t:s0
/usr/sbin/fence_virtd  regular file
system_u:object_r:fenced_exec_t:s0
/usr/sbin/libvirt-qmf  regular file
system_u:object_r:virt_qmf_exec_t:s0
/usr/sbin/libvirtd regular file
system_u:object_r:virtd_exec_t:s0
/usr/sbin/virtinterfaced   regular file
system_u:object_r:virtinterfaced_exec_t:s0
/usr/sbin/virtlockdregular file
system_u:object_r:virtlogd_exec_t:s0
/usr/sbin/virtlogd regular file
system_u:object_r:virtlogd_exec_t:s0
/usr/sbin/virtlxcd regular file
system_u:object_r:virtd_lxc_exec_t:s0
/usr/sbin/virtnetworkd regular file
system_u:object_r:virtnetworkd_exec_t:s0
/usr/sbin/virtnodedevd regular file
system_u:object_r:virtnodedevd_exec_t:s0
/usr/sbin/virtnwfilterdregular file
system_u:object_r:virtnwfilterd_exec_t:s0
/usr/sbin/virtproxyd   regular file
system_u:object_r:virtproxyd_exec_t:s0
/usr/sbin/virtqemudregular file
system_u:object_r:virtqemud_exec_t:s0
/usr/sbin/virtsecretd  regular file
system_u:object_r:virtsecretd_exec_t:s0
/usr/sbin/virtstoraged regular file
system_u:object_r:virtstoraged_exec_t:s0
/usr/sbin/virtvboxdregular file
system_u:object_r:virtvboxd_exec_t:s0
/usr/sbin/virtvzd  regular file
system_u:object_r:virtvzd_exec_t:s0
/usr/sbin/virtxend regular file
system_u:object_r:virtxend_exec_t:s0
```

(should Fedora SELinux policy also drop historical paths for simplicity's
sake if/when RPMs don't use them anymore?)


On Thu, Apr 11, 2024 at 3:39 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> Hi!
>
> I'm trying to get
> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin implemented.
> It was approved for F40, but only a few days before the mass rebuild,
> so there wasn't time to do much, so it was retargeted to F41.
> We now have some time before the F41 mass rebuild, so I want to push
> all the changes required in various packages so that we have time to
> work out any kinks before the mass rebuild commences.
>
> When I started looking at individual packages, I discovered that we
> have an old rule that packages are SUPPOSED to use "historical paths"
> to list their files. This rule was introduced to make the transition
> easier when UsrMove was implemented for F17. For example, mount.nfs
> was historically installed as /sbin/mount.nfs, so nfs-utils must use
> %files:/sbin/mount.nfs, even though /sbin is a symlink to /usr/sbin,
> meaning that the real path after installation is /usr/sbin/mount.nfs.
> And packages using a file path dependency on mount.nfs must use
> /sbin/mount.nfs too.
>
> To implement this rule, packages must use %buildroot/sbin during
> installation and use literal "/sbin/" in the files section. This idea
> made sense at the time, but now it seems overcomplicated and
> unecessary. It requires additional work from packagers who create the
> packages that provide the files, but also additional work from
> packagers that want to refer to those files. In fact, I only found
> three packages that implement the rule correctly: nfs-utils, glibc,
> and ocfs2-tools. So step 0. is to drop the packaging rule:
>   https://pagure.io/packaging-committee/pull-request/1355
>
> As to the actual sbin merge:
>
> Currently, we have %_bindir==/usr/bin, %_sbindir==/usr/sbin,
> and /sbin->/usr/sbin, 

Fedora rawhide compose report: 20240411.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20240410.n.0
NEW: Fedora-Rawhide-20240411.n.0

= SUMMARY =
Added images:3
Dropped images:  3
Added packages:  9
Dropped packages:19
Upgraded packages:   107
Downgraded packages: 0

Size of added packages:  32.01 MiB
Size of dropped packages:46.16 MiB
Size of upgraded packages:   4.17 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Cloud_Base docker aarch64
Path: 
Cloud/aarch64/images/Fedora-Cloud-Base-GCE.aarch64-Rawhide-20240411.n.0.tar.gz
Image: Cloud_Base_UKI qcow2 aarch64
Path: 
Cloud/aarch64/images/Fedora-Cloud-Base-UEFI-UKI.aarch64-Rawhide-20240411.n.0.qcow2
Image: Cloud_Base docker x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-GCE.x86_64-Rawhide-20240411.n.0.tar.gz

= DROPPED IMAGES =
Image: Workstation live-osbuild x86_64
Path: 
Workstation/x86_64/iso/Fedora-Workstation-Live-osb-Rawhide-20240410.n.0.x86_64.iso
Image: Workstation live-osbuild aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-osb-Rawhide-20240410.n.0.aarch64.iso
Image: i3 live aarch64
Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20240410.n.0.iso

= ADDED PACKAGES =
Package: ffmpegthumbnailer-2.2.2-1.20240105git1b5a779.fc41
Summary: Lightweight video thumbnailer that can be used by file managers
RPMs:ffmpegthumbnailer ffmpegthumbnailer-devel ffmpegthumbnailer-libs
Size:675.47 KiB

Package: gap-pkg-fplsa-1.2.6-1.fc41
Summary: Finitely presented Lie algebras
RPMs:gap-pkg-fplsa gap-pkg-fplsa-doc
Size:1.10 MiB

Package: google-compute-engine-guest-configs-20240307.00-1.fc41
Summary: Google Compute Engine guest environment tools
RPMs:google-compute-engine-guest-configs 
google-compute-engine-guest-configs-rsyslog 
google-compute-engine-guest-configs-udev
Size:47.93 KiB

Package: google-disk-expand-20240228.00-1.fc41
Summary: Expands root partition in Google Cloud instances
RPMs:google-disk-expand
Size:15.87 KiB

Package: google-guest-agent-20240314.00-4.fc41
Summary: Google Compute Engine guest environment
RPMs:google-guest-agent
Size:18.23 MiB

Package: google-osconfig-agent-20240409.00-1.fc41
Summary: Google OS Config Agent
RPMs:google-osconfig-agent
Size:10.41 MiB

Package: mmtests-0.27-1.fc41
Summary: Configurable test framework
RPMs:mmtests
Size:1.33 MiB

Package: rust-http-body0.4-0.4.6-1.fc41
Summary: Trait representing an asynchronous, streaming, HTTP request or 
response body
RPMs:rust-http-body0.4+default-devel rust-http-body0.4-devel
Size:26.82 KiB

Package: ut-2.0.0-1.fc41
Summary: UT: C++20 ??(micro)/Unit Testing Framework
RPMs:ut-devel
Size:199.60 KiB


= DROPPED PACKAGES =
Package: fedmod-0.6.6-5.fc40
Summary: Utilities for generating & maintaining modulemd files
RPMs:fedmod
Size:176.01 KiB

Package: golang-gopkg-src-d-billy-4-4.3.2-10.fc40
Summary: Interface filesystem abstraction for Go
RPMs:golang-gopkg-src-d-billy-4-devel
Size:43.75 KiB

Package: golang-gopkg-src-d-git-fixtures-3-3.5.0-13.fc40
Summary: Several git fixtures to run go-git tests
RPMs:golang-gopkg-src-d-git-fixtures-3-devel
Size:43.11 MiB

Package: libcxl-1.7-17.fc40
Summary: Coherent accelerator interface
RPMs:libcxl libcxl-devel
Size:106.48 KiB

Package: liquidshell-1.9.0-3.fc40
Summary: Basic desktop shell using QtWidgets
RPMs:liquidshell
Size:1.56 MiB

Package: perl-Git-PurePerl-0.53-25.fc40
Summary: Pure Perl interface to Git repositories
RPMs:perl-Git-PurePerl
Size:35.09 KiB

Package: perl-Net-GitHub-1.05-5.fc40
Summary: Perl interface for github.com
RPMs:perl-Net-GitHub
Size:79.77 KiB

Package: perl-Spreadsheet-ParseExcel-Simple-1.04-45.fc40
Summary: Simple interface to Excel data
RPMs:perl-Spreadsheet-ParseExcel-Simple
Size:15.28 KiB

Package: perl-Spreadsheet-WriteExcel-Simple-1.04-45.fc40
Summary: Simple single-sheet Excel document creator
RPMs:perl-Spreadsheet-WriteExcel-Simple
Size:14.34 KiB

Package: perl-String-Diff-0.07-26.fc40
Summary: Simple diff to String
RPMs:perl-String-Diff
Size:20.80 KiB

Package: php-phpSmug-2.1-25.fc40
Summary: PHP wrapper for the SmugMug API
RPMs:php-phpSmug
Size:23.80 KiB

Package: rust-cpython-0.7.1-2.fc38
Summary: Bindings to Python
RPMs:rust-cpython+default-devel rust-cpython+extension-module-devel 
rust-cpython+nightly-devel rust-cpython+no-auto-initialize-devel 
rust-cpython+nonnull-devel rust-cpython+py-link-mode-default-devel 
rust-cpython+py-link-mode-unresolved-static-devel 
rust-cpython+python-3-10-devel rust-cpython+python-3-11-devel 
rust-cpython+python-3-4-devel rust-cpython+python-3-5-devel 
rust-cpython+python-3-6-devel rust-cpython+python-3-7-devel 
rust-cpython+python-3-8-devel rust-cpython+python-3-9-devel 
rust-cpython+python3-sys-devel rust-cpython+serde-convert-devel 
rust-cpython+serde-devel rust-cpython-devel

Re: Fedora Linux 40 Go/No-Go Meeting: 2024-11-04

[Aoife Moloney]

REMINDER: The Fedora Linux 40 Go/No-Go meeting is scheduled for today, 11th
April @ 1700 UTC in in #meeting:fedoraproject.org channel on Matrix.


Aoife Moloney
Fedora Operations Architect

On Mon, Apr 8, 2024, 10:23 PM Aoife Moloney  wrote:

> Happy Monday folks!
>
> On Thursday 11th April, the Fedora Linux 40 Final Go/No-Go meeting[1] will
> be held at 1700 UTC in #meeting:fedoraproject.org channel on Matrix.
>
> At this time, we will determine the status of the F40 Final release for
> the 16th April, which is the early target date[2]. For more information
> about the Go/No-Go meeting, see the wiki[3].
>
>
> [1] https://calendar.fedoraproject.org/meeting/10787/
> [2] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
> [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting
>
>
> --
>
> Aoife Moloney
>
> Fedora Operations Architect
>
> Fedora Project
>
> Matrix: @amoloney:fedora.im
>
> IRC: amoloney
>
>
>
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Test-Announce] Re: Fedora Linux 40 Go/No-Go Meeting: 2024-11-04

[Aoife Moloney]

REMINDER: The Fedora Linux 40 Go/No-Go meeting is scheduled for today, 11th
April @ 1700 UTC in in #meeting:fedoraproject.org channel on Matrix.


Aoife Moloney
Fedora Operations Architect

On Mon, Apr 8, 2024, 10:23 PM Aoife Moloney  wrote:

> Happy Monday folks!
>
> On Thursday 11th April, the Fedora Linux 40 Final Go/No-Go meeting[1] will
> be held at 1700 UTC in #meeting:fedoraproject.org channel on Matrix.
>
> At this time, we will determine the status of the F40 Final release for
> the 16th April, which is the early target date[2]. For more information
> about the Go/No-Go meeting, see the wiki[3].
>
>
> [1] https://calendar.fedoraproject.org/meeting/10787/
> [2] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
> [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting
>
>
> --
>
> Aoife Moloney
>
> Fedora Operations Architect
>
> Fedora Project
>
> Matrix: @amoloney:fedora.im
>
> IRC: amoloney
>
>
>
--
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Idea: pynose as drop-in replacement for nose

[Ben Beasley]

For a proposed nose successor, pynose doesn’t seem to have gained much 
community traction so far: it has seven stars on GitHub[1] (compared to 
770 for nose2, which itself was never that widely adopted and has fewer 
than ten dependent packages in Fedora); and the imperfect but fairly 
useful reverse dependency index at Wheelodex[2] shows only three 
packages that explicitly depend on it.


As far as I can tell, pynose exists because SeleniumBase[3] found it 
easier to fork nose than to port away from it. I’m *definitely* not 
saying we should only package things with a bunch of GitHub stars, but I 
do have some concerns about whether or not pynose is going to remain a 
generally-useful project in the medium-to-long term.


[1] https://github.com/mdmintz/pynose/stargazers

[2] https://www.wheelodex.org/projects/pynose/rdepends/

[3] https://github.com/seleniumbase/SeleniumBase

On 4/11/24 9:17 AM, Miro Hrončok wrote:

On 11. 04. 24 15:05, Sandro wrote:

On 11-04-2024 13:54, Miro Hrončok wrote:

On 11. 04. 24 11:55, Sandro wrote:
While I ponder those thoughts some more, moving forward in either 
direction, the next step would be writing a change proposal?


I'd start by:

Packaging pynose without hacks (only making it Conflict with nose, 
no compatibility Provides, Obsoletes or dist-infos).


That way, pro-active packagers can switch already.


That makes sense. Review is up [1]. If enough packagers adapt, I may 
not need to go through the changes process.


And the change proposal can then describe what will be *added* to 
pynose, rather than describing the approach from scratch.


Since predicting the future is difficult, I'll start on writing up a 
proposal while the package is being introduced, anyway.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2274514


I see "# Package doesn't provide any tests" in the %check section.
That certainly feels a bit dodgy. This successor of a test framework 
decided to ditch all of the tests it used to have? That is certainly a 
red flag.



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

[Bug 2274529] New: perl-ExtUtils-HasCompiler-0.024 is available

[bugzilla]

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

Bug ID: 2274529
   Summary: perl-ExtUtils-HasCompiler-0.024 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-ExtUtils-HasCompiler
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 0.024
Upstream release that is considered latest: 0.024
Current version/release in rawhide: 0.023-11.fc40
URL: http://search.cpan.org/dist/ExtUtils-HasCompiler/

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


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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202274529%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

Merging /usr/sbin to /usr/bin

[Zbigniew Jędrzejewski-Szmek]

Hi!

I'm trying to get
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin implemented.
It was approved for F40, but only a few days before the mass rebuild,
so there wasn't time to do much, so it was retargeted to F41.
We now have some time before the F41 mass rebuild, so I want to push
all the changes required in various packages so that we have time to
work out any kinks before the mass rebuild commences.

When I started looking at individual packages, I discovered that we
have an old rule that packages are SUPPOSED to use "historical paths"
to list their files. This rule was introduced to make the transition
easier when UsrMove was implemented for F17. For example, mount.nfs
was historically installed as /sbin/mount.nfs, so nfs-utils must use
%files:/sbin/mount.nfs, even though /sbin is a symlink to /usr/sbin,
meaning that the real path after installation is /usr/sbin/mount.nfs.
And packages using a file path dependency on mount.nfs must use
/sbin/mount.nfs too.

To implement this rule, packages must use %buildroot/sbin during
installation and use literal "/sbin/" in the files section. This idea
made sense at the time, but now it seems overcomplicated and
unecessary. It requires additional work from packagers who create the
packages that provide the files, but also additional work from
packagers that want to refer to those files. In fact, I only found
three packages that implement the rule correctly: nfs-utils, glibc,
and ocfs2-tools. So step 0. is to drop the packaging rule:
  https://pagure.io/packaging-committee/pull-request/1355

As to the actual sbin merge:

Currently, we have %_bindir==/usr/bin, %_sbindir==/usr/sbin,
and /sbin->/usr/sbin, /bin->/usr/sbin.

In the end state, we will have %_bindir==%_sbindir==/usr/bin,
and /bin,/sbin,/usr/sbin -> /usr/bin. This end state is simple:
_any_ path will works for any binary.

It's the transition, as we rebuild packages with the new definition,
that requires some careful handling.

After experimenting with a few different ways to handle this, the
following approach seems to work best:

1. rpm is patched to provide %_sbindir==/usr/bin.
   (This affects what paths packages will list after being rebuilt.)

2. filesystem is patched to not contain /usr/sbin in %files,
   but instead symlink /usr/sbin -> bin in %pretrans.

   On fresh installations, this will succeed, so the merge is in place.
   On upgrades, this will fail, meaning that /usr/sbin remains a dir.
   There is also a %posttrans scriptlet to attempt a merge on upgrades,
   more about this below.

   In particular, since buildroots are created afresh for each build,
   package builds will get merged-sbin.

3. We need to handle the case where package foo had /usr/sbin/foo, but
   this file will be in /usr/bin/foo after rebuild. After the merge is
   done, /usr/sbin/foo and /usr/bin/foo will point to the same
   location, no problem, but during the transition, users or scripts
   might call /usr/sbin/foo. To make this work, filesystem rpm gets a
   scriptlet that will create symlinks from /usr/sbin to /usr/bin, for
   any files which were installed by packages in /usr/sbin. (A list
   was obtained using repoquery.)

   Initially, I wanted to put those scriptlets in individual packages,
   but that turns out to be a lot of duplicate work. Some packages
   have multiple subpackages with files (currently) in /usr/sbin, so
   we'd end up with a lot of churn. Doing it once in filesystem turns
   out to be fairly easy.

4. We also need to handle the case where other package bar has
   Requires:/usr/sbin/foo. Once foo has been rebuilt, it has only an
   automatic provides for /usr/bin/foo. We could adjust bar for the
   new path, but then bar would not be installable on old systems.
   Instead, a compat virtual Provides:/usr/sbin/foo is added to foo.
   We know that either /usr/sbin will be a symlink, or that filesystem
   will create the /usr/sbin/foo symlink.

   We need to ensure that the filesystem package that is installed is
   actually new enough so that the Provides is not a lie.
   filesystem.rpm gets a virtual
   Provides:filesystem(unmerged-sbin-symlinks)=1 which is used as
   Requires:filesystem(unmerged-sbin-symlinks) by foo.

   (An explicit Provides/Requires allows us to adjust or rescind the
   mechanism in the future.)

5. After this preparatory work is done, we can rebuild
   various packages with updated rpm and filesystem.

   Packages which don't use %_sbindir generally don't care.
   Some packages which use %_sbindir need small adjustments.
   There are some common failure modes:

   a. 'mv %buildroot/%_bindir/foo %buildroot/%_sbindir/'
   b. 'ln -s ../bin/foo %buildroot/%_sbindir/foo'
   c. Listing both %_bindir/foo and %_sbindir/foo in %files
   d. 'ln -sf ../bin/foo %buildroot/%_sbindir/foo.alt'
   e. 'ln -sf ../sbin/foo %buildroot/%_bindir/foo.alt'

   To make builds work both before and after the merge, a-c should be
   conditionalized on '%if "%{_sbindir}" != "%{_bindir}"'.

Re: Idea: pynose as drop-in replacement for nose

[Sandro]

On 11-04-2024 15:17, Miro Hrončok wrote:

On 11. 04. 24 15:05, Sandro wrote:

On 11-04-2024 13:54, Miro Hrončok wrote:

On 11. 04. 24 11:55, Sandro wrote:
While I ponder those thoughts some more, moving forward in either 
direction, the next step would be writing a change proposal?


I'd start by:

Packaging pynose without hacks (only making it Conflict with nose, no 
compatibility Provides, Obsoletes or dist-infos).


That way, pro-active packagers can switch already.


That makes sense. Review is up [1]. If enough packagers adapt, I may 
not need to go through the changes process.


And the change proposal can then describe what will be *added* to 
pynose, rather than describing the approach from scratch.


Since predicting the future is difficult, I'll start on writing up a 
proposal while the package is being introduced, anyway.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2274514


I see "# Package doesn't provide any tests" in the %check section.
That certainly feels a bit dodgy. This successor of a test framework 
decided to ditch all of the tests it used to have? That is certainly a 
red flag.


More like a chicken and egg story, maybe? If I were to provide a testing 
framework, I'd very much like to use that testing framework for testing.




Anyway, I'll contact upstream asking them about it. It's the least I can 
do. I'll also ask about the documentation link on PyPI, which points to 
the RTD page of ye olde .


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

Rust Stack Spring Cleaning - 2024 Edition

[Fabio Valentini]

Hello Rust packagers,

I'm continuously working on reducing unnecessary accumulation of cruft
in the Rust package stack in Fedora, and I have been keeping track of
unused library packages for almost three years now.

Some of these packages have been unused leaves for over two years!

I will again start being more proactive with orphaning / retiring
affected packages where I am the primary maintainer, starting
incrementally from the packages which have been unused for the longest
time - unless I know of a reason to keep a specific package, for
example:

- something that depends on the package is still going through package review
- the package was updated to a "breaking" release and a compat package
was created, and now the "main" package is not depended on while the
compat package is in use

If you know of a reason why a leaf package where I am the primary
maintainer should not be retired, please let me know, and I will
exclude it from the list.

For packages where I am *not* the primary maintainer, I need help:

- Is this package still required for something that I don't know
about, or can it be dropped?
- Was it added as a dependency for something else, but packaging this
"something else" was abandoned?
- Was it needed at the time, but is the library no longer needed now?

Keeping unused packages around only makes maintenance of the Rust
stack more difficult due to the more "dense" dependency graph that
needs to be considered when pushing "breaking" changes. Over the past
year or so, the number of Rust packages in Fedora has grown by almost
50% from about 2200 to over 3000, which is making this issue worse.

Full report included below (view in monospace font for correct formatting).

Thank you for your help,
Fabio

+--++---+--+
| Package  | Leaf since | Leaf days | Maintainer   |
+--++---+--+
| rust-curve25519-dalek| 2021-11-18 |   875 | dcavalca |
| rust-gstreamer-editing-services  | 2021-11-18 |   875 | atim |
| rust-gstreamer-player| 2021-11-18 |   875 | atim |
| rust-rand_jitter | 2021-11-18 |   875 | jistone  |
| rust-rand_os | 2021-11-18 |   875 | jistone  |
| rust-tower-test  | 2021-11-18 |   875 | decathorpe   |
| rust-tower-util  | 2021-11-18 |   875 | decathorpe   |
| rust-partial-io  | 2022-02-06 |   795 | decathorpe   |
| rust-minimad | 2022-02-18 |   783 | dcavalca |
| rust-libhandy| 2022-02-20 |   781 | decathorpe   |
| rust-tiger   | 2022-02-20 |   781 | decathorpe   |
| rust-rand_hc | 2022-02-21 |   780 | jistone  |
| rust-benfred-read-process-memory | 2022-02-27 |   774 | dcavalca |
| rust-custom_error| 2022-02-27 |   774 | dcavalca |
| rust-madvr_parse | 2022-02-27 |   774 | dcavalca |
| rust-os-release  | 2022-02-27 |   774 | dcavalca |
| rust-strict  | 2022-02-27 |   774 | dcavalca |
| rust-subprocess  | 2022-02-27 |   774 | dcavalca |
| rust-libxml  | 2022-04-07 |   735 | decathorpe   |
| rust-snake_case  | 2022-04-25 |   717 | decathorpe   |
| rust-openat-ext  | 2022-04-28 |   714 | walters  |
| rust-log-mdc | 2022-05-05 |   707 | decathorpe   |
| rust-cargo-manifest  | 2022-05-06 |   706 | laiot|
| rust-digest_auth | 2022-05-06 |   706 | laiot|
| rust-binascii| 2022-05-10 |   702 | saluki   |
| rust-inlinable_string| 2022-05-10 |   702 | decathorpe   |
| rust-ubyte   | 2022-05-10 |   702 | decathorpe   |
| rust-email-encoding  | 2022-05-17 |   695 | saluki   |
| rust-tabular | 2022-05-23 |   689 | jbtrystram   |
| rust-async-mutex | 2022-06-01 |   680 | decathorpe   |
| rust-awc | 2022-06-01 |   680 | decathorpe   |
| rust-infer   | 2022-06-15 |   666 | decathorpe   |
| rust-escape_string   | 2022-07-08 |   643 | dcavalca |
| rust-actix   | 2022-07-18 |   633 | decathorpe   |
| rust-envsubst| 2022-07-18 |   633 | jlebon   |
| rust-esphome | 2022-07-18 |   633 | dcavalca |
| rust-fail| 2022-07-18 |   633 | jlebon   |
| 

Re: [Test-Announce] Re: Fedora 40 Candidate RC-1.12 Available Now! GRUB ISSUE

[Leslie Satenstein via devel]

Yesterday, Nov10, a set of "Final candidate" for Fedora 40 was posted.  Adam  
requested that we test it to the ends and make sure all is OK.
So, I suppose positively, that tomorrow, Friday, we will know if Fedora 40 is a 
go/nogo.

For me, as a single distro to be installed, it is ready to go. However, if you 
want a Gnome version on one drive, and a KDE version on a second drive, you may 
be out of luck.  

The problem I am experiencing is with each produced grub menu, each seems to 
prevent two Fedoras 40's from being listed within the boot menu. Not with 
workstation, the first, or the boot menu of the second (KDE).  

>From the desktop computer bios, I see both devices listed, and yes, via the 
>bios, I can boot the alternate Fedora40 version.  However, using the bios' 
>presentation in order to select the Fedora Linux to boot is wrong!!

I would use RH's bugzilla to report this issue, but right now, the Fedora 
activity is heavily focused on videos, documentation, web pages... etc.

At this time, there is no "unlimited" number of people to provide Fedora 40 
installation support. I will await post-install to see if grub.cfg can be less 
restrictive.
 


Leslie Satenstein    


PSMy confignvme0  Fedora39 
nvme1  Fedora40 Gnomesdax Fedora KDEsdbx Non Fedora setupsdc-sdf  
Empty,Backups, and available 1tb drives. 
--
___
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: Idea: pynose as drop-in replacement for nose

[Miro Hrončok]

On 11. 04. 24 15:05, Sandro wrote:

On 11-04-2024 13:54, Miro Hrončok wrote:

On 11. 04. 24 11:55, Sandro wrote:
While I ponder those thoughts some more, moving forward in either direction, 
the next step would be writing a change proposal?


I'd start by:

Packaging pynose without hacks (only making it Conflict with nose, no 
compatibility Provides, Obsoletes or dist-infos).


That way, pro-active packagers can switch already.


That makes sense. Review is up [1]. If enough packagers adapt, I may not need 
to go through the changes process.


And the change proposal can then describe what will be *added* to pynose, 
rather than describing the approach from scratch.


Since predicting the future is difficult, I'll start on writing up a proposal 
while the package is being introduced, anyway.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2274514


I see "# Package doesn't provide any tests" in the %check section.
That certainly feels a bit dodgy. This successor of a test framework decided to 
ditch all of the tests it used to have? That is certainly a red flag.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Idea: pynose as drop-in replacement for nose

[Sandro]

On 11-04-2024 13:54, Miro Hrončok wrote:

On 11. 04. 24 11:55, Sandro wrote:
While I ponder those thoughts some more, moving forward in either 
direction, the next step would be writing a change proposal?


I'd start by:

Packaging pynose without hacks (only making it Conflict with nose, no 
compatibility Provides, Obsoletes or dist-infos).


That way, pro-active packagers can switch already.


That makes sense. Review is up [1]. If enough packagers adapt, I may not 
need to go through the changes process.


And the change proposal can then describe what will be *added* to 
pynose, rather than describing the approach from scratch.


Since predicting the future is difficult, I'll start on writing up a 
proposal while the package is being introduced, anyway.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2274514

-- Sandro

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

Re: Idea: pynose as drop-in replacement for nose

[Miro Hrončok]

On 11. 04. 24 11:55, Sandro wrote:
While I ponder those thoughts some more, moving forward in either direction, 
the next step would be writing a change proposal?


I'd start by:

Packaging pynose without hacks (only making it Conflict with nose, no 
compatibility Provides, Obsoletes or dist-infos).


That way, pro-active packagers can switch already.

And the change proposal can then describe what will be *added* to pynose, 
rather than describing the approach from scratch.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [SPDX] Mass license change Artistic 2.0 to Artistic-2.0

[Petr Pisar]

V Thu, Apr 11, 2024 at 01:04:22PM +0200, Miroslav Suchý napsal(a):
> perl-Unix-Groups-FFI
> perl-Unix-Groups-FFI

You can remove perl-Unix-Groups-FFI from your list. I converted both of them.

-- Petr


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

[SPDX] Mass license change Artistic 2.0 to Artistic-2.0

[Miroslav Suchý]

Hi.

I am going to do the mass change of the license from Artistic 2.0 to 
Artistic-2.0

The proposed diff is in attachment.

Affected packages:

chordpro
cleanfeed
libkdtree++
R-AnnotationDbi
perl-Data-IEEE754
mingw-ftplib
nicstat
perl-Test-Bits
perl-MaxMind-DB-Common
perl-MaxMind-DB-Reader-XS
perl-SQL-Abstract-Pg
R-MatrixGenerics
perl-Applify
perl-App-SVN-Bisect
perl-App-SVN-Bisect
perl-Business-ISSN
perl-Crypt-PWSafe3
perl-Dancer-Plugin-Database-Core
perl-Dist-Zilla-Plugin-Config-Git
perl-File-Next
perl-Flickr-API
perl-Ham-Reference-QRZ
perl-HTML-FormatText-WithLinks-AndTables
perl-HTTP-Tiny-Multipart
perl-Inline-CPP
perl-IPTables-ChainMgr
perl-IPTables-Parse
perl-JSON-Validator
perl-Log-Agent
perl-Mango
perl-Minion-Backend-SQLite
perl-Mojolicious-Plugin-AssetPack
perl-Mojolicious-Plugin-CHI
perl-Mojolicious-Plugin-I18N
perl-Mojolicious-Plugin-OAuth2
perl-Mojolicious-Plugin-OpenAPI
perl-Mojo-Pg
perl-Mojo-SQLite
perl-MojoX-JSON-RPC
perl-MooseX-ClassAttribute
perl-MooseX-SemiAffordanceAccessor
perl-Parse-CPAN-Distributions
perl-Perl-Critic-Bangs
perl-Razor-Agent
perl-Set-Object
perl-STD
perl-Test-PostgreSQL
perl-Test-YAML-Meta
perl-Text-Context-EitherSide
perl-Text-SimpleTable
perl-Tie-Cycle
perl-Unix-Groups-FFI
perl-Unix-Groups-FFI
perl-WWW-Shorten
pv
R-restfulr
R-KEGGREST
qstat
R-Biobase
R-BiocGenerics
R-biomaRt
R-Biostrings
R-BSgenome
R-DelayedArray
R-DynDoc
remoot
renrot
R-GenomeInfoDbData
R-GenomeInfoDb
R-GenomicAlignments
R-GenomicRanges
R-matrixStats
rpmgrill
R-Rsamtools
R-Rsolid
R-S4Vectors
R-SummarizedExperiment
R-tkWidgets
R-BiocIO
R-XVector
smaclient
xxkb
R-BiocFileCache

perl-Test-Snapshot


Unless somebody stop me, I will do this change directly in dist-git after a 
week.
--

Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
diff -Naur rpm-specs.orig/cleanfeed.spec rpm-specs/cleanfeed.spec
--- rpm-specs.orig/cleanfeed.spec	2024-01-25 03:03:00.0 +0100
+++ rpm-specs/cleanfeed.spec	2024-04-11 13:01:04.933821114 +0200
@@ -1,9 +1,9 @@
 Summary: A spam filter for Usenet news servers
 Name: cleanfeed
 Version: 20020501
-Release: 31%{?dist}
+Release: 32%{?dist}
 # Confirmed with upstream, website
-License: Artistic 2.0
+License: Artistic-2.0
 URL: http://www.bofh.it/~md/cleanfeed/
 Source0: http://www.bofh.it/~md/cleanfeed/cleanfeed-20020501.tgz
 Patch0: cleanfeed-20020501-redhat.patch
@@ -56,6 +56,9 @@
 %attr(-,news,news) %{_datadir}/news/bin/filter/filter_innd.pl
 
 %changelog
+* Thu Apr 11 2024 Miroslav Suchý  - 20020501-32
+- convert license to SPDX
+
 * Wed Jan 24 2024 Fedora Release Engineering  - 20020501-31
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
 
diff -Naur rpm-specs.orig/chordpro.spec rpm-specs/chordpro.spec
--- rpm-specs.orig/chordpro.spec	2024-02-15 03:02:20.0 +0100
+++ rpm-specs/chordpro.spec	2024-04-11 13:01:04.568817373 +0200
@@ -7,9 +7,9 @@
 
 Name: chordpro
 Summary: Print songbooks (lyrics + chords)
-License: Artistic 2.0
+License: Artistic-2.0
 Version: 6.050
-Release: 2%{?dist}
+Release: 3%{?dist}
 Source: https://cpan.metacpan.org/authors/id/J/JV/JV/%{FullName}-%{version}.tar.gz
 Source1: README.ABC
 Source2: README.LilyPond
@@ -250,6 +250,9 @@
 gtk-update-icon-cache %{_datadir}/icons/hicolor
 
 %changelog
+* Thu Apr 11 2024 Miroslav Suchý  - 6.050-3
+- convert license to SPDX
+
 * Wed Feb 14 2024 Johan Vromans  - 6.050-2
 - Repackage ABC support (abc2svg 1.22.13).
 
diff -Naur rpm-specs.orig/libkdtree++.spec rpm-specs/libkdtree++.spec
--- rpm-specs.orig/libkdtree++.spec	2024-04-10 04:19:33.0 +0200
+++ rpm-specs/libkdtree++.spec	2024-04-11 13:01:05.481826731 +0200
@@ -1,9 +1,9 @@
 Name:   libkdtree++
 Version:0.7.0
-Release:38%{?dist}
+Release:39%{?dist}
 Summary:C++ template container implementation of kd-tree sorting
 URL:http://libkdtree.alioth.debian.org/
-License:Artistic 2.0
+License:Artistic-2.0
 BuildRequires:  gcc-c++
 BuildRequires:  autoconf automake python3-devel swig
 BuildRequires: make
@@ -113,6 +113,9 @@
 %doc examples/test*.cpp
 
 %changelog
+* Thu Apr 11 2024 Miroslav Suchý  - 0.7.0-39
+- convert license to SPDX
+
 * Thu Jan 25 2024 Fedora Release Engineering  - 0.7.0-38
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
 
diff -Naur rpm-specs.orig/mingw-ftplib.spec rpm-specs/mingw-ftplib.spec
--- rpm-specs.orig/mingw-ftplib.spec	2024-01-26 03:21:59.0 +0100
+++ rpm-specs/mingw-ftplib.spec	2024-04-11 13:01:06.768839922 +0200
@@ -2,10 +2,10 @@
 
 Name:   mingw-ftplib
 Version:4.0
-Release:19%{?dist}
+Release:20%{?dist}
 Summary:MinGW Library of FTP routines
 
-License:Artistic 2.0
+License:Artistic-2.0
 URL:http://nbpfaus.net/~pfau/ftplib/
 Source0:http://nbpfaus.net/~pfau/ftplib/ftplib-%{version}.tar.gz
 Source1:ftplib-rc.rc
@@ -115,6 +115,9 @@
 
 
 %changelog
+* Thu Apr 11 2024 Miroslav Suchý  - 4.0-20

Re: convert everything to rpmautospec?

[Fabio Valentini]

On Thu, Apr 11, 2024 at 12:39 PM Leon Fauster via devel
 wrote:
>
> Am 08.04.24 um 08:01 schrieb Miro Hrončok:
> > On 08. 04. 24 6:08, Carlos Rodriguez-Fernandez wrote:
> >>
> >> Not all commits correspond with a new release downstream, and not all
> >> commit messages are relevant to the end user to be part of the change
> >> log. For example, commits related with increasing gating test coverage
> >> efforts, or setting up gating.yaml itself. Another example is linting
> >> setting and/or configurations. How is that handled with autochangelog?
> >> Can we tell it to skip certain commits? Or should we include it all?
> >
> > Put [skip changelog] in the commit message.
> >
> > https://fedora-infra.github.io/rpmautospec-docs/autochangelog.html#skipping-changelog-entries
> >
>
> May be an [add rpmchangelog] would be more appropriate for some
> scenarios, where branching and merging or whatever would clutter
> the git log. Would lead to a more curated rpm changelog. Still,
> not ideal.

As far as I know, merge commits are already excluded automatically.

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: convert everything to rpmautospec?

[Leon Fauster via devel]

Am 08.04.24 um 08:01 schrieb Miro Hrončok:

On 08. 04. 24 6:08, Carlos Rodriguez-Fernandez wrote:


Not all commits correspond with a new release downstream, and not all 
commit messages are relevant to the end user to be part of the change 
log. For example, commits related with increasing gating test coverage 
efforts, or setting up gating.yaml itself. Another example is linting 
setting and/or configurations. How is that handled with autochangelog? 
Can we tell it to skip certain commits? Or should we include it all?


Put [skip changelog] in the commit message.

https://fedora-infra.github.io/rpmautospec-docs/autochangelog.html#skipping-changelog-entries



May be an [add rpmchangelog] would be more appropriate for some
scenarios, where branching and merging or whatever would clutter
the git log. Would lead to a more curated rpm changelog. Still,
not ideal.

--
Leon
--
___
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: Idea: pynose as drop-in replacement for nose

[Sandro]

On 10-04-2024 17:50, Miro Hrončok wrote:

On 10. 04. 24 17:30, Sandro wrote:

On 10-04-2024 12:04, Miro Hrončok wrote:

On 09. 04. 24 19:30, Sandro wrote:
Therefore, I'm thinking of introducing pynose as a drop in 
replacement of deprecated nose. Pynose uses the same namespace as 
nose, but provides python3dist(pynose). Thus adding Provides: for 
nose would make it a drop-in replacement for packages currently 
depending on nose.


FTR We MUST NOT add RPM Provides for python3dist(nose) unless we 
package nose dist-info metadata.


Thanks for pointing that out. I was indeed experimenting with it.

Is there some documentation or example for packaging extra dist-info 
metadata?


Not really, because it is a hack that should not be done if it can be 
avoided.


You can see a working example in python-lark

https://src.fedoraproject.org/rpms/python-lark/c/c7a9aa2e7b0b1d9d621ac60f73c854fdcc154ab2




Agreed. If we do add python3dist(nose) it needs to work not cause more 
issues. Most packages I've looked at recently have a BR for 
python3-nose. That's covered by adding "%py_provides python3-nose". 
But dependency resolution in %pyproject_buildrequires uses 
python3dist. If the package configuration has a dependency on nose 
declared, I would like that to be satisfiable, both in RPM and pip, by 
installing python3-pynose.


If that is too much hassle or simply (currently) not possible, a 
fallback to not providing nose at all, is also possible. In that case 
more packages might need to be patched and we need to educate people 
te replace dependencies on nose with pynose.


My preference at the moment is for the former.


If we are to retire python-nose at the same time, I'd do:

  - have python3-pynose %py_provides (and Obsolete) python3-nose
  - don't mess with dist metadata at all

That way:

  - packages that use upstream requirements will need to be updated
    (preferably upstream first => good)
  - packages that manually BuildRequire python3-nose will likely keep 
working


If the pynose package has a "nose" importable module, providing 
python3-nose even follows 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_provides_for_importable_modules


Well, `pynose` provides `nose` as an importable module, which is 
installed into `%{python3_sitelib}/nose`. Since that conflicts with 
python3-nose, proper Provides and Obsoletes are required, indeed.


Thanks for the example, I used that to properly provide `nose`. Building 
against that package reduced the troublesome packages to one (two more 
are currently FTBFS in rawhide/F40) compared to 11+2[1] when using only 
`%py_provides python3-nose`.


I think that justifies carrying the "hack". Moreover, `nose` has been 
dead for a long time upstream, yet we still have packages depending on 
it. In a way the justification here doesn't differ very much from that 
of `lark`.


I agree that maintainers of packages still depending on `nose` should 
ask upstream to switch to `pynose` or some other testing framework. Yet, 
I wouldn't be surprised that exactly those packages are also 
un(der)maintained upstream.


While I ponder those thoughts some more, moving forward in either 
direction, the next step would be writing a change proposal?


[1] Some failures were unrelated to `nose` vs. `pynose` and have been 
fixed by having `pynose` require `setuptools`.


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

Re: convert everything to rpmautospec?

[Ondrej Mosnáček]

On Wed, 10 Apr 2024 at 16:30, Pierre-Yves Chibon  wrote:
[...]
> Let's look at it in another way: would you say that the people who leaved in 
> the
> 14th century were liars for saying that the earth is flat?
> No, they just didn't know.

Off-topic and not really affecting the validity of your point, but the
idea that people in the 14th century / Middle Ages generally believed
that the earth was flat is a myth. I recently read about it in the
book "Fake History: 101 Things that Never Happened" by Jo Teeuwisse
(great book, BTW!), but also Wikipedia happens to have a decent
article about it: https://en.wikipedia.org/wiki/Myth_of_the_flat_Earth
--
___
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