F22 System Wide Change: Ruby 2.2
by Jaroslav Reznik
= Proposed System Wide Change: Ruby 2.2 =
https://fedoraproject.org/wiki/Changes/Ruby_2.2
Change owner(s): Vít Ondruch <vondruch(a)redhat.com>
Ruby 2.2 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.1 in Fedora 21 to Ruby 2.2 in
Fedora 22, alongside JRuby, Fedora becomes the superior Ruby development
platform.
== Detailed Description ==
Ruby 2.2 is upstream's new major release of Ruby. Notable changes are:
* Incremental GC
* Symbol GC
* core libraries:
** Support Unicode 7.0
** New methods in Enumerable, Float, File and String classes
* bundled libraries
** Updated Psych 2.0.6, Rake 10.4.0, RDoc 4.2.0, Update RubyGems 2.4.4+, test-
unit 3.0.7, minitest 5.4.3
** Deprecate mathn, DL
* C API
** Remove deprecated APIs
Ruby 2.2 is source level backward compatible with Ruby 2.1, so your software
will continue to work.
== Scope ==
* Proposal owners:
** Finish packaging of Ruby 2.2. Current changes available in private-ruby-2.2
branch of ruby package in dist-git.
** 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.2 properly.
* Release engineering:
** Separate Koji tag for package rebuild will be needed. The same tag will be
used for Ruby on Rails 4.2 change proposal as well.
* Policies and guidelines:
** Since testrb tool suggested by guidelines to execute test suite was
deprecated, the packaging guidelines needs minor update to reflect this change
(fortunately this change was already reflected in most packages).
9 years, 2 months
F22 Self Contained Change: Lohit2 Odia Telugu
by Jaroslav Reznik
= Proposed Self Contained: Lohit2 Odia Telugu =
https://fedoraproject.org/wiki/Changes/Lohit2_Odia_Telugu
Change owner(s): Pravin Satpute <pravins(a)fedoraproject.org>
Lohit2 project aims to make open type tables of Indian fonts effective and
efficient following various standard around font technology including Unicode,
Open type specification, Adobe font naming guidelines. During Fedora 22 Lohit
upstream planning to release Lohit Odia and Lohit Telugu with completely
rewritten open type tables.
== Detailed Description ==
Lohit Odia and Telugu fonts are available from 2004. Over the years number of
redundant and incorrect open type rules got added into this to cope up with
different layout engine available with Pango, Qt and ICU. We started using
Harfbuzz-NG unified shaper in Fedora from Fedora 19. Its time to clean-up Odia
and Telugu open type tables and make them effective and efficient by following
all the standards around font technology. Under Lohit2 project this is
happening with Fedora 22 release cycle.
== Scope ==
* Proposal owners: Update fonts to the new upstream
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
9 years, 2 months
F22 System Wide Change: Harden all packages with position-independent code
by Jaroslav Reznik
= Proposed System Wide Change: Harden all packages with position-independent
code =
https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-...
Change owner(s): Till Maas <opensource(a)till.name>, Moez Roy
<moez.roy(a)gmail.com>
Harden all packages with position-independent code to limit the damage from
certain security vulnerabilities.
== Detailed Description ==
Currently, the Packaging Guidelines allow maintainers to decide whether their
packages use position-independent code (PIC). There are rules that say that a
lot of packages should use PIC, but in reality a lot of packages do not use
PIC even if they must. Also since a lot of packages if not all potentially
process untrusted input, it makes sense for these packages to use PIC to
enhance the security of Fedora. Therefore I propose to build all packages with
PIC by changing RPM to use the appropriate flags by default.
References:
* https://fedorahosted.org/rel-eng/ticket/6049
* There should be several mails about this on the devel list
== Scope ==
* Proposal owners:
Help writing the new packaging guidelines.
* Other developers:
Change the rpm macros to build packages by default with PIC/PIE flags (i.e. set
_hardened_package to 1 by default).
* Release engineering:
Do a mass rebuild for all arch packages
* Policies and guidelines:
Adjust the Packaging Guidelines to allow non-PIC packages only if the package
is not working otherwise and require a tracker bug similar to packages not
working on certain archs. Update the Guidelines to reflect the new defaults.
9 years, 2 months
F22 System Wide Change: Fedora 22 Boost 1.58 Uplift
by Jaroslav Reznik
= Proposed System Wide Change: Fedora 22 Boost 1.58 Uplift =
https://fedoraproject.org/wiki/Changes/F22Boost158
Change owner(s): Petr Machata <pmachata(a)redhat.com>
This change brings Boost 1.57.0 or later to Fedora 22. We generally aim to
ship 1.58.0, as that seems likely to make it (hence the Change name), but
1.57.0 is out and available now.
== Detailed Description ==
The aim is to synchronize Fedora with the most recent Boost release. Because
ABI stability is one of explicit Boost non-goals, this entails rebuilding of
all dependent packages. This has also always entailed yours truly assisting
maintainers of client packages in decoding cryptic boostese seen in output
from g++. Such care is to be expected this time around as well.
Boost 1.58 doesn't have firm schedule yet. I don't think there is even a
provisional schedule at this point. We may have to package Boost 1.57 instead.
Here is the Fedora 21 Change [1], should you need it.
== Scope ==
Rebasing Boost has a fairly large impact on Fedora. For Fedora 20, the scope
was: about 130 packages _must_ be rebuilt due to ABI breakage inherent in
bumping Boost sonames. There were almost 250 client packages total. I expect
these numbers to stay in the same ballpark for Fedora 22.
* Proposal owners:
** Build will be done with Boost.Build v2 (which is upstream-sanctioned way of
building Boost)
** Request a "boost" build system tag
** Build boost into that tag
** Post a request for rebuilds to fedora-devel
** Work on rebuilding dependent packages in the tag.
** When most is done, re-tag all the packages to rawhide
** Watch fedora-devel and assist in rebuilding broken Boost clients (by fixing
the client, or Boost).
* Other developers: Those who depend on Boost DSO's will have to rebuild their
packages. Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.
* Release engineering: Side tag creation.
* Policies and guidelines: Apart from scope, this is business as usual, so no
policies, no guidelines.
[1] https://fedoraproject.org/wiki/Changes/F21Boost156
9 years, 2 months
F22 System Wide Change: GHC 7.8
by Jaroslav Reznik
= Proposed System Wide Change: GHC 7.8 =
https://fedoraproject.org/wiki/Changes/GHC_7.8
Change owner(s): Jens Petersen <petersen(a)redhat.com>, Ricky Elrod
<relrod(a)redhat.com>, Haskell_SIG <haskell(a)lists.fedoraproject.org>
Update the GHC Haskell compiler to the major new 7.8 release, and
update/rebuild all Haskell packages against it.
== Detailed Description ==
* The involves updating ghc from 7.6.3 to 7.8.1 (or later), and
rebuilding/updating all Fedora Haskell packages.
* The initial work will be done locally offline to make sure that it is possible
to build all our packages with ghc-7.8 and the latest updated libraries.
* This may also include building with the llvm backend to ensure that building
on ARM will work.
* Once that is completed, building will be done into Koji for rawhide and
testing done.
== Scope ==
* Proposal owners:
** locally test rebuilding and updating of all packages
** update macros to subpackage static libraries
** push changes to Koji
** testing
* Other developers:
** If you own a package which contains some Haskell code built with ghc you
will need to rebuild you package to make sure it still rebuilds with ghc-7.8.
Feel free to contact the Haskell SIG if we need assistance with fixing any
build breakage, and we will try to help out.
* Release engineering: not required
* Policies and guidelines:
** There may be some lesser changes to the Haskell Packaging Guidelines needed
- they could be done after this Change.
9 years, 2 months