FWN/Issue171

= Fedora Weekly News Issue 171 =

Welcome to Fedora Weekly News Issue 171 for the week ending April 12th, 2009.

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

Our latest issue includes important Announcements about Fedora 11 and freeze statuses. Ambassadors celebrates the way "Italians Fete Document Freedom Day" and "LinuxFest Northwest Ramps Up". Developments relays some fraught conversations about "Emacs, Glibc, Malloc and i586" and cautions that "Mono Breakage on PPC May Cause Reversion". Translations keys us in to the "Fedora 11 Release Notes Discussion". Artwork provides insight into "Finishing the Artwork for Fedora 11". Virtualization reports on the "Virtualization Technology Preview Repo."

If you are interested in contributing to Fedora Weekly News, please see our 'join' page. We welcome reader feedback: fedora-news-list@redhat.com release schedule built up some glitches arising in part from the decision to support i586 instead of i686 (see FWN#162 ) led to tense words.

Reports trickled in of problems with  in rawhide. Per Bothner reported both that  threw an "Invalid regex: Unmatched ( or \\(" and that   was responding excruciatingly slowly. Ulrich Drepper speculated to that the regexp problem was due to some changes to  in. A bugzilla report by Andy Wingo expanded on the problem and drew comments suggesting that  and   were also failing to due   changes. Jakub Jelinek thought they were different problems with the  errors being due to.

TomLane asked what was going on with  reverting to an earlier version in rawhide. Jesse Keating responded that  for the   architecture was broken for all versions after beta. After Panu Matilainen commented that  was so broken that   could not even read its own configurations Ulrich Drepper said : "If you want to complain then to the idiots who made the decision to go with .i586 instead of .i686 for x86 binaries.  This is exactly the kind of problem I've been warning about all along.  Using the i586 target stresses code paths (in this case in gcc) which are hardly ever used since nobody cares for this target in general." Panu disavowed any intent to complain.

now has  rules in place to set wireless regulatory domains based on the configured timezone.

might have been enabled. It turned out that this was simply due to a confusion between a  API named "moonlight" and the actual   itself.

All that had actually happened was that Fedora Legal okayed the use of the mono compiler switch "moonlight" in order to facilitate RPMFusion's request.

issue discussed with reference to the 2009-04-08 Rawhide Report suggests that due to breakage on the  architecture it may be necessary to untag the latest mono package.

Objections that the disabling of PPC architecture support on the  package was happening too close to the   final freeze prompted David Nielsen to make the rejoinder that no help had been given to the Mono SIG despite their reporting a problem. Jesse Keating announced that in the absence of a fix before the final freeze  would simply be downgraded: "[t]his kind of version change shouldn't really be made after beta anyway."

David Nielsen argued that the changes had been made well before the beta. Bill Nottingham thrust the responsibility back on him. Alex Lancaster made a similar point more diplomatically.

Mary Ellen Foster requested, as a mono-dependent maintainer, that concrete actions be recommended. Jesse Keating and Toshio Kuratomi asked that all such did _not_ set "ExcludeArch: ppc" and rebuild as this would cause massive churn on a large number of packages. Instead a process to track down the failures and fix them with a fallback plan to revert to a mono release-candidate was proposed by Toshio.

. Contrary advice led to some sarcasm from Christoph Wickert about Red Hat employees not being familiar with Fedora packaging guidelines and it worried Peter Lemenkov, who believed that Red Hat employees all had "provenpackager" status (see FWN#170 ). Jason L. Tibbitts III corrected this latter assertion.

into his machine to fix an X session problem and would like to revert "[...] to the old behavior of having ctrl-alt-backspace kill the current X session." See FWN#169 for earlier discussion.

Anders Rayner-Karlsson explained that dual-head setup in  was as simple as:

xrandr --output LVDS --auto --output VGA --auto --above LVDS

to which Michael Cronenworth responded that this would need to be done in a start-up script as there was also now no  by default. Jesse Keating suggested using the  tool instead as this would obviate the need for an. Adam Jackson cautioned that nVidia's proprietary drivers might not export RANDR-1.2 yet and thus the latter might not work. Further discussions about whether  was needed for side-by-side wide virtual desktops suggested that Intel chipsets while currently enforcing a 2048 pixel limit may be capable of supporting up to 4096 pixels on   or   in the near future.

Dissent and discussion about Fedora's decision to follow the upstream rumbled on. Kevin Kofler suggested that "mailing list consensus" was not a good process by which to make such decisions as that taken by Xorg. Dave Airlie seemed as though he had had enough of personal attacks on him, but was also able to joke about it.

.   "lets you examine and modify virtual machine disk images, so you can perform sysadmin tasks on virtual machines without needing to bring them up or log into them."

"Augeas is a configuration editing tool. It parses configuration files in their native formats and transforms them into a tree. Configuration changes are made by manipulating this tree and saving it back into native config files." Now  "supports Augeas, so you can use Augeas to edit configuration files within the virtual machine."

Richard will be working on creating a Fedora RPM of  this week.

led Jan ONDREJ to reveal a tool in development,.

This script can be used to
 * Make online backups, when virtual server is running.
 * Transfer partitions over the network while the virtual server is off.

"without having to include & debug the rest of rawhide". Daniel summaried the "braindump".

"So in summary":
 * All new upstream releases built in rawhide
 * New upstream releases also built in stable preview branch if possible
 * Only bugfixes built in stable updates/updates-testing branch
 * In exceptional circumstances, rebase for preview branch can be built to updates/updates-testing after alot of positive testing

"This would":
 * Ensure users of stable Fedora release have high confidence in quality of the updates/updates-testing stream
 * Allow users to trivially test new upstream rebases while staying on the stable distro stream
 * Improve testing coverage of major new rawhide features without using the stable release stream users as guinea pigs

Mark McLoughlin thought "this would be hugely useful to people interested in the latest virt bits, but without a testing machine for running rawhide." And even proposed a name for the proposed repository, "How about 'virt-hide' ? :)". Mark also reverenced these FESCo approved guidelines relevant to package maintainers who wish to update a package on an already-released branch.

provides a hypervisor or emulator neutral platform for manipulating virtual machine resources. This model leverages "drivers" for each emulator or backend system. The driver acts as a translator, converting  API calls to the native API. For example, there are drivers for Xen, QEMU KVM, LXC, OpenVZ, User Mode Linux, and storage subsystems.

"The libvirt TCK provides a framework for performing testing of the integration between  drivers, the underlying virt hypervisor technology, related operating system services and system configuration. The idea (and name) is motivated by the Java TCK"

"In particular the libvirt TCK is intended to address the following scenarios


 * Validate that a new libvirt driver is in compliance with the (possibly undocumented!) driver API semantics
 * Validate that an update to an existing driver does not change the API semantics in a non-compliant manner
 * Validate that a new hypervisor release is still providing compatability with the corresponding libvirt driver usage
 * Validate that an OS distro deployment consisting of a hypervisor and libvirt release is configured correctly

Thus the libvirt TCK will allow developers, administrators and users to determine the level of compatability of their platform, and evaluate whether it will meet their needs, and get awareness of any regressions that may have occurred since a previous test run."

The TCK will utilize Perl's testing frameworks and the  Perl binding (FWN#169 ).

Daniel created "4 simple proof of concept scripts" which have already "highlighted some horrible problems" in remote, QEMU, and Xen drivers. There are even some results "in pretty HTML format":


 * http://berrange.fedorapeople.org/libvirt-tck/results/libvirt-tck-rhel-5.html
 * http://berrange.fedorapeople.org/libvirt-tck/results/libvirt-tck-f10-broken.html
 * http://berrange.fedorapeople.org/libvirt-tck/results/libvirt-tck-f10-fixed.html

Daniel goes on to describe how to try out the test suite, talk about what's still left todo, describe how TCK is expected to be used, and provide an introduction to writing tests.