F36 Change: Ruby 3.1 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Ruby_3.1
== Summary ==
Ruby 3.1 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 3.0 in Fedora 35 to
Ruby 3.1 in Fedora 36, Fedora becomes the superior Ruby development
platform.
== Owner ==
* Name: [[User:vondruch| Vít Ondruch]]
* Email: vondruch(a)redhat.com
== Detailed Description ==
Ruby 3.1 is upstream's new major release of Ruby. Many new features
and improvements are included.
=== YJIT: New experimental in-process JIT compiler ===
Ruby 3.1 merges YJIT, a new in-process JIT compiler developed by Shopify.
Since Ruby 2.6 introduced MJIT in 2018, its performance greatly
improved, and finally we achieved Ruby3x3 last year. But even though
Optcarrot has shown impressive speedups, the JIT hasn’t benefited real
world business applications.
Recently Shopify contributed many Ruby improvements to speed up their
Rails application. YJIT is an important contribution, and aims to
improve the performance of Rails applications.
Though MJIT is a method-based JIT compiler and uses an external C
compiler, YJIT uses Basic Block Versioning and includes JIT compiler
inside it. With Lazy Basic Block Versioning (LBBV) it first compiles
the beginning of a method, and incrementally compiles the rest when
the type of arguments and variables are dynamically determined. See
YJIT: a basic block versioning JIT compiler for CRuby for a detailed
introduction.
With this technology, YJIT achieves both fast warmup time and
performance improvements on most real-world software, up to 22% on
railsbench, 39% on liquid-render.
YJIT is still an experimental feature, and as such, it is disabled by
default. If you want to use this, specify the --yjit command-line
option to enable YJIT. It is also limited to macOS & Linux on x86-64
platforms for now.
https://bugs.ruby-lang.org/issues/18229
https://shopify.engineering/yjit-just-in-time-compiler-cruby
https://www.youtube.com/watch?v=PBVLf3yfMs8
=== debug gem: A new debugger ===
A new debugger debug.gem is bundled. debug.gem is fast debugger
implementation and it provides many features like remote debugging,
colorful REPL, IDE (VSCode) integration and more. It replaces
lib/debug.rb standard library.
=== error_highlight: Fine-grained error location in backtrace ===
A built-in gem, error_highlight, has been introduced. It includes
fine-grained error location in backtrace:
$ ruby test.rb
test.rb:1:in `<main>': undefined method `time' for 1:Integer (NoMethodError)
1.time {}
^^^^^
Did you mean? times
This gem is enabled by default. You can disable it by using a
command-line option --disable-error_highlight. See the repository in
detail.
=== Irb improvement ===
=== Other Notable New Features ===
* Language
** Values in Hash literals and keyword arguments can be omitted.
** Pin operator in pattern matching now takes an expression.
* RBS
** `rbs collection` has been introduced to manage gems’ RBSs.
** Many signatures for built-in and standard libraries have been added/updated.
** It includes many bug fixes and performance improvements too.
* TypeProf
** Experimental IDE support has been implemented.
** Many bug fixes and performance improvements.
=== Performance improvements ===
* MJIT
** For workloads like Rails, the default --jit-max-cache is changed
from 100 to 10000. The JIT compiler no longer skips compilation of
methods longer than 1000 instructions.
** To support Zeitwerk of Rails, JIT-ed code is no longer cancelled
when a TracePoint for class events is enabled.
=== Other notable changes since 3.0 ===
* One-line pattern matching, e.g., ary => [x, y, z], is no longer experimental.
* Multiple assignment evaluation order has been changed slightly.
** foo[0], bar[0] = baz, qux was evaluated in order baz, qux, foo, and
then bar in Ruby 3.0. In Ruby 3.1, it is evaluated in order foo, bar,
baz, and then qux.
* Variable Width Allocation: Strings (experimental)
* Standard libraries updates
== 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 3.1. Current changes available in PR
https://src.fedoraproject.org/rpms/ruby/pull-request/106
** Rebuilding of Ruby packages providing native extensions (i.e.
packages which depends on libruby).
* Other developers:
** 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 3.1 properly.
* Release engineering: [https://pagure.io/releng/issue/10478 #10478]
** The packages are going to be rebuild in side-tag, but that does not
need releng involvement nowadays.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
* User specific Ruby binary extensions need to be rebuild.
* Ruby packages/application dependencies might need to be adjusted if
net-* and other newly bundled gems are used.
== How To Test ==
* No special hardware is needed.
* To test, install Ruby 3.1. The test builds are pusblished in PR or
on Ruby-SIG ML
* Try to locally rebuild your packages using Ruby 3.1.
* 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
130
</pre>
== Contingency Plan ==
* Contingency mechanism: We would like to get a special buildroot tag
to be able to rebuild necessary the packages with Ruby 3.1. If
anything goes wrong, the tag could be easily dropped and previous
version of Ruby 3.0 and its dependencies stays intact. The tag would
be merged into F36 after everything is rebuild.
* Contingency deadline: Mass Rebuild
* Blocks release? No
== Documentation ==
* [http://www.ruby-doc.org/ Help and documentation for the Ruby
programming language]
* [https://github.com/ruby/ruby/blob/v3_1_0_preview1/NEWS.md Ruby 3.1.0 NEWS]
* [https://www.ruby-lang.org/en/news/2021/11/09/ruby-3-1-0-preview1-released/
Ruby 3.1 release announcement]
== Release Notes ==
* The Ruby 3.1 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/v3_1_0_preview1/NEWS.md
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
Intent to retire w3c-markup-validator, perl-HTML-Tidy, tidyp
by Paul Howarth
Hello all,
I'm the Fedora maintainer of the perl-HTML-Tidy package and its
underlying library, tidyp.
The upstream maintainer of these packages has now stopped work on
tidyp, and has archived the upstream repository in a read-only state:
https://github.com/petdance/tidyp
He has also stopped work on HTML-Tidy, and is working on HTML-Tidy5
instead.
Since I no longer use this software myself, I'm intending to stop
maintaining it in Fedora. The only package I can find in Fedora that
depends on perl-HTML-Tidy is w3c-markup-validator; I have contacted
Nathanael, the maintainer of w3c-markup-validator, and since he no
longer uses that package, it would seem like the best thing to do would
be to retire all three packages.
If any other packager has an interest in any of these packages, let us
know and we can transfer ownership of them over to you. Otherwise,
they'll be retired at the start of February, before Fedora 36 is
branched.
Regards, Paul.
2 years, 4 months
botan2 soname bump
by Benjamin Kircher
Hello,
botan2 2.19 has been released and includes a soname bump for
/usr/lib64/libbotan-2.so
I will update it next week in rawhide. Based on repoquery following
packages need rebuilding:
corectrl
qownnotes
I think I can take care of rebuilding these two packages myself.
BK
2 years, 4 months
Package Review / Sponsorship Request
by Koroglu, Ali Erdinc
Hi everyone,
I’ve mpdecimal package need a re-review at https://bugzilla.redhat.com/show_bug.cgi?id=2047796, but also I need help with a sponsor.
Best Regards,
Ali Erdinc Koroglu
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
2 years, 4 months
java-17-openjdk mass-rebuild for f36 in copr III (last one)
by Jiri Vanek
Hello fellow java package maintainers!
I had run last kopr mass rebuild for JDK from java-11-openjdk to java-17-openjdk for f36. Please see https://fedoraproject.org/wiki/Changes/Java17
Full report is: https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/spammer...
Diff against rerun II https://github.com/judovana/FedoraSystemJdkBump/commit/671d5aa1c1e7355f13...
There is still some ~70 failures.
This was the last rebuild in copr. Next week or two, I will do my best to run the mass rebuild in Koji, FTBFS will be filled, and unless it goes terribly wrong, the side tag will be merged, and all would be settled.
I will spam individual maintainers in following days.
Thanx a lot to everybody who helped to fix the failures. It was some work, and is highly appreciated.
Also common issues grown a bit; https://fedoraproject.org/wiki/Changes/Java17#common_issues_packagers_can...
J.
Old long Story and how to debug:
We ran a preliminary mass rebuild of javastack in copr repo https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/ (select "all" instead of "25" at the bottom), on packages requiring java,javac, java-devel, maven-local, ant, ivy &
comp. for build. You can see the result was quite interesting:
498 total; attempted to rebuild
64 failed; from those 44 are trivial failures (but if you fix it, there is no guarantee real troubles are not hidden behind that)
425 succeeded
9 not even srpm rebuilt - orphan? dead? (but orpahns and dead ones should be already excluded)
* if you have some java package, be aware that we are bumping JDK in rawhide
* Ensure your package builds and runs fine with java-17-openjdk (see the https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/ )
* there is special tooling ready for this, before the mass rebuild is launched
** See https://fedoraproject.org/wiki/Changes/Java17#copr_preliminary_rebuild
* If you do not want Fedora to rot with java-11-openjdk for ever, continue reading
I would kindly ask you to search yourself in this list: https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/fillCop...
If you are here, please check status of your package in https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/spammer... (pain text of
https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/).
* If all your packages are "succeeded", congratulations nothing to do, and just keep en eye on JDK bump
* If there is "failed" but contains "- -" then even srpm built failes. If you wish to resurrect it, please ensure it runs against java-17-openjdk (see lower)
* If there is "failed" but failed in "seconds", then those packages failed so quickly, that the build was in initial phases. That usually mean that you build with source/target/release lower then 1.7. java-17-openjdk supports 1.7 and up.
We recommend to bump the source/target to 1.8, to allow existence of compact 1.8 packages alongside main javastack. See https://fedoraproject.org/wiki/Changes/Java17#Wrong_source.2Ftarget_version. Don't forget to upstream the patch, or
maybe it is enough to update to more fresh upstream release which supports java-17-openjdk? it may happen, that after the fix, your build will fail in more terrible way (see below)
* If there is "failed", and its none of above, then your package simply failed. Very often the scary error may be fixed by bump to latest upstream version. java-17-openjdk is out shortly, but changes against java-11-openjdk are minimal,
and upstreams keep an track. Please, try to fix the package. Don't hesitate to ask on devel(a)fedoraproject.org or java-devel(a)fedoraproject.org or directly to me jvanek(a)redhat.com. If you fix the fail, feel free to share your fix, it may help
others.
We are trying to gather the most common issues at https://fedoraproject.org/wiki/Changes/Java17#common_issues_packagers_can... . Feel free to enhance the page, or write us your case (possibly both with solution and
without) so we can add it here.
If your package is missing, and you wish it here, I will gladly add it! Just let me know - jvanek(a)redhat.com
Debugging Your failures.
The copr repo we maintain, contains builds of java-17-openjdk as system JDK, javapackages-tools, maven & comp. honoring that, and java-11-openjdk as non system JDK. Also it contains successfully rebuilt packages. You can directly use this
copr repo in several ways.
* first glance on error. On https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/ find your build (select "all" instead of "25" at the bottom),
** Click its number, select chroot (currently fedora-rawhide-x86_64 ) and check the logs. Main log is build.log.gz.
* anything you push to rawhide, will automatically rebuild here in fedora-rawhide-x86_64 chroot.
** It is the best approach. If you can fix your package in rawhide directly, without breaking the rawhide too much, go for it
** If you need to experiment, I have a mock config for you (generated from copr-cli mock-config jvanek/java17 fedora-rawhide-x86_64) which you can copy to your /etc/mock and use -
https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/spammer... . Eg:
# as root, globally
sudo wget https://raw.githubusercontent.com/judovana/FedoraSystemJdkBump/main/scrit... -O /etc/mock/jvanek-java17-fedora-rawhide-x86_64.cfg
# or as user, locally (after creating ~/.config/mock/)
wget https://raw.githubusercontent.com/judovana/FedoraSystemJdkBump/main/scrit... -O ~/.config/mock/jvanek-java17-fedora-rawhide-x86_64.cfg
# change spec, bump sources, apply patches
fedpkg srpm
mock -r jvanek-java17-fedora-rawhide-x86_64 *.src.rpm
Or any other packaging workflow you use, and you can use against the copr repo.
Thank you very much for your help, there are 73 failures, and 267 java packagers, but only 2 active members of java sig. Without your help, the JDK bump will be very hard.
Thank You!
J.
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
2 years, 4 months
F36 Change: Authselect: Move State Files to /etc (Self-Contained
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Authselect_Move_State_Files_To_Etc
== Summary ==
Authselect will move several files that are currently stored at
/var/lib/authselect to /etc/authselect/.state. This does not affect
configuration backup, that will be kept at
/var/lib/authselect/backups.
The files that will be moved are:
* /var/lib/authselect/dconf-db -> /etc/authselect/.state/dconf-db
* /var/lib/authselect/dconf-locks /etc/authselect/.state/dconf-locks
* /var/lib/authselect/fingerprint-auth /etc/authselect/.state/fingerprint-auth
* /var/lib/authselect/nsswitch.conf /etc/authselect/.state/nsswitch.conf
* /var/lib/authselect/password-auth /etc/authselect/.state/password-auth
* /var/lib/authselect/postlogin /etc/authselect/.state/postlogin
* /var/lib/authselect/smartcard-auth /etc/authselect/.state/smartcard-auth
* /var/lib/authselect/system-auth /etc/authselect/.state/system-auth
== Owner ==
* Name: [[User:pbrezina| Pavel Březina]]
* Email: pbrezina(a)redhat.com
== Detailed Description ==
These files are used by authselect to detect changes to the system
nsswitch and PAM configurations when the configuration is updated with
an updated profile using 'authselect apply-changes'. There are two
reasons for the move:
1. The current location conflicts with ostree model where /var is not
writable during rpm transaction and this currently blocks compose of
ostree systems. [https://bugzilla.redhat.com/show_bug.cgi?id=2034360
BZ#2034360]
2. Removing these files would reduce authselect functionality, user
would need to run 'authselect select --force' to restore it. Since
/var should contain only files that can be safely removed, /etc is a
better place for them.
== Feedback ==
This change is accepted by ostree system maintainers, see
[https://bugzilla.redhat.com/show_bug.cgi?id=2034360 BZ#2034360].
== Benefit to Fedora ==
This makes authselect more compatible with ostree model.
== Scope ==
* Proposal owners: Build authselect with
--statedir=/etc/authselect/.state and move files from
/var/lib/authselect to the new location. Spec file changes only.
* Other developers: N/A (not needed for this Change)
* Release engineering: [https://pagure.io/releng/issue/10544 #10544]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
No impact. Files will be moved automatically during update and
everything will keep working as prior.
== How To Test ==
1. Authselect keeps working as expected after the upgrade
== User Experience ==
This change is only under the hood, it does not affect user experience.
== Dependencies ==
No dependencies.
== 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)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Authselect state files moved from /var/lib/authselect to /etc/authselect/.state.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
libvpx soname bump 6.3.0 -> 7.0.0
by Tom Callaway
Updating libvpx in rawhide to 1.11.0 comes with an soname bump to 7.0.0.
Affected Fedora packages:
* baresip
* godot
* gstreamer1-plugins-good
* linphone
* qt5-qtwebengine
* seamonkey
* toxcore
* utox
* xpra
I'm doing a rawhide chain-build since all of these rebuild locally without
issue against the new libvpx. Hopefully that will go fine, but we'll see.
~spot
2 years, 4 months
