F21 Self Contained Change: libzhuyin
by Jaroslav Reznik
= Proposed Self Contained Change: libzhuyin =
https://fedoraproject.org/wiki/Changes/libzhuyin
Change owner(s): Peng Wu <pwu(a)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
10 years
F21 System Wide Change: Workstation: Enable Software Collections
by Jaroslav Reznik
= Proposed System Wide Change: Workstation: Enable Software Collections =
https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collec...
Change owner(s): Matthias Clasen <mclasen(a)redhat.com>
The Software Collections repositories will be enabled by default.
== Detailed Description ==
The Workstation product is targeting developers, among others. Software
collections are aiming to give developers easy access to the tools they need.
== Scope ==
* Proposal owners: Include scl-utils in the Workstation package set
* Other developers: The devassistant should integrate software collection
functionality
* Release engineering: No action required
* Policies and guidelines: Allow the inclusion of the software collections
repositories in Fedora products
10 years
F21 System Wide Change: Workstation: Disable firewall
by Jaroslav Reznik
= Proposed System Wide Change: Workstation: Disable firewall =
https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall
Change owner(s): Matthias Clasen <mclasen(a)redhat.com>
The firewalld service will not be enabled by default in the workstation
product.
== Detailed Description ==
The current level of integration into the desktop and applications does not
justify enabling the firewalld service by default. Additionally, the set of
zones that we currently expose is excessive and not user-friendly. Therefore,
we will disable the firewall service while we are working on a more user-
friendly way to deal with network-related privacy issues.
It will of course still be possible to enable the firewall manually.
== Scope ==
* Proposal owners/Other developers: Add a Workstation-specific service
configuration (preset ?) to the firewalld package that disables firewalld for
the Workstation product
* Release engineering: No action required
* Policies and guidelines: No action required
10 years
F21 Self Contained Change: 64bit ARM emulation on x86
by 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 <crobinso(a)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
10 years
F21 System Wide Change: Use license macro in RPMs for packages in Cloud Image
by Jaroslav Reznik
= Proposed System Wide Change: Use license macro in RPMs for packages in
Cloud Image =
https://fedoraproject.org/wiki/Changes/Use_license_macro_in_RPMs_for_pack...
Change owner(s): Matthew Miller <mattdm at fedoraproject>, Tom Callaway <spot
at fedoraproject>
Use new %license macro to separate license files from documentation, so the
latter can be excluded from container images without stripping license
information which must be included.
== Detailed Description ==
Background:
1. Right now, license files are required to be marked as %doc files.
2. There has long been a "nodocs" parameter to RPM which skips all doc files.
3. In addition to the desired space-savings, this installs packages without
their possibly-mandatory license files
This interaction hasn't been problematic before, because generally using
nodocs is an endpoint choice with no distribution after that. But now, we are
looking at building some official cloud and container images with nodocs, so
it suddenly becomes important.
As a bonus, in the future, %license may handle automatic hardlinking of
identical license files.
Specifically, I propose:
1. We change the guidelines
2. We start doing it for new packages
3. We file a F21 system-wide change (that is, this change) for a proven
packager to change all the packages that land in the cloud image for F21
(roughly, @core + dependencies plus a few extras)
4. We may file a similar change for other packages in the base design for F22,
but the work/reward ratio is much lower.
5. It may also be valuable to focus on a few key packages commonly used in
Docker images (like httpd)
6. Other packages updated on a as-time-permits/best-effort basis.
== Scope ==
* Proposal owners: Update guidelines. Identify target packages. Tom will use
provenpackager to make changes to spec files.
* Other developers: Be aware of possible provenpackager changes. Update other
packages on best-effort basis if interested.
* Release engineering: none
* Policies and guidelines: Yes; packaging guidelines change. See [1]
[1] https://fedorahosted.org/fpc/ticket/411
10 years
F21 System Wide Change: Smaller Cloud Image Footprint
by Jaroslav Reznik
= Proposed System Wide Change: Smaller Cloud Image Footprint =
https://fedoraproject.org/wiki/Changes/Smaller_Cloud_Image_Footprint
Change owner(s): Sandro Mathys <red(a)fedoraproject.org> & Cloud SIG
Shrink the footprint of our cloud images as far as reasonably, and within the
given timeframe, possible.
== Detailed Description ==
Space is precious in the cloud, therefore the Cloud SIG tries to keep the
images' footprint as small as reasonably possible. Several approaches are
ongoing in this regard and while they are hardly worth mentioning
individually, the combined effort is going to be noticeable.
== Scope ==
As mentioned, there's really various changes that are quite independent of
each other but share the common goal.
* Proposal owners:
** Replace NetworkManager, etc. with systemd-networkd.
** Make sure only just kernel-core, not kernel and kernel-drivers, is
installed (see the related change: Modular Kernel Packaging for Cloud [1]).
** Make sure only the packages really required are installed.
** Use %packages --excludedocs to to skip installing docs.
** Use %packages --instLangs= to ship only just English.
** Tweak the locales (in %post) so that local-archive ships with only just
English instead of all languages. We might skip this one if it seems too much
tinkering. Work is going on to have proper support for this in the glibc
package (see rhbz#156477 [2] - also, c#30 shows the necessary tinkering).
* Other developers:
** Packages that are part of any cloud image (and in the long run all
packages) must use %license instead of %doc for the license file(s) so we can
skip shipping docs but still ship licenses. (See separate change Use license
macro in RPMs for packages in Cloud Image [3]
** cloud-init should no longer require python-cheetah and needs to be
refactored (upstream) accordingly.
* Release engineering: Nothing.
* Policies and guidelines:
** Packaging Guidelines need to reflect that license files must be tagged with
%license instead of %docs (FPC#411 [4]).
[1] https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud
[2] https://bugzilla.redhat.com/show_bug.cgi?id=156477
[3]
https://fedoraproject.org/wiki/Changes/Use_license_macro_in_RPMs_for_pack...
packages in Cloud Image
[4] https://fedorahosted.org/fpc/ticket/411
10 years
F21 System Wide Change: Ruby193 in SCL
by Jaroslav Reznik
= Proposed System Wide Change: Ruby193 in SCL =
https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL
Change owner(s): Marcela Mašláňová <mmaslano(a)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/
10 years
F21 Self Contained Change: SDDM as the default KDE display manager instead of KDM
by 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 <mbriza(a)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)
10 years
F21 Self Contained Change: Remote Journal Logging
by Jaroslav Reznik
= Proposed Self Contained Change: Remote Journal Logging =
https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging
Change owner(s): Zbigniew Jędrzejewski-Szmek <zbyszek(a)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
10 years
F21 Self Contained Change: Move to ImageFactory For Cloud Image Creation
by Jaroslav Reznik
= Proposed Self Contained Change: Move to ImageFactory For Cloud Image
Creation =
https://fedoraproject.org/wiki/Changes/Move_to_ImageFactory_For_Cloud_Ima...
Change owner(s): Ian McLeod <imcleod(a)redhat.com>, Dennis Gilmore
dgilmore(a)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)
10 years