Fedora Weekly News #147

[Oisin Feeley]

= Fedora Weekly News #147 - The Canadian Thanksgiving Issue =

           1.1 Announcements
                + 1.1.1 New Fedora 9 Re-spins
                + 1.1.2 Fedora Test Day
                + 1.1.3 Uberpackager Replaces Packager
           1.2 Planet Fedora
                + 1.2.1 Events
                + 1.2.2 Tech Tidbits
           1.3 Marketing
                + 1.3.1 Fedora's Community Attracts Experienced Users
                + 1.3.2 Five Second Boot of a Modified Version of Fedora
           1.4 Developments
                + 1.4.1 Unsigned Rawhide Packages an Attack Vector ?
                + 1.4.2 Procedure for Re-naming a Package
                + 1.4.3 Review of trash-cli Raises Generic Naming Issues
                + 1.4.4 PackageKit-gstreamer-plugins Obsoletes Codeina
                + 1.4.5 LXDE Feature Removal Disappointment - How to
                Avoid
           1.5 Documentation
                + 1.5.1 Fedora 10 Release Notes
                + 1.5.2 Fedora Wiki Mailing List
           1.6 Translation
                + 1.6.1 Documentation Repository Updates
                + 1.6.2 Release Notes .pot File Delayed
                + 1.6.3 Virt-* Modules Cannot Be Submitted Via Transifex
           1.7 Infrastructure
                + 1.7.1 Some Architectural Changes
           1.8 Artwork
                + 1.8.1 Fedora 10 CD/DVD Sleeves
           1.9 Security Advisories
                + 1.9.1 Fedora 9 Security Advisories
                + 1.9.2 Fedora 8 Security Advisories
           1.10 Virtualization
                + 1.10.1 Enterprise Management Tools List
                      # 1.10.1.1 Importing Appliance Raw Disk Images
                + 1.10.2 Fedora Xen List
                      # 1.10.2.1 Support for F10 domU on RHEL5.2 dom0
                + 1.10.3 Libvirt List
                      # 1.10.3.1 KVM Domain Migration Not Yet Supported
                      # 1.10.3.2 Disable QEMU Drive Cacheing
                      # 1.10.3.3 NSIS Windows Installer in Nightly
                      Builds
                      # 1.10.3.4 Domain Events API Progress
                + 1.10.4 oVirt Devel List
                      # 1.10.4.1 oVirt Qpid API

Fedora Weekly News Issue 147

Welcome to Fedora Weekly News Issue 146 for the week ending October 12,
2008.

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

In this Canadian Thanksgiving[0] issue of FWN, Max Spevack announces the
Fedora Unity's latest offerings of Fedora 9 re-spins, provides detail on
James Lasker's Fedora Test Day. and covers the goings on in the Fedora
community blogosphere, with coverage of three contributions about the
Red Hat Government Users and Developers Conference, and various tech
tidbits around Fedora through the week. Svetoslav Chukov covers two
stories in our marketing beat, including Intel linux developer work on
building a modified Fedora install on an Asus EEE that boots in an
amazing five seconds. Oisin Feeley again provides amazing coverage of
Fedora development, including discussions of unsigned Rawhide packages
as an attack vector, procedures for renaming Fedora packages, a
discussion of the trash-cli package and its implications for generic
naming issues, and much more. Jason Taylor brings us up to date with the
documentation project, covering Fedora 10 release notes, and discussion
of a possible fedora-wiki mailing list. Runa Bhattacharjee covers
happenings in the translation team for us, discussing release note and
documentation translation topics, and translations to the virt-*
modules. Huzaifa Sidhpurwala covers the Infrastructure beat again for
us, with a story on the infrastructure team's consolidation over the
past few months and news of a new bapp class of servers that is under
deployment. Nicu Buculei covers all of the great work going on in the
Fedora Art team, and details the discussion of Fedora 10 CD/DVD sleeves
this week. David Nalley details for us the Fedora 8 and 9 security
advisories for the week, and Dale Bewley gets us current with the many
happenings on the four virtualization lists he covers -- the Enterprise
Management Tools, Fedora Xen, library virtualization and oVirt
development lists, including stories on importing appliance raw disk
images, support for F10 domU on RHEL5.2 dom0, support for KVM migration,
amongst others.

If you are interested in contributing to Fedora Weekly News, please see
our 'join' page[1].

FWN Editorial Team:

    * Pascal Calarco
    * Oisin Feeley
    * Huzaifa Sidhpurwala 

[0] http://en.wikipedia.org/wiki/Canadian_Thanksgiving

[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/

Contributing Writer: Max Spevack

=== New Fedora 9 Re-spins ===

Ben Williams announced[1] the availability of a new Fedora 9 re-spin.
"The Fedora Unity Project is proud to announce the release of new ISO
Re-Spins of Fedora 9. These Re-Spin ISOs are based on the officially
released Fedora 8 installation media and include all updates released as
of October 4th, 2008."

[1]
http://www.redhat.com/archives/fedora-announce-list/2008-October/msg00003...

=== Fedora Test Day ===

James Laska announced[2] the next Fedora Test Day. "I'd like to invite
testers and users to join #fedora-qa this Thursday, October 9, 2008.
Testing efforts will focus[3] on gathering Fedora 10 Beta feedback and
exercising GlitchFreeAudio (aka pulseaudio)."

[2]
http://www.redhat.com/archives/fedora-devel-announce/2008-October/msg0000...

[3] https://fedoraproject.org/wiki/QA/Test_Days/2008-10-09

=== Uberpackager Replaces Packager ===

Toshio Kuratomi explained[4] the changes to packager groups and ACLs.
"The transition from a single packager group to an entry level packager
group that can only commit to packages that the person owns and a
separate uberpackager group that can commit to everything has been
made." Additionally, "people in uberpackager should be able to commit to
any package which is open to the uberpackager group. As part of the
update, all packages which were previously opened to packager/cvsextras
are now opened to uberpackager."

[4]
http://www.redhat.com/archives/fedora-devel-announce/2008-October/msg0000...

== Planet Fedora ==

In this section, we cover the highlights of Planet Fedora - an
aggregation of blogs from Fedora contributors worldwide.

http://planet.fedoraproject.org

Contributing Writer: Max Spevack

=== Events ===

Several Fedora folks posted about the Red Hat Government Users and
Developers Conference. Paul Frields posted[0] a few thoughts, as did[1]
Eric Christensen and Dan Walsh[2].

[0] http://marilyn.frields.org:8080/~paul/wordpress/?p=1212

[1]
http://fedora-sparks.blogspot.com/2008/10/red-hat-govt-users-and-develope...

[2] http://danwalsh.livejournal.com/24935.html

=== Tech Tidbits ===

James Laska wrote[3] about the Anaconda and NetworkManager Fedora Test
Day. "Our focus this round was exercising Anaconda NetworkManager
integration in Fedora 10 Beta. In preparation for the day, David
Cantrell pulled together several fixes for issues discovered since the
beta was released."

[3] http://jlaska.livejournal.com/2257.html

Jeremy Katz posted[4] about updates to the initiative to get Fedora
running on the XO. "So, you just got your XO to do some testing of
Fedora on OLPC. You update the software that was on there, get a
developer key, wait a day, and then get all ready to boot your Fedora
image off of the SD card ....

And it boots. But it's slow. Very very slow. Some slowness is to be
expected... this isn't a fast machine. But it should probably be a
little bit speedier than it is. So want to try out a few experiments to
try to help pin down the cause of the slowness? Then read on, pick a
case and leave comments about your results."

[4] http://katzj.livejournal.com/440444.html

Karsten Wade wrote[5] about the Fedora 10 release notes. "If you don’t
assign someone from your sub-project or SIG to cover that content, that
area will be empty for the Fedora 10 Preview and possibly final
releases.

Yep, it’s our job to remind you, edit, convert, get translated, package,
and deliver. But only you can fill in the content that is missing. One
thing we will do for you is hunt through your feature page and pull in
any release notes content that you put there. But you have to put it
there first, we cannot divine it."

Read the full post for a list of topics within Fedora that are falling
behind in the release notes process, and help out if you would like to.

[5] http://iquaid.org/2008/10/06/your-release-notes-are-looking-thin/

== Marketing ==

In this section, we cover the Fedora Marketing Project.

http://fedoraproject.org/wiki/Marketing

Contributing Writer: Svetoslav Chukov

=== Fedora's Community Attracts Experienced Users ===

A tale[1] of one user's experience migrating from SUSE 9 to Fedora. "I
realized that Fedora is not simply a GNU/Linux distribution with great
amount of software but something more than that. I would classify Fedora
as combination of strong community, GNU/Linux distribution and great
spirit. So, that was the best distro I would switch on. Because of the
good support from the community I migrated so easily and avoiding
problems."

[1]
http://spreadfedora.org/sf/index.php?option=com_content&task=view&...

=== Five Second Boot of a Modified Version of Fedora ===

As reported[1] in LWN.net, at the Linux Plumbers Developer Conference,
two Linux developers at Intel demonstrated two different modified linux
distributions booting in about five seconds on an 'Asus EeePC', one of
which was a modified Fedora install. The article includes details on
where the time savings were achieved throughout the boot process.

[1] http://lwn.net/Articles/299483/

== Developments ==

In this section the people, personalities and debates on the
@fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley

=== Unsigned Rawhide Packages an Attack Vector? ===

Rahul Sundaram noticed[1] that when using PackageKit to obtain updates
from the rawhide repository a warning for each package was displayed as
they are all unsigned. He asked "[it] is just plain annoying. Can't we
do something nice about that?"

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00959.html

The planets may have wobbled in their orbits when Ralf Corsepius
responded[2] "IMO the 'only correct approach' would be to only have
signed packages in rawhide" and Rahul agreed[3] completely "[m]any of us
including me run rawhide for a large time of the Fedora development
cycle, a security exploit in one of our machines via a bad rawhide
mirror can result in malicious packages being pushed to stable
repositories or other even worse issues. We should take this attack
vector seriously." He asked if the reason was due to the time delay.

[2]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00960.html

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00964.html

Josh Boyer confirmed[4] that time delay was the central problem and
added "[...] the fact that we have a very limited number of people that
know the signing key." Till Maas pointed[5] to the need for more
developers to help Jesse Keating implement the Sigul[6] signing server
that "[...] stores the signing keys within smartcards or something
similar."

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00980.html

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00976.html

[6] https://fedorahosted.org/sigul

Richard Hughes suggested[7] that although PackageKit should simply abort
any transaction involving an unsigned package it might be possible to
add a configuration setting UnsignedPackages=abort|warn|allow to
PackageKit.conf and asked for opinions on whether it was possible for
"[u]pstream [to] set this to abort, and patch the package in rawhide to
"allow" -- having F10 set to warn or abort[?]" In response to Denis
Leroy's suggestion that such properties belonged to the repository
rather than the package manager Richard agreed[8] that the policy would
be implemented only if the repository declared itself as unsigned.

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01004.html

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01010.html

=== Procedure for Re-naming a Package ===

Two issues were raised[1] by Patrice Dumas in a post which initially
asked for information on the formal procedure to rename a package and
later explored the apparent lack of an active LaTeX and TeX community
within the Fedora Project.

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00210.html

Patrice listed all the possible places on the wiki which should contain
the information but failed to do so. Debarshi Ray remembered[2] a
similar request on @fedora-packaging to which Tom Callaway had
suggested: "[...] just open a ticket with Fedora Release Engineering
(http://fedorahosted.org/rel-eng) and request the renaming of the
package." A slightly different procedure was advanced[3] by Jesse
Keating: "Renaming a package is just bringing in the new package,
getting it reviewed, particularly for correct Provides/Obsoletes, and
then requesting that the old named package be removed." Thorsten
Leemhuis concurred[4] with this but pointed out that decisions made by
FESCo had not been documented properly on the wiki.

[2]
https://www.redhat.com/archives/fedora-packaging/2008-October/msg00004.html

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00220.html

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00224.html

The procedure appeared cumbersome to Patrice although Jesse argued[5]
that a new review was useful in order to help diminish "[...] the vast
number of improper Provides/Obsoletes I've ran across [.]" Patrice stuck
to the idea that time spent "re-reviewing" the package would be better
spent elsewhere. Specifically he worried[6] that not enough reviewers
knowledgeable about TeX and LaTeX were active and able to keep pace with
the "[...] rapid pace of changes linked with switching to texlive 2007
and now 2008 [.]" In response to interest from Matej Cepl he posted[7] a
list of pending reviews.

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00234.html

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00278.html

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00450.html

=== Review of trash-cli Raises Generic Naming Issues ===

The maintainer of the putative trash-cli package, Jean-François Martin
(lokthare), asked[1] whether any package reviewers were interested in
examining trash-cli . The package implements the FreeDesktop.org trash
specification via the command line. The package had been partially
reviewed previously by Patrice Dumas who seemed generally supportive and
interested but had expressed[2] unhappiness with the generic nature of
one of the command names, trash, provided by the package . The other
command names are: list-trash; empty-trash;restore-trash. Patrice had
suggested to Jean-Francois that other reviewers might react more
favorably but that it would be better to persuade upstream to change the
names of the commands.

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00216.html

[2] https://bugzilla.redhat.com/show.bug.cgi?id=448122

This objection was re-iterated[3] by Michael Schwendt with the addition
of the explanation that such names increased the chances of a namespace
collision between current and future packages. Reference was made to
existing generic naming of samba commands by Juha Tuomala and player[4]
by Yanko Kaneti. Tim Niemuller argued that for the latter case the
review had covered the naming problem and decided that adhering to
upstream convention in the absence of present conflicts was the best
policy as it allowed users to easily reproduce commands found elsewhere
on the internet. A longish exchange followed in which Patrice argued[5]
that upstreams should consider such issues more carefully and
suggested[6] that individual distributions could follow Debian's example
and override upstream naming choices when necessary. Tim put[7] the case
for respecting upstream choices as long as there were no obvious current
conflicts. His suggestion to use /etc/alternatives to resolve the
problem was challenged[8] by Toshio Kuratomi as an inappropriate use.

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00223.html

[4] Player is part of a robot and sensor research system:
http://playerstage.sourceforge.net/

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00287.html

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00324.html

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00359.html

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00320.html

Re-naming was considered[9] by Jean-Francois early on in the discussion
and Rahul Sundaram recommended[10] alerting one of the FreeDesktop.org
email lists to the change. Behdad Esfahbod suggested renaming all the
commands to follow the pattern trash-* and was engaged[11] by the
primary developer Andrea Francia in a discussion about why this might be
preferable. Matt Miller wondered if it was a real problem and Andrea
provided[12] a list of all the possible "trash" programs to show that
none of them conflicted. Jesse Keating commented[13] that this was
because "[...] all of them were smart enough to avoid falling into the
generic trap." The bugzilla entry indicated[14] that upstream was going
to rename the commands and the trash-cli commands will be available with
the next release.

[9]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00218.html

[10]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00219.html

[11]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00251.html

[12]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00327.html

[13]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00330.html

[14] https://bugzilla.redhat.com/show.bug.cgi?id=448122
PackageKit-gstreamer-plugins Obsoletes Codeina

Richard Hughes wondered[1] what he was doing wrong with the specfile for
the PackageKit-gstreamer-plugins package. This package allows individual
applications to call PackageKit to install[2] missing codecs.

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00281.html

[2]
http://blogs.gnome.org/hughsie/2008/10/02/codec-install-in-fedora-10/
The bugzilla error filed[3] against the package reported that it
conflicted with the codeina package[4], which was the previous method to
install plugins for GStreamer aware applications. Richard wondered if a
simple

Obsoletes: codeina
Provides: codeina

would do the trick, but Paul Howarth cautioned[5] "[u]nversioned
obsoletes are bad and should be avoided like the plague." Matej Cepl
suggested[6] using the RPM name and version macros:

Obsoletes: codeina < 0.10.1-10
Provides: codeina = %{version}-%{release}

[3] https://bugzilla.redhat.com/show.bug.cgi?id=465723

[4] http://fedoraproject.org/wiki/Multimedia/Codeina

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00284.html

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00443.html

Ville Skyttä wondered "[i]s the Provides: above appropriate in the first
place, or should only the Obsoletes: be there? The only thing
PackageKit-gstreamerplugin and codeina appear to have in common is
/usr/libexec/gst-install-pluginshelper." Jesse Keating disputed[7] this
but Villä explained[8] that "Dropping the Provides would mean that if
something had a depdendency on codeina, that dep would be broken, and
that pk-gstreamer-plugin couldn't be installed with "yum install
codeina". I don't think it'd have any effect on whether
pk-gstreamerplugin would/wouldn't be applied as an upgrade over
installed codeina e.g. by yum (assuming the Obsoletes is left there)."
He proved[9] his point with a practical example and this combined with
James Antill's observation[10] seemed[11] convincing.

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00468.html

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00471.html

[9]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00480.html

[10]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00481.html

[11]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00483.html

=== LXDE Feature Removal Disappointment - How to Avoid ===

Some possible problems with the package review process were raised when
Christoph Wickert expressed[1] disappointment over the removal of his
Lightweight X11 Desktop Environment (LXDE)[2] Feature from Fedora 10
without any apparent notification coming his way. The discussion was
positive and restrained although Christoph was obviously upset.
Christoph admitted that his feature was late but pleaded that he had
followed the Feature Wrangler's advice and argued that the FESCo
deliberations incorrectly assumed that most of his packages were
unready. He requested an explanation of the concerns about breaking the
string freeze as this was the other main reason for omitting LXDE from
Fedora 10. Bill Nottingham explained that "Groups in comps (and their
descriptions) are translatable strings; adding or changing them breaks
the string freeze [...]" and added that "[t]he feature is supposed to be
testable by the feature freeze, which is the same time as the string
freeze." Christoph argued[3] that in that case he should have been
informed earlier.

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00408.html

[2] https://fedoraproject.org/w/index.php?title=Features/LXDE#LXDE

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00422.html

Suggestions made[4][5] by Kevin Kofler to hack around the translation
problem were rebutted[6] by Bill Nottingham as not following the string
freeze policy and he also listed the uncompleted parts of the feature
and wondered "[...] exactly what else is there to do when even the basic
scope and test plan of the feature isn't ready?" Christoph responded[7]
fully and explained that his outrage was because of a lack of
communication from anyone and incorrect assumptions made during the
FESCo deliberations. He thanked Bill for his feedback. Christoph
contended that the necessary packages had in fact passed review contrary
to an assumption that none of them had done so. The existence of this
assumption was disputed[8] by Brian Pepple. Christoph explained that in
addition he had waited fruitlessly for FESCo to give him permission to
make changes to comps.

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00446.html
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00457

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00461.html

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00484.html

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00521.html

Toshio Kuratomi tried[9] to calm the discussion by avoiding assigning
fault to any party. He suggested trading reviews with other people,
explained that any maintainer can make changes to comps without waiting
for FESCo and suggested some improvements to the communication process.
Apparently MediaWiki handles watches differently to MoinMoin and this
might explain some missed information. But Toshio disavowed some of the
stronger assertions made by Christoph as "unfair" and reminded him
"[t]he Feature Page shows that the feature is not done. Checking
bugzilla shows that the page is up-to-date in regards to the package
review status. Beta is a deadline for features and that has come and
gone. So the Feature is plainly not completed whether you were contacted
or not; whether the people who commented knew all the particulars or
only some." Finally Toshio interpreted the lack of FESCo commentary to
"[...] a bunch of polite people not jumping in to say 'Me too' [.]"
This
part of the discussion did not seem to go much further, but Nicolas
Mailhot added[10] the interesting observation that "Comps is both
central and under-regulated. You'll have a hard time finding who is
supposed to approve comps policy, and the files themselves are wide
open. However out of respect both for the people working on comps
translations, and for the people working of comps consumers, I
personally wouldn't make any deep restructuring such as new group
creation after test1 (to give people time to react)."

[9]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00493.html

[10]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00514.html

Richard W. M. Jones supported[11] the idea that FESCo members were
making decisions without reading the documentation or being interested
in the topics and cited MinGW as another example. He suggested that
FESCo members should volunteer to produces packages for MinGW. Josh
Boyer dismissed[12] the accusations firmly and stated his own interest
in MinGW and participation in the debate. The particular example of
MinGW seemed ancillary to the central question and ended[13] in
irascible disagreement when Richard re-iterated his request and accused
FESCo members of lacking sufficient knowledge. The history of MinGW
development has included[14] substantial disagreements due to the desire
to[15] create a separate repository for it in opposition to Richard's
wishes.

[11]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00494.html

[12]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00508.html

[13]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00511.html

[14]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00519.html

[15] https://fedoraproject.org/wiki/FWN/Issue142#MinGW.on.Fedora

Josh pointed to the finite amount of time FESCo board members have at
their disposal: "If FESCo has to go and be an intimate part of a Feature
in order for it to get approved or discussed, then that is what I would
consider to be a very large failure. Reality dictates that the 9 people
in FESCo do not have infinite time to do explicit things with every
single Feature that gets presented. FESCo is a steering committee. We
rely on you, the developers, to do your part for Features." Josh noted
that other Fedora 10-approved Features had been dropped simply because
of their owners failing to follow the process: "They were dropped later
for nothing more than lack of following the Feature process. Not out of
spite, or lack of interest, or some evil desire to promote only things
that some Cabal cares about." Separately Josh explained[16] that
although the advertising advantage of declaring LXDE a Fedora 10 Feature
had been missed it did not mean Christoph's work was wasted.

[16]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00510.html

While sympathetic to Christoph and extremely interested in LXDE Kevin
Fenzi was[17] largely in agreement with Bill Nottingham and Josh Boyer
that "[LXDE] was not testable by Beta, so it shouldn't be advertised as
a feature this time. I'm sorry that that is due to communication
problems. ;( I find it very unfortunate." He suggested that although
there had been a string freeze it would be possible to make LXDE a
Feature for Fedora 11. Christoph appeared[18] unhappy still but keen to
move forward with these suggestions.

[17]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00495.html

[18]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00513.html

David Woodhouse expressed[19] regret at the lack of communication,
sought further details to avoid such failures in the future and
suggested "[o]ne thing we can do in future to make that situation better
is Cc the feature owners when the meeting agenda is sent to
fedora-devel-list." As a related matter he urged "[l]et's get the final
two packages reviewed -- and that's another area where we could do with
some improvement, because failing to approve packages really _is_
verging on the 'deletionism' you spoke of. But that's a separate
discussion." He later proposed[20] "[...] that each FESCo member should
try to work on at least one package review per week. Each week at the
FESCo meeting, we'll ask members which reviews they've worked on in the
past week [...] ad anyone else who considers themselves an active member
of the Fedora development community should also try to do the same." The
size of the review queue was cited by John Poelstra as 1,212 which
surprised[21] Hans de Goede into suggesting review swapping as a
solution: "[...] what we should be promoting much more is exchange
reviews. Just post a mail to fedora-devel-list, saying I've got these
and these packages which need review, and I'll gladly review any other
package in return." Patrice Dumas analyzed[22] the situation slightly
differently and noted that many of the review requests were blocked upon
waiting for upstream changes. He thought that "[...] the ratio of review
requests that nobody had a look at over the number of fedora
contributors" would be a statistic which might indicate if there were a
problem with a lack of reviewers.

[19]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00553.html

[20]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00673.html

[21]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00829.html

[22]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00836.html

Matters seemed to end amicably enough when Brian Pepple corrected[23]
Christoph's assumption that FESCo meeting summaries were not being
posted to @fedora-devel and this was accepted[24] with apologies by
Christoph.

[23]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00529.html

[24]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00649.html

The positive note continued to be sounded when Chuck Anderson asked[25]
for some practical advice on how he could help out with reviews and
Christoph sought[26] information on how to find suitable outstanding
reviews.

[25]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00854.html

[26]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00850.html

== Documentation ==

In this section, we cover the Fedora Documentation Project.

http://fedoraproject.org/wiki/DocsProject

Contributing Writer: Jason Taylor

=== Fedora 10 Release Notes ===

This week marked the freeze time for the release notes for the Preview
Release of Fedora 10. There was a lot of work done by the team in
getting the notes updated, edited, converted to xml and ready for the
translation team. It was a little late[1] due to lots of content and
tooling changes but with the added time taken less updates will be
needed for the final release.

[1]
https://www.redhat.com/archives/fedora-docs-list/2008-October/msg00103.html
Fedora Wiki Mailing List

There was conversation this week about the possibility of making a
fedora-wiki mailing list[1]. Some of the reasons for making a
wiki-centric list are that groups unrelated to documentation could ask
questions but not have the documentation related information that the
@fedora-docs-list generates to sort through and a forum for wiki
questions that aren't related to documentation but Fedora Project usage
of the wiki. After a series of replies supporting the creation of a wiki
list, it looks like it will be implemented in the near future.

[1]
https://www.redhat.com/archives/fedora-docs-list/2008-October/msg00069.html

== Translation ==

This section covers the news surrounding the Fedora Translation (L10n)
Project.

http://fedoraproject.org/wiki/L10N

Contributing Writer: Runa Bhattacharjee

=== Documentation Repository Updates ===

PaulFrields (stickster) announced[1] the updated repository information
for Fedora Documentation. Submissions to the "master" branch for the
documents is currently enabled[2] via
https://translate.fedoraproject.org.

[1]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00049.html

[2]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00052.html

=== Release Notes .pot File Delayed ===

KarstenWade (quaid) announced[3] a day's delay in the Fedora 10 Release
Notes .pot file, due to content changes and rewriting. The currently
projected date and time for its availability is 0700 UTC 12 October '08.

[3]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00062.html

=== Virt-* Modules Cannot Be Submitted Via Transifex ===

Translations for all the virt-* modules cannot be submitted[4] via
https://translate.fedoraproject.org. The backend repository of these
modules are currently hosted on hg.et.redhat.com, which is
inaccessible[5] from Transifex. With the Fedora 10 translation deadline
approaching fast, this issue is still unresolved.

[4]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00033.html

[5] https://bugzilla.redhat.com/show_bug.cgi?id=435412

== Infrastructure ==

This section contains the discussion happening on the
fedora-infrastructure-list

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: Huzaifa Sidhpurwala

=== Some Architectural Changes ===

Mike McGrath wrote[1] on the @fedora-infrastructure-list that we have
finally completed some consolidation we have been working on for the
past couple of months. We have also added a new class of server (bappX
servers). The bapp servers (there's only one right now) will be our job
control servers.

[1]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-October/m...

== Artwork ==

In this section, we cover the Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: Nicu Buculei

=== Fedora 10 CD/DVD Sleeves ===

Jarod Wen started to work on a set of CD and DVD sleeves for Fedora 10
"The style of the design follows the previous version used in Fedora 9.
Most of the sources used in these design are from the source of Solar
theme of Fedora 10" publishing a first draft[1] to @fedora-art. As first
reactions, Ian Weller stressed[2] the importance of using the MgOpen
Modata font "[...] as that's the font that Fedora uses for pretty much
everything in their designs"

[1]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00049.html

[2]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00050.html

A concern about the number of colors was raised by Rahul Sundaram[3]
"IIRC, the number of different colors shoots up the printing cost of the
material drastically" and Paul Frields[4] "Make sure that the printing
of the design is going to be a reasonable cost for the Ambassadors
bulk-ordering the discs. If there are any sort of color restrictions, we
should get those figured out up-front" but was cleared[5] by MairinDuffy
"Actually you don't have to worry about this for the sleeves. It is only
the disc designs themselves that are color-limited because of the screen
printing process used to print them."

[3]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00051.html

[4]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00057.html

[5]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00059.html

Another concern was raised by Mairin about the use of potentially
tainted older version of the Solar theme "That is the old one, so you
shouldn't use it. Please don't use any images from round 2, only round
3", a problem quickly corrected by Jarod in a second7] and third[8]
drafts.

[6]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00065.html

[7]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00066.html

[8]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00071.html

Also Paul proposed[4] the addition of an informative text "For Live CD,
include a small bit of information about how to use the media: `This
disc contains a complete bootable Fedora environment. To use it, make
sure your computer supports booting from its CD or DVD drive. Then
insert the disc, turn the computer's power on, and follow the prompts.
If you enjoy this Fedora environment, you can copy it to your computer
using the desktop 'Install to Hard Disk' icon. For further assistance,
visit help.fedoraproject.org'". The proposal was followed[9] by a
comparison between SUSE and Fedora sleeves from John Poelstra: "Here is
an interesting comparison I noticed at OSCON this year after stopping by
the SuSE booth [...] I realize there are differing philosophies as to
how much or little content should be on the cover and what it should say
:)" Nicu also offered[10] his opinion regarding this comparison "Maybe
*I* am not the target audience[1], but I do not like the SUSE cover, its
too busy, with so much text that is simply makes me to not read it. Only
the 'Novell' word grab my attention, but not too much. It's boring and a
'corporate' look. I like how from the first look I can understand that
the other disc is a DVD and is Fedora. "

[9]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00073.html

[10]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00077.html

== Security Advisories ==

In this section, we cover Security Advisories from
fedora-package-announce.

https://www.redhat.com/mailman/listinfo/fedora-package-announce

Contributing Writer: David Nalley

=== Fedora 9 Security Advisories ===

    * mediawiki-1.13.2-41.fc9 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg0...
    * ruby-1.8.6.287-2.fc9 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg0...
    * condor-7.0.5-1.fc9 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg0...
    * postfix-2.5.5-1.fc9 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg0...
    * dbus-1.2.4-1.fc9 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg0... 

=== Fedora 8 Security Advisories ===

    * mediawiki-1.13.2-40.99.fc8 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg0...
    * postfix-2.5.5-1.fc8 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg0...
    * ruby-1.8.6.287-2.fc8 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg0... 

== Virtualization ==

In this section, we cover discussion on the @et-mgmnt-tools-list,
@fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora
virtualization technologies.

Contributing Writer: Dale Bewley

=== Enterprise Management Tools List ===

This section contains the discussion happening on the et-mgmt-tools list

==== Importing Appliance Raw Disk Images ====

Bryan Kearney cross-posted[1] an RFC to the @thincrust-devel[2] list.
The goal being the ability to importing "appliance" disk images. Cole
Robinson said[3], "the whole problem of taking an existing disk image
and turning into something useful is not handled well by any of the
virt-* tools", and wondered where best to add it. Daniel P. Berrange
said[4], "the live cd installer class in virtinst can basically do 90%
of the neccessary stuff already".

[1]
https://www.redhat.com/archives/et-mgmt-tools/2008-October/msg00086.html

[2] http://www.thincrust.net/

[3]
https://www.redhat.com/archives/et-mgmt-tools/2008-October/msg00088.html

[4]
https://www.redhat.com/archives/et-mgmt-tools/2008-October/msg00093.html

=== Fedora Xen List ===

This section contains the discussion happening on the fedora-xen list.

==== Support for F10 domU on RHEL5.2 dom0 ====

Jon Stanley noticed[1] that a RHEL 5.2 dom0 was unable to install a
current Fedora 10 Rawhide domU. Mark McLoughlin explained[2] that the
"older virt-install doesn't know to look in the 'images-xen' stanza in
the '.treeinfo' file to determine which images to use". Patches are
being backported to RHEL 5.3 for this[3]. A further issue[4] is a lack
of bzimage support in the libxc of RHEL.

[1]
https://www.redhat.com/archives/fedora-xen/2008-October/msg00002.html

[2]
https://www.redhat.com/archives/fedora-xen/2008-October/msg00003.html

[3] https://bugzilla.redhat.com/460585

[4] https://bugzilla.redhat.com/457199

Michael Young asked[5] about a timeline for these patches and expressed
concern that there could be "a period of time where there won't be any
supported Redhat or Fedora platform to run Xen guests, and of course the
lack of current support in RHEL is reducing the testing that Fedora 10
xen is getting."

[5]
https://www.redhat.com/archives/fedora-xen/2008-October/msg00006.html

=== Libvirt List ===

This section contains the discussion happening on the libvir-list.

==== KVM Domain Migration Not Yet Supported ====

Kenneth Nagin noticed[1] a problem migrating a KVM guest. Daniel P.
Berrange said[2] that's because it's not yet supported. "Currently KVM's
private fork of QEMU has some migration support, but this is not written
in a suitable way for " libvirt "to use - it blocks the QEMU monitor on
startup. Upstream QEMU is getting better migration support and once
that's done we can support it in libvirt."

[1]
https://www.redhat.com/archives/libvir-list/2008-October/msg00147.html

[2]
https://www.redhat.com/archives/libvir-list/2008-October/msg00148.html

==== Disable QEMU Drive Cacheing ====

Daniel P. Berrange posted[1] a patch with the following explaination.

QEMU defaults to allowing the host OS to cache all disk I/O. This has a
couple of problems

    * It is a waste of memory because the guest already caches I/O ops
    * It is unsafe on host OS crash - all unflushed guest I/O will be
    lost, and there's no ordering guarantees, so metadata updates could
    be flushed to disk, while the journal updates were not. Say goodbye
    to your filesystem.
    * It makes benchmarking more or less impossible / worthless because
    what the benchmark things are disk writes just sit around in memory
    so guest disk performance appears to exceed host diskperformance. 

This patch disables caching on all QEMU guests. NB, Xen has long done
this for both PV & HVM guests - QEMU only gained this ability when
-drive was introduced, and sadly kept the default to unsafe cache=on
settings.

[1]
https://www.redhat.com/archives/libvir-list/2008-October/msg00180.html

==== NSIS Windows Installer in Nightly Builds ====

Richard W.M. Jones added[1] NSIS[2] support to generate a Windows
installer in the nightly build. Richard also recently blogged[3] on the
subject on MinGW and NSIS.

[1]
https://www.redhat.com/archives/libvir-list/2008-October/msg00191.html

[2] http://nsis.sourceforge.net/

[3]
http://camltastic.blogspot.com/2008/10/mingw-compile-software-for-windows...

In reply to another thread[4] Daniel P. Berrange explained support is
targeted for "client-mode only. ie, allow use of libvirt clients to
connect to remote Linux hosts running libvirtd", and that there is no
emminent Hyper-V or VMWare support.

[4]
https://www.redhat.com/archives/libvir-list/2008-October/msg00304.html

==== Domain Events API Progress ====

Ben Guthro posted[1] patches to implement domain state transition events
which were previously discussed[2].

[1]
https://www.redhat.com/archives/libvir-list/2008-October/msg00245.html

[2]
http://www.redhat.com/archives/libvir-list/2008-September/msg00321.html

=== oVirt Devel List ===

This section contains the discussion happening on the ovirt-devel list.

==== oVirt Qpid API ====

Ian Main continues to work[1] on a qpid API for oVirt which leverages
the device enumeration[2] and qpid support[3] in libvirt. Ian extended
the oVirt API to include network configuration information. Ian also
posted[4] a demo script.

[1]
https://www.redhat.com/archives/ovirt-devel/2008-October/msg00101.html

[2]
https://fedoraproject.org/wiki/FWN/Issue146#Host_Device_Enumeration_API

[3]
https://fedoraproject.org/wiki/FWN/Issue146#QPID_Modeling_Framework_and_l...

[4]
https://www.redhat.com/archives/ovirt-devel/2008-October/msg00150.html 
-- 
  Oisin Feeley
  http://fedoraproject.org/wiki/OisinFeeley