https://fedoraproject.org/wiki/Changes/UseNanoByDefault
== Summary ==
Let's make Fedora more approachable, by having a default editor that
doesn't require specialist knowledge to use.
== Owner ==
* Name: [[User:chrismurphy| Chris Murphy]]
* Email: chrismurphy(a)fedoraproject.org
== Detailed Description ==
Users are exposed to the default editor when they use commands that
call it. The main example here is something like <code>git
commit</code>.
Fedora does not currently have a default terminal text editor, because
the $EDITOR environment variable is unset by default. But a common
scenario where users wind up in a terminal text editor is when using
'git commit'. By default, git picks vi. You need to spend time
learning how to use it, for even basic editing tasks. This increases
the barrier to entry for those who are switching to Fedora and don't
know how to use vi. It also makes things hard for those who don't
particularly want to learn how to use vi. (These arguments would apply
just as well if git picked Vim. vi is like hard mode for Vim, with
fewer features, missing syntax highlighting, and no indication of what
mode you are in. Even Vim users may feel lost and bewildered when
using vi.)
In contrast, Nano offers the kind of graphical text editing experience
that people are used to, and therefore doesn't require specialist
knowledge to use. It is already installed across most Fedora Editions
and Spins. This proposal will make Nano the default editor, while
continuing to install <code>vim-minimal</code> (which provides vi, but
not Vim). People will still be able to call <code>vi</code> if they
want to edit a file. It will also obviously be possible to change the
default editor to vi or Vim, for those who want it.
Why make Nano default and vi optional, rather than the other way
round? Because Nano is the option that everyone can use.
== Feedback ==
Pending ...
== Benefit to Fedora ==
* Makes the default editor across all of Fedora more approachable.
* Nano is also mostly self-documenting, by displaying common keyboard
shortcuts on-screen.
* More in line with the default editor of other distributions.
== Scope ==
* Proposal owners:
** Modify comps to include nano Fedora wide.
** Create a new subpackage of <code>nano</code>, called
<code>nano-editor</code>.
** <code>nano-editor</code> to include
<code>/usr/lib/environment.d/10-nano.conf</code>, which sets
<code>$EDITOR</code> to <code>nano</code>.
With this approach, if <code>nano</code> is uninstalled, the
configuration will be removed with it. At the same time, installing
nano on its own won't install the conf.
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/9522 #9522]
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
Will not apply to upgrades.
== How To Test ==
Run <code>export EDITOR="/usr/bin/nano"</code>.
== User Experience ==
Users running <code>git commit</code> will be able to just type their
commit message, rather than having to learn about insert mode, and
they'll be able to cut and paste without having to learn special
shortcuts.
== Dependencies ==
No additional dependencies are required.
== Contingency Plan ==
The contingency plan is to revert the change by removing the
<code>nano-editor</code> package.
* Contingency deadline: probably the beta? It's an easy change to revert.
* Blocks release? If the change breaks the redirection to an editor,
it should block the release. However, this is unlikely.
* Blocks product? Potentially all.
== Documentation ==
As part of this change, it would be good to add instructions for
changing the default editor to the
[https://docs.fedoraproject.org/en-US/quick-docs/ quick docs].
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/BINUTILS235
= Binutils 2.35 =
== Summary ==
Rebase the binutils package from version 2.34 to version 2.35.
== Owner ==
* Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
* Email: nickc(a)redhat.com
== Detailed Description ==
Switch the binutils package from being based on the 2.34 release of
the GNU binutils to
being based on the 2.35 release. This release will bring in numerous
bug fixes, as well
as support for DWARF-5 format line number tables.
== Benefit to Fedora ==
The main benefit will be the bug fixes and the improvement to the
linker and assembler.
== Scope ==
* Proposal owners:
Change the source parameter in the binutils.spec rpm and adjust the
local patches to take account of the bugs that are now already fixed.
This is a significant change to the underlying tools used to build
Fedora and so there should be a mass rebuild in order for the changes
to be noticed across the system.
* Other developers: None
* Release engineering: [https://pagure.io/releng/issue/9539]
A mass rebuild will be required.
* Policies and guidelines: No documents need to be updated.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The binutils are backwards compatible with previous releases, so no
changes should be necessary.
== How To Test ==
The binutils package does include its own set of testsuites which
check basic functionality.
The real test however is by rebuilding other packages which depend
upon the binutils, or
more likely, upon gcc. If these packages continue to work then the
binutils update has not
broken anything.
== User Experience ==
The change should not be noticeable to the user.
== Dependencies ==
This update has no hard dependencies on any other package.
There are other packages that do depend upon the binutils however.
Most notably gcc and redhat-rpm-config.
== Contingency Plan ==
Revert to the 2.34 binutils as currently used in rawhide. This work
can be done by me, should it prove necessary.
* Contingency deadline: Beta freeze.
* Blocks release? No
== Documentation ==
Documentation is not currently available, due to the fact that the
2.35 release has not yet been created.
(It is hoped that the release will happen before the Fedora 34 mass rebuild).
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/PythonExtras
== Summary ==
The Python RPM dependency generator (that generates
<code>python3.Xdist(foo)</code> requirements) will be adapted to also
generate requirements on
[https://www.python.org/dev/peps/pep-0508/#extras Python extras] (e.g.
<code>python3.Xdist(foo[bar])</code>) whenever upstream metadata
indicate such dependency. An easy opt out mechanism will exist. A
supported way of adding metapackages that provide such Python extras
(e.g. <code>python3.Xdist(foo[bar])</code>) will be introduced. Change
owners will add the missing metapackages that would otherwise cause
broken dependencies (in non-modular packages).
== Owner ==
* Name: [[User:Torsava|Tomáš Orsava]]
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: <python-maint(a)redhat.com>
== Detailed Description ==
=== The problem ===
[https://www.python.org/dev/peps/pep-0508/#extras Python extras] are a
way for a Python package (called "distribution" or "distribution
package" upstream) to declare that extra dependencies are required for
additional functionality.
For example Python package <code>requests</code> has several standard
dependencies (e.g. <code>urllib3</code>). But it also declares an
extra named <code>requests[security]</code> which lists additional
dependencies (e.g. <code>pyOpenSSL</code>) if you want to use this
additional functionality. The Python package code handles the missing
optional dependency gracefully -- e.g. it won't crash but might
instruct the user to install <code>requests[security]</code> if needed
by a warning or an actionable error message.
Python packages included in Fedora as RPMs automatically create a
special Provides in the format <code>python3.Xdist(foo)</code> (and
<code>python3dist(foo)</code>) where <code>foo</code> is the upstream
Python package distribution name and X is the Python minor version.
That way you can require any Python package without knowing under
which name it was packaged in Fedora. And these tags are also
automatically used by the Python dependency generator, which reads
upstream Python metadata and creates dependencies on these Provides.
However, Python extras are not yet handled by the Provides tags which
leads to imperfections and problems in declared dependencies.
=== Status quo ===
Currently in Fedora (before this change), no package provides
<code>python3.Xdist(foo[bar])</code> for the <code>foo[bar]</code>
Python extra. As a direct result of this, no package can require it.
The automatic RPM Python dist dependency generator only generates an
incomplete requirement on the base package
(<code>python3.Xdist(foo)</code>) in such cases.
The transitive extra dependencies were often needed to be hardcoded
manually. I.e. when <code>foo</code> requires <code>bar[baz]</code>,
package <code>bar</code> does not require the additional dependencies
for the <code>bar[baz]</code> extra. Thus <code>foo</code> needs to
hardcode those dependencies manually. For example:
[https://src.fedoraproject.org/rpms/poetry/c/97fa3d908]. This leads to
possibly missing, broken and/or outdated superfluous dependencies.
=== Extras metapackages ===
In this change proposal, we propose to solve the problem using
metapackages. The following metapackage represents the
<code>setuptools_scm[toml]</code> extra for the
<code>python3-setuptools_scm</code> RPM package
(<code>python-setuptools_scm</code> source package):
%package -n python3-setuptools_scm+toml
Summary: Metapackage for python3-setuptools_scm: toml extra
Requires: python3-setuptools_scm = %{?epoch:%{epoch}:}%{version}-%{release}
%description -n python3-setuptools_scm+toml
This is a metapackage bringing in toml extra requires for
python3-setuptools_scm.
It contains no code, just makes sure the dependencies are installed.
%files -n python3-setuptools_scm+toml
%ghost %{python3_sitelib}/*.egg-info
Notice several things:
* The package has a hard dependency on <code>python3-setuptools_scm =
%{?epoch:%{epoch}:}%{version}-%{release}</code>. While this could be
in theory generated by the dependency generator, the change owners
have decided not to do that to allow certain leeway for
experimentation. However, the dependency will created by the macro
helper below. Technically, <code>%{?_isa}</code> should also be used
for arched packages, but in practice we believe it can be omitted.
* The package contains no files except the <code>%ghost</code>
metadata. This is needed for the dependency generator to have access
to the upstream metadata of this package.
The [https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/19
updated RPM Python dist dependency generator] parses the extras name
from the subpackage name by splitting it on the <code>+</code> sign.
This naming scheme is not new, it is copied from Rust packaging. Five
Python packages in Fedora already use the same scheme for similar
metapackages representing Python extras. And normalized Python
distribution package names (or extras names) don't naturally contain
the <code>+</code> sign. (Neither do existing Fedora packages prefixed
with <code>python3-</code>, except the 5 components already
mentioned.)
The metapackage can have additional features if desired. For example:
* It can obsolete/provide other names (e.g. obsoleted extras packages)
* It can have manual strong or weak dependencies on other (possibly
non-Python) packages
* It can contain files excluded from the "base" package (if such files
only make sense with the extra and the base package does not fail
without them)
The "base" package (in this case <code>python3-setuptools_scm</code>)
can optionally Require/Recommend/Suggest a Python extras metapackage
if the packager deems it useful.
The change for the RPM Python dist dependency generator is prepared in:
* https://github.com/torsava/rpm/pull/2 (PR for upstream RPM will
follow after this change is discussed in Fedora)
* https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/19
(to be adapted based on feedback and merged in Fedora once the change
is approved)
=== Macro helper ===
For the most common case, the change owners have prepared a macro
helper in https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/59
To generate the example above, it should be used like this:
%{?python_extras_subpkg:%python_extras_subpkg -n
python3-setuptools_scm -i %{python3_sitelib}/*.egg-info toml}
* The <code>%{?python_extras_subpkg:...}</code> way of using this
macro ensures the spec file remains valid for older Fedora/EL
releases, where this code will do nothing.
* The <code>-n</code> option specifies the name of the "base" package.
* The <code>-i</code> option specifies the <code>%files %ghost</code>
path (glob) to the the metadata directory (the <code>.dist-info</code>
or <code>.egg-info</code> directory)
* The one or more positional arguments specify the extra(s) name(s) —
multiple metapackages are generated when multiple names are provided.
Other possible arguments:
* The <code>-f</code> option (conflicts with <code>-i</code> and
<code>-F</code>) can specify the relative path to the filelist for
this metapackage (which should contain the <code>%files %ghost</code>
path (glob) to the the metadata directory). This API is prepared for
integration with <code>pyproject-rpm-macros</code>.
* The <code>-F</code> flag (conflicts with <code>-i</code> and
<code>-f</code>) can be used to skip the <code>%files</code> section
entirely (if the packager wants to construct it manually).
Note that this macro generates all the subpackage definition sections
(<code>%package</code> including the Summary and Requires on the base
package, <code>%description</code> and <code>%files</code>), and hence
it cannot be extended with custom Provides/Obsoletes/Requires/etc.
This macro is designed to fit the most common uses. It doesn't
currently cover all use cases. Packagers can, however, construct the
subpackage manually if they need custom features not covered by
<code>%python_extras_subpkg</code>. In the future, the API of the
macro can be extended if there is demand.
See the [https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/59
linked pull request] for example outputs.
Due to technical limitations, the macro helper never generates
requirement on the arched <code>BASE_PACKAGE%{?_isa} =
%{?epoch:%{epoch}:}%{version}-%{release}</code>. It only adds
<code>Requires: BASE_PACKAGE =
%{?epoch:%{epoch}:}%{version}-%{release}</code>) because a
[https://github.com/rpm-software-management/rpm/issues/689 macro
cannot reliably detect if the subpackage is arched or not]. The change
owners believe the resolver will do the right thing by default. If
there are problems with this approach, an additional flag (such as
<code>-a</code>) can be introduced to indicate an arched base package.
=== Why is there no automatic extras discovery? ===
[http://lists.rpm.org/pipermail/rpm-ecosystem/2020-February/000730.html
RPM is not capable of creating dynamic subpackages] based on the
content in <code>%{buildroot}</code> or on the unpacked sources
(<code>%{_builddir}</code>) yet.
Hence, we require the packager to manually list which Python extras
(if any) should be packaged as metapackages. Not all extras are useful
for us anyway, as there are often extras representing the
build/dev/doc/test dependencies of the project.
In the future (once/if RPM supports this), the generators can be
extended with auto-discovery of Python extras (with filtering).
=== Automatic provides generator ===
To continue with our example, the
<code>python3-setuptools_scm+toml</code> subpackage will Provide
<code>python3.Xdist(setuptools_scm[toml])</code> (and also
<code>python3dist(setuptools_scm[toml])</code>).
An attempt to package a nonexsiting extra (e.g.
<code>python3-setuptools_scm+nopenopenope</code>) will result in build
failure with an human-readable error message.
=== Automatic requires generator ===
If a Python package requires <code>setuptools_scm[toml]</code>, the
Fedora RPM package will require
<code>python3.Xdist(setuptools_scm[toml])</code> and also
<code>python3.Xdist(setuptools_scm)</code>. In theory, the second
requirement is redundant, but in practice, it makes it easier (and
less error prone) to query package dependencies in Fedora (e.g. using
<code>dnf repoquery</code>).
The packaged extras will also Require additional dependencies listed
in their Python metadata, in the case of
<code>python3-setuptools_scm+toml</code>, it will require
<code>python3.Xdist(toml)</code> (because on the Python level,
<code>setuptools_scm[toml]</code> requires <code>toml</code>).
Packagers can opt out from automatically generated dependencies on
Python extras by defining the <code>%_python_no_extras_requires</code>
macro to any value (usually <code>1</code>) in the spec file. This
should be only a a temporary measure until the missing extra is
packaged. If the upstream dependency information is not accurate,
please work with upstream to fix it.
=== Coordinated effort to avoid breakage ===
The change owners have
[https://copr.fedorainfracloud.org/coprs/g/python/python-extras/
collected data about non-modular packages in Copr]. Note that ~270
packages failed to build for unrelated reasons and hence we miss data
for them. However, ~3300 packages built successfully.
The following extras metapackages will be added to avoid broken dependencies:
autobahn[twisted]
cachecontrol[filecache]
cairocffi[xcb]
cli-helpers[styles]
docker[ssh]
fonttools[ufo]
fonttools[unicode]
ipython[notebook]
lunr[languages]
oauthlib[signedtoken]
pyjwt[crypto]
raven[flask]
requests[security]
requests[socks]
tabulate[widechars]
twisted[tls]
vistir[spinner]
The following components will be modified:
python-autobahn
python-CacheControl
python-cairocffi
python-cli-helpers
python-docker
fonttools
ipython
python-lunr
python-oauthlib
python-jwt
python-raven
python-requests
python-tabulate
python-twisted
python-vistir
When we added the metapackages for these extras in our testing Copr,
no new broken requires on Python extras were generated. In other
words, these new extras subpackages don't require adding any more
extras subpackages. No extras are required by the remaining Python 2
packages in Fedora.
Once the change in the dependency generator is deployed in rawhide,
the change owners will monitor all newly added requires on missing
extras and will add new metapackages as needed.
5 source packages in Fedora already have Python extras
meta-subpackages with the proposed naming pattern, but they don't have
any listed <code>%files</code>. They will be non-intrusively adapted
via pull requests — by adding the <code>%ghost</code> file entry to
the metapackage(s). Maintainers can then decide whether to opt for
simpler rawhide only specfile with <code>%python_extras_subpkg</code>
or to maintain the current compatibility. This concerns the following
18 subpackages:
python3-dask+{array,bag,dataframe,delayed}
python3-django-storages+{azure,boto,boto3,dropbox,libcloud,sftp}
python3-dns-lexicon+{easyname,gratisdns,henet,hetzner,plesk,route53}
python3-drf-yasg+validation
python3-prometheus_client+twisted
==== Modular packages ====
The change owners are only cable of monitoring and adapting
non-modular packages. Due to long standing issues, we are unable to
inspect, query (or do a targeted rebuild of) modular content:
* https://pagure.io/modularity/issue/160
* https://pagure.io/modularity/issue/163
* https://pagure.io/modularity/issue/165
If there are people available to help with this problem, the change
owners will gladly accept their help, we are not excluding modular
content because we would like to do it, but because we don't know how
to work with it at scale.
=== How to add Python extras subpackage to my package? ===
In this section, we'll describe a step-by-step guide of adding the
Python extras subpackage to your package. Imagine you maintain
<code>python-requests</code> and a maintainer of a dependent package
contacts you: "I would like you to add a subpackage for
<code>requests[security]</code>, because my package requires it."
# Locate the <code>%files</code> section for
<code>python3-requests</code> package in
<code>python-requests.spec</code>.
# Find the entry for <code>.egg-info</code> or <code>.dist-info</code>
metadata directory. If the entry is generalized with globs like
<code>%{python3_sitelib}/*</code>, please make the <code>%files</code>
section more explicit while at it. Copy the line with the metadata
directory. In this guide we assume it is
<code>%{python3_sitelib}/*.egg-info</code>.
# Locate the <code>%description</code> of the
<code>python3-requests</code> package.
# After the description, add:
<code>%{?python_extras_subpkg:%python_extras_subpkg -n
python3-requests -i %{python3_sitelib}/*.egg-info security}</code> on
a separate line.
# Build the package (e.g. in local mock).
# Verify the <code>python3-requests+security</code> package is build
and provides <code>python3dist(requests[security])</code>.
# See if the new extras package doesn't have dependencies on packages
missing from Fedora (extras or "basic") and proceed with adding those
if needed.
# Ship the change in Fedora 33+. It should do nothing in Fedora 31/32
or current EPELs.
=== Packaging guidelines ===
The change owners will describe this concept in the Python packaging
guidelines and will propose the following rules for the Fedora
Packaging Committee to approve:
* Packagers MAY add Python extras metapackages as needed.
* The Python extras metapackages MUST require the base package (exact NEVR).
* Packagers MAY add strong or weak dependencies on the extras
metapackages from the base package as they see fit.
* Packagers SHOULD NOT add Python extras metapackages with
dependencies only useful for maintaining the package (usually extras
called dev/test/doc/build/...).
** Optional: Packagers MAY package tests separately into the
<code>[test]</code> or <code>[testing]</code> extras subpackage.
* If a Fedora package requires a Python extra of a different package,
the extras metapackage MUST be added to that package to avoid broken
dependencies.
* Packagers MAY temporarily disable the automatic requires on extras
subpackages (by defining <code>%_python_no_extras_requires</code>)
until the missing metapackage is introduced, but they SHOULD notify
the maintainer of the package they depend on about the situation.
* If upstream drops an extra, even though it is discouraged by
upstream documentation
([https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-extra…
see final paragraph]), the metapackage SHOULD be Obsoleted from the
base package or, if there is continuity, from another extras
metapackage.
* If the upstream Python package name contains <code>+</code>, it MUST
be replaced with <code>-</code> in package names (in accordance with
the upstream [https://www.python.org/dev/peps/pep-0503/#normalized-names
Python package names normalization]).
== Feedback ==
This has been briefly discussed in general terms
[https://github.com/rpm-software-management/rpm/issues/1061 upstream].
People tend to agree that some solution is needed. The concrete
proposal contained in this Fedora Change is based on the discussion,
but has received no feedback yet.
More feedback will be documented here once the change proposal is
announced and discussed in Fedora.
== Benefit to Fedora ==
* Packages will have more accurate automatic dependencies, and the
hard-to-maintain and error prone manual transitive (and other)
dependencies can be dropped.
* There will be less missing and redundant dependencies.
* Python packagers will have less manual dependencies to worry about
and less problems to workaround.
* The handling of Python extras will be standardized.
* Overall, the Python ecosystem in Fedora will be closer to upstream.
== Scope ==
* Proposal owners:
** Polish and merge the code changes for
<code>python-rpm-generators</code> and <code>python-rpm-macros</code>
linked above.
** Add the 17 missing extras metapackages listed in this change to
avoid broken dependencies (using pull requests or provenpackager
powers if need be).
** Adapt the 5 existing Python extras subpackages listed in this
change to work with the dependency generator (using pull requests, or
provenpackager powers if need be).
** Monitor new dependencies on Python extras subpackages, add extras
subpackages where needed (using pull requests, or provenpackager
powers if need be).
** Propose the updated Python packaging guidelines to FPC for approval.
** Provide help and guidance for packagers.
** Optional: Prepare <code>pyproject-rpm-macros</code> integration of
this change.
* Other developers:
** No immediate action necessary.
** They can opt in for more metapackages with extras.
** They can review and merge pull requests.
** They should follow the updated Python packaging guidelines if the
changes are approved by FPC.
* Release engineering: No releng impact anticipated. The new
dependencies will be primarily generated by the mass rebuild, but if
the mass rebuild is missed, the package maintainers or change owners
can rebuild the packages that will gain the new automatic Requires is
on Python extras.
* Policies and guidelines: Yes, see detailed description.
* Trademark approval: Not needed for this Change.
== Upgrade/compatibility impact ==
No impact anticipated.
== How To Test ==
Check that there are packages that Require
<code>python3.9dist(basename[extrasname])</code>. You can use the
following repoquery:
dnf repoquery --repo=rawhide --whatrequires 'python3.9dist(*\[*\])'
Check that there are Python extras metapackages with the correct
Provides, for example by installing the packages returned by the above
query, or manually via queries like:
dnf repoquery --repo=rawhide --whatprovides
'python3.9dist(requests\[security\])'
To query all existing Python extras metapackages, you can use:
dnf repoquery --repo=rawhide --provides -a | grep -E
'python(3\.9|2\.7)dist\(\S+\[\S+\]\)'
And lastly, to query all required Python extras metapackages:
dnf repoquery --repo=rawhide --requires -a | grep -E
'python(3\.9|2\.7)dist\(\S+\[\S+\]\)'
== User Experience ==
When installing Python RPM packages, the dependencies are more likely
to fulfill user expectations, as they will more closely adhere to the
behavior of pip (the Python package installer).
== Dependencies ==
Nothing.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
** Soft: The change owners will disable the requirements generator by
default and rebuild (or untag if FTBFS) packages with broken
dependencies caused by the change.
** Hard: The change owners will revert everything and rebuild (or
untag if FTBFS) packages with new requirements/provides caused by the
change.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
The packaging guidelines will be the documentation if approved. If
not, this Fedora Change shall serve as the documentation.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/GLIBC232
== Summary ==
Switch glibc in Fedora 33 to glibc version 2.32.
== Owner ==
* Name: [[User:codonell|Carlos O'Donell]]
* Email: carlos(a)redhat.com
== Detailed Description ==
The GNU C Library version 2.32 will be released at the beginning of
August 2020; we have started closely tracking the glibc 2.32
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 33 will branch after the
glibc 2.32 upstream release. However, the mass rebuild schedule means
Fedora 33 will mass rebuild (if required) after glibc 2.31 upstream
freezes ABI for release, but before the actual release, so careful
attention must be paid to any last minute ABI changes.
== Benefit to Fedora ==
Stays up to date with latest security and bug fixes from glibc upstream.
== Scope ==
* Proposal owners: Update glibc to 2.32.
* Other developers: Developers need to ensure that rawhide is stable
and ready for the Fedora 32 branch. Given that glibc is backwards
compatible and we have been testing the new glibc in rawhide it should
make very little impact when updated, except for the occasional
deprecation warnings and removal of legacy interfaces from public
header files.
* Release engineering: [https://pagure.io/releng/issue/9491 #9491]
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The GNU C Library has its own testsuite, which is run during the
package build and examined by the glibc developers before being
uploaded. This test suite has over 6200 tests that run to verify the
correct operation of the library. In the future may also run the
microbenchmark to look for performance regressions.
== User Experience ==
Users will see improved performance, many bugfixes and improvements to
POSIX compliance, additional locales, etc. The glibc 2.32 NEWS update
will include more details.
== Dependencies ==
All packages do not need to be rebuilt.
== Contingency Plan ==
* Contingency mechanism: Given that Rawhide has started tracking glibc
2.32, no show-stopper problems are expected. At this point, we can
still revert to upstream version 2.31 if insurmountable problems
appear, but to do so may require a mass rebuild to remove new symbols
from the ABI/API.
* Contingency deadline: Upstream ABI freeze deadline of 2020-07-01.
* Blocks release? Yes, upgrading glibc does block the release. We
should not ship without a newer glibc, there will be gcc and language
features that depend on glibc being upgraded. Thus without the upgrade
some features will be disabled or fall back to less optimal
implementations.
== Documentation ==
The glibc manual contains the documentation for the release and
doesn't need any more additional work.
== Release Notes ==
The GNU C Library version 2.32 will be released at the beginning of
August 2020. The current NEWS notes can be seen here as they are
added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Hi,
We'd like to announce public testing of the Packager Dashboard - a new
service for Fedora package maintainers aiming to provide all relevant
data: FTBFS/FTI status (from both Bugzilla, Koschei and health check),
orphan warnings, bugzillas, pull requests, active overrides and
updates - at a single place in an easy to read and filter way.
The Dashboard is now available: https://packager.fedorainfracloud.org/
Packager Dashboard leverages caching in the Oraculum backend to
significantly speed-up loading times with comparison to querying all
the relevant resources separately. We, of course, can't cache the
entire Bugzilla, Pagure, Bodhi... so we only cache data for users who
visit Packager Dashboard at least once per 14 days. Please keep in
mind that the first load for a “new” user might take a while. Most of
the data sources are refreshed every hour.
You can use the Dashboard for individual accounts as well as for FAS groups.
We'd love to hear your feedback. Please keep in mind that this is
testing deployment - it's currently running on a server with very
limited resources and we're aiming for production deployment on
CommuniShift during this summer.
Feel free to provide ideas or bug reports at
https://pagure.io/fedora-qa/packager_dashboard or simply send an email
reply to this thread with all kinds of feedback.
I'd like to mention the other people who made this possible:
- Miro Hrončok (churchyard) - Original idea
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…>
and ideas for data to display
- František Zatloukal - Backend <https://pagure.io/fedora-qa/oraculum>
- Lukáš Brabec - Frontend <https://pagure.io/fedora-qa/packager_dashboard>
Josef
https://fedoraproject.org/wiki/Changes/LLVM-11
== Summary ==
Update all llvm sub-projects in Fedora to version 11.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 11, and there
will be a soname version change for the llvm libraries. Compatibility
packages clang10 and llvm10 will be added to ensure that packages that
currently depend on clang and llvm version 10 libraries will continue to
work.
Also, changing in this update is the compatibility package naming. The .0
will be dropped from the package name, so the compatibility packages will
be called llvm10 and clang10 instead of llvm10.0 and clang10.0.
== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.
== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan any
packages that are no longer used.
** Request a f33-llvm side-tag from Release Engineering.
** Build llvm10 and clang10 into the side-tag.
** When the upstream LLVM project releases version 11.0.0-rc1 (2020-7-15),
package this and build it into the side tag.
** Merge side-tag into rawhide prior to the f33 branch date.
** Continue packaging newer release candidates into rawhide and f33 until
the final release is complete (~2020-8-26)
* Other developers:
** Maintainers of packages that depend on clang-libs or llvm-libs will need
to update their spec files to depend on the clang10 and llvm10
compatibility packages if they want to rebuild their package and it does
not work with LLVM 11 yet. The key point here is that spec file changes
are only needed if a package is going to be rebuilt after LLVM 11 is added
to Fedora. The compatibility packages will ensure that already built
packages continue to work.
* Release engineering: [https://pagure.io/releng/issues/9535]
* Policies and guidelines: No policies or guidelines will need to be
updated as a result of this change.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change should not impact upgradeability.
== How To Test ==
The CI tests for the llvm sub-packages in Fedora will be used to catch
regressions that might be potentially introduced by the update to LLVM 11.
== User Experience ==
Users will benefit from new features and bug-fixes in the latest version of
LLVM.
== Dependencies ==
This change can be made without updating any other packages. However, as
mention before, packages that need to use LLVM 10 will need to update their
spec file on their first rebuild after this change.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) If there are major
problems with LLVM 11, the compatibility package provide a way for other
packages to continue using LLVM 10. In the worst case, we could always
revert LLVM back to LLVM 10, but this would only happen if their were an
unprecedented amount of problems.
* Contingency deadline: Beta Freeze
* Blocks release? No
== Documentation ==
Release notes will be added for this change.
== Release Notes ==
LLVM sub-projects in Fedora have been updated to version 11:
* llvm
* clang
* lld
* lldb
* compiler-rt
* libomp
* llvm-test-suite
* libcxx
* libcxxabi
* python-lit
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro
== Summary ==
This change will update all spec files in Fedora that use make and replace
the make invocations with either the %make_build or %make_install macros.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
The goal of this change is to standardize the usage of make in Fedora. All
make invocations in spec files that don't use the install target will be
modified to use the %make_build macro, and all make invocations that use
the install target will be updated to use the %make_install macro. Any
additional arguments to make that are not included in either the
%make_build and %make_install will be preserved.
The %make_build macro enables parallel make builds using the -j option. In
case a package does not build correctly with parallel make, then parallel
make will be disabled for that package by redefining the %_smp_mflags macro
like this:
%global _smp_mflags -j1
All changes will be submitted to dist-git repositories via pull requests.
Pull requests will be merged after 1 week if there are no objections or
earlier if approved by the package maintainers.
A script will be used to apply the necessary changes to the spec files, and
the result will be manually inspected before being merged.
All packages updated by this change request will be rebuilt after the spec
file changes are merged.
Some packages already use the %make_build and %make_install macros. These
packages will be left unchanged.
== Benefit to Fedora ==
* Reduced build times: Using the %make_build macros enables parallel make
builds which will reduce build times for Fedora packages.
* This will make it easier to enforce consistent build flag usage across
all of Fedora.
== Scope ==
* Proposal owners: Update spec files and submit pull requests and do new
package builds. Optional: Merge pull requests (Proposal Owner would need
to request to be added to provenpackagers group)
* Other developers: Package owners may merge pull requests and submit new
builds if they want, but this is not required for them. A member of the
provenpackagers group will be needed to merge pull requests.
* Release engineering: [https://pagure.io/releng/issues/9533 #9533]
* Policies and guidelines: Package guidelines already specify that packages
should use these macros when possible. Documentation will be updated to
clarify that %make_build should be used for all make invocations (besides
make install), and also with instructions for packages that fail to build
with parallel make.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
No impact.
== How To Test ==
End-users will not notice any changes.
== Dependencies ==
No real dependencies, each package can be updated independently.
== Contingency Plan ==
* Contingency mechanism: None. If not all packages are updated in time,
then the work can continue into the next release.
* Contingency deadline: All work will be done in the rawhide branch, and
will not be backported into the f33 branch once it is created, so whatever
gets done before the branch date will make it into the release.
* Blocks release? No
== Documentation ==
The packaging guidelines will be updated as described in the Scope Section.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Zanata_removal
== Summary ==
While most Fedora project migrated to Weblate, the old translation platform
still exists and needs to be removed (the community shouldn't have to go to
multiple place to contribute, and nobody assume Zanata maintenance).
== Owner ==
* Owner: the [[L10N]] group ({{fpchat|#fedora-i18n}})
* Primary contact: [[User:jibecfed|Jean-Baptiste Holcroft]]
* Email: [
https://lists.fedoraproject.org/archives/list/trans@lists.fedoraproject.org/
localization mailing list]
== Detailed Description ==
<!-- Expand on the summary, if appropriate. A couple sentences suffices to
explain the goal, but the more details you can provide the better. -->
We created a migration page to follow projects migration from Zanata to
Weblate: [[L10N Move to Weblate]].
Remaining projects should either: migrate to Weblate or move to another
translation platform.
== Feedback ==
Weblate configuration: unless your team knows Weblate, Jibecfed will do
first configuration and make you admin of your project so you can add more
components.
Pull request support for Pagure: it is unlikely this features lands in
Weblate before Zanata removal. Suggestion is to allow
https://pagure.io/user/weblatebot for commits.
Some project requiring Sign-off:
https://docs.weblate.org/en/latest/admin/licensing.html#signed-off-by
Reducing translation impact in your repository:
* you can configure weblate's components to save po files without any line
number, saving many useless commits if you do frequent pot updates
* you can configure weblate's components to squash commits per author to
limit the number of commits
== Benefit to Fedora ==
This makes the distribution more efficient:
* translators have one single place for translating, and get many
interesting features (alerts, comments, etc.)
* newcomers can directly translate without approval
* maintainer have less automation to do (po updates, etc.)
* reduce complexity (all in one place) & infrastructure costs
== Scope ==
* Proposal owners: continue to answer questions from upstream projects and
translators
* Other developers:
** if we created a ticket for you, answer it. It may require you to change
your l10n/i18n automation (likely) and git repositories (unlikely).
** if not, open a ticket to l10n team: https://pagure.io/fedora-l10n/tickets
* Release engineering: [https://pagure.io/releng/issue/9537 #9537]
* Policies and guidelines: No
* Trademark approval: No
== Upgrade/compatibility impact ==
This impact upstream projects, not the delivered operating system.
Worse case scenario: less translations reach upstream.
== How To Test ==
Project is in readonly in https://fedora.zanata.org
Project exists in Fedora Weblate: https://translate.fedoraproject.org
Modification done in Fedora Weblate can be seen in upstream repository.
== User Experience ==
This improve the experience of users that don't speak English correctly
(90% of the world, source CLDR + Wikipedia) or not at all (80% of the
world, source CLDR + Wikipedia)
== Dependencies ==
None (this doesn't impact packaging)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) No contingency,
Zanata won't be kept any longer, we already gave 6 more month to let
project migrate at their own pace to the new system
* Contingency deadline: none
* Blocks release? No
== Documentation ==
* [[L10N/Translate_on_Weblate|How to translate on Weblate?]]
* List of Weblate file formats support:
https://docs.weblate.org/en/latest/formats.html
* Weblate's FAQ: https://docs.weblate.org/en/latest/faq.html
* Weblate evolves fast, reading changes is interesting:
https://docs.weblate.org/en/latest/changes.html
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis