F30 Self-Contained Change proposal: Retire YUM 3
by Ben Cotton
(Note this change was previously submitted for Fedora 29:
https://pagure.io/fesco/issue/2064)
https://fedoraproject.org/wiki/Changes/Retire_YUM_3
== Summary ==
Remove yum (v3) and all related packages from Fedora.
== Owner ==
* Name: [[User:mdomonko|Michal Domonkos]]
* Email: mdomonko(a)redhat.com
== Detailed Description ==
Remove packages from the distribution:
* createrepo
* yum
* yum-langpacks
* yum-utils
* yum-metadata-parser
* yum-updatesd
* python-urlgrabber
All these packages should no longer be used and all software using
them should be migrated to DNF.
Compatibility:
* Important packages such as yum, createrepo or yum-utils will be
provided/obsoleted by relevant packages from the dnf stack
* Important executables such yum, repoquery, createrepo, etc. will be
provided either as new executables or via symlinks
== Benefit to Fedora ==
Drop an old package manager that has no active upstream development.
Move existing users to DNF which that has active development.
Secondary benefit is reducing number of packages in Fedora that still
depend on Python 2.
== Scope ==
* Proposal owners: Remove packages from the distribution: createrepo,
yum, yum-langpacks, yum-utils, yum-metadata-parser, yum-updatesd,
python-urlgrabber
* Other developers: Either remove packages from the distribution or
switch them to DNF
* Release engineering: [https://pagure.io/releng/issue/7588 #7588]
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Any tool based on YUM 3 Python API will stop working. This applies on
any 3rd party software which won't be changed in Fedora as part of
this change.
CLI compatibility will be provided by DNF.
== How To Test ==
Repoclosure passes after dropping the packages.
== User Experience ==
There shouldn't be any impact on YUM users because the functionality
is provided by DNF already.
Users of tools listed in the Dependencies section shouldn't see any
difference if the migration to DNF is done properly.
== Dependencies ==
The list of source packages (SRPMs) that still depend on some of the
yum-related packages to be removed:
(see wiki page)
== Contingency Plan ==
* Contingency mechanism: Do not remove the packages in the current release.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
N/A
== Release Notes ==
Inform end-users about removing the YUM 3 stack and definitive migration to DNF.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years
libravatar is in fedorainfracloud!
by Michal Novotny
Hello!
maybe you know that around April 2018, there was an announcement that
libravatar service (a service for serving user avatars) is shutting
down: https://blog.libravatar.org/posts/Libravatar.org_is_shutting_down_on_2018...
This raised a big wave of interest in the service and in keeping it
alive because libravatar was here for quite a long time and used by
many parties including Pagure, Mozilla Firefox, or Linux kernel. A
group of people formed with the goal to port libravatar to a new
platform and new servers and
https://blog.libravatar.org/posts/Libravatar.org_is_not_going_away/
was published. Then the work on saving libravatar had begun...
And now, it is finally done! Yesterday at 17pm UTC, Francois Marier
flipped the DNS switch to point www.libravatar.org to the new server
and completely new, modern implementation placed in our Fedora cloud!
\o/ Check it out here: www.libravatar.org
I think it's quite a nice message of how well people in Open Source
and Free Software can cooperate and how they can make something
significant happen. I would like to say thank you to them and in
particular to:
Oliver Falk who rewrote libravatar from scratch
(https://git.linux-kernel.at/oliver/ivatar)
Francois Marier who wrote and maintained the original libravatar and
who was helping us all the time with the migration
Tristan Le Guern who was testing the new implementation and provided
great insights
Niklas Poslovski who themed new libravatar
Lars Kruse who lead our IRC meetings and setup our @libravatar.org
email addresses
Me who setup the new servers in Fedora Infra Cloud and did some
testing of the new implementation too
I would also like to thank the Fedora community and the Infra team for
providing us with the space in the cloud for the new service.
So yeah, if your avatars are not served properly, you know whom to
blame :). You can get in touch with us on #libravatar Freenode
channel. Through https://git.linux-kernel.at/oliver/ivatar bugtracker
or by writing to libravatar-fans(a)lists.launchpad.net mailing list.
Enjoy
clime
5 years
F29 System Wide Change: OpenLDAP without Non-threaded Libraries
by Jan Kurik
= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries =
https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
Owner(s):
* Matus Honek <mhonek at redhat dot com>
OpenLDAP will not ship non-threaded version of libldap. Instead,
libldap will be built with the same threading support as libldap_r.
== Detailed description ==
After this change the non-threaded version of libldap will not be
shipped any more. Instead, this library will rather be built the same
way as the threaded libldap_r. This has been previously discussed in
Bugzilla [https://bugzilla.redhat.com/show_bug.cgi?id=1370065] and
other distributions where this change already happened. Upstream still
supports non-threaded version of their library as it might be used on
processors where threads are not supported. However, when these two
versions happen to be loaded at the same time (as discussed about Curl
in the Bugzilla) symbol names overlap which may result in
unpredictable behaviour. Immediate solution would be to symlink
libldap to libldap_r, however SONAME of the library would be the same,
hence breaking dependencies of other packages. For that reason the
solution hereby proposed should be the most convenient one.
== Scope ==
* Proposal owners:
update SPEC file so that non-threaded libldap is replaced with threaded one.
* Other developers:
None. Issues should not occur.
* Release engineering:
[https://pagure.io/releng/issue/7253]
** List of deliverables:
N/A
* Policies and guidelines:
None.
* Trademark approval:
(not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
5 years
Broken modules on rawhide
by Miroslav Suchý
From:
https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2
When you try to run:
mock -r fedora-rawhide-x86_64 shell
You will get:
Problem 1: conflicting requests
- nothing provides module(platform:f30) needed by module stratis:1:20181215204600:a5b0195c-0.x86_64
Problem 2: conflicting requests
- nothing provides module(platform:f30) needed by module standard-test-roles:3.0:3020190214144451:a5b0195c-0.x86_64
....
rawhide has module_id=platform:f31.
When will be all rawhide modules rebuild? Or what is the solution for this? Because right now all rawhide modules are
basically broken. And because Mock started using modular fedora repos, then all Mock attempts for rawhides builds are
broken too.
Miroslav
5 years
Promoting qpid-proton to stable
by Irina Boverman
There is an issue with qpid-proton-0.26.0-1.fc28. It should be in
"stable", but it was blocked. This is creating a problem with qpid packages
in F28. Can someone advise or assist in moving this package to "stable"
ASAP?
--
Regards, Irina.
5 years