Hi,
A fonts packaging policy rewrite proposal has been pushed to FPC today:
https://pagure.io/packaging-committee/pull-request/934
It should be clearer, more opinionated, and take into account:
– updates of The OpenType standard
– variable fonts
– web fonts
– upstream depreciation of non OpenType formats: final stages of the
Harfbuzz consolidation decided at the 2006 Text Layout summit
https://www.freedesktop.org/wiki/TextLayout/
– appstream & fonts
– weak dependencies
– and probably more I forget here
It is based on the new fonts-rpm-macros project for automation:
This project builds on tooling enhancements in redhat-rpm-config and rpm
itself, done during the past two years for the Forge and Go sets of
packaging macros. It started 2 years ago as a fork of fontpackages,
which is the core of our current fonts packaging guidelines.
It will require putting the fonts-srpm-macros package in the default
build root, like is done for other domain-specific packaging macro
sets.
Major additions:
– better documentation (clearer and more complete)
– better automation (less packager hassle for better and more complete
results)
Major removals:
– tools and scripts
– fixing metadata with ttname
Mostly because no one seems willing to maintain those scripts, or port
ttname to python 3.
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/
showcases the new policy on 62 real-world source packages, generating
139 installation packages. Some of those are badly delayed updates to
Fedora packages, others are brand-new packages ready for Fedora
inclusion. They include major font packages such as Stix, DejaVu, Droid,
IBM Plex.
Existing Fedora packages will continue to build, the old fontpackages
macros are grandfathered in fonts-rpm-macros for now. They will be
removed in a few years to give packagers time to apply the new
guidelines.
Regards,
--
Nicolas Mailhot
Dear maintainers.
Based on the latest fail to build from source policy, the following packages
will be retired from Fedora 32 approximately one week before branching (February
2020).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails…
The packages in rawhide were not successfully built at least since Fedora 30.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbf…
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
================================================================================
elasticsearch hubbitus, jvanek, lbazan, Fedora 24
zbyszek
expresso jamielinux, nodejs-sig, Fedora 28
patches
libocrdma ocrdma Fedora 27
nuvola-app-google-calendar martinkg Fedora 29
nuvola-app-groove martinkg Fedora 28
nuvola-app-logitech-media- martinkg Fedora 29
server
nuvola-app-plex martinkg Fedora 29
nuvola-app-soundcloud martinkg Fedora 29
nuvola-app-yandex-music martinkg Fedora 29
shim-unsigned-aarch64 pjones Fedora 28
shim-unsigned-x64 pjones Fedora 28
The following packages require above mentioned packages:
Depending on: expresso (1)
nodejs-chrono (maintained by: jamielinux, nodejs-sig, tomh)
nodejs-chrono-1.0.5-10.fc31.src requires npm(expresso) = 0.9.2
Affected (co)maintainers
hubbitus: elasticsearch
jamielinux: expresso
jvanek: elasticsearch
lbazan: elasticsearch
martinkg: nuvola-app-soundcloud, nuvola-app-logitech-media-server,
nuvola-app-yandex-music, nuvola-app-groove, nuvola-app-google-calendar,
nuvola-app-plex
nodejs-sig: expresso
ocrdma: libocrdma
patches: expresso
pjones: shim-unsigned-aarch64, shim-unsigned-x64
tomh: expresso
zbyszek: elasticsearch
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
Dear maintainers.
Based on the latest fail to build from source policy, the following packages
will be retired from Fedora 32 approximately one week before branching (February
2020).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails…
The packages in rawhide were not successfully built at least since Fedora 30.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbf…
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
================================================================================
elasticsearch hubbitus, jvanek, lbazan, Fedora 24
zbyszek
expresso jamielinux, nodejs-sig, Fedora 28
patches
libocrdma ocrdma Fedora 27
nuvola-app-google-calendar martinkg Fedora 29
nuvola-app-groove martinkg Fedora 28
nuvola-app-logitech-media- martinkg Fedora 29
server
nuvola-app-plex martinkg Fedora 29
nuvola-app-soundcloud martinkg Fedora 29
nuvola-app-yandex-music martinkg Fedora 29
shim-unsigned-aarch64 pjones Fedora 28
shim-unsigned-x64 pjones Fedora 28
The following packages require above mentioned packages:
Depending on: expresso (1)
nodejs-chrono (maintained by: jamielinux, nodejs-sig, tomh)
nodejs-chrono-1.0.5-10.fc31.src requires npm(expresso) = 0.9.2
Affected (co)maintainers
hubbitus: elasticsearch
jamielinux: expresso
jvanek: elasticsearch
lbazan: elasticsearch
martinkg: nuvola-app-logitech-media-server, nuvola-app-plex, nuvola-app-groove,
nuvola-app-google-calendar, nuvola-app-soundcloud, nuvola-app-yandex-music
nodejs-sig: expresso
ocrdma: libocrdma
patches: expresso
pjones: shim-unsigned-aarch64, shim-unsigned-x64
tomh: expresso
zbyszek: elasticsearch
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-…
== Summary ==
Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
symlinks are managed by update-alternatives.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
The gcc package currently installs symlinks to /usr/bin/cc and
/usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
respectively. For this change, the gcc package will be modified so
that update-alternatives creates and manages these symlinks.
In addition to modifying the gcc package, the clang package will be
modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
alternatives for /usr/bin/cc and /usr/bin/c++. The clang alternatives
will have a lower priority than the gcc alternatives, so that by
default, gcc will provide the /usr/bin/cc and /usr/bin/c++
implementations.
The clang package currently has a run-time dependency on gcc, so this
ensures that gcc will always provide the default implementation,
because it's impossible to install clang without gcc.
The only way users will be able to change the /usr/bin/cc or
/usr/bin/c++ implementations will be by explicitly using the
update-alternatives tool.
== Benefit to Fedora ==
Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
the default C/C++ compilers. Being able to easily swap out these
implementation will provide a lot of flexibility within Fedora for
doing things like:
* Setting up alternative buildroots for testing.
* Installing a gcc wrapper script to /usr/bin/cc to help migrate
packages to new compiler flags or to capture statistics about compiler
usage.
* Letting users experiment easily with alternate compilers.
* Easily switch between system gcc and a development version of gcc.
== Scope ==
* Proposal owners: The proposal owner will implement the necessary
changes in the gcc and clang packages.
* Other developers: The gcc maintainers will be responsible for
reviewing and approving changes to the gcc package.
* Release engineering: (a check of an impact with Release Engineering is needed)
* Policies and guidelines: No policies or guidelines will need to be
updated as a result of this change.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change should not impact upgradeability.
== How To Test ==
CI tests will be added to the gcc package to ensure that /usr/bin/cc
and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
installed. There will also be a CI test added to the clang package to
ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
clang is installed.
== User Experience ==
This change will give users a much better way to experiment using
other compilers for their own development. They will be able to
easily switch between different compilers without having to modify
their projects build system or make non-standard changes to their
Fedora system.
== Dependencies ==
This change has no other dependencies besides the changes to the gcc
and clang packages.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Proposal Owner
will revert changes made to gcc and clang packages and rebuild.
* Contingency deadline: If the changes are not complete by 2 weeks
before the mass rebuild, then we will consider postponing to the next
Fedora release and back out any changes that were made.
* Blocks release? No
* Blocks product? None
== Documentation ==
Release notes will be added for this change.
== Release Notes ==
The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
update-alternatives. If you would like to change these symlinks to
point to another compiler, like clang, for example, you can use these
commands:
`update-alternatives --set cc /usr/bin/clang`
`update-alternatives --set c++ /usr/bin/clang++`
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer
== Summary ==
Enabling fstrim.timer will cause fstrim.service to execute weekly,
which in turn executes `/usr/sbin/fstrim --fstab --verbose --quiet`
== Owner ==
* Name: [[User:chrismurphy| Chris Murphy]]
* Email: bugzilla(a)colorremedies.com
== Detailed Description ==
Over time, some users experience slow downs in certain flash storage
devices. This might be alleviated by issuing a periodic fstrim command
to the mounted file system. Devices and file systems that don't
support fstrim are unaffected.
By enabling the existing fstrim.timer systemd unit file by default,
will cause weekly execution of the fstrim.service. This service acts
only on mounted filesystems listed in fstab. On supported hardware
(e.g. most SD Card, SSD, and NVMe drives), LVM thin provisioned
storage, and file systems (ext4, XFS, Btrfs, f2fs, but excluding
FAT16/32), fstrim will inform underlying physical storage device's
firmware about unused blocks. This hinting can make wear leveling and
block erasure more efficient.
The timer will execute Monday at 00:00 local time. If the system is
inactive at this time, it will be run immediately upon becoming active
again (upon wake from suspend, during or very soon after boot).
Some devices do not support "queued trim" and there may be a brief
(seconds) pause as the drive firmware acts upon command issuance. It's
expected most users won't notice this.
== Benefit to Fedora ==
This is an optimization to the storage stack, and may help improve
performance and wear leveling for some devices. On LVM thin
provisioned stacks, unused LV extents will be returned to the thin
pool, reducing the likelihood of pool exhaustion.
In a way, this is overdue on Fedora, as it's been the default behavior
on other distributions for a while (at least Ubuntu and openSUSE). At
least it has been well tested.
== Scope ==
* Proposal owners:<br>
Upon approval, submit a PR for fedora-release, modifying
90-default.preset to enable fstrim.timer
* Other developers:<br>
fstrim.timer is provided by util-linux, notify util-linux maintainer<br>
https://bugzilla.redhat.com/show_bug.cgi?id=1785041
* Release engineering: [https://pagure.io/releng/issues #9116]
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
fstrim.timer will be enabled on upgrade. An upgraded system should
exhibit the same behaviors as a clean installed system.
== How To Test ==
The low level function of systemd timers, fstrim.service, and fstrim
command are well understood and tested already, all Fedora needs to
test is that the timer is enabled following clean installation and
upgrades:<br><br>
Preliminaries:
* Clean install Fedora 32, any edition or spin; or
* Upgrade from Fedora 30 or Fedora 31, any edition or spin, to Fedora 32
Confirm:
* Run `sudo systemctl list-timers`
* Confirm `fstrim.timer` is listed under UNITS, and is next scheduled
for Monday 00:00:00
* Anytime following the listed NEXT date+time, run `sudo systemctl
status fstrim.timer`
Example, should apply in all cases:<br>
{{code|Dec 18 13:48:54 fmac.local systemd[1]: fstrim.service: Succeeded.}}
Full example on a device with an SSD and filesystem supporting trim:<br>
<pre>
$ sudo systemctl status fstrim.service
● fstrim.service - Discard unused blocks on filesystems from /etc/fstab
Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static;
vendor preset: disabled)
Active: inactive (dead) since Wed 2019-12-18 13:48:54 MST; 15min ago
Docs: man:fstrim(8)
Process: 3870 ExecStart=/usr/sbin/fstrim --fstab --verbose --quiet
(code=exited, status=0/SUCCESS)
Main PID: 3870 (code=exited, status=0/SUCCESS)
CPU: 1.387s
Dec 18 13:48:48 fmac.local systemd[1]: Starting Discard unused blocks
on filesystems from /etc/fstab...
Dec 18 13:48:54 fmac.local fstrim[3870]: /: 32 GiB (34409328640 bytes)
trimmed on /dev/sda4
Dec 18 13:48:54 fmac.local systemd[1]: fstrim.service: Succeeded.
Dec 18 13:48:54 fmac.local systemd[1]: Started Discard unused blocks
on filesystems from /etc/fstab.
Dec 18 13:48:54 fmac.local systemd[1]: fstrim.service: Consumed 1.387s CPU time.
</pre>
<br>
Regardless of configuration, there should be no errors.
== User Experience ==
Most users will not notice the change. Some will notice improved
performance of flash storage devices, and more efficient use of thinly
provisioned storage.
This does not affect all storage. Only file systems listed in fstab
are affected.
If the user/admin wants fstrim to apply to all mounted file systems,
they should copy the original fstrim.service unit file, replacing
`--fstab` with `--all`, and use this modified unit file as a drop-in
service unit in /etc. See
https://www.freedesktop.org/software/systemd/man/systemd.unit.html
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Owner will revert the change
* Contingency deadline: final freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
man fstrim
== Release Notes ==
fstrim.timer is enabled by default, and runs fstrim.service weekly.
This service executes `/usr/sbin/fstrim --fstab --verbose --quiet` See
`man fstrim` for details.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/LTOByDefault
== Summary ==
This is a proposal to enable link time optimization (LTO) of packages
built with rpmbuild by default. It's an over-simplification, but
think of LTO as deferring analysis, optimization and code generation
until creation of an executable or dynamic shared object.
This is implemented by adding the option "-flto" the injected flags in
redhat-rpm-config. There will be a simple way for packages to opt-out
of LTO.
== Owner ==
* Name: Jeff Law
* Email: law(a)redhat.com
== Detailed Description ==
Programs built with rpmbuild and which honor flags injection via
redhat-rpm-config will be built with LTO by default. A simple opt-out
mechanism will be provided for packages which use features that are
not LTO compatible.
The LTO bytecode itself will not be distributed as it is not stable
from one GCC release to the next. This is enforced by stripping the
LTO bytecode from any installed .o/.a files. We'll use bits SuSE has
already written for redhat-rpm-config to implement this.
Minor changes are desirable to the %configure macro in
redhat-rpm-config to fix common code idioms used by autoconf generated
scripts which are compromised by the additional optimization enabled
by LTO. Minor updates to various packages will be needed to opt-out
of LTO or fix bugs exposed by LTO.
== Benefit to Fedora ==
The primary benefits of building with LTO enabled are smaller, faster
executables/DSOs. A secondary benefit is LTO allows deeper analysis
of package source code at compile time which can improve various GCC
diagnostics and thus improve our ability to catch bugs at compile time
such as uninitialized objects, buffer overflows, unterminated strings,
restrict violations, etc.
This change also brings us back on-par with SuSE who enabled LTO by
default for their free distribution earlier in 2019.
== Scope ==
* Proposal owners:
The primary change is to redhat-rpm-config to add LTO to the default
compile/link flags as well as a conditional which allows easy opt-out
on a package by package basis. Additionally the post-build scripts
need to strip the LTO bytecodes from any installed .o/.a files.
Additionally, we know there are many packages with configure scripts
that are compromised by LTO. I have tweaks to the %configure macro in
redhat-rpm-config which fixes the vast majority of these problems with
a few simple sed scripts on the generated output. Like the basic
support for injecting the LTO flags, this will require coordination
with the redhat-rpm-config maintainers. Packages which call configure
directly and have compromised tests will need a one line change to
their .spec files to fix their configure scripts.
Some packages will need to opt-out of using LTO at this time. The
most common case are packages that use symbol versioning or toplevel
ASM statements. While there is a new mechanism to make LTO work with
symbol versioning, I don't think any packages have been updated to use
that mechanism. This will require a one line change to 50-75 packages
(my script to find these is still running).
Finally, some packages will fail to build with LTO due to deeper
analysis for compile-time diagnostics catching programming mistakes
that have gone unnoticed until now. I'll obviously be working with
package maintainers on all of these issues.
Note that even though the changes are fairly well localized in
redhat-rpm-config and a small number of packages, the real scope of
this change is much larger since it affects all packages in the
distribution that are compiled with GCC and which honor the flags
injection by redhat-rpm-config.
* Other developers:
As I mentioned, I'm happy to contact package owners that need to
modify their packages and suggest how their package needs to be fixed.
As a multi-decade GCC developer, I'm particularly well suited to
describe LTO, its limitations and how LTO impacts the diagnostics from
GCC to any package owner that needs additional information.
I'm also capable and available to address any GCC issues that we may
arise as a result of this change. I don't expect much of the latter
as SuSE has already enabled this feature for their distribution and
thus weeded out most of the issues.
The highest level of coordination will be with the redhat-rpm-config
maintainers.
I will also be coordinating with the GDB team to address debugging
issues related to LTO. The most important issue is to ensure that we
can pass the GDB testsuite with and without the -flto option being
enabled. Failure to meet this goal would be considered a blocking
issue for LTO enablement.
I'm also already in contact with SuSE and Debian/Ununtu engineers to
discuss issues with gcc-10 with and without LTO.
We know there are some problems with debugging LTO code. I will be
working with the GDB team to identify these issues and fix them either
in the debugger or compiler as needed.
I have prototype code for the required redhat-rpm-config changes and
I'll coordinate with the redhat-rpm-config maintainer to get them into
the desired final form.
I also know every package that fails with LTO enabled. I'm still
categorizing those failures. Many will ultimately need to use the
opt-out mechanism because they use features that are not compatible
with LTO. I expect to have all this ready to go the first work week
of the new year. I will coordinate with package owners to either add
the opt-out markers or fix issues in the package as needed.
* Release engineering: (a check of an impact with Release Engineering is needed)
Aside from the redhat-rpm-config changes, I do not expect any work
from releng to be necessary. However, they need to be aware of the
change and who to contact in case of issues.
* Policies and guidelines: It would be useful to document how to
opt-out of LTO in the packaging guidelines.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Should not affect compatibility. Stripping of the LTO bytecode is
critical to ensure there are not long term compatibility issues.
== How To Test ==
In the short term, I'm happy to expose a repository with a gcc-10
snapshot and updated redhat-rpm-config. Developers could then use
that repo to pick up gcc-10 and LTO optimizations for testing
purposes. I'm already doing this internally for x86_64 and exposing
it to the world would be trivial.
Given such a repository, another developer would merely use that repo
when building their package. No special hardware is needed. The most
useful testing is first to identify FTBFS issues and get them
proactively fixed. I'm happy to own that since I'm already doing that
for baseline gcc-10 issues as well as gcc-10 + LTO issues.
Doing the same testing on other architectures would definitely be
useful. I'd be particularly concerned about large packages on the
32bit architectures. I wouldn't be surprised if we find some packages
need to opt-out of LTO because they run out of memory at link/compile
time. I'm already in contact with some Debian maintainers who want
to do testing around this issue as they're investigating a similar
change for Debian.
I'm already building all of Fedora with the weekly gcc-10 snapshots
(including LTO builds starting the week of 12/15). This is primarily
to proactive find/address issues with the gcc-10 transition, but
verification of LTO state pretty much piggy backs for free on the
gcc-10 work.
== User Experience ==
In theory, the only noticeable difference to users would be smaller,
faster binaries and DSOs. However, a developer that uses rpmbuild to
build their own code may see their package fail to build if it's got
errors or uses certain features that do not work with LTO.
Users who try to debug Fedora shipped executables could notice
differences in the debugging experience.
== Dependencies ==
None expected beyond addressing FTBFS issues and coordination between
GCC and GDB teams on any debugging issues we find over the next few
weeks.
== Contingency Plan ==
* Contingency mechanism: Revert the LTO flags injection
* Contingency deadline: Beta freeze, but shooting for prior to mass
rebuilds starting
* Blocks release? No
* Blocks product? No
Most critically, if we don't address the GDB testsuite issue noted
above, our fallback position would be to simply disable the LTO
injection globally and re-evaluate for Fedora 33, similarly if we were
to find some show-stopping LTO issue.
Otherwise the plan is to analyze the remaining 100-125 package build
failures. These are likely a mixture of configure issues that can't
be trivially fixed via %configure, new diagnostics exposed by the
deeper analysis from LTO, and other small issues.
== Documentation ==
I would think we would want documentation on the opt-out method for RPM builds.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Ruby_2.7
== Summary ==
Ruby 2.7 is the latest stable version of Ruby. Many new features and
improvements are included for the increasingly diverse and expanding
demands for Ruby. With this major update from Ruby 2.6 in Fedora 31 to
Ruby 2.7 in Fedora 32, Fedora becomes the superior Ruby development
platform.
== Owner ==
* Name: [[User:vondruch| Vít Ondruch]], [[User:pvalena| Pavel Valena]]
* Email: vondruch(a)redhat.com, pvalena(a)redhat.com
== Detailed Description ==
Ruby 2.7 is upstream's new major release of Ruby. Many new features
and improvements are included.
=== Compaction GC ===
This release introduces Compaction GC which can defragment a
fragmented memory space.
Some multi-threaded Ruby programs may cause memory fragmentation,
leading to high memory usage and degraded speed.
The `GC.compact` method is introduced for compacting the heap. This
function compacts live objects in the heap so that fewer pages may be
used, and the heap may be more CoW friendly.
=== Pattern Matching [Experimental] ===
Pattern matching, a widely used feature in functional programming
languages, is introduced as an experimental feature.
It can traverse a given object and assign its value if it matches a pattern.
=== REPL improvement ===
`irb`, the bundled interactive environment (REPL;
Read-Eval-Print-Loop), now supports multi-line editing. It is powered
by `reline`, a `readline`-compatible pure Ruby implementation. It also
provides rdoc integration. In `irb` you can display the reference for
a given class, module, or method.
Besides, source lines shown at `binding.irb` and inspect results for
core-class objects are now colorized.
=== Separation of positional and keyword arguments ===
Automatic conversion of keyword arguments and positional arguments is
deprecated, and conversion will be removed in Ruby 3.
* When a method call passes a Hash at the last argument, and when it
passes no keywords, and when the called method accepts keywords, a
warning is emitted. To continue treating the hash as keywords, add a
double splat operator to avoid the warning and ensure correct behavior
in Ruby 3.
* When a method call passes keywords to a method that accepts
keywords, but it does not pass enough required positional arguments,
the keywords are treated as a final required positional argument, and
a warning is emitted. Pass the argument as a hash instead of keywords
to avoid the warning and ensure correct behavior in Ruby 3.
* When a method accepts specific keywords but not a keyword splat, and
a hash or keywords splat is passed to the method that includes both
Symbol and non-Symbol keys, the hash will continue to be split, and a
warning will be emitted. You will need to update the calling code to
pass separate hashes to ensure correct behavior in Ruby 3.
* If a method does not accept keywords, and is called with keywords,
the keywords are still treated as a positional hash, with no warning.
This behavior will continue to work in Ruby 3.
* Non-symbols are allowed as keyword argument keys if the method
accepts arbitrary keywords.
* `**nil` is allowed in method definitions to explicitly mark that the
method accepts no keywords. Calling such a method with keywords will
result in an ArgumentError.
* Passing an empty keyword splat to a method that does not accept
keywords no longer passes an empty hash, unless the empty hash is
necessary for a required parameter, in which case a warning will be
emitted. Remove the double splat to continue passing a positional
hash.
=== Other Notable New Features ===
* Numbered parameter as the default block parameter is introduced as
an experimental feature.
* A beginless range is experimentally introduced. It might not be as
useful as an endless range, but would be good for DSL purposes.
* `Enumerable#tally` is added. It counts the occurrence of each element.
* Calling a private method on `self` is now allowed.
* `Enumerator::Lazy#eager` is added. It generates a non-lazy
enumerator from a lazy enumerator.
=== Performance improvements ===
* JIT [Experimental]
** JIT-ed code is recompiled to less-optimized code when an
optimization assumption is invalidated.
** Method inlining is performed when a method is considered as pure.
This optimization is still experimental and many methods are NOT
considered as pure yet.
** The default value of `--jit-min-calls` is changed from 5 to 10,000.
** The default value of `--jit-max-cache` is changed from 1,000 to 100.
* The performance of `CGI.escapeHTML` is improved.
* The performance of Monitor and MonitorMixin is improved.
=== Other notable changes since 2.6 ===
* Some standard libraries are updated.
* Big part of stdlib was to default gems.
* `Proc.new` and `proc` with no block in a method called with a block
is warned now.
* `lambda` with no block in a method called with a block errs.
* Update Unicode version and Emoji version from 11.0.0 to 12.0.0.
* Update Unicode version to 12.1.0, adding support for U+32FF SQUARE
ERA NAME REIWA.
* `Date.jisx0301`, `Date#jisx0301`, and `Date.parse` support the new
Japanese era.
* Require compilers to support C99.
== Benefit to Fedora ==
With a latest release, Ruby language is supporting the newest language
features, which enables even faster and easier development of Ruby
applications.
== Scope ==
* Proposal owners:
** Finish packaging of Ruby 2.7. Current changes available in PR
https://src.fedoraproject.org/rpms/ruby/pull-request/48
** Rebuilding of Ruby packages providing native extensions (i.e.
packages which depends on libruby).
* Other developers: N/A
** Rebuild of packages with binary extensions (i.e. packages which
depends on libruby) will be handled automatically, but some packages
might need fixes/updates to support Ruby 2.7 properly.
* Release engineering: [https://pagure.io/releng/issue/9104 #9104]
** Separate Koji tag for package rebuild will be needed.
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
* User specific Ruby binary extensions need to be rebuild.
== How To Test ==
* No special hardware is needed.
* To test, install Ruby 2.7. The test builds are pusblished in PR or
on Ruby-SIG ML
* Try to locally rebuild your packages using Ruby 2.7.
* Use the packages with your applications previously written in Ruby.
* If something doesn't work as it should, let us know.
== User Experience ==
The Ruby programs/scripts should behave as they were used to.
== Dependencies ==
<pre>
$ dnf repoquery --disablerepo=* --enablerepo=rawhide
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' |
sort | uniq | wc -l
142
</pre>
== Contingency Plan ==
* Contingency mechanism: We would like to get a special buildroot tag
to be able to rebuild necessary the packages with Ruby 2.7. If
anything goes wrong, the tag could be easily dropped and previous
version of Ruby 2.6 and its dependencies stays intact. The tag would
be merged into F32 after everything is rebuild.
* Contingency deadline: Mass Rebuild
* Blocks release? No
* Blocks product? No
== Documentation ==
* [http://www.ruby-doc.org/ Help and documentation for the Ruby
programming language]
* [https://github.com/ruby/ruby/blob/v2_7_0_preview3/NEWS Ruby
2.7.0.preview3 NEWS]
== Release Notes ==
* The Ruby 2.7 bumps soname, therefore Ruby packages, which use binary
extensions, should be rebuilt. Nevertheless, since upstream paid great
attention to source compatibility, no changes to your code are needed.
https://github.com/ruby/ruby/blob/master/NEWS
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis