11:13 a.m.
Welcome to Fedora Weekly News Issue 153 for the week ending November
23rd, 2008.
http://fedoraproject.org/wiki/FWN/Issue153
Fedora 10 is released[0] tomorrow and we hope you can find time during
the install to read-up on what's going on in our rapidly moving Fedora
Project. We include a discussion in Developments of the need for "More
and Wider Testing". Translation shares that "Release Announcements in
Local Languages" are now possible, Artwork brings an important "Fonts
Survey" to your attention and also looks at the "Echo Perspective" icon
variants. SecurityAdvisories lists the essential updates. Virtualization
gets you up to speed with an overview of all the new features of "Fedora
10 Virtualization". This is just a sampling of this week's essential
reading for those who wish to stay abreast of where our distribution is
going and why. Enjoy Fedora 10!
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://fedoraproject.org/en/get-fedora
[1] http://fedoraproject.org/wiki/NewsProject/Join
Fedora Weekly News Issue 153
1.1 Developments
1.1.1 More and Wider Testing
1.1.2 Source File Audit Catches RPM Problems Early
1.1.3 One Issue Tracker to Rule Them All
1.1.4 RFC: Fix Summary Text for Lots of Packages
1.1.5 Smock: Simpler Mock for Chain Building
1.2 Translation
1.2.1 FLSCo Elections
1.2.2 Fedora-website Translation Repository
1.2.3 Fedora 10 Release Notes Branched
1.2.4 Release Announcements in Local Languages
1.2.5 Zero-Day Version of the Fedora 10 Release Notes
1.2.6 Sponsorship to cvsl10n Group
1.3 Artwork
1.3.1 Echo Perspective
1.3.2 CD Faces
1.3.3 Fonts Survey
1.4 Security Advisories
1.4.1 Fedora 9 Security Advisories
1.4.2 Fedora 8 Security Advisories
1.5 Virtualization
1.5.1 Fedora 10 Virtualization
1.5.1.1 New Features
1.5.1.2 Updates to Virtualization Software
1.5.2 Enterprise Management Tools List
1.5.2.1 Connecting to VNC Console on Remote System
Installs
1.5.2.2 Specifying Installation Media URLs
1.5.3 Fedora Xen List
1.5.3.1 Xen No Graphical Console and CentOS
1.5.4 Libvirt List
1.5.4.1 User Mode Linux Support
1.5.4.2 Increased Network Throughput with Large MTU
1.5.4.3 Integration with SolidICE
== Developments ==
In this section the people, personalities and debates on the
@fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
=== More and Wider Testing ===
In a thoughtful post Callum Lerwick suggested[1] that Fedora testing
coverage could be improved in several inter-related areas. These
included making Bugzilla easier to use; adding per-package rollbacks to
enable reversion to known good states; blocking yum updates on specific
reported bugs; providing a rescue image in /boot with the aforementioned
functionality; and lastly, enabling simple installation of specific
updates which might fix said reported bugs. Callum asked for respondents
to eschew what he called the "Hard problem fallacy" which consisted of
minor technical objections and asked them to provide answers modeled on
the pattern of "You are an idiot and your ideas are stupid. We're not
doing this."
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01370....
On the subject of rollbacks Jef Spaleta objected[2] that it was
complicated by the triggered scripts in packages. Currently there are no
tests for rollback and Jef wondered "...how do you set up a test which
attempts to measure whether rollback across a trigger boundary put you
back to where you were? How much of a different in state counts as
'break rollback' ?" He then added the problem of Obsoletes: "When an
obsolete is introduced in an update... can we rollback and get what we
had?" He finished off with the suggestion that Carrier Grade Linux might
have some experience to offer as they had attempted rollbacks. Seth
Vidal remembered[3] that "[...] the rollback functionality the CGL
wanted was removed from rpm recently." Gilboa Davra asked[4] how it
would be possible to pin-point what exactly had broken when there was a
"150 package update push. Will you rollback all the updates? Only the
updates that had _something_ to do with the breakage?" RalfCorsepius
also nixed[5] the idea as "[...] package rollbacks will never work in
general, because updates may contain non-reversable statefull operations
(e.g. reformatting databases)."
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01394....
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01396....
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01409....
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01442....
A comprehensive reply was made[6] by Gilboa Davra. In it he argued that
automating bug reports lowered the signal-to-noise ratio considerable
and objected to modification of yum to refuse updates until reported
bugs are fixed: "Say-what?!? Are we building a second Vista here?"
Although he liked the idea of a rescue image in /boot he cautioned that
space considerations impinged upon the need to keep "[...] a different
rescue image for each installed kernel unless you plan to keep the
original kernel[.]" As regards selective updates he stated: "You can
always enable updates-testing and selectively install what you need."
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01409....
A preliminary step was added[7] by Chris Lumens to those listed by
Callum: "I'd like to add a step (0) before we make bugs easier to file
and really crank up the number of reports we're getting: (0) More people
FIXING the bug, not just reporting them. You can have a giant user base
of people filing tons of bugs, and you can have a motivated and
effective QA/Triaging team whittling them down to the really important
and reproducable bugs. But without more people fixing them, the backlog
is just going to continue to build."
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01421....
When Peter Lemenkov wondered[8] why users were forced to register on
Bugzilla Bill Nottingham underscored[9] the need for tools which do not
swamp developers with large numbers of bugs. Alan Cox added[10] that the
key was "[...] one clear and accurate bug report that happens to contain
the right information and the user willing to help." Daniel P. Berrange
further explained[11] that "[...] 90% [of bugs] are essentially useless
when first reported. It requires several back/forth interactions between
myself & the bug reporter to get enough information to diagnose &
resolve the problem. If we create a system where we bombard maintainers
with bugreports & no scope for user interaction they'll end up directly
in /dev/null, and further discourage maintainers from addressing even
bugs with enough info."
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01408....
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01399....
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01415....
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01422....
The Ubuntu tool apport was discussed[12] as a possible solution several
times as was[13] the Debian tool reportbug.
[12]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01428....
[13]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01456....
An emphasis was placed[14] on providing Bugzilla tools for developers
and packagers by James Antill: "I won't mind getting 666 dups, or
dealing with 10x as many bugs in general, as long as I have a decent
local tool that can manage that number of bugs. Atm lots of TABs of open
bugs, and giant folders of BZ email are the best tools I've seen."
[14]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01492....
KarelZak jumped[15] straight to the original question and answered that
testing participation was low "[...] because this work is not
attractive. It's boring work without proper credit in open source
community. It's very simple to found list of top-ten kernel developers,
but who knows the most active bug reporters or QA around kernel? Nobody.
People who are testing a software are real contributors. Our THANKS to
them should be more visible!"
[15]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01696....
=== Source File Audit Catches RPM Problems Early ===
Kevin Fenzi posted[1] the results from the latest run of his
sources/patches URL checker script. There were 912 possible problems
reported, which Kevin noted was "Up from 662 last run. This is a pretty
sad increase."
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01433....
Happily many of the reported problems appeared[2] to be due to either
temporary problems with GoogleCode and SourceForge project hosting or to
some minor oddities in the script. Many of the other highlighted
problems were confirmed as genuine and fixed by the package owners.
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01450....
Ian Weller contrasted[3] a successful run of spectool -g[4], which uses
wget internally, with the failure of Kevin's script. Later Kevin also
found[5] a similar result when examining another failure. He speculated
"[...] it's working fine with a wget... perhaps they are blocking the
agent that spectool -g uses? (which I am not sure what it reports)."
Ville Skyttä offered[6] that "spectool -g uses plain wget, with
configuration file /etc/fedora/wgetrc if it exists, otherwise usual
system wget configs" and Thomas Moschny discovered[7] that "spectool
uses -N, which seems to cause 404 errors with googlecode[.]" Jaroslav
Reznik confirmed[8] this: "Same for me - it's not working for googlecode
downloads. Wget with -N param sends HEAD instead GET - these two are
same, but HEADs response are only headers - it's used for links
validation etc... But looks is it misconfiguration on server side?" and
thanked Kevin for the usefulness of his script which had caught a
serious problem.
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01434....
[4] The spectool utility is part of rpmdevtools. It downloads and
extracts sources and patches to build RPMs
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01451....
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01454....
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01459....
Eric Sandeen asked[9] if it would be a good idea to extend rpmlint to
perform these checks: "I'm most likely to fix this stuff if I'm in the
middle of making some other change, and an automatic check while I'm
working on a package that says `hey your source URL is no longer valid'
would probably provoke me to fix it quickly. :)"
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01466....
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01641....
=== One Issue Tracker to Rule Them All ===
Arthur Pemberton examined[1] the challenge issued by Callum Lerwick to
improve Bugzilla (see this same FWN#153 "More and Wider Testing".) He
asked for a list features which distinguished Bugzilla from competitors.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01430....
The ability of Bugzilla to deal with a massive number of "products,
components, users, hits per second [with] clustering databases and
similar magic" was advanced[2] by Matej Cepl as the most compelling
reason. Nicholas Mailhot added[3] "feature completeness, familiar UI,
integrating with upstream issue trackers (which are often bugzilla too)"
and Emmanuel Seyman suggested[4]: "And as an encore : it has to contain
109900+ bugs of existing data so that we don't lose any history."
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01470....
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01477....
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01483....
A certain amount of impatience with the general idea was expressed[5] by
Matej Cepl when he agreed with Andrew Cagney that one essential feature
would be a "push upstream" button: "AMEN!!! And I think we should
concentrate on this rather than doing stupid bugzilla rewrites. Sorry,
for being harsh, but it is so IMNSHO." Emmanuel Seyman warned[6] that it
would be necessary to map users, bugs and components across any separate
upstream/downstream instances of bugzilla. He later expanded[7] upon
this: "Bugzilla has gained the abilty to customize statuses and
resolutions, making it even harder to push bugs from one bugzilla to
another with prompting for user interaction." LaunchPad[8] was
discussed[9] as possibly providing this feature. Casey Dahlin noted[10]
that cross-site integration was still not implemented "[...] because
there should never ever ever be two independent sets of launchpad data
ever, according to their philosophy [.]"
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01611....
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01615....
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01622....
[8] Canonical's collaborative hosting service https://launchpad.net/
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01616....
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01539....
Till Maas suggested[11] several interesting improvements including
"[...] the possibility of having several people beeing responsible for a
Component, which is currently only partly possible. There is the initial
CC list, but when a bug is reassigned to a different component, the
members of the initial CC list of the old component are not removed from
the list." Other desiderata included storing the NEVR of a package in a
dedicated field and support for the same bug across several different
releases.
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01612....
The issue of how bugs can actually be fixed cropped up again in the
discussion. Brennan Ashton suggested[12] that triaging bugs was an area
in need of volunteers and provided a link[13] to the BugZappers wiki
page.
[12]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01704....
[13] https://fedoraproject.org/wiki/BugZappers
=== RFC: Fix Summary Text for Lots of Packages ===
Richard Hughes wished[1] that the Packaging Guidelines on summaries and
descriptions would be followed a little more closely as "[q]uite a lot
of packages have summary text that is overly verbose, and this makes the
GUI and output from pkcon look rubbish."
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01484....
Josh Boyer warned[2] against making reviewers' jobs harder by codifying
too much in the package guidelines and suggested: "Just file bugs for
packages you think are overly verbose. Offer alternate summaries in the
bug, and a URL to your email for rationale." Bill Nottingham was[3]
dubious that "[...] this scales across 5000 packages. So it would be
good to have at least *something* in the guidelines." When Richard
compromised on a "soft guideline such as: Summary should aim to be less
than 8 words" David Woodhouse gently poked[4] fun at this summary as
being too wordy.
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01487....
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01489....
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01493....
Toshio Kuratomi expressed[5] disapproval of soft guidelines due to their
potential for sparking many individual disagreements instead of one
single point of contention being handled by the Packaging Committee.
Richard seemed happy enough with Toshio's suggestion[6] that the
packaging guidelines contain a "best practice" description with
examples.
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01495....
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01499....
When Bill Nottingham raised[7] the possibility of "summary collisions"
Jef Spaleta threw out[8] an analogy based on searching for medicine in a
grocery store in a foreign country. This was intended to stimulate
clarification of the function of summaries. Toshio Kuratomi loved[9] it
and suggested that summaries were like the "[...] little advertising
gimicks seen on and alongside the other things on the bottle. Things
like: "New!", "Larger size", [Picture of grapes and smiling child],
etc.
They're differentiators that "help" you choose one product over
another." He provided some concrete examples which seemed to prove his
case.
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01520....
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01536....
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01569....
Michal Hlavinka worried[10] that yum search <keyword> would be disrupted
but Michael Schwendt re-assured[11] him that "'yum search' also searches
the package %description. And the description is the place where to be
much more verbose than in the summary. The %summary is not made for
searching, but for enabling the installer and packaging tools to to
display a brief and concise package description or a list thereof. That
means, put a few relevant keywords in the summary (newspaper
headline-style at most), but avoid long/complete sentences as often as
possible. That also makes it easier to fit into one line."
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01500....
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01510....
Later Richard asked[12] for opinions on a sample email which he intended
to send out to some maintainers to alert them to their long package
summaries.
[12]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01640....
Andrea Musuruane, as an RPM Fusion packager, felt[13] that packagers'
time would be wasted in following the proposal and that a "Summary is
something that the packager should choose on his own. It must be less
than 80 characters and _maybe_ it should not contain the package name.
Everything else is just marketing. If someone thinks that adding the
fact that the application is based on Gnome, it is fine for me. If
someone else thinks that mentioning that other application uses DBUS it
is fine for me too." Richard clarified[14]: "I'm _not_ saying "change
your summary or we'll drop your package" I'm asking them to come into
line with 90% of the other packages in the distro. I'm even offering to
do the cvs commit myself, if they give me the new summary line."
[13]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01654....
[14]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01656....
The issue of these changes being made solely to accommodate PackageKit
was addressed[15] by James Antill: "The fact that a single tool decided
that summaries should be used instead of names, and so summaries should
be roughly the same size of names shouldn't make Fedora packages break
their summaries for other tools ... all IMO." When Emmanuel Seyman
asked[16] exactly how GUI packaging tools made the summary more
prominent than the package name Richard Hughes responded[17] that it was
actually one, but one that was exposed in many places. Emmanuel's
response was blunt: "FWIW, I don't appreciate our maintainers being lied
to. The vast majority of them work hard to make their packages and I
believe that a minimum of respect should be shown [...] it is a case of
changing one application versus changing 500." Ville Skyttä took[18] an
overview which left the current user-interface of gnome-PackageKit aside
and concentrated on whether there was agreement that rpmlint should be
taught to check that the package name should not be repeated in the
summary.
[15]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01683....
[16]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01672....
[17]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01713....
[18]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01673....
Further criticism was made[19] by Christopher Wickert of sorting
packages by description instead of name in PackageKit and Tom Lane
raised[20] the problem of sub-packages needing to reference the name of
their parent package. At this stage it seemed that some consensus had
been reached on the idea that summaries which repeated the program name
were frowned upon and that "verb phrases" should be also be deprecated
as suggested[21] by Ignacio Vazquez-Abrams.
[19]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01721....
[20]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01733....
[21]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01532....
A brief dispute between Andreas Musuruane and Michael Schwendt yielded a
closing statement which seemed[22] to make the case of those that favor
the changes in a strong manner. Michael accepted that: "[i]t isn't
trivial to come up with good one-line summaries that do more than
repeating the program name. It's nothing packagers like to spend time
on. Reducing a packager's freedom even further won't be a good thing
[...] I think with some people one could argue endlessly about pkg
summaries. And during pkg reviews that's wasted time. Still, with very
old repositories it has been noticed [and agreed on, mostly] that some
types of summaries simply look poor in Anaconda and package management
tools. That was the rationale for some of the recommendations."
RichardHughes noted[23] that over the last forty-eight hours many
maintainers had changed their package summaries as requested.
[22]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01753....
[23]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01764....
=== Smock: Simpler Mock for Chain Building ===
A couple of announcements were made by Richard Jones. The first was of a
new version of OCaml. The second was[1] of a wrapper script that "[...]
runs on top of mock, allowing you to chain-build a series of RPMs from a
single command." An example which would "[...] arrange the SRPMs into
the correct order according to their BuildRequires, then build each in
the four separate mock environments Fedora {9,10} {i386,x86_64}" was
provided:
smock.pl --arch=i386 --arch=x86_64 \
--distro=fedora-9 --distro=fedora-10 \
*.src.rpm
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01229....
Till Maas suggested[2] that local file access URIs[3], such as file:///,
could be used to avoid the need for a webserver and Paul Howarth
confirmed[4] that he had been using mock "[...] like this for *years*
with loopback-mounted ISO images for a low-cost source for the base
repo. It definitely works."
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01232....
[3] See RFC1738 section 3.10 http://tools.ietf.org/html/rfc1738
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01264....
Seth Vidal asked[5] why the wrapper approach had been taken instead of
integrating the functionality into mock and Richard agreed[6] that this
should happen. An initial problem with build requires of the form
"%{name}-devel" failing was quickly fixed[7].
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01238....
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01239....
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01354....
== Translation ==
This section covers the news surrounding the Fedora Translation (L10n)
Project.
http://fedoraproject.org/wiki/L10N
Contributing Writer: Runa Bhattacharjee
=== FLSCo Elections ===
The mid-term elections for FLSCo are slated to happen sometime during
the end of December 2008. Members will be elected to replace three
serving members completing their 6 months term. Paul Frields and
Dimitris Glezos called[1] on FLP members to nominate themselves or
suitable members[2] to be part of the Steering Committee.
Paul Frields also commended[8] the improved coordination between the
Documentation and Translation teams during this release and applauded
the efforts made by FLSCo and other members of FLP that has helped bring
about this change.
[1]
https://www.redhat.com/archives/fedora-trans-list/2008-November/msg00139....
[2] http://fedoraproject.org/wiki/L10N/SteeringCommittee/Nominations
Fedora-website Translation Repository
The last week of the Fedora Translation cycle saw translation activity
for the Fedora Websites[3]. A minor hiccup was averted when Ricky Zhou
alerted[4] the translators about the change in the submission repository
for the fedoraproject.org website translations.
[3]
https://www.redhat.com/archives/fedora-trans-list/2008-November/msg00058....
[4]
https://www.redhat.com/archives/fedora-trans-list/2008-November/msg00126....
=== Fedora 10 Release Notes Branched ===
The "f10" branch was created for the Fedora 10 Release Notes and added
into translate.fedoraproject.org by DimitrisGlezos[5].
[5]
https://www.redhat.com/archives/fedora-trans-list/2008-November/msg00122....
=== Release Announcements in Local Languages ===
Karsten Wade announced[6] that for Fedora 10, the translation/local
country teams have the option of writing their own release announcements
instead of translating the English version.
[6]
https://www.redhat.com/archives/fedora-trans-list/2008-November/msg00140....
=== Zero-Day Version of the Fedora 10 Release Notes ===
All bugs related to Fedora 10 Release Notes have been closed by
PaulFrields[7] and the Zero-Day version of the .pot file is now
available[8]. A final RPM version with the updates would be packaged on
Monday.
[7]
https://www.redhat.com/archives/fedora-trans-list/2008-November/msg00146....
[8]
https://www.redhat.com/archives/fedora-trans-list/2008-November/msg00152....
=== Sponsorship to cvsl10n Group ===
The discussion related to sponsoring new members to the cvsl10n group
continued this week. DimitrisGlezos suggested[9] elevating the status of
all language coordinators to "sponsor".
[9]
https://www.redhat.com/archives/fedora-trans-list/2008-November/msg00142....
== Artwork ==
In this section, we cover the Fedora Artwork Project.
http://fedoraproject.org/wiki/Artwork
Contributing Writer: Nicu Buculei
=== Echo Perspective ===
Martin Sourada, the maintainer of the Echo icon theme, announced[1] on
@fedora-art a variant of this theme, called Echo Perspective "I think
because we are starting new icon set from the start we can afford more
radical changes than before to Echo. Most of them are visible in the
icon I've created. But we need more, namely redesign of the directory
and trash icons. It would be great if as many people as possible
submitted their ideas for these, either here on a wiki I've created for
this purpose [2]"
[1]
https://www.redhat.com/archives/fedora-art-list/2008-November/msg00053.html
[2] https://fedoraproject.org/wiki/Artwork/EchoIconTheme/Perspective
Some days later, Martin continued the experiment[3] by trying a new
representation of the folder icon, one of the most seen icons on the
desktop "I've just finished first take of the folder design for Echo
Perspective. I do not hide that the design has been inspired by Mac OS X
Leopard folder as well as current Echo folder. I've more or less
retained the original colour, but adjusted it to better fit with our
colour palette."
[3]
https://www.redhat.com/archives/fedora-art-list/2008-November/msg00089.html
=== CD Faces ===
Paul Frields relayed[1] to @fedora-art a request from @fedora-marketing
for CD faces (labels and sleeves) and Máirín Duffy stepped up[2] and
published on the wiki[3] a set of labels and the final version of the
sleeves created earlier by team member Jarod Wen.
[1]
https://www.redhat.com/archives/fedora-art-list/2008-November/msg00073.html
[2]
https://www.redhat.com/archives/fedora-art-list/2008-November/msg00084.html
[3] http://fedoraproject.org/wiki/Artwork/MediaArt/F10
Since Máirín's design is optimised for "professionally-done screen
printed version of the discs" two other designers, Jayme Ayres[4] and
Susmit Shannigrahi[5], proposed alternative, much richer versions of the
labels (suitable for large scale printing.)
[4]
https://www.redhat.com/archives/fedora-art-list/2008-November/msg00078.html
[5]
https://www.redhat.com/archives/fedora-art-list/2008-November/msg00087.html
=== Fonts Survey ===
Nicolas Mailhot wrote[1] to @fedora-fonts about a survey[2] "[...]
asking our users to participate in the online font surveys out there on
Fedora 10 release". He felt this was important as "this way we may limit
the number of web sites that only work with Arial or Times New Roman,
and make more web designers aware of the fonts actually available on
free systems."
[1]
https://www.redhat.com/archives/fedora-fonts-list/2008-November/msg00039....
[2]
http://fedoraproject.org/wiki/Linux_fonts_on_the_web__CSS_and_font_surveys
== 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 ===
* grip-3.2.0-24.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg...
* htop-0.8.1-2.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg...
* geda-gnetlist-20080929-2.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg...
* roundup-1.4.6-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg...
* cobbler-1.2.9-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg...
* libxml2-2.7.2-2.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg...
* thunderbird-2.0.0.18-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg...
=== Fedora 8 Security Advisories ===
* geda-gnetlist-20080929-2.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg...
* roundup-1.4.6-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg...
* libxml2-2.7.2-2.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg...
* cobbler-1.2.9-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg...
* grip-3.2.0-24.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg...
* htop-0.8.1-2.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg...
* thunderbird-2.0.0.18-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg...
== 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
=== Fedora 10 Virtualization ===
This section contains a description of the virtualization features in
the brand new Fedora 10 release.
==== New Features ====
Fedora 10 includes a number of virtualization enhancements over previous
releases including new software packages and major new features.
* Unified Kernel Image
The kernel-xen package has been obsoleted by the integration of
paravirtualization operations in the upstream kernel.
* Virtualization Storage Management
Advances in libvirt now provide the ability to list, create, and
delete storage volumes on remote hosts.
* Remote Installation of Virtual Machines
Improvements in Virtualization Storage Management have enabled the
creation of guests on remote host systems.
For complete details, see the release notes[1] and then jump into the
quick start guide[2].
[1] http://fedoraproject.org/wiki/Docs/Beats#Virtualization
[2] http://fedoraproject.org/wiki/Virtualization_Quick_Start
==== Updates to Virtualization Software ====
Virtualization with Fedora is achieved through the hard work of many
projects including kvm, libvirt, virt-manager, xen, and others.
Below is a listing of some of the virtualization software found in
Fedora, illustrating the updates since the release of Fedora 9.
+----------------+--------------+-------------+----------------------+
| Software | F9 Release | F10 Release | ReleaseNotes/Changes |
+----------------+--------------+-------------+----------------------+
| kvm | 65-1 | 74-5 | [1] |
| libvirt | 0.4.2-1 | 0.4.6-3 | [2] |
| python-virtinst| 0.300.3-5 | 0.400.0-4 | [3] |
| virt-df | n/a | 2.1.4-2 | [4] |
| virt-manager | 0.5.4-3 | 0.6.0-3 | [5] |
| virt-mem | n/a | 0.2.9-6 | [6] |
| virt-top | 0.4.1.1-1 | 1.0.3-2 | [7] |
| virt-viewer | 0.0.3-1 | 0.0.3-3 | [8] |
| xen | 3.2.0-10 | 3.3.0-1 | [9] |
| xenner | 0.29-2 | 0.46-3 | [10] |
| xenwatch | n/a | 0.5.3-1 | [11] |
+----------------+--------------+-------------+----------------------+
[1] http://kvm.qumranet.com/kvmwiki/ChangeLog
[2] http://www.libvirt.org/news.html
[3] http://virt-manager.et.redhat.com/download.html
[4] http://et.redhat.com/~rjones/virt-df/
[5] http://virt-manager.et.redhat.com/download.html
[6] http://et.redhat.com/~rjones/virt-mem/faq.html
[7] http://et.redhat.com/~rjones/virt-top/ChangeLog.txt
[8] http://virt-manager.et.redhat.com/download.html
[9] http://www.xen.org/download/
[10] http://cvs.bytesex.org/xenner.html
[11] http://cvs.bytesex.org/xenwatch.html
=== Enterprise Management Tools List ===
This section contains the discussion happening on the et-mgmt-tools list
==== Connecting to VNC Console on Remote System Installs ====
While executing virt-install on a remote system, Stephan found[1] that
the installer created a VNC service listening on 127.0.0.1, and wanted
to know how to connect to this service or move it to a public interface
on the remote system.
Daniel P. Berrange answered[2] that modifying the vnc_listen parameter
in /etc/libvirt/qemu.conf will affect the IP used, but this isn't
necessary. The virt-viewer application will automatically tunnel[3][4]
VNC connection over SSH.
virt-viewer --connect qemu+ssh://root@remotehost/system centos1
[1]
http://www.redhat.com/archives/et-mgmt-tools/2008-November/msg00041.html
[2]
http://www.redhat.com/archives/et-mgmt-tools/2008-November/msg00042.html
[3] http://virt-manager.org/page/RemoteSSH
[4] http://libvirt.org/remote.html
==== Specifying Installation Media URLs ====
Enzo Medici became[1] frustrated while trying to provision Xen domUs
with virt-manager. "What constitutes a valid install media URL?" "How do
you get a valid install media URL for a particular Linux distribution?"
Cole Robinson explained[2] "We actually don't have support in the
backend for fetching kernels from Ubuntu trees" yet. "This may work at
the moment though since it could be detected as a debian tree." Cole
then described the installation URLs for some popular distributions.
* For Fedora, it has varied a bit for different releases, but
basically whatever ends in {ARCH}/os:
http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Fedora/x86_...
* CentOS is similar, but seems to have ARCH and os reversed:
http://mirrors.cmich.edu/centos/5/os/x86_64/
* Debian/Ubuntu trees are everything up to the install-{ARCH} dir:
http://us.archive.ubuntu.com/ubuntu/dists/etch/main/installer-i386
[1]
http://www.redhat.com/archives/et-mgmt-tools/2008-November/msg00044.html
[2]
http://www.redhat.com/archives/et-mgmt-tools/2008-November/msg00046.html
Fedora Xen List
This section contains the discussion happening on the fedora-xen list.
=== Xen No Graphical Console and CentOS ===
While creating a domU on CentOS 5.2, Jason passed --nographics to
virt-install and received the error message: No console available for
domain. Investigation /var/log/xen uncovered: Could not initialize SDL -
exiting.
Cole Robinson responded[2] that "This is actually a known bug: xen
doesn't abide nographics and tries to init SDL. This will almost always
fail if run through [CentOS] 5.2 libvirt. This bug will be fixed in
[CentOS] 5.3." The --vnc flag may be used as a workaround this crash in
the meantime.
[1]
http://www.redhat.com/archives/fedora-xen/2008-November/msg00015.html
[2]
http://www.redhat.com/archives/fedora-xen/2008-November/msg00016.html
=== Libvirt List ===
This section contains the discussion happening on the libvir-list.
==== User Mode Linux Support ====
Daniel P. Berrange improved[1] the user mode linux driver[2] (See
FWN#148[3]), by improving stability and adding documentation. Network
support is not yet available, but the driver is planned for release with
libvirt 0.5.0.
[1]
http://www.redhat.com/archives/libvir-list/2008-November/msg00239.html
[2] http://libvirt.org/drvuml.html
[3]
http://fedoraproject.org/wiki/FWN/Issue148#Experimental_User_Mode_Linux_D...
==== Increased Network Throughput with Large MTU ====
Chris Wright created[1] a proof of concept patch "for setting a large
MTU size on a tap[2] device. With this we are able to improve net i/o
throughput substantially (~40% improvement on TX and ~130% improvement
on RX). This is just RFC because it's hardcoded to an MTU of 9000 for
any tap device."
[1]
http://www.redhat.com/archives/libvir-list/2008-November/msg00225.html
[2] http://www.mjmwired.net/kernel/Documentation/networking/tuntap.txt
==== Integration with SolidICE ====
With a goal of integrating libvirt and SolidICE[1], Shahar Frank
posted[2] "an initial version of the operations required for SolidICE
and the proposed high level interface." All of the listed operations
were storage related.
Daniel P. Berrange provided[3] a very detailed and informative response
explaining how to to apply the libvirt API to these operations.
SolidICE is a product of Qumranet, now Red Hat[4]. SolidICE runs virtual
KVM desktops in the datacenter for display by thin clients.
[1] http://www.qumranet.com/products-and-solutions
[2]
http://www.redhat.com/archives/libvir-list/2008-November/msg00256.html
[3]
http://www.redhat.com/archives/libvir-list/2008-November/msg00262.html
[4] http://fedoraproject.org/wiki/FWN/Issue143#Other_Virtualization_News
--
Oisin Feeley
http://fedoraproject.org/wiki/OisinFeeley