Fedora 31 Beta Released
----------------------------------
We're excited to announce the release of Fedora 31 Beta.
A short list of highlights:
* GNOME 3.34 (As part of updates)
* Farewell to bootable i686
* AArch64 Xfce Desktop image
* And more...
For more details about the release, read the full announcement at
* https://fedoramagazine.org/announcing-the-release-of-fedora-31-beta/
or look for the prerelease pages in the download sections at
* https://getfedora.org/
Since this is a Beta release, we expect that you may encounter bugs or
missing features. To report issues encountered during testing, contact the
Fedora QA team via the mailing list or in #fedora-qa on Freenode.
Regards,
Mohan Boddu
Fedora Release Engineering.
Good Morning Everyone,
The Fedora Infrastructure team has been working on making changes to the way
orphaned packages are being adopted as well as the way to set the monitoring
status for the integration with anitya (ie: https://release-monitoring.org)
## Orphan packages
Currently if a package is orphaned there is no way to adopt it easily on
dist-git (https://src.fedoraproject.org) You need to open a ticket on the
releng issue tracker and wait for someone to process that ticket.
This is going to change, new versions of pagure-dist-git and pagure will offer a
button on the left hand side menu offering to adopt orphaned packages.
This is already live in staging, so you can see how it looks there, for example:
https://src.stg.fedoraproject.org/rpms/aasaver (you'll need to be logged in)
Note: if the package is retired, you will still have to go through a releng
ticket as it will need to be unblocked in koji.
## Anitya integration
Currently if you want to tweak the setting for the anitya integration, you need
to open a pull-request on the fedora-scm-requests project at
https://pagure.io/releng/fedora-scm-requests/
That git repo is pretty big and once your pull-request is finally open, you
still have to wait for someone to merge it.
This is also going to change, new versions of pagure and pagure-dist-git offer a
drop-down menu on the left hand side menu to see and adjust the monitoring
status of the project.
This is also live in staging and you can see an example of a project who has set
its monitoring status to "monitoring":
https://src.stg.fedoraproject.org/rpms/0ad
(The status in staging have been imported from the fedora-scm-requests repo)
## Feedback
Feel free to play with this in staging and let us know if there is anything that
isn't working as expected or that you would like to change before we push this
to production (post F31-beta freeze).
Once the new versions of pagure, pagure-dist-git, anitya and the-new-hotness
have been deployed to production we will send another announcement for the
change and work on getting the different documentations updated.
Looking forward to hear from you,
Michal and Pierre
- On behalf of the Fedora Infrastructure team
https://fedoraproject.org/wiki/Changes/MariaDB_10.4
= MariaDB 10.4 =
== Summary ==
Update of MariaDB ('mariadb' package) in Fedora from 10.3 to 10.4 version.
== Owner ==
* Name: [[User:mschorm| Michal Schorm]]
* Email: mschorm(a)redhat.com
== Detailed Description ==
Update of MariaDB package in Fedora from 10.3 version to 10.4 version.
== Benefit to Fedora ==
I'm cooperating with the upstream to bring the latest stable software
to Fedora users.
10.4 series introduces number of enhancements, which cannot be found
in previous series.
Apart from that, MariaDB Galera Cluster has been significantly
reworked and enhanced. (galera 3 updated to galera 4)
== Scope ==
* Proposal owners:
**Prepare MariaDB 10.4 as a module for Rawhide and atleast one stable
Fedora release (done)
**Prepare MariaDB 10.3 as a module for Rawhide, so there would be a
failover in case of problems (done)
**Release MariaDB 10.4 to Rawhide (blocked by #1724283; solving with upstream)
**Check software that requires or depends on 'mariadb' or 'galera'
package for incompatibilities
**Gather user input on the changes between MariaDB 10.3 and 10.4
* Other developers: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The MariaDB client library is compatible, so the shouldn't be any
issues and / or need for rebuild of dependent packages.
Galera package bumped version from 25.3 to 25.4 which introduces
bigger changes. However since no other project in Fedora than MariaDB
use Galera, I don't expect any issue here.
== How To Test ==
Usual testing as when upgrading between major MariaDB versions.
Test that all other software runs well with MariaDB 10.4.
Report any issues, so I can reach the different upstreams and check if
they plan update their software to support MariaDB 10.4 and when.
== User Experience ==
The users will have to upgrade their databases the same way as between
major MariaDB versions.
If the users want to stick with MariaDB for a little longer, I provide
MariaDB 10.3 module.
If the users want to test it beforehand, I provide MariaDB 10.4 module.
== Dependencies ==
There should be absolute minimum amountof packages, that use MariaDB
as a BuildRequires. Since the separation of MariaDB client library,
only packages that build server plugins may use MariaDB as a
BuildRequires.
Since the client library ('mariadb-connector-c') is not changing,
dependent software should work fine.
== Contingency Plan ==
Modules will provide the functional version of MariaDB 10.3, available
to all users.
* Contingency mechanism: Fedora Modules available
* Contingency deadline: beta freeze
== Documentation ==
Upgrade startegy:
https://mariadb.com/kb/en/library/upgrading-from-mariadb-103-to-mariadb-104/
Upgrading and incompatibilities:
https://mariadb.com/kb/en/library/upgrading-from-mariadb-103-to-mariadb-104ā€¦
== Release Notes ==
Release notes for each release:
https://mariadb.com/kb/en/library/release-notes-mariadb-104-series/
Overall overview of the changes and improvements:
https://mariadb.com/kb/en/library/changes-improvements-in-mariadb-104/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Jekyll4
== Summary ==
This Change will bring the latest version of Jekyll, 4.0.0 (or later), to
fedora. It includes minor backwards-incompatible changes, but also brings a lot
of clean-ups and bug fixes compared to the 3.8 branch.
== Owner ==
* Name: [[User:Decathorpe| Fabio Valentini (decathorpe)]]
* Email: decathorpe(a)gmail.com
== Detailed Description ==
I will update the Jekyll static page generator to version 4.0.0 (or later),
which will also include new versions of some Jekyll plugins / components and
other rubygem dependencies.
== Benefit to Fedora ==
The Jekyll stack in fedora 32 will be the latest and greatest.
== Scope ==
* Proposal owners:
** Update existing packages:
*** rubygem-jekyll: 4.0.0
*** rubygem-jekyll-asciidoc: 3.0.0
*** rubygem-jekyll-sass-converter: 2.0.0
*** rubygem-minima: 2.5.1
** Package new dependencies:
*** rubygem-kramdown-parser-gfm
*** rubygem-kramdown-syntax-coderay
*** rubygem-sassc (DONE)
*** rubygem-stringex
It might also be necessary to update other packages as soon as new
versions targeting Jekyll 4 are released (for example, jekyll-feed,
jekyll-seo-tag, jekyll-toc, jekyll-watch gems).
* Other developers:
** Update existing packages not owned by me:
*** rubygem-kramdown: 2.1.0
* Release engineering: N/A
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Jekyll 4 includes some minor backwards-incompatible changes which made new
features possible, as outlined in the
[https://jekyllrb.com/news/2019/08/20/jekyll-4-0-0-released/ upstream
announcement]
and [https://github.com/jekyll/jekyll/blob/v4.0.0/History.markdown
release notes].
Some themes might not yet be compatible with Jekyll 4.0.0+, but the default
theme (minima) will be updated to a compatible version.
== How To Test ==
I've prepared a
[https://copr.fedorainfracloud.org/coprs/decathorpe/jekyll4/ COPR
repository]
with a first draft of all packages that are necessary for upgrading Jekyll to
versions 4.0.0 and later, but the packages are still a "work in progress" and
not necessarily complete yet.
* Update jekyll to version 4.0.0
* Try to create a new jekyll site, try to build an existing site, etc.
== User Experience ==
In general, the new release should be noticably faster than the 3.8 branch of
Jekyll, and brings only minor backwards-incompatible changes that will probably
not affect most users.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: 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? N/A
== Documentation ==
* https://jekyllrb.com/news/2019/08/20/jekyll-4-0-0-released/
* https://github.com/jekyll/jekyll/blob/v4.0.0/History.markdown
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables
== Summary ==
This change will toggle the default firewalld backend from iptables to
nftables. All of firewalld's primitives will use nftables while direct
rules continue to use iptables/ebtables.
== Owner ==
* Name: [[User:erig0| Eric Garver]]
* Email: egarver(a)redhat.com
== Detailed Description ==
Firewalld upstream has used nftables as the default backend for the
past two minor releases. It is also the default in other distributions
(e.g. RHEL-8). This change will bring Fedora in line with upstream.
Using nftables bring many advantages. See firewalld's upstream
[https://firewalld.org/2018/07/nftables-backend blog post]. It also
highlights a few behavioral changes.
== Benefit to Fedora ==
* Fewer firewall rules (rule consolidation)
All of firewalld's primitives will use the same underlying firewall
(nftables) instead of duplicating rules both in iptables and
ip6tables. In nftables rules can match both IPv4 and IPv6 packets.
This reduces the number of firewall rules by half.
* firewalld's rules are namespaced
With nftables firewalld's rules are isolated to a "firewalld" table. A
separate firewall (or user) can create its own independent ruleset and
firewalld will never touch it.
* Netfilter upstream is focusing on nftables, not iptables
== Scope ==
* Proposal owners: firewalld (erig0, Eric Garver)
Currently the firewalld package has a Fedora downstream patch to hide
the nftables backend. The only firewalld change required is to remove
that patch from the package and rebuild.
* Other developers: libvirt, podman, docker
** libvirt
*** libvirt already cooperates with the firewalld nftables backend.
The only thing needed is to test/verify.
** podman
*** libvirt already cooperates with the firewalld nftables backend.
The only thing needed is to test/verify.
** docker
*** Docker currently does not cooperate with the nftables backend. It
currently side-steps firewalld by injecting its own rules in iptables
ahead of firewalld's rules. However, with the nftables backend
firewalld's rule will still be evaluated. Netfilter in the kernel will
call iptables, then nftables for the same packet. This means
firewalld/nftables is likely to drop the packet even if docker has
iptables rules to ACCEPT.
*** Proposed fix 1: Docker package should provide a firewalld zone
definition that includes the docker interfaces (e.g. docker0). The
zone should use the "ACCEPT" policy (firewalld --set-target). This
will allow docker's traffic to pass through firewalld/nftables.
**** Issue 1: If a user has configured a different docker bridge name,
then they'll have to manually add the bridge to the docker zone (or
firewalld's trusted zone).
*** Proposed fix 2: Just like "Proposed fix 1", but instead of adding
the zone definition to docker we created a "docker-firewalld" (or
firewalld-docker?) package that has the zone definition. This could be
installed by default when docker is installed.
* Policies and guidelines: No updated needed.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
When users are upgraded to firewalld with nftables enabled (f32) all
their firewall rules will exist in nftables instead of iptables. All
of firewalld's primitives (zones, services, ports, rich rules, etc.)
are 100% compatible between backends.
Users of direct rules may need to consider the
[https://firewalld.org/2018/07/nftables-backend behavioral changes]
that were announced upstream. Some are also highlighted here:
* direct rules execute before _all_ firewalld rules
** This has been requested by users
* packets dropped in iptables (or direct rules) will never be seen by firewalld
* packets accepted in iptables (or direct rules) are still subject to
firewalld's rules
== How To Test ==
Testing should mostly be integration based. Firewalld upstream has a
fairly comprehensive testsuite that covers functional testing.
The following are packages known to integrate with firewalld. They
should be tested with the nftables backend.
* libvirt
** verify VMs with different network types (bridged, routed) have
working network access
** newer version of libvirt should create and use a "libvirt"
firewalld zone. Interfaces should be dynamically added to the zone.
* podman
** verify podman adds container bridge interface to the "trusted" zone
** verify container still has network access
* docker
** known to not work with the firewalld nftables backend out of the box
** verify new package docker-firewalld installs firewalld docker zone
and has "docker0" interface added
** verify container still has network access
* fail2ban-firewalld
** verify the direct rules added to firewalld by fail2ban still block traffic
== User Experience ==
In general users shouldn't notice the change. Occasional a user will
look at the iptables rule that firewalld generates. They'll now have
to look at nftables instead.
== Dependencies ==
* libvirt >= 5.1.0
* CNI >= 0.8.0 (used by podman)
* docker-firewalld (new package)
== Contingency Plan ==
* Contingency mechanism: firewalld maintainer (erig0) will reinstate
the current patch to default to the iptables backend.
* Contingency deadline: beta freeze
== Documentation ==
* [https://firewalld.org/2018/07/nftables-backend Firewalld blog post]
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
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