Fedora 30 Self-Contained Change proposal: Migrate Python-based
Nautilus extensions to Python 3
by Ben Cotton
https://fedoraproject.org/wiki/Changes/NautilusExtensionsPython3
The Python backend for the nautilus-python extension will be updated
from python2 to python3. All Nautilus extensions written in Python
will need to be checked for Python 3 compatibility and updated if
necessary. Extensions compatible only with Python 2 will no longer be
supported.
## Owner
Name: Kalev Lember, Frank Dana
Email: klember(a)redhat.com, ferdnyc(a)gmail.com
Release notes owner:
## Detailed Description
The nautilus-python package allows Nautilus extensions to be written
in the Python scripting language. In Fedora releases up to and
including Fedora 29, these extensions were executed in a Python 2
environment. With the general move to Python 3 as Fedora's default
Python runtime and the impending deprecation of Python 2,
nautilus-python will execute extension code in a Python 3 context.
Compatibility with Python 3 will be required for all Python-based
Nautilus extensions.
(Note: In Fedora 28 the nautilus-python package was named
python2-nautilus. For Fedora 29 the name has been reverted to
nautilus-python to better indicate its status as a Nautilus
component.)
## Benefit to Fedora
In addition to eliminating nautilus-python's direct dependency on
Python 2, this change will remove all Python-based Nautilus extensions
from the list of Fedora components which still require the legacy
Python 2 interpreter (which has been deprecated, and is slated for
removal). It will allow us to ensure that all Python-based Nautilus
extensions still in use are fully compatible with Python 3.
## Scope
Proposal owners: Build nautilus-python with Python 3 support and deploy.
Other developers: N/A (not a System Wide Change)
Release engineering: N/A (not a System Wide Change)
List of deliverables: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change)
Trademark approval: N/A (not needed for this Change)
## Upgrade/compatibility impact
N/A (not a System Wide Change)
## How To Test
Launch the Nautilus file manager and verify that any functionality
provided by Python-based extensions is still available.
## User Experience
As long as Python 3 compatibility is verified for all Nautilus Python
extensions, users will see no impact from this change. If any
extensions are not compatible with Python 3 and must be removed, users
may notice loss of certain functionality from Nautilus.
## Dependencies
Any Nautilus extensions which use nautilus-python will have to be
checked for Python 3 compatibility. Repackaging should not be
necessary, as the nautilus-python dependency Required by those
packages will be carried forward to Python 3 builds.
The list of packages in the Fedora 29 repos which depend on
nautilus-python is, as of 2018-11-08:
kde-connect-nautilus
nautilus-font-manager
nautilus-pastebin
nautilus-phatch
nextcloud-client-nautilus
nitroshare-extension-nautilus
onionshare
owncloud-client-nautilus
qdigidoc-nautilus
rabbitvcs-nautilus
tilix-nautilus
tortoisehg-nautilus
## Contingency Plan
Continue shipping builds of nautilus-python based on Python 2.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years
Fedora 30 System-Wide Change proposal: Ruby 2.6
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Ruby_2.6
== Summary ==
Ruby 2.6 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.5 in Fedora 29 to
Ruby 2.6 in Fedora 30, 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.6 is upstream's new major release of Ruby. Many new features
and improvements are included.
=== JIT ===
Ruby 2.6 introduces an initial implementation of JIT (Just-in-time) compiler.
JIT compiler aims to improve performance of any Ruby program
execution. Unlike ordinary JIT compilers for other languages, Ruby’s
JIT compiler does JIT compilation in a unique way, which prints C code
to a disk and spawns common C compiler process to generate native
code.
The main purpose of this JIT release is to provide a chance to check
if it works for your platform and to find out security risks before
the 2.6 release. JIT compiler is supported when Ruby is built by GCC,
Clang, or Microsoft VC++, which needs to be available on runtime.
Otherwise you can’t use it for now.
As of Ruby 2.6.0 preview3, we achieved 1.7x faster performance than
Ruby 2.5 on CPU-intensive non-trivial benchmark workload called
Optcarrot. The performance on memory-intensive workload like Rails
application are going to be improved as well.
=== RubyVM::AST [Experimental] ===
Ruby 2.6 introduces `RubyVM::AST` module.
This module has `parse` method which parses a given ruby code of
string and returns AST (Abstract Syntax Tree) nodes, and `parse_file`
method which parses a given ruby code file and returns AST nodes.
`RubyVM::AST::Node` class is also introduced. You can get location
information and children nodes from `Node` objects. This feature is
experimental. Compatibility of the structure of AST nodes are not
guaranteed.
=== New Features ===
* Add a new alias `then` to `Kernel#yield_self`.
* Add `Random.bytes`.
* Add `Binding#source_location`. This method returns the source
location of binding, a 2-element array of __FILE__ and __LINE__.
* Add `:exception` option to let `Kernel.#system` raise error instead
of returning `false`.
* Add a new alias then to `Kernel#yield_self`.
* `else` without `rescue` now causes a syntax error. [EXPERIMENTAL]
* Constant names may start with a non-ASCII capital letter.
* An endless range, (1..), is introduced. It works as it has no end.
=== Performance improvements ===
* Speedup `Proc#call` because we don’t need to care about $SAFE any
more. With `lc_fizzbuzz` benchmark it makes x1.4 speed improvement.
* Speedup `block.call` where block is passed block parameter. Ruby 2.6
improves the performance of passed block calling. There can observed
2.6x improvement with micro-benchmarks.
* Transient Heap (theap) is introduced. theap is managed heap for
short-living memory objects which are pointed by specific classes. For
example, making small and short-living Hash object is x2 faster. With
rdoc benchmark, 6-7% performance improvement is observed.
=== Other notable changes since 2.5 ===
* `$SAFE` is a process global state and we can set `0` again.
* Passing `safe_level` to `ERB.new` is deprecated. `trim_mode` and
`eoutvar` arguments are changed to keyword arguments.
* Merged RubyGems 3.0.0.beta2.
* Merge Bundler as default gem.
== 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.6. Current changes available in PR
https://src.fedoraproject.org/rpms/ruby/pull-request/32
** 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 2.6 properly.
* Release engineering: [https://pagure.io/releng/issue/7936 #7936]
** 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.6. The test builds are pusblished in PR or
on Ruby-SIG ML
* Try to locally rebuild your packages using Ruby 2.6.
* 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
156
</pre>
== Contingency Plan ==
* 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_6_0_preview3/NEWS Ruby
2.6.0.preview3 NEWS]
== Release Notes ==
* The Ruby 2.6 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/trunk/NEWS
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years
Fedora 30 System-Wide Change Proposal: GnuPG2 as default GPG implementation
by Ben Cotton
https://fedoraproject.org/wiki/Changes/GnuPG2_as_default_GPG_implementation
== Summary ==
The /usr/bin/gpg path representing the main GPG implementation will
now use GnuPG 2 instead of GnuPG 1.
== Owner ==
* Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:till|Till
Maas]], [[User:ngompa|Neal Gompa]]
* Email: ignatenkobrain(a)fedoraproject.org, opensource(a)till.name,
ngompa13(a)gmail.com
== Detailed Description ==
For long time, GnuPG 2 is de-facto standard and it is unfortunate to
have /usr/bin/gpg to point to GnuPG 1 given that all major
repositories already have it that way.
Some of them don't even have GnuPG 1 shipped (RHEL is one example).
== Benefit to Fedora ==
This change will bring Fedora in line with other major distributions,
users will get consistent experience between distributions and the
naive expectation that "gpg" binary is the latest and greatest
implementation of GnuPG.
== Scope ==
* Proposal owners:
** Rename gnupg package to gnupg1
** Rename gpg binary to gpg1
** Rename gpg2 binary to gpg
** Create gpg2 → gpg symlink
** Check and fix if needed existing packages which require /usr/bin/gpg
* Other developers: Everything can be handled by change owners.
* Release engineering: [https://pagure.io/releng/issue/7920 #7920]
* Policies and guidelines: No changes are needed.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Users will have to adapt to change that gpg is now called gpg1 if
their usage is not compatible with both 1.x and 2.x.
== How To Test ==
Before change is implemented, owners will prepare COPR repository. You
will need to enable it and update and ensure that your
applications/scripts still work.
== User Experience ==
* /usr/bin/gpg is pointing to latest release of GnuPG 2 which makes
consistent user experience between distributions
== Dependencies ==
What can't be adopted to this change will be patched to use gpg1
explicitly, no action is needed from any developers.
== Contingency Plan ==
* Contingency mechanism: Owners will revert changes and postpone
change to next release.
* Contingency deadline: Beta Freeze.
* Blocks release? No
* Blocks product? No
== Documentation ==
Both gpg1 and gpg2 have their own documentation shipped with them.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years
Bodhi update pushes are now automated
by Mohan Boddu
Hello all,
For a long time now updates are pushed manually everyday. It was
troublesome and someone has to own it for a week and look after it.
Now, the pushes are automated and are pushed everyday at 00:00 UTC. If
anything fails there will be an oncall person (same person who used to do
the pushes) who will take care of the failure.
During release freezes these automated pushes are disabled and are manually
pushed by RelEng/Infra. Since freezes should be handled differently this
will give RelEng more control over the pushes.
Please let us know if you have any questions or contact us on
#fedora-releng on Freenode.
Thanks,
Mohan Boddu.
5 years