Reminder: Fedora 24 End Of Life on 2017-Aug-08

[Jaroslav Reznik]

Fedora 24 support is going to be EOL on Tuesday, August 08th, 2017.
At this day we are going to close all the Fedora 24 bugs which will
remain open [1].
You have last few weeks to submit  your updates to the Fedora 24, if
you have any, before the Fedora 24 release becomes unsupported.

[1] 
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora26#Fedora_24_EOL_Closure

Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 Self Contained Change: libpinyin 2.1

[Jaroslav Reznik]

= Proposed Self Contained Change: libpinyin 2.1 =
https://fedoraproject.org/wiki/Changes/libpinyin2.1

Change owner(s):
* Peng Wu 

libpinyin 2.1 will merge libzhuyin code and replace the package

== Detailed Description ==
Actually libzhuyin uses very similar code as libpinyin. After merged
libzhuyin into libpinyin, it will bring some libpinyin features to
libzhuyin.

== Scope ==
* Proposal owners:

merge libzhuyin code into libpinyin.
merge libzhuyin data into ibus-libzhuyin.
retire libzhuyin package for Fedora 27.

* Other developers: N/A (not a System Wide Change)

* Release engineering: [1]
* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)

[1] https://pagure.io/releng/issue/6912

Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 Self Contained Change: Chinese Serif Fonts

[Jaroslav Reznik]

= Proposed Self Contained Change: Chinese Serif Fonts =
https://fedoraproject.org/wiki/Changes/ChineseSerifFonts

Change owner(s):
* Peng Wu 

Fedora already provides default Chinese Sans fonts, now Fedora 27 will
also provide default Chinese Serif fonts.

== Detailed Description ==
Adobe and Google released good quality Chinese Sans and Serif fonts
now. Now Fedora 27 will package the Chinese fonts, and use the fonts
as default Chinese fonts.

== Scope ==
* Proposal owners:

new packages for adobe-source-han-serif-cn-fonts and
adobe-source-han-serif-tw-fonts.
update font packages to use both Chinese Sans and Serif fonts
update fedora-comps to install the Chinese Sans and Serif fonts by default

* Other developers: N/A (not a System Wide Change)

* Release engineering: [1]

* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)

[1] https://pagure.io/releng/issue/6911

Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 Self Contained Change: New default cipher in OpenVPN

[Jaroslav Reznik]

= Proposed Self Contained Change: New default cipher in OpenVPN =
https://fedoraproject.org/wiki/Changes/New_default_cipher_in_OpenVPN

Change owner(s):
* David Sommerseth 

Since the discovery of the SWEET32 flaw [1], ciphers using
cipher-blocks smaller than 128-bits are considered vulnerable and
should not be used any more. OpenVPN uses Blowfish (BF-128-CBC) as the
default cipher, which is hit by the SWEET32 flaw. This proposal
changes the default cipher to AES-256-GCM while in parallel allowing
clients to connect using AES-256-CBC, AES-128-CBC or the deprecated
BF-CBC,

This proposal will make use of that possibility by modifying the
openvpn-server@.service unit file slightly.

== Detailed Description ==

There have been two independent security audits of OpenVPN recently,
performed by QuarksLab SAS [2] and Cryptography Engineering [3]. Both
recommends moving away from the default Blowfish cipher (BF/BF-CBC) to
a stronger cipher.

The concept is fairly simple.  In today's openvpn-server@.service
systemd unit file the following command line is used to start OpenVPN:

ExecStart=/usr/sbin/openvpn --status
%t/openvpn-server/status-%i.log --status-version 2
--suppress-timestamps --config %i.conf

By adding --cipher AES-256-GCM --ncp-ciphers
AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC before the
--config option, the default cipher will be modified.  The
--ncp-ciphers list allows clients to use any of the listed ciphers as
well.  The new line will look like this:

ExecStart=/usr/sbin/openvpn --status
%t/openvpn-server/status-%i.log --status-version 2
--suppress-timestamps --cipher AES-256-GCM --ncp-ciphers
AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC --config
%i.conf

This will result in the following:
* OpenVPN 2.4 based clients will automatically upgrade to AES-256-GCM,
regardless if they have --cipher in their configuration file or not.
For OpenVPN v2.4 configurations not wanting this cipher upgrade, the
client configuration needs to deploy --ncp-disable.
* OpenVPN 2.3 based clients and older (and v2.4 clients using
--ncp-disable in the client configuration) can connect to the server
using any of the --ncp-ciphers list; this is what is called "poor
man's cipher negotiation" by the upstream OpenVPN developers.
* Any client not providing --cipher defaults to BF-CBC.  These clients
should still be able to connect to the server as the server allows
BF-CBC through --ncp-ciphers.

If an already configured OpenVPN v2.4  based server configuration
deploys --cipher and/or --ncp-ciphers, the options in the
configuration file will override command line options set before
--config.  This should not break any existing configuration.

The log files will still complain about the use of BF-CBC if a client
uses that.  But the advantage is that OpenVPN v2.3 and older clients
can be updated one-by-one, by adding the recommended --cipher
AES-256-CBC option in the client configurations in their own pace,
independent of the server - or upgrade to OpenVPN v2.4 or newer.

== Scope ==

* Proposal owners: Patch the openvpn-server@.service unit file which
adds the --cipher and --ncp-ciphers options.

* Other developers: N/A (not a System Wide Change)

* Release engineering: [4] (a check of an impact with Release
Engineering is needed)

* 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)

[1] https://sweet32.info/
[2] https://ostif.org/wp-content/uploads/2017/05/OpenVPN1.2final.pdf
[3] 
https://www.privateinternetaccess.com/blog/2017/05/openvpn-2-4-evaluation-summary-report/
[4] https://pagure.io/releng/issue/6908

Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 Self Contained Change: Authselect: new tool to replace authconfig

[Jaroslav Reznik]

= Proposed Self Contained Change: Authselect: new tool to replace authconfig =
https://fedoraproject.org/wiki/Changes/Authselect

Change owner(s):
* Pavel Březina 

Authselect is a tool to select system authentication and identity
sources from a list of supported profiles.

It is designed to be a replacement for authconfig but it takes a
different approach to configure the system. Instead of letting the
administrator build the pam stack with a tool (which may potentially
end up with a broken configuration), it would ship several tested
stacks (profiles) that solve a use-case and are well tested and
supported. At the same time, some obsolete features of authconfig
would not be supported by authselect.

This tool aims to be first shipped along and later deprecate and later
replace authconfig in a future Fedora release.

== Detailed Description ==

Authselect will allow the administrator to choose one of the supported
profiles. A profile provides description of how the resulting pam and
nsswitch configuration looks like. The tool will be packaged with a
default profile set that will be fully supported. If an administrator
has different needs they can create a custom profile and make it
accessible by authselect by dropping it in the tool directory.

The authentication and identity configuration is hardcoded within the
profile. However each profile is also allowed to contain some
conditional modules that can be either enabled or disabled to allow
the administrator to enable some optional behaviour such as password
policy or ecryptfs support.

Authselect will not configure daemons that provide the selected
identity and authentication services such as SSSD or winbind, it will
only configure pam and nsswitch. Daemons must be configured manually
or through other system tools like realmd or ipa-client-install.

The default profile set will contain the following profiles:

Local users + SSSD -- local users and remote users are handled by sssd
Local users + SSSD + Fingerprint -- same as above but also pam_fprintd
is enabled
Local users + winbind -- local users are handled by files and remote
users by winbind
Local users + winbind + Fingerprint -- same as above but also
pam_fprintd is enabled

We do not want to support nss-pam-ldapd and pam_krb5 in default
profiles since their use-cases are completely or almost completely
covered by SSSD. SSSD can be used as a complete replacement for
pam_krb5 and there are only few old and rarely used maps for LDAP that
remain unimplemented within SSSD such as hosts and aliases. These maps
will be added in a future SSSD version.

== Scope ==
* Proposal owners: implement the change
* Other developers: N/A (not a System Wide Change)
* Release engineering: [1] (a check of an impact with Release
Engineering is needed)
* 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)

[1] https://pagure.io/releng/issue/6907

Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 Self Contained Change: Improved Bay- and Cherry-Trail device support

[Jaroslav Reznik]

= Proposed Self Contained Change: mproved Bay- and Cherry-Trail device support =
https://fedoraproject.org/wiki/Changes/Improved_Bay_Cherry_Trail_Support

Change owner(s):
* Hans de Goede 

Improve support for hardware using Intel Bay Trail and Cherry Trail SoCs.

== Detailed Description ==
There are many affordable x86 laptops / tablets using Intel Bay Trail
and Cherry Trail SoCs this change is about improving support for these
SoCs and the peripherals typically found on devices with these SoCs.
Examples of improvements in progress are fixing battery monitoring,
touchscreen, audio and accelerometers (sometimes) not working.

== Scope ==

* Proposal owners:
Most of the work on this is kernel work and most of this is being done upstream
The Fedora kernel package needs to have the right drivers enabled as
well as some patches backported
Some small userspace changes like adding new entries to hwdb for
accelerometer orientation

* Other developers: The non-upstream kernel and hwdb changes need to
be coordinated with their resp. package owners

* Release engineering: [1] (a check of an impact with Release
Engineering is needed)

* 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)

[1] https://pagure.io/releng/issue/6881

Thanks,
Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 Self Contained Change: No More i686 Kernels

[Jaroslav Reznik]

= Proposed Self Contained Change: No More i686 Kernels =
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels

Change owner(s):
* Justin Forbes 

Stop building i686 kernels, reduce the i686 package to a
kernel-headers package that can be used to build 32bit versions of
everything else.

== Detailed Description ==
The i686 kernel is of limited use as most x86 hardware supports 64bit
these days. It has been in a status of "community supported" for
several Fedora releases now. As such, it gets very little testing, and
issues frequently appear upstream. These tend to go unnoticed for long
periods of time. When issues are found, it is often a long time before
they are fixed because they are considered low priority by most
developers upstream. This can leave other architectures waiting for
important updates, and provides a less than desirable experience for
people choosing to run a 32bit kernel. With this proposal, the i686
kernel will no longer be built. A kernel headers package will still
exist, and all 32bit packages should continue to build as normal. The
main difference is there would no longer be bootable 32bit images.

== Scope ==

* Proposal owners:
Changes to the kernel spec to stop the actual i686 builds, but keep
the kernel-headers package.

* Other developers: NA

* Release engineering: [1] (a check of an impact with Release
Engineering is needed)

* 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)

[1] https://pagure.io/releng/issues/6894

Thanks,
Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 Self Contained Change: Packaging Rust applications/libraries

[Jaroslav Reznik]

= Proposed Self Contained Change: Packaging Rust applications/libraries =
https://fedoraproject.org/wiki/Changes/Packaging_Rust_applications_and_libraries

Change owner(s):
* Igor Gnatenko  (on behalf of Rust SIG)

Add required tools/instructions for packaging applications/libraries
written in Rust. Rust is a systems programming language that runs
blazingly fast, prevents segfaults, and guarantees thread safety.

== Detailed Description ==

During initial research of SIG about packaging we identified that
inability to specify version range dependencies (1.0 <= foo < 2.0) in
RPM is main blocker. This problem hits almost every other language
ecosystem (esp. NodeJS), but it is not very noticable due to having
not more than 2 versions. While packaging some applications we
discovered need of having 3 or more versions of same crate.

The most of the work already has been done and users can consume
applications without needing to do anything from Rust/Playground COPR
repository [1].

== Scope ==

* Proposal owners: Create tool for automatic creation of rpm-spec-file
from crate on crates.io, create RPM macro for easy packaging, write
packaging guidelines.

* Other developers: RPM developers to add support for expressing
version range dependencies.

* Release engineering: #6889 (a check of an impact with Release
Engineering is needed)

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: Packaging Guidelines needs to be written
for packaging Rust applications/libraries.

* Trademark approval: N/A (not needed for this Change)

[1] https://copr.fedorainfracloud.org/coprs/g/rust/playground/
[2] https://pagure.io/releng/issue/6889

Thanks,
Jaroslav
-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 Self Contained Change: Unified database for DNF

[Jaroslav Reznik]

= Proposed Self Contained Change: Unified database for DNF =
https://fedoraproject.org/wiki/Changes/Unified_database_for_DNF

Change owner(s):
* Eduard Čuba 
* Igor Gnatenko 

Replacing obsoleted YUM/DNF databases (yumdb, historydb, groups.json)
with new unified sqlite database adapted to the current needs of DNF.

== Detailed Description ==
Using single unified database with shared interface enhances data
integrity, safety and performance of package managers in Fedora.
Database is easily expandable for new features (Modularity support in
DNF will use SWDB).

== Scope ==

* Proposal owners: Port DNF to SWDB (patches has been already sent),
Port PackageKit to SWDB

* Other developers: PackageKit developers should review proposed
changes in libdnf for logging PackageKit transactions into SWDB
instead of yumdb. In addition PackageKit developers should consider
using SWDB for reading transaction data instead of using its own
backend.

* Release engineering: [1] (a check of an impact with Release
Engineering is needed)

* List of deliverables: Change affects whole distro rather than some derivable

* Policies and guidelines: Nothing is required

* Trademark approval: N/A (not needed for this Change)

[1] https://pagure.io/releng/issue/6886
-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 System Wide Change: Drop 256term.sh

[Jaroslav Reznik]

= System Wide Change: Drop 256term.sh =
https://fedoraproject.org/wiki/Changes/Drop_256term.sh

Change owner(s):
* Zbigniew Jędrzejewski-Szmek 

Do not install /etc/profile.d/256term.sh and /etc/profile.d/256term.csh.

== Detailed Description ==
Currently Fedora installs some scripts to be executed every time a
shell is started which perform some heuristics to set $TERM based on
the terminal emulator being used. This is a work-around and it's
better to for the terminal emulator to set $TERM properly on its own.
Various terminal emulators have been updated to do that.
/etc/profile.d/256term.sh and /etc/profile.d/256term.csh will not be
installed anymore and the $TERM variable set by the terminal emulator
will be used.

[The change is trivial in and of itself. I'm making this a system wide
change, and a change at all, only because those scripts take part in
every shell startup, so it's possible they will have some unforeseen
impact or require adjustments in other components. If FESCo or
Wrangler think this does need a change page, I'm ready to drop it.]

== Scope ==
* Proposal owners: do the change in initscripts package, work with
other developers to fix any identified issues.

* Other developers: fix any identified issues

* Release engineering: [1]

* List of deliverables: N/A

* Policies and guidelines: N/A

* Trademark approval: N/A (not needed for this Change)

[1] https://pagure.io/releng/issue/6885

Thanks,
Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL

[Jaroslav Reznik]

= System Wide Change: Switch OpenLDAP from NSS to OpenSSL =
https://fedoraproject.org/wiki/Changes/OpenLDAPwithOpenSSL

Change owner(s):
* Matus Honek 

Currently, OpenLDAP in Fedora is compiled with NSS (aka MozNSS) for
cypto. OpenLDAP is going to be compiled with OpenSSL, instead.

== Detailed Description ==
OpenLDAP in Fedora is has been compiled with NSS for crypto for
several years now. Support layer for NSS was added back in 2008 but
the OpenLDAP upstream ceased to keep it up to date since 2014. Reasons
for keeping OpenLDAP compiled with NSS was to make it work with some
other packages (esp. 389DS) seamlessly. Fixing and keeping downstream
patches has become a burden, thus it was decided to switch to OpenSSL,
instead.

For more detailed description, check out Change page.

== Scope ==
* Proposal owners: write the Interception code.

* Other developers: ensure usage of OpenSSL-like TLS configuration
based on the Schedule.

* Release engineering: [1]

* List of deliverables: Not affected

* Policies and guidelines: none.

* Trademark approval: none.

[1] https://pagure.io/releng/issue/6891

Thanks,
Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 System Wide Change: Reduce Initial Setup Redundancy

[Jaroslav Reznik]

= System Wide Change: Reduce Initial Setup Redundancy =
https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy

Change owner(s):
* Michael Catanzaro 

Currently there is a high level of redundancy between the Anaconda
installer and gnome-initial-setup. This change aims to eliminate these
redundancies and streamline the initial user experience in Fedora
Workstation.

== Detailed Description ==
Firstly, please note that the effects of this change will be
restricted to Fedora Workstation. We do not propose any changes that
affect alternative Fedora installers (e.g. Calamares) or initial setup
tools (e.g. the initial-setup package, not to be confused with
gnome-initial-setup).

A few years ago, Fedora Workstation developers discussed with Anaconda
developers the redundancy between many Anaconda settings and
gnome-initial-setup. The Anaconda developers responded by added a
configuration file mechanism, /etc/sysconfig/anaconda, which can be
used to suppress Anaconda spokes if written before Anaconda runs. This
file is also written by Anaconda to tell the initial-setup tool which
Anaconda spokes the user has visited, so that the initial-setup tool
can suppress specific spokes. Although this functionality has existed
for some time now, the Workstation developers until now failed to
follow up and begin using it. We now intend to make use of this
functionality to suppress Anaconda spokes that are redundant with
gnome-initial-setup. Meanwhile, our friends at Endless OS have added a
similar configuration file for gnome-initial-setup that allows us to
suppress some configuration that is best handled in Anaconda. Below,
we discuss what we plan to do with specific settings.

Language and Keyboard Layout

Although we do not propose it at this time, language and keyboard
layout selection should be presented to the user *before* entering the
live session, as it is currently too difficult for users to change
these settings unless they are already familiar with Fedora, and --
unless you speak English and use a US keyboard -- these settings must
be changed for the live session to be usable. Both Anaconda and
gnome-initial-setup are too late for configuring these settings. (An
exception would be for netinstalls of Fedora Workstation, where
Anaconda is the best place for this configuration.) In the meantime,
until we have a way to prompt users for these settings earlier than
Anaconda, these panels should be removed from gnome-initial-setup,
because Anaconda is clearly a better place than gnome-initial-setup
for this configuration. (This would affect gnome-initial-setup when
creating the first user account. Additional user accounts created
later would still receive these panels in gnome-initial-setup.)

Time and Date

We want to remove the time and date spoke from Anaconda, since it is
largely redundant with the timezone page in gnome-initial-setup.
However, it might be necessary to remove this page from
gnome-initial-setup instead, as previously there have been technical
concerns raised regarding the necessity of configuring the system
clock before running the installer. This choice will be based on
technical feedback from the Fedora developer community.

Network

We will remove the network configuration spoke from Anaconda.
Currently this spoke only allows configuring the system hostname, but
it places restrictions on the possible characters in the hostname that
do not match the restrictions used by Fedora Workstation. Fedora
Workstation uses systemd-hostnamed to allow "pretty" hostnames with
Unicode characters and spaces, which we expect to be displayed
properly and consistently in the user interface, but the Anaconda
configuration does not follow this pattern. Additionally, exposing the
hostname as network configuration is confusing. We may consider adding
a simpler "Computer Name" setting that allows "pretty" characters and
is not presented as a networking setting in the future, but it does
not seem necessary to prompt the user to set a hostname at all.

Note: this applies only to USB install, obviously not to netinstall.
We will need some way to differentiate between the two when writing
the Anaconda configuration file.

User Account

Currently, users have the option of creating the initial user account
in Anaconda, or not. Anaconda does not require this if the user sets a
root password. Users who do not create a user account in Anaconda are
required to create a user account later, by gnome-initial-setup. This
means we currently have two different ways of creating the first user
account in Workstation, with (potentially) two different sets of bugs.
Since Anaconda allows configuring whether the initial user is added to
the wheel group, it also means some initial users will be in wheel and
others will not. We will remove the user account creation spoke in
Anaconda. All users will create the first user account using
gnome-initial-setup, and all initial users will be added to the wheel
group. Of course, this can be

F27 System Wide Change: RPM 4.14

[Jaroslav Reznik]

= System Wide Change: RPM 4.14 =
https://fedoraproject.org/wiki/Changes/RPM-4.14

Change owner(s):
* Igor Gnatenko 
* Florian Festi 
* Panu Matilainen 

Update RPM to the upcoming 4.14 release.

== Detailed Description ==
RPM 4.14 contains several improvements that needs to get released and
integrated in Fedora:
* Major macro engine bug fix + sanity work:
** Macro scope simplification + enforcing
** Macro arguments expanded
** Nested lua macro scoping fixes
** Improved error reporting
* Major header/package/signature rewrite:
** Unified code path for all header read/import
** Major hardening work on header parsing
** Unified code path for all header/package signature checking
** Signature checking before header imports
** Support for multiple signatures per package
** Support for configurable signature policies
* Major debuginfo rewrite (covered by two other changes and already
applied in F27)
* Signal handling rewrite:
** Custom signal handlers while rpmdb open
** Signals blocked throughout write transactions
* SSD conservation mode
* Improved support for reproducible builds
* RPMCALLBACK_ELEM_PROGRESS now carries index of header
* Support for OpenSSL as a one of crypto libraries used for
digests/signatures (already part of F27)
* Support for rich dependencies coming out from dependency generators
* %include can contain paths with whitespaces
* Dependency generator for pkg-config files doesn't check dependencies
in .pc recursively, but rather print top-level ones (if pkgconf is
used)
* Header digests use SHA256 by default
* Improvements in Python dependency generator
* Improvements and stabilization of "ndb"
* Support for "with" rich-operator:
** Specifying version range dependencies
** Specifying packages which provide special ability

== Scope ==
* Proposal owners:
Rebase RPM

* Other developers:
Test new release, report issues and bugs, fix bugs in packaging (if it
is not bug in RPM, should be detected during Mass Rebuild)

* Release engineering: [1] (a check of an impact with Release
Engineering is needed)

* List of deliverables:
Change affects whole distribution rather than deliverables

* Policies and guidelines:
FPC should look (and possibly approve) "with" rich dependency in
Packaging Guidelines

* Trademark approval: N/A (not needed for this Change)

[1] https://pagure.io/releng/issue/6875

Thanks,
Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

Fedora 26 status is GO, release on July 11, 2017

[Jaroslav Reznik]

The Fedora 26 Final 1.5 compose [1] is considered as GOLD and is going
to be shipped live on Tuesday, July 11th, 2017.

For more information please check the Go/No-Go meeting minutes [2] or logs [3].

I'd like to thank everyone for the hard work on this release and great job Jan!

[1] https://kojipkgs.fedoraproject.org/compose/26/Fedora-26-20170705.0/compose/
[2] 
https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-06/f26_final_gono-go_meeting.2017-07-06-17.00.html
[3] 
https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-06/f26_final_gono-go_meeting.2017-07-06-17.00.log.html

Thanks,
Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 System Wide Change: NSS signtool deprecation

[Jaroslav Reznik]

= System Wide Change: NSS signtool deprecation =
https://fedoraproject.org/wiki/Changes/NSSSigntoolDeprecation

Change owner(s):
* Kai Engert 

Deprecate the NSS tool named signtool, currently shipped as part of
the nss-tools package, and available in the default search path at
/usr/bin/signtool. Move it to
/usr/lib*/nss/unsupported-tools/signtool.

== Detailed Description ==
The NSS signtool is hardcoded to use SHA1 for signatures, however,
SHA1 is no longer considered secure. Because it seems difficult to
change the signtool default to make use of a more secure hash
algorithm in a backwards and forwards compatible way, and because
signtool might no longer be required for common uses, the suggestion
is to deprecate it.

See also [1] and [2]

== Scope ==
* Proposal owners:

The work required to implement this change is a simple packaging change.

* Other developers:

Users who used signtool for signing Jar/Zip/etc. files must use a
different tool. A possible alternative is the jarsigner tool, which is
shipped as part of the java-*-openjdk-devel package.

* Release engineering: [1]

* List of deliverables:
N/A

* Policies and guidelines:
N/A, no changes should be necessary.

* Trademark approval:
N/A (not needed for this Change)

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1345528
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1444136
[3] https://pagure.io/releng/issue/6882

Thanks,
Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 System Wide Change: NSS Default File Format SQL

[Jaroslav Reznik]

= System Wide Change: NSS Default File Format SQL =
https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql

Change owner(s):
* Kai Engert 

Change the NSS library default to use the sqlite based data storage,
when applications don't specify their preferred storage file format.

== Detailed Description ==

Applications that use the NSS library often use a database for storage
of keys, certificates and trust. NSS supports two different file
formats, one called DBM (based on berkeley DB files) and another one
called SQL (based on sqlite DB files).

Today's default file format used by NSS, used when applications omit
the type parameter, is the older DBM file format, which forbids
parallel access to the storage. The suggestion is to change the
default file format to SQL, which allows parallel access to the
storage.

Applications, or users using the NSS command line utilities, often
provide the database storage location using a simple directory path
parameter. Some might not be aware, or forget, that the parameter can
be prefixed with a type modifier, either "dbm:" or "sql:".

As a result, when not providing this parameter, the file format used
will be the fragile DBM file format. This is particuarly problematic,
if a user attempts to modify the NSS storage using command line tools,
while another process, such as a daemon, is running concurrently,
which also accesses the same database in the DBM file format. This
often results in corrupted database storage, which cannot be
recovered.

By changing the default, all applications that currently use the DBM
file format, will automatically be migrated to the SQL file format.
NSS has the ability to discover if a storage location (a directory)
contains the DBM file format. If configured to use the modern SQL
format, NSS will automatically perform a one-time conversion from the
DBM to the SQL format.

The same applies to the NSS command line utilities. If the NSS library
default is changed to SQL, the NSS tools will also trigger the
one-time conversion, or access the already converted files.

== Scope ==

* Proposal owners:

A small downstream patch needs to be applied to the NSS library
package, which changes the library default.

* Other developers:

It's up to developers of NSS applications, if they accept the new
default and an automatic conversion, or if they prefer to continue to
use the classic DBM storage format. Although not recommended,
developers can easily do so, by adding a "dbm:" prefix to the storage
parameter they provide to NSS at NSS library initialization time.

* Release engineering: [1]

No help should be necessary. No mass rebuild necessary.

* Policies and guidelines: N/A

* Trademark approval: N/A

[1] https://pagure.io/releng/issue/6883

Thanks,
Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 System Wide Change: Graphical Applications as Flatpaks

[Jaroslav Reznik]

= System Wide Change: Graphical Applications as Flatpaks =
https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks

Change owner(s):
* Owen Taylor 

This change is to enable package maintainers to build Flatpaks of
their applications and make those Flatpaks available for installation.

== Detailed Description ==

See Workstation/Flatpaks [1] for the full development plan.

The goal of this change is make Flatpaks available as a distribution
mechanism for software packaged in Fedora.

Multiple Flatpaks on the system can share a runtime of common
libraries. There will be a single Fedora runtime maintained on the
same schedule as the Platform module for Fedora. It will be be defined
as a module that includes libraries that are commonly used for
graphical applications. Some of these will inherit from the Platform
module.

Applications then bundle the code for the application itself and for
additional libraries they depend on beyond the base runtime. Each
application has its own module in which the relevant RPMs are rebuilt
with a special RPM macros (in the flatpak-rpm-macros package) to
relocate the application and bundled libraries into the /app prefix.
(This is necessary, because inside an executing Flatpak, the
application is mounted at /app, and the runtime at /usr)

The packages are then composed into Flatpaks by the layered image
service, sharing as much of the workflow and code as possible with
containers. While the native delivery mechanism for Flatpaks is as an
ostree repository, they can also be distributed as OCI images, and our
goal is to use this format during the build process, and to distribute
them to users via registry.fedoraproject.com.

Automation of rebuilds and integration with Bodhi will also be needed
to make sure that security and bug-fix updates to packages end up
being distributed to users. This part is least specified at the
current time, and full automation may not be achievable for Fedora 27.
If the above plan is followed, most of this work is shared with work
needed for modularity in general and for server-side containers.

== Scope ==
* Proposal owners: (f27)
** Create and maintain a flatpak-runtime module
** Provide tools for application authors to use to create module
descriptions for their flatpaks
** Provide patches for the container build pipeline (atomic reactor
and friends) to build flatpaks as well as containers
** Create some way to get summary information for all flatpaks on
registry.fedoraproject.org; this might be a patch to the codebase, a
look-aside file, or a separate service.
** Modify flatpak and gnome-software so that flatpaks can be installed
from registry.fedoraproject.org.

* Proposal owners: (f28)
** Provide a "SDK" profile of the flatpak-runtime module to create a
Flatpak SDK for third-party non-RPM builds against the SDK using
flatpak-builder

* Other developers: (f27)
** Provide exports of built modules as repositories (the "On Demand
Compose Service")
** Provide some reasonably self-service way for packagers to create
modules without a lot of overhead. (Does it make sense to allow
''application modules'' where when a package corresponds one-to-one to
a module to allow the modulemd to live in dist-git next to the spec
file?)
** Allow Fedora packagers to submit module builds
** Allow uploading OCI images to registry.fedoraproject.org Upstream
pull request [2]
** Make sure that Bodhi updates can be submitted for Flatpaks/OCI
Images in the same way as for Docker containers (no significant code
changes are expected beyond the current work to enable multiple types
of Bodhi updates.)

* Other developers: (f28)
** Create a unified workflow for package and container/flatpak updates
(detailed plan to be developed, something like:)
*** updates submitted to bodhi for a package should trigger automatic
module and container/flatpak builds
*** Pushing a package to stable should push the updated flatpaks/containers
*** the Bodhi user interface should show modules/containers that
include a package and their status

* Release engineering: [3] (a check of an impact with Release
Engineering is needed)
** List of deliverables: Most likely, runtime and applications would
not be part of the deliverables list. However, we will need to
consider the quality of the runtime and applications as part of the
overall quality of release - if some common application did not run on
upgrade that would seriously affect users. This should, as much as
possible, be addressed through continuous automated testing.

* Policies and guidelines: The people working on this change will need
to work closely in the development of module guidelines, and make sure
that Flatpak specifics are documented as well (for example,
documenting the creation of a 'flatpak.json' with permissions and
other metadata for the Flatpak). It's possible some changes will be
needed to the packaging guidelines to make sure that all relevant
packages relocate to /app properly, but it's expected that most
packa

F27 System Wide Change: The GNU C Library version 2.26

[Jaroslav Reznik]

= System Wide Change: The GNU C Library version 2.26 =
https://fedoraproject.org/wiki/Changes/GLIBC226

Change owner(s):
* Carlos O'Donell 

Switch glibc in Fedora 27 to glibc version 2.26.

== Detailed Description ==
The GNU C Library version 2.26 will be released at the beginning of
August 2017; we have started closely tracking the glibc 2.26
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 27 will branch after the
GLIBC 2.26 upstream release. However, the mass rebuild schedule means
Fedora 27 will mass rebuild just after GLIBC 2.26 upstream freezes ABI
for release, so careful attention must be paid to any last minute ABI
changes.

== Scope ==
* Proposal owners: Update glibc to 2.26 from tested upstream release.

* Other developers: Developers need to ensure that rawhide is stable
and ready for the Fedora 27 branch. Given that glibc is backwards
compatible and we have been testing the new glibc in rawhide it should
make very little impact when updated.

* Release engineering: [1] All Fedora releases must be released using
a released version of glibc. The Fedora glibc team is responsible for
ensuring that Fedora Rawhide stabilizes ABI before a Fedora release,
or that after the branch that the Fedora release is rebased (a very
small rebase) to the final released version. This is a requirement for
Fedora to inherit the ABI and API guarantees provided by upstream. If
a mass rebuild is required by glibc or other components, the Fedora
glibc team will ensure coordination with release engineering such that
a mass rebuild uses the released version of glibc to fix any last
minute ABI changes. The GNU C Library (glibc) does not require a mass
rebuild for this release.

* List of deliverables: all

* Policies and guidelines: The policies and guidelines do not need to
be updated.

* Trademark approval: N/A (not needed for this Change)

[1] https://pagure.io/releng/issue/6890

Thanks,
Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 Self Contained Change: VirtualBox Guest Integration

[Jaroslav Reznik]

= Proposed Self Contained Change: VirtualBox Guest Integration =
https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration

Change owner(s):
* Hans de Goede 

VirtualBox is popular, easy to use virtual-machine software. The
purpose of this change is to ship the VirtualBox guest-drivers and
-tools by default in the Fedora workstation product.

== Detailed Description ==
VirtualBox runs on Windows. MacOS and Linux and is used by many users
to try it Linux for the first time. As such it is important for Fedora
to work well in VirtualBox virtual-machines. Like other
virtual-machines VirtualBox virtual-machines can offer an enhanced
user-experience when some VirtualBox specific guest-drivers and
guest-tools are installed. This change is about adding the
guest-drivers to the Fedora kernel package, packaging the
userspace-tools (VirtualBox Guest Additions) and adding the VirtualBox
Guest Additions package to the default package list for the
Workstation product.

== Scope ==
* Proposal owners:

** Adding the VirtualBox guest drivers to the kernel package. To make
this happen work is underway to clean them up and submit them
upstream.
** Package VirtualBox Guest Additions userspace parts
** Add VirtualBox Guest Additions package to the default package list
for the Workstation product

* Other developers:
N/A (not a System Wide Change)

* Release engineering: [1]

* 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)

[1] https://pagure.io/releng/issue/6880

Thanks,
Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

Change Checkpoint: Proposal submission deadline (System Wide Changes) on Fedora 27 is today

[Jaroslav Reznik]

Hi everyone!

Today (2017-07-04) is the submission deadline for System Wide Changes
of Fedora 27 [1]. Please schedule your upcoming System Wide Changes
for the next (Fedora 28) release.

Self Contained Changes proposals submission deadline is on 2017-07-25
with changes completion (testable state) in the following week
(2017-08-01).

[1] https://fedoraproject.org/wiki/Releases/27/Schedule

Thanks,
Jaroslav

(And happy July 4th!)
-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F27 System Wide Change: 32 bit UEFI Support

[Jaroslav Reznik]

= System Wide Change: 32 bit UEFI Support =
https://fedoraproject.org/wiki/Changes/32BitUefiSupport

Change owner(s):
Peter Jones 

Some x86 systems ship with a 64 bit CPU, but 32 bit UEFI firmware. It
is possible to use a 32 bit UEFI grub build to boot a 64 bit kernel
and distribution on these systems. So far this setup has not been
supported in Fedora. This feature is about adding support for
installing and booting Fedora on this hardware.

== Detailed Description ==
To add support for booting Fedora x86_64 on x86 systems with 32 bit
UEFI firmware a number of (small) changes to grub, various EFI related
userspace tools and anaconda are necessary. See Scope for more
details.

== Scope ==
* Proposal owners:
** The x86_64 grub2 packages will need to include an extra grub build,
next to the current classic BIOS and 64 bit UEFI build a new 32 bit
UEFI build will be added to the x86_64 packages.
** This new grub will need to be added to the various x86_64 boot media
** A few EFI userspace utilities need to be updated to work with 32 bit x86 UEFI
** The installer (anaconda) needs some changes to the bootloader
installation code to install the 32 bit UEFI grub binary

* Other developers:

No changes are necessary outside of the affected packages

* Release engineering: [1]
** List of deliverables:
This feature should be enabled on all non cloud/container x86_64 images

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

[1] https://pagure.io/releng/issue/6879

Thanks,
Jaroslav
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

Fedora 25 Alpha status is GO, release on August 30, 2016

[Jaroslav Reznik]

At the second Fedora 25 Alpha Go/No-Go Meeting [1][2] that just ended,
it has been agreed by QA, Release Engineering and Development to go live
with the Fedora 25 Alpha.

Fedora 25 Alpha release will be publicly available on August 30, 2016.

Meeting details can be seen here:
[1] Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2016-08-25/f25-alpha-go_no_go-meeting.2016-08-25-17.04.html
[2] Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2016-08-25/f25-alpha-go_no_go-meeting.2016-08-25-17.04.log.html

Thanks everyone!
Jaroslav
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

FESCo and Council elections in July 2016

[Jaroslav Reznik]

Greetings,

FESCo and Council elections are now open and we're looking for new
candidates: https://fedoraproject.org/wiki/Elections

For FESCo we have opened four seats:
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations

For Council we have opened one seat:
https://fedoraproject.org/wiki/Council/Nominations

The Elections schedule is as follows:
* July 05-11: Nomination period open (closes promptly at 23:59 UTC on July 11th)
* July 12-18: Campaign period. Individual blog posts, etc. encouraged.
Will also have an email interview with all answers published
simultaneously on the 19th.
* July 19-25: Voting open (closes promptly at 23:59 UTC on July 25th)
* July 26:Results announcement

Elections Questionnaire needs more questions for email/Community blog
interviews! If you have anything you would like to ask candidates to
FESCo or to Council, please add it to the wiki.
 http://fedoraproject.org/wiki/Elections/Questionnaire

Read more about the FESCo at:
http://fedoraproject.org/wiki/Development/SteeringCommittee
and about the Council at: http://fedoraproject.org/wiki/Council

Jaroslav
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

Fedora 25 Bugzilla Rawhide rebase

[Jaroslav Reznik]

Greetings,

This e-mail is intended to inform you about the upcoming Bugzilla changes
happening on 2016-07-26 (Rawhide bug rebase) and what you need to do,
if anything.

We will be automatically changing the version for most rawhide bugs to
Fedora 25.
This will result in regular bugs reported against rawhide during the Fedora 25
development cycle being changed to version ‘25' instead of their current
assignment, ‘rawhide’.  This is to align with the branching of Fedora 25 from
rawhide and to more accurately tell where in the lineage of releases the bug was
last reported.

Note that this procedure does not apply to bugs that are open for the ‘Package
Review’ or 'kernel; components or bugs that have the ''FutureFeature''
or ''Tracking'' keywords
set. These will stay open as rawhide bugs indefinitely.

If you do not want your bugs changed to version ‘25‘, add the ''FutureFeature''
keyword. If you need help changing a large amount of bugs manually, we’d be glad
to help.

The process was re-approved by FESCo https://fedorahosted.org/fesco/ticket/1096.

Jaroslav
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

REMINDER: Changes submission deadline for Fedora 25 is today

[Jaroslav Reznik]

Hi everyone!
Today we have Fedora 25 Changes submission deadline [1]. No more
System Wide Changes should be submitted for this release (after 23:59
UTC today). Alpha release is currently planned on August, the 23rd
with Alpha Freeze two weeks earlier.

In case you'll need any help with your Change proposals, feel free to
contact me.

Btw. due to public holidays here, I might be a bit slower with
processing submitted changes. Don't worry, conclusive is date of the
submission.

[1] https://fedoraproject.org/wiki/Releases/25/Schedule
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

F25 System Wide Change: Unicode 9.0 support

[Jaroslav Reznik]

= Proposed System Wide Change: Unicode 9.0 support =
https://fedoraproject.org/wiki/Changes/Unicode_9.0

Change owner(s):
* Mike Fabian 
* Pravin Satpute 
* Carlos O'Donell 

Unicode 9.0 [1] got released on 21th June 2016. Version 9.0 adds 7,500 
characters, including six new scripts and 72 new emoji characters. These new 
script provide support for languages Osage, Nepal Bhasa, Fulani and other 
African languages, The Bravanese dialect of Swahili, used in Somalia, The 
Warsh orthography for Arabic and Tangut, a major historic script of China. 

== Detailed Description ==
We are upgrading core libraries in Fedora for Unicode 9.0

* Updating Glibc localedata.
* Updating Lib ICU. (If upstream releases well in time)
* libunistring - This portable C library implements Unicode string types in 
three flavours: (UTF-8, UTF-16, UTF-32), together with functions for character 
processing (names, classifications, properties) and functions for string 
processing (iteration, formatted output, width, word breaks, line breaks, 
normalization, case folding and regular expressions).
* Unicode UCD 

== Scope ==
* Proposal owners: Work with upstream, file bugs and provide patches where 
required. 

* Other developers: This change will impact glibc, ICU and all applications 
that uses these libraries. Other Developers do not need to make any changes 
from their end, but they need to watch how their application behaves with 
improved localedata. We need proper testing to see that it does not break any 
application. 

* Release engineering: No work required from Release engineering.
  - List of deliverables: N/A 

* Policies and guidelines: No, this change does not required any updates to 
Policies or packaging guideline updates. 

* Trademark approval: N/A (not needed for this Change) 

[1] http://blog.unicode.org/2016/06/announcing-unicode-standard-version-90.html
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

F25 System Wide Change: SSSD fast cache for local users

[Jaroslav Reznik]

= Proposed System Wide Change: SSSD fast cache for local users =
https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers

Change owner(s):
* Stephen Gallagher 
* Jakub Hrozek 

Enable resolving all users through the sss NSS modules for better performance. 

== Detailed Description ==
SSSD ships with a very fast memory cache for a couple of releases now. 
However, using this cache conflicts with nscd's caching and nscd has been 
disabled by default. That degrades performance, because every user or group 
lookup must open the local files.

This change proposes leveraging a new "files" provider SSSD will ship in the 
next version in order to resolve also users from the local files. That way, 
the "sss" NSS module can be configured before the files module in 
nsswitch.conf and the system could leverage sss_nss caching for both local and 
remote users.

The upstream design of the files provider can be found at: [1]

Below is a mini-FAQ that lists the most common questions we've received so 
far:

Q: Does SSSD take over /etc/passwd and /etc/files?
A: No. SSSD just monitors them with inotify and copies the records into its 
cache.
 
Q: Does SSSD need to be running all the time now? What if it crashes?
A: SSSD needs to be running in order to benefit from this functionality. 
However, the nss_sss module is built in such a way that even if sssd is not 
running, nss_sss should fail over to nss_files pretty quickly (we'll quantify 
"pretty quickly" in a more scientific fashion soon) 

Q: Do I need to configure SSSD now?
A: No, we'll ship a default configuration. 

== Scope ==
* Proposal owners: Jakub Hrozek and Stephen Gallagher work on the design and 
coding 

* Other developers: The SSSD upstream will participate in code review of the 
change 

* Release engineering: None required 

* Policies and guidelines: None needed 

* Trademark approval: None needed 

[1] https://fedorahosted.org/sssd/wiki/DesignDocs/FilesProvider

___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

F25 System Wide Change: Ruby on Rails 5.0

[Jaroslav Reznik]

= Proposed System Wide Change: Ruby on Rails 5.0 =
https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_5.0

Change owner(s):
* Jun Aruga 
* Pavel Valena 
* Vít Ondruch 
* Ruby SIG 

Ruby on Rails 5.0 is the latest version of well known web framework written in 
Ruby. 

== 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.2 in 
Fedora 24 to 5.0 (latest version) in Fedora 25. 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

Full list of packages needed by Rails 5.0 to generate basic application and 
list of optional packages, required by the basic Ruby on Rails application are 
availble in the Change page. 

The lists are compiled from the result of "bundle list" and "Gemfile.lock" 
after both installing rails, and creating new Rails app.

* Other developers: Update Rails dependent packages to be working with Ruby on 
Rails 5.0 

* Release engineering: Not needed. 

* Policies and guidelines: Not needed 

* Trademark approval: N/A (not needed for this Change) 
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

F25 Self Contained Change: Golang 1.7

[Jaroslav Reznik]

= Proposed Self Contained Change: Golang 1.7 =
https://fedoraproject.org/wiki/Changes/golang1.7

Change owner(s):
* Jakub Čajka 

Rebase of Golang package to upcoming version 1.7 in Fedora 25, including 
rebuild of all dependent packages. 

== Detailed Description ==
Rebase of Golang package to upcoming version 1.7 in Fedora 25. Golang 1.7 is 
schedule to be released in Aug. Due to current nature of Go packages, rebuild 
of dependent package will be required to pick up the changes. 

== Scope ==
* Proposal owners: Rebase golang package in f25(side tag), bootstrap for 
s390x(+update golang srpm macros), help with resolving possible issues found 
during package rebuilds. 

* Other developers: fix possible issues. 

* Release engineering: Create/merge side tag.
  - List of deliverables: N/A 

* Policies and guidelines: N/A 

* Trademark approval: N/A 
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

F25 Self Contained Change: Erlang 19

[Jaroslav Reznik]

= Proposed Self Contained Change: Erlang 19 =
https://fedoraproject.org/wiki/Changes/Erlang_19

Change owner(s):
* Peter Lemenkov 
* Fedora Erlang SIG 
* Randy Barlow 
* Jeremy Cline 

== Detailed Description ==
Upgrade Erlang to version 19 which brings a lot of good stuff. Just a few 
highlights:

* A new state machine behavior - gen_statem.
* An experimental plugin to mnesia which allows using expernal storage 
solutions (leveldb, for example) - mnesia_ext.
* Cryptographic functions speedups.
* Even better dirty NIF schedulers [1].
* Experimental support for Unix Domain Sockets which opens a door for native 
Journald, systemd-notify, D-Bus implementations.

Aside from this, we plan to improve quality of Erlang and related packages. 
These are shortcomings we want to address:

* We should enable so-called dirty NIF scheduler [1] which is still disabled 
currently.
* Every daemon written in Erlang has its own logging solution which doesn't 
use neither syslog nor Journald. We should start switching them to Journald.
* We should add ability to use D-Bus via erlang-dbus library.
* Further improve Erlang Packaging Guidelines [2].

== Scope ==
* Proposal owners:
** Upgrade Erlang to the latest version (19.0.1) [3].
** We must rebuild every package which requires NIF or Driver version (listed 
below in the [[#Dependencies|Dependencies]] section) against Erlang 19.x.y.
** Every Erlang daemon's systemd unit must require epmd.socket.
** Consider allowing EPMD implementation switching. Erlang is about choice!
** We need to fill new review request for erlang-ejournald [4]
*** We have to fill new review request for erlang-lager_journald_backend [5]
** We need to fill new review request for erlang-dbus [6]
** Add another default directory to look for Erlang *.beam files.
** Upgrade outdated packages:
*** Riak [7]
 Riak has has been retired. We have to re-add it back.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines:
** We should promote officially Erlang Packaging Guidelines [2].

[1] https://medium.com/@jlouis666/erlang-dirty-scheduler-overhead-6e1219dcc7
[2] User:Peter/Erlang_Packaging_Guidelines
[3] https://bugzilla.redhat.com/1348957
[4] https://github.com/travelping/ejournald
[5] https://github.com/travelping/lager_journald_backend
[6] https://github.com/lizenn/erlang-dbus
[7] https://apps.fedoraproject.org/packages/riak
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

F25 Self Contained Change: Zend Framework 3

[Jaroslav Reznik]

= Proposed Self Contained Change: Zend Framework 3 =
https://fedoraproject.org/wiki/Changes/ZF3

Change owner(s):
*  Remi Collet  and PHP SIG 

== Detailed Description ==
See upstream annoucement: Zend Framework 3 Released! [1]

The Zend Framework is a huge set of ~60 components. The framework version 
defines a minimal set of components, and their minimal version.
Version 3 is recommend for PHP 7.0 [2] which is also part of Fedora 25.

Dropped package:

* php-zendframework-zend-version

Updated packages: (12 major versions)

* php-zendframework: 3.0.0
* php-zendframework-zend-code: 3.0.3
* php-zendframework-zend-crypt: 3.0.0
* php-zendframework-zend-eventmanager: 3.0.1
* php-zendframework-zend-hydrator: 2.2.1
* php-zendframework-zend-json: 3.0.0
* php-zendframework-zend-math: 3.0.0
* php-zendframework-zend-mvc: 3.0.1
* php-zendframework-zend-router: 3.0.2
* php-zendframework-zend-servicemanager: 3.1.0
* php-zendframework-zend-stdlib: 3.0.1
* php-zendframework-zend-test: 3.0.1

Updated Dependencies (4 major versions)

* php-di: 5.3.0
* php-ocramius-code-generator-utils: 0.4.0
* php-ocramius-generated-hydrator: 2.0.0
* php-ocramius-proxy-manager: 2.0.0

New packages (12)

* php-zendframework-zend-json-server: 3.0.0 
* php-zendframework-zend-mvc-console: 1.1.0
* php-zendframework-zend-mvc-form: 1.0.0
* php-zendframework-zend-mvc-i18n: 1.0.0
* php-zendframework-zend-mvc-plugins: 1.0.1
* php-zendframework-zend-mvc-plugin-fileprg 1.0.0
* php-zendframework-zend-mvc-plugin-flashmessenger: 1.0.0
* php-zendframework-zend-mvc-plugin-prg 1.0.0
* php-zendframework-zend-mvc-plugin-identity: 1.0.0
* php-zendframework-zend-servicemanager-di: 1.1.0
* php-zendframework-zend-stratigility: 1.2.1 
* php-zendframework-zend-xml2json: 3.0.0

Some additional optional components can be added later (especially the 
expressive new micro framework, another set of ~10 new components).

== Scope ==
* Proposal owners: Update packages and create new for additional components

* Other developers: Test their applications 
* 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) 

[1] https://framework.zend.com/blog/2016-06-28-zend-framework-3.html
[2] https://fedoraproject.org/wiki/Changes/php70
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

F25 Self Contained Change: IBus Emoji Typing

[Jaroslav Reznik]

= Proposed Self Contained Change: IBus Emoji Typing  =
https://fedoraproject.org/wiki/Changes/IBus_Emoji_Typing

Change owner(s): 
* Takao Fujiwara 

The IBus core will provide the Emoji Unicode typing with the IBus XKB engines. 

== Detailed Description ==
IBus has already provided Unicode hex codes tying with Ctrl-Shift-u and now we 
think the similar implementation for the Emoji typging. With IBus XKB engines, 
Emoji typing will be provided with the Emoji annotations [1] following Ctrl-
Shift-e. 

== Scope ==
* Proposal owners:
 - IBus core provide the dictionary of the Emoji typing.
 - IBus XKB engines load the Emoji dictionary. 

* Other developers: N/A 

* Release engineering: N/A
 - List of deliverables: N/A 

* Policies and guidelines: N/A 

* Trademark approval: N/A 

[1] http://unicode.org/emoji/charts/index.html#col-annotations
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

F25 System Wide Change: Automatic Provides for Python RPM Packages

[Jaroslav Reznik]

= Proposed System Wide Change: Automatic Provides for Python RPM Packages =
https://fedoraproject.org/wiki/Changes/
Automatic_Provides_for_Python_RPM_Packages

Change owner(s):
* Tomas Orsava 
* Miro Hroncok 
* Email: python-ma...@redhat.com

Upon building Python packages containing packaging metadata, RPM will 
automatically detect the standardized name of the software (i.e. dist name, 
name on PyPI) in the canonical format [1] and create a virtual Provides tag 
with the value pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python 
version. RPM may also detect dependencies of the software from the metadata 
and automatically require them using the same syntax. 

== Detailed Description ==
If during the building of a Python package RPM encounters .egg-info, .egg-link 
or .dist-info files (provided in Python Wheels and Eggs), it will read the 
standardized name of the software (i.e. dist name, name on PyPI) in the 
canonical format and create a virtual Provides tag with the value 
pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python version. Note that 
the canonical format can differ slightly from the name displayed, for example, 
on PyPI.[1]

RPM will also detect dependencies of the software from the aforementioned 
metadata files and automatically require them using the format 
pythonX.Ydist(). However, because these files don't always contain the full 
list of requirements (which are either in setup.py or requirements.txt), the 
dependency generator will not be conclusive.

All Python packages will need to be rebuilt so that the virtual Provides tags 
are generated and can be used by users, scripts and the requires generator. 

== Scope ==
* Proposal owners: Prepare a draft for the Fedora Packaging Guidelines for 
Python

* Maintainers of the RPM package: Backport the functionality from upsteram to 
Fedora. — Already done thanks to Florian Festi [2] 

* Release engineering: Targeted rebuild of Python packages. Ticket [3].

* List of deliverables: All Fedora deliverables will be affected, but only in 
a very minor way that in no way jeopardizes their delivery.

* Policies and guidelines: Fedora Packaging Guidelines for Python need to be 
updated after the implementation so users know how to take advantage of the 
change.

* Trademark approval: Not needed for this Change

[1] https://fedoraproject.org/wiki/Changes/
Automatic_Provides_for_Python_RPM_Packages#cite_note-canonical-0
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

REMINDER: Submission deadline for System Wide Changes of Fedora 25 next Tuesday!

[Jaroslav Reznik]

Hi everyone!

The submission deadline for System Wide Changes of Fedora 25 [1] is
coming pretty soon - just in one week from today on July 5th. Alpha release of
Fedora 25 is planned on August 23rd with Change Checkpoint: Completion
deadline on July 26th (that means changes are testable)

Please, submit your System Wide Changes by this deadline. As the
deadline applies for System Wide Changes only, it is always good to
have most of Self Contained Changes proposed as well.

In case you'll need any help with your Change proposals, feel free to
contact me. I'm covering for Jan Kurik during his holidays.

Thanks
Jaroslav

[1] https://fedoraproject.org/wiki/Releases/25/Schedule
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

Fedora 22 Final status is Go, release on May 26, 2015

[Jaroslav Reznik]

At the Fedora 22 Final Go/No-Go Meeting #2 that just occurred, it was
agreed to Go with the Fedora 22 Final by Fedora QA, Release Engineering
and Development.

Fedora 22 Final will be publicly available on Tuesday, May 26, 2015.

Meeting details can be seen here:
Minutes: http://bit.ly/1Bh2pH1
Log: http://bit.ly/1HzMI5g

Thank you everyone for a great job, sleepless nights validating TCs,
RCs, fixing bugs, composing stuf and everything else needed for 
smooth releases. Amazing last three years wrangling releases for me! 

Jaroslav
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 22 Final is No-Go but second sign-off try is tomorrow

[Jaroslav Reznik]

Hi!
Today at Fedora 22 Final Go/No-Go meeting it was decided that Fedora 22
Final is No-Go. More details in meeting minutes [1].

As both bugs we accepted as blocker bugs today are already fixed and RC3
compose is requested, we will try to sign-off the final release tomorrow.
If you are willing to help with release validation, follow standard
channels for RC3 announcement. 

The next Go/No-Go meeting is on Friday, May 22 17:00 UTC #fedora-meeting-2
channel.

[1] http://bit.ly/1FFcJ2G

___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 22 Final Release Readiness Meeting :: Thursday, May 21, 19:00 UTC

[Jaroslav Reznik]

Fedora 22 Final Release Readiness Meeting.

date: 2015-05-21 place: irc.freenode.net in #fedora-meeting-2
time: 19:00 UTC (3 PM EDT, 12 noon PDT, 21:00 CEST)

This Thursday, May 21, we will meet to make sure we are coordinated
and ready for the Final release of Fedora 22 on Tuesday, May 26, 2015.
Please note that this meeting will occur on May 21 even if the
release is delayed at the Go/No-Go meeting on the same day two hours
earlier.

You may received this message several times, but I was asked to open this
meeting to the teams and I'll also hope this will raise awareness and more
team representatives will come to this meeting. This meeting works best
when we have representatives from all of the teams. We also have a badge!

Jaroslav
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 22 Final Go/No-Go Meeting, Thursday, May 21 @ 17:00 UTC

[Jaroslav Reznik]

Join us on irc.freenode.net in #fedora-meeting-2 for this important
meeting, wherein we shall determine the readiness of the Fedora 22.

Thursday, May 21, 2015 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST)

"Before each public release Development, QA and Release Engineering meet
to determine if the release criteria are met for a particular release.
This meeting is called the Go/No-Go Meeting."

"Verifying that the Release criteria are met is the responsibility of
the QA Team."

For more details about this meeting see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting

In the meantime, keep an eye on the Fedora 22 Final Blocker list:
http://qa.fedoraproject.org/blockerbugs/milestone/22/final/buglist

We don't have RC yet but seem like we're very close to it - testing
heroes will be needed to cover all required tests by this meeting.

Jaroslav

___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 22 Beta status is Go, release on April 21, 2015

[Jaroslav Reznik]

At the Fedora 22 Beta Go/No-Go Meeting #2 that just occurred, it was
agreed to Go with the Fedora 22 Beta by Fedora QA, Release Engineering
and Development.

Fedora 22 Beta will be publicly available on Tuesday, April 21, 2015.

Meeting details can be seen here:
Minutes: http://bit.ly/1HxYmvU
Log: http://bit.ly/1IiY3TU

THX EVRYONE!

Jaroslav

___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 22 Beta Go/No-Go Meeting #2, Thursday, April 16 @ 17:00 UTC

[Jaroslav Reznik]

Join us on irc.freenode.net in #fedora-meeting-2 for this important
meeting, wherein we shall determine the readiness of the Fedora 22 Beta.

Thursday, April 16, 2015 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST)

"Before each public release Development, QA and Release Engineering meet
to determine if the release criteria are met for a particular release.
This meeting is called the Go/No-Go Meeting."

"Verifying that the Release criteria are met is the responsibility of
the QA Team."

For more details about this meeting see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting

In the meantime, keep an eye on the Fedora 22 Beta Blocker list:
http://qa.fedoraproject.org/blockerbugs/milestone/22/beta/buglist

Jaroslav
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 22 Beta to slip by one week

[Jaroslav Reznik]

Today at Go/No-Go meeting it was decided to slip Fedora 22 Beta release
by one week due to unresolved blocker bug [1]. More details in meeting
minutes [2].

As a result, ALL MAJOR MILESTONES, and their dependent tasks, will be
pushed out by one week [3].

The next Go/No-Go meeting is on Thursday, Apr 16, 17:00 UTC at
#fedora-meeting-2 channel on FreeNode.

Jaroslav

[1] http://qa.fedoraproject.org/blockerbugs/milestone/22/beta/buglist
[2] http://bit.ly/1NX92nq
[3] https://fedoraproject.org/wiki/Releases/22/Schedule

___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 22 Beta Go/No-Go Meeting, Thursday, April 09 @ 17:00 UTC

[Jaroslav Reznik]

Join us on irc.freenode.net in #fedora-meeting-2 for this important
meeting, wherein we shall determine the readiness of the Fedora 22 Beta.

Thursday, April 09, 2015 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST)

"Before each public release Development, QA and Release Engineering meet
to determine if the release criteria are met for a particular release.
This meeting is called the Go/No-Go Meeting."

"Verifying that the Release criteria are met is the responsibility of
the QA Team."

Release Candidate (RC) availability and good QA coverage are prerequisites
for the Go/No-Go meeting. We don't have RC yet, the list of blocker bugs
does not look so scary now but there's still quite a lot of work ahead of
us. If you have any bug on the list, please help us with Beta release.
If we won't be ready by Thursday, we will use this meeting to review
blockers and decide what to do next.

For more details about this meeting see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting

In the meantime, keep an eye on the Fedora 22 Beta Blocker list:
http://qa.fedoraproject.org/blockerbugs/milestone/22/beta/buglist

Jaroslav

___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 22 Beta Release Readiness Meeting :: Thursday, April 09, 19:00 UTC

[Jaroslav Reznik]

Fedora 22 Beta Release Readiness Meeting.

date: 2015-04-09 place: irc.freenode.net in #fedora-meeting-2
time: 19:00 UTC (3 PM EDT, 12 noon PDT, 21:00 CEST)

This Thursday, April 09, we will meet to make sure we are coordinated
and ready for the Beta release of Fedora 22 on Tuesday, April 14, 2015.
Please note that this meeting will occur on April 09 even if the
release is delayed at the Go/No-Go meeting on the same day two hours
earlier.

You may received this message several times, but I was asked to open this
meeting to the teams and I'll also hope this will raise awareness and more
team representatives will come to this meeting. This meeting works best
when we have representatives from all of the teams. We also have a badge!

Jaroslav

___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 22 Change Checkpoint: 100% Code Complete Deadline in two weeks

[Jaroslav Reznik]

Hi!
This is a reminder, that Fedora 22 Change Checkpoint: 100% Code
Complete Deadline is coming in two weeks. It's important milestone
as for this release, we'd like to strictly adhere to schedule and 
contingency plan may be put into effect for Changes that miss
this deadline. As always, the list will be shared with FESCo. 

2015-03-31 Change Checkpoint: 100% Code Complete Deadline
2015-03-31 Fedora 22 Beta Freeze

Expected bug state is ON_QA - Change has to be code complete and
can be tested in the Beta release (optionally by Fedora QA).

Please make sure to update state of yours Change(s) bug(s) on time.
In case of any problems, let me know, we will try to find working
solution.

http://fedoraproject.org/wiki/Releases/22/Schedule

Expect more nagging in Change bug(s) between now and Beta Freeze ;-).

Thanks
Jaroslav
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: Disabled Repositories Support

[Jaroslav Reznik]

= Proposed Self Contained Change: Disabled Repositories Support =
https://fedoraproject.org/wiki/Changes/DisabledRepoSupport

Change owner(s): Richard Hughes 

The Software tool and PackageKit now support disabled repositories to help 
users locate software in additional repositories which are not meant to be 
enabled by default. 

* This Change is announced after the Change Submission Deadline as an
exception to the process. May not be approved for proposed Fedora release. *

== Detailed Description ==
This feature aims to reduce the technical hurdles for users and developers to 
locate software packaged for a distribution, but which needs to be clearly 
identified as not officially included (or possibly sanctioned) by that 
distribution.

When Software (via PackageKit) queries a repo definition that contains the line 
enabled_metadata=1, even if the repo is disabled, it will download repodata. 
This feature allows a user to locate software in response to a search. If the 
user wants to install the software, she receives a dialog with information 
that the repo must be enabled to satisfy the request, and if relevant, 
information about the nature of the software (for instance, if it is non-
libre).

N.B. This feature does not currently operate in Fedora, since no such repo 
definitions are currently shipped. However, the feature could be used by 
remixers, and in the future in Fedora in the event of a policy change. 

== Scope ==
* Proposal owners: Include enhancements in gnome-software/PackageKit (done)
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
** Note: For this feature to be used in Fedora requires an additional *-
release-extra package to ship disabled repo definition 
* Policies and guidelines: N/A (not a System Wide Change)
** Note: For this feature to be used in Fedora requires clearer approval from 
FESCo and the Council 

___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 22 Alpha status is Go, release on March 10, 2015

[Jaroslav Reznik]

At the Fedora 22 Alpha Go/No-Go Meeting #2 that just occurred, it was
agreed to Go with the Fedora 22 Alpha by Fedora QA, Release Engineering
and Development.

Fedora 22 Alpha will be publicly available on Tuesday, March 10, 2015.

Meeting details can be seen here:
Minutes: http://bit.ly/17Y8Je5
Log: http://bit.ly/1Em9JXo

Thanks everyone! It's pretty solid Alpha release and on time :).
Jaroslav
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 22 Alpha is No-Go but second sign-off try is tomorrow

[Jaroslav Reznik]

Hi!
Today at Fedora 22 Alpha Go/No-Go meeting it was decided that Fedora 22
Alpha is No-Go as no release candidate is available. More details in
meeting minutes [1].

But as we're looking pretty good and RC1 compose is undergoing right
now (estimate delivery is 3:00 UTC on Friday), we decided to try the
seconnd Go/No-Go meeting tomorrow. Earlier to give rel-eng chance to
prepare the content for mirroring.

The next Go/No-Go meeting is on Friday, Mar 06 8:30 AM CST/14:30 UTC
#fedora-meeting-2 channel.

[1] http://bit.ly/1H0LMmC
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: Xfce412

[Jaroslav Reznik]

= Proposed Self Contained Change: Xfce412 =
https://fedoraproject.org/wiki/Changes/Xfce412

Change owner(s): Kevin Fenzi , Mukundan Ragavan 
, Christoph Wickert 

Update Xfce to the new 4.12 release with a number of bugfixes and improvements. 

* This Change is announced after the Change Submission Deadline as an
exception to the process. May not be approved for proposed Fedora release. *

== Detailed Description ==
Upstream Release Date: 2015-02-28

This release will have a number of bugfixes and improvements, but no radical 
changes. 

== Scope ==
* Proposal owners: Update Xfce packages. Update Xfce spin with any needed 
adjustments. 
* 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) 
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 22 Alpha Go/No-Go Meeting, Thursday, March 05 @ 17:00 UTC

[Jaroslav Reznik]

Join us on irc.freenode.net in #fedora-meeting-2 for this important
meeting, wherein we shall determine the readiness of the Fedora 22 Alpha.

Thursday, March 05, 2015 17:00 UTC (12 noon EST, 9 AM PST, 18:00 CET)

"Before each public release Development, QA and Release Engineering meet
to determine if the release criteria are met for a particular release.
This meeting is called the Go/No-Go Meeting."

"Verifying that the Release criteria are met is the responsibility of
the QA Team."

Release Candidate (RC) availability and good QA coverage are prerequisites
for the Go/No-Go meeting. We don't have RC yet as the list of accepted
blockers is still pretty long. If you have any bug on the list, please
help us with Alpha release. If we won't be ready by Thursday, we will
use this meeting to review blockers and decide what to do.

For more details about this meeting see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting

In the meantime, keep an eye on the Fedora 22 Alpha Blocker list:
http://qa.fedoraproject.org/blockerbugs/milestone/22/alpha/buglist

Jaroslav
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 22 Alpha Release Readiness Meeting :: Thursday, March. 05, 19:00 UTC

[Jaroslav Reznik]

Fedora 22 Alpha Release Readiness Meeting.

date: 2015-03-05 place: irc.freenode.net in #fedora-meeting-2
time: 19:00 UTC (2 PM EST, 11 AM PST, 20:00 CET)

This Thursday, March 05, we will meet to make sure we are coordinated
and ready for the Alpha release of Fedora 22 on Tuesday, March 10, 2015.
Please note that this meeting will occur on March 05 even if the
release is delayed at the Go/No-Go meeting on the same day two hours
earlier.

You may received this message several times, but I was asked to open this
meeting to the teams and I'll also hope this will raise awareness and more
team representatives will come to this meeting. This meeting works best
when we have representatives from all of the teams. We also have a badge!

Jaroslav
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 22 Bugzilla Rawhide rebase

[Jaroslav Reznik]

Greetings,
This e-mail is intended to inform you about the upcoming Bugzilla changes 
happening March 3, 2015 (Rawhide bug rebase) and what you need to do, if 
anything.

We will be automatically changing the version for most rawhide bugs to Fedora 
22.
This will result in regular bugs reported against rawhide during the Fedora 22
development cycle being changed to version ‘22' instead of their current
assignment, ‘rawhide’.  This is to align with the branching of Fedora 22 from
rawhide and to more accurately tell where in the lineage of releases the bug was
last reported.

Note that this procedure does not apply to bugs that are open for the ‘Package
Review’ component or bugs that have the ''FutureFeature'' or ''Tracking'' 
keywords
set. These will stay open as rawhide bugs indefinitely.

If you do not want your bugs changed to version ‘22‘, add the ''FutureFeature''
keyword. If you need help changing a large amount of bugs manually, we’d be glad
to help.

The process was re-approved by FESCo 
https://fedorahosted.org/fesco/ticket/1096. 

Jaroslav

___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: LXQt

[Jaroslav Reznik]

= Proposed Self Contained Change: LXQt =
https://fedoraproject.org/wiki/Changes/LXQt

Change owner(s):  Helio Chissini de Castro , 
Christoph Wickert 

Package the LXQt desktop Environment for Fedora.

* This Change is announced after the Change Submission Deadline as an
exception to the process. May not be approved for proposed Fedora release. *

== Detailed Description ==
LXQt [1] is the Qt port and the upcoming version of LXDE [2], the Lightweight 
Desktop Environment. It is the product of the merge between the LXDE-Qt and 
the Razor-qt projects: A lightweight, modular, blazing-fast and user-friendly 
desktop environment. 

== Scope ==
* Proposal owners: LXQt packages already approved and in the system.
* 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) 

[1] http://lxqt.org/
[2] https://fedoraproject.org/wiki/LXDE
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Legacy implementations of the Java platform in Fedora

[Jaroslav Reznik]

= Proposed System Wide Change: Legacy implementations of the Java platform in 
Fedora =
https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora

Change owner(s): Jiri Vanek 

Currently Fedora supports one main Java runtime and Java Development Kit (JDK) 
and from time to time one future JDK as a tech preview. This change should be 
set of rules, which will enable community to maintain legacy JDKs. Please 
note, people are bugging main JDK maintainers pretty often with this, and to 
allow them to maintain legacy JDKs is a step in right direction.

* This Change is announced after the Change Submission Deadline as an 
exception to the process. May not be approved for proposed Fedora release. *

== Detailed Description ==
This is no real work proposal. The result of this proposal is set of rules, 
which will allow community maintainers to pack any legacy jdk and will be 
ensuring that this JDKs will not conflict by any other JDK and will smoothly 
integrate to system. The results are summarized here, and pledged for 
discussion until final resolution is done.

=== Proposed rules ===
0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. 
This must remain clear'''

 option one - introducing new packages - preferred 
1. main jdk is proclaimed as dead as it was until now.  The new jdk is derived 
as new package prviousName-legacy
 1. so from killed java-1.7.0-openjdk will become new package java-1.7.0-
openjdk-legacy
 2. next main jdk do Obsolete previous one as usually
2. new package '''must''' not do any virtual provides (aka java,java-devel)... 
(protection against random pull by as dependence)
 1. it provides only itself by name
3 its priority '''must''' be kept on less digits (right now it would be 5) 
then main jdk (protection against winning in alternatives after update)
 1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 
are '''mandatory'''
4. at least one of the main-jdk's members '''must''' be set as comaintainer 
(to watch the commits and save the world if necessary)
5. new  package '''should''' to follow both original jdk (ideally not change 
at all (except source updates and necessary)) and current main jdk as close as 
possibly
 1. here it requires some common sense and a lot of testing if integration 
with system is as expected
6. as it is generally not new package, the review process '''should''' be only 
formal - to know maintainer and to create cvs repo 
 1. this is quite important, otherwise the new maintainer can become really 
frustrated, and we are forcing the "dead" package over"orpahned" so the full 
review (especially in alignment with rule 5) really should not be forced.
 2. on the contrary, rules agreed here '''must''' be checked.  (even the 
number 5)
7. all depending packages '''must''' keep requiring java-headless or java (and 
BuildRequires java-devel). Requirements on any exact jdk - or even worse on 
any exact legacy jdk are forbidden and needs FESCO exception. 

This option is forcing maintainers to fight with the name x current setup of 
alternatives. However, the work should be minimal. But it makes the update 
path pretty clear and it keeps users well protected against legacy jdk.

 option two - orphaning legacy jdks and ensure update path 
1. main JDK is only orphaned when new main JDK landed
 1. it do '''not''' Obsolate previous jdk
2. other rules (2-7) are same

This is making life of legacy JDK maintainers a bit simpler. But I don't know, 
how to ensure proper "obsolete" implementation in this case.

== Scope ==
* Proposal owners: are responsible for initial setup of those guidelines. 
The FESCO, the owners and pssible legacy JDKs maintainers have to agree on 
those rules. New legacy JDK can be then added anytime in Fedora lifecycle.
* Other developers: no developers
* Release engineering: in ideal case, no release engineer needed  
* Policies and guidelines: The proposal may split to proposal and "Legacy JDKs 
in Fedora guidelines" pages 
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 22 Changes Completion deadline in one week - 2015-02-24

[Jaroslav Reznik]

Greetings!
Fedora 22 Change Checkpoint: Completion deadline (testable) is in
one week - 2015-02-24 [1] and we're getting closer to this date.

Other important milestones are scheduled for this date:
* Alpha Freeze
* Software String Freeze
* Bodhi activation point

At this point, all accepted changes should be substantially complete,
and testable. Additionally, if a change is to be enabled by default,
it must be so enabled at Change Completion deadline.

Change tracking bug should be set to the MODIFIED state to indicate
it achieved completeness.

Fedora 22 is strictly time based release and we want to adhere to the
schedule. Incomplete and non testable Changes will be reported to 
FESCo for 2015-02-25 meeting.  Contingency plan for System Wide Changes,
if planned for Alpha (or in case of serious doubts regarding Change
completion), will be activated.

[1] https://fedoraproject.org/wiki/Releases/22/Schedule

Jaroslav
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

FESCo Elections results

[Jaroslav Reznik]

Greetings, all!

The elections for FESCo - January 2015 have concluded, and the results
are shown below.

A total of 283 ballots were cast, meaning a candidate could accumulate
up to 1981 votes (283 * 7).

The results for the elections are as follows:

  # votes |  name
- +--
1427  | Kevin Fenzi
1247  | Adam Jackson
 919  | Tomas Hozza
 818  | Parag Nemade
 617  | Debarshi Ray
- +--
 540  | Alberto Ruiz
 441  | David King

Number of voters283
Number of votes 1204
Maximum of votes1981

Congratulations to the winning candidates, and thank you all
candidates for running this elections!

___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Cast your vote - FESCo elections closes today!

[Jaroslav Reznik]

Hi everyone,
this is a friendly reminder that today is the last chance to vote
in the FESCo elections - great opportunity for everyone to steer 
future Fedora's development. Voting closes promptly at 2015-02-03
23:59 UTC.

Go to https://admin.fedoraproject.org/voting/ and cast your vote!

If you're still undecided, we have two new interviews available:
* Alberto Ruiz http://bit.ly/18JS1zZ
* Adam Jackson http://bit.ly/1DsyqgK

(And it's worth reading even you already voted)

The other Fedora Magazine interviews:
* Kevin Fenzi http://bit.ly/16r7NPl
* Tomas Hozza http://bit.ly/1Cspprd
* Debarshi Ray http://bit.ly/1z7IasJ
* Parag Nemade http://bit.ly/1HRSI9T
* David King http://bit.ly/1K6ZshQ

Jaroslav
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Python 3 Migration Improvements

[Jaroslav Reznik]

= Proposed System Wide Change: Python 3 Migration Improvements =
https://fedoraproject.org/wiki/Changes/Python_3_Migration_Improvements

Change owner(s): Slavek Kabrda , Matej Stuchlik 
, Miro Hroncok 

Since Changes/Python_3_as_Default was retargeted for F23 mostly due to 
uncertainty about DNF and Anaconda porting status, this change aims to reflect 
current progress of Python 3 readiness in Fedora and sum up goals for Fedora 
22. 

== Detailed Description ==
Python 3 is the next generation of Python programming language. It is 
currently mature and stable, since it has been under active development for 
more than six years - version 3.0 was released in December 2008, current 
latest stable version is 3.4.2 released in October 2014. The main reason to 
switch to Python 3 as the default implementation is that Python 2 is in 
maintenance mode, thus only bugfixes and security fixes are accepted upstream. 
Further reasons are mentioned in the Benefit to Fedora section [1].

Originally, Fedora 22 was supposed to be shipped with Python 3 as Default [2]. 
There was however rising concern about Python 3 readiness of some key 
components - mostly Anaconda and DNF. Due to this fact FESCo decided to 
retarget Python 3 as Default for Fedora 23, hence also stopping mass bug filing 
for rebuilds with Python 3 for Fedora 22. As a result, most packages in Fedora 
22 will still use Python 2 and at this state it's not desirable to pronounce 
Python 3 "the default Python".

Since a massive amount of work has been done towards Python 3 migration, it 
still makes sense to use as much of this effort for Fedora 22 as possible. See 
Scope for overview of changes proposed for Fedora 22 by this Change. 

== Scope ==
Goals of this change are:
* to switch as many packages present on Fedora Workstation LiveCD to Python 3 
(the Workstation LiveCD already ships both Python interpreters, so switching 
more packages to Python 3 won't increase size)
* to make minimal cloud image Python 2 free
* to make Fedora atomic host Python 2 free
Note: this Change intentionally doesn't talk about switching or not switching 
Anaconda and DNF to Python 3. These are left up to broader community consensus 
and don't prevent this change from happening.

There are basically two types of packages that need to undergo the conversion:
* "libraries" - Python extension modules and libraries that provide Python 
bindings - assuming that there is upstream support, these can receive python3- 
subpackage anytime without any damage to Fedora; we can then just utilize this 
subpackage when switching to Python 3 (instead of using current python- 
subpackage).
* "applications" - Packages that build with some sort of embedded Python 
support, like gdb, or Rhythmbox with its plugins. In these cases, it makes no 
sense to do a python3- subpackage, since the whole package would need to be 
duplicated (e.g. python3-gdb). These packages should be built with Python 3 in 
Fedora 22 rawhide as soon as possible.

The packages that should be rebuilt with Python 3 are:
* abrt 
* authconfig https://bugzilla.redhat.com/show_bug.cgi?id=984907
* bind https://bugzilla.redhat.com/show_bug.cgi?id=1186791
* caribou https://bugzilla.redhat.com/show_bug.cgi?id=1186792
* cloud-init https://bugzilla.redhat.com/show_bug.cgi?id=1024357
* environment-modules https://bugzilla.redhat.com/show_bug.cgi?id=1184979
* gdb https://bugzilla.redhat.com/show_bug.cgi?id=1014549
* gettext
* gnome-abrt
* heat-cfntools https://bugzilla.redhat.com/show_bug.cgi?id=1024368
* hplip
* gupnp
* nfs-utils
* pcp
* pidgin
* setroubleshoot https://bugzilla.redhat.com/show_bug.cgi?id=1125209
* sos https://bugzilla.redhat.com/show_bug.cgi?id=1014595
* telepathy-gabble
* totem

This list is provided here because the tracking bug of Python 3 as Default 
contains also packages needed for DNF and Anaconda, which are not essential to 
this effort. These BZs will be attached to a new tracker bug once it's created.

Note that Python packaging guidelines have already been [3] to prefer Python 3 
over Python 2 for newly introduced applications since Fedora 22.

== Contingency Plan ==
* Contingency mechanism: None needed. Packages that will be ready will be 
built with Python 3, the rest will be ported in next release.
* Contingency deadline: Software string freeze
* Blocks release? No

[1] 
https://fedoraproject.org/wiki/Changes/Python_3_Migration_Improvements#Benefit_to_Fedora
[2] https://fedoraproject.org/wiki/Changes/Python_3_as_Default
[3] 
https://fedoraproject.org/w/index.php?title=Packaging%3APython&diff=402016&oldid=400811
 
changed
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

FESCo elections are open

[Jaroslav Reznik]

Greetings,
FESCo elections are now open and we're looking for five new
committee members. Elections closes promptly at 23:59 UTC
on February 3rd. Don't forget to vote!

To cast your vote, go to:
https://admin.fedoraproject.org/voting

Read more about Fedora elections at

  https://fedoraproject.org/wiki/Elections

and about the new FESCo at

  http://fedoraproject.org/wiki/Development/SteeringCommittee

We use range voting in this process — vote for as many or as
few candidates as you like on a sliding scale.

Note: we were planning Env and Stacks WG elections too but
as number of candidates was the same as open seats, Env and
Stacks group decided not to run elections this time and
accept all candidates as committee members. See the announce-
ment from Honza Horak.

The Fedora Magazine interviews got delayed as we were waiting
for more questions being asked from the community. If you
need it to make your decision, please check magazine later. 

Jaroslav 

___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

FESCo Elections Questionnaire - questions needed

[Jaroslav Reznik]

Hi everyone,
Elections Questionnaire needs more questions for Fedora Magazine
interviews! If you have anything you'd like to ask candidates to
FESCo, add it to the wiki today.

http://fedoraproject.org/wiki/Elections/Questionnaire 

Thanks
Jaroslav
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: Vagrant

[Jaroslav Reznik]

= Proposed Self Contained Change: Vagrant =
https://fedoraproject.org/wiki/Changes/Vagrant

Change owner(s): Josef Stribny 

Provide Vagrant http://www.vagrantup.com/ with the libvirt provider
as a default. 

== Detailed Description ==
Vagrant is an automation tool used to manage development environments
using virtualization and configuration management tools. It allows
developers and teams to work on their projects and test them in an
environment similar to production. Historically, Vagrant had a 
dependency on VirtualBox, but the newer versions have a plugin system 
allowing it to work with other virtualization technologies, including 
libvirt. The plan is to package Vagrant with the support for libvirt 
(coming as vagrant-libvirt plugin) replacing VirtualBox as a default 
provider. 

== Scope ==
* Proposal Owners: Initial work has been done in for Vagrant on F20 
in a Copr repository. Patches and quick fixes should be cleaned up 
or revisited. Also we need to depend on newer version of libvirt 
through rubygem-fog. Some commits for that are already in upstream 
repositories for vagrant-libvirt and fog. See upstream issue for 
details. 

* 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) 
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: qtile

[Jaroslav Reznik]

= Proposed Self Contained Change: qtile =
https://fedoraproject.org/wiki/Changes/qtile

Change owner(s): John Dulaney  

qtile is a tiling window manager written in python. More can be
found at the project's website [1].

== Detailed Description ==
Once qtile 0.9 is released upstream, package it for Fedora.
All of the dependencies are already in Rawhide as of this writing. 

== Scope ==
* Proposal owners: Work with upstream to get releae out and then package for 
Fedora
* 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) 

[1] http://www.qtile.org/
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: Tunir

[Jaroslav Reznik]

= Proposed Self Contained Change: Tunir =
https://fedoraproject.org/wiki/Changes/tunir

Change owner(s): Kushal Das 

Tunir is a self contained CI Continuous Integration [1] which will be used to 
test Fedora Cloud images nightly. This tool can be used separately by any 
developer in their Fedora 21 system to run/test their local tests/jobs. 

== Detailed Description ==
Tunir is a very simple CI system written keeping Fedora Cloud images at mind. 
At the same time it is generic enough to be used by anyone to configure and run 
jobs/tests in their local system. We will be able to track the status of 
nightly cloud builds, we can also keep track other changes like, the 
dependencies pulled in, or the overall size of the images. The same tool can 
used as a self contained CI system by any Fedora user to run their own tests 
locally. The tool has a minimal dependency and very simple to configure and 
maintain.

This tool right now can create vm(s) based on cloud images (without needing an 
actual cloud), or can run the tests in a bare metal box, or it can even create 
jobs inside Docker containers.

Example:

  $ sudo tunir --job dockerjob --stateless

The above command will run a stateless job named "dockerjob", it will not save 
the result into any database as it is a stateless run. 

== Scope ==
* Proposal owners: kushal...@gmail.com to work on tunir 
* 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) 

[1] http://en.wikipedia.org/wiki/Continuous_integration
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: Local Test Cloud

[Jaroslav Reznik]

= Proposed Self Contained Change: Local Test Cloud =
https://fedoraproject.org/wiki/Changes/Local_Test_Cloud

Change owner(s): Mike Ruckman 

testCloud [1] is a small tool to download and boot cloud images locally. 

== Detailed Description ==
testCloud was created because manually booting a cloud image locally can be a 
pain. It handles downloading the image, spoofing cloud-init metadata as well as 
providing an ssh_config to easily connect to the booted instance. What was 
usually several different steps to get an image to boot locally is now just 
one:

 python testCloud.py 

It currently supports both the Fedora Cloud Base as well as the Atomic host 
image.

Note: testCloud will likely change names in the near future. 

== Scope ==
* Proposal owners: Mike Ruckman, Kushal Das to implement proposed change 
* 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) 

[1] https://github.com/Rorosha/testCloud
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Vagrant Box for Fedora Atomic and Fedora Cloud

[Jaroslav Reznik]

= Proposed System Wide Change: Vagrant Box for Fedora Atomic and Fedora Cloud 
=
https://fedoraproject.org/wiki/Changes/Vagrant_Box_Atomic

Change owner(s): Joe Brockmeier , Ian McLeod 
, Langdon White 

To produce Vagrant boxes based on the Fedora Atomic Host and Fedora Cloud 
flavors so that users can easily work with Fedora in the Vagrant environment. 

== Detailed Description ==
Vagrant is a tool for building and distributing development environments. 
Vagrant boxes can easily be used on a number of local virtualization platforms 
such as VirtualBox, VMware, via AWS or OpenStack, or with other platforms. 
Vagrant is used on Linux, Mac OS X, and Microsoft Windows and would present 
Fedora with an opportunity to reach a larger developer audience than it 
currently does.

Many developers prefer to work with Vagrant [1] for their development work, 
using Vagrant to lower their development setup time, increase productivity, 
and avoid having to specifically install an OS each time they wish to use it 
for development.

A number of people have produced unofficial Vagrant boxes, but the Fedora 
project does not currently produce an "official" Vagrant box for consumption. 
We 
would like to close the gap here and offer Vagrant users easy-to-consume Fedora 
22 Atomic and Cloud flavored Vagrant boxes. 

== Scope ==
* Proposal owners:
** Provide a kickstart file and additional definition for the Vagrant Boxes.
** Provide scripts and patches for Koji to generate Vagrant Boxes.
** Encourage testing of the new Vagrant Boxes by the rest of the Cloud Working 
Group.

* Other developers:
** Encourage other Fedora developers to make use of the Fedora Vagrant Boxes 
for their own development work.
** Ensure that Vagrant is packaged for Fedora 22.

* Release engineering:
** Would need to work with owners of this proposal to add needed features to 
Koji, and add Vagrant Boxes to list of output formats required for release.

* Policies and Guidelines:
** No known impact.

== Contingency Plan ==
If feature is incomplete by Fedora 22 beta, it would be pulled from the 
release. No contingency necessary for fallback as this does not exist in 
Fedora 21.

* Contingency deadline: Beta
* Blocks release? No
* Blocks product? No 

[1] https://www.vagrantup.com/
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Bare Metal Installer for Fedora Atomic Host

[Jaroslav Reznik]

= Proposed System Wide Change: Bare Metal Installer for Fedora Atomic Host =
https://fedoraproject.org/wiki/Changes/Bare_Metal_Atomic

Change owner(s): Joe Brockmeier , Ian McLeod 


To produce a bare metal installer suitable for installing Fedora Atomic Host 
22 on "bare metal" (e.g., directly on a server rather than running on top of 
some kind of cloud or virtualization). 

== Detailed Description ==
In Fedora 21 we shipped Fedora Atomic Host as an AMI for use in Amazon EC2, 
and as a qcow2 suitable for use with OpenStack, KVM, etc.

For Fedora 22 we wish to expand the coverage of Fedora Atomic Host to make it 
installable on "bare metal" so users are able to run Atomic Host directly on a 
server, workstation, etc. without the need for a cloud or virtualzation layer 
underneath the host. 

== Scope ==
* Proposal owners: Work with rel-eng to add bare metal support. The patches 
should be in Anaconda already, it should mostly be a matter of producing the 
builds via Koji. 

* Other developers: May require some coordination with Anaconda folks. 

* Release engineering: Work with Cloud Working Group to turn on support for 
bare metal builds, add bare metal to regularly produced builds. 

* Policies and guidelines: No obvious impact.

== Contingency Plan ==
* Contingency mechanism: If not ready, will not ship for Fedora 22. 
* Contingency deadline: Beta freeze. 
* Blocks release? No. 
* Blocks product? No.  
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: GNOME 3.16

[Jaroslav Reznik]

= Proposed System Wide Change: GNOME 3.16 =
https://fedoraproject.org/wiki/Changes/GNOME3.16

Change owner(s): Kalev Lember 

Update GNOME to the latest upstream release, 3.16.

== Detailed Description ==
The new features for 3.16 include:

* Notification redesign in gnome-shell [1]
* Improvements in nautilus UI [2]
* New games: gnome-2048 and gnome-taquin
* Improved GTK+ and gnome-shell themes
* The codec, font, mime handler installation support is moving from gnome-
packagekit to gnome-software, with a new UI

== Scope ==
* Proposal owners:
** Keep existing GNOME packages updated
** Follow upstream module changes
** Package new applications and new dependencies of existing GNOME packages 
for GNOME 3.16:
*** gnome-taquin
*** gnome-2048

* Other developers: N/A 
* Release engineering: N/A
* Policies and guidelines: N/A 

== Contingency Plan ==
GNOME 3.16 will be released in March 2015 and fits well into Fedora 22 
schedule. In case of issues with individual modules that aren't either 
released in time or aren't deemed suitable for Fedora 22, we'll continue using 
the GNOME 3.14 versions of these modules.

* Contingency mechanism: The Workstation WG evaluates the GNOME 3.16 
prerelease before beta freeze and reverts individual changes as needed.
* Contingency deadline: beta freeze
* Blocks release? No 

[1] https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications
[2] https://fedoraproject.org/wiki/Changes/Nautilus_Improvements
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Systemd Package Split

[Jaroslav Reznik]

= Proposed System Wide Change: Systemd Package Split =
https://fedoraproject.org/wiki/Changes/SystemdPackageSplit

Change owner(s): Zbigniew Jędrzejewski-Szmek 

Split systemd-units out of the main systemd package 

== Detailed Description ==
Systemd contains many binaries and depends on a fairly large number of 
libraries. Packages which carry systemd units currently have to depend on 
systemd (through %post, %preun, %postun macros used to install and uninstall 
systemd units), which grows the dependency tree and increases the size of 
minimal installs.

With this proposal systemd-units subpackages will be split out again:
systemd-units

This subpackage will contain the directories and binaries necessary to satisfy 
%post, %preun, %postun macros for packages containing systemd units 
(systemctl, systemd-escape, systemd-sysusers, udevadm, journalctl), and config 
information (pkg-config files).

The main systemd package would require this package so it will be pulled in on 
all existing systems. All packages which have BuildRequires:systemd will also 
pull it in transitively.

Systemd previously had a -units subpackage and ~150 packages still depend on 
it. Those packages would start using the reduced subpackage immediately. Other 
packages wishing to use the reduced dependency, would have to change the 
BuildRequires and Requires to systemd-units. 

== Scope ==
* Proposal owners: Create the subpackage, test that macros work as expected. 

* Other developers: Change the BuildRequires and Requires to systemd-units if 
wanted. 

* Release engineering: None 
* Policies and guidelines: s/systemd/systemd-units/ in the appropriate places. 

== Contingency Plan ==
* Revert the packaging change and rebuild systemd. Main systemd package would 
provide systemd-units, as it does now, so no other changes should be 
necessary.
* Contingency deadline: should be possible at any time.
* Blocks release? No.
* Blocks product? No. 
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: python-dateutil 2.x

[Jaroslav Reznik]

= Proposed System Wide Change: python-dateutil 2.x =
https://fedoraproject.org/wiki/Changes/python-dateutil_2.x

Change owner(s): Pete Travis ,  Stephen 
Gallagher 

The package providing `dateutil` python libraries is currently on version 1.5. 
Early releases in the 2.x series of python-dateutil would work only for 
python3, so the package was not updated in Fedora. Now, python-dateutil is at 
version 2.4 and does work with python2. Fedora packages can be updated to use 
the newer version. 

== Detailed Description ==
Many newer python packages require the newer version of python-dateutil, but 
some still need python-dateutil 1.5 to function properly. Maintainers will 
assess affected packages, and can use the parallel installable python-
dateutil15 package, which already exists in the distribution, if they cannot 
migrate. 

== Scope ==
* Proposal owners: 
Coordinate update efforts and assist maintainers in assessing, testing, and 
updating their packages.

* Other developers: 
Maintainers of packages that depend on python-dateutils should test with 
version 2.4, or the current release at freeze. If their package is not 
compatible with this version, they should change the packages Requires: to use 
python-dateutil15 and ensure that it works with the parallel-installable egg 
that it provides.

* Release engineering: As each package should be assessed individually, a mass 
rebuild is not appropriate and release engineering has no requirements for 
this change. 

* Policies and guidelines: 
https://fedoraproject.org/wiki/Packaging:Python_Eggs#Multiple_Versions is 
relevant. 
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: Ipsilon

[Jaroslav Reznik]

= Proposed Self Contained Change: Ipsilon =
https://fedoraproject.org/wiki/Changes/Ipsilon

Change owner(s): Patrick Uiterwijk , Simo Sorce 


Inclusion of Ipsilon in the Fedora repositories. 

== Detailed Description ==
The goal is to include the Ipsilon identity provider [1] into Fedora.

Ipsilon is a server and a toolkit to configure Apache-based Service Providers. 
The server is a pluggable selfcontained mod_wsgi application that provides 
federated SSO to web applications. User authentication is always performed 
against a separate Identity Management system (for example a FreeIPA server), 
and communication with application is done using a federation protocol like 
SAML, OpenID, etc.. 

== Scope ==
* Proposal owners: work on Ipsilon inclusion into Fedora 
* 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) 

[1] https://fedorahosted.org/ipsilon
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Atomic Host

[Jaroslav Reznik]

= Proposed System Wide Change: Atomic Host =
https://fedoraproject.org/wiki/Changes/AtomicHost

Change owner(s): Cloud SIG / Joe Brockmeier  and Colin 
Walters 

New Fedora product: Fedora Atomic Host, an implementation of the Project 
Atomic [1] pattern.

This is a continuation and expansion of Changes/Atomic_Cloud_Image [2].

== Detailed Description ==
The original Changes/Atomic_Cloud_Image was a host system delivered just as a 
cloud image. This Change for Fedora 22 expands it to a multitude of delivery 
vehicles:

* Bare metal support via Anaconda
* Cloud providers
** OpenStack/KVM qcow2
** EC2 AMI
** Google Compute Engine 
* Vagrant boxes (OS X and vagrant-libvirt)
* Ultra-minimal LiveOS image designed for PXE booting diskless servers 

== Scope ==
* Proposal owners: Maintain kickstart and tree configuration, integration with 
Anaconda and other tools, maintain packages in Fedora
* Other developers: Unknown.
* Release engineering: Will need to generate trees during the general Fedora 
compose process, and generate install media and cloud image based on trees.
* Policies and guidelines: May need updates for RpmOstree. 

== Contingency Plan ==
* Blocks product? Yes, Atomic Host 

If something fails and this product can't ship, some upgrade mechanism for 
Fedora 21 Atomic Cloud Image users would need to be evaluated. The simplest 
fallback is to tell those users to reinstall with a traditional Fedora 22 
Cloud image. 

[1] http://www.projectatomic.io/
[2] https://fedoraproject.org/wiki/Changes/Atomic_Cloud_Image
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Plasma 5

[Jaroslav Reznik]

= Proposed System Wide Change: Plasma 5 =
https://fedoraproject.org/wiki/Changes/Plasma_5

Change owner(s): KDE SIG & Daniel Vrátil , Lukáš Tinkl 
, Jan Grulich , Rex Dieter 
, Than Ngo , Kevin Kofler 


Plasma 5 is successor to KDE Plasma 4 created by the KDE Community. It is 
based on Qt 5 and KDE Frameworks 5 and brings many changes and improvements 
over previous versions, including new look & feel as well as important changes 
under the hood. 

== Detailed Description ==
Plasma 5 is a new major version of KDE's workspaces. It has a new theme called 
Breeze, which has cleaner visuals and better readability, improves certain 
work-flows and provides overall more consistent and polished interface.

Changes under the hood include switch to Qt 5 and KDE Frameworks 5 and 
migration to fully hardware-accelerated graphics stack based on OpenGL(ES).

Note that Plasma 5 only includes the actual shell, decorations, icons and a 
few applications coupled with workspace (e.g. KWin, System Settings, 
KSysGuard). It does not include "regular" applications like Dolphin, Okular, 
Konqueror, etc. which are part of KDE Applications product and released 
independently of Plasma 5.

Plasma 5 gets a new feature release every three months, and each feature 
release has monthly bugfix releases. Plasma 5.2 is scheduled to be released on 
January 27. KDE SIG intends to ship Plasma 5.2.2 or Plasma 5.3, depending on 
the final schedules. 

== Scope ==
* Proposal owners:
** Submit, review and import new packages for Plasma 5 to rawhide/F22
** Modify existing KDE 4 packages to ensure smooth upgrade path to Plasma 5
** Retire KDE 4 packages not compatible with Plasma 5, or available in Plasma 
5 under different names/components

* Other developers:
Optionally, maintainers of 3rd party KDE Workspace 4 packages such as Plasma 
applets or KCMs may want to consult upstream regarding Qt 5/Frameworks 
versions of their packages, and eventually update them to Frameworks version, 
so that they are available in Plasma 5.

* Release engineering: 
No, this change requires no coordination with rel-eng.

* Policies and guidelines:
No, this change requires no update to packaging guidelines or policies.

== Contingency Plan ==
* Contingency mechanism: Rolling back to KDE 4 and shipping KDE Workspace 
4.11.X. As rawhide would already have packages with version 5.x.y, we would 
have to increase the epoch number of all affected KDE 4 packages, and making 
them Obsolete their Plasma 5 equivalents (since some Plasma 5 packages have 
been renamed or split from larger KDE 4 packages)
* Contingency deadline: Before F22 beta freeze
* Blocks release? No
* Blocks product? No 

___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: Minglish - New input method for Marathi Language

[Jaroslav Reznik]

= Proposed Self Contained Change: Minglish - New input method for Marathi 
Language =
https://fedoraproject.org/wiki/Changes/minglish

Change owner(s): anish 

New input method for Marathi language users. 

== Detailed Description ==
Minglish input method is to type Marathi using Latin alpha-bates.However there 
are existing mim layouts are available though each layout has few problems. 
e.g to type word "anish" in Marathi using phonetic input method one has to 
type sequence as "FniS" while with itrans input method one has to type 
"anisha". In given example user often expects "अनिश" to be appear with 
keystrokes "anish". In India, people who have familiar with English language 
tend to type Marathi letters upon English letter pronunciation, that is why we 
have new term http://en.wikipedia.org/wiki/Hinglish. 

== Scope ==
* Proposal owner: Initial plan is to send this patch to upstream and otherwise 
patch it into Fedora 

* 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) 
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default

[Jaroslav Reznik]

= Proposed System Wide Change: Enable Polyinstantiated /tmp and /var/tmp 
directories by default =
https://fedoraproject.org/wiki/Changes/Polyinstantiated_tmp_by_Default

Change owner(s): Huzaifa Sidhpurwala 

Polyinstantiation of temperary directories is a pro-active security measure, 
which reduced chances of attacks caused due to the /tmp and /var/tmp 
directories being world-writable. These include flaws caused by predictive 
temp. file names, race conditions due to symbolic links etc. 

== Detailed Description ==
The basic idea is to provide better security to Fedora installs. Though 
Polyinstantiated /tmp has worked since Fedora 19, its not a single step 
process to configure it. Secondly people don't really understand its benefits. 
Because of this having it on by default makes more sense. It is completely 
transparent to the user, they wont even realize that it has been enabled.

The Red Hat Product Security Team assigns CWE ids to severe flaws (CVSSv2 > 7). 
Here is a list of severe flaws caused by insecure tmp files [1].

== Scope ==
* Proposal owners: No work required to be done by proposal owner.

* Other developers:
** Add /tmp-inst and /var/tmp/tmp-inst to filesystem. (packagename: filesystem)
** Enable namespaces in /etc/security/namespace.conf (packagename: PAM)
** Enable proper selinux context and polyinstantiation_enabled boolean to be 
set (packagename: selinux-policy-targeted or selinux-policy)

* Release engineering: N/A
* Policies and guidelines: N/A

== Contingency Plan ==
* Contingency mechanism: Poly tmp can be rolled back quite easily, by using 
the previous versions of packages which provides the old directory structures 
and old versions of the configuration files (poly tmp is just configuration and 
a 
few new directories). In releases earlier gnome-shell had issues with poly 
tmp, which now seems to be resolved. In any case, by Beta deadline if any 
blockers exists, we can easily remove this feature, by tagging previous 
versions of the affected packages, before the final spin.

* Contingency deadline: Beta freeze
* Blocks release? No 

[1] http://red.ht/1EkZ1gT
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Login Screen Over Wayland

[Jaroslav Reznik]

= Proposed System Wide Change: Login Screen Over Wayland =
https://fedoraproject.org/wiki/Changes/Login_Screen_Over_Wayland

Change owner(s): Ray Strode 

Change the Login screen that GDM uses to run on Wayland instead of X.

== Detailed Description ==
At the moment, a user can choose to log in to a Wayland session from the login 
screen, but the login screen itself always runs on top of X. The point of this 
change is to change that, and make the login screen always run on a Wayland 
session. 

== Scope ==
* Proposal owners: The main things that need be accomplished are:
** Change GDM to not start an X server at startup, instead run the login 
screen in Wayland mode
** Change X based user sessions to run on their own VT, since they can no 
longer piggyback off the login screen VT
** Come up with some answer for proprietary Nvidia driver users, since that 
stack doesn't yet support Wayland.  One idea is to force the login session to 
use software-based mesa if the proprietary Nvidia driver is detected.

* Other developers: We may need to get the mesa maintainer involved as part of 
a proprietary Nvidia driver handling, but also might not need to pending 
investigation.

* Release engineering: This change doesn't affect release workflow
* Policies and guidelines: This change doesn't affect packaging guidelines

== Contingency Plan ==
* Contingency mechanism: Revert to existing mechanism of login screen on Xorg
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: Gradle 2.x

[Jaroslav Reznik]

= Proposed Self Contained Change: Gradle 2.x =
https://fedoraproject.org/wiki/Changes/Gradle

Change owner(s): Mikolaj Izdebski 

This change aims at making latest version of Gradle available in Fedora and 
making it possible to easily build Fedora packages using Gradle. 

== Detailed Description ==
Gradle [1] is a popular Java build automation tool, which can automate 
building, testing, publishing, deployment and more of software packages or 
other types of projects such as generated static websites, generated 
documentation or indeed anything else.

This change brings latest upstream version of Gradle to Fedora, which enables 
Fedora users to use Gradle to work with software projects.

This change also implements integration with software used for Java packaging 
in Fedora (XMvn and Javapackages), which makes it possible to use standard 
Fedora pagkaging techniques to build RPM packages with Gradle with all 
features, such as automatic artifact installation or auto-requires/provides. 

== Scope ==
* Proposal owners:
** Package latest Gradle 2.x
** Implement local Gradle resolver so that RPM packages can be built with 
Gradle
** Update Java Packaging HOWTO to include information about Gradle packaging

* Other developers:
** Maintainers of packages not built with Gradle and which upstreams are using 
Gradle as build system can optionally update their packages to be built with 
Gradle, but that's not absolutely required as existing ways of building Java 
packages will continue to work.

* Release engineering: N/A

* Policies and guidelines: N/A

[1] http://gradle.org/
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Glibc Unicode 7.0

[Jaroslav Reznik]

= Proposed System Wide Change: Glibc Unicode 7.0 =
https://fedoraproject.org/wiki/Changes/Glibc_Unicode_7

Change owner(s):  Mike Fabian , Pravin Satpute 
, Siddhesh Poyarekar

We are updating Glibc Unicode data from Unicode 5.1 to Unicode 7.0 version. It 
took long time since there was not much documentation on how to update Unicode 
data and also there was chance of loosing backward compatibility. Most of the 
issues are resolved now and patches are ready for inclusion. This update adds 
around 8000 number of character support in Glibc and also correcting the 
Unicode data of many characters as per latest Unicode standard. 

== Detailed Description ==
In this update we are planning to update Glibc's the Unicode locale data - 
character map and LC_CTYPE information to Unicode 7.0 version. This data is 
used almost in all locales and going to affect all applications using these 
locales. It is system wide change since it impacting glibc and application 
dependent on it. Glibc provides two files for Unicode data, UTF-8 and i18n. 
UTF-8 file provides information about CHARMAP and WIDTH for Unicode characters. 
i18n file provides CTYPE (uppercase, lowercase, punct etc.) information for all 
Unicode characters. It has been long time this is not updated due to 
incomplete documentation and also possible chances of loosing backward 
compatibility. Work has been started on this 5-6 months back and now most of 
the issues are resolved.

Respective bugs in upstream for more information.

* Update locale data to Unicode 7.0.0 [1]
* Update UTF-8 charmap and width to Unicode 7.0.0 [2]

Github repo for scripts. [3]

== Scope ==
* Proposal owners:
1. Writing scripts for generating UTF-8 and i18n files from Unicode character 
database.
2. Preparing patch for UTF-8 and i18n files.
3. Preparing backward compatibility report.
4. Applying patches to Fedora.
5. Testing whether does it breaks anything around.

* Other developers: This change impacting glibc and all applications that 
using locales. Other Developers do not need to do any changes from there end 
but they need to watch how there application behave with improved localedata. 
We need proper testing to see it does not break any application.

* Release engineering: No work required from Release engineering.

* Policies and guidelines: No, this change does not required any updates to 
Policies or packaging guideline updates.

== Contingency Plan ==
* Contingency mechanism: Will drop patches from Glibc build.
* Contingency deadline: Before F22 Beta release eg. Beta freeze.
* Blocks release? No
* Blocks product? product No 

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=14094
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=17588
[3] https://github.com/pravins/lohit
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: Dnf Langpack Plugin

[Jaroslav Reznik]

= Proposed Self Contained Change: Dnf Langpack Plugin =
https://fedoraproject.org/wiki/Changes/DnfLangpacksPlugin

Change owner(s): Parag Nemade 

A dnf plugin that allows langpacks to be installed/removed for the given 
languages using its commands. 

== Detailed Description ==
This is similar to what we have yum langpacks plugin which is already a 
Features/YumLangpackPlugin [1] in Fedora but there is one missing thing that 
this plugin currently does not provide automatic installation of langpacks 
which is under development [2]. Therefore I am proposing this as basic 
langpacks plugin that provides all the required commands for langpacks only.

== Scope ==
* Proposal owners: implement langpacks plugin
* 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) 

[1] https://fedoraproject.org/wiki/Features/YumLangpackPlugin
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1114422
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Django 1.8

[Jaroslav Reznik]

= Proposed System Wide Change: Django 1.8 =
https://fedoraproject.org/wiki/Changes/Django18

Change owner(s): Matthias Runge 

Update python-django to version 1.8. 

== Detailed Description ==
Update python-django to version 1.8. Fedora 21 contains version 1.6, which 
will become deprecated by upstream, once Django-1.8 is out. This is a change, 
impacting many of python-django-* packages.

Django upstream is transparent and announces deprecation far in advance. 

== Scope ==
* Proposal owners: 
** update python-django to version 1.8. To support maintainers of dependent 
packages, a copr repo containing latest Django-1.8 is here: [1]
** A build containing latest Django will be pushed to f22 branch late in dev 
cycle. If we decide not to push Django-1.8, nothing will be broken.
** Django 1.8 final release is expected around April 1st, 2015: [2] 

* Other developers: update dependent packages to work with Django-1.8
* Release engineering: N/A 
* Policies and guidelines: N/A

== Contingency Plan ==
* Contingency mechanism: If we can not make it, we'll keep Django-1.7 from 
rawhide.
* Contingency deadline: Fedora 22 Beta release.
* Blocks release? No 
* Blocks product? doesn't block a product.

[1] https://copr.fedoraproject.org/coprs/mrunge/django-1.8/ 
[2] https://code.djangoproject.com/wiki/Version1.8Roadmap#schedule
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: Database Server Role

[Jaroslav Reznik]

= Proposed Self Contained Change: Database Server Role =
https://fedoraproject.org/wiki/Changes/DatabaseServerRole

Change owner(s): Stephen Gallagher , Kevin Fenzi 
 and Truong Anh Tuan  and Server WG 


The Fedora Server Product will provide a standard deployment mechanism for a 
Linux Database Server (powered by the postgresql project). 

== Detailed Description ==
The Fedora Server Product will be shipped with a role-deployment mechanism. 
One such role will be to act as a primary or replica Database Server for the 
Linux machines in the network.

This will be implemented by taking advantage of the postgresql project, 
packaging it up within the Server Role Framework and enabling it to be 
deployed through the mechanisms described in the Framework for Server Role 
Deployment Change Proposal.

Note that this role is a secondary target of the Server Working group. 

== Scope ==
* Proposal owners:
** Postgresql server and related tools need to be packaged appropriately for 
use with the Server Role Infrastructure.
** A D-BUS API plugin needs to be written and tested to support deployment and 
monitoring of the Database server.

* Other developers:
** None

* Release engineering:
** Pre-loading roles will need to be a capability of the Anaconda install 
system, both in the graphical installer and kickstart

* Policies and guidelines:
** Packaging guidelines for this Change should be inherited from the Framework 
for Server Role Deployment Change Proposal.

___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: Domain Controller Set Up Through Cockpit

[Jaroslav Reznik]

= Proposed Self Contained Change: Domain Controller Set Up Through Cockpit =
https://fedoraproject.org/wiki/Changes/CockpitDomainController

Change owner(s): Stephen Gallagher  

With Fedora 21, the rolekit project now provides a public D-BUS interface for 
creating a Domain Controller based on the FreeIPA project. This Change will 
track adding this capability to the Cockpit management console of Fedora 
Server. 

== Detailed Description ==
Providing users with a simple graphical user interface to set up a FreeIPA 
Domain Controller will provide a fast way to bootstrap an enterprise-grade 
Linux environment. Once the Domain Controller is made available, it becomes 
easy to manage single-sign-on between systems (and Cockpit instances), control 
user authentication and authorization centrally and manage DNS entries (among 
other things). 

== Scope ==
* Proposal owners: The Cockpit user experience needs to be written and added 
to that upstream project. It needs to be connected to the local rolekit 
daemon.

* 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)
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Change Checkpoint: Proposals submission deadline is tomorrow

[Jaroslav Reznik]

Hi everyone!
Tomorrow is the last day/chance to submit your system wide changes
for Fedora 22 [1]! Your proposed change has to be at least in ready
for Wrangler state.

For policies, check out [2]. Empty template is available at [3].
All changes approved so far are available on the ChangeSet [4] wiki.

This time, the deadline is *final* as we'd like to strictly adhere to
schedule and any further exception may be rejected. Self contained 
changes will be considered after this deadline but in case of any
doubts, may be rejected too.

Please make sure Contingency Plan section contains all required fields
and enough details to understand all the potential risks.

Thanks
Jaroslav

[1] https://fedoraproject.org/wiki/Releases/22/Schedule
[2] https://fedoraproject.org/wiki/Changes/Policy
[3] https://fedoraproject.org/wiki/Changes/EmptyTemplate
[4] https://fedoraproject.org/wiki/Releases/22/ChangeSet



___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: Wine to use mesa Direct3D

[Jaroslav Reznik]

= Proposed Self Contained Change: Wine to use mesa Direct3D =
https://fedoraproject.org/wiki/Changes/Wine_to_use_mesa_Direct3D

Change owner(s): Igor Gnatenko  

Enhancing mesa and wine with Direct3D9 support will increase performance and 
reduce resource usage in applications which using D3D9 framework. 

== Detailed Description ==
When playing d3d9 games on Wine, their d3d9 calls are translated to OpenGL. 
This is complicated process, because you have to deal with different drivers 
having different extensions available, and the fact that opengl and d3d9 don't 
map perfectly together. Gallium Nine implements the d3d9 API with Gallium 
internal API, which maps better to d3d9 than OpenGL. You remove some layers of 
translation in the process which enables better performance. Gallium Nine is 
not as mature as Wine OpenGL translation, and it is likely to have more bugs, 
but when the games work, you can expect 5-10% improvement for gpu limited 
games, or much more (sometimes 100%) for cpu limited games.

what is Gallium: Gallium is an internal graphic driver abstraction of Mesa to 
enable support of non-opengl languages more easily (it is used for vdpau and 
vaapi on r600/radeonsi for example). It is used by nouveau and r300 up to 
radeonsi for AMD. Intel OpenGL support doesn't use gallium, but a gallium 
driver named ilo exists, but isn't sponsored by Intel.

In practice, games have also smoother frame rate on Gallium Nine. Gallium Nine 
has good DRI_PRIME support, and if you have a system with an iGPU+dGPU, you 
can play without issues with the parameters DRI_PRIME=1 thread_submit=true

https://wiki.ixit.cz/d3d9 

== Scope ==
* Proposal owners: work on the Mesa Direct3D support 
* 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) 

== Contingency Plan ==
* Contingency mechanism: Revert and try to do in next release
* Contingency deadline: beta freeze 
* Blocks release? N/A (not a System Wide Change) 
* Blocks product? N/A (not a System Wide Change) 
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: Nautilus Improvements

[Jaroslav Reznik]

= Proposed Self Contained Change: Nautilus Improvements =
https://fedoraproject.org/wiki/Changes/Nautilus_Improvements

Change owner(s): Carlos Soriano  

Tie up some of the loose ends that were leftover after the nautilus design 
refresh work that has happened a while ago. 

== Detailed Description ==
The nautilus code base will be cleaned up by porting it from the deprecated 
GtkAction APIs to GAction. As part of this, the view, gear and app menus will 
be updated to match the current designs. In addition, several long-standing 
annoyances will be addressed, such as the problematic floating statusbar, and 
the keyboard shortcut for deleting files. 

== Scope ==
* Proposal owners:
** Get the [1] branch reviewed and merged (in progress)
** Write a patch to change from Ctrl-Delete to Delete with an undo notification 
(bug [2])
** Implement a different solution for the floating statusbar

* 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)

== Contingency Plan ==
N/A (not a System Wide Change)

[1] https://git.gnome.org/browse/nautilus/log/?h=wip/gaction wip/gaction
[2] https://bugzilla.gnome.org/show_bug.cgi?id=648658
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: Gnome Shell - New Notifications

[Jaroslav Reznik]

= Proposed Self Contained Change: Gnome Shell - New Notifications =
https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications

Change owner(s): Florian Müllner  

Redesign the way in which notifications are shown and kept available in gnome-
shell. 

== Detailed Description ==
The message tray is one of the remaining weaker points of the original gnome-
shell design. This change will replace it with a new implementation of 
notifications that avoids the problems of the current implementation. 

== Scope ==
* Proposal owners:
** Implement the new design
** Get the changes reviewed and merged 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) 

== Contingency Plan ==
N/A (not a System Wide Change)
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: GCC5

[Jaroslav Reznik]

= Proposed System Wide Change: GCC5 =
https://fedoraproject.org/wiki/Changes/GCC5

Change owner(s):  Jakub Jelínek 

Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.

== Detailed Description ==
GCC 5 is currently in stage3, but in 3 days will move to stage4, in prerelease 
state with only regression bugfixes and documentation fixes allowed. The 
release 
will happen probably in the first half of April. We are working on scratch gcc 
rpms and will perform a test mass rebuild. Other distributions have performed 
test mass rebuilds already. 

== Scope ==
All packages should be rebuilt with the new gcc once it hits f22.

* Proposal owners: Build gcc in f22, rebuild packages that have direct 
dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).

* Other developers: First few days/weeks just voluntary rebuilds using the new 
system gcc, if things fail, look at http://gcc.gnu.org/gcc-5/porting_to.html 
and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, 
analyze and report. 

* Release engineering: Organize a mass rebuild 
* Policies and guidelines: No policies need to be changed 

== Contingency Plan ==
If bugs are discovered, I'd appreciate help from the package owners in 
preparing self-contained testcases to speed up analysis and fixing the bugs. 
Don't have time to debug issues in 12000+ packages, especially when in many 
cases it could be caused by undefined code in the packages etc. I don't expect 
we'll have to fall back to the older gcc, we've never had to do it in the 
past, but worst case we can mass rebuild everything with older gcc again.

* Contingency mechanism: Revert to older gcc, mass rebuild everything again
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No 
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades

[Jaroslav Reznik]

= Proposed System Wide Change: RpmOstree - Server side composes and atomic 
upgrades =
https://fedoraproject.org/wiki/Changes/RpmOstree

Change owner(s): Colin Walters 

The rpm-ostree [1] tool provides a new way to deploy and manage RPM-based 
operating systems. Instead of performing a package-by-package install and 
upgrade on each client machine, the tooling supports "composing" sets of 
packages on a server side, and then clients can perform atomic upgrades as a 
tree.

The system by default preserves the previously booted deployment, providing an 
"A/B partition" type feel, allowing quick system rollbacks for the entire OS 
content (kernel and userspace).

This is a dependency of the Changes/Atomic_Cloud_Image. [2]

== Detailed Description ==
rpm-ostree is far from the first effort in the field of "image-like" update 
systems in Fedora. The StatelessLinux [3] project was first prototyped in 
Fedora Core 6 timeframe. Today, particularly in the cloud, many deployments 
perform OS upgrades by terminating an instance, and booting a new OS image and 
having it discover previous state stored in an external volume or network 
store.

Another model is to perform an atomic upgrade by delivering the OS content via 
an ISO or USB stick, and simply swapping it out, then rebooting. The oVirt 
Node [4] is an example of this model.

The most challenging case though is stateful systems that require 
online/incremental Internet/Intranet connected upgrades. This is the default 
model for traditional Fedora package managers such as yum. A common approach 
for this to have an "A/B" partition model, and to use rsync or a custom tool 
to perform upgrades offline into the non-active partition.

rpm-ostree is attempting to address this last case, but in a more flexible and 
dynamic fashion. It has some of the flexibility of package systems, with the 
atomic upgrade and rollback of image-based systems. Furthermore, rpm-ostree 
intends to bind together the world of packages with an image-like update 
system. For example, an "rpm-ostree upgrade" command can show the system 
administrator the package-level diff.

In the future, the intention is for rpm-ostree to further gain package-system 
like features. See package layering prototype [5]. An active git branch uses 
libhif [6]. 

== Scope ==
* Proposal owners: work on http://projectatomic.io upstream

* Other developers:
** Anaconda: Help maintain rpmostreepayload.py
** Anaconda/Architecture porters: Backends for the OSTree bootloader code, 
similar to grubby

** RPM content:
*** Use systemd-tmpfiles instead of placing content in /var  (TODO: better docs 
for this)
*** Change "rootfiles" and "bash" to not require files in /root by default  
(TODO: bugzilla entry)

* Release engineering: Create trees from package set, mirroring support

* Policies and guidelines: TODO: Guideline for /var

[1] https://github.com/projectatomic/rpm-ostree
[2] https://fedoraproject.org/wiki/Changes/Atomic_Cloud_Image
[3] https://fedoraproject.org/wiki/StatelessLinux
[4] http://www.ovirt.org/Node_Building
[5] 
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2014-October/msg5.html
[6] https://github.com/projectatomic/rpm-ostree/pull/81
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Re: FESCo and Env and Stacks WG upcoming elections nominations are open

[Jaroslav Reznik]

> Hello everyone!
> The nomination period for FESCo and Environments and Stacks Working
> Group Elections is now open.
> 
> We will be selecting five seats on FESCo [1] and four seats on Env and
> Stacks Working Group [2]. If you are interested in these roles, please
> add yourself to the lists of nominees at [1] and [2] before 23:59:59
> UTC on January 19, 2015!  If you wish to nominate someone else, please
> consult with that person ahead of time. If you know someone who would
> be a good candidate, now is a great time to make sure they're thinking
> about it.

And missing links I promised :).

[1] http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
[2] http://fedoraproject.org/wiki/Env_and_Stacks/Nominations

Main elections page is at http://fedoraproject.org/wiki/Elections

Jaroslav
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

FESCo and Env and Stacks WG upcoming elections nominations are open

[Jaroslav Reznik]

Hello everyone!
The nomination period for FESCo and Environments and Stacks Working
Group Elections is now open.

We will be selecting five seats on FESCo [1] and four seats on Env and
Stacks Working Group [2]. If you are interested in these roles, please
add yourself to the lists of nominees at [1] and [2] before 23:59:59
UTC on January 19, 2015!  If you wish to nominate someone else, please
consult with that person ahead of time. If you know someone who would
be a good candidate, now is a great time to make sure they're thinking
about it.

If you have questions you'd like asked of candidates, please add them
to the  wiki
page. Nominees will answer these questions and the answers will be
published simultaneously on January 26th as part of campaign period.
Questions may be moderated to fit Fedora Magazine interview format.

No FAmSCo elections are held this time as FAmSCo is discussing the
new committee format.

Elections schedule:
* January 13-19: Nomination period open
* January 20-26: "Campaign" period.
* January 27 - February 03: Voting open
* February 04: Results announcement 
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Default Local DNS Resolver

[Jaroslav Reznik]

= Proposed System Wide Change: Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver

This Change was already proposed as Fedora 21 Change but moved to Fedora 22 
(and discussed as Fedora 22 Change), re-announcing it as more details were 
provided as requested by FESCo [0].

Change owner(s): P J P , Pavel Šimerda
, Tomas Hozza 

To install a local DNS resolver trusted for the DNSSEC validation running on 
127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.

The automatic name server entries received via dhcp/vpn/wireless configurations 
should be stored separately, as transitory name servers to be used by the 
trusted local resolver. In all cases, DNSSEC validation will be done locally. 

== Detailed Description ==
There are growing instances of discussions and debates about the need for a 
trusted DNSSEC validating local resolver running on 127.0.0.1:53. There are 
multiple reasons for having such a resolver, importantly security & usability. 
Security & protection of user's privacy becomes paramount with the backdrop of 
the increasingly snooping governments and service providers world wide.

People use Fedora on portable/mobile devices which are connected to diverse 
networks as and when required. The automatic DNS configurations provided by 
these networks are never trustworthy for DNSSEC validation. As currently there 
is no way to establish such trust.

Apart from trust, these name servers are often known to be flaky and 
unreliable. Which only adds to the overall bad and at times even frustrating 
user experience. In such a situation, having a trusted local DNS resolver not 
only makes sense but is in fact badly needed. It has become a need of the 
hour. (See: [1], [2], [3])

Going forward, as DNSSEC and IPv6 networks become more and more ubiquitous, 
having a trusted local DNS resolver will not only be imperative but be 
unavoidable. Because it will perform the most important operation of 
establishing trust between two parties.

All DNS literature strongly recommends it. And amongst all discussions and 
debates about issues involved in establishing such trust, it is unanimously 
agreed upon and accepted that having a trusted local DNS resolver is the best 
solution possible. It'll simplify and facilitate lot of other design decisions 
and application development in future. (See: [1], [2], [3])

People:
* Petr Spacek
* Paul Wouters
* Simo Sorce
* Dmitri Pal
* Carlos O'Donell

== Scope ==
Proposal owners: Proposal owners shall have to
* define the syntax and semantics for new configuration parameters/files. 
* persuade and coordinate with the other package owners to incorporate new 
changes/workflow in their applications.

Other developers: (especially NetworkManager and the likes)
*  would have to implement the new features/workflow for their applications 
adhering to the new configurations and assuming the availability of the trusted 
local DNS resolver.
* NetworkManager already has features & capability to support local DNS 
resolvers. Though few details are still under development, but are expected to 
realize in near future. Please see -> 
https://lists.fedoraproject.org/pipermail/devel/2014-April/197848.html

Release engineering: 
* would have to ensure that trusted local DNS resolver is available throughout 
the installation stage and the same is installed on all installations 
including LiveCDs etc.

Policies and guidelines: 
* the chosen trusted DNS resolver package(ex dnsmasq or dnssec-trigger etc.) 
would have to ensure that their DNS resolver starts at boot time and works out 
of the box without any user intervention.
* NetworkManager and others would have to be told to not tamper with the local 
nameserver entries in '/etc/resolv.conf' and save the dynamic nameserver 
entries in a separate configuration file.

[0] https://fedorahosted.org/fesco/ticket/1307
[1] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html
[2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html
[3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Set sshd(8) PermitRootLogin=no

[Jaroslav Reznik]

= Proposed System Wide Change: Set sshd(8) PermitRootLogin=no =
https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no

Change owner(s): P J P  and Fedora Security Team

To disable remote root login facility in sshd(8) by default. 

== Detailed Description ==
Sshd(8) daemon allows remote users to login as 'root' by default. This 
provides remote attackers an option to brute force their way into a system. 
Empirically it is observed that many users use their systems via 'root' login, 
without creating non-root user and often have weak passwords for this mighty 
account. sshd_config(5) has an option 'PermitRootLogin=yes|no' which controls 
sshd(8) behaviour; it is set to be 'Yes' by default. Disabling remote root 
login by setting PermitRootLogin=no would help to harden Fedora systems, 
moving it an inch closer towards 'secure by default' future. Users can have 
non-root accounts with weak passwords too, yet disabling remote root login 
keeps an attacker a step away from getting full control on a system. There is 
another option of disabling user login via password and require usage of 
cryptographic keys for the same. But that could a next step in future.

Please see -> 
https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html 

== Scope ==
* Proposal owners: to communicate with the Fedora maintainers of packages: 
Anaconda, OpenSSH, GNOME, etc.
* Other developers: packages like Anaconda, GNOME etc. need to update their 
workflow to enable compulsory non-root user account creation and ensure good 
password strength for it.
* Release engineering: installer needs to ensure creation of non-root user 
account with strong password. Similarly, all Fedora images must be created 
with a non-root user account.
* Policies and guidelines: unknown yet.
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Changes submission deadline and Fedora 22 scheduling changes

[Jaroslav Reznik]

Hi everyone!
Fedora 22 and especially Changes submission deadline [1] is coming pretty
soon - in less than two weeks on January 20th. With Alpha release in March.
Please, submit your System Wide Changes by this deadline, earlier better.

There's one significant change FESCo agreed at yesterday's meeting 
regarding Fedora schedules. Fedora 22 will be strictly time based release
(of course except quality related slips) and the final schedule will not
be based on submitted Change proposals! We will strictly enforce Contingency
plan at Changes checkpoints. Please make sure to provide valid plan in
your Change proposal as otherwise it can be rejected by FESCo (and scope
within Fedora 22 schedule).

This means, we have approved FINAL schedule for Fedora 22! It will be
released on May 19th (in case of no slips occurring).

In case you'll need any help with your Change proposals, feel free to
contact me and I'll do everything to help you :).

Jaroslav

[1] https://fedoraproject.org/wiki/Releases/22/Schedule
 
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: New Default Console Font

[Jaroslav Reznik]

= Proposed Self Contained: New Default Console Font =
https://fedoraproject.org/wiki/Changes/NewDefaultConsoleFont

Change owner(s): Marko Myllynen ,  Mike FABIAN 
 

A new console font, eurlatgr, was recently added to kbd and it should be 
better default console font for European based languages written in Latin or 
Greek script. eurlatgr is based on latarcyrheb-sun16 so the typeface does not 
change.

== Detailed Description ==
eurlatgr would bring these changes over the current default latarcyrheb-sun16:

* full compatibility with latarcyrheb-sun16 for Latin script and special 
characters
* Arabic/Cyrillic/Hebrew are not supported at all by eurlatgr so those users 
should still stay with latarcyrheb-sun16
* non-European languages written in Latin script (like Vietnamese) are not 
fully supported but perhaps a bit more so than with latarcyrheb-sun16
* the only non-Arabic/Cyrillic/Hebrew characters not present in eurlatgr but 
in latarcyrheb-sun16 are U+F800 and U+F804 which are not valid Unicode 
characters so the use case for them is unclear, especially today. These could 
be re-added if there's a real need for them but if not, dropping them is ok
* full support for all European languages written in Latin script
* full support for Greek
* full support for a huge list of characters and character sets (see 
Documentation below)
* support for a wide range of accented Latin characters not present in 
latarcyrheb-sun16 to allow people to write their names correctly
* support for glyphs used by some systemd(1) utilities
* support for glyphs used by man(1) (see e.g. the bottom of unicode(7) how 
some characters are not displayed properly under latarcyrheb-sun16)
* support for glyphs that have become popular recently, like the smiley (☺) 
and arrows (e.g. →)

== Scope ==
* Adjust langtable rules to prefer eurlatgr instead of latarcyrheb-sun16 for 
the languages supported by eurlatgr. Review additional related tools 
(anaconda, dracut, systemd) to see whether any defaults need to be changed. 
* 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)
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Ruby 2.2

[Jaroslav Reznik]

= Proposed System Wide Change: Ruby 2.2 =
https://fedoraproject.org/wiki/Changes/Ruby_2.2

Change owner(s): Vít Ondruch 

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).
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 Self Contained Change: Lohit2 Odia Telugu

[Jaroslav Reznik]

= Proposed Self Contained: Lohit2 Odia Telugu =
https://fedoraproject.org/wiki/Changes/Lohit2_Odia_Telugu

Change owner(s): Pravin Satpute  

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)
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Harden all packages with position-independent code

[Jaroslav Reznik]

= Proposed System Wide Change: Harden all packages with position-independent 
code =
https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code

Change owner(s): Till Maas , Moez Roy 


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.

___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Fedora 22 Boost 1.58 Uplift

[Jaroslav Reznik]

= Proposed System Wide Change: Fedora 22 Boost 1.58 Uplift =
https://fedoraproject.org/wiki/Changes/F22Boost158

Change owner(s): Petr Machata 

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
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: GHC 7.8

[Jaroslav Reznik]

= Proposed System Wide Change: GHC 7.8 =
https://fedoraproject.org/wiki/Changes/GHC_7.8

Change owner(s): Jens Petersen , Ricky Elrod 
, Haskell_SIG 

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.
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: wxPython 3

[Jaroslav Reznik]

= Proposed System Wide Change: wxPython 3 =
https://fedoraproject.org/wiki/Changes/wxPython3

Change owner(s): Scott Talbert 

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
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Elasticsearch

[Jaroslav Reznik]

= Proposed System Wide Change: Elasticsearch =
https://fedoraproject.org/wiki/Changes/Elasticsearch

Change owner(s): Jiri Vanek 

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/

___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Ruby on Rails 4.2

[Jaroslav Reznik]

= 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ý , Vít Ondruch 
, ruby-...@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
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce