FWN/Issue166

= Fedora Weekly News Issue 166 =

Welcome to Fedora Weekly News Issue 166 for the week ending March 8th, 2009.

http://fedoraproject.org/wiki/FWN/Issue166

A small sample of this issue's stories reflects the imminent release of Fedora 11! Announcements lists the freeze dates and upcoming Fedora events. PlanetFedora rounds up essential blog reading including a piece by Thomas Vander Stichele on "meltdown analysis". Marketing cheers for "1 Million New Fedora 10 Installations". In QualityAssurance a reminder that the next of the "Test Days" is of interest to Intel video users is just one of the items reflecting a massive amount of QA activity. Ambassadors relates some OLPC news from Rochester Institute of Technology. Developments explains why "Orphans are Purged" and asks are we "Ready for a New RPM Version?". Translation highlights a "Study about FLP". Artwork stares at the wallpaper while "Preparing for the Beta Release". SecurityAdvisories lists stuff to help you avoid a rooting. Virtualization pops some salient items out of the development maelstrom including a "New Release of libvirt-0.6.1" and SELinux "sVirt Support Committed". There's a lot more, so keep reading!

If you are interested in contributing to Fedora Weekly News, please see our 'join' page[1]. We welcome reader feedback: fedora-news-list@redhat.com

FWN Editorial Team: Pascal Calarco, Oisin Feeley, Huzaifa Sidhpurwala

[1] http://fedoraproject.org/wiki/NewsProject/Join

Announcements
In this section, we cover announcements from the Fedora Project.

http://www.redhat.com/archives/fedora-announce-list/

http://www.redhat.com/archives/fedora-devel-announce/

https://fedoraproject.org/wiki/FedoraEvents

Contributing Writer: Max Spevack

Fedora 11
Jesse Keating reminded the community that the Fedora 11 Beta freeze is coming this week. "It is scheduled for Tuesday, March 10th. They way we've historically enacted the beta freeze is to tag the content in that day's rawhide into the freeze tag.  That is, what gets reported as rawhide-20090310 is the frozen content.  As such, your builds need to be complete by 0600 UTC March 10 2009 in order to be in the Beta, without a special request."

The string freeze is also on March 10th.

project seems to have found a friend at Rochester Institute of Technology. Fedora Ambassador Karlie Robinson contacted RIT professor Stephen Jacobs and discussed the project, which spurred Jacobs' interest in doing a class around the.

Karlie brought Professor Jacobs up to speed on what  is doing around the , where   is providing  s to those who will do development work. The deal revolved around getting XOs for Jacobs classroom in exchange for the RIT students working on Greg DeKoenigsberg's 4th Grade Math project.

So RIT students got s and the project got some more help.

. Dave Lehman, Chris Lumens and Joel Granados were the developers present. Several people showed up and provided valuable testing in a wide range of scenarios, and the developers were able to identify and resolve several bugs. Further testing in this area is still very helpful. The wiki page contains instructions for using a supplementary image while installing, to use the new storage code successfully, but the code will soon be available directly in  , so testing can be performed simply by attempting to install   in as many different storage scenarios as possible.

Next week's test day is tentatively scheduled for testing  graphics devices, especially the new kernel mode setting support and identifying performance regressions from Fedora 10. It will be held on Thursday (2009-03-12) in the #fedora-qa channel on Freenode IRC. If you use an Intel graphics card, please come by to help make sure it will be well-supported in Fedora 11 - the more testing, the better the code!

packages and a shorter revised list was posted.

A follow-up posted states that packages listed therein will be removed on 2009-03-09 unless volunteers are found to maintain them.

with the  fork. Adam has a history of very actively seeking to merge improvements upstream which in the past led to the replacement of  with   when it seemed that the latter was more willing to evolve. The glacial pace of  development seemed to be correlated with the presence of a non-Free enterprise edition. Adam reported that unfortunately a lack of co-ordination of the  project had led to the   and   projects deciding that a fork was necessary. An initial mail posted by PeterÅstrand on @tigervnc-users provides some more details.

One specific outcome anticipated by KingInuYasha was a "[...] proper implementations of VNC 4 for UNIX like systems [...] Having a VNC implementation that actually is kept up to date with the VNC protocol and is optimized with extensions is something I have been waiting for awhile now."

Another hint of good things which may come from a more rapid pace of development was revealed when Daniel Berrange asked about Adam's plans to include the  server-side SSL/TLS extension. This would result in a "[...] consistent TLS extension that's inter operable across all the VNC clients & servers in Fedora." Daniel also mentioned that he had "[...] recently defined & implemented another VNC auth extension based on SASL. This provides for a good extendable authentication capability, most importantly including GSSAPI Kerberos for single sign on. I've got it implemented for QEMU, KVM, GTK-VNC and VINO already, so again it'd be good to plan for adding it to TigerVNC too so we have a widely interoperable strong authentication system."

All in all it looks as though contrary to their slogan "The VNC that bites" TigerVNC will be superb.

at this late stage of the  release cycle. This new version decreases memory use and improves performance. Panu emphasized that it was not as large an upgrade as the "[...] 4.4.2.x -> 4.6.0 leap-of-faith upgrade last year [.]"

Bill Nottingham was among those who expressed concern that  would be completely ready for the final release of. He also wondered if there would be incompatibilities with previous  version. Panu answered that  was expected to be ready for the final release and that incompatibilities would only result if packagers used the   file capabilities. This latter is protected against with an  dependency.

A certain amount of disquiet at the idea of "[g]oing with a beta version of critical infrastructure like RPM [...]" based on the recent changes to RPM was voiced by Tom Lane. Upon a challenge from Seth Vidal some problems with the process of upgrading  to handle stronger hashes were listed by Bill Nottingham. These included including "No solution for handling packages natively on F9" and Tom Lane expanded on the point: "I'm personally still ticked off that I'm being forced to update my development workstation to F-10 immediately in order to continue doing useful work on rawhide packages. I don't have time for that right now.  Since F-9 is still supported, isn't it a management failing to have allowed this to happen without a plan to make mock on F-9 work?" The general response seemed to be that developers need to use one of the virtual machine solutions in order to be able to build for.

A substantial sub-thread on the rate of change in  and whether or not developers should use it or stick to the current stable release with a virtualized instance of   developed following some thoughts from Adam Williamson.

RahulSundaram asked for more information on the use of  compression as this is one of the new features of. Panu replied  will not be used by default as it would make even the current     unable to read packages produced with such compression.

A FESCo decision made on 2009-03-06 confirmed that  would be the version shipping in.

before the rapidly approaching 2009-03-10 string freeze.

Kevin Kofler asked why Richard did not call it "MinGW cross compiler" and Richard responded that he wanted to avoid trademarks and leave open the possibility to broaden support to other non-embedded platforms. He came up with either "Consumer cross-compilers (CCC) or Consumer cross-compiler collection (CCCC)." Kevin had some other interesting questions about the legality of possible  cross-compilers and the desirability of one group per OS. Richard pointed to an earlier thread on the latter question.

should support separate  and   partitions in order to support clean installs during upgrades. Lex's detailed post included links to relevant previous discussion.

Adam Williamson was very much in favor of the idea and in response to Jesse Keating suggested some heuristics which might allow  to determine the relative sizes of the   and   partitions. Bruno Wolff III's  partition size (circa 40GB) proved to be surprisingly large due to multiple languages installed. Michel Salim and Callum Lerwick both brought up the necessity to have a large  partition in order to be able to run.

Lex elaborated on possible space requirements for such a scheme.

.

media player was to occur. David also objected that the onus had been placed on him to convince the maintainer of the competitor  package to allow the replacement. He also suggested that the use of the  language was a stumbling block due to   eschewing  : "[...] RHEL does not ship Mono, if RHEL wants to ship Rhythmbox that is their decision but what Fedora ships should not be. What else are we going to be dictated from above.. who else should bother to make proposals for what they preceive to be improvements?"

Jesse Keating responded that his understanding was that the desire to avoid  in   is to avoid bloating the  s with dependencies. The IRC logs bore out this interpretation with FESCo members explicitly stating that "[...] what its written in should have no bearing on what goes in[.]" It was also clear however that, as the largest downstream distributor of an OS directly derived from  , would not be ignored.

for the  instance,   support (statistics), inclusion of the   RPM files into the yum repositories etc.

Meanwhile, the test instance of http://translate.fedoraproject.org with a new version of transifex is currently available on http://publictest14.fedoraproject.org for testing and feedback. The statistics can be viewed without login. For advanced operations, a log-in can be created on the server.

option to  and. Output from this option would be used to help users determine the appropriate argument for. The  option is used to "Optimize the guest configuration for a type of operating system. This will attempt to pick the most suitable ACPI & APIC settings, optimally supported mouse drivers and generally accommodate other operating system quirks."

This touched off a discussion of how such information is managed. Daniel P. Berrange pointed out shortcomings in the current approach and perscribed the following fixes, and supplied an example XML file.
 * An XML schema for defining all the information wrt to guest OS distros that is relevant to virt management tools.
 * A C library for querying the information in the XML file(s).
 * Bindings of the C library into Python/Ruby etc as needed
 * Ability for local admins to extend / override the information either by editing the XML files directly, or a pretty GUI

Cole later dropped his patch and automated the creation of the OS list in the  man page instead.

and. This adds a command to "Attach a physical host device to the guest. HOSTDEV is a node device name as used by libvirt (as shown by 'virsh nodedev-list')."

Daniel P. Berrange described the management options for host devices.
 * "If 'managed=yes' then libvirt will automatically detach the device from the host driver."
 * "If 'managed=no' then libvirt expects that the caller has already ensured the device is detached from the host before *ALL* attempts to start the guest, now & in the future."

This change supports the KVM PCI Device Assignment feature in Fedora 11.

release, version 0.400.2.

is a module that helps build and install  based virtual machines. It currently supports,   and   virtual machines. Package includes several command line utilities, including  (build and install new VMs) and   (clone an existing virtual machine).

New features:
 * New  option , allows cloning a guest from an xml file, rather than require an existing, defined guest.
 * New  option , allows creating a guest from an existing disk image, bypassing any OS install phase.
 * New  option , for connecting a physical host device to the guest.
 * Allow specifying 'cache' value via 's   options (Ben Kochie)
 * New  option   (John Levon)
 * Lots of backend cleanups and documentation improvements.

and  fail with the error " ".

It seems that  is not present for some unknown reason.

is a  toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes).

New features:
 * new APIs for Node device detach reattach and reset (Mark McLoughlin)
 * mandatory access control support (James Morris and Dan Walsh)

Improvements:
 * don't hardcode ssh port (Guido Gunther)
 * new test cases and testing infrastructure (Jim Meyering)
 * improve the SExpr parser (John Levon)
 * proper error reporting on  shutdown command (John Levon)
 * proper handling of errors when saving  domains state (Guido Gunther)
 * revamp of the internal error memory APIs (John Levon)
 * better  error reporting (John Levon)
 * more daemon options to allow running multiple daemons (Jim Meyering)
 * error handling when creating a  domain (Guido Gunther)
 * fix timeouts in  log reading (Guido Gunther)
 * migration with  3.3 fixes (John Levon)
 * XML dump flags cleanup (Cole Robinson)
 * fix build with loadable drivers (Maximilian Wilhelm)
 * internal XML APIs to read long long and hexa values (Mark McLoughlin)
 * function to parse node device XML descriptions and associated test (Mark McLoughlin)
 * generate network bridge names if not provided (Cole Robinson)
 * recognize ejectable media in hostdev hal driver (Cole Robinson)
 * integration of  (Daniel Berrange)

There were also dozens of cleanups, documentation enhancements, portability and bug fixes.

With about five weeks since the release of 0.6.0, Daniel added "So quite a bit of changes happened in one month of development, so it's getting clear we aren't really slowing down and keeping a relatively fast release cycle is needed. So expect 0.6.2 in a month or so."

patches to enable  support in.

. The proposal included two options. One leveraged existing RPC while the second created a new well known port to handle the migration. Using RPC adds a layer of authenitcation which may possibly be avoided in the second option by simply opening a new port in a firewall.

Sticking with existing RPC and enhancing the authentication system for migration seemed to be the consensus.

, VirtualBox, and OpenVZ with, and so asked about support for a number of features including auxiliary TAP devices in the host to correspond with ethernet devices in the guest.