From Fedora Project Wiki

< FWN
Revision as of 16:31, 24 November 2008 by Ush (talk | contribs) (→‎Smock: Simpler Smock for Chain Building: title correction s/Smock/Mock)

Fedora Weekly News Issue 153

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

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.html

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.html

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

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

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

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.html

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.html

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.html

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

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

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

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.html

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

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.html

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.html

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.html

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.html

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.html

[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.html

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

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

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.html

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

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.html

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.html

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

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

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.html

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

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

[8] Canonical's collaborative hosting service https://launchpad.net/

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

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

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.html

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.html

[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.html

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.html

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

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

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.html

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

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.html

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

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

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.html

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

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.html

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.html

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

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.html

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

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

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

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.html

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

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

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.html

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

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.html

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.html

[3] See RFC1738 section 3.10 http://tools.ietf.org/html/rfc1738

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

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.html

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

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

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.html

[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.html

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

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.html

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.html

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.html

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

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.html

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.html

[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

Fedora 8 Security Advisories

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.

Virtualization Software Versions
Software F9 Release F10 Release Release Notes or Changes
kvm 65-1 74-5 http://kvm.qumranet.com/kvmwiki/ChangeLog
libvirt 0.4.2-1 0.4.6-3 http://www.libvirt.org/news.html
python-virtinst 0.300.3-5 0.400.0-4 http://virt-manager.et.redhat.com/download.html
virt-df n/a 2.1.4-2 http://et.redhat.com/~rjones/virt-df/
virt-manager 0.5.4-3 0.6.0-3 http://virt-manager.et.redhat.com/download.html
virt-mem n/a 0.2.9-6 http://et.redhat.com/~rjones/virt-mem/faq.html
virt-top 0.4.1.1-1 1.0.3-2 http://et.redhat.com/~rjones/virt-top/ChangeLog.txt
virt-viewer 0.0.3-1 0.0.3-3 http://virt-manager.et.redhat.com/download.html
xen 3.2.0-10 3.3.0-1 http://www.xen.org/download/
xenner 0.29-2 0.46-3 http://cvs.bytesex.org/xenner.html
xenwatch n/a 0.5.3-1 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_64/os/
  • 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_Driver

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

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Issue153&oldid=61369"