https://fedoraproject.org/wiki/Changes/fedora-change-wrangler
= Track Changes in Taiga =
The Motivation for this proposal is to propose using the Taiga
instance at teams.fedoraproject.org for Change processing.
[[User:Bcotton/UsePagureForChanges|Using Pagure]] was previously
proposed for this. The new Change Processing workflow aims to simplify
the process to improve visibility and ease of management.
== Summary ==
The current process allows contributors to propose changes in upcoming
Fedora releases. However, the management of those feature proposals is
cumbersome and requires several manual steps. This introduces more
opportunity for error and reduces the time available to the Change
Wrangler for more valuable contributions to Fedora. In particular, the
current process includes artifacts and discussion in the Fedora Wiki,
on mailing lists, FESCo tickets, Bugzilla tickets, and Docs tickets.
The current process is cumbersome with several manual steps,this
introduces more opportunity for error and reduces the time available
for the Change Wrangler.
A Cli Tool Written in Python that interacts with Taiga,Pagure and
Bugzilla.Functionality includes
Promoting,announcing,submitting,accepting and updating the changes
across the three platforms and over mailing list.
The new process will consolidate much of the information in
Taiga.Proposed Changes will be submitted as an issue in Taiga. The
description of the Issue will include the content with few exceptions:
* System-Wide or Self-Contained change will be indicated by a binary
in the issue metadata
* Fedora release will be indicated by a milestone in the issue metadata
* Change status will be indicated by a list selection in the issue metadata
== Owner ==
* Name: [[User:Pac23| Manas Mangaonkar]]
* Email: manasmangaonkar(a)gmail.com || pac23(a)fedoraproject.org
* Name: [[User:Bcotton | Ben Cotton]]
* Email: bcotton(a)redhat.com
== Detailed Description ==
As Part of GSoC 2019 the fedora-change-wrangler tool will be developed
to smooth out the workflow,reduce Manual Work involved for both the
Contributors and the Change-Wrangler(FPgm). The tool makes it easy by
covering all the functionality required for the process of moving
forward proposals.
The tool will be developed using Python 3.6+ and will interact with
Taiga/Pagure/Bugzilla via their API and the Mailing List via SMTP.
The General Workflow would be :
1. Change Owner opens an issue and fills in the fields. When they are
ready to submit the Change proposal, they set the status to "Ready
for Wrangler".
2. The Change Wrangler (FPgM) reviews the proposal. If it is
incomplete, they set the status back to "New" and inform the Change
Owner of what's needed. If it is ready to process, then...
Functionality covered
1. Promote
* The issue will be promoted to a user story in taiga,copies the
contents of the custom fields from the issue to the user story. Closes
the issue.
2. Announce
* The tool would have the functionality to enable announcing the
change proposal to devel and devel-announce lists using smtp. It will
also automatically change the story status to announced.
3. fesco-submit
* Allowing creation of a new issue in the FESco Pagure repo directly
from the command line.
4. Accept
* Once the changes are accepted the change-wrangler can create a
tracking bug in Bugzilla along with release notes on Pagure.THe status
of the user story is updated to accepted aswell.
5. Update
* Status can be changed to testable if BZ is "Modified" and to
Complete is BZ is "ON_QA"
6. Creation of Report
* The user can create a report to provide quick view of changes and
their status. It can be in wiki or Html form.
Techstack:
* Python3.6+
* SMTP
* Taiga/Pagure/Bugzilla API's
* Nano/Gedit/Vi ( Inbuilt support to edit text)
* Kerberos(For authentication)
The current sample arg created looks like this [ change-tool convert
--taiga <issue no> <issue no> ] . The advantage of this the Manager
would be able to specify unlimited no of issues to change at once in a
single command using the issue no in taiga to convert to user story.
== Benefit to Fedora ==
The proposed change will make the change-process easier for
everyone.Everyone would be able to see them in one place with
status,id filters. The current wiki process can be bit difficult for
formatting,having defined fields would mean easy access without the
cumbersome wiki edits.
Since changes would be submitted in Issue format on
Taiga,pre-submission discussions would be available thus getting
suggestions/feedback at the first stage itself would be easy for
everyone involved.
== Scope ==
* Proposal owners:
I will be working with the Change-Wrangler(Ben Cotton) throughout the
summer to create this tool from scratch.
* Other developers: N/A (not a System Wide Change)
* Release engineering:(no release engineering impact is expected)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No visible Impact is expected.
== Dependencies ==
No other packages depend on this.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
Enough buffer time has been allocated to complete this during the GSoC period.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Qt_Wayland_By_Default_On_Gnome
== Summary ==
Make Qt applications to run natively on Gnome Wayland session, using
the Qt Wayland platform plugin instead of the XCB plugin which is used
for X11/XWayland. Other desktop environments already run natively on
Wayland sessions, only Gnome is excluded by Qt.
== Owner ==
* Name: [[User:jgrulich| Jan Grulich]]
* Email: <jgrulich(a)redhat.com>
* Product: Spins / Workstation
* Responsible WG: Desktop
== Detailed Description ==
Qt Wayland plugin has been available for a long time, but it hasn't
been in condition where it could be enabled by default. With Qt 5.12
the state of the Wayland plugin is much better and it's becoming more
and more reliable. It now supports all the needed protocols and has
been enabled by default for non-Gnome Wayland sessions.
With Qt Wayland on Gnome Wayland session we need to support CSD, it's
actually the only way how decorations are going to work in Qt apps
right now. Qt Wayland implements basic decorations, which really
doesn't match Gnome Adwaita theme, therefore there are new CSD being
implemented as part of QGnomePlatform.
To make Qt applications run natively on Wayland we need to modify Qt
5, specifically '''qt5-qtbase''' module, where we allow the Wayland
plugin to be used also for Gnome sessions. The new decorations from
QGnomePlatform will be used automatically once they are fully
implemented and updated in Fedora.
== Benefit to Fedora ==
Qt applications running with the Wayland plugin run generally faster
and smoother on Wayland enabled sessions like Gnome Wayland and better
support HiDPI displays (respects desktop scale) .
== Scope ==
* Proposal owners:
# Modify Qt 5 (qt5-qtbase) to not exclude Gnome when deciding whether
to use the wayland platform plugin
# Update QGnomePlatform with upcoming upstream release including
window decorations
* Other developers:
# Test and watch for regressions.
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
Run any Qt application on Gnome Wayland session and check any issues
you may see.
== User Experience ==
* Smoother font rendering compared to Qt applications using XCB plugin
* Honor display scale, better user experience on HiDPI and semi-HiDPI desktops.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Switch back default to XCB plugin.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? product No
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Gawk501
** Note that this has already landed in Rawhide:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
== Summary ==
New upstream major version of gawk has been released (4.2.1 -> 5.0.X).
Among many changes, the version 5 introduced a namespaces, which may
possible break some of the existing scripts.
== Owner ==
* Name: [[User:jamartis| Jakub Martisko]]
* Email: jamartis(a)redhat.com
== Detailed Description ==
The new version of gawk has been released. The new version fixes a
number of bugs, some of which were quite significant. Other notable
changes include:
* The regex routines have been replaced with those from GNULIB
* Comment handling in the pretty-printer has been reworked almost
completely from scratch. As a result, comments in many corner cases
that were previously lost are now included in the formatted output.
* Namespaces have been added.
* Gawk now uses the locale settings for ignoring case in single byte
locales, instead of hardwiring in Latin-1.
<s>The introduction of namespaces may break some scripts written for
gawk 4.2.1 due to different variable names.</s> (This is considered to
be a bug by the upstream and there is a patch fixing this)
== Benefit to Fedora ==
See above, the main benefit are several bug fixes.
== Scope ==
* Proposal owners: Update the source archive of the gawk, drop no
longer needed patches.
* Other developers: Some modifications to existing gawk scripts may be
needed. <s>Especially those, using the inplace gawk extension, where
some of the variables have been renamed.</s> (This is considered to be
a bug by the upstream and there is a patch fixing this)
* Release engineering: [https://pagure.io/releng/issue/8489 #8489]
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
see above
== How To Test ==
(not provided)
== User Experience ==
(not provided)
== Dependencies ==
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'gawk'
Judy
Macaulay2
acl
apt
autoconf213
avr-binutils
avr-gcc
clucene
cone
crack
dictd
eterm
geomview
git
glibc
gnome-libs
gnome-menus
gpgme
gpm
gscan2pdf
gyachi
japanese-bitmap-fonts
kde-filesystem
kdelibs3
kernel
kernel-tools
krb5
lapack
libAfterImage
libassuan
libecpg
libgcrypt
libgpg-error
libguestfs
libksba
libpaper
libphidget
libpq
libsvm
libtpms
libvirt
linuxdoc-tools
lm_sensors
lxcfs
maildrop
mingw-clucene
nco
netcdf
nss
ocaml
ocaml-calendar
ocaml-csv
ocaml-curl
ocaml-curses
ocaml-expat
ocaml-extlib
ocaml-findlib
ocaml-libvirt
ocaml-pcre
ocaml-ssl
ocaml-xml-light
paperkey
pcb
postgresql
powermanga
quilt
rbldnsd
rpm
rss-glx
samba
selinux-policy
stow
surfraw
swig
systemd
topgit
tzdata
virt-top
xblast
xdg-utils
xfsdump
xschem
xscreensaver
yara
zsh
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora --enablerepo=updates
--enablerepo=updates-testing --whatrequires 'gawk'
R-core
akmods
am-utils
authselect-libs
autoconf213
autofs
backupninja
calamares
centerim
ceph-selinux
check-checkmk
checksec
cloud-utils
cloud-utils-growpart
condor-vm-gahp
copr-backend
coreos-installer
ctdb
dhcp-client
dkms
docbook-utils
dracut-kiwi-oem-dump
e2fsprogs-devel
esh
execstack
flamegraph-stackcollapse
flamegraph-stackcollapse-perf
gawk-abort
gawk-devel
gawk-doc
gawk-errno
gawk-json
gawk-lmdb
gawk-nl_langinfo
gawk-pgsql
gawk-redis
gawk-select
gawk-xml
gawkextlib
geeqie
git-secret
glimmer
groff
gt5
gtkpod
guilt
hylafax+
initscripts
krb5-libs
latex2rtf
lbdb
lde
libguestfs
libsmi
linuxconsoletools
linuxdoc-tools
lorax
ltunify
m17n-db
neofetch
netconsole-service
netdump-server
network-scripts
nfs-utils
ocaml
opari2
pal
pcp
phpPgAdmin
pkgdiff
policycoreutils
prettyping
quilt
rarian
readonly-root
rear
redhat-lsb-core
redis
resource-agents
rf
rpm-build
rpmdevtools
rust-packaging
screenie
selinux-policy
seqan
seqan2-apps
sofia-sip-devel
spectre-meltdown-checker
surfraw
syslog-ng
systemtap-testsuite
testssl
topgit
translate-shell
tuned
tw
twa
txt2man
unity-gtk-module-common
virt-p2v-maker
virt-v2v
vzctl-core
xfce4-dev-tools
xschem
ypserv
zram
== Contingency Plan ==
* Contingency mechanism: Reverting to gawk 4.2.1 if significant issues
are discovered
* Contingency deadline: Beta freeze (?)
* Blocks release? No
* Blocks product? no
== Documentation ==
* http://git.savannah.gnu.org/cgit/gawk.git/tree/NEWS?h=gawk-5.0-stable
* https://www.gnu.org/software/gawk/manual/
* https://www.gnu.org/software/gawk/manual/gawk.html#Namespaces
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/DNF_Default_Best
== Summary ==
Currently, DNF prefers clean dependency resolution over package updates;
a package (almost) silently won't get updated to a newer version if the new
version has dependency problems. DNF will be changed to prefer updates and fail
if they have dependency resolution issues, while the failure has a
temporal or permanent workaround
hint for users who want to use the older behavior.
== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmracek(a)redhat.com
== Detailed Description ==
Change the built-in default value of the `best` configuration option
from `0` (false) to `1` (true).
As a result, unless `best` is overridden in the `/etc/dnf/dnf.conf`
file or using `--setopt`, it will default to `1`. As a convenience, we
will also put the explicit `best=1` assignment in the shipped
`/etc/dnf/dnf.conf` file for better transparency, and introduce the
new `--nobest` command-line switch.
The purpose of the `--nobest` switch (as a shorthand for
`--setopt=best=0`) is to make it easy for the user to override the
default setting when needed, and it will also be
[https://github.com/rpm-software-management/dnf/pull/1311/commits/9a3e8fd0da…
suggested] in the DNF output when a dependency error occurs.
Relevant excerpt from the updated `dnf.conf(5)`:
<pre>
best boolean
When upgrading a package, always try to install its highest version
available, even only to find out some of its deps are not satisfiable.
Enable this if you want to experience broken dependencies in the
repositories firsthand. The default is True.
</pre>
Relevant excerpt from the updated `dnf(8)`:
<pre>
--nobest
Set best option as false, therefore transactions are not limited to
only best candidates.
</pre>
'''Change in DNF output - missing vim-enhanced-2:8.1.1561-1.fc30'''
Original output. DNF succeed with return code 0:
<pre>
sudo dnf upgrade
Last metadata expiration check: 2:16:40 ago on Mon 24 Jun 2019 04:27:16 PM CEST.
Dependencies resolved.
Problem: package vim-enhanced-2:8.1.1471-1.fc30.x86_64 requires
vim-common = 2:8.1.1471-1.fc30, but none of the providers can be
installed
- cannot install both vim-common-2:8.1.1561-1.fc30.x86_64 and
vim-common-2:8.1.1471-1.fc30.x86_64
- problem with installed package vim-enhanced-2:8.1.1471-1.fc30.x86_64
- cannot install the best update candidate for package
vim-common-2:8.1.1471-1.fc30.x86_64
- package vim-enhanced-2:8.1.1561-1.fc30.x86_64 is excluded
===================================================================================================================================
Package Architecture Version
Repository Size
===================================================================================================================================
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
vim-common x86_64
2:8.1.1561-1.fc30 updates 6.7
M
Transaction Summary
===================================================================================================================================
Skip 1 Package
Nothing to do.
Complete!
</pre>
Output after the change. DNF fails with return code 1, but proposing
`--nobest` option as an option to resolve the issue:
<pre>
sudo dnf upgrade
Last metadata expiration check: 2:16:36 ago on Mon 24 Jun 2019 04:27:16 PM CEST.
Error:
Problem: package vim-enhanced-2:8.1.1471-1.fc30.x86_64 requires
vim-common = 2:8.1.1471-1.fc30, but none of the providers can be
installed
- cannot install both vim-common-2:8.1.1561-1.fc30.x86_64 and
vim-common-2:8.1.1471-1.fc30.x86_64
- problem with installed package vim-enhanced-2:8.1.1471-1.fc30.x86_64
- cannot install the best update candidate for package
vim-common-2:8.1.1471-1.fc30.x86_64
- package vim-enhanced-2:8.1.1561-1.fc30.x86_64 is excluded
(try to add '--allowerasing' to command line to replace conflicting
packages or '--skip-broken' to skip uninstallable packages or
'--nobest' to use not only best candidate packages)
</pre>
'''Q&A'''
Can be a default of the best configuration option overwritten easily
and permanently by user?
Yes, just add `best=false` to `/etc/dnf/dnf.conf`
<pre>
[main]
best=False
</pre>
Can be a default of the best configuration option overwritten easily
from commandline?
Yes, just add `--nobest` to command
<pre>
dnf upgrade --nobest
</pre>
What about PackageKit and Gnome Software?
<pre>
PackageKit and Gnome Software will be not affected by the change. In
case that the same behavior will be desired for PackageKit, It will
require changes in PackageKit code.
</pre>
What about Microdnf?
<pre>
Microdnf will be not affected by the change. There is a plan to unify
functional parity and behavior DNF with Microdnf but not before Fedora
33.
</pre>
== Benefit to Fedora ==
This change allows the users to be properly notified when a package
cannot be upgraded to the latest version, instead of silently ignoring
it as an upgrade candidate.
Right now, when DNF runs in `best=0` mode, if a package cannot be
upgraded due to dependency problems, it is skipped and a warning is
printed in the transaction summary table. However, this poses a risk
of important security fixes being overlooked by the user in case they
are broken for some reason, such as due to a repository
misconfiguration or inconsistency within the metadata itself.
Moreover, since DNF always exits with the return code `0` (success)
when in `best=0` mode, this mode is especially risky in automated
scripts invoking DNF in `assumeyes` mode in which case such
unsuccessful package upgrades could easily go unnoticed unless the
logs are manually examined after the fact.
The new behavior is also more in line with the generally accepted
software development practice of failing early and failing fast.
As a secondary benefit, broken upgrade paths in the Fedora
repositories will hopefully be noticed, reported and therefore fixed
sooner. Although, we would prefer if such problems would be detected
before we ship them to users.
'''Summary of benefits:'''
# No silently passed problems with updates
# Broken dependencies faster disappear from Fedora distribution
# Problems will be reported more often - opportunity to fix issues
# Increase in stability of Fedora distribution
# Less issues after branching
# Identical behavior of DNF in all distributions - Fedora/RHEL/Mageia/OpenSuse
== Scope ==
* Proposal owners:
The change is already part of the upstream (dnf-4.1.0) and reverted in
Fedora downstream. The change was composed by following pull requests:
https://github.com/rpm-software-management/libdnf/pull/678<br>
https://github.com/rpm-software-management/dnf/pull/1311<br>
https://github.com/rpm-software-management/dnf/pull/1316<br>
https://github.com/rpm-software-management/dnf/pull/1319
We would like to stop the reverting the changes.
* Other developers: N/A (not a System Wide Change)
* 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)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
Broken upgrades 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 ==
N/A (not a System Wide Change)
== Contingency Plan ==
If there is a massive negative feedback by the rawhide and pre-beta
users, we can revert the
change at the beta freeze. If there is a massive negative feedback by
the beta users, we can
revert the change at final freeze.
* 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), Yes/No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Python_means_Python3
== Summary ==
In package and command names, "Python" will mean "Python 3".
Users installing and running Python or Python packages without
specifying a version will get Python 3.
Running <code>python</code> will run <code>python3</code>. Running
<code>pytest</code> will run the Python 3 version of pytest, and
similarly for <code>pydoc</code>, <code>pylint</code>, etc.
<code>dnf install python</code> will install {{package|python3}}, and
similarly for other <code>python-*</code> provides, e.g. <code>dnf
install python-requests</code> will install
{{package|python3-requests}}.
This is the final preparation for
[https://fedoraproject.org/wiki/Changes/RetirePython2 the retirement
of Python 2 in Fedora 32] done in line with the
[https://github.com/python/peps/pull/989 soon to be finalized]
upstream recommendations.
== Owner ==
* Name: [[User:Churchyard| Miro Hrončok]]
* Name: [[User:Pviktori| Petr Viktorin]]
* Email: <python-maint(a)redhat.com>
== Detailed Description ==
=== Motivation ===
The final upstream release of Python 2 is planned for January 2020. No
further fixes will be made upstream. Most of Fedora 31's lifetime is
after that date. Python 2 will be maintained only by its Fedora
maintainers.
In preparation for removing Python 2 from Fedora entirely, we will
make the unqualified name "Python" refer to the fully supported
version.
This is in line with upstream changes to
[https://www.python.org/dev/peps/pep-0394/ PEP 394] recommendations.
(At the time of this writing, these changes are still
[https://github.com/python/peps/pull/989 being finalized], but
recommendations for Linux distributions are accepted.)
This completes the work started with Fedora 23's
[https://fedoraproject.org/wiki/Changes/Python_3_as_Default "Python 3
as Default"] change, with only
[https://fedoraproject.org/wiki/Changes/RetirePython2 removing Python
2] left to do.
=== What is being changed ===
The following changes will be made both in the
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
Python packaging guidelines] and the actual packages.
==== Package provides ====
'''Before:''' Packages with Python 2 modules used to provide the
unversioned <code>python-</code> name. Users could do <code>dnf
install python-requests</code> and the {{package|python2-requests}}
package would be installed.
'''After:''' Packages with Python 3 modules will provide the
unversioned <code>python-</code> name. Users can do <code>dnf install
python-requests</code> and the {{package|python3-requests}} package
will be installed.
This applies to the {{package|python3}}/{{package|python2}} package as
well as packages with Python modules. <code>dnf install python</code>
will install {{package|python3}}.
The vast majority of packages will be updated by changing
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_the_pyth…
the %python-provide macro], with no changes in the individual spec
files. The change owners will change the macro before the mass
rebuild.
==== Python command ====
'''Before:''' The <code>/usr/bin/python</code> command was a symbolic
link to <code>/usr/bin/python2</code> living in the
{{package|python-unversioned-command}} subpackage of
{{package|python2}}. {{package|python2}} recommended
{{package|python-unversioned-command}}, so most users got the command
by default when {{package|python2}} was installed.
'''After:''' The <code>/usr/bin/python</code> command will be a
symbolic link to <code>/usr/bin/python3</code> living in the
{{package|python-unversioned-command}} subpackage of
{{package|python3}}. {{package|python3}} will recommend
{{package|python-unversioned-command}}, so most users will get the
command by default when {{package|python3}} is installed (and it is
installed by default).
==== Other commands ====
Similarly, the Python-specific commands will switch from Python 2 to
Python 3. This includes at least the following commands:
* pip
* python-config
* wheel
* idle
* pydoc
* pytest
* nosetest
* pycodestyle
* pylint
* epylint
* pyreverse
* symilar
* unit2
* msgfmt.py
* pygettext.py
* flask
* ipython
* f2py
* ipdb
* easy_install
* ...
This list is incomplete, automation is yet to be created to discover
all such commands.
Note that applications like <code>pygmentize</code> or
<code>cython</code>, whose behavior doesn't depend on the Python
version, are not affected. (By current guidelines, they should be
already using Python 3 if possible.)
=== Changes needed by Python package maintainers ===
This section of the change covers action needed from Python package
maintainers. Most of the packages need no change, but there are
several exceptions.
==== Packages with ambiguous names ====
Tracked at: https://fedora.portingdb.xyz/namingpolicy/
If your package with a Python 2 module or plugin is named with
unversioned <code>python</code> (such as for example
<code>claws-mail-plugins-python</code> or <code>PyQt4</code>), it
needs to be removed or renamed to have <code>python2</code> in the
name (such as, for example, <code>claws-mail-plugins-python2</code> or
<code>python2-PyQt4</code>).
If your package is an application that happens to be written in Python
2 (such as {{package|calibre}}), no renaming is needed (applications
don't need the <code>python-</code>, <code>python2-</code> or
<code>python3-</code> prefix).
==== Packages with ambiguous requires ====
Tracked at: https://fedora.portingdb.xyz/namingpolicy/
If your package depends on (Requires, BuildRequires, Recommends, etc.)
a Python package with unversioned Python name (such as for example:
systemd-python, python-setuptools, PyQt5, pycairo), it will now get
resolved to the Python 3 version. Such dependencies need to be updated
to specific Python 2 or Python 3 names (such as for example:
pythonX-systemd, pythonX-setuptools, pythonX-qt5, pythonX-cairo where
X is either 2 or 3).
==== Packages with ambiguous provides ====
Most of the backwards compatibility <code>python-*</code> provides are
handled by the %python_provide macro and the change owners will change
the macro behavior, so you don't have to worry about those.
However, sometimes manual provides were added. If your package has
some manual backwards compatibility provides for Python 2 packages,
those need to be moved to the Python 3 packages or removed.
For example, before this change, the {{package|python2-m2crypto}}
package provided and obsoleted <code>m2crypto</code>. Instead, the
{{package|python3-m2crypto}} package should do that after this change.
==== Packages with missing %python_provide ====
The <code>%python_provide</code> macro used to do nothing for Python 3
packages. As such, it was often forgotten and only used with the
Python 2 packages.
Packagers of Python 3 packages should make sure to use the
<code>%python_provide</code> macro according to the guidelines:
%package -n python3-%{srcname}
...
%{?python_provide:%python_provide python3-%{srcname}}
==== Packages with Python versioned commands and tools ====
Some packages have two versions of the provided commands. For example,
the {{package|python2-pytest}} package has
<code>/usr/bin/pytest-2</code> and <code>/usr/bin/pytest-2.7</code>,
the {{package|python3-pytest}} package has
<code>/usr/bin/pytest-3</code> and <code>/usr/bin/pytest-3.X</code>.
The unversioned <code>/usr/bin/pytest</code> command used to be a
symbolic link to <code>/usr/bin/pytest-2</code>. Now it needs to be
changed to <code>/usr/bin/pytest-3</code> and moved to the
{{package|python3-pytest}} package.
For some packages, such duplication makes no sense, because the user
sees no difference. For example, there should be just one
<code>/usr/bin/pygmentize</code> -- the user doesn't care if it runs
on Python 3, Python 2 or if it is written in Rust. This is not a new
rule, but if your package is not following it, now is a good time to
make sure the tool uses Python 3.
==== Packages that need unversioned Python to be Python 2 ====
Since Fedora 29, a
[https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_pa…
specific workaround is needed] to use the <code>python</code> command
as Python 2.
This workaround will now bring Python 3.
If that does not work for your package, you'll need to fix it (patch
it) or retire it from Fedora.
If you only need the <code>python</code> command to mean Python 2
during package build, you can do something like this:
mkdir tmp_path
ln -s %{__python2} tmp_path/python
PATH=$(pwd)/tmp_path:$PATH make ...
However, if your package uses the <code>python</code> command during
runtime, this ugly workaround won't work.
== Benefit to Fedora ==
The name "Python" will not refer to software that will be unmaintained
upstream for most of Fedora 31's lifetime and
[https://fedoraproject.org/wiki/Changes/RetirePython2 retired from
Fedora 32].
== Scope ==
* Proposal owners:
** Changes in {{package|python3}}, {{package|python2}} packages:
*** make <code>/usr/bin/python</code> link to
<code>/usr/bin/python3</code> instead of <code>/usr/bin/python2</code>
(+ the same for other executables there)
*** make {{package|python-unversioned-command}} a subpackage of
{{package|python3}} instead of {{package|python2}}
*** make {{package|python3}} (instead of {{package|python2}})
recommend {{package|python-unversioned-command}}
** Changes in other commands:
*** switch pytest, nosetests, ipython, pip... to python3 (see Detailed
Description for the actual list)
** Changes in {{package|python-rpm-macros}}:
*** make <code>%python_provide</code> provide <code>python-foo</code>
for <code>python3-foo</code> instead of for <code>python2-foo</code>
** Let the mass rebuild change the provides based on the
<code>%python_provide</code> change
** Examine the failures and provide help to package maintainers
** File bugs for remaining packages that provide <code>python-x</code>
or <code>x-python</code> for Python 2
* Other developers (Python package maintainers, see Detailed Description):
** Everybody: Make sure that you require and use python2 or python3
packages explicitly
** If your package provides <code>python-*</code> or
<code>*-python</code> for a Python 2 package by other means than the
<code>%python_provide</code> macro, move that to the Python 3 package
(or remove entirely if not applicable)
** Fix or retire your package if it requires the unversioned
<code>python</code> command to be Python 2
* Release engineering: [https://pagure.io/releng/issue/8482 #8482]
* Policies and guidelines:
** Slightly adapt
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_the_pyth…
the %pyton_provide macro] section of the Python packaging guidelines
and the [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/
Python Appendix].
* Trademark approval: not needed
== Upgrade/compatibility impact ==
Custom scripts with <code>python</code> shebangs will invoke Python 3
by default, whereas previosuly they invoked Python 2 by default. See
the User Experience section for details.
== How To Test ==
For your favorite Python 3 package, check that it can be installed
with the ambiguous Python name. For example, check that <code>dnf
install python-pip</code> installs {{package|pyhon3-pip}} instead of
{{package|pyhon2-pip}}.
For your favorite Python command, check that it invokes the Python 3
version. For example, check that <code>python</code> runs Python 3.
== User Experience ==
Users who run <code>python</code> directly will get Python 3.
Users who run <code>pip</code> directly will get pip for Python 3.
Users who run <code>pytest</code> directly will get Python 3 pytest
for Python 3.
...
Scripts with ambiguous Python shebangs (<code>#!/usr/bin/python</code>
or <code>#!/usr/bin/env python</code>) will be executed by Python 3 by
default.
If users need the <code>python</code> command or the
<code>#!/usr/bin/env python</code> shebang to run Python 2, they can
easily do that by:
ln -s /usr/bin/python2 ~/.local/bin/python
Similarly, sysadmins can do that system-wide:
ln -s /usr/bin/python2 /usr/local/bin/python
If users don't want the python command at all, they can <code>dnf
remove python-unversioned-command</code>.
== Dependencies ==
Most packages that provide Python version-specific functionality will
be affected. However, the Change owners include proven packagers and
they maintain python-rpm-macros, so most will not need packager
attention.
We depend on the Fedora mass rebuild to adjust macro-generated package provides.
(Also, the PEP 394 update could be delayed, or even rejected/changed.
Even if that happens, this Change will not be affected: Fedora would
depart from following the upstream recommendations.)
There are currently (2019-06-25)
[https://fedora.portingdb.xyz/namingpolicy/ 90 packages left with
ambiguous Python requires]. Those need to be adapted. Lot of them
unfortunately Fail to Build From Source and will be retired before the
Fedora 31 branching.
== Contingency Plan ==
* Contingency mechanism: revert the changes, mass rebuild packages
with the original <code>%python_provide</code> macro
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
* Updated Packaging guidelines
* This Change page
== Release Notes ==
TBD. Check User Experience section.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Planned Outage - fedoraproject.org/wiki - 2019-06-27 21:00 UTC
There will be an outage starting at 2019-06-27 21:00 UTC ,
which will last approximately 2 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2019-06-27 21:00UTC'
Reason for outage:
We will be updating the nodes running mediawiki to Fedora 30 and thus
also upgrading mediawiki to a newer version. The last scheduled upgrade
was aborted due to some issues found in staging. These issues have been
fixed and we are ready to finally upgrade.
Affected Services:
https://fedoraproject.org/wiki
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/7942
Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
If you have a Change proposal that requires changes to Infrastructure,
those proposals must be submitted (i.e. in ChangeReadyForWrangler
category) today, 26 June.
Other deadlines approaching:
* 2019-07-02 — Changes requiring mass rebuild
* 2019-07-02 — System-Wide changes
* 2019-07-23 — Self-contained changes
For more development milestones in the F31 schedule, see:
https://fedorapeople.org/groups/schedule/f-31/f-31-devel-tasks.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/golang1.13
== Summary ==
Rebase of Golang package to upcoming version 1.13 in Fedora 31,
including rebuild of all dependent packages(pre-release version of Go
will be used for rebuild, if released version will not be available at
the time of the mass rebuild).
== Owner ==
* Name: [[User:Jcajka| Jakub Čajka]]
* Email: jcajka(a)redhat.com
== Detailed Description ==
Rebase of Golang package to upcoming version 1.13 in Fedora 31. Golang
1.13 is schedule to be released in Aug.
Due to current nature and state of Go packages, rebuild of dependent
package will be required to pick up the changes.
With this rebase we will slightly deviate from upstream default
config. By setting GOSUMDB=off and GOPROXY=direct, instead of them set
to the default Google's services(or any other provider). This will
still preserve the ability of users to set the nobs to value of their
liking. By setting this we will prevent unintended (personal)
information leaks. There will be no impact on users of the compiler.
== Benefit to Fedora ==
Staying closely behind upstream by providing latest release of golang,
which includes performance improvements and improvements in support
for currently supported platforms among other bug fixes and new
features. For complete list of changes see upstream change notes at
https://tip.golang.org/doc/go1.13 . In result Fedora will be providing
solid development platform for Go language.
== Scope ==
* Proposal owners: Rebase golang package in f31, help with resolving
possible issues found during package rebuilds.
* Other developers: fix possible issues with help from golang maintainers
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild. https://pagure.io/releng/issue/8481
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
None
== How To Test ==
;0.
:a)Install golang 1.13 from rawhide and use it to build your
application(s)/package(s).
:b)Scratch build against rawhide.
;1.
:Your application/package built using golang 1.13 should work as expected.
== User Experience ==
None
== Dependencies ==
(see wiki page)
Not all of listed require re-build as they might not ship binaries.
== Contingency Plan ==
* Contingency mechanism:Reverting to golang version 1.12.X if
significatnt issues are discovered.
* Contingency deadline: Beta Freeze(?)
* Blocks release? No
* Blocks product? No
== Documentation ==
https://tip.golang.org/doc/go1.13
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Move_test.support_module_to_python3-…
== Summary ==
Move <code>test.support</code> from <code>python3-libs</code> to
<code>python3-test</code> subpackage.
== Owner ==
* Name: [[User:lbalhar| Lumír Balhar]]
* Email: [mailto:lbalhar@redhat.com| lbalhar(a)redhat.com]
== Detailed Description ==
Python test modules should be used only for testing Python itself.
However, some packages have buildtime or runtime dependency on parts
of Python test modules. The aim of this change is to move the most
popular Python test module <code>test.support</code> from
<code>python3-libs</code> to <code>python3-test</code> subpackage
which will help us discover packages which depend on it and also
identify parts of the module which might be useful to move to standard
library.
Also, [https://docs.python.org/3/library/test.html#module-test.support
the Python documentation] says test.support is not a public module.
Other things should not depend on it, and if something is useful
outside the CPython test suite, we should ideally take it out of
test.support.
== Benefit to Fedora ==
The main benefit here is that moving it all to -test is less fragile
and more consistent.
It also helps us understand which parts of Python test suite are
useful and which is worth to move to the standard library.
There were also a few bugs caused by parts of the test module packaged
in different subpackages and by differences between Python 2 and 3 -
[https://bugzilla.redhat.com/show_bug.cgi?id=1651245 RHBZ#1651245],
[https://bugzilla.redhat.com/show_bug.cgi?id=1528899 RHBZ#1528899],
[https://bugzilla.redhat.com/show_bug.cgi?id=596258 RHBZ#596258]
== Scope ==
* Proposal owners:
** Move <code>test.support</code> from <code>python3-libs</code> to
<code>python3-test</code> subpackage.
** Identify as many as possible affected packages and try to fix their
buildtime/runtime issues caused by the change.
* Other developers:
** If a package depends on <code>test.support</code> module which we
move to -test subpackage, change the build/runtime dependencies
definition accordingly.
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Test modules should not be used as a runtime dependency so there is no
impact on an upgrade.
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
The user experience should not be affected.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Changes will be mostly done in Python
specfile and they can be easily reverted in case of some unexpected
issues. The second possibility is to set Provides to temporarily
deactivate the impact of the change.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? No.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Since this affects only a few packages, no release notes are necessary.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis