It's been six months, and like clockwork, we release Fedora 30 today!
Thank you to the thousands of people who worked to bring this release
together. Fedora doesn't happen by magic: it happens because of you!
Read the official announcement at:
* https://fedoramagazine.org/announcing-fedora-30/
or just go ahead and grab it from:
* https://getfedora.org/
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot
== Summary ==
Create <code>gdb-minimal</code> package (without XML support, Python
support, Syntax Highlight and such) and switch to it in buildroot.
== Owner ==
* Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:sergiodj|Sergio
Durigan Junior]]
* Email: ignatenkobrain(a)fedoraproject.org, sergiodj(a)sergiodj.net
== Detailed Description ==
Create subpackage in <code>gdb</code> source package called
<code>gdb-minimal</code> that will contain 2 files:
* <code>/usr/libexec/gdb-minimal</code> — GDB executable built without
optional unneeded features
* <code>/usr/bin/gdb-add-index</code> — Executable script shared with
gdb-headless package (modified to fallback to gdb-minimal if exists)
debuginfo code in RPM needs just gdb-add-index and that one doesn't
need any syntax highlight or python plugins to work.
As of Apr 26, following packages would disappear from buildroot:
<pre>
boost-regex-1.69.0-6.fc30.x86_64
ctags-5.8-25.fc30.x86_64
gdbm-libs-1:1.18-4.fc30.x86_64
libbabeltrace-1.5.6-2.fc30.x86_64
libicu-63.1-2.fc30.x86_64
libipt-2.0-2.fc30.x86_64
python-pip-wheel-19.0.3-1.fc31.noarch
python-setuptools-wheel-40.8.0-1.fc30.noarch
python3-3.7.3-2.fc31.x86_64
python3-libs-3.7.3-2.fc31.x86_64
python3-pip-19.0.3-1.fc31.noarch
python3-setuptools-40.8.0-1.fc30.noarch
source-highlight-3.1.8-24.fc31.x86_64
sqlite-libs-3.27.2-3.fc31.x86_64
</pre>
== Benefit to Fedora ==
* Python 3 will disappear from buildroot (yes, it was there just because of GDB)
* RPM download size for buildroot preparation will go down from 101M to 85M
* installed buildroot size will go down from 439M to 350M
== Scope ==
* Proposal owners: Create a subpackage in gdb, Add <code>Suggests:
gdb-minimal</code> into rpm-build
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issue/8311 #8311]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== User Experience ==
Python 3 will disappear from buildroot, but nobody should have ever
relied on it since we have guidelines about that for long time:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#buildrequires
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
Release status of Fedora 30 Final is NO-GO.
Due to open blocker bugs and the recentness of RC1, Fedora 30 Final
was declared "No-Go". We will reconvene at 1700 UTC on Friday, 26
April[1] to evaluate the status of RC2. If declared Go, we will
release on the preferred target date of 30 April. If declared No-Go,
we will meet again on Monday, 29 April to target a release date of
Thursday 2 May.
For more information, please see the minutes[2] from the Fedora 30
Final Go/No-Go meeting.
[1] https://apps.fedoraproject.org/calendar/Fedora%20release/2019/4/22/#m9521
[2] https://meetbot.fedoraproject.org/fedora-meeting-1/2019-04-25/f30-final-go_…
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
https://fedoraproject.org/wiki/Changes/Set_skip_if_unavailable_default_to_f…
== Summary ==
Dnf team wants to change a default setting for the repo option
`skip_if_unavailable` to `FALSE`.
== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmracek(a)redhat.com
== Detailed Description ==
Dnf team wants to change a default setting for the repo option
`skip_if_unavailable` to `FALSE`. The option is responsible for
behavior when metadata of a repository is unavailable. When it is set
to false, it will stop on the first unavailable repository with
raising an error. The default behavior could be overwritten by a
configuration of each repository or in dnf by configuration in
/etc/dnf/dnf.conf.
The behavior is not new, because it was used already by YUM, and the
behavior is really essential because all Fedora ropos are already
shipped with `skip_if_unavailable=FALSE`.
The change will be applied in libdnf library, and the changed behavior
will be visible for all direct and indirect users of the library: dnf,
microdnf, PackageKit, ... .
== Benefit to Fedora ==
It should provide a better security because some Important updates
from third-party repositories could be present in temporary
unavailable repository, but user can easily overlook it during `dnf
update` because the issue is reported as a warning.
== Scope ==
* Proposal owners:
** Backport the following upstream pull requests into the DNF stack on
Fedora: https://github.com/rpm-software-management/libdnf/pull/701
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/8307 #8307]
* Policies and guidelines: N/A
* Trademark approval: not needed for this Change
== How To Test ==
Edit .repo file in /etc/yum.repos.d/* and set an url that is not accessible.
Case 1:
No skip_if_unavailable in the repo file, in /etc/dnf/dnf.conf or
overwritten from commandline using `--setopt`.
Any command that requires available repositories like `dnf repoquery`
will fail due to an error `Error: Failed to synchronize cache for repo
'<repo_ID>'`
Case 2:
Set skip_if_unavailable=true in the repo file.
Any command that requires available repositories like `dnf repoquery`
will not fail due to missing metadata of the `<repo_id>`
== User Experience ==
Broken repositories are recognized early, enabling the users to act
upon them by double-checking their repository configuration or filing
bugs, instead of assuming no upgrades are available.
== Dependencies ==
Depend packages - dnf, microdnf, PackageKit
There are no changes on which completion of this change depends.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
The change requires a merge and a release of the pull-request
https://github.com/rpm-software-management/libdnf/pull/701
* Contingency deadline: Should be delivered before 2019-07-24.
* Blocks release? No
* Blocks product? No
== Documentation ==
https://dnf.readthedocs.io/en/latest/conf_ref.html
Update for documentation:
https://github.com/rpm-software-management/dnf/pull/1358
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
https://fedoraproject.org/wiki/Changes/RetirePython2
== Summary ==
The {{package|python2}} package and all its subpackages will be
removed from Fedora 32.
A legacy {{package|python27}} package for developers and users will
be provided.
All packages in Fedora that need Python 2 to run will be removed from
Fedora 32 regardless of their dependencies.
All packages in Fedora that need Python 2 to build will be removed
from Fedora 32 regardless of their dependencies.
Exceptions can be granted by FESCo.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: <mhroncok(a)redhat.com> <python-devel(a)lists.fedoraproject.org>
== Detailed Description ==
Python 2 is unsupported upstream since 2020-01-01. Packages dependent
on Python 2 are being removed from Fedora for several releases
already:
* [[Changes/Mass_Python_2_Package_Removal|Fedora 30 Mass Python 2
Package Removal]]
* [[Changes/F31_Mass_Python_2_Package_Removal|Fedora 31 Mass Python 2
Package Removal]]
Now, the Python maintainers have decided to pull the plug. The
{{package|python2}} package and all its subpackages will be retired
(read: removed) from Fedora 32 (Rawhide) as soon as Fedora 31 is
branched.
All packages depending on any python2 package will be removed. The
removal starts 2 weeks before the planned Fedora 32 Mass Rebuild.
Broken dependencies will not stop the removals.
Packages that Fail to Build From Source and prevent to remove Python 2
subpackages may end up with broken dependencies,
in cases where it is not desired, those packages will be retired instead.
The rules also apply to modules built for Fedora 32+.
The package removal will be executed in an automated fashion.
Removed packages that would block the upgrades to Fedora 32 will be
obsoleted from {{package|fedora-obsolete-packages}}.
=== The python27 package ===
Similarly to existing {{package|python36}}, {{package|python37}} etc.
packages, a {{package|python27}} package will be created.
This package is indented for Python developers who still need to
support the legacy version of Python.
This package is indented for users, who still need to use some
software depending on the legacy version of Python.
This package is not intended for other Fedora packages to be depended upon.
The {{package|python27}} package has several drawbacks compared to the
original {{package|python2}} package:
* it is "flat" - there are no subpackages, everything lives in one package
* there is no debug build (previously available as {{package|python2-debug}})
* there is no <code>/usr/bin/python</code> (note: there might be
already the case before this change)
* any special backwards compatible Provides are removed (this package
is not intended to be depended upon)
=== FESCo exceptions ===
We realize that there are some packages whose removal could seriously
hurt Fedora. FESCo can grant exceptions for packages to use the
{{package|python27}} as a runtime or build dependency.
The package maintainer is responsible to check the entire dependency
chain and they need to request exceptions for the entire list of
packages. For example, when seeking exception for the
{{package|chromium}} package, the request should contain
{{package|python-psutil}} and other dependent packages. (Yes, this is
tedious. Maintaining a Python 2 dependent package is a burden.)
The exception request must include a plan for migrating to Python 3.
Any non-essential dependency must be dropped. That includes optional
dependencies, test dependencies, optional subpackages etc.
Package that fail to get an exception when the removal starts (see
above) will be removed. Their importance for Fedora Release
Engineering, Fedora Infrastructure or any other body will not be
automagically respected; every package that needs Python 2 needs an
exception.
The change owners will send regular reminders to the package owners.
== Benefit to Fedora ==
Python 2 is past upstream End of Life since 2020-01-01. This changes
is generally crafted in a way that:
* it leaves Python developers an option to use it in case they still
need to support it
* it leaves Fedora users an option to use it in case they still need
it to run their (3rd party) software
* it leaves Fedora packagers an option to keep using it (complicated,
but possible)
While:
* it removes Python 2 software from Fedora that was only preserved so
far by inaction
Using Python 2 is dangerous. While the Fedora Python maintainers will
try to fix as many security bugs as possible, without the upstream
involvement this will be hard.
Python 2 is deprecated since Fedora 30. This change moves Python 2
from second class citizen to third class citizen.
== Scope ==
* Proposal owners:
** retire {{package|python2}}
** introduce {{package|python27}}
** remove all {{package|python2}} dependent packages that do not have
FESCo exceptions
** obsolete removed packages that break the upgrade path via
{{package|fedora-obsolete-packages}}
* Other developers:
** remove their {{package|python2}} dependent packages without exceptions
** get exceptions if needed
** fix broken dependencies
* Release engineering: [https://pagure.io/releng/issue/8306 #8306]
easeBlocking/Fedora{{FedoraVersionNumber|next}}|List of
deliverables]]: none
* Policies and guidelines: Python 2 packaging is against the
guidelines since Fedora 30. Python 2 packaging guidelines will be
removed from [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/
Python Appendix] (unless the FPC wants to keep them around until F31
EOL).
* Trademark approval: not needed for this Change
== Upgrade/compatibility impact ==
The majority of removed packages will be obsoleted and removed on upgrade.
Users needing Python 2 libraries will not find these packaged as RPMs.
They may install upstream versions using pip and virtualenv.
== How To Test ==
Try to update Fedora 30 or 31 to 32. No python2 packages should block
the upgrade.
Try to run Python 2 software via the {{package|python27}} package.
== User Experience ==
There will be close to zero Python 2 RPMs in Fedora repos. Users are
encouraged to switch to Python 3 and/or use Python 2 virtual
environments and pip for development.
== Dependencies ==
Ideally, all programs that use python2 would be switched to use
python3. Although we don't expect everything to be switched over, as
much as possible should be, so that the ripped remaining python2 set
is small as possible.
== Contingency Plan ==
* Contingency mechanism:
** In case of serious issues, FESCo can issue a general exception for
packages that would otherwise prevent Fedora 32 from being composed.
** If someone steps up to maintain Python 2 (including the full
ecosystem of packages now in Fedora), they can decide to discontinue
removing packages, revert this Change, or come up with another plan.
(Note that in this case, current maintainers will most likely orphan
many fundamental python2 packages.)
* Contingency deadline: Fedora 32 Beta
* Blocks release? in theory it should not, in practice, it may break
the release and hence it will block it until fixed
* Blocks product? all of them?
== Documentation ==
This page should serve as the documentation.
== Release Notes ==
TBD.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
Dear all,
Join us on irc.freenode.net in #fedora-meeting-1 for the Fedora 30
Release Readiness meeting. This meeting will be held on Thursday,
2018-04-25 at 19:00 UTC.
We will meet to make sure we are coordinated and ready for the release
of Fedora 30. Please note that this meeting will be held even if the
release is delayed at the Go/No-Go meeting on the same day two hours
earlier.
You may receive this message several times in order to open this
meeting to the teams and to raise awareness, so hopefully more team
representatives will come to this meeting. This meeting works best
when we have representatives from all of the teams.
For more information, see
https://fedoraproject.org/wiki/Release_Readiness_Meetings.
View the meeting on Fedocal:
https://apps.fedoraproject.org/calendar/meeting/9514/?from_date=2019-04-22
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
Greetings,
In the past, src.fedoraproject.org git repositories have been accessable
via the pagure[1] interface or via the cgit web interface.
We have been planning some changes to the way the backend git
repositories are stored on src.fedoraproject.org: from local bare repos
to repoSpanner[2] clustered and distributed repositories. This will
allow multiple frontends for that data, including sharing them with
git.centos.org.
This change however meant that cgit could no longer have access to
the bare git repositories and thus would no longer work. Please
adjust any workflows you may have that use cgit to use the
main pagure interface.
Thanks,
[1] https://pagure.io/pagure
[2] https://github.com/repoSpanner