Fedora Weekly News #148

Oisin Feeley oisinfeeley at imapmail.org
Mon Oct 20 14:28:35 UTC 2008 

     Fedora Weekly News Issue 148
          1.1 Announcements
                1.1.1 The Big ACL Opening
                1.1.2 Fedora Test Day
                1.1.3 K12Linux Release Candidate 1 Now Available
          1.2 Developments
                1.2.1 OpenOffice and go-oo
                1.2.2 PackageGurus, SpecMentats or UeberPackagers?
                1.2.3 A Single Torrent ?
                1.2.4 The Old Sendmail Argument
                1.2.5 Review-o-matic
          1.3 Documentation
                1.3.1 Lead Writers
          1.4 Translation
                1.4.1 Preview Version of Release Notes Available
                1.4.2 String Freeze Breaks
                1.4.3 Unscheduled Maintenance of
                translate.fedoraproject.org
                1.4.4 PackageKit Translation Request
          1.5 Artwork
                1.5.1 No Echo for Fedora 10 CD/DVD
          1.6 Security Advisories
                1.6.1 Fedora 9 Security Advisories
                1.6.2 Fedora 8 Security Advisories
          1.7 Virtualization
                1.7.1 Enterprise Management Tools List
                      1.7.1.1 Starting Guests from a Desktop Icon
                      1.7.1.2 Plugins for Performance Monitoring
                      Applications
                1.7.2 Fedora Xen List
                1.7.3 Libvirt List
                      1.7.3.1 Openvz Bridge Support and Related Patches
                      1.7.3.2 Guest Image Locking
                      1.7.3.3 Exporting the Label on Block Devices
                      1.7.3.4 Experimental User Mode Linux Driver
                      1.7.3.5 Experimental Driver Thread Safety
                1.7.4 oVirt Devel List

= Fedora Weekly News Issue 148 =

Welcome to Fedora Weekly News Issue 148 for the week ending October 19,
2008.

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

The preparations for Fedora 10 and beyond are reflected in this week's
issue: "Announcements" alerts us to "Fedora Test Day"; "Documentation"
conveys a request for "Lead Writers"; "Developments" examines
"Review-o-matic" which may help triage our ever-expanding package
repositories; "Translation" explains the "String Freeze Breaks"
occasioned by the imminent release of Fedora 10; "Artwork" dives into
icon controversy with "No Echo for Fedora 10 CD/DVD"; the latest
"SecurityAdvisories" are worth checking out; and finally
"Virtualization" shares some tips on "Starting Guests from a Desktop
Icon" and the latest "Experimental User Mode Linux Driver". But wait!
There's more!: "Announcements" highlights "The Big ACL Opening" as a 
further opening of the Fedora Project infrastructure to contributors.

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 

[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

=== The Big ACL Opening ===

Casey Dahlin announced[0] that "we are now on a two-tiered access system
for CVS. The final change which we will be making is the mass ACL open."
He went on to explain, "what will happen is all packages which are now
set to be private, accessible by their maintainers and a few specific
individuals only, will be opened up to all überpackager members. Members
of überpackager represent a filtered minority of CVS comitters, but
membership is easy to come by for anyone that asks."

[0]
http://www.redhat.com/archives/fedora-announce-list/2008-October/msg00006.html

=== 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 16,
2008[3]." Testing will focus on security audit, better LIRC support, and
Fedora 10 Beta snapshot #1".

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

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

=== K12Linux Release Candidate 1 Now Available ===

Peter Scheie announced[4] "that K12Linux Release Candidate 1 is now
available for download. K12Linux is LTSP 5 built on Fedora 9, and is
slated to become the successor to the highly acclaimed K12LTSP. K12Linux
comes as a live image which can be used to create a LiveUSB or LiveDVD
with the client chroot already installed & configured." Go check it out!

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

== Developments ==

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

Contributing Writer: Oisin Feeley

=== OpenOffice and go-oo ===

The controversy swirling around the OpenOffice.org "fork" named "go-oo"
popped up[1] along with a request for information about why "[...]
Fedora ships a relatively stock (stock + 98 patches) OO.o rather than
shipping [...] the extended feature set provided by go-oo such as the
opengl slide transitions [?]" Caolán McNamara, the maintainer,
explained[2] that he attempted to stick close to upstream "[w]ith a
fairly aggressive push of any fedora patches back upstream asap [...]"
and based upon the low number of reported bugs he believed "[...] this
route provides the stablest and best supported product for fedora
users." Caolán added that the OpenGL slide transitions were "still in a
bit of a confused state" but would probably appear in Fedora 11. While
Caolán eschewed any animosity to the parent ooo-build[3], and emphasized
that Fedora had contributed fontconfig glyph replacement functionality
to ooo-build and extended their GStreamer patches, he suggested that
using ooo-build as an upstream would result in a confusing morass of
patches upon patches.

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

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

[3] A collection of patches presented through a subversion repository
which was intended to work around organizational and practical
bottlenecks in OpenOffice.org development.
http://wiki.services.openoffice.org/wiki/Ooo-build

Muayyad AlSadi argued[4] that go-oo should be used because "[...] one
can drop java and ship openoffice on a livecd [like Novell, Gentoo,
Ubuntu.]" In the exchange that followed Muayyad revealed[5][6] that he
had produced a Fedora-derived LiveCD with Openoffice.org on it by the
expedients of moving some large Java jar and .class files out of the
core rpm package and restricting the language choice to Arabic only.
Muayyad suggested that adding the resulting missing pieces could be done
by adding them to comps.xml . Caolán argued[7] that providing a
non-working OpenOffice.org (the search functionality depends on
Lucene[8] and the XSLT wizard depends on SAXON[9] both of which are
written in Java) was an unacceptable user experience. It also appeared
that the other distributions mentioned by Muayyad had restricted
themselves to a small subset of languages which would result in a
non-usable OpenOffice.org for many Fedora users.

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

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

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

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

[8] A text search-engine library: http://lucene.apache.org/java/docs/

[9] An XML stylesheet processor: http://saxon.sourceforge.net/

Caolán suggested[10] that using go-oo as a base would not solve the Java
dependency and referred[11] to his own work to reduce Java dependencies
as a way in which this goal might be achieved: "Taking `removing java
from core dependencies' as the target, then the right approach is the
boring slow-fix stuff to e.g. rewrite the help search to not require the
java lucene stuff and to tweak the xsltfilter stuff to be a standalone
expert-style feature that only appears in the menus when the xsltfilter
package is installed and place the saxon requires on that subpackage,
and so on for other java functionality." Caolán had previously split out
the beanshell scripting engine to a separate package and he recommended
that Muayyad: "[...] investigate further as to why exactly removing or
replacing java dependencies is the target, when I last thought seriously
about the area I felt the right thing to do was stop swimming against
the tide and boil out some concrete standalone feature requires for gcj
to be able to provide the functionality that was missing at that stage
to implement the java-needs of OOo, and our fabulous java hackers simply
implemented them. Your questions should be what exactly are the size
figures are for requiring the java dependencies and where is that space
getting used and why."

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

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

=== PackageGurus, SpecMentats or UeberPackagers? ===

On 2008-08-13 it was announced[1] on @fedora-announce that CVS access
had been revamped to allow trusted users to modify packages
"distro-wide", not merely packages which they own or co-maintain. In
order to clarify the changes some new terminology was introduced.
Ordinary maintainers (previously members of the "cvsextras" group) are
now members of the "packagers" group and those who are trusted to assist
with all packages are members of the group named "uberpackager". This
change has been coming for some time (see FWN#136[2] for previous
discussions) and seems as though it will help cut out some bureaucracy.

[1]
https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00007.html

[2]
http://fedoraproject.org/wiki/FWN/Issue136#New.libraw1394.Rebuild.Exposes.Closed.ACLs

Lennart Poettering objected[3] to the term "uberpackager" as too
redolent of "Nazi terminology" and asked "[...] if we have
"Überpackagers", maybe it's time to rename normal packagers to
"Unterpackagers"? That would fit awfully well into our pursuit for world
domination, wouldn't it?"

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

Casey Dahlin took the point but wondered[4] why Lennart had waited until
now to object which led[5] Lennart to clarify that he did not follow all
Fedora mailing-list discussions and "[...] noticed the adoption of this
term for the first time a week or two ago when I had to log into FAS and
noticed I had become an Überpackager. And, oh, god, with my blonde hair
and blue eyes it felt so deserved... "

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

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

Many respondents were sympathetic to the objection. Paul Frields
explained[6] that "[u]se of "über-" has indeed made the jump to slang
English. I think there's an increasing tendency in new media communities
to attempt to subvert or undermine existing connotations of terms, for
better or worse. In cases like this, I think we unconsciously or
semi-consciously think we're deflating any unpleasantness by using them
casually.I'm certain no offense was intended, but your comment is worth
serious consideration." The problem of over-sensitivity was raised by
several contributors including Andrew Parker who asked[7] "Do we have to
have all our words vetted against every language before we can use
them?" and provided some examples of common failures to do this. Axel
Thimm added[8] further arguments against Lennart's interpretations.

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

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

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

Some extensive bike-shedding[9] followed with suggestions for alternate
terminology ranging from Jon Ciesla's "spec-mentat"[10] to Seth
Vidal's[11] "WednesdayPackager". Seth exclaimed[12] "[...] our ability
to make subtle references that even we eventually don't understand kicks
ass. :)"

[9] http://en.wikipedia.org/wiki/Color.of.the.bikeshed

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

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

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

At one stage it appeared[13] that Toshio Kuratomi would change the name
to "ultrapackagers" and Lennart excused[14] himself from further
discussion: "Toshio already agreed to changing this term and it is not
too much work. So let's just do it and forget about it and not continue
this discussion here. I am here for the code, not for discussing
Nazism." Axel Thimm[15] and Till Maas disagreed[16] that the prefix
"über-" necessarily carried the connotations associated with it by
Lennart and several others on the thread. Toshio noted[17] that he would
need to make any change either tomorrow or else put it off until after
the freeze. In passing he expressed a preference for the term
"masterpackager" leading Jesse Keating to joke[18] that he preferred his
bike sheds colored chartreuse.

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

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

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

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

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

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

=== A Single Torrent ? ===

The ability of many torrent clients to offer the user a choice of
specific files within a torrent prompted JesseKeating to ask[1] "[...]
does it make sense to collapse the DVD and CD torrents into a single
torrent and allow people to use the client to pick which they want? Are
there pros/cons to this?"

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

Jon Ciesla wondered if the perceived "lowest common denominator client"
bittorrent-curses offered this ability. bittorrent-curses was
dismissed[2] as being dead and closed by Jesse Keating which led[3] to a
slightly hyperbolic demand by Behdad Esfahbod for an equivalent to
facilitate "mindless" downloading. In a later exchange with John Reiser
it was clarified[4] that the "old dead" bittorrent4.4.0-7 only
downloaded all files in a torrent. Dennis Leroy and Conrad Meyer
provided[5] reassurance that both rtorrent and transmission provided
ncurses-based interfaces that offer marking specific files for download.

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

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

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

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

Jesse explained[6] that one advantage of what he was suggesting was
"[w]e can reduce the number of links offered to users on download pages,
simplify the instructions, and have a better end user experience." His
workflow avoided resorting to the command line.

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

Richi Plana responded[7] that lumping all the isos into a single torrent
was not a good idea as "[m]ost people really only download one iso
[...]" and Jesse hastened[8] to clarify "I meant collapsing them per
arch, so you'd have one torrent file for Fedora 10 x86.64, one for
Fedora 10 i386, ppc, source etc.. and probably different torrent files
for the i686 Live and x86.64 Live offerings. I wouldn't imagine one
giant torrent file that has every iso of the release on it."

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

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

Some definite preferences were expressed[9] by Chris Snook on how to Do
The Right Thing By Default: "there needs to be a standalone torrent that
has just the DVD ISO (and maybe the netinst ISO) for all those newcomers
who don't know any better, so we don't scare them off with a 9 GB
torrent." Chris raised the problems of prioritization and smaller sets
of disjoint peers for more specific torrents, especially for the
case[10] of one CD iso per torrent. The ability to prioritize specific
files might allow work to be started sooner by, for instance,
downloading a LiveCD first. Callum Lerwick suggested [11] using Azureus
for this purpose.

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

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

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

A separate problem posed[12] by Seth Vidal was the absence of good
trackers and seeders: "[I]n terms of clients - there are a lot of
choices. In terms of trackers and good server-like-seeders there are NOT
a lot of choices. [T]he original bittorrent client pre-proprietary is
the best we have right now." Callum Lerwick again noted[13] Azureus'
abilities: "I'd suggest just biting the bullet, fire up a vncserver
instance, and run Azureus. It is incredibly flexible at managing many
torrents at once, it can run a tracker as well, and the GUI allows you a
level of insight into the status of a torrent that you just won't get
from a text client."

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

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

=== The Old Sendmail Argument ===

An old discussion (see FWN#145[1]) was given new legs when instructor
Lutz Lange asked[2] why sendmail "[...] is still the default MTA in
Fedora [?]" Patrice Dumas answered[3] with an excellent summary of the
discussions preceding Fedora 10: "To sum up some people considered that
local delivery was a must for the default MTA, and that a send-only MTA
wasn't good enough, e.g., for cronie. My personnal opinion is that there
should not be any MTA in the @base or @code group, and that a MTA should
be chosed if it is pulled in as a dependency, so it could be sendmail or
anything else. Whether local delivery is a must for cronie or other
packages that today require /usr/sbin/sendmail is another story that
caould be discussed a bit more, though in the end it seems to me that
this should be up to the maintainer."

[1]
http://fedoraproject.org/wiki/FWN/Issue145#Default.Deactivation.of.Services

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

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

Les Mikesell rose[4] to the defense of sendmail as a highly-audited and
extensible standard with which most administrators are familiar. All
these points were disputed by various and sundry and Dominik
Mierzejewski added[5] the interesting information that postfix has
partial milter support thus allowing it to be extended easily. David
Woodhouse took issue[6] with the idea that milter support was important:
"Some of the better alternatives don't even _try_ to run milters,
because they are fully-featured enough in their own right, without
needing to rely on external software" and appeared[7] to put to rest the
idea that it was difficult for these alternatives to run tests on
messages prior to accepting them in an SMTP conversation. Les
finished[8] off with an argument invoking the inertia of a wide base of
currently working sendmail systems: "[Postfix is] worse at backwards
compatibility. Fedora seems to assume that their users don't already
have something working, so maybe that's not a concern to anyone here. If
it shipped with a decked-out, well tested setup already integrated with
MimeDefang/clamd/spamassassin it might be enough of an improvement to
switch."

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

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

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

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

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

Some abstruse jokes were cracked[9] when Denis Leroy observed[10] that
"[t]he sendmail configuration file is arguably one of the most complex
and obfuscated configuration format ever designed in the history of
computer science. :-)" and Alan Cox suggested[11] comparing it to IBM's
JCL or TECO. But Les Mikesell believed[12] that "[...] these days all of
the m4 templates anyone might ever need have already been written, so
everyone just uncomments or tweaks a few lines in sendmail.mc for
options and the default already does the right thing for most people.
Or, for complex scenarios you can drop in MimeDefang as a milter and do
most of the control steps with perl snippets."

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

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

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

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

The decision to ship the Desktop spin[13] with no MTA was mentioned[14]
by Colin Walters with the observation that mail from logwatch would be
sent to /dev/null as "[...] most logs from a desktop machine are just
pure noise." In response to Matthew Woehlke's desire for a means to view
some log information Rahul Sundaram suggested15 working on
gnome-system-log.

ArjanvandeVen threw[16] some cold water over the discussion with the
observation that "[a]nybody trying to argue for the politics of
Exim/Postfix/Sendmail as default choice is ignoring the reality..." as
users simply requiring send-only MTAs can use sSMTP (or something
similar) while those requiring a full-blown MTA have strong individual
preferences. Karel Zak and Colin Walters returned[17] to the vision of
Fedora as a "desktop distribution" with Colin arguing "I understand
there's the "workstation" use case where you're say doing web
development and you want to install Apache or Tomcat or something
locally and run logwatch on it. We obviously will support that. But it
doesn't make sense for the default desktop OS to be sending you email
about all the junk going on under the hood."

[13] https://fedoraproject.org/wiki/SIGs/Desktop

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

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

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

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

=== Review-o-matic ===

Kushal Das announced[1] that he was starting work on a project to help
automate the repetitive parts of the review process, as originally
suggested[2] by Chris Weyl on @fedora-packaging. This seems timely in
light of recent discussions which indicated (see FWN#111[3] and
FWN#147[4)] that as the number of Fedora packages grows (PackageDB
indicates[5] that Fedora has grown to offer approximately 6,842
packages) the review queue has on occasion become congested.

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

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

[3] http://fedoraproject.org/wiki/FWN/Issue111#Review.Queue.Cont.

[4]
http://fedoraproject.org/wiki/FWN/Issue147#LXDE.Feature.Removal.Disappointment.-
.How.to.Avoid

[5] https://admin.fedoraproject.org/pkgdb/collections/

Kushal listed the basic tasks as: rpmlint; build in mock; md5sum matches
between srpm and upstream. The tool would, upon submission of a new
review request, download the SRPM and SPEC, run the aforementioned tasks
and then post the results on bugzilla.

"Pierre-Yves" was among those that requested[6] the ability to make the
build directly on koji. Richard W. M. Jones explained[7] that this would
allow checking that the package also built on PPC/PPC64 architectures.
Paul Frields and Brian Kearney liked[8] the idea of doing koji
scratch-builds and Pierre-Yves and Debarshi Ray concurred[9] as long as
it was possible to keep the builds from being removed until the review
was completed. Ignacio Vazquez-Abrams thought[10] that it ought to be
easy enough to do some automatic annotations conditional on the success
of the build.

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

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

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

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

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

Approval of the general idea was expressed[11] by Richard W. M. Jones :
"[...] every package guideline which (a) isn't already done by rpmlint,
and (b) can feasibly be checked automatically, should be checked." He
added that it would be useful to extend rpmbuild to be able to run test
tools such as rpmlint or "review-o-matic" on its generated packages.
Ville Skyttä later confirmed[12] that Richard would need to get a patch
in to rpm itself in order to get "[...] rpmbuild to run rpmlint
automatically on the packages that rpmbuild makes [.]"

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

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

DebarshiRay linked[13] to a script named "fedora-qa" which seemed to
overlap some of the functionality of rpmlint and added that Rakesh
Pandit and Debarshi Ray were[14] working on using it to "[...] do spec
file sanity checking [...]" He stated his own progress as "I have a very
initial stage of code up and running which is taking bugzilla numbers
manually (due to limited speed of network). Currently only doing koji
builds and if successful then rpmlint on resultant rpms. It is also
commenting back to the bugzilla entries."

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

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

It turned[15] out that Chris Weyl had also gone to work on a base
implementation and he asked if there was room for collaboration.

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

== Documentation ==

In this section, we cover the Fedora Documentation Project.

http://fedoraproject.org/wiki/DocsProject

Contributing Writer: Jason Taylor

=== Lead Writers ===

The Documentation Project is looking[1] for lead writers for some of the
published documentation, such as the release notes. Lead writers are
responsible for making sure the information in the documentation is
updated for the current release, some editing tasks and publication
duties.

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

== Translation ==

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

http://fedoraproject.org/wiki/L10N

Contributing Writer: Runa Bhattacharjee

=== Preview Version of Release Notes Available ===

The .pot file of the F10 Release Notes was[1] finally made available.
The preview version was delayed[2] due to a shortage of beat writers,
rewriting and a bug in xml2po that prevented the creation of the .pot
file for translators. The file is available from the Fedora git
repository and translations can be submitted via
https://translate.fedoraproject.org.

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

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

=== String Freeze Breaks ===

Anaconda and firstboot modules broke[3] in the String Freeze. The new
strings in the naconda module were[4] a result of the earlier
non-creation of the .pot file. A request for a string freeze break for
the comps module was rejected[5] by FTP. DimitrisGlezos suggested[6]
that a separate string freeze policy/schedule for comps can be discussed
upon for the future releases.

Fedora packages are[7] currently string frozen for Fedora 10: no new
translated messages can be added without the prior permission of the
Fedora Localization Team as per the String Freeze Policy[8].

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

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

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

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

[5]
https://www.redhat.com/archives/fedora-devel-announce/2008-September/msg00013.html

[7] http://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy

=== Unscheduled Maintenance of translate.fedoraproject.org ===

Asgeir Frimannsson announced[8] an unscheduled outage for
https://translate.fedoraproject.org. It mostly affected the display of
translation statistics and file download. Translation submission
remained unaffected.

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

=== PackageKit Translation Request ===

Richard Hughes requested[9] translations of the PackageKit module for
Fedora 10. Ville PekkaVainio also suggested[10] translating the
gnome-packagekit module for additional value.

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

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

== Artwork ==

In this section, we cover the Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: Nicu Buculei

=== No Echo for Fedora 10 CD/DVD ===

Martin Sourada asked[1] in both @fedora-art and @fedora-desktop about a
decision about the use of the Echo icon theme, which "[...] is the
default icon theme in F10 since Beta (for testing purposes and
exposition to wider audience)" in the upcoming Fedora 10. "What I'd like
to ask you now is the preferred way to decide upon it. Should we hold a
irc meeting, do a mail vote, set up a vote in the fedora voting
system,other way?"

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

In a harsh reply, David Zeuthen, from the Red Hat Desktop Team,
attacked[2] the icon set: "the fact that the Fedora leadership allows
this art charade to go on and on and on for eons is complete and utter
FAIL" and expressed his strong opposition to a vote: "can we please get
away from this voting business? It's a disease. Consider what happened
if we started voting on what patches should go in tarballs? Or what the
dialogs in your desktop looked like? Or what options to use by default.
Or what IO scheduler to use in the kernel. IMNSHO, voting is making
Fedora turn into something mediocre that I, for one, really don't want
to work on, much less rant about. Heck, I'd be running Debian if I
wanted something like this[.]" David also expressed his opposition to
having a personalized default icon theme in Fedora at all: "It's
definitely not about stupid zero-sum games with misunderstood 'value
adds' that may have questionable value in the first place."

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

Martin pointed out[3] that Echo is basically an upstream project
"Technically the development of Echo Icon Theme is an Upstream job,
though done by fedora artists and aiming to be default on Fedora and I'd
say we are now as open with our development as gnome's default or kde's
default icon themes are" and explained his original question as not a
simple call to vote "voting is the last option when there is no better
way on deciding things". He also tried to not vilify voting "there's
nothing wrong with voting system, if used with care. Fedora Art isn't
about competition but about collaboration. We'd like Fedora to have
distinctive look from other distros and we seem to have enough people to
do so, for some people it indeed feels like competition and motivates
them to work harder - and that's a good thing - however when you accept
is as a competition, you're disappointed when you are not the winner -
and it's easier to accept 'defeat' when it's decided by community that
by one (wo)man."

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

Jesse Keating returned to the question about the purpose of an original
icon set "why is looking different, at the icon level, a good thing?
Does it not just confuse the greater community?". Martin pointed[5] that
the situation is not more confusing that the current situation "Well,
gnome and kde already look different on that level. Does that confuse
greater community?" and he continued arguing for a personalized theme
"Does it bring anything to Fedora user? Different, more lively, more
3D-like art. Perhaps wider coverage of Fedora specific stuff (but that
does not need to be limited to Echo). Is that a good thing? Seriously,
who is to decide that? Definitely not me. I believe Art and Desktop
Teams (and various other desktop SIGs when Echo gets selected for other
DE's than gnome) together have the right to do so."

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

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

Bill Nottingham calmed the spirits[6] "[...] there's no need to toss
around 'grow up' and 'stupid'; we're all adults (or close enough) here,
and that's unlikely to bring people around to your point of view" and
asked two crucial questions "So, why are we, as a project, interested in
working on a large set of never-to-be-upstreamed changes when there is
an existing upstream?" and "Why is Nodoka 'ok', and Echo not, in
people's opinion?"

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

Will Woods offered[7] two quick replies "First, Nodoka doesn't
drastically change UI elements from their upstream defaults, or from
other OSes" and "Echo, on the other hand, significantly changes the look
of basic UI elements". He also added a good deal of criticism for the
Echo icon set, using input from "his user-interface-designer wife to
help work on Echo", pointing to a significant number of flaws, which,
for the most part, were acknowledged[8] by Martin "in icon theme it's a
tremendous work and a one that will never ends."

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

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

Máirín Duffy also gave[9] her feedback for the Echo icon theme status "I
have put together the following visual critique of Echo from rawhide.
Let me preface it by saying it is obvious that Echo has come a long way;
it is most noticeable in the applications menus and in some of the
desktop-size icons (I really really love the improvements in the
computer icon, it looks much cleaner now) but it is still very lacking
in quality in areas that affect most applications on the desktop - file
/ edit menus, toolbars, and the panel. Creating an entire icon theme is
no small task." For a better representation, she created a page with a
visual outline of a large number of problems[10].

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

[10] https://fedoraproject.org/wiki/Duffy/EchoCritiqueF10

After the long argument, Martin Sourada stepped back[11] from the
proposal "I'd very much like to hear Luya's opinion, but I don't feel
like supporting Echo for F10 as default much longer..." His
co-maintainer, Luya Tshimbalanga assumed the blame for proposing the
theme as a feature, even if it was not ready enough "Blame me for
pushing Echo through FESCO. After following suggestion for submitting it
to FESCO, I was a bit surprised that icon set was accepted. Were it
rejected, we will not have to deal with current issue. In one part we'd
withdraw Echo while taking a hit from outside for once again not include
it; in other part we keep, taking a hit for having some incomplete set.
That is dilemma which basically means choosing a poison."

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

[12]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00157.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 ===

    * drupal-6.5-1.fc9 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00388.html
    * neon-0.28.3-1.fc9 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00367.html
    * cups-1.3.9-1.fc9 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00380.html 

=== Fedora 8 Security Advisories ===

    * drupal-5.11-1.fc8 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00450.html
    * bluez-utils-3.35-3.fc8 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00396.html
    * bluez-libs-3.35-1.fc8 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00397.html
    * rubygem-activeresource-2.1.1-1.fc8 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00402.html
    * rubygem-actionmailer-2.1.1-1.fc8 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00403.html
    * rubygem-actionpack-2.1.1-1.fc8 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00404.html
    * rubygem-activerecord-2.1.1-1.fc8 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00405.html
    * rubygem-rails-2.1.1-2.fc8 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00406.html
    * cups-1.3.9-1.fc8 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00331.html
    * rubygems-1.2.0-2.fc8 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00322.html
    * rubygem-activesupport-2.1.1-1.fc8 -
    https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00323.html 

== 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

==== Starting Guests from a Desktop Icon ====

Orion Poplawski said[1] "I'd like to provide an icon that would startup
the virtual machine and connect to it." Cole Robinson posted[2] a couple
of ways to accomplish this.

    * With virt-manager and support for CDROM and USB devices 

UUID=`virsh --connect qemu:///system domuuid vm-name`
virsh --connect qemu:///system start $UUID
virt-manager --connect qemu:///system \
             --show-domain-console=$UUID

    * With virt-viewer which won't support CDROM and USB access 

UUID=`virsh --connect qemu:///system domuuid vm-name`
virsh --connect qemu:///system start $UUID
virt-viewer --connect qemu:///system $UUID

Each solution requires adequate user permissions to work.

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

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

==== Plugins for Performance Monitoring Applications ====

Guido Günther announced[1] the creation of libvirt plugins[2] for net
and block I/O monitoring in Munin[3].

Daniel Veillard posted[4] a patch to add this and similar plugins for
collectd[5] and Nagios[6] to the libvirt applications page[7].

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

[2] http://munin.projects.linpro.no/

[3] http://honk.sigxcpu.org/projects/libvirt/monitor/

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

[5] http://collectd.org/plugins/libvirt.shtml

[6] http://et.redhat.com/~rjones/nagios-virt/

[7] http://libvirt.org/apps.html"

=== Fedora Xen List ===

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

There was no list traffic this week.

=== Libvirt List ===

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

==== Openvz Bridge Support and Related Patches ====

Daniel Berrange posted[1] a patch series "derived from Anton Protopopov
/ Evgeniy Sokolov bridge device patches. It first does some generic
refactoring of MAC address handler in all drivers, then adds code to
extract OpenVZ[2] version number, then does network config, and finally
does filesystem config."

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

[2] http://wiki.openvz.org/

==== Guest Image Locking ====

Itamar Heim asked[1] "how libvirt envisions image locking. i.e., how do
we make sure multiple nodes are not trying to access the same storage
volume[?]"

Daniel Berrange said[2] in the domain XML format "the semantics are that
every <disk> section added to a guest config is read-write, with an
exclusive lock. To allow multiple guests to use the same disk, is
intended that you add either <readonly/> or <sharable/> element within
the <disk>."

Adding, "we only implement this for the Xen driver, handing off the
actual logic to XenD to perform. That we don't implement this in the
QEMU driver is a clear shortcoming that needs addressing. "

The problem on a single host is relatively simple, but more complex
among multiple host nodes. Guido Günther has been toying[3] "with the
idea of using DLM[4] for libvirt".

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

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

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

[4] http://sources.redhat.com/cluster/dlm/

==== Exporting the Label on Block Devices ====

Chris Lalancette described[1] his patch "To support LVM partitioning in
oVirt, one of the things we need is the ability to tell what kind of
label is currently on a block device. Here, a 'label' is used in the
same sense that it is used in parted; namely, it defines which kind of
partition table is on the disk, whether it be DOS, LVM2, SUN, BSD, etc."
Note that is is not the same as the partition type.

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

==== Experimental User Mode Linux Driver ====

Daniel P. Berrange applied[1] a patch that "implements a driver
supporting User Mode Linux[2] guests. User mode linux is a kind of
paravirtualized kernel which runs on a plain Linux host. It requires no
elevated privileges at all, except for some of the network integration.
It is a pretty straightforward thing to invoke, so I figured it would be
easy to write a driver to support it. I was right :-)"

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

[2] http://user-mode-linux.sourceforge.net/

==== Experimental Driver Thread Safety ====

Daniel P. Berrange continued[1] work toward making libvirt thread-safe.
The "series of 5 patches implement basic thread safety for the QEMU, LXC
and Network drivers. It does not address the OpenVZ or Test driver yet.
The Xen driver is totally stateless so does not require changes - though
I do need to verify there's no 'static' variables that are used in an
unsafe yet in Xen drivers." Daniel's earlier work was referenced[2] in
FWN #146.

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

[2]
http://fedoraproject.org/wiki/FWN/Issue146#libvirtd_Multi-threaded_Support_in_the_Works

==== oVirt Devel List ====

This section contains the discussion happening on the ovirt-devel list. 
-- 
  Oisin Feeley
  http://fedoraproject.org/wiki/OisinFeeley

More information about the fedora-announce-list mailing list