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: 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 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. 

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 

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

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

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

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 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 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 rhughes at redhat dot com

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

F22 Self Contained Change: Xfce412

[Jaroslav Reznik]

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

Change owner(s): Kevin Fenzi ke...@scrye.com, Mukundan Ragavan 
nonamed...@fedoraproject.org, Christoph Wickert cwick...@fedoraproject.org

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

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 jva...@redhat.com

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 overorpahned 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

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 heliocas...@fedoraproject.org, 
Christoph Wickert cwick...@fedoraproject.org

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: 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 bkab...@redhat.com, Matej Stuchlik 
mstuc...@redhat.com, Miro Hroncok mhron...@redhat.com

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%3APythondiff=402016oldid=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 jstri...@redhat.com

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 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 zbys...@in.waw.pl

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: GNOME 3.16

[Jaroslav Reznik]

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

Change owner(s): Kalev Lember kalevlem...@gmail.com

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 Self Contained Change: Ipsilon

[Jaroslav Reznik]

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

Change owner(s): Patrick Uiterwijk puiterw...@redhat.com, Simo Sorce 
s...@redhat.com

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: 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 immanetize AT fedoraproject.org,  Stephen 
Gallagher sgall...@redhat.com

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: qtile

[Jaroslav Reznik]

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

Change owner(s): John Dulaney jdula...@fedoraproject.org 

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: 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 ro...@fedoraproject.org

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 url for qcow2 image

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 Self Contained Change: Tunir

[Jaroslav Reznik]

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

Change owner(s): Kushal Das kushal...@gmail.com

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: 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 sgall...@redhat.com 

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

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 mfabian At redhat DOT com, Pravin Satpute 
pravins At fedoraproject DOT org, Siddhesh Poyarekarspoyarek AT redhat DOT 
com

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: Gradle 2.x

[Jaroslav Reznik]

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

Change owner(s): Mikolaj Izdebski mizde...@redhat.com

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: 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 huzai...@redhat.com

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 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 apa...@redhat.com

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: 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 dvra...@redhat.com, Lukáš Tinkl 
lti...@redhat.com, Jan Grulich jgrul...@redhat.com, Rex Dieter 
rdie...@fedoraproject.org, Than Ngo t...@redhat.com, Kevin Kofler 
ke...@tigcc.ticalc.org

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

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: Nautilus Improvements

[Jaroslav Reznik]

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

Change owner(s): Carlos Soriano csori...@redhat.com 

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 System Wide Change: Elasticsearch

[Jaroslav Reznik]

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

Change owner(s): Jiri Vanek jva...@rehat.com

Goal of this change is to pack Elasticsearch into main Fedora repo. 

== Detailed Description ==
The Elasticsearch [1] is fully-featured self-standing opensource [2] indexing 
server. Many people and many tools do use it. And many people do want it in 
Fedora. Aim of this Change is to make elastic search available by simple yum 
install elasticsearch, and of course enable it as dependence. To build a 
custom indexing tool on top of elastic search is more easy than current 
upstream install and download. 

== Scope ==
* Proposal owners:
** pack Elasticsearch - nearly done - see RHBZ#902086
** make it somehow works
** verify it works
** tune list of crucial dependencies
** enable Elasticsearch as service - something what have to be decided

* Other developers: 
** '''This is crucial part of this proposal'''
** Elastic search is extremely tuned application, and like it, its 
dependencies must be strictly kept in correct versions
** Currently known troublemakers:
*** lucene
*** netty3
*** sigar
*** compress-lzf
*** guava (currently needed 18, avaiable 17)

* Release engineering: 
** Nothing I'm aware about.

* Policies and guidelines: 
** Nothing I'm aware about.
** maybe... fedora is going by way - keep as updated as possible, if it  
breaks something, that something have to be fixed. This is not best for ES. 
Maybe ES can et some helping exception?

[1] http://www.elasticsearch.com/products/elasticsearch
[2] https://github.com/elasticsearch/elasticsearch/

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

F22 System Wide Change: UEFI Secure Boot Blacklist Updates

[Jaroslav Reznik]

= Proposed System Wide Change: UEFI Secure Boot Blacklist Updates =
https://fedoraproject.org/wiki/Changes/UEFISecureBootBlacklistUpdates

Change owner(s): Peter Jones pjo...@redhat.com

Currently our implementation of UEFI Secure Boot does not include a facility 
to apply blacklist (dbx) updates enabled by default. We provide a utility, 
dbxtool, which uses a systemd service to apply updates, and when there are 
updates we update that package with the new data. dbxtool is currently not 
installed on UEFI machines by default, and when it is installed, its systemd 
service does not default to enabled. 

== Detailed Description ==
In UEFI Secure Boot, the ability for a pre-boot binary such as a bootloader or 
hardware maintenance utility to be executed is determined by a whitelist of 
binaries and cryptographic signing certificates, as well as a blacklist of 
binaries and signing certificates which are no longer considered valid. When a 
signed binary is discovered to have vulnerabilities which allow it to be used 
to circumvent the Secure Boot security model, and thus render the system 
unable to prevent execution of pre-boot malware, the UEFI CA, in coordination 
with the UEFI Security Response Team (USRT) and the relevant software vendor, 
must undertake remedial action. The software vendor must fix their 
vulnerability and issue a new version of the software, and the old software 
must be blocked from execution on applicable machines.

The first task is up to the vendor in question. Once the new version is ready 
(or when sufficient time has passed), if a vulnerability is being actively 
exploited or has a sufficiently high likelihood of being so, the UEFI CA issues 
a blacklist entry in the form of an update to the UEFI variable dbx. That 
update is a cryptographically signed list of binaries and/or signing 
certificates in a format which may be appended to a specific UEFI variable.

Currently Fedora includes the dbxtool [1] utility for updating the UEFI dbx 
blacklist. The dbxtool package includes the most recent UEFI CA blacklist 
update (they each include all data, so previous versions are not required) and 
a systemd service to ensure the update is applied to the system. Currently 
dbxtool is not installed by default on applicable systems, and when it is 
installed, its service is not enabled by default.
This change principally takes place in three packages:

* shim-signed must include a dependency on dbxtool
* dbxtool must have systemd %pre and %post scriptlets added
* systemd must include dbxtool.service in its 90-default.preset

== Scope ==
* Proposal owners: Implement proposed change
* Other developers: potentially the systemd-maint team, though I think I can 
commit the applicable change there.
* Release engineering: N/A
* Policies and guidelines: If we're keeping a list somewhere of things allowed 
to have system preset services, dbxtool should be added.

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

Fedora 21 Final status is Go, release on December 9, 2014

[Jaroslav Reznik]

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

Fedora 21 will be publicly available on Tuesday, December 09, 2014.

Meeting details can be seen here:
Minutes: http://bit.ly/1yjG357
Log: http://bit.ly/1yjG7SE

Thanks everyone, this is a huge achievement after almost one year long
development cycle and many changes not only under the hood how we
produce Fedora! And now, let's back to work on to the next Next Fedora
release ;-).

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

Fedora 21 Final Go/No-Go Meeting, Thursday, December 04 @ 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 21.

Thursday, December 04, 2014 17:00 UTC (12 AM 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 decision but meeting itself is held in any case.

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

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

Note: as I'll be already travelling to FAD Rheinland 2014, I could be
a bit late...

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

Fedora 21 Beta to slip by one week

[Jaroslav Reznik]

Today at Go/No-Go meeting it was decided to slip Fedora 21 Beta release
by one week due to unresolved blocker bugs [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, Oct 30, 17:00 UTC at
#fedora-meeting-2 channel on FreeNode.

Jaroslav

[1] http://qa.fedoraproject.org/blockerbugs/milestone/21/beta/buglist
[2] 
http://meetbot.fedoraproject.org/fedora-meeting-2/2014-10-24/f21_beta_gono-go_meeting.2014-10-24-17.01.html
[3] https://fedoraproject.org/wiki/Releases/21/Schedule
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 21 Beta Go/No-Go Meeting, Thursday, October 23 @ 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 21 Beta.

Thursday, October 23, 2014 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 decision but meeting itself is held in any case. 

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

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

Fedora 21 Beta blocker bug status report by adamw
https://lists.fedoraproject.org/pipermail/devel/2014-October/203591.html

We have very tight schedule this time to make Fedora 21 release this
year, please help us with blocker bugs, testing and other tasks needed
for successful release. So far, many reviews says F21 Alpha is the best
Fedora ever!

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

Fedora 21 Alpha status is Go, release on September 23, 2014

[Jaroslav Reznik]

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

Fedora 21 Alpha will be publicly available on Tuesday, September 23, 2014.

That's one small step for mankind but one giant leap for Fedora - the
first release on the way towards Fedora.Next!

Meeting details can be seen here:
Minutes: http://bit.ly/1pkIobe
Log: http://bit.ly/XpyZIO

Thanks everyone!
Jaroslav

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

F22 Self Contained Change: BIND version 9.10

[Jaroslav Reznik]

= Proposed Self Contained Change: BIND version 9.10 = 
https://fedoraproject.org/wiki/Changes/BIND_9.10

Change owner(s): Tomas Hozza tho...@redhat.com

BIND (Berkeley Internet Name Domain) version 9.10 is the latest stable major 
update of the widely used DNS server. Besides new features, some settings 
defaults have changed since the previous major version (9.9). 

== Detailed Description ==

FULL BIND 9.10 RELEASE NOTES [1]

=== New features ===
* New zone file format, map, stores zone data in a format that can be mapped 
directly into memory, allowing significantly faster zone loading.
* New tool delv (domain entity lookup and validation) with dig-like 
semantics for looking up DNS data and performing internal DNSSEC validation 
has been added.
* New prefetch option improving the recursive resolver performance has been 
added.
* Improved EDNS processing allowing better resolver performance.
* Substantial improvements have been made in response-policy zone (RPZ) 
performance.
* ACLs can now be specified based on geographic location using the MaxMind 
GeoIP databases.
* The statistics channel can now provide data in JSON format as well as XML.
* The new in-view zone option allows zone data to be shared between views, 
so that multiple views can serve the same zones authoritatively without 
storing multiple copies in memory.
* Native PKCS#11 API has been added. This allows BIND 9 cryptography functions 
to use the PKCS#11 API natively, so that BIND can drive a cryptographic 
hardware service module (HSM) directly instead of using a modified OpenSSL as 
an intermediary (Native PKCS#11 is known to work with the Thales nShield HSM 
and with SoftHSM version 2 from the Open DNSSEC project.).
* New tool named-rrchecker can be used to check the syntax of individual 
resource records, and optionally to convert them to the format used for 
unknown record types.
* New tool dnssec-importkey allows offline DNSSEC keys (i.e., keys whose 
private data is not stored on the system on which named is running) to be 
published or deleted on schedule using automatic DNSKEY management.
* Network interfaces are re-scanned automatically whenever they change.  Use 
automatic-interface-scan no; to disable this feature.
** Added rndc scan to trigger an interface scan manually.
* New max-zone-ttl option enforces maximum TTLs for zones. If loading a zone 
containing a higher TTL, the load fails. DDNS updates with higher TTLs are 
accepted but the TTL is truncated.
* Multiple DLZ databases can now be configured, and are searched in order to 
find one that can answer an incoming query.
* named-checkzone and named-compilezone can now read journal files.

=== Feature changes ===
* The version 3 XML schema for the statistics channel, including new 
statistics and a flattened XML tree for faster parsing, is no longer optional. 
The version 2 XML schema is now deprecated.
* named now listens on IPv6 as well as IPv4 interfaces by default.
* The internal and export versions of the BIND libraries (libisc, libdns, etc) 
have been unified so that external library clients can use the same libraries 
as BIND itself.
* The default setting for the -U option (setting the number of UDP listeners 
per interface) has been adjusted to improve performance.
* Adaptive mutex locks are now used on systems which support them.
* rndc flushtree now flushes matching records from the address database and 
bad cache as well as the DNS cache. (Previously only the DNS cache was 
flushed.)
* The isc_bitstring API is no longer used and has been removed from the libisc 
library.
* The timestamps included in RRSIG records can now be read as integers 
indicating the number of seconds since the UNIX epoch, in addition to being 
read as formatted dates in MMDDHHMMSS format.

== Scope ==
* Proposal owners: Rebase the package to the latest 9.10 minor version and 
resolve possible packaging issues. (Also rebuild all currently existing 
dependent packages listed below)

* Other developers: Rebuild dependent packages (dhcp, dnsperf, bind-dyndb-
ldap) 
** Owner of this feature is co-maintainer of all dependent packages. He will 
do the necessary rebuilds himself in cooperation with dependent packages 
owners.

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

[1] http://ftp.isc.org/isc/bind9/9.10.0-P2/RELEASE-NOTES-BIND-9.10.0-P2.txt
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Reminder: Fedora 21 Alpha Go/No-Go Meeting #2, today @ 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 21 Alpha.

Thursday, September 11, 2014 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. As we do not have RC yet, this meeting will be
aiming on coordination of missing pieces for Alpha.

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

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

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

Fedora 21 Alpha to slip by one week

[Jaroslav Reznik]

Today at Go/No-Go meeting it was decided to slip Fedora 21 Alpha release
by one week due to unresolved blocker bugs [1] and no release candidate 
available. 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, Sep 11, the same time at
#fedora-meeting-2 channel.

[1] http://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist
[2] 
http://meetbot.fedoraproject.org/fedora-meeting-2/2014-09-04/f21_alpha_gono-go_meeting.2014-09-04-17.01.html
[3] https://fedoraproject.org/wiki/Releases/21/Schedule
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 21 Alpha Go/No-Go Meeting, Thursday, September 04 @ 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 21 Alpha.

Thursday, September 04, 2014 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.

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

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

Jaroslav

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

Changes in schedule - Fedora 21 to slip three weeks

[Jaroslav Reznik]

Greetings,!
as you probably noticed, Fedora 21 is still not frozen (Alpha Change
Deadline was planned for this Tuesday, 2014-07-22), due to several
issues we hit while working on the Alpha release (incomplete test
composes etc).

There's also Flock being held in the beginning of August (2014-08-06 -
2014-08-09) [1] in Prague and many contributors would like to enjoy
this event instead of being trapped in the release windmills. I hope
to meet you all there!  

Therefore, on yesterday's FESCo meeting (2014-07-23), it was decided [2]
to slip Fedora 21 by three weeks including the Alpha Change Deadline.

2014-08-12 Alpha Change Deadline
2014-08-26 Alpha Release

With final Fedora 21 release planned on 2014-11-04. For more details,
see updated Fedora 21 Schedule [3].

Jaroslav

[1] http://flocktofedora.com/
[2] https://fedorahosted.org/fesco/ticket/1178#comment:53
[3] https://fedoraproject.org/wiki/Releases/21/Schedule
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Elections Results for Summer 2014 FESCo Special Election

[Jaroslav Reznik]

Greetings, all!

The elections for the Fedora Engineering Steering Committee (FESCo)
Summer 2014 Special Election have concluded, and the results are
shown below.

FESCo is electing 3 seats this time. A total of 195 ballots were
cast, meaning a candidate could accumulate up to 975 votes (195 *
5). The results for the FESCo elections are as follows:

# votes |  name  
- +--
629 | Josh Boyer (FAS: jwboyer, IRC: jwb)
548 | Kalev Lember (FAS: kalev, IRC: kalev)
541 | Tomas Hozza (FAS: thozza, IRC: thozza)
---
463 | Lukáš Nykrýn (FAS: lnykryn, IRC: lnykryn)
362 | David King (FAS: amigadave, IRC: amigadave)

As these elections will fill the seats for the remainder of 
the term, Josh Boyer and Kalev Lember are each elected to FESCo 
until next spring. Tomas Hozza until after the F21 release this
fall.

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

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

Re: Elections Results for Summer 2014 FESCo Special Election

[Jaroslav Reznik]

One correction - while updating Wiki with the newly elected FESCo
members I found out the initial announcement was incorrect and only
one seat is available for the full F21/F22 term.

Josh Boyer is elected for full F21/F22 term as replacement for
Toshio Kurotami (who was elected on February 2014) [1].

Kalev Lember and Tomas Hozza until after the F21 release this fall
(F20/F21 term) as replacement for Peter Jones and Bill Nottingham
(elected on June 2013) [2].

Sorry for mistake...

Jaroslav

[1] https://admin.fedoraproject.org/voting/results/fescof21
[2] https://admin.fedoraproject.org/voting/results/fesco-f20

- Original Message -
 Greetings, all!
 
 The elections for the Fedora Engineering Steering Committee (FESCo)
 Summer 2014 Special Election have concluded, and the results are
 shown below.
 
 FESCo is electing 3 seats this time. A total of 195 ballots were
 cast, meaning a candidate could accumulate up to 975 votes (195 *
 5). The results for the FESCo elections are as follows:
 
 # votes |  name
 - +--
 629 | Josh Boyer (FAS: jwboyer, IRC: jwb)
 548 | Kalev Lember (FAS: kalev, IRC: kalev)
 541 | Tomas Hozza (FAS: thozza, IRC: thozza)
 ---
 463 | Lukáš Nykrýn (FAS: lnykryn, IRC: lnykryn)
 362 | David King (FAS: amigadave, IRC: amigadave)
 
 As these elections will fill the seats for the remainder of
 the term, Josh Boyer and Kalev Lember are each elected to FESCo
 until next spring. Tomas Hozza until after the F21 release this
 fall.
 
 Congratulations to the winning candidates, and thank you all
 candidates for running this elections!
 
 Jaroslav
 --
 announce mailing list
 annou...@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/announce
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 21 Changes Freeze in two weeks - 2014-07-08

[Jaroslav Reznik]

Greetings!
Fedora 21 Changes Freeze is currently scheduled to no earlier than
2014-07-08 [1] and we're getting closer to this date. Btw this is
also Fedora 21 Branch from Rawhide date.

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 Freeze.

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

As Fedora 21 scope is really huge, progress at Changes Freeze 
will help us to think about where we are and what we can do for
this release. This applies not only to change owners but to all
other groups - especially from WGs and teams involved in Fedora
re-design. Let us know if you're blocked, if you need any help
etc. or just to say, hey, we're ready :).

Jaroslav

[1] https://fedoraproject.org/wiki/Releases/21/Schedule 
[2] http://bit.ly/f21changesfreeze
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F22 System Wide Change: Replace Yum With DNF

[Jaroslav Reznik]

= Proposed System Wide Change: Replace Yum With DNF = 
https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF

Note: This is Fedora 22 proposal!

Change owner(s): Aleš Kozumplík kozump...@gmail.com

Make DNF/Yum4 the new default packaging tool in F22. 

== Detailed Description ==
DNF was forked from Yum in January 2012 and available for experimenting in 
Fedora since release 18 [1]. The project is now fully capable of replacing Yum 
in new Fedora installations. We want DNF to become the new default packaging 
tool in Fedora 22. This entails:

* letting system administrators (including users who routinely manage their 
packages using the legacy Yum) perform all common packaging operations using 
DNF, with no or minimal and documented [2] change to the command syntax, apart 
from replacing the command name. (done)
* providing implementation of Anaconda backend so system can be bootstrapped 
completely without using legacy Yum. (done)
* providing alternative to all Yum plugins from yum-utils (ongoing)
* providing alternative to all release engineering tools (repoquery, bodhi 
etc.) from yum-utils (ongoing)
* being ready/having the capacity to help out users with migration of their 
custom legacy plugins and extensions to DNF. The solid API documentation [3] 
we provide is of great advantage here. (ongoing)

In practice, the change implies:
* Anaconda installs the system using the DNF backend (with no special 
switches)
* package 'dnf' is installed by default (referenced by the base comps groups)
* package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum 
and provides its own code/usr/bin/yum/code, a short script that redirects 
to code/usr/bin/dnf/code with an appropriate warning message that DNF is 
the preferred package manager now. Notice that upgrading F21 to F22 will not 
cause the compat package to be installed so will not disturb any upgrading 
users.

== Scope ==
This change will be completely transparent for users that use only the 
graphical package management tools. For anybody using the command line 
directly there will be some differences, but all the important operations are 
available with DNF, using the same CLI syntax.

* Proposal owners: The majority of tasks on this change are completed. Some 
plugins and API calls still need to be added. The Anaconda payload 
implementation needs more testing, Fedora Test Day for this is pending.

* Other developers: We provide the paylaod implementation for Anaconda 
developers. Developers of other extensions and developers of plugins that are 
not part of yum-utils will have to update their code.

* Release engineering: Release engineering tools that are internal to the 
releng teams and not part of yum-utils will need modifications to migrate to 
the DNF API.

* Policies and guidelines: None at the moment.

[1] https://fedoraproject.org/wiki/Features/DNF
[2] http://akozumpl.github.io/dnf/cli_vs_yum.html
[3] http://akozumpl.github.io/dnf/api.html 
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 Self Contained Change: Review Board 2.0

[Jaroslav Reznik]

= Proposed Self Contained Change: Review Board 2.0 = 
https://fedoraproject.org/wiki/Changes/ReviewBoard2

Change owner(s):  Stephen Gallagher sgall...@redhat.com

Review Board is a powerful tool for managing patch reviews. 

== Detailed Description ==
Review Board integrates with many types of repository (svn, git, mercurial, 
perforce and more) as well as popular hosting environments such as Fedora 
Hosted, Github and Bitbucket. It provides a powerful and clean interface to 
managing patches for review.

Review Board 2.0 adds the ability to post committed changes from a branch 
directly from the web UI, adds review of text file attachments, greatly 
extends the capabilities of the public API and extension framework, and offers 
significant performance improvements, usability enhancements, and visual 
cleanups. 

== Scope ==
* Proposal owners: Review Board 2.0 RC3 is in Rawhide today and will be 
upgraded to 2.0 final when it is released (expected by the end of May, 2014) 
* 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

F21 Self Contained Change: Serf 0.4.5

[Jaroslav Reznik]

= Proposed Self Contained Change: Serf 0.4.5 =
https://fedoraproject.org/wiki/Changes/Serf_0.4.5

Change owner(s): Jeff Schroeder jeffschroe...@computer.org

Serf [1] is a decentralized solution for service discovery and orchestration 
that is lightweight, highly available, and fault tolerant. This change is to 
package serf for Fedora users. 

== Detailed Description ==
This is the first set of dependencies for serf. After these are merged, the 
second set of dependencies can be independently reviewed and merged. Finally, 
once all of the dependencies are available in fedora, serf can be packaged. 

https://fedoraproject.org/wiki/Changes/Serf_0.4.5#Detailed_Description

== Scope ==
* Proposal owners: Package dependencies and serf itself.
* 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.serfdom.io/
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 System Wide Change: Application Installer Continued

[Jaroslav Reznik]

= Proposed System Wide Change:  Application Installer Continued = 
https://fedoraproject.org/wiki/Changes/AppInstallerContinued

Change owner(s): Richard Hughes for the implementation, Ryan Lerch and Allan 
Day for the design rhug...@redhat.com

Fully integrate the new application installer with Fedora, and complete its 
feature set.

== Detailed Description ==
gnome-software will support installing system add-ons such as fonts and 
codecs. It will show additional metadata for applications: screenshots, 
ratings, other details. We will also work with the Fedora infrastructure team 
to obtain the metadata online for all applications instead of shipping it 
statically for a limited set.

The metadata for application needs to be expanded and its quality monitored. 
Screenshots need to be taken or updated.

The update monitoring and downloading functionality will be moved from the 
gnome-settings-daemon updates plugin into gnome-software. To implement this, 
gnome-software will be turned into a session service, and the updates plugin 
will be removed from gnome-settings-daemon.

A gnome-shell search provider will offer installable applications as search 
results.

gnome-software will allow to customize the app folders that are displayed in 
the gnome-shell app picker.

We will switch to using the hawkey PackageKit backend.

We also want to try to integrate Fedora accounts for collecting ratings and 
installed package lists, but this requires coordination with the Fedora 
infrastructure team.

The priorities for gnome-software 3.12 are also tracked upstream [1].

== Scope ==
* Proposal owners:
** Add add-on support (DONE)
** Display additional metadata in details page (DONE)
** Implement a GNOME shell search provider (DONE)
** Turn gnome-software into a session service and take over updates plugin 
functionality (DONE)
** Implement app folder configuration (DONE)
** Turn search into search-as-you-type
** Implement Fedora account integration
** Replace old gnome-packagekit package installation dialogs (DONE)
** Switch PackageKit to use the hawkey backend (DONE)

* Infrastructure:
** Extract metadata and icons when building packages in koji [2]
** Make metadata available for packaged applications in Fedora
** Make application icons available
** Make application screenshots available
** Make it possible to create Fedora accounts from the client-side
** Allow storing small amount of per-user data for users with a Fedora account

* Application packagers
** Add application metadata to their packages, ideally sending it upstream

* Marketing, documentation
** Assist with review and quality control of application metadata
** Assist with selecting featured applications

* Policies and guidelines:
** We want to use the hawkey backend in PackageKit while the default 
commandline utility is still yum; this kind of separation was rejected by 
Fesco in the past for zif, will need to ask again (DONE, approved 
conditionally)
** The packaging guidelines for applications should be updated to require 
application metadata in addition to a desktop file
** The update experience will also benefit from proposed changes to batch 
updates, but batched updates are not a strict requirement for the new app 
installer

[1] https://wiki.gnome.org/Apps/Software#Priorities_.26_Plans 
[2] https://fedorahosted.org/rel-eng/ticket/5721 rel-eng ticket
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 System Wide Change: Wayland

[Jaroslav Reznik]

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

Change owner(s): Matthias Clasen and the desktop team mcla...@redhat.com, 
desk...@lists.fedoraproject.org

Port the GNOME desktop to Wayland. 

== Detailed Description ==
GNOME is being ported to Wayland. In particular GNOME shell is changed to run 
as a Wayland compositor instead of an X11 compositor. Other components of 
GNOME that currently talk directly to the X server, such as gnome-settings-
daemon or gnome-control-center, will be ported to corresponding Wayland 
interfaces. Many GTK+ applications will just work, using the existing Wayland 
backend. Applications that make use of X-specific APIs will be supported with 
the xwayland X server, which is started on demand. gdm will be changed to 
support both Wayland-based sessions and X-based sessions.

This change is targeted at F21. For F20, we aim for having an experimental 
GNOME shell Wayland compositor available, without necessarily having all the 
surrounding desktop infrastructure ported. To avoid destabilizing the X 
compositor, mutter will ship two separate libraries, and gnome-shell will ship 
two binaries that will link against them. Concretely, we plan to have a 
separate mutter-wayland package.

For more details, see this page [1].

== Scope ==
* Proposal owners:
** Port GNOME shell to be a Wayland compositor
** Implement Wayland equivalents for X11 APIs such as XRANDR, XI2 and 
accessibility features
** Port gnome-settings-daemon, gnome-control-center, gnome-desktop from X11 
APIs to Wayland equivalents
** Enable gdm to launch Wayland sessions
** Complete the GTK+ Wayland backend to be on par with the X11 backend
** Package mutter-wayland as a separate package review [2] (DONE)

* Other developers:
** The X team needs to improve xwayland to be good enough for all X11 
application - in practice this means we need X 1.16
** The X team needs to cooperate with us in reimplementing some X11 APIs
** The X team needs to package libevdev (DONE)
** The X team needs to package libinput (DONE)
** It is not necessary for all spins or all desktop environments in Fedora to 
switch to Wayland at the same time (or ever)

* Release engineering:
** No tasks anticipated

* Policies and guidelines: 
** Once we have a basic Wayland-based GNOME session, it would be good to 
encourage testers and packagers to test their applications under Wayland
** For applications that are known not to work under Wayland, we will need 
guidelines for how to ensure that they will transparently run under xwayland

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

F21 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

Change owner(s): P J P p...@fedoraproject.org, Pavel Šimerda 
pav...@pavlix.net, Tomas Hozza tho...@redhat.com

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. 

This change was submitted after the Submission deadline.

== 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 [4]

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

[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 
[4] https://lists.fedoraproject.org/pipermail/devel/2014-April/197848.html

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

F21 Self Contained Change: Docker Cloud Image

[Jaroslav Reznik]

= Proposed Self Contained Change: Docker Cloud Image =
https://fedoraproject.org/wiki/Changes/Docker_Cloud_Image

Change owner(s): Cloud SIG / Sandro Mathys r...@fedoraproject.org

New Fedora product: Fedora Docker Cloud Image - Docker host ready to go. 

== Detailed Description ==
Fedora Cloud agreed to make a base image plus several tailored to specific 
purposes. This is one of the tailored ones — Docker host ready to go. While 
basically that simply means only just adding docker-io to the base image, this 
is (also) intended to be our response to CoreOS. Therefore, depending on 
further discussion and user input, we might also add etcd [1] and fleet [2] to 
the mix.

Furthermore, the Cloud SIG considers this their most radical image, riding the 
very front of the leading edge. (Yeehaw!) Several approaches (read: bonus 
objectives) are under consideration but not crucial to the product itself: 

* Fedora Atomic Initiative [3] (aka rpm-ostree) to allow for atomic updates. 
We might further choose to remove yum/dnf from the image in favor of ostree.
* Replace cloud-init with min-metadata-service, CoreOS' cloud-init or other 
alternatives. We'd like to find a leaner solution (read: less Requires) and 
one that is better (or easier) tailored to Fedora.
* Remove Python from this image to reduce the footprint. Note, that this can 
only be achieved if yum/dnf AND cloud-init are replaced by other solutions as 
explained in the above points. 

It should be noted that most of these tools are currently under heavy 
construction but might be ready in time. If they are, it's still up to 
discussion whether they will be included. If they aren't, we might punt them 
to F22 or later. Either way, they won't impact the completion of this change's 
main goals and are only listed for completeness' sake. 

== Scope ==
* Proposal owners: Regarding the core objective, it's just about creating a 
new kickstart file (probably even %include-ing the base one) add some minor 
stuff and make sure it gets built into a new image. Also, for added security, 
we'd like to see Docker and SELinux integrate better. There's already work 
going on about this.
** The bonus objectives (i.e. leading edge approaches) further require:
*** ostree to work with SELinux
*** Creating a filesystem tree for ostree that equals the filesystem of the 
image as created by traditional means
*** min-metadata-service to gain the ability to execute scripts just like 
cloud-init does
*** CoreOS' cloud-init or other alternatives to be packages (and possibly 
tailored) 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] https://github.com/coreos/etcd
[2] https://github.com/coreos/fleet
[3] http://rpm-ostree.cloud.fedoraproject.org/
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 Self Contained Change: LVM Cache Logical Volumes

[Jaroslav Reznik]

= Proposed Self Contained Change: LVM Cache Logical Volumes = 
https://fedoraproject.org/wiki/Changes/Cache_Logical_Volumes

Change owner(s):  Alasdair G. Kergon a...@redhat.com, David Cantrell 
dcant...@redhat.com, Dave Lehman dleh...@fedoraproject.org

LVM can now use fast block devices (e.g. SSDs and PCIe Flash) to improve the 
performance of larger but slower block devices. These hierarchical or layered 
logical volumes are called Cache Logical Volumes in LVM. 

== Detailed Description ==
LVM is now capable of using fast block devices (e.g. SSDs) as write-back or 
write-though caches for larger slower block devices. Users can create cache 
logical volumes to improve the performance of their existing logical volumes 
or create new cache logical volumes composed of a small and fast device 
coupled with a large and slow device. These cache logical volumes can be used 
with most LVM segment types, including RAID 1/4/5/6/10, linear, stripe and 
thin pools. 

== Scope ==
* Proposal owners:
The LVM team must deliver the lvm2 package implementing cache LV (already 
included in release 2.02.106)

* Other developers: N/A (not a System Wide Change) 
The Anaconda team must develop a UI for configuring cache LVs during 
installation.  If Anaconda support is not provided, users will have to 
configure cache LVs after installation or by dropping into a command line.  
Also, Anaconda could fail if installing a new OS onto an existing cache LV if 
support is not provided. 

Anaconda team signed as co-owners of this Change.

The dracut team must provide boot support.  If dracut does not provide 
support, cache LVs will not be usable as root devices.

* 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

F21 Self Contained Change: 64bit ARM emulation on x86

[Jaroslav Reznik]

= Proposed Self Contained Change: 64bit ARM emulation on x86 = 
https://fedoraproject.org/wiki/Changes/Virt_64bit_ARM_on_x86

Change owner(s): Cole Robinson crobi...@redhat.com

Allow running 64bit ARM (AArch64) VMs on x86 hosts using standard the standard 
qemu and libvirt stack, as well as end user tools like virt-manager and virt-
install. 

== Detailed Description ==
Work is quickly under way in upstream qemu to enable full AArch64 system 
emulation with qemu-system-aarch64. This 'Change' will track landing that work 
in Fedora 21, in addition to the higher level bits in libvirt and virt-manager 
to ensure it's all usable with standard tools.

To be clear, this stuff is still in progress in upstream qemu and I'm not 
really involved with the development, so it's very much 'wait and see' to 
determine if the actual emulation bits will make it in time for Fedora 21. 

== Scope ==
* Proposal owners: 
1. Wait and see if the qemu bits will land in time for Fedora 21.
2. Once that takes shape, figure out the remaining work to get libvirt/virt-
manager to support it (shouldn't be anything too drastic)
3. Document it all 
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 Self Contained Change: libzhuyin

[Jaroslav Reznik]

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

Change owner(s): Peng Wu p...@redhat.com

An new intelligent input method for Traditional Chinese (Taiwan) provided by 
libzhuyin using 3-grams to give better conversion than ibus-chewing with 
libchewing. 

== Detailed Description ==
This is a Traditional Chinese equivalent of libpinyin [1] and ibus-libpinyin 
[2] which replaced ibus-pinyin as default in Fedora 18.

The libzhuyin project provides the core algorithms for intelligent sentence-
based Chinese Zhuyin input methods, and is already packaged in Fedora. With 
the assistant of libzhuyin, the user can correctly input some words of Chinese 
sentence, and then libzhuyin try to figure out the rest of the inputting 
sentence for the user. 

== Scope ==
* Proposal owner:
** Develop the ibus-libzhuyin project in order for users to use libzhuyin 
backend.
** Package ibus-libzhuyin in Fedora
** Test, improve, and fix bugs
** Change default IME for Traditional Chinese (Taiwan) from ibus-chewing to 
ibus-libzhuyin.

* 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/libpinyin
[2] https://fedoraproject.org/wiki/Features/ibus-libpinyin
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 System Wide Change: SCL

[Jaroslav Reznik]

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

Change owner(s): Marcela Mašláňová mmasl...@redhat.com

SCL - Software Collections - are popular packaging format above rpm. Let's 
enable them for Fedora. More details on upstream page [1]. 

== Detailed Description ==
My first draft [2] is obsoleted by current state of SCL, Copr... I would keep 
the SCL workflow simple as possible.

Playground repo

1. Build SCL in Copr
2. Add SCL into Playground repo

Fedora main repo

0. Build SCL in Copr (or use existing SCL)
1. Do standard package review
2. Upload packages into git - specific branch based on Fedora version and name 
of collection. For stable repo we must be able to replicate builds from git 
repo, which Fedora own.
3. Build SCL in koji or magically add SCL builds from Copr (depends on 
preference of releng)

SCL living on Copr can be good candidates for inclusion in Fedora. Maintainer 
of such SCL must be able create Change proposal for his collection. Review of 
packages in the collection should depend on repository (Playground - almost no 
rules, Fedora - standard guidelines). 

== Scope ==
* Proposal owners: 
0. Approve SCL guidelines by FPC
1. Include one collection into Fedora Playground repository or into main 
Fedora repository (probably the one wanted by Cloud WG). It might be this one 
rebuild for Fedora [3]. Updates of some gems or addition of other gems might 
be needed. Review by Cloud projects is needed.

* Other developers: If SCL is in Fedora, maybe some other project can use it 
for their work. 

* Release engineering: Magically add SCLs builds into compose or set up koji 
for SCLs. 

* Policies and guidelines:
https://fedorahosted.org/fpc/ticket/339
https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29 


[1] https://www.softwarecollections.org/en/
[2] https://fedoraproject.org/wiki/User:Mmaslano/SCLinFedora 
[3] http://copr.fedoraproject.org/coprs/rhscl/ruby193/
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 Self Contained Change: Move to ImageFactory For Cloud Image Creation

[Jaroslav Reznik]

= Proposed Self Contained Change: Move to ImageFactory For Cloud Image 
Creation = 
https://fedoraproject.org/wiki/Changes/Move_to_ImageFactory_For_Cloud_Image_Creation

Change owner(s):  Ian McLeod imcl...@redhat.com, Dennis Gilmore 
dgilm...@fedoraproject.org 

Create images using Anaconda in Koji rather than appliance-creator. Allows 
non-scratch builds with fedmsg integration for upload service, and also could 
produce official Docker images. 

== Detailed Description ==
Jay Greguske recently added a feature to koji that allows it to create full 
system disk images using Image Factory. These images can be output both as raw 
and qcow2 disk images, as well as OVA/OVF bundles compatible with OVirt, 
VMWare and RHEV-M. They are created by running Anaconda kickstart installs in 
virt containers and then packaging/encapsulating the results. 

== Scope ==
* Proposal owners: The Image Factory support in Fedora koji has already landed 
and images are already being built using this technique.  The work for F21 
should mainly involve making sure that the existing cloud kickstart files work 
when run directly by Anaconda and making any chances needed to ensure that 
they do.
* 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

F21 Self Contained Change: Remote Journal Logging

[Jaroslav Reznik]

= Proposed Self Contained Change: Remote Journal Logging = 
https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging

Change owner(s): Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl

Systemd journal can be configured to forward events to a remote server. 
Entries are forwarded including full metadata, and are stored in normal 
journal files, identically to locally generated logs. 

== Detailed Description ==
Systemd's journal currently provides a replacement for most functionality 
offered by traditional syslog daemons,
with two notable exceptions: arbitrary filtering of messages and forwarding of 
messages over the network. This Change targets the latter.

The high-level goal is to have a mechanism where journal logging can be 
extended
to keep a copy of logs on a remote server, without requiring any maintenance, 
done
fairly efficiently and in a secure way.

Two new daemons are added as part of the systemd package:
* on the receiver side systemd-journal-remote accepts messages in the Journal 
Export Format [1]. The export format is a simple serialization of journal 
entries, supporting both text and binary fields. This means that the messages 
are transferred intact, apart from the cursors, which specify the location 
in the journal file. Received entries are stored in local journal files 
underneath /var/log/journal. Those files are subject to normal journald rules 
for rotation, and the older ones will be removed as necessary to stay within 
disk usage limits. Once entries have been written to the journal file, they 
can be read using journalctl and the journal APIs, and are available to all 
clients, e.g. Gnome Logs [2].

* on the sender side systemd-journal-upload is a journal client, which exports 
all available journal messages and uploads them over the network. The (local) 
cursor of the last message successfully forwarded is stored on disk, so when 
systemd-journal-upload is restarted (possibly after a reboot of the machine), 
it will send all recent messages found in the journal and then new ones as 
they arrive.

The communication between the two daemons is done over standard HTTPS, 
following rather simple rules, so it is possible to create alternate 
implementations without much work. For example, curl can be easily used to 
upload journal entries from a text file containing entries in the export 
format. Basically, the data are sent in an HTTP POST to /upload with Content-
Type: application/vnd.fdo.journal. When doing live forwarding, the size of 
the transfer cannot be known in advance, so Transfer-Encoding: chunked is 
used. All communication is encrypted, and the identity of both sides is 
verified by checking for appropriate signatures on the certificates.

== Scope ==
* Proposal owners:
The code in systemd for systemd-journal-remote and systemd-journal-upload will 
have to be added. The first is done, and has already been released in the 
latest Rawhide systemd package. The second is mostly done, and will be 
submitted upstream soon. Necessary units will have to be created, and a 
location with suitable permissions will have to be created so that systemd-
journal-remote can run unprivileged. This means that systemd-journal-remote 
should probably be packaged as a separate subpackage, similarly to systemd-
journal-gatewayd. systemd-journal-upload uses libcurl, and thus should be also 
packaged as a separate subpackage to avoid introducing a new dependency for 
systemd.

Suitable defaults for timeouts for transfers and maximum accepted entry sizes 
have to be chosen.

A port will have to be picked: systemd-journal-gatewayd uses 19531, so 
systemd-journal-remote should probably use 19532.

Two new users will have to be created when the packages are installed.

* 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.freedesktop.org/wiki/Software/systemd/export/
[2] https://wiki.gnome.org/Apps/Logs
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 Self Contained Change: SDDM as the default KDE display manager instead of KDM

[Jaroslav Reznik]

= Proposed Self Contained Change: SDDM as the default KDE display manager 
instead of KDM = 
https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM

Change owner(s): Martin Briza mbr...@redhat.com  KDE SIG

Retire KDM as the default display manager of the KDE Fedora Spin in favor of 
SDDM.

== Detailed Description ==
As described in many articles and discussions, KDM is nearing its end of life 
and it's time we decided upon the successor.

I'm proposing to switch to SDDM, which is a new project that suits our needs 
perfectly despite its immaturity:

As of July 2013, KDM's maintenance consists of bugfixes for the most painful 
bugs, consisting of only about 20 actual commits to the repository in last two 
years (excluding translation, themes and merges), adding many new features 
would require major changes to a lot of the code and there is no active 
maintainer.

SDDM is written in C++11/Qt5 (compared to the bits of XDM in KDM), compilable 
against Qt4, supports QtQuick theming and its upstream is quite active.

Compared to the current DM, KDM, it currently lacks a few features (such as 
XDMCP) but adds some other ones (QtQuick themes) or is currently adding them 
(Keyboard layout switching in the greeter). 

== Scope ==
* Proposal owners:
** Create sddm and sddm-kcm packages.
** Change kde-settings and the spin-kickstarts to provide SDDM package instead 
of KDM
** (eventually) exclude KDM from the kde-workspace package 
* 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

F21 System Wide Change: Ruby193 in SCL

[Jaroslav Reznik]

= Proposed System Wide Change: Ruby193 in SCL = 
https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL

Change owner(s): Marcela Mašláňová mmasl...@redhat.com

Ruby 1.9.3 with Rails 3.2.8 is still commonly used by many projects. Let's 
provide Ruby and Rails in SCL even for Fedora. Rails depends on exact v8 
version, which means v8 3.14 must have also their own SCL as part of the SCL. 

== Detailed Description ==
Ruby 1.9.3 with Rails 3.2.8 is still commonly used by many projects. This 
change aims to provide Ruby 1.9.3 and Rails 3.2.8. Rails depends on exact v8 
version, which means v8 3.14 must have also their own SCL as part of this 
change. 

== Scope ==
* Proposal owners: Marcela
** create the actual collections, at start in Copr and on SCL upstream [1]

* Other developers: Cloud WG
** test SCL with their apps

* Release engineering:
** create branches in dist-git
** add Ruby193 packages into compose

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

F21 Self Contained Change: Apache Pig

[Jaroslav Reznik]

= Proposed Self Contained Change: Apache Pig = 
https://fedoraproject.org/wiki/Changes/ApachePig

Change owner(s): Peter MacKinnon pmack...@redhat.com

Apache Pig [1] is a data analysis tool built on top of Apache Hadoop. 

== Detailed Description ==
Apache Pig is a platform for analysing large data sets that consists of a 
high-level language for expressing data analysis programs, coupled with 
infrastructure for evaluating these programs. The salient property of Pig 
programs is that their structure is amenable to substantial parallelization, 
which in turns enables them to handle very large data sets. 

== Scope ==
* Proposal owners: The Pig [2] package has been accepted into Fedora and 
provides all the functionality from the upstream release with the exception of 
jython (version) and parquet (unpackaged) 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) 

[1] http://pig.apache.org/
[2] http://pkgs.fedoraproject.org/cgit/pig.git
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 Self Contained Change: Big Data Cloud Image

[Jaroslav Reznik]

= Proposed Self Contained Change: Big Data Cloud Image = 
https://fedoraproject.org/wiki/Changes/Big_Data_Cloud_Image

Change owner(s): Julien Eid jei...@gmail.com , Haïkel Guémar 
karlthered_gmail_com 

Fedora Cloud agreed to make a base image plus several tailored to specific 
purposes. This is one of the tailored ones, produced in collaboration with the 
Big Data SIG. 

== Detailed Description ==
Fedora Cloud agreed to make a base image plus several tailored to specific 
purposes. This is one of the tailored ones, produced in collaboration with the 
Big Data SIG. 

== Scope ==
* Proposal owners: The developers must get a kickstart ready for a big data 
image that has the Hadoop ecosystem installed and configured for changes that 
distributed big data servers typically need. The developers may also if time 
is permitting work on a second big data image centering around the Apache 
Mesos ecosystem. The change does not affect large part of the distribution and 
does not block or affect other parts of the distribution. 
* Other developers: N/A (not a System Wide Change) 
* Release engineering: not a System Wide Change, but there will be a new image 
for release engineering to produce and handle. 
* 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

F21 Self Contained Change: Docker Container Image

[Jaroslav Reznik]

= Proposed Self Contained Change: Docker Container Image = 
https://fedoraproject.org/wiki/Changes/Docker_Container_Image

Change owner(s):  Lokesh Mandvekar l...@fedoraproject.org, Dennis Gilmore 
den...@ausil.us

This is Fedora running inside Docker. Currently, there are non-official images 
in the docker index, but we'd like them to really come out of release 
engineering. 

== Detailed Description ==
The public docker registry [1] hosts many fedora images [2] including an 
unprefixed (semi-official) image [3]. However, this image doesn't have rel-eng 
approval which would be required for a fully official image. 

== Scope ==
* Proposal owners: The proposal owner needs to build the image tarballs with 
the official kickstart scripts and make them available to docker's stackbrew 
repo, which is used by the Docker maintainers to build unprefixed images.

Release Engineering approval/intervention would be needed at some point 
(details still TBD)

* Other developers: N/A (not a System Wide Change) 
* Release engineering: Official Release Engineering image approval. Process 
still TBD. 
* Policies and guidelines: N/A (not a System Wide Change) 

[1] http://index.docker.io/
[2] https://index.docker.io/search?q=fedora
[3] https://index.docker.io/_/fedora/
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 System Wide Change: TCL/TK 8.6

[Jaroslav Reznik]

= Proposed System Wide Change: TCL/TK 8.6 = 
https://fedoraproject.org/wiki/Changes/f21tcl86

Change owner(s): Jaroslav Škarvada jskar...@redhat.com

Update tcl/tk from 8.5 to 8.6 in Fedora 21. 

== Detailed Description ==
Latest stable TCL/TK is version 8.6.1, currently there is version 8.5.13 in 
Fedora. The aim of this change is to update the TCL/TK to latest stable 
upstream release.

== Scope ==
* Proposal owners:  Update spec file and build in koji (scratch builds / 
private branch already exists), see RHBZ #889201 for details.
* Other developers: Cca. 60 other packages need to be revised, updated, 
patched or rebuild (most patches already exist), see RHBZ #889201 for details.
* Release engineering:  Tag creation, re-tagging, (tag f21-tcl already 
exists), see RHBZ #889201 for details.
* Policies and guidelines: Probably no policy, guideline change needed.  
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 Self Contained Change: Jenkins

[Jaroslav Reznik]

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

Change owner(s): Michal Srb m...@redhat.com

Jenkins is an open source continuous integration tool written in Java. 

== Detailed Description ==
Jenkins provides continuous integration services for software development. It 
is a server-based system. Builds can be started by various means, including 
being triggered by commit in a version control system, scheduling via a cron-
like mechanism, building when other builds have completed, and by requesting a 
specific build URL. 

== Scope ==
* Proposal owners: All necessary Jenkins dependencies should be already in 
Fedora. Jenkins needs mainly testing and bugfixing. 
* 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

F21 System Wide Change: The securetty file is empty by default

[Jaroslav Reznik]

= Proposed System Wide Change:  The securetty file is empty by default = 
https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default

Change owner(s):  quickbooks quickbooks.off...@gmail.com

The securetty file is empty by default 

There's on-going discussion for this Change on the devel list.
https://lists.fedoraproject.org/pipermail/devel/2014-April/197344.html

== Detailed Description ==
Per: [1]  it states:

=== Method ===
Disabling root access via any console device (tty). 

=== Description ===
An empty /etc/securetty file prevents root login on any devices attached to 
the computer.

=== Effects ===
Prevents access to the root account via the console or the network. The 
following programs are '''prevented''' from accessing the root account: login, 
gdm, kdm, xdm, Other network services that open a tty

=== Does Not Affect ===
Programs that do not log in as root, but perform administrative tasks through 
setuid or other mechanisms.
The following programs are not prevented from accessing the root account: su, 
sudo, ssh, scp, sftp

=== More Details ===
To further limit access to the root account, administrators can disable root 
logins at the console by editing the /etc/securetty file. This file lists all 
devices the root user is allowed to log into. If the file does not exist at 
all, the root user can log in through any communication device on the system, 
whether via the console or a raw network interface. This is dangerous, because 
a user can log in to his machine as root via Telnet, which transmits the 
password in plain text over the network. By default, Fedora's /etc/securetty 
file only allows the root user to log in at the console physically attached to 
the machine. To prevent root from logging in, remove the contents of this file 
by typing the following command: echo  /etc/securetty

Warning: A blank /etc/securetty file does not prevent the root user from 
logging in remotely using the OpenSSH suite of tools because the console is 
not opened until after authentication.

== Scope ==
* Proposal owners: implement the change
* Other developers: None
* Release engineering: None
* Policies and guidelines: The Security Document mentioned above will need to 
be updated.

[1]  
https://docs.fedoraproject.org/en-US/Fedora/19/html/Security_Guide/chap-Security_Guide-Securing_Your_Network.html#tabl-Security_Guide-Disallowing_Root_Access-Methods_of_Disabling_the_Root_Account
 
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 System Wide Change: (A)Periodic Updates to Images

[Jaroslav Reznik]

= Proposed System Wide Change: (A)Periodic Updates to Images = 
https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Images

Change owner(s): Cloud WG collectively, with Matthew Miller 
mat...@fedoraproject.org as point of contact
Responsible WG: Cloud 

We want to be able to release updated images not just at release time. Hope 
for a one-month regular cadence, plus emergency updates if needed. 

== Detailed Description ==
We need to be able to produce official updates to the Fedora Cloud images. 
Initially, we plan to release these updates monthly, but also need the ability 
to release an out-of-cycle update in the event of a severe security issue.

This involves:

   1. policy for level of security issue required for out-of-cycle updates
   2. procedure for notification of security updates in images (as with rpm 
updates)
   3. automated QA (at least smoketests)
   4. documentation of QA expectations
   5. release engineering process
   6. mirroring of updated images
   7. updates to web site for new download links and EC2 AMI IDs. 

Note that this will apply to the Cloud Base Image, the Docker Host Image, the 
Big Data Image, and the Docker Container Base Image. (The latter may need 
separate handling.)

Ultimately, we would like to produce updates whenever a package on the image 
or the kickstart file for the image changes. This is a step towards that goal. 

== Scope ==
* Proposal owners: Create policies and procedures as outlined above. Will also 
assist with changes to release engineering.
* Other developers: Contributions welcome!
* Release engineering: Significant impact, obviously. Cloud WG will interact 
heavily with Release Engineering and work in concert.
* Policies and guidelines: No changes to existing policies.

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

F21 Self Contained Change: Apache Accumulo

[Jaroslav Reznik]

= Proposed Self Contained Change: Apache Accumulo = 
https://fedoraproject.org/wiki/Changes/ApacheAccumulo

Change owner(s): Christopher Tubbs ctubb...@apache.org

The Apache Accumulo [1] is a scalable sorted, distributed, key/value store. 

== Detailed Description ==
The Apache Accumulo™ sorted, distributed key/value store is a robust, 
scalable, high performance data storage and retrieval system. Apache Accumulo 
is based on Google's BigTable design and is built on top of Apache Hadoop, 
Zookeeper, and Thrift. Apache Accumulo features a few novel improvements on 
the BigTable design in the form of cell-based access control and a server-side 
programming mechanism that can modify key/value pairs at various points in the 
data management process. 

== Scope ==
* Proposal owners: The Accumulo package will provide all the functionality 
from the upstream release, packaged 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://accumulo.apache.org/
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 System Wide Change: GNOME 3.12

[Jaroslav Reznik]

= Proposed System Wide Change:  GNOME 3.12 =
https://fedoraproject.org/wiki/Changes/GNOME3.12

Change owner(s): Matthias Clasen mcla...@redhat.com 
Responsible WG: Workstation 

Update GNOME to the latest upstream release. Depending on the Fedora 21 
schedule, this might be GNOME 3.12 or 3.14.

== Detailed Description ==
The new features for GNOME 3.12 include:
* More complete hi-dpi support
* gnome-software better integrated
* totem is now Videos
* New applications:
** gnome-logs: A systemd journal viewer
** gnome-sound-recorder: A simple utility for audio recordings
** polari: A irc client
* Google cloud print support
* Windows live email support
* A terminal search provider

The Wayland port of GNOME is still a preview in 3.12.

The feature set for GNOME 3.14 has not been determined yet.

== Scope ==
* Proposal owners:
** Keep existing GNOME packages updated
** Follow upstream module changes
** Package new applications and new dependencies of existing GNOME packages
*** gnome-logs (Done)
*** gnome-sound-recorder (Done)
*** polari (Done)

* Other developers:
** Package new dependencies:
*** libinput (Done)

* Release engineering:
** Extract app data for gnome-software during package builds and provide it in 
repositories

* Policies and guidelines:
** Add app data expectations to packaging guidelines
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 System Wide Change: Database Server Role

[Jaroslav Reznik]

= Proposed System Wide Change:  Database Server Role =
https://fedoraproject.org/wiki/Changes/DatabaseServerRole

Change owner(s):  Kevin Fenzi and Truong Anh Tuan 
ser...@lists.fedoraproject.org
Responsible WG: 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 [1] 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 [1].

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

F21 System Wide Change: Domain Controller Server Role

[Jaroslav Reznik]

= Proposed Self Contained Change: Domain Controller Server Role = 
https://fedoraproject.org/wiki/Changes/DomainControllerServerRole

Change owner(s):  Stephen Gallagher, Simo Sorce - 
ser...@lists.fedoraproject.org
Responsible WG: Server

The Fedora Server Product will provide a standard deployment mechanism for a 
Linux Domain Controller (powered by the FreeIPA project). 

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

This will be implemented by taking advantage of the FreeIPA project, packaging 
it up within the Server Role Framework and enabling it to be deployed through 
the mechanisms described in the Server Role Infrastructure Change Proposal 
[1].

== Scope ==
* Proposal owners:
** FreeIPA and the optional CA and DNS components 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 Domain Controller Role.

* 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 Server 
Role Infrastructure Change Proposal.

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

Summary of accepted Fedora 21 Changes - weeks 13/14

[Jaroslav Reznik]

Greetings!
This is a summary of FESCo's accepted Fedora 21 Changes for weeks 13 and 14
(2014-03-26 and 2014-04-02 meetings).

Reminder: the Change Submission deadline for System Wide Change is 
tomorrow (2014-04-08 23:59 UTC).

=Accepted changes=
== System Wide Changes ==
* Modular Kernel Packaging for Cloud
   URL: ​​​
https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud
Announcement: 
​https://lists.fedoraproject.org/pipermail/devel/2014-March/196807.html 

Kernel modules that are not necessary in virtualized environments become 
optionally (un)installable. 

* Optional Javadocs
  URL: ​https://fedoraproject.org/wiki/Changes/OptionalJavadocs
  Announcement: 
​https://lists.fedoraproject.org/pipermail/devel/2014-March/196808.html 

Make javadoc subpackages of Java packages optional in guidelines and 
communicate this change to users. 

* Ruby on Rails 4.1
  URL: ​https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.1
  Announcement: 
https://lists.fedoraproject.org/pipermail/devel/2014-March/196803.html

Ruby on Rails 4.1 is the latest version of well know web framework written in 
Ruby. 

* Java 8 
  URL: ​https://fedoraproject.org/wiki/Changes/Java8
  Announcement: 
​https://lists.fedoraproject.org/pipermail/devel/2014-March/196962.html 

Make Java 8 (provided by OpenJDK 8 which is java-1.8.0-openjdk) the default 
Java runtime. The current default Java runtime (Java 7, provided by OpenJDK 7, 
java-1.7.0-openjdk) will be obsoleted and removed.

This is essentially an upgrade to the latest Java and OpenJDK version. 

* PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services
  URL: ​
https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork​
  Announcement: 
​https://lists.fedoraproject.org/pipermail/devel/2014-March/197175.html 

Let's make Fedora more secure by default! Recent systemd versions provide two 
per-service switches PrivateDevices?=yes/no and PrivateNetwork?=yes/no which 
enable services to run without access to any physical devices in /dev, or 
without access to kind of network sockets. So far this has seen little use in 
Fedora, and with this Fedora Change we'd like to change this, and enable these 
for all long-running services that do not require device/network access. 

notting has question to note: is disconnecting the netlink and audit namespace 
truly required, or just merely a choice of what they decided to remove? 

== Self Contained Changes ==
* Amplab Tachyon - ​https://fedoraproject.org/wiki/Changes/AmplabTachyon 
discussed at 
​https://lists.fedoraproject.org/pipermail/devel/2014-March/197168.html 

Amplab-Tachyon is a fault tolerant distributed file system enabling reliable 
file sharing at memory-speed across cluster frameworks.

* Apache Mesos - ​https://fedoraproject.org/wiki/Changes/ApacheMesos discussed 
at ​https://lists.fedoraproject.org/pipermail/devel/2014-March/197180.html 

Apache Mesos is a cluster manager for sharing distributed application 
frameworks. This change brings Mesos to Fedora, which many have called a 
micro-kernel for the data center.

* Apache Spark - ​https://fedoraproject.org/wiki/Changes/ApacheSpark discussed 
at ​https://lists.fedoraproject.org/pipermail/devel/2014-March/196967.html 

Apache Spark is a fast and general engine for large-scale data processing. 
This change brings Spark to Fedora, allowing easy deployment and development 
of Spark applications on Fedora.

* Improved Scala Ecosystem Support - ​
https://fedoraproject.org/wiki/Changes/ImprovedScalaEcosystem discussed at ​
https://lists.fedoraproject.org/pipermail/devel/2014-March/196964.html 

Fedora now supports several essential parts of the Scala language ecosystem as 
well as building packages with sbt, the de facto build tool for the Scala 
community.

Scala proposal owners to work to develop packaging guidelines

* DNSSEC support for FreeIPA - ​
https://fedoraproject.org/wiki/Changes/IPAv3DNSSEC discussed at ​
https://lists.fedoraproject.org/pipermail/devel/2014-March/197177.html 

FreeIPA with integrated DNS server will support serving of DNSSEC secured 
zones and automatic DNSSEC key maintenance.

This first version will have only the very basic functionality with limited 
user interface and limited resiliency. Next versions (to be delivered in 
Fedora 22 time frame) will improve resiliency and user interface 
significantly.

* NFS Ganesha File Server - ​https://fedoraproject.org/wiki/Changes/NFSGanesha 
discussed at 
​https://lists.fedoraproject.org/pipermail/devel/2014-March/196968.html 

NFS Ganesha is a user mode file server that supports NFSv3, NFSv4, and NFSv4.1 
including pNFS for distributed filesystems. It uses loadable filesystem driver 
modules to support its backend filesystems. It also integrates 9P.2000L file 
service 

= Rejected Changes =
* Security Policy In The Installer
  URL: ​https://fedoraproject.org/wiki/Changes/SecurityPolicyInTheInstaller
  Announcement:  

F21 System Wide Change: RPM-4.12

[Jaroslav Reznik]

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

Change owner(s):  Florian Festi, Panu Matilainen rpm-ma...@rpm.org

Update RPM to the upcoming 4.12 release. 

== Detailed Description ==
The current upstream repository contains several improvements that need to get 
released and integrated into Fedora:

* Support for weak dependencies
* Support for packaging files  4GB
* Support for real package reinstallation
* New API for accessing files and file contents
* New tool for converting rpm packages to tar files
* Internal plugin interface
* Massive code clean ups
* Many bug fixes

Some of these features require the new version to reach the builders. So 
actually introducing them in Fedora will take longer that the Fedora 21 
release. Nevertheless updating RPM in F21 is the first step to make this 
happen.

== Scope ==
* Proposal owners: The RPM code base needs to get stabilized and release 
ready. The release candidates need to be tested in rawhide.
* Other developers: Will test the release candidates during normal operation 
in raw hide. Need to report issues and bugs.
* Release engineering: Have a look for compatibility issues.
* Policies and guidelines: Packaging policies might need reconsidering in the 
light of the new options (F22 or even F23 time frame).
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Reminder: Change Proposals Submission Deadline in one week!

[Jaroslav Reznik]

Hi,
the Change Proposals Submission Deadline is coming in one week!

The date is Tuesday, 2014-04-08 for System Wide Changes. Self 
Contained Changes deadline will be set later. 

I'd like to ask especially WGs to work on the PRD/Tech
Specs break out into the Change Proposals - so the scope of release
can be evaluated and also for tracking purposes to know where we are
with Fedora 21/Next release.

One particular topic that should be included are product deliverables,
to get a wider agreement on how each product will be distributed and
to allow release engineering team (and others as websites) to adjust
for product needs.

See https://fedoraproject.org/wiki/Changes/Policy for current policy for
submissions and start a new proposal using this template
https://fedoraproject.org/wiki/Changes/EmptyTemplate

Let me know in case of any issues, I'll try to help you!

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

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

F21 Self Contained Change: Apache Hive

[Jaroslav Reznik]

= Proposed Self Contained Change: Apache Hive =
https://fedoraproject.org/wiki/Changes/ApacheHive

Change owner(s):  Peter MacKinnon pmack...@redhat.com

Apache Hive [1] is a data warehouse built on top of Apache Hadoop. 

== Detailed Description ==
The Apache Hive data warehouse software facilitates querying and managing 
large datasets residing in distributed storage. Apache Hive provides a 
mechanism to project structure onto this data and query the data using a SQL-
like language called HiveQL.

== Scope ==
* Proposal owners: The Hive package has been accepted into Fedora and provides 
all the functionality from the upstream release with the exception of HBase 
support since the latest stable versions are not currently aligned.
* 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://hive.apache.org/
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 Self Contained Change: Better Erlang Support

[Jaroslav Reznik]

= Proposed Self Contained Change: Better Erlang Support =
https://fedoraproject.org/wiki/Changes/BetterErlangSupport

Change owner(s):  Peter Lemenkov lemen...@gmail.com, Sam Kottler skottler 
[at] redhat.com, Fedora Erlang SIG erl...@lists.fedoraproject.org

Update Erlang/OTP to R17, and improve Erlang integration with the rest of 
Fedora. 

== Detailed Description ==
Erlang in Fedora is already in a good shape. However we can do better since 
there are a number of annoying shortcomings and issues. Just a few of them:

* Fedora partially enabled Ellyptic Curve Crypto recently but we still provide 
Erlang with EC disabled completely because there is no way to enable just a 
few EC in the current Erlang version.
* Erlang-systemd interaction is in a quite poor state currently.
* There is no way to install headless Erlang. Every Fedora Erlang user have 
to install graphical libraries even if (s)he doesn't want to use GUI on the 
target machine.
* Every daemon written in Erlang has its own logging solution which doesn't 
use neither syslog nor Journald.
* Erlang packaging is quite complex and undocumented mostly.

In order to address all these issues we should do the following:

* Enable fine grained EC crypto support [1] by upgrading Erlang to the latest 
R17 (not yet released, and scheduled to April, 2014).
* Start working on a better systemd support in Erlang by enabling EPMD systemd 
support. This could be done by merging  patches from Matwey V. Kornilov [2] 
and systemd unit-files from openSUSE  [3].
* Add erlang-ejournald [4], erlang-lager_journald_backend [5], and make 
Journald as a default logging backend.
* Split-off infrequently used modules [6] which requires X11, Pulseaudio and 
ensure that it won't break anything.
* Fix the long-standing noarch issue by providing additional default location 
for Erlang bytecode data.
* Update Erlang RPM-related macros to improve packaging by reducing spec-file 
sizes.

== Scope ==
Proposal owners:
* We must rebuild Erlang R17 and submit it to build-overrides.
** We have to rebuild all the packages listed below in the Dependencies [7] 
section.
* WiP: A necessary *.socket unit must be added to erlang-erts to enable EPMD 
socket activation.
** Every Erlang daemon's systemd unit must require epmd.socket.
* We need to fill new review request for erlang-ejournald
** We have to fill new review request for erlang-lager_journald_backend
* We have to patch out GUI parts and provide a way to tell user what to do in 
order to enable this functionality.
* Add another default directory to look for Erlang *.beam files.
* Every Erlang package must require erlang-rpm-macros.
* Riak has growing Bugzilla backlog. We have to address all of these issues.
Other developers: N/A
Release engineering: N/A
Policies and guidelines: We should create Erlang Packaging Guidelines which 
doesn't exist yet.

[1] https://bugzilla.redhat.com/1023017
[2] https://github.com/matwey/otp/tree/systemd
[3] https://build.opensuse.org/package/show/openSUSE:Factory/erlang 
[4] https://github.com/travelping/ejournald 
[5] https://github.com/travelping/lager_journald_backend
[6] https://bugzilla.redhat.com/784693
[7] https://fedoraproject.org/wiki/Changes/BetterErlangSupport#Dependencies
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 Self Contained Change: Amplab Tachyon

[Jaroslav Reznik]

= Proposed Self Contained Change: Amplab Tachyon =
https://fedoraproject.org/wiki/Changes/AmplabTachyon

Change owner(s): Timothy St. Clair tstcl...@redhat.com

Amplab-Tachyon [1] is a fault tolerant distributed file system enabling 
reliable file sharing at memory-speed across cluster frameworks. 

== Detailed Description ==
Amplab-Tachyon is a fault tolerant distributed file system enabling reliable 
file sharing at memory-speed across cluster frameworks, such as Spark and 
MapReduce. It achieves high performance by leveraging lineage information and 
using memory aggressively. Amplab-Tachyon caches working set files in memory 
thereby avoiding going to disk to load datasets that are frequently read. This 
enables different jobs/queries and frameworks to access cached files at memory 
speed. 

== Scope ==
* Proposal owners: Currently our Amplab-Tachyon package has been accepted into 
Fedora. It should feature all of the functionality available from the upstream 
release. 
* 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://tachyon-project.org/index.html
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 Self Contained Change: DNSSEC support for FreeIPA

[Jaroslav Reznik]

= Proposed Self Contained Change: DNSSEC support for FreeIPA =
https://fedoraproject.org/wiki/Changes/IPAv3DNSSEC

Change owner(s): Petr Špaček pspa...@redhat.com

FreeIPA with integrated DNS server will support serving of DNSSEC secured 
zones and automatic DNSSEC key maintenance.

This first version will have only the very basic functionality with limited 
user interface and limited resiliency. Next versions (to be delivered in 
Fedora 22 time frame) will improve resiliency and user interface 
significantly. 

== Detailed Description ==
DNS server integrated to FreeIPA in Fedora 20 is not able to serve signed DNS 
zones. New version of FreeIPA and bind-dyndb-ldap adds support for DNSSEC. 
Zone maintenance (like perioding zone re-signing etc.) will be handled 
automatically, so the administrative overhead should be minimal. 

== Scope ==
* Proposal owners: This change requires major rewrite of bind-dyndb-ldap 
package, some isolated changes in packages freeipa* and it's integration with 
OpenDNSSEC for key rotation.
* Other developers: FreeIPA team has to prepare user interface for this 
feature. (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

F21 Self Contained Change: Apache Mesos

[Jaroslav Reznik]

= Proposed Self Contained Change: Apache Mesos =
https://fedoraproject.org/wiki/Changes/ApacheMesos

Change owner(s): Timothy St. Clair tstcl...@redhat.com

Apache Mesos [1] is a cluster manager for sharing distributed application 
frameworks. This change brings Mesos to Fedora, which many have called a 
micro-kernel for the data center. 

== Detailed Description ==
Apache Mesos is a cluster manager that provides efficient resource isolation 
and sharing across distributed applications, or frameworks. It can run Hadoop, 
MPI, Hypertable, Spark, and other applications on a dynamically shared pool of 
nodes. 

== Scope ==
* Proposal owners: Currently our Mesos package has been accepted into Fedora. 
It should feature all of the functionality available from the upstream 
release. 
* 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://mesos.apache.org/
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

F21 Self Contained Change: Improved Scala Ecosystem Support

[Jaroslav Reznik]

= Proposed Self Contained Change: Improved Scala Ecosystem Support  =
https://fedoraproject.org/wiki/Changes/ImprovedScalaEcosystem

Change owner(s): William Benton wi...@redhat.com

Fedora now supports several essential parts of the Scala language ecosystem as 
well as building packages with sbt, the de facto build tool for the Scala 
community. 

== Detailed Description ==
Fedora has had a Scala package for some time, but the larger Scala ecosystem 
has been absent from Fedora. In fact, until very recently, Fedora included no 
packages that depended on Scala. The main obstacle to getting Scala ecosystem 
projects packaged for Fedora was the difficulty in packaging sbt, the Simple 
Build Tool, which many Scala projects use for build, dependency, and release 
management. Fedora 21 now includes sbt as well as several interesting and 
foundational Scala ecosystem projects, most notably:

* akka, a toolkit for developing actor-based systems;
* json4s, a unified interface to JSON parsers and generators;
* sbinary, a typed Scala interface for reading and writing binary formats;
* sbt, the simple build tool for Scala and Java projects;
* scala-stm, a software transactional memory implementation for Scala;
* scalacheck, a property-based testing framework for Scala; and
* scalaz, a set of extensions to the Scala standard library to facilitate 
functional programming. 

== Scope ==
* Proposal owners:  The change is complete as described; other ecosystem 
packages and additional Fedora-specific developer documentation will continue 
to become available.
* 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