= Proposed System Wide Change: wxPython 3 =
https://fedoraproject.org/wiki/Changes/wxPython3
Change owner(s): Scott Talbert <swt(a)techie.net>
Get wxPython 3 packaged and into Fedora.
== Detailed Description ==
This change proposal aims to get wxPython 3.0 (Python bindings for the
wxWidgets GUI library) packaged and into Fedora. Currently Fedora has wxPython
2.8 which has not been updated since 2011. The plan is to make wxPython 3.0
co-installable with wxPython 2.8, similarly to what has been done with the
wxWidgets packages (wxGTK and wxGTK3).
== Scope ==
* Proposal owners:
** Update existing wxPython package so that it is co-installable with wxPython
3 (currently in progress [1]).
** Get wxPython 3 through the package review process, built, and ensure it can
co-exist with wxPython 2.8 package.
** If all wxPython-dependent packages get moved to wxPython 3.0, consider
retiring wxPython 2.8 package.
* Other developers:
** For maintainers of packages that depend on wxPython: switch the dependent
packages to use wxPython 3.0. This can be done package-by-package as time
permits. The API hasn't changed much between wxPython 2.8 and 3.0, but some
changes may be required.
** If a package cannot be moved to wxPython 3, after wxPython 3 is packaged,
maintainers should verify that their packages continue to use wxPython 2.8
correctly when wxPython 3.0 is co-installed. A small change may be required
to some packages to ensure they select wxPython 2.8 specifically.
* Release engineering: None
* Policies and guidelines: None
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1142515
= Proposed System Wide Change: Elasticsearch =
https://fedoraproject.org/wiki/Changes/Elasticsearch
Change owner(s): Jiri Vanek <jvanek(a)rehat.com>
Goal of this change is to pack Elasticsearch into main Fedora repo.
== Detailed Description ==
The Elasticsearch [1] is fully-featured self-standing opensource [2] indexing
server. Many people and many tools do use it. And many people do want it in
Fedora. Aim of this Change is to make elastic search available by simple yum
install elasticsearch, and of course enable it as dependence. To build a
custom indexing tool on top of elastic search is more easy than current
upstream install and download.
== Scope ==
* Proposal owners:
** pack Elasticsearch - nearly done - see RHBZ#902086
** make it somehow works
** verify it works
** tune list of crucial dependencies
** enable Elasticsearch as service - something what have to be decided
* Other developers:
** '''This is crucial part of this proposal'''
** Elastic search is extremely tuned application, and like it, its
dependencies must be strictly kept in correct versions
** Currently known troublemakers:
*** lucene
*** netty3
*** sigar
*** compress-lzf
*** guava (currently needed 18, avaiable 17)
* Release engineering:
** Nothing I'm aware about.
* Policies and guidelines:
** Nothing I'm aware about.
** maybe... fedora is going by way - keep as updated as possible, if it
breaks something, that something have to be fixed. This is not best for ES.
Maybe ES can et some helping exception?
[1] http://www.elasticsearch.com/products/elasticsearch
[2] https://github.com/elasticsearch/elasticsearch/
= Proposed System Wide Change: Ruby on Rails 4.2 =
https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.2
Change owner(s): Josef Stříbný <jstribrny(a)redhat.com>, Vít Ondruch
<vondruch(a)redhat.com>, ruby-sig(a)lists.fedoraproject.org
Ruby on Rails 4.2 is the latest version of well know web framework written in
Ruby.
Note: This change might be changed to Rails 5.
== Detailed Description ==
The Ruby on Rails stack is evolving quickly and Fedora needs to keep pace with
it. Therefore the whole Ruby on Rails stack should be updated from 4.1 in
Fedora 21 to 4.2 (latest version) in Fedora 22. This will ensure that all the
Ruby developers using Fedora have the latest and greatest RPM-packaged Ruby on
Rails.
== Scope ==
* Proposal owners:
** The whole Rails stack has to be updated
** Some dependencies of the Rails stack will need update
For set of updated packages, see Change page.
* Other developers: Update Rails dependent packages to be working with Ruby on
Rails 4.2
* Release engineering: Not needed.
* Policies and guidelines: Not needed
= Proposed System Wide Change: UEFI Secure Boot Blacklist Updates =
https://fedoraproject.org/wiki/Changes/UEFISecureBootBlacklistUpdates
Change owner(s): Peter Jones <pjones(a)redhat.com>
Currently our implementation of UEFI Secure Boot does not include a facility
to apply blacklist ("dbx") updates enabled by default. We provide a utility,
dbxtool, which uses a systemd service to apply updates, and when there are
updates we update that package with the new data. dbxtool is currently not
installed on UEFI machines by default, and when it is installed, its systemd
service does not default to enabled.
== Detailed Description ==
In UEFI Secure Boot, the ability for a pre-boot binary such as a bootloader or
hardware maintenance utility to be executed is determined by a whitelist of
binaries and cryptographic signing certificates, as well as a blacklist of
binaries and signing certificates which are no longer considered valid. When a
signed binary is discovered to have vulnerabilities which allow it to be used
to circumvent the Secure Boot security model, and thus render the system
unable to prevent execution of pre-boot malware, the UEFI CA, in coordination
with the UEFI Security Response Team (USRT) and the relevant software vendor,
must undertake remedial action. The software vendor must fix their
vulnerability and issue a new version of the software, and the old software
must be blocked from execution on applicable machines.
The first task is up to the vendor in question. Once the new version is ready
(or when sufficient time has passed), if a vulnerability is being actively
exploited or has a sufficiently high likelihood of being so, the UEFI CA issues
a blacklist entry in the form of an update to the UEFI variable "dbx". That
update is a cryptographically signed list of binaries and/or signing
certificates in a format which may be appended to a specific UEFI variable.
Currently Fedora includes the dbxtool [1] utility for updating the UEFI dbx
blacklist. The dbxtool package includes the most recent UEFI CA blacklist
update (they each include all data, so previous versions are not required) and
a systemd service to ensure the update is applied to the system. Currently
dbxtool is not installed by default on applicable systems, and when it is
installed, its service is not enabled by default.
This change principally takes place in three packages:
* shim-signed must include a dependency on dbxtool
* dbxtool must have systemd %pre and %post scriptlets added
* systemd must include dbxtool.service in its 90-default.preset
== Scope ==
* Proposal owners: Implement proposed change
* Other developers: potentially the systemd-maint team, though I think I can
commit the applicable change there.
* Release engineering: N/A
* Policies and guidelines: If we're keeping a list somewhere of things allowed
to have system preset services, dbxtool should be added.
[1] https://github.com/vathpela/dbxtool
= Proposed Self Contained: Preupgrade Assistant =
https://fedoraproject.org/wiki/Changes/Preupgrade_Assistant
Change owner(s): Petr Hracek <phracek(a)redhat.com>
The Preugrade Assistant is a tool to help people upgrade from one release to
another and be sure to track important manual configuration changes they
performed.
== Detailed Description ==
The idea behind the The Preupgrade Assistant came from the notion that even
during the rather short release cycles in Fedora occasionally there are
changes that are incompatible between releases and which are either hard or
nearly impossible to cover during a standard package upgrade. Examples would
be major version upgrades of applications or services that change configuration
file syntax or on-disk date format changes.
The Preupgrade Assistant works by analyzing the source system and will
generate a report which will offer information and configuration files for
typically changed settings and services. It offers a plugin architecture where
component or functional area owners can contribute and write their on plugins
in python, bash or perl that can generate additional information for the
report.
== Scope ==
The Preupgrade Assistant is a standalone tool that doesn't affect any other
component in the system. The scope for Fedora 22 is to provide the basic
framework and initial plugins for general use. Additional component or
functional area plugins rely on component owners to actively help working on
them.
* Proposal owners: Provide the basic framework and initial plugins for general
use
* Other developers: Provide additional component or functional area plugins
(optional)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
= Proposed System Wide Change: Perl 5.20 =
https://fedoraproject.org/wiki/Changes/perl5.20
Change owner(s): Jitka Plesníková <jplesnik(a)redhat.com>, Petr Písař
<ppisar(a)redhat.com>
A new perl 5.20 version brings a lot of changes done over a year of
development. See 5.20.0 perldelta [1] for more details.
== Detailed Description ==
New perl is released every year and updates containing mainly bug fixes follow
during the year. The 5.20.0 version is stable release this year.
== Scope ==
Every Perl package will be rebuilt in a dedicated ''f22-perl'' build-root
against perl 5.20.0 and then if no major problem emerges the packages will be
merged back to ''f22'' build-root.
* Proposal owners:
New perl and all packages requiring perl or a Perl module will be rebuilt into
f22-perl build-root.
* Other developers:
Owners of packages that fail to rebuild, mainly perl-sig users, will be asked
using Bugzilla to fix or remove their packages from the distribution.
* Release engineering:
Release engineers will be asked for new f22-perl build-root inheriting from
f22 build-root. After successful finishing the rebuild, they will be asked to
merge f22-perl packages back to f22 build-root.
* Policies and guidelines:
No policies have to be modified to complete this change.
[1] http://search.cpan.org/dist/perl-5.20.0/pod/perldelta.pod
= Proposed System Wide Change: Change xorg input stack to use libinput =
https://fedoraproject.org/wiki/Changes/LibinputForXorg
Change owner(s): Hans de Goede <hdegoede(a)redhat.com>
Replace the current (low-level) input xorg drivers with libinput using the
xorg-x11-drv-libinput wrapper.
== Detailed Description ==
Currently xorg uses different input drivers depending on the device type. This
makes it impossible to do things like middle button scrolling on the
trackpoint on laptops where the trackpoint buttons are software-emulated
buttons on the touchpad. Besides this the xf86-input-synaptics driver was
never really designed for multi-touch touchpads and this causes various
issues.
For Wayland we've been working on a new improved input stack, which is to be
shared by all compositors and lives inside libinput. We plan to replace the
current (low-level) input xorg drivers with libinput using the xorg-x11-drv-
libinput wrapper.
== Scope ==
Besides xorg changes, this will also require changes to the control panel
applets for mouse / touchpad configuration in the various desktop environments,
as those all are hardcoded to use the xorg-x11-drv-synaptics specific
interfaces.
* Proposal owners:
Package libinput and xorg-drv-input-libinput (done), make sure that xorg-drv-
input-libinput has the necessary config interfaces for control panel
mouse/touchpad config applets (wip). Write patches for gnome-control-center
mouse/touchpad capplet. Coordinate with other desktop environments.
* Other developers:
GNOME: merge the gnome-control-center patches. KDE: limits itself to standard
X11 mouse config interfaces, no changes needed. Other Desktop Environments:
adjust control-panel code to deal with xorg-x11-drv-libinput, merge these
changes.
* Release engineering: N/A
* Policies and guidelines: N/A
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings.
This is a reminder email about the end of life process for Fedora 19.
Fedora 19 will reach end of life on 2015-01-06, and no further updates
will be pushed out after that time. Additionally, with the recent
release of Fedora 21, no new packages will be added to the Fedora 19
collection.
Please see http://fedoraproject.org/wiki/DistributionUpgrades for more
information on upgrading from Fedora 19 to a newer release.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJUiI5EAAoJEH7ltONmPFDRCEMP/1Gh7JBy2mRQQxuIA+wqTX3u
c4eE42Gld1TzH7bqtGXSBdVdgYIykqAF7jl/kHBRcfL9pKUzc0VyrIBKnxxIFl7e
LGpFQJXgIg3nKIUSbX6VQohYiZQ9FvAnHp+oU+GdEg46uNViGWZQsL0PiBD1MV0/
2pZg4GBQw/nHJoppGMEeMYJe2DTaTyRZ0+HL/H4ROfaMeSs6pu1ZtuqZlUSJx8J3
DIPLewfzbLapTITga2FnWU6IB+cYbBr5rP98F7/Hb3A9BCLysZy5NBu81ty4Xlqn
hSYEzsxNFXfo1vrG7UcDOno/UVhukmrVNFw/JTf6+fHW2+FeHwXjnD16wD1JQ1KE
3m0nLgEKVSrPgRmeDT3z6jFXTsuhPx53bnoPcz1D5coVZ4zB/O6gt3xgq1phZNUC
He/4CfADjIQivanuUfp8Wo2gEVOk+vwsgQ3DcTqWB5B0eXdyfiGepDp1alavpCXr
6Ca2xdiCF0R404ixndjZPG0ns9ezo8eTLBIYUOAga42U8gbKJ3t3BB0mlaawyEWm
izd6+u/85OCSFwghoNSAFe0+YjPEVqjluGFzILihC7ROh+KVfkw6fOtW4HFwXMPl
TUd5seF8w1eliO5HW1nxVQ3/i6zjMlA4hlF1wre+o2Q/f/J5Qg3xGSe0PjlcAMKd
yhl0rdJSesuC/dE+CUzQ
=4gwv
-----END PGP SIGNATURE-----