Fedora 29 Self-Contained Change: Merge Dstat And Performance Co-Pilot
by Ben Cotton
== Summary ==
[http://dag.wiee.rs/home-made/dstat/ Dstat] is a resource statistics
tool for the local host. [https://pcp.io Performance Co-Pilot] is a
system performance analysis toolkit.
This change will merge the existing python2 '''dstat''' utility and
associated ''dstat'' package into the ''pcp-system-tools'' package
where a python3 implementation is provided.
A symbolic link and package replacement rules will streamline the transition.
== Owner ==
* Name: [[User:nathans| Nathan Scott]]
* Email: nathans(a)redhat.com
* Name: [https://src.fedoraproject.org/user/dkaspar David Kaspar]
* Email: dkaspar(a)redhat.com
== Detailed Description ==
The original '''dstat''' utility has reached end of life - it does not
support python3 and there are no plans to update it. It has been
unsupported upstream for some time. However, it is a widely used and
much loved tool. The Performance Co-Pilot (PCP) project has produced
a '''pcp-dstat''' utility which strives for 100% output compatibility
with the original '''dstat'''.
The new '''pcp-dstat''' utility displays metric values and metadata
(e.g. units) by accessing the PCP python APIs. This utility was first
included in PCP version 4.1.0 which is now available in all supported
Fedora versions, in the ''pcp-system-tools'' package. It is invoked
as: 'pcp dstat'.
This proposed change will transition Fedora to provide
''/usr/bin/dstat'' as a symbolic link to the ''pcp-dstat'' script, and
will deprecate the original dstat package which requires python2.
== Benefit to Fedora ==
There are several benefits. First and foremost - the original
motivation - we are able to continue to provide the primary dstat
functionality in a python3-based system.
In addition to providing the same compact, colourful output that the
original dstat provided, the new utility also supports distributed
analysis (monitoring one host from another) using PCP protocol, and
retrospective analysis via Performance Co-Pilot archives.
A configuration file format for plugins has been introduced to
'''pcp-dstat'''(1). This was on the original dstat roadmap for many
years, but not implemented. Because PCP metrics can be accessed by
name, and have strong metadata (including units), a generalised plugin
configuration is possible which allows pcp-dstat to display any
Performance Co-Pilot metric values. All of the original '''dstat'''
"builtin" plugins as well as many of the "extended" plugins are
provided by these configuration files, below the ''/etc/pcp/dstat''
directory.
Customised plugins are encouraged and supported in '''pcp-dstat'''
just as they were in the original '''dstat''', except these are now
configuration files rather than python code.
== Scope ==
* Proposal owners:
The primary goal has been accomplished - providing the python3
pcp-dstat utility. The remaining effort involves ensuring a clean
transition through packaging updates. The pcp-system-tools package
will need to provide a spec file Obsoletes line and symbolic link in
/usr/bin/dstat to complete the transition - this final stage of work
has not yet been done.
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issues #7648]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
On upgrade, a system with ''dstat'' installed will be seamlessly
transitioned to using the ''pcp-system-tools'' package. The command
output format is the same.
The original dstat provided a facility for adding new (python2 code)
'plugins' to provide user-customisable metric reports. This feature
remains, but instead uses the configuration files for providing this
extension. Performance Co-Pilot allows arbitrary metrics to be added
to the framework as well (via PMDAs - Performance Metric Domain
Agents).
The upstream PCP mailing list, books, man pages and tutorials can be
used for anyone wishing to add new metrics, which will then be
automatically available to '''pcp-dstat''' configuration files for
displaying.
== How To Test ==
1. Install pcp-system-tools
2. Verify that ''/usr/bin/dstat'' is now a symbolic link to
'''pcp-dstat''' and that the ''dstat'' package is no longer installed.
3. Run '''dstat''' and compare the output to the original dstat utility.
== User Experience ==
Users of the dstat utility will have an improved analysis experience
using pcp-dstat, as not only is it more easily extended through
configuration files instead of python2 code, it also offers
distributed (remote hosts) and retrospective (historical) analysis
capabilities that the original utility does not provide.
== Dependencies ==
The ''pcp-system-tools'' package depends on ''python3-pcp'', which in
turn depends on ''pcp-libs'' and ''python3''.
== 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)
* Blocks product? No
== Documentation ==
The new version of the utility is documented in the '''pcp-dstat'''(1)
and '''pcp-dstat'''(5) man pages, in the ''pcp-doc'' package.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 9 months
Fedora 29 Self-Contained Change: xfce 4.1
by Ben Cotton
== Summary ==
Xfce desktop environment has utilized GTK-2 up until version 4.12.x
which is currently available in Fedora. Significant work has been
completed to migrate the DE to GTK-3 completely. The obvious benefit
to this migration is the use of a modern and actively maintained
toolkit.
Xfce 4.13 is a development release leading up to the eventual 4.14
stable release, however 4.13 components have proven to be very stable,
provide features users want and the 4.14 release is unscheduled
currently. This change proposal is submitted to sync fedora packages
with latest upstream releases.
== Owners ==
* Name: [[User:nonamedotc| Mukundan Ragavan]]
* Email: nonamedotc(a)fedoraproject.org
* Name: [[User:kevin| Kevin Fenzi]]
* Email: kevin(a)scrye.com
== Detailed Description ==
This change mirgrates Xfce desktop evironment (DE) to latest version
provided by upstream developers. This is a near complete GTK-3
migration of the DE.
== Benefit to Fedora ==
Other GTK-based DEs such as cinnamon and MATE have already migrated to
using GTK-3 libraries. This change proposes to migrate the popular
Xfce DE to the latest GTK-3 based versions upstream developers have
released.
This change would result in fewer packages depending on the older
GTK-2 libraries and move Xfce to using a modern toolkit.
== Scope ==
* Proposal owners:
** Update core xfce packages to 4.13
** Rebuild plugins once core packages are build
* Other developers: N/A (not a System Wide Change)
== User Experience ==
* A fresh install should have fully functional Xfce DE
* Upgrade from Fedora 28 or older should show no visible changes to
the end users.
** GTK-3 applications will be better integrated
No special configuration or hardware needed.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Fedora 29 ships with Xfce 4.13 components. Xfce-4.13 features near
complete GTK-3 migration.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 9 months
F29 Self-Contained Change: Basic FPGA Support
by Ben Cotton
== Summary ==
A number of devices like Xilinx ZYNQ based devices such as the
96boards Ultra96 and the Intel based UP² have onboard FPGAs. FPGA
manager is a vendor-neutral framework that has been upstream in the
kernel since 4.4. This is the initial support for FPGAs in Fedora
using open source vendor agnostic tools.
== Owner ==
* Name: Peter Robinson
* Email: pbrobinson at fedora project dot org
== Detailed Description ==
The use of Artificial Intelligence and Machine Learning is growing.
There's a number types of compute power used to drive this, the
standard system CPU can handle basic work, but for more powerful needs
this workload gets moved to auxiliary processors such as GPGPU, FPGAs
or Neural Network processors. This will add initial support for FPGAs
in Fedora using the Linux Kernel support which currently supports
Altera, Zynq, Lattice and other FPGAs. The use of FPGAs with Open
Source software is improving and this is the beginning of ensuring
that can be consumed in Fedora as easily as possible.
== Benefit to Fedora ==
The general purpose use of FPGAs is growing in the tech industry,
especially in AI and Machine Learning usecases for IoT and numerous
other places where special purpose workload acceleration is needed.
This will help developing these workloads on top of Fedora for use
across the distribution.
== Scope ==
* Proposal owners: Kernel and userspace changes
* Other developers: N/A (not a System Wide Change)
== Upgrade/compatibility impact ==
There is no impact to upgrades or platforms that don't contain FPGAs.
== How To Test ==
Testing will require hardware with a supported FPGA. The initial
devices for this will be a 96boards Ultra96 or a UP² with a Altera
FPGA. Other devices will be supported and testing will be welcome.
The process for testing will be linked to here.
== User Experience ==
Currently the Fedora support for FPGAs is basically non existent.
There's currently a few open tools for specific FPGAs. This is the
beginning of improving this with the intention of having a uniform as
possible user experience across FPGAs as is currently possible.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 9 months
F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default
by Ben Cotton
== Summary ==
This change enables TLS 1.3 (draft28) support on the gnutls crypto library.
== Owner ==
* Name: Nikos Mavrogiannopoulos
== Detailed Description ==
This change will enable the TLS 1.3 protocol (draft28) on the gnutls
library. TLS 1.3 is the latest version of the TLS protocol which
addresses few shortcomings of the previous versions. The protocol has
already been approved by IETF and is on its final publication stage,
with only minor editorial changes expected. The change for gnutls
depending is transparent to existing applications.
More information for applications using gnutls:
* https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html
== Benefit to Fedora ==
* This brings the latest TLS protocol support to applications
depending on gnutls, when crypto policies are updated for TLS1.3.
== Scope ==
* Proposal owners:
* Other developers: N/A (not a System Wide Change)
== Upgrade/compatibility impact ==
That change should have no impact on upgrade or compatibility. The TLS
1.3 protocol is designed in a way that does not cause incompatibility
issues with existing (and even broken) implementations.
== How To Test ==
* Existing work-flows which include secure communications should be tested
* Command line applications which use TLS (e.g., wget, lftp), should
be tested against web-sites using TLS 1.3 (e.g., www.google.com)
== User Experience ==
That change should not be noticeable by users except for applications
which report the connected protocol. Other things users will notice
- Latency on TLS sessions will be reduced
- Performance of establishment of TLS sessions will be improved due
to ed25519/x25519 support
- Privacy of TLS sessions will be improved from the perspective of
passive eavesdroppers; no client certificate will be sent in the clear
- Transparent rekey of long-running sessions
== Dependencies ==
GNOME, samba, rsyslog, wget, lftp, ...
== Contingency Plan ==
If the expected transparent addition of TLS 1.3 cannot be assured
(e.g., important issues are reported), the enablement of TLS1.3
protocol will be postponed for the next fedora release.
* Contingency mechanism: The gnutls maintainer will not enable TLS1.3
by default in the build
* Contingency deadline: Fedora 29 beta
* Blocks release? No; the contingency plan is sufficient and can avoid
a release block
== Documentation ==
* https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html
* https://www.gnutls.org/manual/gnutls.html#Upgrading-from-previous-versions
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 9 months
Man Page Scan
by Maryna Nalbandian
Hi fedora list,
In order to improve usability of packages in Fedora, project Man Page Scan
was created and its task is to provide consistency of man pages (and
documentation in general).
Please take a look at the bug tracker[1] and also please have a look at
the attached! There are 2 files:
-
man-page-day.sh
-
README.md
First file is the script itself and the second one is error/warning
explanation.
There are *841 components* with errors you should take a look (look at the
attached fedora_BZ). We are going to report found errors into Bugzilla[1]..
Should you need any further information, please do not hesitate to contact
us.
Thank you for your attention,
Maryna Nalbandian & David Kutalek
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1600386
--
QE from Base OS Apps
Maryna Nalbandian
5 years, 9 months
Rawhide Rebase Warning to Package Maintainers
by Ben Cotton
Greetings,
This e-mail is intended to inform you about the upcoming Bugzilla changes
happening on 2018-08-14 (Rawhide bug rebase) and what you need to do,
if anything.
We will be automatically changing the version for most rawhide bugs to
Fedora 29.
This will result in regular bugs reported against rawhide during the Fedora 29
development cycle being changed to version ‘29' instead of their current
assignment, ‘rawhide’. This is to align with the branching of Fedora 29 from
rawhide and to more accurately tell where in the lineage of releases the bug was
last reported.
Note that this procedure does not apply to bugs that are open for the ‘Package
Review’ or 'kernel' components or bugs that have the ''FutureFeature''
or ''Tracking'' keywords
set. These will stay open as rawhide bugs indefinitely.
If you do not want your bugs changed to version ‘29‘, add the ''FutureFeature''
keyword. If you need help changing a large amount of bugs manually, we’d be glad
to help.
The process was re-approved by FESCo https://pagure.io/fesco/issue/1096 .
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 9 months
F29 Self Contained Change: Update comps to use Python 3
by Ben Cotton
= Proposed self contained change =
https://fedoraproject.org/wiki/Changes/Update_comps_to_use_python3
* Owner:
churchyard
Change the comps groups python-classroom, engineering-and-scientific,
development-libs, cloud-management, font-design, mysql,
robotics-suite, authoring-and-publishing and electronic-lab to use
python3 packages instead of the python2 ones. Remove python-web group.
== Detailed Description ==
As the whole distro moves towards Python 3 as "the default" and with
the upstream EOL of Python 2 set to 2020-01-01, we want to update
comps to use Python 3 packages instead of Python 2 ones.
Here is the list as of 2017-07-09, note that it might slightly change
as long as changes in comps are done prior to this change happening.
=== python-classroom ===
Remove all python2 packages (except python2-virtualenv as long as it
brings the virtualenv command).
=== python-web ===
Remove this group. It has weird stuff and the motivation for it is long lost.
=== engineering-and-scientific ===
Replace python2-matplotlib, python2-scipy, python2-biopython,
python2-cvxopt, python2-networkx, python2-theano with python3
counterparts.
=== development-libs ===
Replace python-devel with python3-devel. Remove python-ldap and
python-ZODB3 (they have python3 ready variants, but so does plenty of
others, we don't see a point of those being in the group).
=== cloud-management ===
Replace python-boto with python3-boto; python-libcloud with
python3-libcloud; python-openstackclient with python3-openstackclient.
=== font-design ===
Replace python-fontMath with python3-fontMath. Remove retired
python-compositor, python-robofab, python-ufo2fdk.
=== mysql ===
Replace python-mysql with python3-mysql.
=== robotics-suite ===
Replace python-bloom, python-catkin_lint, python-catkin_pkg,
python-catkin_tools, python-rosdep, python-rosdistro,
python-rosinstall, python-rosinstall_generator, python-rospkg,
python-vcstools and python-wstool with their python3- counterparts.
=== authoring-and-publishing ===
Replace python-docutils with python3-docutils and python-manuel with
python3-manuel.
=== electronic-lab ===
Replace python-myhdl with python3-myhdl.
=== Not changed: ansible-node ===
ansible-node will '''stay python2 based''' as explained in
[https://pagure.io/fedora-comps/issue/290
pagure.io/fedora-comps/issue/290]
== Scope ==
* Proposal owners:
Submit a PR to [https://pagure.io/fedora-comps/ fedora-comps] with the
described changes.
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issue/7622 #7622] (no
impact with Release Engineering)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 9 months