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/Switch_RPMs_to_zstd_compression
= Switch RPMs to zstd compression =
== Summary ==
Binary RPMs are currently compressed with xz level 2.
Switching to zstd would increase decompression speed significantly.
== Owner ==
* Name: [[User:dmach| Daniel Mach]]
* Email: dmach(a)redhat.com
== Detailed Description ==
* The change requires setting a new compression algorithm in rpm
macros. Then a mass rebuild of all packages is required.
* The macro for setting the compression is: %define _binary_payload w19.zstdio
* The recommended compression level is 19. The builds will take
longer, but the additional compression time is negligible in the total
build time and it pays off in better compression ratio than xz lvl2
has.
* SRPM payload compression should stay at gzip (there's almost no
benefit in changing the compression, because SRPM's contents is
compressed already)
=== Use case: Firefox installation ===
I rebuilt firefox-66.0.5-1.fc30 with zstd level19.
Then I compared installation times with the original (xz compressed) package:
{| class="wikitable"
|-
! Compression !! Target File System !! Time
|-
| xz level 2 || tmpfs || 8s
|-
| xz level 2 || ext4 on nvme || 11s
|-
| zstd level 19 || tmpfs || 2s
|-
| zstd level 19 || ext4 on nvme || 4s
|-
|}
=== Comparison of compression algorithms and levels ===
Following table shows '''cpio''' and '''compressed cpio''' extraction
times into a tmpfs. Actual times in decompressing RPMs will differ due
to extracting on an actual disk and also some overhead in the RPM tool
(checks, scriptlets).
{| class="wikitable"
|-
! Compression !! Level !! Size B !! Size GiB
!! Compression time !! Compression time, 4 threads !!
Decompression time !! Comment
|-
| CPIO || - || 5016785692 || 4,7
|| - || - || -
||
|-
| xz || 2 || 1615017616 || 1,6
|| 9m55s || - || 1m36s
|| slow decompression
|-
| pxz || 2 || 1631869880 || 1,6
|| - || 6m11s || 1m38s
|| slow decompression
|-
| gzip || 9 || 2086354992 || 2,0
|| 10m23s || - || 31s
|| insufficient compression ratio
|-
| bzip2 || 9 || 1889161565 || 1,8
|| 8m || - || 2m50s
|| very slow decompression; compression ratio could be
better
|-
| zstd || 3 || 1913536587 || 1,8
|| 31s || 29s || 6,5s
||
|-
| zstd || 10 || 1737928978 || 1,7
|| 3m27s || 2m34s || 6,3s
||
|-
| zstd || 15 || 1717303256 || 1,7
|| 9m37s || 6m34s || 6,3s
|| identical compression speed to xz; fast decompression;
slightly worse compression ratio than xz
|-
| zstd || 17 || 1635525492 || 1,6
|| 16m16s || 11m20s || 6,7s
||
|-
| zstd || 19 || 1575843696 || 1,5
|| 24m2s || 18m55s || 7,7s
||
|-
|}
== Benefit to Fedora ==
* Faster installations/upgrades of user systems
* Faster koji builds (installations in build roots)
* Faster container builds
* Lower bandwidth on mirrors if we choose the highest compression level
== Scope ==
* Proposal owners: submit a patch to redhat-rpm-config
* Other developers: redhat-rpm-config maintainer: include the patch
and make a new build
* Release engineering: [https://pagure.io/releng/issue/8345 #8345]
mass rebuild is needed
== Upgrade/compatibility impact ==
* RPM in Fedora supports zstd compression already (from Fedora 28,
rpm-4.14.0-0.rc2.5.fc28). No impact on Fedora users is expected.
* Fedora <= 27 and some other distros will not be able to decompress
zstd-compressed RPMs.
== How To Test ==
* dnf install <package>
* rpm -q --qf "%{PAYLOADCOMPRESSOR} %{PAYLOADFLAGS}\n" <package>
* expected output: zstd 19
Also the overall system installation time should decrease significantly.
== User Experience ==
See '''Benefit to Fedora'''
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Not needed, Fedora will stay at current compression.
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? N/A
== Documentation ==
N/A
== Release Notes ==
RPMs have switched to zstd compression level 19.
Users will benefit from faster package decompression.
Users that build their packages will experience slightly longer build times.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
As of the 28th of May 2019, Fedora 28 has reached its end of life
for updates and support. No further updates, including security
updates, will be available for Fedora 28. Fedora 29 will continue to receive
updates until approximately one month after the release of Fedora 31.
The maintenance schedule of Fedora releases is documented on the
Fedora Project wiki [0]. The Fedora Project wiki also contains
instructions [1] on how to upgrade from a previous release of Fedora
to a version receiving updates.
Regards,
Mohan Boddu.
[0]
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedu…
[1]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades
https://fedoraproject.org/wiki/Changes/Nodejs12x
== Summary ==
The latest release of Node.js to carry a 30-month lifecycle is the
12.x series. As with 10.x and 8.x before it, Fedora 31 will carry 12.x
as the default Node.js interpreter for the system. The 10.x
interpreter will remain available as a non-default module stream.
== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgallagh(a)fedoraproject.org
* Responsible SIG: Node.js SIG
== Detailed Description ==
Fedora 31 will ship with the latest LTS version of Node.js by default.
This will either be the `nodejs:12` module stream or else replicated
to the non-modular repository, depending on the status of other
release engineering work around supporting modular content in the
non-modular buildroots. To end-users, the experience should be
identical: `dnf install nodejs` will give them `nodejs-12.x` and the
matching `npm` package.
== Benefit to Fedora ==
Node.js is a popular server-side JavaScript engine. Keeping Fedora on
the latest release allows us to continue tracking the state-of-the-art
in that space. For those whose applications do not yet work with the
12.x release, Fedora 31 will also have the 10.x release available as a
selectable module stream.
== Scope ==
* Proposal owners:
The packages are already built for Fedora 31 in a non-default module
stream. On June 14th, 2019, the nodejs-12.x packages will become the
default in Fedora 31 (either by making the 12.x module stream be the
default stream or by rebuilding the packages as non-modular ,
depending on other factors).
If the non-modular buildroot work is finished and available by July
17th (a week before the mass-rebuild), Node.js 12.x will drop the
non-modular packages and make the 12.x stream the default.
* Other developers:
Any developer with a package that depends on Node.js at run-time or
build-time should test with the 12.x module stream enabled as soon as
possible. Issues should be reported to nodejs(a)lists.fedoraproject.org
* Release engineering: [https://pagure.io/releng/issue/8388 #8388]
Release engineering and FESCo will need to approve the change to the
default module stream.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
As with previous releases, users running Fedora 29 or Fedora 30 with
the non-modular nodejs-10.x packages will be automatically upgraded to
the 12.x packages, which may cause issues. If users are running
software known not to support Node.js 12.x yet, they can switch the
system back to using 10.x with yum commands (to be documented in
release notes).
== How To Test ==
* Confirm that `yum install nodejs` results in Node.js 12.x being installed.
* Confirm that upgrading from Fedora 29 or Fedora 30 with nodejs-10.x
installed (non-modular) results in an upgrade to nodejs-12.x
* Confirm that upgrading from Fedora 29 or Fedora 30 with the
`nodejs:10` module enabled does *not* result in an upgrade to 12.x and
still has `nodejs:10` enabled on Fedora 31.
* Confirm that upgrading from Fedora 29 or Fedora 30 with the
`nodejs:12` module enabled upgrades successfully and still has
`nodejs:12` enabled on Fedora 31.
== User Experience ==
Users will have the 12.x release of Node.js available by default. See
the "Upgrade/compatibility impact" section for specific details.
== Dependencies ==
All packages prefixed with `nodejs-` depend on this package. They will
need to be updated or removed from Fedora 31 if they do not work with
Node.js 12.x.
== Contingency Plan ==
* Contingency mechanism:
Revert to Node.js 10.x as the default stream. This may require bumping
epoch or making the `nodejs:10` stream the default, depending on the
status of the modules-in-non-modular-buildroot work at the time.
* Contingency deadline: August 5th, 2019
* Blocks release? No
== Documentation ==
* https://nodejs.org/dist/latest-v12.x/docs/api/
* https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V12.md
== Release Notes ==
Fedora 31 now ships with Node.js 12.x as the default Node.js
JavaScript server-side engine. If your applications are not yet ready
for this newer version, you can revert to the 10.x series by running
the following commands
<pre>
dnf remove nodejs
dnf module reset nodejs
dnf module install nodejs:10
</pre>
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/RPM-4.15
== Summary ==
Update RPM to the 4.15.0 release.
== Owner ==
* Name: User:pmatilai, User:ffesti
* Email: pmatilai@redhat.com,ffesti@redhat.com
== Detailed Description ==
RPM 4.15 contains numerous improvements over previous versions
* Faster builds due to increased parallelism
* Dynamic build dependency generator (planned)
* Caret version operator (the opposite of tilde)
* String data is returned as surrogate-escaped utf-8 in Python 3 bindings
* %patchlist and %sourcelist spec sections for minimal boilerplate
patch and source declarations
* Experimental chroot operations for non-root users
* Many error and warning report improvements
* A new plugin for issuing audit log events on package install/update/erase
* Native support for Lua 5.2-5.3 without compat defines in Lua
* Numerous other improvements and bugfixes: https://rpm.org/wiki/Releases/4.15.0
Rawhide rpm will be updated to 4.15 alpha once released and updated through
beta and rc cycles, 5.15.0 final release is expected prior to F31 final freeze.
== Benefit to Fedora ==
See above.
== Scope ==
* Proposal owners:
** Rebase RPM
** help Python binding users adjust to the string change
** help coordinate for macro + helper script removals
* Other developers:
** Test new release, report issues and bugs.
** Fix Python 3 string/bytes usages in API users
(https://bugzilla.redhat.com/show_bug.cgi?id=1693751 already in
progress in rawhide)
* Release engineering: [https://pagure.io/releng/issue/8380 #8380]
* Policies and guidelines:
As always, utilizing new rpm features is subject to packaging guidelines,
but the time for this is after the new version has properly landed.
There is no need to change guidelines, any new features are optional.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
* Python 3 bindings see a dramatic change as all string data is now
returned as utf-8 encoded string instead of bytes, but this is already
being test-driven in rawhide and at least anaconda, dnf and mock are
already compatible:
https://bugzilla.redhat.com/show_bug.cgi?id=1631292
* Similar to compiler updates, some previously working specs might
fail to build due to stricter error checking and the like.
* Some long-standing perl and python macros and helpers have been
removed from rpm and might need either changes to packages or
redhat-rpm-config
== How To Test ==
Rpm receives a thorough and constant testing via every single package
build, system installs and updates. New features can be tested
specifically as per their documentation.
== User Experience ==
There are no significant user experience changes, but some more minor
ones include:
* faster package builds on SMP systems
* improved diagnostics from macro errors/warnings and spec constrcuts
== Dependencies ==
* There is a soname bump involved so all API-dependent packages will
need a rebuild.
* The Python 3 string change has impact on several packages but this
is already in process
== Contingency Plan ==
* Contingency mechanism: Roll back to rpm 4.14, but under no
circumstances should such a thing be necessary.
* Contingency deadline: Beta freeze.
* Blocks release? No
== Documentation ==
Draft release notes available at https://rpm.org/wiki/Releases/4.15.0
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
There will be an outage starting at 2019-05-22 21:00 UTC ,
which will last approximately 5 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2019-05-22 21:00UTC'
Reason for outage:
There have been a number of kernel and low level library updates which
require a system reboot to put into place. We will be rebooting
productions servers which do require a full outage and downtime.
Affected Services:
koji.fedoraproject.orgsrc.fedoraproject.org
*.phx2.fedoraproject.org
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/7810
Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
--
Stephen J Smoogen.
There will be an outage starting at 2019-05-21 21:00 UTC,
which will last approximately 4 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2019-05-21 21:00UTC'
Reason for outage:
We have come to chew gum and reboot servers, and we have all run out of gum.
There have been a number of kernel and low level library updates which
require a system reboot to put into place. We will be rebooting staging and
non-PHX2 servers which do not require a full outage due to redundancy or
low service level expectations.
Affected Services:
proxy05.fedoraproject.org
coloamer01.fedoraproject.org:proxy08.fedoraproject.org:running:1
dedicatedsolutions01.fedoraproject.org:proxy11.fedoraproject.org:running:1
ibiblio01.fedoraproject.org:download-ib01.fedoraproject.org:running:1
ibiblio01.fedoraproject.org:noc02.fedoraproject.org:running:1
ibiblio01.fedoraproject.org:pagure-proxy01.fedoraproject.org:running:1
ibiblio01.fedoraproject.org:proxy04.fedoraproject.org:running:1
ibiblio05.fedoraproject.org:ns02.fedoraproject.org:running:1
ibiblio05.fedoraproject.org:people02.fedoraproject.org:running:1
ibiblio05.fedoraproject.org:proxy12.fedoraproject.org:running:1
ibiblio05.fedoraproject.org:smtp-mm-ib01.fedoraproject.org:running:1
ibiblio05.fedoraproject.org:torrent02.fedoraproject.org:running:1
ibiblio05.fedoraproject.org:unbound-ib01.fedoraproject.org:running:1
internetx01.fedoraproject.org:ns05.fedoraproject.org:running:1
internetx01.fedoraproject.org:proxy02.fedoraproject.org:running:1
osuosl01.fedoraproject.org:pagure01.fedoraproject.org:running:1
osuosl01.fedoraproject.org:proxy06.fedoraproject.org:running:1
osuosl01.fedoraproject.org:repospanner-osuosl01.fedoraproject.org:running:1
osuosl02.fedoraproject.org:keys01.fedoraproject.org:running:1
osuosl02.fedoraproject.org:pagure-stg01.fedoraproject.org:running:1
osuosl02.fedoraproject.org:proxy09.fedoraproject.org:running:1
osuosl02.fedoraproject.org:smtp-mm-osuosl01.fedoraproject.org:running:1
osuosl02.fedoraproject.org:unbound-osuosl01.fedoraproject.org:running:1
virthost-cc-rdu01.fedoraproject.org:ci-cc-rdu01.fedoraproject.org:running:1
virthost-cc-rdu01.fedoraproject.org:proxy14.fedoraproject.org:running:1
virthost-cc-rdu01.fedoraproject.org:smtp-mm-cc-rdu01.fedoraproject.org:running:1
virthost-cc-rdu02.fedoraproject.org:infinote.fedoraproject.org:running:1
virthost-cc-rdu02.fedoraproject.org:proxy03.fedoraproject.org:running:1
virthost-cc-rdu02.fedoraproject.org:repospanner-cc-rdu01.fedoraproject.org:running:1
virthost-cc-rdu02.fedoraproject.org:unbound-cc-rdu01.fedoraproject.org:running:1
virthost-cc-rdu03.fedoraproject.org:download-cc-rdu01.fedoraproject.org:running:1
virthost-cc-rdu03.fedoraproject.org:ipv6-test.fedoraproject.org:running:1
virthost-rdu01.fedoraproject.org:bastion13.fedoraproject.org:running:1
virthost-rdu01.fedoraproject.org:batcave13.rdu2.fedoraproject.org:running:1
virthost-rdu01.fedoraproject.org:ns13.rdu2.fedoraproject.org:running:1
virthost-rdu01.fedoraproject.org:proxy13.fedoraproject.org:running:1
data-analysis01.phx2.fedoraproject.orgdl.fedoraproject.org (service has multiple front ends so outages should be
short per)
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/7809
Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
--
Stephen J Smoogen.
https://fedoraproject.org/wiki/Changes/perl5.30
== Summary ==
A new ''perl 5.30'' version brings a lot of changes done over a year
of development. Perl 5.30 should be released at the end of May 2019.
See [https://metacpan.org/pod/release/XSAWYERX/perl-5.30.0-RC1/pod/perldelta.pod
5.30.0 perldelta] for more details about preparing release.
== Owner ==
* Name: [[User:Jplesnik| Jitka Plesníková]]
* Email: <jplesnik(a)redhat.com>
* Name: [[User:Ppisar| Petr Písař]]
* Email: <ppisar(a)redhat.com>
=== Completed Items ===
=== Items in Progress ===
=== Items to Be Done ===
* Upstream to release Perl 5.30
* Get dedicated build-root from rel-engs (''f31-perl'')
* Define perl_bootstrap in perl-srpm-macros
* Rebase perl to 5.30.0
* Build new perl 5.30 keeping old COMPAT Provides
* Rebuild dual-lived packages (otherwise dnf recommends --skip-broken and fails)
* Rebuild packages needed for minimal build-root
* Rebuild packages needed for building source packages from git repository
* Remove old perl(:MODULE_COMPAT_5.28.*) from perl
* Undefine perl_bootstrap
* Rebuild other packages: Use Fedora::Rebuild dependency solver
* Rebuild packages having perl_bootstrap condition in spec file
* Rebuild all updated packages
* Merge dedicated build-root to rawhide and remove the dedicated one by rel-engs
* Synchronize packages upgraded in ''f31'' build root
* Rebuilt Perl packages: 0 of 3186 done (0.00 %)
* Failed builds (0):
* Unsatisfied dependencies (0):
== Detailed Description ==
New perl is released every year and updates containing mainly bug
fixes follow during the year. The 5.30.0 version is stable release
this year.
In addition, Perl ''site'' paths will be made ABI-specific. CPAN
modules intended for an installation under /usr/local/ will be
installed to /usr/local/{share,lib*}/perl5/5.30 paths. This will
prevent from breaking Perl with old locally installed modules after a
Fedora upgrade.
== Benefit to Fedora ==
Up-to-date and latest perl release will be delivered to Fedora users.
== Scope ==
Every Perl package will be rebuilt in a dedicated ''f31-perl''
build-root against perl 5.30.0 and then if no major problem emerges
the packages will be merged back to ''f31'' build-root.
* Proposal owners:
New perl and all packages requiring perl or a Perl module will be
rebuilt into ''f31-perl'' build-root.
* Other developers: Owners of packages that fail to rebuild, mainly
perl-sig users, will be asked using Bugzilla to fix or remove their
packages from the distribution.
* Release engineering: [https://pagure.io/releng/issue/8368 #8368] (a
check of an impact with Release Engineering is needed)
Release engineers will be asked for new ''f31-perl'' build-root
inheriting from ''f31'' build-root. After successful finishing the
rebuild, they will be asked to merge ''f31-perl'' packages back to
''f31'' build-root.
* Policies and guidelines:
No policies have to be modified to complete this change.
== Upgrade/Compatibility Impact ==
Vast majority of functionality will be preserved. Only the packages
that failed to build against perl 5.30 will be removed from the
distribution. That will require to remove those packages from existing
systems otherwise package manager will encounter unsatisfied
dependencies. Modules installed locally into /usr/local will become
unavailable and users will need to reinstall them.
== How to Test ==
Try upgrading from Fedora 30 to 31. Try some Perl application to
verify they work as expected. Try embedded perl in slapd or snmpd.
== User Experience ==
There should not be any remarkable change in user experience. With the
exception that previously locally installed modules with a CPAN
clients will need a reinstalation.
== Dependencies ==
There is more than 3100 packages depending on perl. Most of them are
expected not to break. Finishing this change can be endangered only by
critical changes in a toolchain.
== Contingency Plan ==
If we find perl 5.30 is not suitable for Fedora 31, we will revert
back to perl 5.28 and we drop the temporary build-root with already
rebuilt packages.
* Contingency deadline: branching Fedora 31 from Rawhide.
* Blocks release? No.
== Documentation ==
* [https://metacpan.org/pod/release/XSAWYERX/perl-5.30.0-RC1/pod/perldelta.pod
5.30.0 perldelta]
* An announcement on the perl-devel mailing list
* [https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraprojec…
Making Perl site paths ABI-specific] discussion on perl-devel mailing
list
== Release Notes ==
=== Important Changes ===
* Unicode 11, 12 and draft 12.1 is supported
* The upper limit "n" specifiable in a regular expression quantifier
of the form "{m,n}" has been doubled to 65534
* Wildcards in Unicode property value specifications are now partially supported
* qr'\N{name}' is now supported
* It is now possible to compile perl to always use thread-safe locale
operations.
* Limited variable length lookbehind in regular expression pattern
matching is now experimentally supported
* Use faster method to convert to UTF-8
* Turkic UTF-8 locales are now seamlessly supported
* Eliminate opASSIGN macro usage from core
* -Drv now means something on -DDEBUGGING builds
=== Removed Features and Incompatible Changes ===
* Removed modules: Math::BigInt::CalcEmu, arybase, Locale::Code, B::Debug
* Pattern delimiters now must be graphemes
* Delimiters must now be graphemes
* Some formerly deprecated uses of an unescaped left brace "{" in
regular expression patterns are now illegal
* Assigning non-zero to $[ is fatal
* Previously deprecated sysread()/syswrite() on :utf8 handles now fatal
* my() in false conditional prohibited
* Fatalize $* and $#
* Fatalize unqualified use of dump()
* Remove File::Glob::glob()
* pack() no longer can return malformed UTF-8
* Any set of digits in the Common script are legal in a script run of
another script
* JSON::PP enable allow_nonref by default
* Site paths moved from /usr/local/…/perl5 to /usr/local/…/perl5/5.30
=== Deprecated Features ===
* In XS code, use of various macros dealing with UTF-8.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/DisableRootPasswordLoginInSshd
== Summary ==
The upstream OpenSSH disabled password logins for root back in 2015.
The Fedora should follow to keep security expectation and avoid users
surprises with this configuration.
== Owner ==
* Name: [[User:jjelen| Jakub Jelen]], OpenSSH maintainer
* Email: jjelen(a)redhat.com
== Detailed Description ==
The OpenSSH server configuration contains a configuration option
`PermitRootLogin`, which controls whether the root user is allowed to
login using passwords or using public key authentication. The root
login is target of most of the random or targeted attack on Linux
systems and password is usually the weakest part. For that reason, the
upstream OpenSSH changed this option in 2015 to `prohibit-password`,
which still allows public-key authentication, but prevents the
password logins. Fedora was for many practical reasons keeping the old
configuration since then, but the difference is no longer bearable and
might confuse users expecting the root logins will not be enabled out
of the box.
On the other hand, there is still a lot of infrastructure, installers
and test instances that simply might depend on this configuration and
therefore this change needs to go through the system-wide change so
everyone is onboard.
== Benefit to Fedora ==
This will provide more secure Fedora installations out of the box and
prevent inadvertently accessible root logins in the wild.
== Scope ==
* Proposal owners: Modify the default shipped sshd configuration in
`sshd_config` to no longer include the `PermitRootLogin yes` option
and advertise this change throughout Fedora.
* Other developers: Make sure their workflow does not include logging
in as a root to ssh, otherwise modify that workflow
* Release engineering: [https://pagure.io/releng/issues/8342]
* Policies and guidelines: none
* Trademark approval: none
== Upgrade/compatibility impact ==
The updates of previously-modified `sshd_config` will not be affected
and create a `.rpmnew` configuration file.
The updates of default `sshd_config` will be updated and the
modification needs to be listed in release notes to prevent surprises.
== How To Test ==
* Make sure you have root user with password and you can login to this
user using `su`
* Make sure the sshd_config does not contain `PermitRootLogin yes` option
* Restart sshd service: `systemctl restart sshd`
* Try to connect to root user: `ssh
-oPreferredAuthentications=password root@localhost`
* Should fail
Other authentication methods (publickey, gssapi should not be affected)
== User Experience ==
Nothing in production should really depend on root password logins in
2019. If it does, it is the time to change that (or explicitly allow
it on the affected systems).
== Dependencies ==
Installer and kickstarts depending on this functionality.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Maintainer
will revert the change to sshd_config if needed.
* Contingency deadline: Beta freeze
* Blocks release? no
* Blocks product? no
== Documentation ==
OpenSSH in Fedora 31 does not allow root logins using passwords by default.
Upstream release notes: http://www.openssh.com/txt/release-7.0
== Release Notes ==
OpenSSH in Fedora 31 does not allow root logins using passwords by default.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/MingwEnvToolchainUpdate
== Summary ==
Update the MinGW base environment and toolchain to the latest upstream
stable releases.
== Owner ==
* Name: [[User:smani|Sandro Mani]]
* Email: manisandro(a)gmail.com
== Detailed Description ==
The following packages will be updated
* mingw-gcc to version 9.1.0
* mingw-w64-tools to version 6.0.0
* mingw-winpthreads to version 6.0.0
* mingw-crt to version 6.0.0
* mingw-headers to version 6.0.0
* mingw-binutils to version 2.32
Packages for early testing are available here:
https://copr.fedorainfracloud.org/coprs/smani/mingw-gcc9/builds/
== Benefit to Fedora ==
Ship the latest available MinGW environment and GNU toolchain.
== Scope ==
* Proposal owners:
The above mentioned packages will be updated. Build failures following
the mass rebuild will be inspected.
* Other developers:
Help with build failures may be requested.
* Release engineering: Impact check [https://pagure.io/releng/issues/8340]
* Release engineering: Mass rebuild requested
* Policies and guidelines: No policies need to be changed
== Upgrade/compatibility impact ==
No impact
== How To Test ==
Update the system once the updated packages land, look out for new
build failures etc.
== User Experience ==
The features of the newest MinGW environment and GNU Toolchain will be
available to the users.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Revert to older versions of environment /
toolchain, mass rebuild mingw packages again
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No
== Documentation ==
* http://gcc.gnu.org/gcc-9/
* https://mingw-w64.org/doku.php/versions
== Release Notes ==
Fedora 31 comes with the mingw-w64-6.0.0 environment, mingw-gcc-9.1
and mingw-binutils 2.32.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Today we are starting the Nomination & Campaign period during which we
accept nominations to the "steering bodies" of the following teams:
* FESCo (Engineering) (4 seats) [1]
* Fedora Council (1 seat) [2]
* Mindshare (1 seat) [3]
This period is open until 2019-05-22 at 23:59:59 UTC.
Candidates may self-nominate. If you nominate someone else, please
check with them to ensure that they are willing to be nominated before
submitting their name.
The steering bodies are currently selecting interview questions for
the candidates.
Nominees submit their questionnaire answers via a private Pagure
issue. The Election Wrangler or their backup will publish the
interviews to the Community Blog before the start of the voting
period. Fedora Podcast episodes will be recorded and published as
well.
Please note that the interview is mandatory for all nominees. Nominees
not having their interview ready by end of the Interview period
(2019-05-29) will be disqualified and removed from the election.
As part of the campaign people may also ask questions to specific
candidates on the appropriate mailing list.
The full schedule of the elections is available on the Elections
schedule[4]. For more information about the elections process, see the
wiki[5].
[1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
[2] https://fedoraproject.org/wiki/Council/Nominations
[3] https://fedoraproject.org/wiki/Mindshare/Nominations
[4] https://fedorapeople.org/groups/schedule/f-30/f-30-elections.html
[5] https://fedoraproject.org/wiki/Elections
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Fedora 28 will be EOL on Tuesday, May 28th, 2019. On this day we are
going to close all of the Fedora 28 bugs which remain open [1].
You have a few weeks remaining to submit updates, if you have any,
before the Fedora 28 release becomes unsupported.
[1] https://fedoraproject.org/wiki/Releases/30/HouseKeeping#Fedora_28_EOL_Closu…
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him