botan update to 1.10
by Thomas Moschny
Hi,
this is a heads-up that I updated the botan package to the latest
stable version 1.10.5 in rawhide, as requested in bug 822421.
This changes the API and thus the soname of the library. Also, since
1.9.18, the library and header paths have been changed to allow
parallel installation of different versions of the library, so headers
are in /usr/include/botan-1.10/botan now, the library is named
libbotan-1.10, botan-config and the botan pkg-config file are
namespaced.
The dependent packages that need to be rebuilt by their owners are:
* bind10: configure finds botan-1.10, but a local rebuild failed
later due to an unrelated problem as far as I can see
* softhsm: seems to support botan-1.10 in principle, but needs a
patch for configure (resp. m4/acx_botan.m4) from SVN
* ne7ssh: rebuild failed, seems to need a patch
* monotone: needs a patch from mainline, will take care of that myself
Regards,
Thomas
9 years, 10 months
F20 System Wide Change: Enable SELinux Labeled NFS Support
by Jaroslav Reznik
= Proposed System Wide Change: Enable SELinux Labeled NFS Support =
https://fedoraproject.org/wiki/Changes/LabeledNFS
Change owner(s): Daniel Walsh <dwalsh(a)redhat.com>, Steve Dickson
<steved(a)redhat.com>
The Linux Kernel has grown support for passing SELinux labels between a client
and server using NFS.
== Detailed description ==
We have always needed to treat NFS mounts with a single label usually
something like nfs_t. Or at best allow an administrator to override the
default with a label using the mount --context option. With this change we
have lots of different Labels supported on an NFS share.
== Scope ==
Proposal owners:
* Steve Dickson needs to make sure nfs-utils works properly.
* Dan Walsh needs to make sure selinux-policy works properly in all use cases.
Other developers: Kernel
* Turn on Labeled NFS in the Fedora Kernel, Fix any policy issues that arise
because of this. I believe this is mainly a testing issue, and that the
functionality is complete.
Release engineering: N/A (No changes for Release Engineering)
Policies and guidelines: N/A (not affected)
9 years, 10 months
F20 System Wide Change: NetworkManager Bonding Support
by Jaroslav Reznik
= Proposed System Wide Change: NetworkManager Bonding Support =
https://fedoraproject.org/wiki/Changes/NetworkManagerBonding
Change owner(s): Dan Williams <dcbw at redhat dot com>, Pavel Šimerda
<psimerda at redhat dot com>
NetworkManager should be able to configure bond master interfaces with commonly
used options and recognize their existing configuration on startup without
disrupting their operation.
== Detailed description ==
NetworkManager's existing support for bond interfaces covers a limited number
of use-cases and can conflict with existing bonding configurations created by
tools like libvirt. The purpose of this Fedora feature is to implement more
flexible bonding infrastructure in NetworkManager to support an expanded number
of use-cases and to be more cooperative with other users of bonding.
Support will be added to NetworkManager to detect the existing configuration of
a bond interface and its slaves and to seamless "take over" that connection
without disrupting it. Even if the existing configuration is not backed by
ifcfg files on-disk, NetworkManager will leave that configuration on the
interface unless told to change it by the user via GUI or CLI tools.
Additional bond interface configuration will be added to expand the use-cases
and hardware that NetworkManager can configure (eg primary, use_carrier,
xmit_hash_policy, etc).
== Scope ==
Proposal owners: development, dcbw
Other developers: This feature requires changes to nm-applet (done), nm-
connection-editor (done), gnome-shell, gnome-control-center (in-progress) and
KDE counterparts to expose bond interfaces and their connection information in
the user interface. NetworkManager also needs updates to implement the
proposed changes (mostly done).
This Change Proposal has been communicated with Wrangler before the Submission
deadline.
9 years, 10 months
F20 System Wide Change: NetworkManager Bridging Support
by Jaroslav Reznik
= Proposed System Wide Change: NetworkManager Bridging Support =
https://fedoraproject.org/wiki/Changes/NetworkManagerBridging
Change owner(s): Dan Williams <dcbw at redhat dot com>, Pavel Šimerda
<psimerda at redhat dot com>
NetworkManager should be able to configure bridge interfaces with commonly used
options and recognize their existing configuration on startup without
disrupting their operation.
== Detailed description ==
A bridge connects two or more physical or virtual network interfaces to allow
network traffic to flow between the two interfaces at a low level. Bridging is
commonly used to connect Virtual Machines to the outside world; a bridge
interface is created, to which a physical interface (typically ethernet) is
assigned as a slave, and a virtual interface (typically TAP) is created and
also assigned to the bridge as a slave, and then given to the Virtual Machine.
Thus traffic from one or more VMs can be combined and sent out of the machine
via the physical interface.
This setup is currently done either manually using ifcfg files and ifup/ifdown,
or by a tool like libvirt/netcf. NetworkManager should be able to configure
bridge interfaces and their slaves with the same functionality as provided by
libvirt, and should recognize and not disrupt existing bridge connections when
it starts up.
== Scope ==
Proposal owners: development dcbw
Other developers: This feature requires changes to nm-applet (done), nm-
connection-editor (done), gnome-shell, gnome-control-center (in-progress) and
KDE counterparts to expose bridge interfaces and their connection information
in the user interface. NetworkManager also needs updates to implement the
proposed changes (mostly done).
This Change Proposal has been communicated with Wrangler before the Submission
deadline.
9 years, 10 months
F20 Self Contained Change: Adding NetworkManager Connections via CLI
by Jaroslav Reznik
= Proposed Self Contained Change: Adding NetworkManager Connections via CLI =
https://fedoraproject.org/wiki/Changes/NetworkManagerCLIAddConnection
Change owner(s): Jiří Klimeš<jklimes at redhat.com>, Pavel Šimerda <psimerda
at redhat.com>
Support for adding new NetworkManager connections using the nmcli commandline
tool.
== Detailed description ==
Administrators will be able to configure new connections via a simple command-
line interface. It will be possible to create and activate new connections, as
well as delete them.
== Scope ==
Proposal owners: development Jirka Klimes and Pavel Šimerda
Other developers: N/A
Release engineering: N/A
Policies and guidelines: N/A
This Change Proposal has been communicated with Wrangler before the Submission
deadline.
9 years, 10 months
F20 Self Contained Change: Enlightenment
by Jaroslav Reznik
= Proposed Self Contained Change: Enlightenment =
https://fedoraproject.org/wiki/Changes/Enlightenment
Change owner(s): Rahul Sundaram <sundaram AT fedoraproject org>, Christopher
Meng <i AT cicku me>, Dan Mashal <dan.mashal AT fedoraproject org>
Enlightenment 0.17 a new stable release has been released after 12 years or so
of development. As many desktops are being landed on Fedora, Integrating
Enlightenment in Fedora can not only enlarge the number of available desktops
in Fedora, but also improve user experiences and give users another choice of
Desktop Environment.
== Detailed description ==
Enlightenment 0.17 (a.k.a E17) is the next generation of graphical desktop
shell from the Enlightenment project. When you first run it and get past the
initial setup wizard, you should end up with a desktop not unlike the above.
It is a very traditional UNIX/X11 style desktop, because that is what E
primarily is and attempts to be, BUT with a bunch of bells, whistles and
modernities that were never there, as well as a different core design
philosophy. There seems to be some obsession with Window Manager vs. Desktop
Environment debates. It doesn't much matter what you call it. It manages
windows. It does compositing. It manages files. It launches applications. It
handles UI and system settings.
Before we go any further, it is time to clean up some common misconceptions.
* First, Enlightenment is not new. It is OLD.
* It predates larger desktop environments like GNOME or XFCE. It is just
barely younger than KDE.
* It never started life as an attempt to "be a full desktop environment".
* It started life as simply a window manager. This was back towards the latter
part of 1996, and its first 0.1 release came in the first part of 1997. It was a
window manager with some extras to scratch the itch that "everything was gray
bevels and UIs had to be plain to be functional or useful, and that
computers/X11 were not capable of more".
* It handily proved that to be wrong. It could manage function AND form more
flexibly than anything else, and to this date is still in an enviable position
of flexibility in both behavior features and in terms of visuals. In fact, its
Achilles heel simply may be that it has too many options and too much
flexibility. Some of the extras filled in the gaps, like setting wallpaper, that
was always done by 3rd party tools and not the window manager at the time. If
you are after a constrained and simple UI, then Enlightenment (E) is not for
you. It can be configured to be plain and simple if you try, or to be buzzing
with activity and complexity, but this is up to you. Its default is somewhere
in between these to give you a taste of what it can do on both ends of the
spectrum.
The default look is not what you are stuck with. Enlightenment was the first
Window Manager (WM) to introduce themes in X11 (pre-packaged sets of data that
you just grab and select, providing you with a vast new look and feel). Today
in Enlightenment, these themes come as "Edje" files (.edj), and are pre-
packaged data files containing all images, layout, animation etc. that you may
need. They never get "unpacked". They are used "live as-is", and only the data
needed from the file is sourced and decoded, so even if the theme is massive,
only the pieces needed at any one time are decoded into memory, which is
normally a fraction of the actual file size. They are also live data and need
to be there while E17 runs as it is forever digging bits of data out of these
files as it needs it. It is an accepted fact that the default look will not be
for everyone. It tries to strike a balance of being unique (not mimicking some
other desktop look), yet still being stylish. It is meant to echo some of the
past from where Enlightenment comes from, and yet roll in modern effects and
feels. It sacrifices some "usability" for look, yet tries to keep a balance and
still be functional. It will not be for everyone, but it is hoped that it
keeps you mostly happy until you find other themes that exactly meet your
visual needs. You will find this as an on-going philosophy in Enlightenment.
One size does NOT fit all. That's what options are for. Thats why we have
themes. Do not have the misconception that what you see is what you are stuck
with. You are expected to experiment and discover what is good for you. Maybe
the default is fine. Maybe it is not. That's why we pioneered themes and spent
immense amounts of time making them nicely packaged, efficient and powerful
enough to fine-tune almost any aspect of the UI.
== Scope ==
Just package every dependency and promise that they can be reviewed 'PASS'.
* Proposal owners: Package all dependencies and push them to review queue.
* Other developers: Keep existed dependency packages updated, make sure the
default backgrounds and theme is available.
* Release engineering: Nothing here currently. If there are sufficient interests
and participation, a Fedora Enlightenment spin could be released.
* Policies and guidelines: N/A (not a System Wide Change)
9 years, 10 months
