Hi everyone-
This is a notice in accordance with the mass bug filing procedure.
A number of packages install systemd units and enable them
automatically. They should not. Please update these packages to use the
macroized scriptlet
(https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd)
If your package has an exception from FESCo permitting it to enable
itself, please make sure that the service in question is listed in the
appropriate preset file.
There is a general exception described here:
https://fedoraproject.org/wiki/Starting_services_by_default
If your package falls under the general exception, then it is possible
that no change is required. Nevertheless, if you are relying on the
exception, please make sure that your rpm scripts are sensible. The
exception is:
In addition, any service which does not remain persistent on the
system (aka, it "runs once then goes away"), does not listen to
incoming connections during initialization, and does not require
configuration to be functional may be enabled by default (but is not
required to do so). An example of "runs once then goes away" service
is iptables.
Given that this issue can affect Fedora 20 users who install your
package as a dependency, these bugs should be fixed in Fedora 20 and
Rawhide.
The tracker bug is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1090684
I created it early because three of the bugs are pre-existing. Next
week, I'll file bugs against the packages below. If you fix your
package in the mean time, please let me know.
After three weeks, provenpackagers may step in and fix these issues.
OpenIPMI
at
avahi
avahi-dnsconfd
bcfg2
bcfg2-server
bwbar
cronie
deltacloud-core
device-mapper-multipath
dmapd
fsniper
gpm
groonga
hsqldb
iscsi-initiator-utils
jabberd
libvirt
libvirt-client
lvm2
mailman
mdadm
monit
openct
opendkim
openssh-server
partimage
rhnsd
rinetd
sendmail
vdsm
xrdp
yum-updatesd
It's possible that I'm missing some packages. I may follow up with an
updated list.
= Proposed Self Contained Change: MariaDB 10.0 =
https://fedoraproject.org/wiki/Changes/MariaDB10
Change owner(s): Jakub Dorňák <jdornak(a)redhat.com>
Update MariaDB to version 10.0
== Detailed Description ==
MariaDB 10.0 is the current stable (GA) release of MariaDB. It is built on the
MariaDB 5.5 series with backported features from MySQL 5.6 and entirely new
features not found anywhere else.
The libraries provided by MariaDB 10.0 packages remain compatible. There is no
need to rebuild other packages.
== Scope ==
* Proposal owners: rebase MariaDB to version 10.0.10
* 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)
There is no need to rebuild other packages.
= Proposed Self Contained Change: The Shogun Machine Learning Toolbox =
https://fedoraproject.org/wiki/Changes/shogun
Change owner(s): Björn Esser <besser82(a)fedoraproject.org>
SHOGUN is a large Scale Machine Learning Toolbox, being implemented in C++ and
offering interfaces to C#, Java, Lua, Octave, Perl, Python, R and Ruby.
== Detailed Description ==
* Homepage: The SHOGUN Machine Learning Toolbox [1]
* SCM-repo: on GitHub [2]
* Documentation: is available here [3]
* further Information: on Wikipedia [4]
The machine learning toolbox's focus is on large scale kernel methods and
especially on Support Vector Machines (SVM). It provides a generic SVM object
interfacing to several different SVM implementations, among them the state of
the art LibSVM. Each of the SVMs can be combined with a variety of kernels.
The toolbox not only provides efficient implementations of the most common
kernels, like the Linear, Polynomial, Gaussian and Sigmoid Kernel but also
comes with a number of recent string kernels as e.g. the Locality Improved,
Fischer, TOP, Spectrum, Weighted Degree Kernel (with shifts). For the latter
the efficient LINADD optimizations are implemented. Also SHOGUN offers the
freedom of working with custom pre-computed kernels. One of its key features
is the "combined kernel" which can be constructed by a weighted linear
combination of a number of sub-kernels, each of which not necessarily working
on the same domain. An optimal sub-kernel weighting can be learned using
Multiple Kernel Learning. Currently SVM 2-class classification and regression
problems can be dealt with. However SHOGUN also implements a number of linear
methods like Linear Discriminant Analysis (LDA), Linear Programming Machine
(LPM), (Kernel) Perceptrons and features algorithms to train hidden Markov-
models. The input feature-objects can be dense, sparse or strings and of type
int/short/double/char and can be converted into different feature types.
Chains of "pre-processors" (e.g. subtracting the mean) can be attached to each
feature object allowing for on-the-fly pre-processing.
== Scope ==
* Proposal owners: Create the rpm-spec and file a review bug. Have the package
build after review was granted.
* 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://shogun-toolbox.org/
[2] https://github.com/shogun-toolbox/shogun
[3] http://shogun-toolbox.org/doc/en/current/
[4] http://en.wikipedia.org/wiki/Shogun_%28toolbox%29
= Proposed Self Contained Change: LVM Cache Logical Volumes =
https://fedoraproject.org/wiki/Changes/Cache_Logical_Volumes
Change owner(s): Alasdair G. Kergon <agk(a)redhat.com>, David Cantrell
<dcantrel(a)redhat.com>, Dave Lehman <dlehman(a)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)
= Proposed Self Contained Change: Docker Cloud Image =
https://fedoraproject.org/wiki/Changes/Docker_Cloud_Image
Change owner(s): Cloud SIG / Sandro Mathys <red(a)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/
= Proposed System Wide Change: Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s): P J P <pjp(a)fedoraproject.org>, Pavel Šimerda
<pavlix(a)pavlix.net>, Tomas Hozza <thozza(a)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
= Proposed System Wide Change: Wayland =
https://fedoraproject.org/wiki/Changes/Wayland
Change owner(s): Matthias Clasen and the desktop team <mclasen(a)redhat.com,
desktop(a)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
= 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 <rhughes(a)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