devel-announce January 2013

devel-announce@lists.fedoraproject.org

9 participants
100 discussions

Call for Test Days for Fedora 18
by Adam Williamson 20 Feb '13

20 Feb '13

Hey, folks. It's that time again - time to start thinking about Test Days for Fedora 18. For anyone who isn't aware, a Test Day is an event usually focused around IRC for interaction and a Wiki page for instructions and results, with the aim being to get a bunch of interested users and developers together to test a specific feature or area of the distribution. You can run a Test Day on just about anything for which it would be useful to do some fairly focused testing in 'real time' with a group of testers; it doesn't have to be code, for instance we often run Test Days for l10n/i18n topics. For more information on Test Days, see https://fedoraproject.org/wiki/QA/Test_Days . Anyone who wants to can host their own Test Day, or you can request that the QA group helps you out with organization, or any combination of the two. To propose a Test Day, just file a ticket in QA trac - full details are at https://fedoraproject.org/wiki/QA/Test_Days/Create . For instructions on hosting a Test Day, see https://fedoraproject.org/wiki/QA/SOP_Test_Day_management . You can see the schedule at https://fedoraproject.org/wiki/QA/Fedora_18_test_days . There are many slots open right now, with the earliest on 2012-08-09 and the latest 2012-11-01. Consider the development schedule, though, in deciding when you want to run your Test Day - for some topics you may want to avoid the time before the Alpha release or the time after the feature freeze or the Final freeze. We normally aim to schedule Test Days on Thursdays; however, if you want to run a series of related Test Days, it's often a good idea to do something like Tuesday / Wednesday / Thursday of the same week (this is how we usually run the X Test Week, for instance). If all the Thursday slots fill up but more people want to run Test Days, we will open up Tuesday slots as overflows. And finally, if you really want to run a Test Day in a specific timeframe due to the development schedule, but the Thursday slot for that week is full, we can add a slot on another day. We're flexible! Just put in your ticket the date or timeframe you'd like, and we'll figure it out from there. If you have any questions about the Test Day process, please don't hesitate to contact me or any other member of the QA team on test@ or in #fedora-qa on IRC. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

2 1

Proposed F19 Feature: Usermode Migration
by Jaroslav Reznik 31 Jan '13

31 Jan '13

= Features/UsermodeMigration = https://fedoraproject.org/wiki/Features/UsermodeMigration Feature owner(s): Harald Hoyer <harald(a)redhat.com>, Kay Sievers <kay(a)redhat.com>, Bill Nottingham <notting(a)redhat.com> Access control of privileged operations for ordinary users should be handled exclusively by a centrally managed authority. Usermode/consolehelper should be phased out and be replaced entirely by polkit. == Detailed description == The usermode/consolehelper program is a setuid-root wrapper around a couple of system tools, providing superuser privileges to ordinary users. Its policy is controlled by text files in /etc. These days, most privileged system operations are already controlled by polkit, a well-established, fine-grained, (possibly) network-transparent service for managing privileged operations by ordinary users. Enterprise environments need to be able to centrally define access control policy for the organization, and automatically apply it to all connected workstations. * polkit can be used by privileged processes to decide if it should execute privileged operations on behalf of the requesting user. For directly executed tools, polkit provides a setuid-root helper program called ‘’pkexec’’.The hooks to ask the user for authorizations are well-integrated into text environments, and native in all major graphical environments. * The concept of a ''console user'' (that usermode/consolehelper implements) is no longer a sufficient concept to derive privileges from. OTOH polkit authorizations can properly distinguish between multiple active sessions and seats: e.g. an untrusted user’s reboot request is only granted if only a single user session runs at that time. Btw. this Feature was already accepted for Fedora 18 and it's continuous effort spread over several releases.

1 0

Proposed F19 Feature: Virt Storage Migration
by Jaroslav Reznik 31 Jan '13

31 Jan '13

= Features/Virt Storage Migration = https://fedoraproject.org/wiki/Features/Virt_Storage_Migration Feature owner(s): Cole Robinson <crobinso(a)redhat.com>, Paolo Bonzini <pbonzini(a)redhat.com> Migrate a running virtual machine from one host to another, including in use storage, with no downtime. No need for a shared storage location between the two. == Detailed description == Live migration of a VM has been around for a while, but usage historically required that VM storage disk images were shared between the source and destination host, and mounted in the same location. Since qemu 0.12 (December 2009), there has been a storage migration feature in qemu, but it was inflexible, and inefficient to the point that any workload in the guest would often prevent the guest from ever being full migrated. While supported in libvirt/virsh, it was still difficult to use, requiring stub disk images to be present on the destination host. New developments in QEMU allow migrating a VM with no shared storage between the source and destination, and does it in a performant manner.

1 0

Proposed F19 Feature: System Configuration Shell
by Jaroslav Reznik 31 Jan '13

31 Jan '13

= Features/SystemConfigurationShell = https://fedoraproject.org/wiki/Features/SystemConfigurationShell Feature owner(s): Tom Schwaller <tom dot schwaller at web dot de> The System Configuration Shell System provides an easy to use interactive command line interface with a standardized syntax to manage your system. == Detailed description == Network Administrators love their very powerful switch/router/firewall/etc. CLI which can be used for all administrative tasks in a very structured and well documented way. Compare that to classical Linux System Administration which is a mix of editing configuration files using different formats and executing commands & scripts with a heterogeneous syntax. The System Configuration Shell will provide an interactive command line interface using the python-configshell framework with a standardized syntax to manage your system. It consists of the command configsh which starts an interactive shell and can also be used in shell scripts and the command config for one-shot configuration commands (e.g. config hostname www.fedoraproject.org which not only executes hostname www.fedoraproject.org but also changes several configuration files to make the new hostname permanent). The System Configuration Shell will facilitate the Linux System administrators daily work. Since every command is logged (in a verbose mode even showing the exact system commands and scripts executed), each administrator can decide him/herself if he/she feels comfortable using standard parts (or local extensions) the System Configuration Shell. The approach is similar to the OpenWrt UCI Command Line Utility or the Vyatta vbash but using a different approach.

1 0

Proposed F19 Feature: Virtio RNG
by Jaroslav Reznik 31 Jan '13

31 Jan '13

= Features/Virtio RNG = https://fedoraproject.org/wiki/Features/Virtio_RNG Feature owner(s): Cole Robinson <crobinso(a)redhat.com>, Amit Shah <amit.shah(a)redhat.com> Provide a paravirtual random number generator to virtual machines, to prevent entropy starvation in guests. == Detailed description == The linux kernel collects entropy from various non-deterministic hardware events, like mouse and keyboard input, and network traffic. This entropy is then exposed through /dev/random, commonly used by cryptographic applications that need true randomness to maintain security. However if more entropy is being consumed than is being produced, we have entropy starvation: reading from /dev/random will block, which can cause a denial of service. A common example here is use of /dev/random by SSL in various services. VirtIO RNG (random number generator) is a paravirtualized device that is exposed as a hardware RNG device to the guest. Virtio RNG just appears as a regular hardware RNG to the guest, which the kernel reads from to fill its entropy pool. This effectively allows a host to inject entropy into a guest via several means: The default mode uses the host's /dev/random, but a physical HW RNG device or EGD (Entropy Gathering Daemon) source can also be used.

1 0

Proposed F19 Feature: QXL/Spice KMS Driver
by Jaroslav Reznik 31 Jan '13

31 Jan '13

= Features/QXLKMSSupport = https://fedoraproject.org/wiki/Features/QXLKMSSupport Feature owner(s): Alon Levy <alevy(a)redhat.com> Currently the QXL driver is X.org only, a KMS driver is required to move forward with projects like spice 3D, and also to allow more features to be show in virt environments like plymouth. == Detailed description == The current spice GPU driver for Linux guests is an X.org only driver. A kernel modesetting driver needs to be developed along with a new X.org driver that runs on top of it. Additionally the kernel driver will allow it to work with the modesetting DDX driver. The new ioctl interface the driver will expose will allow updating the qxl DDX driver to work on it. The new driver needs to support all revisions of the qxl device. Btw. Feature has been already proposed as Fedora 18 feature but was postponed for Fedora 19.

1 0

Proposed F19 Feature: Less Brittle Kerberos
by Jaroslav Reznik 31 Jan '13

31 Jan '13

= Features/LessBrittleKerberos = https://fedoraproject.org/wiki/Features/LessBrittleKerberos Feature owner(s): Stef Walter <stefw(a)redhat.com> Make kerberos in Fedora simpler to use by removing some of the brittleness that are common failure points. In particular we remove the need for kerberos clients to sync their clocks, and remove the need to have reverse DNS records carefully setup for services. == Detailed description == MIT kerberos 1.11 now contains work so that clients do not have to sync their system clocks with that of the KDC. A time offset is discovered during preauth and stored along with the local credentials. This removes a common point of failure when using kerberos. Kerberos clients can optionally verify reverse DNS records for services that they connect to as a way of trying to identify which realm they belong to. However in many cases these do not exist. Kerberos should fall back to it's default behavior in that case. Failure to do this is a common point of failure when using kerberos. Further enhancements will be included in kerberos 1.11: * http://k5wiki.kerberos.org/wiki/Projects/Responder (for 1.11) * http://web.mit.edu/kerberos/krb5-latest/

1 0

Proposed F19 Feature: Yesod Web Framework
by Jaroslav Reznik 31 Jan '13

31 Jan '13

= Features/YesodWebFramework = https://fedoraproject.org/wiki/Features/YesodWebFramework Feature owner(s): Jens Petersen <petersen(a)redhat.com>, Michel Salim, Ben Boeckel Yesod is a Haskell web framework for productive development of type-safe, RESTful, high performance web applications. == Detailed description == This is a packaging effort: the Yesod stack of packages requires quite a lot of new Haskell libraries to be added to Fedora. Some basic packages have already been done for a long time but there are a lot left to be added.

1 0

Proposed F19 Feature: KVM Device Failover
by Jaroslav Reznik 31 Jan '13

31 Jan '13

= Features/Virt Device Failover = https://fedoraproject.org/wiki/Features/Virt_Device_Failover Feature owner(s): Michael S. Tsirkin <mst(a)redhat.com>, Gal Hammer <hammer(a)redhat.com>, Cole Robinson <crobinso(a)redhat.com>, Laine Stump <laine(a)redhat.com> Support for transparent failover between an assigned and an emulated device, allows enabling the migration and overcommit dynamically, while still gaining the performance benefits of device assignment and without disrupting the guest operation. == Detailed description == For virtual machines, device assignment is the best option for performance. However, when a device is assigned to a VM, both migration and memory overcommit are currently disabled. This feature aims at removing the performance/features tradeoff, by switching to an emulated device in a way that is almost transparent to users, for configurations where both host and guest are Fedora. Fedora should detect that the emulated device serves as a failover for the assigned device. When requested by the hypervisor, it will stop and eject the assigned device, switching to failover. After this point, migration and memory overcommit are possible, while device configuration is preserved. Once e.g. migration completes, the reverse switch can take place. Thus the device is controlled by: * before migration: device specific driver loaded in guest * during migration: driver loaded in host, virtio or emulated device driver loaded in guest * after migration: device specific driver loaded in guest At the kernel level, for networking, this can be done by and creating a bond in a failover configuration, and for storage, using multipath, on top of both the assigned and the emulated device.

1 0

ARM arches in F19 and forward.
by Dennis Gilmore 30 Jan '13

30 Jan '13

Hi all, This is just a note for a wider audience. the Fedora ARM has dropped support for software floating point going forward, we will only be building hardware floating point binaries from Fedora 19 on. it was discussed at FUDCon and on the arm list the FUDCon notes https://fedoraproject.org/wiki/Architectures/ARM/Meetings/FUDCon_Lawrence_2… show that we were going to look at having F19 be the last softfp supporting release after further thought and discussion we are dropping from F19 and F18 will be the last release supporting sfp so those with sfp only devices, which the only supported ones are kirkwood based devices like the guruplug will get software support for about 1 year more. The Raspberry Pi will be supported by the efforts at Seneca College with armv6hl it will support hardware floating point. Longer term we will start to support aarch64 Regards Dennis

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce January 2013