F22 Self Contained Change: Nautilus Improvements
by Jaroslav Reznik
= Proposed Self Contained Change: Nautilus Improvements =
https://fedoraproject.org/wiki/Changes/Nautilus_Improvements
Change owner(s): Carlos Soriano <csoriano(a)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
9 years, 3 months
F22 Self Contained Change: Gnome Shell - New Notifications
by Jaroslav Reznik
= Proposed Self Contained Change: Gnome Shell - New Notifications =
https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications
Change owner(s): Florian Müllner <fmuellne(a)redhat.com>
Redesign the way in which notifications are shown and kept available in gnome-
shell.
== Detailed Description ==
The message tray is one of the remaining weaker points of the original gnome-
shell design. This change will replace it with a new implementation of
notifications that avoids the problems of the current implementation.
== Scope ==
* Proposal owners:
** Implement the new design
** Get the changes reviewed and merged upstream
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
== Contingency Plan ==
N/A (not a System Wide Change)
9 years, 3 months
F22 System Wide Change: GCC5
by Jaroslav Reznik
= Proposed System Wide Change: GCC5 =
https://fedoraproject.org/wiki/Changes/GCC5
Change owner(s): Jakub Jelínek <jakub(a)redhat.com>
Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.
== Detailed Description ==
GCC 5 is currently in stage3, but in 3 days will move to stage4, in prerelease
state with only regression bugfixes and documentation fixes allowed. The release
will happen probably in the first half of April. We are working on scratch gcc
rpms and will perform a test mass rebuild. Other distributions have performed
test mass rebuilds already.
== Scope ==
All packages should be rebuilt with the new gcc once it hits f22.
* Proposal owners: Build gcc in f22, rebuild packages that have direct
dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).
* Other developers: First few days/weeks just voluntary rebuilds using the new
system gcc, if things fail, look at http://gcc.gnu.org/gcc-5/porting_to.html
and fix bugs in packages or, if there is a gcc bug or suspected gcc bug,
analyze and report.
* Release engineering: Organize a mass rebuild
* Policies and guidelines: No policies need to be changed
== Contingency Plan ==
If bugs are discovered, I'd appreciate help from the package owners in
preparing self-contained testcases to speed up analysis and fixing the bugs.
Don't have time to debug issues in 12000+ packages, especially when in many
cases it could be caused by undefined code in the packages etc. I don't expect
we'll have to fall back to the older gcc, we've never had to do it in the
past, but worst case we can mass rebuild everything with older gcc again.
* Contingency mechanism: Revert to older gcc, mass rebuild everything again
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No
9 years, 3 months
F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades
by Jaroslav Reznik
= Proposed System Wide Change: RpmOstree - Server side composes and atomic
upgrades =
https://fedoraproject.org/wiki/Changes/RpmOstree
Change owner(s): Colin Walters <walters(a)verbum.org>
The rpm-ostree [1] tool provides a new way to deploy and manage RPM-based
operating systems. Instead of performing a package-by-package install and
upgrade on each client machine, the tooling supports "composing" sets of
packages on a server side, and then clients can perform atomic upgrades as a
tree.
The system by default preserves the previously booted deployment, providing an
"A/B partition" type feel, allowing quick system rollbacks for the entire OS
content (kernel and userspace).
This is a dependency of the Changes/Atomic_Cloud_Image. [2]
== Detailed Description ==
rpm-ostree is far from the first effort in the field of "image-like" update
systems in Fedora. The StatelessLinux [3] project was first prototyped in
Fedora Core 6 timeframe. Today, particularly in the cloud, many deployments
perform OS upgrades by terminating an instance, and booting a new OS image and
having it discover previous state stored in an external volume or network
store.
Another model is to perform an atomic upgrade by delivering the OS content via
an ISO or USB stick, and simply swapping it out, then rebooting. The oVirt
Node [4] is an example of this model.
The most challenging case though is stateful systems that require
online/incremental Internet/Intranet connected upgrades. This is the default
model for traditional Fedora package managers such as yum. A common approach
for this to have an "A/B" partition model, and to use rsync or a custom tool
to perform upgrades offline into the non-active partition.
rpm-ostree is attempting to address this last case, but in a more flexible and
dynamic fashion. It has some of the flexibility of package systems, with the
atomic upgrade and rollback of image-based systems. Furthermore, rpm-ostree
intends to bind together the world of packages with an image-like update
system. For example, an "rpm-ostree upgrade" command can show the system
administrator the package-level diff.
In the future, the intention is for rpm-ostree to further gain package-system
like features. See package layering prototype [5]. An active git branch uses
libhif [6].
== Scope ==
* Proposal owners: work on http://projectatomic.io upstream
* Other developers:
** Anaconda: Help maintain rpmostreepayload.py
** Anaconda/Architecture porters: Backends for the OSTree bootloader code,
similar to grubby
** RPM content:
*** Use systemd-tmpfiles instead of placing content in /var (TODO: better docs
for this)
*** Change "rootfiles" and "bash" to not require files in /root by default
(TODO: bugzilla entry)
* Release engineering: Create trees from package set, mirroring support
* Policies and guidelines: TODO: Guideline for /var
[1] https://github.com/projectatomic/rpm-ostree
[2] https://fedoraproject.org/wiki/Changes/Atomic_Cloud_Image
[3] https://fedoraproject.org/wiki/StatelessLinux
[4] http://www.ovirt.org/Node_Building
[5] https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2014-O...
[6] https://github.com/projectatomic/rpm-ostree/pull/81
9 years, 3 months
FESCo and Env and Stacks WG upcoming elections nominations are open
by Jaroslav Reznik
Hello everyone!
The nomination period for FESCo and Environments and Stacks Working
Group Elections is now open.
We will be selecting five seats on FESCo [1] and four seats on Env and
Stacks Working Group [2]. If you are interested in these roles, please
add yourself to the lists of nominees at [1] and [2] before 23:59:59
UTC on January 19, 2015! If you wish to nominate someone else, please
consult with that person ahead of time. If you know someone who would
be a good candidate, now is a great time to make sure they're thinking
about it.
If you have questions you'd like asked of candidates, please add them
to the <https://fedoraproject.org/wiki/Elections/Questionnaire> wiki
page. Nominees will answer these questions and the answers will be
published simultaneously on January 26th as part of campaign period.
Questions may be moderated to fit Fedora Magazine interview format.
No FAmSCo elections are held this time as FAmSCo is discussing the
new committee format.
Elections schedule:
* January 13-19: Nomination period open
* January 20-26: "Campaign" period.
* January 27 - February 03: Voting open
* February 04: Results announcement
9 years, 3 months
F22 System Wide Change: Default Local DNS Resolver
by Jaroslav Reznik
= Proposed System Wide Change: Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
This Change was already proposed as Fedora 21 Change but moved to Fedora 22
(and discussed as Fedora 22 Change), re-announcing it as more details were
provided as requested by FESCo [0].
Change owner(s): P J P <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.
== Detailed Description ==
There are growing instances of discussions and debates about the need for a
trusted DNSSEC validating local resolver running on 127.0.0.1:53. There are
multiple reasons for having such a resolver, importantly security & usability.
Security & protection of user's privacy becomes paramount with the backdrop of
the increasingly snooping governments and service providers world wide.
People use Fedora on portable/mobile devices which are connected to diverse
networks as and when required. The automatic DNS configurations provided by
these networks are never trustworthy for DNSSEC validation. As currently there
is no way to establish such trust.
Apart from trust, these name servers are often known to be flaky and
unreliable. Which only adds to the overall bad and at times even frustrating
user experience. In such a situation, having a trusted local DNS resolver not
only makes sense but is in fact badly needed. It has become a need of the
hour. (See: [1], [2], [3])
Going forward, as DNSSEC and IPv6 networks become more and more ubiquitous,
having a trusted local DNS resolver will not only be imperative but be
unavoidable. Because it will perform the most important operation of
establishing trust between two parties.
All DNS literature strongly recommends it. And amongst all discussions and
debates about issues involved in establishing such trust, it is unanimously
agreed upon and accepted that having a trusted local DNS resolver is the best
solution possible. It'll simplify and facilitate lot of other design decisions
and application development in future. (See: [1], [2], [3])
People:
* Petr Spacek
* Paul Wouters
* Simo Sorce
* Dmitri Pal
* Carlos O'Donell
== Scope ==
Proposal owners: Proposal owners shall have to
* define the syntax and semantics for new configuration parameters/files.
* persuade and coordinate with the other package owners to incorporate new
changes/workflow in their applications.
Other developers: (especially NetworkManager and the likes)
* would have to implement the new features/workflow for their applications
adhering to the new configurations and assuming the availability of the trusted
local DNS resolver.
* NetworkManager already has features & capability to support local DNS
resolvers. Though few details are still under development, but are expected to
realize in near future. Please see ->
https://lists.fedoraproject.org/pipermail/devel/2014-April/197848.html
Release engineering:
* would have to ensure that trusted local DNS resolver is available throughout
the installation stage and the same is installed on all installations
including LiveCDs etc.
Policies and guidelines:
* the chosen trusted DNS resolver package(ex dnsmasq or dnssec-trigger etc.)
would have to ensure that their DNS resolver starts at boot time and works out
of the box without any user intervention.
* NetworkManager and others would have to be told to not tamper with the local
nameserver entries in '/etc/resolv.conf' and save the dynamic nameserver
entries in a separate configuration file.
[0] https://fedorahosted.org/fesco/ticket/1307
[1] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html
[2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html
[3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html
9 years, 3 months
F22 System Wide Change: Set sshd(8) PermitRootLogin=no
by Jaroslav Reznik
= Proposed System Wide Change: Set sshd(8) PermitRootLogin=no =
https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
Change owner(s): P J P <pjp(a)fedoraproject.org> and Fedora Security Team
To disable remote root login facility in sshd(8) by default.
== Detailed Description ==
Sshd(8) daemon allows remote users to login as 'root' by default. This
provides remote attackers an option to brute force their way into a system.
Empirically it is observed that many users use their systems via 'root' login,
without creating non-root user and often have weak passwords for this mighty
account. sshd_config(5) has an option 'PermitRootLogin=yes|no' which controls
sshd(8) behaviour; it is set to be 'Yes' by default. Disabling remote root
login by setting PermitRootLogin=no would help to harden Fedora systems,
moving it an inch closer towards 'secure by default' future. Users can have
non-root accounts with weak passwords too, yet disabling remote root login
keeps an attacker a step away from getting full control on a system. There is
another option of disabling user login via password and require usage of
cryptographic keys for the same. But that could a next step in future.
Please see -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html
== Scope ==
* Proposal owners: to communicate with the Fedora maintainers of packages:
Anaconda, OpenSSH, GNOME, etc.
* Other developers: packages like Anaconda, GNOME etc. need to update their
workflow to enable compulsory non-root user account creation and ensure good
password strength for it.
* Release engineering: installer needs to ensure creation of non-root user
account with strong password. Similarly, all Fedora images must be created
with a non-root user account.
* Policies and guidelines: unknown yet.
9 years, 3 months
Changes submission deadline and Fedora 22 scheduling changes
by Jaroslav Reznik
Hi everyone!
Fedora 22 and especially Changes submission deadline [1] is coming pretty
soon - in less than two weeks on January 20th. With Alpha release in March.
Please, submit your System Wide Changes by this deadline, earlier better.
There's one significant change FESCo agreed at yesterday's meeting
regarding Fedora schedules. Fedora 22 will be strictly time based release
(of course except quality related slips) and the final schedule will not
be based on submitted Change proposals! We will strictly enforce Contingency
plan at Changes checkpoints. Please make sure to provide valid plan in
your Change proposal as otherwise it can be rejected by FESCo (and scope
within Fedora 22 schedule).
This means, we have approved FINAL schedule for Fedora 22! It will be
released on May 19th (in case of no slips occurring).
In case you'll need any help with your Change proposals, feel free to
contact me and I'll do everything to help you :).
Jaroslav
[1] https://fedoraproject.org/wiki/Releases/22/Schedule
9 years, 3 months
[Guielines Change] Changes to the packaging guidelines
by Jason L Tibbitts III
The autoprovides and requires filtering guidelines have been updated to
take advantage of features in RPM versions 4.9 and newer. Packagers
making use of filtering, for instance compiled extensions to scripting
languages from being provided as though they were a shared library,
should take a look at the guidelines and update their spec files
accordingly. This includes packages which are overriding the
%perl_default_filter macro as the previous ways of overriding that
%macro have lead to quite a few silent bugs
https://lists.rpm.org/pipermail/rpm-list/2013-January/001359.html
The new guidelines work on all Fedora versions but EPEL6 and below will
need to follow different formulas:
https://fedoraproject.org/wiki/EPEL:Packaging#Provides_and_Requires_Filte...
The previous method of filtering autoprovides and requires will continue
to limp along but it has many known caveats so packagers are encouraged
to update their packages at their earliest convenience.
---
A prohibition on using %{_isa} in BuildRequires has formally been added
to the Guidelines:
https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_and_.25...
Work on finishing a complete %{_isa} Guideline is underway.
---
The Conflicts guidelines have been clarified to state that the goal is
for users to be able to install the latest packages from Fedora's repos
regardless of what other Fedora packages are installed.
https://fedoraproject.org/wiki/Packaging:Guidelines#Conflicts
---
Added an additional allowed use of Conflicts to the packaging guidelines
on Conflicts. This usage is for a package which is split into multiple
packages with files that may conflict with files in the older version of
the base package. See the Conflicts Guidelines if you think you may be
able to make use of this:
https://fedoraproject.org/wiki/Packaging:Conflicts#Splitting_Packages
---
Packaging guidelines for cron files
https://fedoraproject.org/wiki/Packaging:CronFiles
have been clarified.
---
A new guideline for header-only libraries (for instance, C++ templates)
was added. These guidelines treat header-only libraries similarly to
static libraries.
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Header_Only...
---
A section on the proper naming of language packs (langpacks) was added
to the Naming and Versioning Guidelines:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_...
---
A longtime limitation of RPM is that it cannot replace a directory with
any kind of file nor can it replace a symlink to a directory with a
directory. Workarounds with varying limitations have been used in
different packages when the need has arisen. We now have guidelines that
codify one of these workarounds that we hope has as few problems as
possible and also documents the known limitations of its approach. The
guideline also encourages has advice on designing your package to not
run into this problem down the road in cases where the problem can be
anticipated in advance.
Please see:
https://fedoraproject.org/wiki/Packaging:Directory_Replacement
for information in case you are in the unfortunate position of having to
deal with this case.
---
Mention of the %autosetup macro has been added; its use is now
permitted in Fedora packages.
https://fedoraproject.org/wiki/Packaging:Guidelines#.25autosetup
---
The section of guidelines on packaging additional rpm macros has been
amended to say that macros must be stored under
%{_rpmconfigdir}/macros.d on Fedora and EPEL7+ as the rpm on all of
these systems will search that path. A recipe for spec files that also
need to be used on EPEL5 & 6 is included. See
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_of_Addition...
for details.
---
The ruby guidelines have been updated for recent improvments in ruby
packaging. RubyGems now ship with an RPM dependency generator that
automatically generates requires/provides are in many cases. RubyGems
now support platform specific locations for binary extensions that
allows for a simplification of the guidelines. Please see
https://fedoraproject.org/wiki/Packaging:Ruby for complete details.
---
AppData files should be included in packages which contain graphical
applications. Guidelines were added describing the use of these files:
https://fedoraproject.org/wiki/Packaging:Guidelines#AppData_files
---
The environment modules guidelines have been updated. The new
guidelines mention how to deal with an alternate module implementation
(lmod) and use the new %{_modulesdir} macro to shift modules from
/etc/modulefiles to /usr/share/modulefiles (so that sysadmins can use
the /etc/modulefiles location) See the policy for complete information:
https://fedoraproject.org/wiki/Packaging:EnvironmentModules
---
The tmpfiles.d guidelines
https://fedoraproject.org/wiki/Packaging:Tmpfiles.d
have been updated and clarified. Note that this includes new
instructions for specifying files created by the tmpfiles.d mechanism in
your %files section; %verify is now used instead of %ghost.
---
The scriptlets for calling update-mime-database when mimeinfo files are
installed have been updated:
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#mimeinfo
---
Guidelines were added for use of %{_sysctldir} (/usr/lib/sysctl.d) and
/usr/lib/binfmt.d:
https://fedoraproject.org/wiki/Packaging:Guidelines#binfmt.d.2C_sysctl.d_...
---
One section of the Java guidelines
https://fedoraproject.org/wiki/Packaging:Java#Javadoc_installation)
was updated to indicate that generation of javadocs is optional.
---
Fedora.next Products may need to configure some packages differently
from each other (for instance, firewall rules). There are now
guidelines for how to achieve this using RPM subpackages that will be
pulled in on the specific product on which they are needed.
https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration
---
The guidelines about directories that Fedora packages are not allowed
to touch has been updated to:
* Clarify that modifications of any type (adding files, modifying
files, removing files, etc) are not allowed.
* Add a different section for /opt that explains its use in
Fedora. This is because otherwise this guideline would conflict with
the scl guidelines and also addresses the clarifications the LSB has
made to me about the meaning of the /opt directory.
* Add /home/USER directories as another set of directories that
packages are not allowed to touch.
https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directori...
---
Guidelines were added for packages which make use of the SSL and TLS
cryptographic protocols:
https://fedoraproject.org/wiki/Packaging:CryptoPolicies
---
A guideline was added concerning the need for all executables to have
manpages, and clarifying that they should be installed uncompressed.
https://fedoraproject.org/wiki/Packaging:Guidelines#Manpages
---
The old OpenOffice.org extension guidelines have been replaced by new
guidelines for LibreOffice extensions. There are significant changes so
please review them:
https://fedoraproject.org/wiki/Packaging:LibreOfficeExtensions
---
Guidelines on file permissions
https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions
have been clarified.
---
Use of the %{?dist} tag in the Release: field is now mandatory.
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#The_.25.7B.3Fdi...
---
Thanks for your attention.
- J<
9 years, 3 months
F22 Self Contained Change: New Default Console Font
by Jaroslav Reznik
= Proposed Self Contained: New Default Console Font =
https://fedoraproject.org/wiki/Changes/NewDefaultConsoleFont
Change owner(s): Marko Myllynen <myllynen(a)redhat.com>, Mike FABIAN
<mfabian(a)fedoraproject.org>
A new console font, eurlatgr, was recently added to kbd and it should be
better default console font for European based languages written in Latin or
Greek script. eurlatgr is based on latarcyrheb-sun16 so the typeface does not
change.
== Detailed Description ==
eurlatgr would bring these changes over the current default latarcyrheb-sun16:
* full compatibility with latarcyrheb-sun16 for Latin script and special
characters
* Arabic/Cyrillic/Hebrew are not supported at all by eurlatgr so those users
should still stay with latarcyrheb-sun16
* non-European languages written in Latin script (like Vietnamese) are not
fully supported but perhaps a bit more so than with latarcyrheb-sun16
* the only non-Arabic/Cyrillic/Hebrew characters not present in eurlatgr but
in latarcyrheb-sun16 are U+F800 and U+F804 which are not valid Unicode
characters so the use case for them is unclear, especially today. These could
be re-added if there's a real need for them but if not, dropping them is ok
* full support for all European languages written in Latin script
* full support for Greek
* full support for a huge list of characters and character sets (see
Documentation below)
* support for a wide range of accented Latin characters not present in
latarcyrheb-sun16 to allow people to write their names correctly
* support for glyphs used by some systemd(1) utilities
* support for glyphs used by man(1) (see e.g. the bottom of unicode(7) how
some characters are not displayed properly under latarcyrheb-sun16)
* support for glyphs that have become popular recently, like the smiley (☺)
and arrows (e.g. →)
== Scope ==
* Adjust langtable rules to prefer eurlatgr instead of latarcyrheb-sun16 for
the languages supported by eurlatgr. Review additional related tools
(anaconda, dracut, systemd) to see whether any defaults need to be changed.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
9 years, 3 months