devel-announce November 2018

devel-announce@lists.fedoraproject.org

7 participants
15 discussions

Fedora 27 End Of Life
by Mohan Boddu 30 Nov '18

30 Nov '18

Hi, As of the 30th of November 2018, Fedora 27 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 27. Fedora 28 will continue to receive updates until 4 weeks after the release of Fedora 30. 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

1 0

Bugzilla outage/upgrade on 2 December 2018
by Ben Cotton 30 Nov '18

30 Nov '18

Hi all, If you haven't seen the banner at the top of bugzilla.redhat.com, it is scheduled to undergo an upgrade from Bugzilla 4 to Bugzilla 5 on December 2 2018. The outage will begin on 2 December at 0:00 UTC and end on 2 December at 12:00 UTC. For more information on Bugzilla 5, see: https://partner-bugzilla.redhat.com/page.cgi?id=whats-new.html https://partner-bugzilla.redhat.com/page.cgi?id=release-notes.html Bugzilla 5.0 introduces a new REST endpoint to replace XML-RPC and JSON-RPC. The XML-RPC and JSON-RPC APIs will remain available. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

1 1

Fedora 30 Self-Contained Change proposal: Migrate Python-based Nautilus extensions to Python 3
by Ben Cotton 29 Nov '18

29 Nov '18

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

1 0

Fedora 30 System-Wide Change proposal: Ruby 2.6
by Ben Cotton 28 Nov '18

28 Nov '18

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

1 0

[HEADS UP] Rawhide buildroot now has glibc-minimal-langpack instead
by Igor Gnatenko 28 Nov '18

28 Nov '18

Hello, the removal of glibc-all-langpacks from the buildroot[0] is done. Standard buildroot has decreased from 445 to 237 megabytes in installed size ;) Before: DEBUG util.py:439: Install 146 Packages DEBUG util.py:439: Total download size: 86 M DEBUG util.py:439: Installed size: 445 M After: DEBUG util.py:439: Install 146 Packages DEBUG util.py:439: Total download size: 61 M DEBUG util.py:439: Installed size: 237 M All thanks go to zbyszek and mboddu :champagne:! [0]https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_bu…

1 0

REMINDER: Fedora 27 End of Life on 2018-Nov-30
by Ben Cotton 26 Nov '18

26 Nov '18

I apologize for the short notice. As a reminder, Fedora 27 reaches End of Life on Friday, 30 November 2018. On this date, we will close all the Fedora 27 bugs which remain open[1]. [1] https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&… -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

1 0

Fedora 30 System-Wide Change Proposal: GnuPG2 as default GPG implementation
by Ben Cotton 26 Nov '18

26 Nov '18

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

1 0

Planned Outage - src.fedoraproject.org - 2018-11-20 08:30 UTC
by Pierre-Yves Chibon 16 Nov '18

16 Nov '18

Planned Outage - src.fedoraproject.org - 2018-11-20 08:30 UTC There will be an outage starting at 2018-11-20 08:30 UTC, which will last approximately 1 hour. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2018-11-20 08:30UTC' Reason for outage: We will be upgrading the pagure instance running at src.fedoraproject.org to the latest release of pagure. Affected Services: https://src.fedoraproject.org https://koji.fedoraproject.org (since builds pull from dist-git via http) Ticket Link: https://pagure.io/fedora-infrastructure/issue/7367 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above.

1 0

Dec 2018 Fedora Elections: Nomination & Campaign period is open
by Ben Cotton 14 Nov '18

14 Nov '18

Today we are starting the Nomination & Campaign period during which we accept nominations to the "steering bodies" of the following teams: * FESCo (Engineering) (5 seats) [1] * Fedora Council (1 seat) [2] * Mindshare (1 seat) [3] This period is open until 2018-Nov-28 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 nominees can already start preparing their answers for questions in the Election Questionnaire. The questions can be found in the template files[4]. Nominees submit their questionnaire answers via a private Pagure issue[5]. The Election Wrangler or their backup will publish the interviews to the Community Blog [6] a day before the start of the Voting period (2018-Dec-06). Please note that the interview is mandatory for all nominees. Nominees not having their interview ready by end of the Interview period (2018-Dec-05) will be disqualified and removed from the election. Nominees may submit their interview answers immediately and may edit them until the end of the interview period. Nominees are encouraged to begin their interview answers as soon as they accept their nomination. As part of the Campaign people might also ask questions to specific candidates on @devel mailing list, if they want. The full schedule of the December 2018 Elections is available on the Elections schedule[7]. [1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations [2] https://fedoraproject.org/wiki/Council/Nominations [3] https://fedoraproject.org/wiki/Mindshare/Nominations [4] https://pagure.io/fedora-project-schedule/blob/master/f/elections/2018-Dece… [5] https://pagure.io/fedora-project-schedule/issues [6] http://communityblog.fedoraproject.org/ [7] https://fedorapeople.org/groups/schedule/f-29/f-29-elections.html -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

1 0

Bodhi update pushes are now automated
by Mohan Boddu 07 Nov '18

07 Nov '18

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.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce November 2018