Re: F41 Change Proposal: Switch to DNF 5 (System-Wide)

[Jan Kolarik]

Hello Vit,

I don't understand this. So if GS going to use DNF, therefore the same
> cache etc, or not? Or what other metadata PackageKit downloads on top of
> DNF?
>

Yes, it will ultimately utilize the same cache. The paragraph you
referenced is extracted from the "Early access for developmental branch
users" section. This means that until integration is finalized, GNOME
Software will use the libdnf backend, which can operate alongside dnf5 but
maintains a separate cache. I'll revise the wiki paragraph to explicitly
state this as a temporary arrangement until integration is complete.

Previously, I had issues that migration from DNF4 to DNF5 left a lot of
> data in /var/cache. How is this going to be addressed? I don't think it is
> fair to leave those behind and waste disk space for regular users.
>

That's a good point. Though since this migration isn't entirely removing
dnf4 from the system but just altering the symlink, users can still access
it. Hence, automated removal isn't feasible. However, we could consider
offering a user prompt after the transaction involving symlink replacement,
advising users to delete /var/cache/dnf if they no longer intend to use
dnf4.

Thanks,
Jan

On Mon, Mar 25, 2024 at 5:59 PM Vít Ondruch  wrote:

>
> Dne 25. 03. 24 v 16:46 Aoife Moloney napsal(a):
>
> === Reduced footprint ===
> The dnf5 package is a fully-featured package manager that doesn't
> require Python dependencies.
>
> It also reduces the number of software management tools in Fedora by
> replacing both the dnf and microdnf packages.
>
> The installation size of the dnf5 stack in an empty container is
> approximately 60% smaller than the dnf installation.
>
> Currently, dnf, microdnf, and PackageKit use their own cache, leading
> to significant metadata redundancy. With dnf5 and dnf5daemon, which
> share metadata, this redundancy will be eliminated.
>
>
> ... snip ...
>
>
> = [https://github.com/rpm-software-management/dnf5/issues/169
> GNOME Software support] =
> The integration of dnf5 support, particularly dnf5daemon, into GNOME
> Software is currently underway. Developers from both DNF5 and GNOME
> Software are closely connected and regularly synchronize the progress
> of their work.
>
>
> ... snip ...
>
>
> = GNOME Software =
> Rawhide users will continue to utilize the current PackageKit backend
> connected to the existing libdnf interface. These libraries can
> coexist with the new dnf5 package on the same system. Although the
> setup is not ideal due to differences in package state metadata
> formats stored at separate locations, resulting in inefficient storage
> usage, this is generally imperceptible for typical GUI users.
> Furthermore, the underlying RPM DB remains the sole shared source of
> information about installed packages.
>
>
> I don't understand this. So if GS going to use DNF, therefore the same
> cache etc, or not? Or what other metadata PackageKit downloads on top of
> DNF?
>
>
>  Before upgrade 
> 
> $ tree /usr/bin/ -P dnf*
> /usr/bin/
> ├── dnf -> dnf-3
> ├── dnf-3
> └── dnf4 -> dnf-3
> 
>
>  After upgrade 
> 
> $ tree /usr/bin/ -P dnf*
> /usr/bin/
> ├── dnf -> dnf5
> ├── dnf-3
> ├── dnf4 -> dnf-3
> └── dnf5
> 
>
>
> 
>
> Love these versions, as always
>
> 
>
>
> === Different system state ===
> The transactional history in dnf and dnf5 is not shared, and they now
> use different formats. Transactions performed in dnf will not be
> visible in dnf5, and vice versa.
>
> While the history database is not migrated to dnf5, when running a
> transaction in dnf5 for the first time, an attempt is made to convert
> and load the existing system state from dnf. This should preserve
> information about the reasons for installed packages and prevent them
> from being treated as user-installed, requiring manual removal from
> the system instead of being seen as dependencies of explicitly removed
> packages.
>
>
> Previously, I had issues that migration from DNF4 to DNF5 left a lot of
> data in /var/cache. How is this going to be addressed? I don't think it is
> fair to leave those behind and waste disk space for regular users.
>
>
> Vít
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 

Re: Hoping to unorphan package edb

[Kevin Kofler via devel]

Pekka Oinas via devel wrote:
> The package for edb, a GUI debugger application, has been orphaned in
> Fedora for many years: https://src.fedoraproject.org/rpms/edb
> 
> I like this application and think it's useful, and would like to see it
> unorphaned. I have been building it in COPR at
> https://copr.fedorainfracloud.org/coprs/peoinas/edb-debugger/ for some
> time and just now updated my packaging configuration there to the newest
> version, 1.5.0, released a few days ago (though I am sure my spec files
> aren't up to mainline standards).
> 
> Unless some existing maintainer reading this mailing list becomes inspired
> to adopt this package, I would be interested in pursuing the packager
> sponsoring process in order to adopt or co-maintain this package. I would
> like some input, particularly from maintainers experienced in packaging Qt
> applications, on if this sounds like a good idea.

Given that this has been retired for more than 8 weeks (in fact, for way 
longer, more than 3 years), it needs a rereview anyway, see:
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming

So you can mostly just follow the usual process for getting sponsored: 
submit your specfile for review (but mention in the bug comments that it is 
a rereview for a retired package) and follow:
https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/
until the point where you would request a new dist-git repository to be 
created. The repository already exists, so in this case, you want instead to 
request unretirement as per:
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
– but please only after you got sponsored and the review request got 
approved!

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

[Bug 2265953] perl-Encode-3.21 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Encode-3.21-505.fc41   |perl-Encode-3.21-505.fc41
   ||perl-Encode-3.21-505.fc40



--- Comment #4 from Fedora Update System  ---
FEDORA-2024-f21fb72a29 (perl-Encode-3.21-505.fc40) has been pushed to the
Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202265953%23c4
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2265313] Upgrade perl-Text-Tabs+Wrap to 2024.001

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Text-Tabs+Wrap-2024.00 |perl-Text-Tabs+Wrap-2024.00
   |1-1.fc41|1-1.fc41
   ||perl-Text-Tabs+Wrap-2024.00
   ||1-1.fc40



--- Comment #4 from Fedora Update System  ---
FEDORA-2024-3eb9aec7c1 (perl-Text-Tabs+Wrap-2024.001-1.fc40) has been pushed to
the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202265313%23c4
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2265230] perl-perlfaq-5.20240218 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-perlfaq-5.20240218-1.f |perl-perlfaq-5.20240218-1.f
   |c41 |c41
   ||perl-perlfaq-5.20240218-1.f
   ||c40



--- Comment #4 from Fedora Update System  ---
FEDORA-2024-cd4a399bb4 (perl-perlfaq-5.20240218-1.fc40) has been pushed to the
Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202265230%23c4
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Hoping to unorphan package edb

[Pekka Oinas via devel]

The package for edb, a GUI debugger application, has been orphaned in Fedora 
for many years: https://src.fedoraproject.org/rpms/edb

I like this application and think it's useful, and would like to see it 
unorphaned. I have been building it in COPR at 
https://copr.fedorainfracloud.org/coprs/peoinas/edb-debugger/ for some time and 
just now updated my packaging configuration there to the newest version, 1.5.0, 
released a few days ago (though I am sure my spec files aren't up to mainline 
standards).

Unless some existing maintainer reading this mailing list becomes inspired to 
adopt this package, I would be interested in pursuing the packager sponsoring 
process in order to adopt or co-maintain this package. I would like some input, 
particularly from maintainers experienced in packaging Qt applications, on if 
this sounds like a good idea.

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

Re: Retiring Celestia from Fedora due to licensing issues

[Kevin Fenzi]

On Wed, Mar 20, 2024 at 04:36:02PM +, Mattia Verga via devel wrote:
> After I requested [1] Celestia project upstream to better define 
> licensing of all the textures and 3d models included in upstream data, 
> it turned out that at least some content is licensed CC-BY-NC-SA-3.0 [2] 
> which is not permitted in Fedora.
> 
> Upstream is still working on specify exactly the licenses of each file 
> and, maybe, in future will replace the problematic content with FOSS 
> textures. However, since there's no ETA for those tasks and the main 
> program cannot work by simply stripping out the problematic content, I 
> am forced to retire Celestia from Fedora.
> 
> I will be following the procedure for completely removing a package [3], 
> however there are a couple of things that I'd like to ask:
> 
> - should I wait for the flatpak maintainer to retire the flatpaks 
> (celestia-gtk and celestia-qt) before retiring the RPMs (celestia and 
> celestia-content)?

I don't think thats needed. The flatpak will not be able to build after
the rpm is gone, but thats ok, it shouldn't be in this case. 

> - do I need to ask releng to purge celestia sources from the lookaside 
> cache as well?

I'm not sure? Perhaps we could try and ask on the legal list?
We aren't really 'distributing' it there, just using that as part of our
build process. But of course it's available there.

> -do the flatpaks need to be added to fedora-obsolete-packages (or 
> something similar for flatpaks)?

Not sure on this one either. Would ask the flatpak sig.

kevin


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

Re: F41 Change Proposal: Change Compose Settings (system-wide)

[Kevin Fenzi]

On Mon, Mar 25, 2024 at 10:59:15PM +0100, Kevin Kofler via devel wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> 
> > On Mon, Mar 25, 2024 at 04:50:28PM -0400, Neal Gompa wrote:
> >> Keep in mind we also want to make the compose process faster too, I
> >> don't know if it's worth it to spend 20x more time compressing
> >> repodata when we keep trying to get back hours and minutes in the
> >> compose time.
> > 
> > I wanted to write that the compression times are small enough for this not
> > not matter, but indeed, at the very highest levels, they do become
> > noticable.
> 
> 5 minutes? On a process that is run once every 24 hours? While at the same 
> time saving download time for all Fedora users? I fail to see the issue.

7 repodata files compressed x 5 arches x 2 (debuginfo) x 2 (server and
Everything ) = 140 files * 5min -> 11 hours?

Thats of course a inflation of what it would be... most of the repodata
files are way smaller than filelists, but still... keep in mind that any
one thing we do, if we do it a zillion times will add up. 

kevin


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

Re: F41 Change Proposal: Change Compose Settings (system-wide)

[Kevin Kofler via devel]

Zbigniew Jędrzejewski-Szmek wrote:

> On Mon, Mar 25, 2024 at 04:50:28PM -0400, Neal Gompa wrote:
>> Keep in mind we also want to make the compose process faster too, I
>> don't know if it's worth it to spend 20x more time compressing
>> repodata when we keep trying to get back hours and minutes in the
>> compose time.
> 
> I wanted to write that the compression times are small enough for this not
> not matter, but indeed, at the very highest levels, they do become
> noticable.

5 minutes? On a process that is run once every 24 hours? While at the same 
time saving download time for all Fedora users? I fail to see the issue.

> $ time xz -k -v
> 8e09489af54bbd4ab85470d449f0b0afa4a26fc3eb97c1665c741427bbc8f060-
filelists.xml
> 8e09489af54bbd4ab85470d449f0b0afa4a26fc3eb97c1665c741427bbc8f060-
filelists.xml
> (1/1)
>   100 %44.3 MiB / 862.9 MiB = 0.05133 MiB/s   0:26
> xz -k -v   196.88s user 0.63s system 749% cpu 26.337 total
> (This is multithreaded, and gives a compression ratio of 5.14%.)

That is not the highest compression level of xz though. Try xz -9, it should 
be better than zstd. It will take longer to compress, but should actually be 
FASTER (!) to decompress, which is what really matters.

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

Re: F41 Change Proposal: Change Compose Settings (system-wide)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Mar 25, 2024 at 04:50:28PM -0400, Neal Gompa wrote:
> On Mon, Mar 25, 2024 at 4:40 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Mon, Mar 25, 2024 at 07:29:09PM +0100, Kevin Kofler via devel wrote:
> > > Daniel Alley wrote:
> > > > One more point: createrepo_c uses zstd compression level 10, but the 
> > > > range
> > > > goes all the way up to level 22.  I would oppose making the default much
> > > > computationally heavier than it is currently, but if spending 20x longer
> > > > to compress the repo 10% more is desirable to the fedora project, then
> > > > createrepo_c could perhaps add a the ability to select a compression
> > > > level.
> > > >
> > > > zstd at high compression levels is very nearly as good at compressing as
> > > > xz and sometimes better, while remaining much faster to decompress. --
> > >
> > > Considering that compression happens once on the server and downloading 
> > > and
> > > decompression happens many times on many computers, I think we should use
> > > the highest possible compression level.
> >
> > +1
> >
> 
> Keep in mind we also want to make the compose process faster too, I
> don't know if it's worth it to spend 20x more time compressing
> repodata when we keep trying to get back hours and minutes in the
> compose time.

I wanted to write that the compression times are small enough for this not
not matter, but indeed, at the very highest levels, they do become noticable.

$ mv 
8e09489af54bbd4ab85470d449f0b0afa4a26fc3eb97c1665c741427bbc8f060-filelists.xml 
filelists.xml
$ time zstd -k -9 filelists.xml
filelists.xml :  5.38%   (   863 MiB =>   46.4 MiB, filelists.xml.zst) 
zstd -k -9   4.96s user 0.18s system 103% cpu 4.971 total

$ time zstd -k -21 filelists.xml
Warning : compression level higher than max, reduced to 19 
filelists.xml :  4.74%   (   863 MiB =>   40.9 MiB, filelists.xml.zst) 
zstd -k -21   321.49s user 0.31s system 99% cpu 5:22.20 total

$ time zstd -k -21 -T8 filelists.xml
Warning : compression level higher than max, reduced to 19 
filelists.xml :  4.74%   (   863 MiB =>   40.9 MiB, filelists.xml.zst) 
zstd -k -21 -T8   874.57s user 0.70s system 732% cpu 1:59.51 total

$ time xz -k -v 
8e09489af54bbd4ab85470d449f0b0afa4a26fc3eb97c1665c741427bbc8f060-filelists.xml 
8e09489af54bbd4ab85470d449f0b0afa4a26fc3eb97c1665c741427bbc8f060-filelists.xml 
(1/1)
  100 %44.3 MiB / 862.9 MiB = 0.05133 MiB/s   0:26 
xz -k -v   196.88s user 0.63s system 749% cpu 26.337 total
(This is multithreaded, and gives a compression ratio of 5.14%.)

Dunno, I think anything below a minute should be OK…

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

Re: F41 Change Proposal: Change Compose Settings (system-wide)

[Neal Gompa]

On Mon, Mar 25, 2024 at 4:40 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Mon, Mar 25, 2024 at 07:29:09PM +0100, Kevin Kofler via devel wrote:
> > Daniel Alley wrote:
> > > One more point: createrepo_c uses zstd compression level 10, but the range
> > > goes all the way up to level 22.  I would oppose making the default much
> > > computationally heavier than it is currently, but if spending 20x longer
> > > to compress the repo 10% more is desirable to the fedora project, then
> > > createrepo_c could perhaps add a the ability to select a compression
> > > level.
> > >
> > > zstd at high compression levels is very nearly as good at compressing as
> > > xz and sometimes better, while remaining much faster to decompress. --
> >
> > Considering that compression happens once on the server and downloading and
> > decompression happens many times on many computers, I think we should use
> > the highest possible compression level.
>
> +1
>

Keep in mind we also want to make the compose process faster too, I
don't know if it's worth it to spend 20x more time compressing
repodata when we keep trying to get back hours and minutes in the
compose time.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Change Compose Settings (system-wide)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Mar 25, 2024 at 07:29:09PM +0100, Kevin Kofler via devel wrote:
> Daniel Alley wrote:
> > One more point: createrepo_c uses zstd compression level 10, but the range
> > goes all the way up to level 22.  I would oppose making the default much
> > computationally heavier than it is currently, but if spending 20x longer
> > to compress the repo 10% more is desirable to the fedora project, then
> > createrepo_c could perhaps add a the ability to select a compression
> > level.
> > 
> > zstd at high compression levels is very nearly as good at compressing as
> > xz and sometimes better, while remaining much faster to decompress. --
> 
> Considering that compression happens once on the server and downloading and 
> decompression happens many times on many computers, I think we should use 
> the highest possible compression level.

+1

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: Summary/Minutes from today's FESCo Meeting (2024-03-25)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Mar 25, 2024 at 08:30:30PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Text Log: 
> https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.log.txt
> HTML Log: 
> https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.log.html
> Text Minutes: 
> https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.txt
> HTML Minutes: 
> https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.html
> 
> * TOPIC: Init Process
> * TOPIC: #3173 F40 Change Proposal Status: Incomplete Changes
> * INFO: https://fedoraproject.org/wiki/Changes/DefaultBpfman
> * INFO: https://bugzilla.redhat.com/show_bug.cgi?id=2269411
> 
> * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2258084 
> * INFO: LLVM 18 is effectively complete. (@zbyszek:fedora.im, 19:44:47)
> 
> * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2258090 
> * INFO: Removing Opessl 1.1 is waiting on a pull request for python2.7, 
> which is almost ready.
>   [In fact, this PR was merged tonight and the build is in progress. Yay!]
> * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2260081
> 
> * INFO: Cloud image kiwification is done as of Beta. 
> * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2260082 
> 
> * TOPIC: #3182 Change: Open SSL No Engine
> * AGREED: REJECTED (+1, 1, -5)
> 
> * TOPIC: #3184 Possibility of Delaying Final Freeze Start Date
> * AGREED: REJECTED (-6, 0, 0)
> 
> * TOPIC: Next week's chair 
> * ACTION: Josh Stone will chair the next meeting. 
> 
> * TOPIC: Open Floor (@zbyszek:fedora.im, 20:15:05)
> * INFO: We will try to hold the meeting April 1st, even though there are 
> some worries about quorum because of the holidays.
> 
> Meeting ended at 2024-03-25 20:23:38
> 
> Action items
> 
> * Josh Stone will chair the next meeting. 

There was in fact one more that should have been announced together with the 
agenda:

= Discussed and Voted in the Ticket =

#3174 Nonresponsive maintainer: Irina Boverman irina
https://pagure.io/fesco/issue/3174
APPROVED: (+1, 0, 0)
--
___
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

Summary/Minutes from today's FESCo Meeting (2024-03-25)

[Zbigniew Jędrzejewski-Szmek]

Text Log: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.log.txt
HTML Log: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.log.html
Text Minutes: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.txt
HTML Minutes: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-25/fesco.2024-03-25-19.33.html

* TOPIC: Init Process
* TOPIC: #3173 F40 Change Proposal Status: Incomplete Changes
* INFO: https://fedoraproject.org/wiki/Changes/DefaultBpfman
* INFO: https://bugzilla.redhat.com/show_bug.cgi?id=2269411

* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2258084 
* INFO: LLVM 18 is effectively complete. (@zbyszek:fedora.im, 19:44:47)

* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2258090 
* INFO: Removing Opessl 1.1 is waiting on a pull request for python2.7, 
which is almost ready.
  [In fact, this PR was merged tonight and the build is in progress. Yay!]
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2260081

* INFO: Cloud image kiwification is done as of Beta. 
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2260082 

* TOPIC: #3182 Change: Open SSL No Engine
* AGREED: REJECTED (+1, 1, -5)

* TOPIC: #3184 Possibility of Delaying Final Freeze Start Date
* AGREED: REJECTED (-6, 0, 0)

* TOPIC: Next week's chair 
* ACTION: Josh Stone will chair the next meeting. 

* TOPIC: Open Floor (@zbyszek:fedora.im, 20:15:05)
* INFO: We will try to hold the meeting April 1st, even though there are 
some worries about quorum because of the holidays.

Meeting ended at 2024-03-25 20:23:38

Action items

* Josh Stone will chair the next meeting. 
--
___
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: Obsoleted packages in F40

[Kevin Kofler via devel]

Miroslav Suchý wrote:
> I just upgraded my workstation to F40 and it surprised how many packages
> were reported by `remove-retired-packages`. There was lots of orphaned
> packages - there is nothing to do about them. But there was lot of
> packages that were removed intentionally. See the list at the end of my
> email.
> 
> I want to highlight that we have policy for removing policy
> 
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#complete_removal
> which at the end mention adding the package to
> https://src.fedoraproject.org/rpms/fedora-obsolete-packages

The point of fedora-obsolete-packages is to remove packages that actually 
BREAK things when they remain installed. Otherwise, the best thing to do is 
to NOT obsolete those packages. Users might still rely on them. E.g., they 
might have locally built software that depends on the dropped compatibility 
libraries. Forcefully obsoleting those will break the locally installed 
software.

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

Re: F41 Change Proposal: Change Compose Settings (system-wide)

[Kevin Kofler via devel]

Daniel Alley wrote:
> One more point: createrepo_c uses zstd compression level 10, but the range
> goes all the way up to level 22.  I would oppose making the default much
> computationally heavier than it is currently, but if spending 20x longer
> to compress the repo 10% more is desirable to the fedora project, then
> createrepo_c could perhaps add a the ability to select a compression
> level.
> 
> zstd at high compression levels is very nearly as good at compressing as
> xz and sometimes better, while remaining much faster to decompress. --

Considering that compression happens once on the server and downloading and 
decompression happens many times on many computers, I think we should use 
the highest possible compression level.

By the way, xz also supports stronger parameters than -9 in principle, there 
is just no preset for it.

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

Re: F41 Change Proposal: Switch to DNF 5 (System-Wide)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Mar 25, 2024 at 03:46:47PM +, Aoife Moloney wrote:
> == Summary ==
> Change the default package manager from dnf to dnf5.
> 
> == Owner ==
> * Name: [[User:jkolarik| Jan Kolarik]]
> * Email: jkola...@redhat.com
> 
> * Name: [[User:jmracek| Jaroslav Mracek]]
> * Email: jmra...@redhat.com

First, thank you for putting together such a detailed proposal.
Having all the dependencies listed allows a proper evaluation of how
things are going to work during the upgrade.

Second, I think that the lack of support for dnf5 in some areas is
going to be painful: in particular, as long as Anaconda and PackageKit
depend on dnf-3, we're going to be in a strange state the basic system
tools use two different versions of the code, and perhaps more
importantly, use two different databases of information about
installed packages.

But, third, I think we should do the switch. Dnf5 is some aspects
significantly better than dnf-3, so users will really benefit from
the switch. And we cannot and should not maintain the situation where
the dnf team is working on two different versions of the code. We
need to switch to the new thing and devote the resources we have
to making it work great.

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

Re: F41 Change Proposal: Switch to DNF 5 (System-Wide)

[Gary Buhrmaster]

On Mon, Mar 25, 2024 at 4:59 PM Vít Ondruch  wrote:

>
> Previously, I had issues that migration from DNF4 to DNF5 left a lot of data 
> in /var/cache. How is this going to be addressed? I don't think it is fair to 
> leave those behind and waste disk space for regular users.
>

Are you suggesting the dnf(4) should have an additional
stanza in the %postun scriptlet something of the form
(following not tested, validated, or run, just prototype):

if [ -d /var/cache/dnf && "$1" -eq "0" ] ; then
  rm -r /var/cache/dnf || :
fi

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

Re: F41 Change Proposal: Switch to DNF 5 (System-Wide)

[Vít Ondruch]

Dne 25. 03. 24 v 16:46 Aoife Moloney napsal(a):


=== Reduced footprint ===
The dnf5 package is a fully-featured package manager that doesn't
require Python dependencies.

It also reduces the number of software management tools in Fedora by
replacing both the dnf and microdnf packages.

The installation size of the dnf5 stack in an empty container is
approximately 60% smaller than the dnf installation.

Currently, dnf, microdnf, and PackageKit use their own cache, leading
to significant metadata redundancy. With dnf5 and dnf5daemon, which
share metadata, this redundancy will be eliminated.



... snip ...




= [https://github.com/rpm-software-management/dnf5/issues/169
GNOME Software support] =
The integration of dnf5 support, particularly dnf5daemon, into GNOME
Software is currently underway. Developers from both DNF5 and GNOME
Software are closely connected and regularly synchronize the progress
of their work.



... snip ...




= GNOME Software =
Rawhide users will continue to utilize the current PackageKit backend
connected to the existing libdnf interface. These libraries can
coexist with the new dnf5 package on the same system. Although the
setup is not ideal due to differences in package state metadata
formats stored at separate locations, resulting in inefficient storage
usage, this is generally imperceptible for typical GUI users.
Furthermore, the underlying RPM DB remains the sole shared source of
information about installed packages.



I don't understand this. So if GS going to use DNF, therefore the same 
cache etc, or not? Or what other metadata PackageKit downloads on top of 
DNF?




 Before upgrade 

$ tree /usr/bin/ -P dnf*
/usr/bin/
├── dnf -> dnf-3
├── dnf-3
└── dnf4 -> dnf-3


 After upgrade 

$ tree /usr/bin/ -P dnf*
/usr/bin/
├── dnf -> dnf5
├── dnf-3
├── dnf4 -> dnf-3
└── dnf5






Love these versions, as always





=== Different system state ===
The transactional history in dnf and dnf5 is not shared, and they now
use different formats. Transactions performed in dnf will not be
visible in dnf5, and vice versa.

While the history database is not migrated to dnf5, when running a
transaction in dnf5 for the first time, an attempt is made to convert
and load the existing system state from dnf. This should preserve
information about the reasons for installed packages and prevent them
from being treated as user-installed, requiring manual removal from
the system instead of being seen as dependencies of explicitly removed
packages.



Previously, I had issues that migration from DNF4 to DNF5 left a lot of 
data in /var/cache. How is this going to be addressed? I don't think it 
is fair to leave those behind and waste disk space for regular users.



Vít



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

F41 Change Proposal: Versioned Kubernetes Packages (Self-Cont

[Aoife Moloney]

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

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

= Multiple Versioned Kubernetes Packages =

== Summary ==
Provide all maintained Kubernetes releases in Fedora as multiple,
versioned packages. Current practice is a separate Kubernetes release
matched with each Fedora release.

== Owner ==
* Name: [[User:Buckaroogeek| Brad Smith]]
* Email: bradley.g.sm...@gmail.com


== Detailed Description ==
The Kubernetes project maintains 3 concurrent versions with a new
release every 4 months. Each version has a defined life-cycle of
approximately 1 year (https://https://kubernetes.io/releases/ for
details and current versions). In this proposal a release is a
major:minor version combination such as 1.28 or 1.27 and ignores any
patch updates (e.g. 1.28.1 or 1.28.2 as these are part of the same
1.28 minor release).

We currently match one version of Kubernetes with each Fedora release.
See https://src.fedoraproject.org/rpms/kubernetes for the list of
Kubernetes releases by Fedora release. Due to the differing release
cadences between Fedora and Kubernetes this means that a new release
of Fedora may not have the most current release of Kubernetes. And,
given that the Kubernetes cluster upgrade process does not permit
skipping major:minor releases, not providing a Kubernetes release in
Fedora so that the most current Kubernetes release is available when a
Fedora release goes into production becomes a barrier to using Fedora
as a host OS for Kubernetes.

We propose to create packages for all current Kubernetes releases for
each Fedora release starting with Fedora 40. The package name would
follow the Fedora naming convention standard for multiple package
versions of "kubernetes[major].[minor]". Using the kubernetes-client
rpm as an example, instead of kubernetes-client-1.29.2-1.fc41 Fedora
would offer kubernetes1.29-client-1.29.2-1.fc41,
kubernetes1.28-client-1.28.5-1.fc41, and
kubernetes1.27-client-1.27.8-1.fc41. The exact list of Kubernetes
versions available will depend on what is supported upstream.

We also propose that there not be any default version of Kubernetes
for a given Fedora release. Fedora would not provide a
kubernetes-client-1.30.1-1.fc41 package available, assuming that
Kubernetes 1.30 is the "default" for Fedora 41. Default versions
coupled to a given Fedora release can result in unplanned version
updates to the installed Kubernetes version (i.e. v1.28 to v1.29)
which can adversely affect cluster functioning.

It is also important to note that each Kubernetes release is built
with a specific version of the Go language. The version of Go
available in a Fedora release will potentially be a constraint on
which version of Kubernetes can be provided for an older Fedora
release.

We also maintain a Kubernetes page on Fedora Quick Docs with
information about the change and how to install Kubernetes using
Fedora provided packages.

== Feedback ==
To be provided.

== Benefit to Fedora ==

Fedora becomes a first class platform for Kubernetes using packages
from Fedora repositories. That is, all current, maintained releases of
Kubernetes are available in the main Fedora repositories, subject to
the Go language constraint. This allows Fedora, as a host OS for a
Kubernetes cluster, to be maintained and upgraded independently of the
Kubernetes release used by the cluster. This also allows the cluster
to be upgraded independently of the Fedora release using Fedora
provided packages.

This also means that a Kubernetes cluster administrator using Fedora
as their workstation can install and use or retain the appropriate
Kubernetes command line client, kubectl, that matches the release of
the cluster. Updating to a new Fedora release will not inadvertently
install a command line client that is not compatible with the release
version of the cluster(s) managed by the user.


== Scope ==
* Proposal owners:
With each new minor release of Kubernetes, package owners would
request a new repository on src.fedoraproject.org from engineering
similar to what the nodejs team now does for the parallel-installable
versions of nodejs. Documentation would be refreshed to inform users
of the new version and what specific Fedora releases the new version
of Kubernetes would be available on.

* Other developers:
Releases of cri-o and cri-tools are version matched with Kubernetes
release at the major:minor level. Cri-o uses modularity in Fedora 38
and older to provide multiple versions. The cri-o and cri-tools
package maintainers will adopt a similar versioned approach to
packaging and release in Fedora.

* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
Release engineering would need to create the new dist-git repository
for each new Kubernetes 

F41 Change Proposal: Versioned Kubernetes Packages (Self-Cont

[Aoife Moloney]

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

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

= Multiple Versioned Kubernetes Packages =

== Summary ==
Provide all maintained Kubernetes releases in Fedora as multiple,
versioned packages. Current practice is a separate Kubernetes release
matched with each Fedora release.

== Owner ==
* Name: [[User:Buckaroogeek| Brad Smith]]
* Email: bradley.g.sm...@gmail.com


== Detailed Description ==
The Kubernetes project maintains 3 concurrent versions with a new
release every 4 months. Each version has a defined life-cycle of
approximately 1 year (https://https://kubernetes.io/releases/ for
details and current versions). In this proposal a release is a
major:minor version combination such as 1.28 or 1.27 and ignores any
patch updates (e.g. 1.28.1 or 1.28.2 as these are part of the same
1.28 minor release).

We currently match one version of Kubernetes with each Fedora release.
See https://src.fedoraproject.org/rpms/kubernetes for the list of
Kubernetes releases by Fedora release. Due to the differing release
cadences between Fedora and Kubernetes this means that a new release
of Fedora may not have the most current release of Kubernetes. And,
given that the Kubernetes cluster upgrade process does not permit
skipping major:minor releases, not providing a Kubernetes release in
Fedora so that the most current Kubernetes release is available when a
Fedora release goes into production becomes a barrier to using Fedora
as a host OS for Kubernetes.

We propose to create packages for all current Kubernetes releases for
each Fedora release starting with Fedora 40. The package name would
follow the Fedora naming convention standard for multiple package
versions of "kubernetes[major].[minor]". Using the kubernetes-client
rpm as an example, instead of kubernetes-client-1.29.2-1.fc41 Fedora
would offer kubernetes1.29-client-1.29.2-1.fc41,
kubernetes1.28-client-1.28.5-1.fc41, and
kubernetes1.27-client-1.27.8-1.fc41. The exact list of Kubernetes
versions available will depend on what is supported upstream.

We also propose that there not be any default version of Kubernetes
for a given Fedora release. Fedora would not provide a
kubernetes-client-1.30.1-1.fc41 package available, assuming that
Kubernetes 1.30 is the "default" for Fedora 41. Default versions
coupled to a given Fedora release can result in unplanned version
updates to the installed Kubernetes version (i.e. v1.28 to v1.29)
which can adversely affect cluster functioning.

It is also important to note that each Kubernetes release is built
with a specific version of the Go language. The version of Go
available in a Fedora release will potentially be a constraint on
which version of Kubernetes can be provided for an older Fedora
release.

We also maintain a Kubernetes page on Fedora Quick Docs with
information about the change and how to install Kubernetes using
Fedora provided packages.

== Feedback ==
To be provided.

== Benefit to Fedora ==

Fedora becomes a first class platform for Kubernetes using packages
from Fedora repositories. That is, all current, maintained releases of
Kubernetes are available in the main Fedora repositories, subject to
the Go language constraint. This allows Fedora, as a host OS for a
Kubernetes cluster, to be maintained and upgraded independently of the
Kubernetes release used by the cluster. This also allows the cluster
to be upgraded independently of the Fedora release using Fedora
provided packages.

This also means that a Kubernetes cluster administrator using Fedora
as their workstation can install and use or retain the appropriate
Kubernetes command line client, kubectl, that matches the release of
the cluster. Updating to a new Fedora release will not inadvertently
install a command line client that is not compatible with the release
version of the cluster(s) managed by the user.


== Scope ==
* Proposal owners:
With each new minor release of Kubernetes, package owners would
request a new repository on src.fedoraproject.org from engineering
similar to what the nodejs team now does for the parallel-installable
versions of nodejs. Documentation would be refreshed to inform users
of the new version and what specific Fedora releases the new version
of Kubernetes would be available on.

* Other developers:
Releases of cri-o and cri-tools are version matched with Kubernetes
release at the major:minor level. Cri-o uses modularity in Fedora 38
and older to provide multiple versions. The cri-o and cri-tools
package maintainers will adopt a similar versioned approach to
packaging and release in Fedora.

* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
Release engineering would need to create the new dist-git repository
for each new Kubernetes 

F41 Change Proposal: Switch to DNF 5 (System-Wide)

[Aoife Moloney]

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

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

== Summary ==
Change the default package manager from dnf to dnf5.

== Owner ==
* Name: [[User:jkolarik| Jan Kolarik]]
* Email: jkola...@redhat.com

* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmra...@redhat.com



== Detailed Description ==
This proposal will implement several topics, which are outlined below.

=== Provider of the dnf command ===
This change proposes to switch the current provider of the
/usr/bin/dnf symlink from dnf to dnf5. Currently, the symlink target
is /usr/bin/dnf-3, provided by the dnf sub-package, python3-dnf. Upon
implementation of this change, the symlink will point to
/usr/bin/dnf5, provided by the dnf5 package.

=== Prepare the upgrade path ===
The dnf5 package, serving as the new provider of the /usr/bin/dnf
symlink, will obsolete the dnf package starting with Fedora 41. Upon
the release of this dnf5 package, upgrading the system or installing
dnf5 will replace the existing dnf package on the system.
Additionally, the dnf5 package will provide a /usr/bin/yum symlink for
backwards compatibility and the dnf-automatic command will be
obsoleted.

=== Feature parity with dnf ===
We aim to cover the majority of use cases available in the existing
dnf package. However, there are some features that may not be
implemented in time. Nevertheless, we plan to deliver them at a later
stage.

 Plugins 
The progress of implementing plugins to match the current set from the
dnf-plugins-core package is tracked
[https://github.com/rpm-software-management/dnf5/issues/389 upstream].
Among the missing plugins, we still plan to implement:

* debuginfo-install plugin
* reposync plugin

 Modularity 
As support for modularity was retired in Fedora 39, dnf5 currently
only implements a basic feature set for listing and enabling/disabling
modules.

=== Background service support ===
A new daemonized service, dnf5daemon, utilizing the D-Bus interface,
is prepared for clients as a sub-package. This will serve as an
alternative or replacement for the PackageKit layer. Integration of
dnf5daemon support into the default Fedora user interface, GNOME
Software, is currently in progress

=== Documentation of API changes ===
The public interface has undergone significant changes to enhance the
user experience and remove unused and obsolete code components. To
facilitate user migration to the new CLI and API interfaces, a
[https://dnf5.readthedocs.io/en/latest/changes.html guide] was
prepared covering all differences compared to the interface provided
by the existing dnf package, along with examples of typical use cases.

=== Deployment tasks ===
During the deployment of the dnf5 package manager as the new default,
several adjustments need to be made both to the infrastructure and the
dnf5 package itself. Some of these adjustments are detailed [[#Release
engineering|below]]. To ensure synchronization and address all
necessary changes, we've established an upstream tracking
[https://github.com/rpm-software-management/dnf5/issues/1057 issue].

== Feedback ==
As this is the second iteration of such a proposal, we've gathered a
lot of feedback from various sources during the first attempt to
accept this change.

=== FESCo inputs ===
A [https://pagure.io/fesco/issue/3039 ticket] discussing the reasons
why the contingency mechanism was invoked for the first attempt of the
proposal was opened by FESCo. It includes a list of items that are
either incomplete or in progress.

Below is a list of issues from the ticket that are still unresolved or
require clarification on their current status. Other items not
mentioned below are considered completed.

 Switch in ELN 
This should not block the proposal, as the current plan is to target
RHEL 11. Integration can occur there after the proposal is implemented
for Fedora 41.

 Aligning configuration with the current state in dnf 
All overrides to match the current state of dnf configuration will be
provided to the Fedora release project, see [[#Apply downstream
configuration overrides|below]].

 System upgrade and offline transactions 
The implementation work has been completed and is already present
upstream. We anticipate extensive testing during the summer, and we
also plan to organize testing days for this purpose.

 Dropping the Snapper plugin 
In dnf5, we've adopted a new approach for implementing functionality
that was previously handled by the Snapper plugin in dnf.

We're introducing the Actions plugin, which offers more capabilities
than the Snapper plugin, including support for running external
applications before or after transactions and interacting with the
dnf5 configuration.

F41 Change Proposal: Switch to DNF 5 (System-Wide)

[Aoife Moloney]

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

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

== Summary ==
Change the default package manager from dnf to dnf5.

== Owner ==
* Name: [[User:jkolarik| Jan Kolarik]]
* Email: jkola...@redhat.com

* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmra...@redhat.com



== Detailed Description ==
This proposal will implement several topics, which are outlined below.

=== Provider of the dnf command ===
This change proposes to switch the current provider of the
/usr/bin/dnf symlink from dnf to dnf5. Currently, the symlink target
is /usr/bin/dnf-3, provided by the dnf sub-package, python3-dnf. Upon
implementation of this change, the symlink will point to
/usr/bin/dnf5, provided by the dnf5 package.

=== Prepare the upgrade path ===
The dnf5 package, serving as the new provider of the /usr/bin/dnf
symlink, will obsolete the dnf package starting with Fedora 41. Upon
the release of this dnf5 package, upgrading the system or installing
dnf5 will replace the existing dnf package on the system.
Additionally, the dnf5 package will provide a /usr/bin/yum symlink for
backwards compatibility and the dnf-automatic command will be
obsoleted.

=== Feature parity with dnf ===
We aim to cover the majority of use cases available in the existing
dnf package. However, there are some features that may not be
implemented in time. Nevertheless, we plan to deliver them at a later
stage.

 Plugins 
The progress of implementing plugins to match the current set from the
dnf-plugins-core package is tracked
[https://github.com/rpm-software-management/dnf5/issues/389 upstream].
Among the missing plugins, we still plan to implement:

* debuginfo-install plugin
* reposync plugin

 Modularity 
As support for modularity was retired in Fedora 39, dnf5 currently
only implements a basic feature set for listing and enabling/disabling
modules.

=== Background service support ===
A new daemonized service, dnf5daemon, utilizing the D-Bus interface,
is prepared for clients as a sub-package. This will serve as an
alternative or replacement for the PackageKit layer. Integration of
dnf5daemon support into the default Fedora user interface, GNOME
Software, is currently in progress

=== Documentation of API changes ===
The public interface has undergone significant changes to enhance the
user experience and remove unused and obsolete code components. To
facilitate user migration to the new CLI and API interfaces, a
[https://dnf5.readthedocs.io/en/latest/changes.html guide] was
prepared covering all differences compared to the interface provided
by the existing dnf package, along with examples of typical use cases.

=== Deployment tasks ===
During the deployment of the dnf5 package manager as the new default,
several adjustments need to be made both to the infrastructure and the
dnf5 package itself. Some of these adjustments are detailed [[#Release
engineering|below]]. To ensure synchronization and address all
necessary changes, we've established an upstream tracking
[https://github.com/rpm-software-management/dnf5/issues/1057 issue].

== Feedback ==
As this is the second iteration of such a proposal, we've gathered a
lot of feedback from various sources during the first attempt to
accept this change.

=== FESCo inputs ===
A [https://pagure.io/fesco/issue/3039 ticket] discussing the reasons
why the contingency mechanism was invoked for the first attempt of the
proposal was opened by FESCo. It includes a list of items that are
either incomplete or in progress.

Below is a list of issues from the ticket that are still unresolved or
require clarification on their current status. Other items not
mentioned below are considered completed.

 Switch in ELN 
This should not block the proposal, as the current plan is to target
RHEL 11. Integration can occur there after the proposal is implemented
for Fedora 41.

 Aligning configuration with the current state in dnf 
All overrides to match the current state of dnf configuration will be
provided to the Fedora release project, see [[#Apply downstream
configuration overrides|below]].

 System upgrade and offline transactions 
The implementation work has been completed and is already present
upstream. We anticipate extensive testing during the summer, and we
also plan to organize testing days for this purpose.

 Dropping the Snapper plugin 
In dnf5, we've adopted a new approach for implementing functionality
that was previously handled by the Snapper plugin in dnf.

We're introducing the Actions plugin, which offers more capabilities
than the Snapper plugin, including support for running external
applications before or after transactions and interacting with the
dnf5 configuration.

F41 Change Proposal: RPM 4.20 (System-Wide)

[Aoife Moloney]

Wiki - https://fedoraproject.org/wiki/Changes/RPM-4.20

== Summary ==
Update RPM to the up coming  [https://rpm.org/wiki/Releases/4.20.0
4.20] release.

== Owner ==
* Name: [[User:ffesti| Florian Festi]]
* Email: ffe...@redhat.com



== Detailed Description ==

RPM 4.20 contains various improvements over previous versions.

* Hands-free packaging
** [https://github.com/rpm-software-management/rpm/issues/1087
Declarative build system]
** Dynamic spec generation extended
** [https://github.com/orgs/rpm-software-management/projects/16/views/1
File trigger scriptlet arguments]
** [https://github.com/rpm-software-management/rpm/issues/782 Support
for spec local dependency generators]
** [https://github.com/rpm-software-management/rpm/issues/2816 Support
for sysusers 'm' directive]
** [https://github.com/rpm-software-management/rpm/issues/2078
Guaranteed per-build directory]
* [https://github.com/rpm-software-management/rpm/issues/1536 Public plugin API]
* Increased install scriptlet isolation
([https://github.com/rpm-software-management/rpm/issues/2632 #2632],
[https://github.com/rpm-software-management/rpm/issues/2665 #2665])

The 4.20 alpha release is expected in late March/early April and the
final release is expected in time for the Fedora 41 release cycle as
usual.

== Feedback ==


== Benefit to Fedora ==

This release comes with many improvements. It opens the possibility
for Fedora to adopt the new major features mentioned above.

== Scope ==
* Proposal owners:
** Release RPM 4.20 alpha
** Rebase RPM in rawhide
** Assist with dealing with incompatibilities
* Other developers:
** Test new release, report issues and bugs

* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: None


== Upgrade/compatibility impact ==


== How To Test ==
Rpm receives a thorough and constant testing via every single package
build, system installs and updates. New features can be tested
specifically as per their documentation.

== User Experience ==
There are no major differences in the normal user experience.

== Dependencies ==


== Contingency Plan ==
* Contingency mechanism: Revert back to RPM 4.19
* Contingency deadline: Beta freeze
* Blocks release? No


== Documentation ==
Release notes at https://rpm.org/wiki/Releases/4.20.0 (still tbd) and
reference manual at
https://rpm-software-management.github.io/rpm/manual/


== Release Notes ==



-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@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-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

F41 Change Proposal: RPM 4.20 (System-Wide)

[Aoife Moloney]

Wiki - https://fedoraproject.org/wiki/Changes/RPM-4.20

== Summary ==
Update RPM to the up coming  [https://rpm.org/wiki/Releases/4.20.0
4.20] release.

== Owner ==
* Name: [[User:ffesti| Florian Festi]]
* Email: ffe...@redhat.com



== Detailed Description ==

RPM 4.20 contains various improvements over previous versions.

* Hands-free packaging
** [https://github.com/rpm-software-management/rpm/issues/1087
Declarative build system]
** Dynamic spec generation extended
** [https://github.com/orgs/rpm-software-management/projects/16/views/1
File trigger scriptlet arguments]
** [https://github.com/rpm-software-management/rpm/issues/782 Support
for spec local dependency generators]
** [https://github.com/rpm-software-management/rpm/issues/2816 Support
for sysusers 'm' directive]
** [https://github.com/rpm-software-management/rpm/issues/2078
Guaranteed per-build directory]
* [https://github.com/rpm-software-management/rpm/issues/1536 Public plugin API]
* Increased install scriptlet isolation
([https://github.com/rpm-software-management/rpm/issues/2632 #2632],
[https://github.com/rpm-software-management/rpm/issues/2665 #2665])

The 4.20 alpha release is expected in late March/early April and the
final release is expected in time for the Fedora 41 release cycle as
usual.

== Feedback ==


== Benefit to Fedora ==

This release comes with many improvements. It opens the possibility
for Fedora to adopt the new major features mentioned above.

== Scope ==
* Proposal owners:
** Release RPM 4.20 alpha
** Rebase RPM in rawhide
** Assist with dealing with incompatibilities
* Other developers:
** Test new release, report issues and bugs

* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: None


== Upgrade/compatibility impact ==


== How To Test ==
Rpm receives a thorough and constant testing via every single package
build, system installs and updates. New features can be tested
specifically as per their documentation.

== User Experience ==
There are no major differences in the normal user experience.

== Dependencies ==


== Contingency Plan ==
* Contingency mechanism: Revert back to RPM 4.19
* Contingency deadline: Beta freeze
* Blocks release? No


== Documentation ==
Release notes at https://rpm.org/wiki/Releases/4.20.0 (still tbd) and
reference manual at
https://rpm-software-management.github.io/rpm/manual/


== Release Notes ==



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

Fedora 40 compose report: 20240325.n.0 changes

[Fedora Branched Report]

OLD: Fedora-40-20240324.n.0
NEW: Fedora-40-20240325.n.0

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

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

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

= ADDED IMAGES =
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Generic.s390x-40-20240325.n.0.qcow2

= DROPPED IMAGES =
Image: LXQt live x86_64
Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-40-20240324.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  chromium-123.0.6312.58-1.fc40
Old package:  chromium-122.0.6261.111-1.fc40
Summary:  A WebKit (Blink) powered web browser that Google doesn't want you 
to use
RPMs: chromedriver chromium chromium-common chromium-headless
Size: 307.58 MiB
Size change:  1003.20 KiB
Changelog:
  * Mon Mar 11 2024 Than Ngo  - 122.0.6261.111-2
  - enable ppc64le build

  * Wed Mar 13 2024 Than Ngo  - 122.0.6261.128-1
  - upstream security release 122.0.6261.128
 * High CVE-2024-2400: Use after free in Performance Manager

  * Fri Mar 15 2024 Than Ngo  - 123.0.6312.46-1
  - update to 123.0.6312.46

  * Wed Mar 20 2024 Than Ngo  - 123.0.6312.58-1
  - update to 123.0.6312.58
 * High CVE-2024-2625: Object lifecycle issue in V8
 * Medium CVE-2024-2626: Out of bounds read in Swiftshader
 * Medium CVE-2024-2627: Use after free in Canvas
 * Medium CVE-2024-2628: Inappropriate implementation in Downloads
 * Medium CVE-2024-2629: Incorrect security UI in iOS
 * Medium CVE-2024-2630: Inappropriate implementation in iOS
 * Low CVE-2024-2631: Inappropriate implementation in iOS


Package:  firefox-124.0.1-1.fc40
Old package:  firefox-124.0-1.fc40
Summary:  Mozilla Firefox Web browser
RPMs: firefox firefox-langpacks
Size: 457.03 MiB
Size change:  190.67 KiB

Package:  glibc-2.39-4.fc40
Old package:  glibc-2.39-2.fc40
Summary:  The GNU libc libraries
RPMs: compat-libpthread-nonshared glibc glibc-all-langpacks 
glibc-benchtests glibc-common glibc-devel glibc-doc glibc-gconv-extra 
glibc-headers-s390 glibc-headers-x86 glibc-langpack-aa glibc-langpack-af 
glibc-langpack-agr glibc-langpack-ak glibc-langpack-am glibc-langpack-an 
glibc-langpack-anp glibc-langpack-ar glibc-langpack-as glibc-langpack-ast 
glibc-langpack-ayc glibc-langpack-az glibc-langpack-be glibc-langpack-bem 
glibc-langpack-ber glibc-langpack-bg glibc-langpack-bhb glibc-langpack-bho 
glibc-langpack-bi glibc-langpack-bn glibc-langpack-bo glibc-langpack-br 
glibc-langpack-brx glibc-langpack-bs glibc-langpack-byn glibc-langpack-ca 
glibc-langpack-ce glibc-langpack-chr glibc-langpack-ckb glibc-langpack-cmn 
glibc-langpack-crh glibc-langpack-cs glibc-langpack-csb glibc-langpack-cv 
glibc-langpack-cy glibc-langpack-da glibc-langpack-de glibc-langpack-doi 
glibc-langpack-dsb glibc-langpack-dv glibc-langpack-dz glibc-langpack-el 
glibc-langpack-en glibc-langpack-eo glibc-langpack-es glibc-langpack-et 
glibc-langpack-eu glibc-langpack-fa glibc-langpack-ff glibc-langpack-fi 
glibc-langpack-fil glibc-langpack-fo glibc-langpack-fr glibc-langpack-fur 
glibc-langpack-fy glibc-langpack-ga glibc-langpack-gbm glibc-langpack-gd 
glibc-langpack-gez glibc-langpack-gl glibc-langpack-gu glibc-langpack-gv 
glibc-langpack-ha glibc-langpack-hak glibc-langpack-he glibc-langpack-hi 
glibc-langpack-hif glibc-langpack-hne glibc-langpack-hr glibc-langpack-hsb 
glibc-langpack-ht glibc-langpack-hu glibc-langpack-hy glibc-langpack-ia 
glibc-langpack-id glibc-langpack-ig glibc-langpack-ik glibc-langpack-is 
glibc-langpack-it glibc-langpack-iu glibc-langpack-ja glibc-langpack-ka 
glibc-langpack-kab glibc-langpack-kk glibc-langpack-kl glibc-langpack-km 
glibc-langpack-kn glibc-langpack-ko glibc-langpack-kok glibc-langpack-ks 
glibc-langpack-ku glibc-langpack-kv glibc-langpack-kw glibc-langpack-ky 
glibc-langpack-lb glibc-langpack-lg glibc-langpack-li glibc-langpack-lij 
glibc-langpack-ln glibc-langpack-lo glibc-langpack-lt glibc-langpack-lv 
glibc-langpack-lzh glibc-langpack-mag glibc-langpack-mai glibc-langpack-mfe 
glibc-langpack-mg glibc-langpack-mhr glibc-langpack-mi glibc-langpack-miq 
glibc-langpack-mjw glibc-langpack-mk glibc-langpack-ml glibc-langpack-mn 
glibc-langpack-mni glibc-langpack-mnw glibc-langpack-mr glibc-langpack-ms 
glibc-langpack-mt glibc-langpack-my glibc-langpack-nan glibc-langpack-nb 
glibc-langpack-nds glibc-langpack-ne glibc-langpack-nhn glibc-langpack-niu 
glibc-langpack-nl glibc-langpack-nn glibc-langpack-nr glibc-langpack-nso 
glibc-langpack-oc glibc-langpack-om glibc-langpack-or glibc-langpack-os 
glibc-langpack-pa glibc-langpack-pap glibc-langpack-pl glibc-langpack-ps 
glibc-langpack-pt glibc-langpack-quz glibc

Re: Obsoleted packages in F40

[Zbigniew Jędrzejewski-Szmek]

On Mon, Mar 25, 2024 at 07:30:43AM -0700, Tom Stellard wrote:
> On 3/24/24 02:25, Miroslav Suchý wrote:
> > I just upgraded my workstation to F40 and it surprised how many packages 
> > were reported by `remove-retired-packages`.
> > There was lots of orphaned packages - there is nothing to do about them. 
> > But there was lot of packages that were removed intentionally. See the list 
> > at the end of my email.
> > 
> > I want to highlight that we have policy for removing policy
> >     
> > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#complete_removal
> > which at the end mention adding the package to
> >     https://src.fedoraproject.org/rpms/fedora-obsolete-packages
> > 
> > Doing this will improve the experience of users upgrading to the next 
> > Fedora version.
> > 
> 
> Sorry, I missed this step for some of my packages.  Is there still
> time to add packages to fedora-obsolete-packages for f41?

Yes, both for f40 and f41. There is actually no time limit: if
we figure out that e.g. a package is blocking upgrades, we'll add it to
f-o-p even after the release.

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: Obsoleted packages in F40

[Tom Stellard]

On 3/24/24 02:25, Miroslav Suchý wrote:

I just upgraded my workstation to F40 and it surprised how many packages were 
reported by `remove-retired-packages`.
There was lots of orphaned packages - there is nothing to do about them. But 
there was lot of packages that were removed intentionally. See the list at the 
end of my email.

I want to highlight that we have policy for removing policy
    
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#complete_removal
which at the end mention adding the package to
    https://src.fedoraproject.org/rpms/fedora-obsolete-packages

Doing this will improve the experience of users upgrading to the next Fedora 
version.



Sorry, I missed this step for some of my packages.  Is there still
time to add packages to fedora-obsolete-packages for f41?

-Tom



For the list below I will submit PR.


List of removed packages in F40:

Removing ldc1.32-libs: LLVM D Compiler libraries
Reason of retirement: Compat package no longer needed

Removing ldc1.30-libs: LLVM D Compiler libraries
Reason of retirement: Compat package no longer needed

Removing clang14-libs: Runtime library for clang
Reason of retirement: This compat package is no longer used: 
https://fedoraproject.org/wiki/Changes/LLVM-18

Removing clang11-resource-filesystem: Filesystem package that owns the clang 
resource directory
Reason of retirement: Orphaned for 6+ weeks

Removing clang11-libs: Runtime library for clang
Reason of retirement: Orphaned for 6+ weeks

Removing anaconda-user-help: Content for the Anaconda built-in help system
Reason of retirement: Retired due to the build-in help system in the Anaconda 
GTK UI being removed

Removing libicu72: International Components for Unicode
Reason of retirement: libicu72 isn't required by anything in fc40, was solely a 
compat package for icu 73 rebase

Removing libvpx7: Compat package with libvpx libraries
Reason of retirement: Retire old compat package in F40+

Removing llvm7.0-libs: LLVM shared libraries
Reason of retirement: obsolete and no longer used (#2258890)

Removing pcmciautils: PCMCIA utilities and initialization programs
Reason of retirement: These are only used for 16 bit (basically ISA) PCMCIA 
cards which are being actively removed from the kernel

Removing python3.7: Version 3.7 of the Python interpreter
Reason of retirement: https://fedoraproject.org/wiki/Changes/RetirePython3.7



--
___
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: Obsoleted packages in F40

[Tulio Magno Quites Machado Filho]

Miroslav Suchý  writes:

> I just upgraded my workstation to F40 and it surprised how many packages were 
> reported by `remove-retired-packages`.
> There was lots of orphaned packages - there is nothing to do about them. But 
> there was lot of packages that were removed 
> intentionally. See the list at the end of my email.
>
> I want to highlight that we have policy for removing policy
> 
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#complete_removal
> which at the end mention adding the package to
> https://src.fedoraproject.org/rpms/fedora-obsolete-packages

Thanks for raising this. It was not clear to me these cases should be
completely removed.
I created a PR hoping to make it clear:
https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/151

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

Schedule for Monday's FESCo Meeting (2024-03-25)

[Zbigniew Jędrzejewski-Szmek]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 19:30 UTC in #meeting:fedoraproject.org
on Matrix.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2024-03-25 19:30 UTC'

Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

#3180 Change: SPDX License Phase 4 (The last one)
https://pagure.io/fesco/issue/3180
APPROVED (+8, 0, 0)

#3144 Nonresponsive maintainer: Christopher Engelhard lcts
https://pagure.io/fesco/issue/3144
APPROVED (+2, 0, 0)

= Followups =

#3173 F40 Change Proposal Status: Incomplete Changes 
https://pagure.io/fesco/issue/3173

= New business =

#3182 Change: Open SSL No Engine
https://pagure.io/fesco/issue/3182

#3184 Possibility of Delaying Final Freeze Start Date
https://pagure.io/fesco/issue/3184

= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Change Compose Settings (system-wide)

[Daniel Alley]

One more point: createrepo_c uses zstd compression level 10, but the range goes 
all the way up to level 22.  I would oppose making the default much 
computationally heavier than it is currently, but if spending 20x longer to 
compress the repo 10% more is desirable to the fedora project, then 
createrepo_c could perhaps add a the ability to select a compression level.

zstd at high compression levels is very nearly as good at compressing as xz and 
sometimes better, while remaining much faster to decompress.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20240325.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20240324.n.0
NEW: Fedora-Rawhide-20240325.n.0

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

Size of added packages:  66.84 KiB
Size of dropped packages:0 B
Size of upgraded packages:   157.21 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

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

= ADDED PACKAGES =
Package: rust-heck0.4-0.4.1-1.fc41
Summary: Case conversion library
RPMs:rust-heck0.4+default-devel rust-heck0.4+unicode-devel 
rust-heck0.4+unicode-segmentation-devel rust-heck0.4-devel
Size:41.16 KiB

Package: rust-strsim0.10-0.10.0-1.fc41
Summary: Implementations of string similarity metrics
RPMs:rust-strsim0.10+default-devel rust-strsim0.10-devel
Size:25.68 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  blend2d-0.10.6-2.fc41
Old package:  blend2d-0.10.6-1.fc41
Summary:  2D Vector Graphics Engine Powered by a JIT Compiler
RPMs: blend2d blend2d-devel
Size: 3.63 MiB
Size change:  807.82 KiB
Changelog:
  * Sun Mar 24 2024 topazus  - 0.10.6-2
  - add s390x build


Package:  budgie-desktop-10.9.1-2.fc41
Old package:  budgie-desktop-10.9.1-1.fc40
Summary:  A feature-rich, modern desktop designed to keep out the way of 
the user
RPMs: budgie-desktop budgie-desktop-devel budgie-desktop-docs
Size: 8.39 MiB
Size change:  1.69 KiB
Changelog:
  * Sun Mar 24 2024 Joshua Strobl  - 10.9.1-2
  - Backport patches, fix FTBFS on gcc 14, support latest libxfce4windowing git


Package:  fedora-upgrade-40.1-1.fc41
Old package:  fedora-upgrade-39.1-3.fc40
Summary:  Upgrade Fedora to next version using dnf upgrade (unofficial tool)
RPMs: fedora-upgrade remove-retired-packages
Size: 42.24 KiB
Size change:  -805 B
Changelog:
  * Sun Mar 24 2024 Miroslav Such??  39.2-1
  - add upgrade to F40

  * Sun Mar 24 2024 Miroslav Such??  40.1-1
  - upgrade to F40


Package:  gnome-shell-extension-dash-to-panel-61-1.fc41
Old package:  gnome-shell-extension-dash-to-panel-60-2.fc41
Summary:  Integrated icon taskbar and status panel for Gnome Shell
RPMs: gnome-shell-extension-dash-to-panel
Size: 221.60 KiB
Size change:  1.90 KiB
Changelog:
  * Sun Mar 24 2024 Dominik Mierzejewski  - 61-1
  - update to 61 (#2271317)


Package:  hardinfo2-2.0.18-1.fc41
Old package:  hardinfo2-2.0.15-1.fc41
Summary:  System Information and Benchmark for Linux Systems
RPMs: hardinfo2
Size: 5.42 MiB
Size change:  17.07 KiB
Changelog:
  * Tue Mar 12 2024 Felix Wang  - 2.0.15-2
  - Fix build issues on epel 7 and 8

  * Tue Mar 12 2024 Felix Wang  - 2.0.15-3
  - fix build on epel 7; do not use ninja-nuild on epel

  * Tue Mar 12 2024 Felix Wang  - 2.0.15-4
  - fix build on epel 7; correct license

  * Sun Mar 24 2024 topazus  - 2.0.18-1
  - 2.0.18


Package:  hyprcursor-0.1.5-1.fc41
Old package:  hyprcursor-0.1.4-1.fc41
Summary:  The hyprland cursor format, library and utilities
RPMs: hyprcursor hyprcursor-devel
Size: 518.89 KiB
Size change:  2.73 KiB
Changelog:
  * Sun Mar 24 2024 Pavel Solovev  - 0.1.5-1
  - Update to 0.1.5


Package:  imhex-1.33.2-1.fc41
Old package:  imhex-1.33.1-1.fc41
Summary:  A hex editor for reverse engineers and programmers
RPMs: imhex imhex-devel imhex-patterns
Size: 19.52 MiB
Size change:  -684.02 KiB
Changelog:
  * Sun Mar 24 2024 Jonathan Wright  - 1.33.2-1
  - Update to 1.33.2 rhbz#2256886


Package:  libxfce4windowing-4.19.3^git20240317.0a487d7-1.fc41
Old package:  libxfce4windowing-4.19.2^git20231104.1fbbf17-3.fc40
Summary:  Windowing concept abstraction library for X11 and Wayland
RPMs: libxfce4windowing libxfce4windowing-devel
Size: 705.07 KiB
Size change:  26.56 KiB
Changelog:
  * Sun Mar 24 2024 Joshua Strobl  - 
4.19.3^git20240317.0a487d7-1
  - Update to 4.19.3


Package:  lua-dbi-0.7.3-1.fc41
Old package:  lua-dbi-0.7.2-11.fc39
Summary:  Database interface library for Lua
RPMs: lua-dbi lua5.1-dbi
Size: 264.14 KiB
Size change:  885 B
Changelog:
  * Sun Jan 21 2024 Fedora Release Engineering  - 
0.7.2-12
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Thu Jan 25 2024 Fedora Release Engineering  - 
0.7.2-13
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  * Sun Mar 24 2024 Robert Scheck  0.7.3-1
  - Upgrade to 0.7.3 (#2261359, #2269422)


Package:  mingw-adwaita-icon-theme-46.0-1.fc41
Old package:  mingw-adwaita-icon-theme-45.0-3.fc40
Summary:  Adwaita icon theme for MingGW
RPMs: mingw32-adwaita-icon-theme mingw64-adwaita-icon-theme
Size: 4.27 MiB
Size change

Next Open NeuroFedora Meeting: Monday, 25 March 2024 (today) at 13:00 UTC

[Sandro]

Hello everyone,

Please join us at the next Open NeuroFedora team meeting on Monday, 25
March at 13:00 UTC.  The meeting is a public meeting, and open for 
everyone to attend. You can join us over on Matrix in the Fedora Meeting 
channel:


https://matrix.to/#/#meeting:fedoraproject.org

You can use this link to see the local time for the meeting:

https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20240325T13=1440=1

or you can use this command in a terminal:

$ date -d 'Monday, March 25, 2024 13:00 UTC'

The meeting will be chaired by @Penguinpee. The agenda for the
meeting is:

- New introductions and roll call.
- Tasks from last meeting: 
https://meetbot.fedoraproject.org/latest/neurofedora
- Open Pagure tickets: 
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
- Package health check: 
https://packager-dashboard.fedoraproject.org/dashboard?groups=neuro-sig
- Open package reviews check: 
https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro
- CompNeuro lab compose status check for F40: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=30691

- Neuroscience query of the week
- Next meeting day, and chair.
- Open floor.

We hope to see you there!

The meeting announcement is also posted on the NeuroFedora blog here:

https://neuroblog.fedoraproject.org/2024/03/25/next-open-neurofedora-meeting-25-march-1300-utc.html

You can learn more about NeuroFedora here:
https://neuro.fedoraproject.org

Cheers,

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

Re: Orphaned packages looking for new maintainers

[Jens-Ulrik Petersen]

Also botan got orphaned despite the FTI going away
 [1] ;-(
Could it be un-orphaned back?

I really don't need another package, but if no one is willing to pick it
up, I can sit on it to prevent breaking monotone and ikiwiki, and above...

> Depending on: botan (13)

Jens
[1] Seems FTI failed to close the bug fixed on 2024-03-07
--
___
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