From Fedora Project Wiki

< FWN

m (added category)
 
(47 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= Fedora Weekly News Issue 161 =
Welcome to Fedora Weekly News Issue 161 for the week ending February 1, 2009.
http://fedoraproject.org/wiki/FWN/Issue161
This week's FWN goodness offers a very special update from the Fonts SIG to bring us up to date on their work leading up to Fedora 11.  You may also notice that we are tweaking the wiki formatting to take advantage of the cite module and other features in MediaWiki, and employing User: references for links to named Fedora folk.  We'd love to hear your feedback on these changes.
Also in this week's intrepid issue details on the upcoming Fedora monthly public meeting, updates on upcoming events with a Fedora presence, and news updates from around the Fedora Planet.  In Developments, details on a slight delay to F11 Alpha and Electronic Automation Tools updates.  Translation news brings updates from the latest FLP meeting and website translation updates, along with more Fedora 11 plans.  A couple brief updates from the Infrastructure Team, including discussion of possible automation of fedora hosted requests.  The Artwork beat paints a lovely picture with details on Fedora 11 visual details, and we're brought up to date with the latest security advisories for Fedora 9 and 10.  The issue completes with updates from the various virtualization projects, including details on a new libvirt and virt-manager, as well as meaty updates on the Fedora Xen list.  Enjoy, everyone!
We are currently looking for a new writer to cover the Fedora Ambassadors for FWN.  The work chiefly involves summarizing each's week's traffic on the Fedora Ambassadors' list, and is likely a time committment of perhaps one hour per week.
If you are interested in contributing to Fedora Weekly News, please see our 'join' page<ref>http://fedoraproject.org/wiki/NewsProject/Join</ref>. We welcome reader feedback: fedora-news-list@redhat.com
FWN Editorial Team: [[User:Pcalarco|Pascal Calarco]], [[User:Ush|Oisin Feeley]], [[HuzaifaSidhpurwala|Huzaifa Sidhpurwala]]


{{Anchor|Announcements}}
{{Anchor|Announcements}}
Line 13: Line 27:
=== Fedora Board Meeting ===
=== Fedora Board Meeting ===


[[PaulWFrields|Paul Frields]] wrote<ref>http://www.redhat.com/archives/fedora-announce-list/2009-January/msg00018.html
[[User:Pfrields|Paul Frields]] wrote<ref>http://www.redhat.com/archives/fedora-announce-list/2009-January/msg00018.html
</ref> that "the Board is holding its monthly public meeting on Tuesday, 3 February 2009, at 1900 UTC on IRC Freenode."
</ref> that "the Board is holding its monthly public meeting on Tuesday, 3 February 2009, at 1900 UTC on IRC Freenode."


Line 24: Line 38:
=== Legal ===
=== Legal ===


[[TomCallaway|Tom Callaway]] announced
[[User:Spot|Tom Callaway]] announced
<ref>http://www.redhat.com/archives/fedora-devel-announce/2009-January/msg00012.html</ref> that "after talking with Red Hat Legal about how we should be handling trademarks in package summaries and descriptions, we came to the conclusion that it would be far easier (and less risky for Red Hat) if we did not use "(TM)" or "(R)" notations at all."
<ref>http://www.redhat.com/archives/fedora-devel-announce/2009-January/msg00012.html</ref> that "after talking with Red Hat Legal about how we should be handling trademarks in package summaries and descriptions, we came to the conclusion that it would be far easier (and less risky for Red Hat) if we did not use "(TM)" or "(R)" notations at all."


Line 50: Line 64:


<references/>
<references/>
{{Anchor|Fonts}}
Contributing Writer: [[NicolasMailhot|Nicolas Mailhot]]
== Special Report: Fonts SIG ==
Since Fedora 11 Alpha is quickly approaching, here is a much-delayed edition of the fonts SIG irregular status report.  You may recall FWN covered the font surveys in FWN #153<ref>https://fedoraproject.org/wiki/FWN/Issue153#Fonts_Survey</ref>.  The following special report is largely in addition to that previous report.
I should probably have done one for Fedora 10 release, but (silly me) expected then that the new font packaging guidelines would be adopted quickly. After all, they only reworded existing rules and added material already presented and discussed on the fonts and devel lists.
Of course various instances decided to celebrate F10 by taking a break, then there was some bike-shedding, then we had the Christmas vacations, then FUDCON and more bike-shedding. Live and learn. At least after being hammered to death the result is clear and clean.
Anyway, to the report.
<references/>
=== New fonts packaging guidelines ===
After much anguish and unexpected developments FPC and FESCO approved the complete set of fonts packaging changes that we had submitted.<ref>https://www.redhat.com/archives/fedora-devel-announce/2009-January/msg00007.html</ref>
The end result is:
1) a completed and clarified policy page<ref>http://fedoraproject.org/wiki/Packaging:FontsPolicy</ref>
2) two new packaging templates<ref>http://fedoraproject.org/wiki/Simple_fonts_spec_template</ref> <ref>http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts</ref>
3) a helper package with rpm macros, documentation, plus fontconfig
and spec templates<ref>http://fedoraproject.org/wiki/Fedora_fonts_policy_package</ref>
<references/>
=== Distribution-wide font auditing and repackaging ===
Some innocent repoqueries revealed a distressing number of source packages (>130) that made us ship fonts while completely ignoring our previous fonts packaging guidelines and existing licensing rules. So applying new font guidelines twists quickly turned into distribution-wide operation.
1) Its advancement is now tracked<ref>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=477044</ref>
2) A (long) FAQ was published to help packagers with no fonts
experience<ref>http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_(FAQ)</ref>
3) To make sure documentation, QA and other groups are aware and help
implement the changes they've been proposed as a Fedora 11 feature<ref>http://fedoraproject.org/wiki/Features/Repackaging_of_Fedora_fonts</ref>
<references/>
=== Wishlist status ===
Our wishlist stood at 56 entries for last report. It has now reached 76 entries <ref>
http://fedoraproject.org/wiki/Category:Font_wishlist</ref>. The current fonts packagers are clearly unable to
cope with Fedora demands, fresh blood is needed before it moves into 100+ numbers.
At the same time the respected lwn.net is running a front page article<ref>http://lwn.net/Articles/315872/</ref> listing more indispensable free or open fonts, some of them being neither in Fedora nor in our wishlist yet.
Volunteers to package those or at least add them to our wishlist are welcome. The free and open font landscape is really moving now, and the quality and breadth of its font offerings is now a distribution differentiator.
<references/>
=== Review status ===
At this time there are no un-reviewed font packages in Fedora bugzilla. However, several reviews have been open for quite a long time with their requesters not acting on review comments.
Please do respond to review comments. Reviewing packages is tedious ungrateful work and getting no response after one is demotivating.
=== New packages ===
Ignoring renamings ctan-musixtex-fonts, dustin-dustismo-roman-fonts,dustin-dustismo-sans-fonts, hanazono-fonts, google-droid-sans-fonts, google-droid-sans-mono-font, google-droid-serif-fonts, serafettin-cartoon-fonts, and unikurd-web-font are now available in the repository.
The most user-visible of those are probably the Droid fonts, but Dustimo had been waited for a long time.
Several other fonts previously hidden deep inside apps have now been exposed as part of the ongoing F11 auditing and repackaging. The complete set of changes is documented as usual<ref>http://fedoraproject.org/wiki/Fonts_inclusion_history</ref>
Several new packagers worked on those and on other packages not pushed yet and I want to thank them publicly for their contribution to a better Fedora.
<references/>
=== Web font surveys ===
Fedora 10 shipped with an openjdk plugin that should be complete enough to run web font surveys. There is no reason left for Fedora users not to participate in them, and help web designers select fonts that work well with Fedora browsers. Please take the time to contribute to these<ref>
http://fedoraproject.org/wiki/Linux_fonts_on_the_web:_CSS_and_font_surveys</ref>
<references/>
=== Better fonts whiteboard ===
The desktop team has added a whiteboard page<ref>http://fedoraproject.org/wiki/Desktop/Whiteboards/BetterFonts</ref> to the wiki to help identify the software changes needed to improve Fedora fonts and text handling.
Please contribute comments and complements to this page to help make Fedora better.
<references/>
=== Font autoinstallation ===
Rumors on IRC are that the feature is advancing fast. Hopefully we'll have finished cleaning up our font packages before they need to be rebuild to add auto-install metadata<ref>
http://fedoraproject.org/wiki/Features/AutomaticFontInstallation</ref>. Automating this operation requires clean packages free of historic cruft.
<references/>
And that's all for this issue, thank you for reading it to its end.


{{Anchor|PlanetFedora}}
{{Anchor|PlanetFedora}}
== Planet Fedora ==
== Planet Fedora ==


Line 99: Line 214:


{{Anchor|Developments}}
{{Anchor|Developments}}
== Developments ==
== Developments ==


Line 104: Line 220:
mailing list are summarized.
mailing list are summarized.


Contributing Writer: [[OisinFeeley|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== Fedora 11 Alpha May Be Delayed ===
=== Fedora 11 Alpha May Be Delayed ===
Line 116: Line 232:
[[JakubJelinek|Jakub Jelinek]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01661.html</ref> whether the minimum CPU which would run code compiled by Fedora 11's <code>GCC</code> should be re-evaluated. A follow-on question was whether the minimum supported kernel version in <code>glibc</code> could be bumped to <code>2.6.29</code>. Jakub held out the promise of potentially increased speed and decreased shared library sizes.
[[JakubJelinek|Jakub Jelinek]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01661.html</ref> whether the minimum CPU which would run code compiled by Fedora 11's <code>GCC</code> should be re-evaluated. A follow-on question was whether the minimum supported kernel version in <code>glibc</code> could be bumped to <code>2.6.29</code>. Jakub held out the promise of potentially increased speed and decreased shared library sizes.


A problem raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01668.html</ref> by [[KevinKofler|Kevin Kofler]] was that <code>mock</code> builds would no longer be able to run on older <code>Fedora</code> releases and that some VPSs would not be able to upgrade at all. [[GerdHoffman|Gerd Hoffman]] agreed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01813.html</ref>: "We just can't make the huge jump from .9 to .29. We have to do it smaller steps, considering kernel versions at least in supported Fedora versions, maybe also latest RHEL."
A problem raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01668.html</ref> by [[User:Kkofler|Kevin Kofler]] was that <code>mock</code> builds would no longer be able to run on older <code>Fedora</code> releases and that some VPSs would not be able to upgrade at all. [[GerdHoffman|Gerd Hoffman]] agreed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01813.html</ref>: "We just can't make the huge jump from .9 to .29. We have to do it smaller steps, considering kernel versions at least in supported Fedora versions, maybe also latest RHEL."


[[JoshBoyer|Josh Boyer]] seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01680.html</ref> to believe that the required mass rebuild with GCC-4.4 would be difficult but possible. [[MikeMcGrath|Mike McGrath]] outlined<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01696.html</ref> the amount of work which would be needed.
[[User:Jwboyer|Josh Boyer]] seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01680.html</ref> to believe that the required mass rebuild with GCC-4.4 would be difficult but possible. [[User:Mmcgrath|Mike McGrath]] outlined<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01696.html</ref> the amount of work which would be needed.


See this same FWN#161 "Dropping Support for i586 Architecture" for a related discussion.
See this same FWN#161 "Dropping Support for i586 Architecture" for a related discussion.
Line 126: Line 242:
=== RPM Packagers: Too Many Unowned Directories ===
=== RPM Packagers: Too Many Unowned Directories ===


[[MichaelSchwendt|Michael Schwendt]] raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02326.html</ref> the problem of unowned directories installed as a result of packagers unfamiliar with "how to include files vs. directories in RPM package %files lists."
[[User:Mschwendt|Michael Schwendt]] raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02326.html</ref> the problem of unowned directories installed as a result of packagers unfamiliar with "how to include files vs. directories in RPM package %files lists."


[[ColinWalters|Colin Walters]] remembered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02335.html</ref> discussions which had suggested that if <code>RPM</code> were able to reference count directories there could be a technological fix. Separately [[RichardJones|Richard W.M. Jones]] made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02400.html</ref> a similar argument. [[PanuMatilainen|Panu Matilainen]] seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02350.html</ref> willing to move this task to the top of his queue if it were sufficiently important.
[[ColinWalters|Colin Walters]] remembered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02335.html</ref> discussions which had suggested that if <code>RPM</code> were able to reference count directories there could be a technological fix. Separately [[RichardJones|Richard W.M. Jones]] made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02400.html</ref> a similar argument. [[PanuMatilainen|Panu Matilainen]] seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02350.html</ref> willing to move this task to the top of his queue if it were sufficiently important.
Line 134: Line 250:
=== Lack of Update Information ===
=== Lack of Update Information ===


A can of worms was opened<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01643.html</ref> by [[RahulSundaram|Rahul Sundaram]] when he noticed that the update information provided by package maintainers was often unhelpful. He cited generic messages of the form "Update foo to upstream x.y.z" as a common problem and wondered if guidelines could improve the situation.
A can of worms was opened<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01643.html</ref> by [[User:Sundaram|Rahul Sundaram]] when he noticed that the update information provided by package maintainers was often unhelpful. He cited generic messages of the form "Update foo to upstream x.y.z" as a common problem and wondered if guidelines could improve the situation.


Following some questions Rahul expanded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01648.html</ref> on the problem pointing out that package maintainers had the knowledge to tersely explain what upstream changes implied for ordinary users. He emphasized that he was concerned with the "description that is part of bodhi update and not the changelog which can be very brief."
Following some questions Rahul expanded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01648.html</ref> on the problem pointing out that package maintainers had the knowledge to tersely explain what upstream changes implied for ordinary users. He emphasized that he was concerned with the "description that is part of bodhi update and not the changelog which can be very brief."


[[ChrisWeyl|Chris Weyl]] put<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01742.html</ref> forward the counter-argument that package maintainers had a difficult enough life already.
[[User:Cweyl|Chris Weyl]] put<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01742.html</ref> forward the counter-argument that package maintainers had a difficult enough life already.


[[RichardJones|Richard W.M. Jones]] wondered<ref>htts://www.redhat.com/archives/fedora-devel-list/2009-January/msg01687.html</ref> if <code>rpm</code> could be altered to allow it to reference upstream changelogs which could be pulled out by other tools. [[PanuMatilainen|Panu Matilainen]] averred<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01703.html</ref> that while rpm was alterable Richard's proposed change would just dump the information into the rpm payload and it would thus not be available to users until after they had installed it. Further brainstorming seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01737.html</ref> to run into various practical dead ends.
[[RichardJones|Richard W.M. Jones]] wondered<ref>https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01687.html</ref> if <code>rpm</code> could be altered to allow it to reference upstream changelogs which could be pulled out by other tools. [[PanuMatilainen|Panu Matilainen]] averred<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01703.html</ref> that while rpm was alterable Richard's proposed change would just dump the information into the rpm payload and it would thus not be available to users until after they had installed it. Further brainstorming seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01737.html</ref> to run into various practical dead ends.


Subsequently Rahul published<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01842.html</ref> a draft guideline which fanned the flames back to life. ThorstenLeemhuis asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01845.html</ref> "Don't we have way [too] many guidelines and policies already? [...] Note that I don't disagree with the text that was proposed. My 2 cent: Put it as text into the wiki somewhere, write "best practices" on top of it (avoid the words "rules" and "guidelines") and add a link to the bodhi UI ("best practices for filling this box with information")." Rahul appeared to agree that this was the best course for the present and deferred to FESCo for the ultimate decision.
Subsequently Rahul published<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01842.html</ref> a draft guideline which fanned the flames back to life. [[User:Thl|Thorsten Leemhuis]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01845.html</ref> "Don't we have way [too] many guidelines and policies already? [...] Note that I don't disagree with the text that was proposed. My 2 cent: Put it as text into the wiki somewhere, write "best practices" on top of it (avoid the words "rules" and "guidelines") and add a link to the bodhi UI ("best practices for filling this box with information")." Rahul appeared to agree that this was the best course for the present and deferred to FESCo for the ultimate decision.


<references/>
<references/>
Line 150: Line 266:
[[ChitleshGoorah|Chitlesh Goorah]] redirected<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02364.html</ref> a debate on Electronic Design Automation (EDA)<ref>http://en.wikipedia.org/wiki/Electronic_design_automation</ref> tools from FESCo to @fedora-devel. Chitlesh is the prime mover behind the <code>Fedora Electronic Lab Spin</code><ref>http://chitlesh.fedorapeople.org/FEL/</ref>. He was concerned that FESCo had decided that packages in the OVM<ref>http://www.ovmworld.org/overview.php</ref> format were barred from Fedora on the grounds that there was no FLOSS tool which could use them although they were licensed acceptably.
[[ChitleshGoorah|Chitlesh Goorah]] redirected<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02364.html</ref> a debate on Electronic Design Automation (EDA)<ref>http://en.wikipedia.org/wiki/Electronic_design_automation</ref> tools from FESCo to @fedora-devel. Chitlesh is the prime mover behind the <code>Fedora Electronic Lab Spin</code><ref>http://chitlesh.fedorapeople.org/FEL/</ref>. He was concerned that FESCo had decided that packages in the OVM<ref>http://www.ovmworld.org/overview.php</ref> format were barred from Fedora on the grounds that there was no FLOSS tool which could use them although they were licensed acceptably.


[[JeffSpaleta|Jef Spaleta]] explained<ref>htts://www.redhat.com/archives/fedora-devel-list/2009-January/msg02369.html</ref> that there were subtle problems in the discussion as "[OVM] is code of some sort. The problem is we don't have a compiler or interpreter that can process the instructions. In the context of Fedora its code that can't be used." [[KevinKofler|Kevin Kofler]] supplied<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02377.html</ref> the appropriate guideline.
[[User:Jspaleta|Jef Spaleta]] explained<ref>htts://www.redhat.com/archives/fedora-devel-list/2009-January/msg02369.html</ref> that there were subtle problems in the discussion as "[OVM] is code of some sort. The problem is we don't have a compiler or interpreter that can process the instructions. In the context of Fedora its code that can't be used." [[KevinKofler|Kevin Kofler]] supplied<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02377.html</ref> the appropriate guideline.


[[KevinFenzi|Kevin Fenzi]] expressed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02470.html</ref> appreciation for Chitlesh's work on the Fedora Electronics Lab and asked if there was any use for OVM besides hooking it up with a non-Free simulator? [[ManuelWolfshant|Manuel Wolfshant]] argued<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02480.html</ref> that OVM was i[...] interesting for a subset of the people interested in EDA" and that it should be provided for them. [[HorstvonBrand|Horst von Brand]] disliked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02489.html</ref> the idea of mirrors carrying such a little-used package around and suggested that Manuel could just set up his own repository.
[[User:Kevin|Kevin Fenzi]] expressed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02470.html</ref> appreciation for Chitlesh's work on the Fedora Electronics Lab and asked if there was any use for OVM besides hooking it up with a non-Free simulator? [[ManuelWolfshant|Manuel Wolfshant]] argued<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02480.html</ref> that OVM "is interesting for a subset of the people interested in EDA" and that it should be provided for them. [[HorstvonBrand|Horst von Brand]] disliked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02489.html</ref> the idea of mirrors carrying such a little-used package around and suggested that Manuel could just set up his own repository.


<references/>
<references/>
Line 158: Line 274:
=== Dropping Support for i586 Architecture ? ===
=== Dropping Support for i586 Architecture ? ===


Following FESCo discussions<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02328.html</ref>[[BillNottingham|Bill Nottingham]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02345.html</ref> that the supported architecture list was going to change. Important changes include building binaries only for i686 and above. There are concerns that older thin clients based on i586 hardware and the AMD Geode-based XO laptops may then be unsupported or unstable. Bill characterized the discussions as a follow-up to the compiler flag discussions (see this same FWN#161"GCC: Default ISA Flags and Glibc") and summarized the main points as:
Following FESCo discussions<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02328.html</ref> [[User:Notting|Bill Nottingham]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02345.html</ref> that the supported architecture list was going to change. Important changes include building binaries only for i686 and above. There are concerns that older thin clients based on i586 hardware and the AMD Geode-based XO laptops may then be unsupported or unstable. Bill characterized the discussions as a follow-up to the compiler flag discussions (see this same FWN#161"GCC: Default ISA Flags and Glibc") and summarized the main points as:


<pre>
<pre>
Line 166: Line 282:
</pre>
</pre>


[[JeremyKatz|Jeremy Katz]] added<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02382.html</ref> anecdotal reassurance that the XO should probably be fine with the i686 kernel and glibc.
[[User:Katzj|Jeremy Katz]] added<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02382.html</ref> anecdotal reassurance that the XO should probably be fine with the i686 kernel and glibc.


[[RobertScheck|Robert Scheck]] wondered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02355.html</ref> what the definition of "where appropriate" was and what mechanism would be used to make this determination.
[[User:Robert|Robert Scheck]] wondered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02355.html</ref> what the definition of "where appropriate" was and what mechanism would be used to make this determination.


[[DominikMierzejewski|Dominik 'Rathann' Mierzejewski]] predicted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02378.html</ref> "[t]here's going to be some screaming from VIA C3 and AMD K6 users about this." His suggestion was true during an older similar discussion (see FWN#93<ref>http://fedoraproject.org/wiki/FWN/Issue93#No_More_586_Kernels</ref>) in 2007 which concerned plans to drop shipping an i586 kernel. Suggested attempts to compensate by making the i686 kernel bootable on i586 architectures were thwarted as rpm balked at installing a kernel which violated its architecture check. [[AlanCox|Alan Cox]] was one of the strongest objectors to the possibility of thus losing support for i586 as he had many thin clients using that architecture. Doubt was cast during that thread as to whether the smolt statistics were believable. However, Alan has recently become an Intel employee (following other ex-Red Hat luminaries [[DavidWoodhouse|David Woodhouse]] and [[ArjanvandeVen)|Arjan van de Ven]]) and did not contribute to the thread. The <code>smolt</code> statistics listed<ref>http://fedoraproject.org/wiki/Features/ArchitectureSupport#What_about_the_i586_users_3F</ref> on the feature page suggest that there are only 130 i586 users.
[[User:Rathann|Dominik 'Rathann' Mierzejewski]] predicted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02378.html</ref> "[t]here's going to be some screaming from VIA C3 and AMD K6 users about this." His suggestion was true during an older similar discussion (see FWN#93<ref>http://fedoraproject.org/wiki/FWN/Issue93#No_More_586_Kernels</ref>) in 2007 which concerned plans to drop shipping an i586 kernel. Suggested attempts to compensate by making the i686 kernel bootable on i586 architectures were thwarted as rpm balked at installing a kernel which violated its architecture check. [[AlanCox|Alan Cox]] was one of the strongest objectors to the possibility of thus losing support for i586 as he had many thin clients using that architecture. Doubt was cast during that thread as to whether the smolt statistics were believable. However, Alan has recently become an Intel employee (following other ex-Red Hat luminaries [[DavidWoodhouse|David Woodhouse]] and [[ArjanvandeVen)|Arjan van de Ven]]) and did not contribute to the thread. The <code>smolt</code> statistics listed<ref>http://fedoraproject.org/wiki/Features/ArchitectureSupport#What_about_the_i586_users_3F</ref> on the feature page suggest that there are only 130 i586 users.


[[JoshBoyer|Josh Boyer]] clarified<ref>htts://www.redhat.com/archives/fedora-devel-list/2009-January/msg02383.html</ref> that no decision had yet been made by FESCo and that a vote would take place next week.
[[User:Jwboyer|Josh Boyer]] clarified<ref>https://www.redhat.com/archives/fedora-devel-list/2009-January/msg02383.html</ref> that no decision had yet been made by FESCo and that a vote would take place next week.


<references/>
<references/>
Line 180: Line 296:
[[MatthewGarret|Matthew Garrett]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02265.html</ref> for comments on the idea that the cursor should default to not blinking. The rationale was that several less Watts of power would be consumed.   
[[MatthewGarret|Matthew Garrett]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02265.html</ref> for comments on the idea that the cursor should default to not blinking. The rationale was that several less Watts of power would be consumed.   


The suggestion seemed generally popular but [[DominikMierzejewski|Dominik `Rathann' Mierzejewski]] wished to retain the blinking cursor and expressed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02309.html</ref> a desire for more information on the methodology which Matthew had used. [[BillNottingham|Bill Nottingham]] reminded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02320.html</ref> that it would still be possible to turn the cursor back on from this new default. Matthew provided<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02387.html</ref> some of the requested details.
The suggestion seemed generally popular but [[User:Rathann|Dominik `Rathann' Mierzejewski]] wished to retain the blinking cursor and expressed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02309.html</ref> a desire for more information on the methodology which Matthew had used. [[User:Notting|Bill Nottingham]] reminded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02320.html</ref> that it would still be possible to turn the cursor back on from this new default. Matthew provided<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02387.html</ref> some of the requested details.


[[MatthiasClasen|Matthias Clasen]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02268.html</ref> changing a <code>GTK</code> setting which disables cursor blinking after a timeout. [[JoshBoyer|Josh Boyer]] worried<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02287.html</ref> about other desktop environments and vttys.
[[MatthiasClasen|Matthias Clasen]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02268.html</ref> changing a <code>GTK</code> setting which disables cursor blinking after a timeout. [[User:Jwboyer|Josh Boyer]] worried<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02287.html</ref> about other desktop environments and vttys.


<references/>
<references/>
Line 193: Line 309:
http://fedoraproject.org/wiki/L10N
http://fedoraproject.org/wiki/L10N


Contributing Writer: [[RunaBhattacharjee|Runa Bhattacharjee]]
Contributing Writer: [[User:Runab|Runa Bhattacharjee]]


=== FLP Meeting held on 27th January 2009 ===
=== FLP Meeting held on 27th January 2009 ===
Line 203: Line 319:
=== Website Translation Process Update ===
=== Website Translation Process Update ===


[[RickyZhou]] reminded<ref>http://www.redhat.com/archives/fedora-trans-list/2009-January/msg00119.html
[[User:Ricky|Ricky Zhou]] reminded<ref>http://www.redhat.com/archives/fedora-trans-list/2009-January/msg00119.html
</ref> the list about the requirement of notification to be sent to the fedora-websites team for the inclusion of translations for a new language. It is to be noted, that for new languages the relevant language code is also required to be added to the LINGUAS file. However, the notification sent to the fedora-websites team ensures that the apache configuration is modified to activate the translations for the new language.  
</ref> the list about the requirement of notification to be sent to the fedora-websites team for the inclusion of translations for a new language. It is to be noted, that for new languages the relevant language code is also required to be added to the LINGUAS file. However, the notification sent to the fedora-websites team ensures that the apache configuration is modified to activate the translations for the new language.  


Line 210: Line 326:
=== System-Config-Printer branch 1.1.x to be used for Fedora 11 ===
=== System-Config-Printer branch 1.1.x to be used for Fedora 11 ===


[[TimWaugh]] announced<ref>http://www.redhat.com/archives/fedora-trans-list/2009-January/msg00135.html</ref> that the branch 1.1.x of System-Config-Printer is to be used for submitting translations. This branch has been activated for submission on translate.fedoraproject.org by [[DimitrisGlezos]]. Additionally, the obsolete branches for System-Config-Printer have been removed<ref>http://www.redhat.com/archives/fedora-trans-list/2009-January/msg00133.html</ref> from the submission interface.
[[TimWaugh|Tim Waugh]] announced<ref>http://www.redhat.com/archives/fedora-trans-list/2009-January/msg00135.html</ref> that the branch 1.1.x of System-Config-Printer is to be used for submitting translations. This branch has been activated for submission on translate.fedoraproject.org by [[DimitrisGlezos|Dimitris Glezos]]. Additionally, the obsolete branches for System-Config-Printer have been removed<ref>http://www.redhat.com/archives/fedora-trans-list/2009-January/msg00133.html</ref> from the submission interface.


<references/>
<references/>
Line 216: Line 332:
=== Fedora 11 Release Schedule Plans ===
=== Fedora 11 Release Schedule Plans ===


[[JohnPoelstra]] has drafted<ref>http://www.redhat.com/archives/fedora-trans-list/2009-January/msg00130.html</ref> the Documentation and Translation Schedules for the upcoming Fedora 11 Release. The Translation Schedule has been based upon the Documentation Schedule. FLSCo member [[NorikoMizumoto]] provided<ref>http://www.redhat.com/archives/fedora-trans-list/2009-January/msg00103.html</ref> feedback from the FLP about the Translation Schedule. Earlier during the week, [[DimitrisGlezos]] attended</ref>http://www.redhat.com/archives/fedora-trans-list/2009-January/msg00116.html</ref> the Fedora 11 Alpha Readiness Meeting.
[[User:Poelstra|John Poelstra]] has drafted<ref>http://www.redhat.com/archives/fedora-trans-list/2009-January/msg00130.html</ref> the Documentation and Translation Schedules for the upcoming Fedora 11 Release. The Translation Schedule has been based upon the Documentation Schedule. FLSCo member [[NorikoMizumoto|Noriko Mizumoto]] provided<ref>http://www.redhat.com/archives/fedora-trans-list/2009-January/msg00103.html</ref> feedback from the FLP about the Translation Schedule. Earlier during the week, [[DimitrisGlezos|Dimitris Glezos]] attended<ref>http://www.redhat.com/archives/fedora-trans-list/2009-January/msg00116.html</ref> the Fedora 11 Alpha Readiness Meeting.


<references/>
<references/>
Line 222: Line 338:
=== Anaconda bug due to UTF characters ===
=== Anaconda bug due to UTF characters ===


[[VillePekkaVainio]] mentioned the presence of a bug<ref>https://bugzilla.redhat.com/show_bug.cgi?id=466644</ref> in Anaconda caused<ref>http://www.redhat.com/archives/fedora-trans-list/2009-January/msg00159.html</ref> by the presence of UTF-8 characters more than 2 bytes wide. As a result the translated interface is damaged.
[[User:Vpv|Ville Pekka Vainio]] mentioned the presence of a bug<ref>https://bugzilla.redhat.com/show_bug.cgi?id=466644</ref> in Anaconda caused<ref>http://www.redhat.com/archives/fedora-trans-list/2009-January/msg00159.html</ref> by the presence of UTF-8 characters more than 2 bytes wide. As a result the translated interface is damaged.


<references/>
<references/>
Line 228: Line 344:
=== L10n Infrastructure Roadmap Proposal ===
=== L10n Infrastructure Roadmap Proposal ===


In response to the earlier discussions about the problems faced by the L10n infrastructure, [[AsgeirFrimannsson]] sent<ref>http://www.redhat.com/archives/fedora-trans-list/2009-February/msg00000.html</ref> in a proposal for a review roadmap of the current infrastructure[11]. He explained that based upon the outcome of this discussion, further plans can be determined about restructuring the infrastructure.
In response to the earlier discussions about the problems faced by the L10n infrastructure, [[User:Asgeirf|Asgeir Frimannsson]] sent<ref>http://www.redhat.com/archives/fedora-trans-list/2009-February/msg00000.html</ref> in a proposal for a review roadmap of the current infrastructure[11]. He explained that based upon the outcome of this discussion, further plans can be determined about restructuring the infrastructure.


<references/>
<references/>
Line 239: Line 355:


{{Anchor|Infrastructure}}
{{Anchor|Infrastructure}}
== Infrastructure ==
== Infrastructure ==


Line 249: Line 366:
=== Automating hosted projects? ===
=== Automating hosted projects? ===


[[PaulFrields|Paul W. Frields]] asked<ref>https://www.redhat.com/archives/fedora-infrastructure-list/2009-January/msg00124.html</ref> on the @fedora-infrastructure-list if it was possible to automate the creation of projects on the fedorahosted.org site. Since some potential contributors may need more instantaneos result and not wait for an admin to create the project.
[[User:Pfrields|Paul W. Frields]] asked<ref>https://www.redhat.com/archives/fedora-infrastructure-list/2009-January/msg00124.html</ref> on the @fedora-infrastructure-list if it was possible to automate the creation of projects on the fedorahosted.org site. Since some potential contributors may need more immediate results and not wait for an admin to create the project.


To this [[SethVidal|Seth Vidal]] replied<ref>https://www.redhat.com/archives/fedora-infrastructure-list/2009-January/msg00125.html</ref> that a part of the benefit of this being manual is that
To this [[SethVidal|Seth Vidal]] replied<ref>https://www.redhat.com/archives/fedora-infrastructure-list/2009-January/msg00125.html</ref> that a part of the benefit of this being manual is that the admin can do a bit of sanity check before the project is created.
the admin can do a bit of sanity check before the project is created.


<references/>
<references/>
Line 258: Line 374:
=== CSI (Security Policy) ===
=== CSI (Security Policy) ===


[[MikeMcGrath | Mike McGrath]] said<ref>https://www.redhat.com/archives/fedora-infrastructure-list/2009-January/msg00172.html</ref> on the @fedora-infrastructure-list that he had put the security policy CSI docs in the standard place<ref>http://infrastructure.fedoraproject.org/csi/security-policy/en-US</ref>
[[User:Mmcgrath| Mike McGrath]] said<ref>https://www.redhat.com/archives/fedora-infrastructure-list/2009-January/msg00172.html</ref> on the @fedora-infrastructure-list that he had put the security policy CSI docs in the standard place<ref>http://infrastructure.fedoraproject.org/csi/security-policy/en-US</ref>


<references/>
<references/>


{{Anchor|Artwork}}
{{Anchor|Artwork}}
== Artwork ==
== Artwork ==


Line 320: Line 437:


==== New Release virt-manager 0.6.1 ====
==== New Release virt-manager 0.6.1 ====
[[ColeRobinson|Cole Robinson]] announced[1] a new {{package|virt-manager}} release, version 0.6.1.
[[User:Crobinso|Cole Robinson]] announced[1] a new {{package|virt-manager}} release, version 0.6.1.


Virtual Machine Manager provides a graphical tool for administering virtual
Virtual Machine Manager provides a graphical tool for administering virtual
Line 362: Line 479:


==== Fedora Virt Status Update ====
==== Fedora Virt Status Update ====
True to his word, [[MarkMcLoughlin|Mark McLoughlin]] posted<ref>http://www.redhat.com/archives/fedora-virt/2009-January/msg00063.html</ref> another weekly update on the status of virtualization development in Fedora. Some highlights included:
True to his word, [[User:Markmc|Mark McLoughlin]] posted<ref>http://www.redhat.com/archives/fedora-virt/2009-January/msg00063.html</ref> another weekly update on the status of virtualization development in Fedora. Some highlights included:


* F11 Alpha Blockers - Workaround found for "unsynchronized TSC" issue<ref>https://bugzilla.redhat.com/475598</ref> which caused guests on certain hosts to hang or crash.
* F11 Alpha Blockers - Workaround found for "unsynchronized TSC" issue<ref>https://bugzilla.redhat.com/475598</ref> which caused guests on certain hosts to hang or crash.
Line 379: Line 496:


==== Xen Users Future on Fedora ====
==== Xen Users Future on Fedora ====
[[EvanLavelle|Evan Lavelle]] might have struck a nerve when wondering[1] if those who have invested years in {{package|xen}} on Fedora have been "shafted". "<code>Xen</code> isn't flavour of the month around here, but I assumed there were good reasons for that. Now, rather belatedly, I've found" that Red Hat acquired Qumranet and {{package|KVM}}. (FWN #143[2])  
[[EvanLavelle|Evan Lavelle]] might have struck a nerve when wondering<ref>http://www.redhat.com/archives/fedora-xen/2009-January/msg00031.html</ref> if those who have invested years in {{package|xen}} on Fedora have been "shafted". "<code>Xen</code> isn't flavour of the month around here, but I assumed there were good reasons for that. Now, rather belatedly, I've found" that Red Hat acquired Qumranet and {{package|KVM}}. (FWN #143)<ref>http://fedoraproject.org/wiki/FWN/Issue143#Red_Hat_Acquires_Makers_of_KVM.2C_Qumranet_Inc</ref>


[[NeilThompson|Neil Thompson]] thought[3] not. "Shafted?...I don't think so. We're just in a blip at the moment." Neil pointed out that "RHEL5, which has a number of years left, includes xen - I don't think
[[NeilThompson|Neil Thompson]] thought<ref>http://www.redhat.com/archives/fedora-xen/2009-January/msg00033.html</ref> not. "Shafted?...I don't think so. We're just in a blip at the moment." Neil pointed out that "RHEL5, which has a number of years left, includes xen - I don't think
Red Hat are going to mess their corporate clients around by removing it. The problem with F8 is that the {{package|kernel}} people could no longer drag an obsolete (2.6.21) <code>kernel</code> around just for xen, and decided to concentrate on helping get it into the mainstream <code>kernel</code>.  This[4] has taken longer than expected."
Red Hat are going to mess their corporate clients around by removing it. The problem with F8 is that the {{package|kernel}} people could no longer drag an obsolete (2.6.21) <code>kernel</code> around just for xen, and decided to concentrate on helping get it into the mainstream <code>kernel</code>.  This<ref>http://fedoraproject.org/wiki/Features/XenPvopsDom0</ref> has taken longer than expected."


Jan ONDREJ was also concerned[5] that, "<code>KVM</code> is still not a replacement for paravirtualized machines and I think fully virtualized <code>KVM</code> will be slower like a paravirtualized XEN."
Jan ONDREJ was also concerned<ref>http://www.redhat.com/archives/fedora-xen/2009-January/msg00032.html</ref> that, "<code>KVM</code> is still not a replacement for paravirtualized machines and I think fully virtualized <code>KVM</code> will be slower like a paravirtualized XEN."


[[RichardJones|Richard W.M. Jones]] countered[6]
[[RichardJones|Richard W.M. Jones]] countered<ref>http://www.redhat.com/archives/fedora-xen/2009-January/msg00041.html</ref>
"<code>KVM</code> is a great replacement for <code>Xen</code>. It's much easier to use for a start -- no more rebooting into a completely separate <code>kernel</code> hypervisor. As long as you have the <code>virtio</code> drivers in the guest, which is the default for all new Linux distros, performance is roughly the same."  
"<code>KVM</code> is a great replacement for <code>Xen</code>. It's much easier to use for a start -- no more rebooting into a completely separate <code>kernel</code> hypervisor. As long as you have the <code>virtio</code> drivers in the guest, which is the default for all new Linux distros, performance is roughly the same."  


Apropos to the topic, but on another list, [[MarkMcLoughlin|Mark McLoughlin]] explained[7]
Apropos to the topic, but on another list, [[MarkMcLoughlin|Mark McLoughlin]] explained<ref>http://www.redhat.com/archives/et-mgmt-tools/2009-January/msg00063.html</ref>
"Para-virtualization isn't always better. <code>KVM</code> uses full virtualization, meaning that it uses the processor's support for virtualization. This means you can run an unmodified guest OS on <code>KVM</code>.  
"Para-virtualization isn't always better. <code>KVM</code> uses full virtualization, meaning that it uses the processor's support for virtualization. This means you can run an unmodified guest OS on <code>KVM</code>.  
If you can modify the guest OS, then <code>KVM</code> does allow you to use paravirtualization for some performance sensitive operations - so e.g.  we've got <code>pvclock</code>, pv MMU and <code>virtio</code> devices.
If you can modify the guest OS, then <code>KVM</code> does allow you to use paravirtualization for some performance sensitive operations - so e.g.  we've got <code>pvclock</code>, pv MMU and <code>virtio</code> devices.
Don't get tied up in marketing terminology - try both and decide for yourself which works best for you."
Don't get tied up in marketing terminology - try both and decide for yourself which works best for you."


Support for dom0 is targeted[8] for <code>kernel</code> 2.6.29, but the changelogs[9] for the release candidates don't seem to indicate completion yet.  
Support for dom0 is targeted<ref>http://wiki.xensource.com/xenwiki/XenParavirtOps</ref> for <code>kernel</code> 2.6.29, but the changelogs<ref>http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.29-rc2 http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.29-rc1</ref> for the release candidates don't seem to indicate completion yet.  
[[GerdHoffmann|Gerd Hoffmann]] confirmed[10] that "...most of the dom0 stuff missed the boat. Some prelimary stuff might be in though..." adding that "The pv_ops/dom0 kernel has some not-yet debugged storage issues (disk controller either fails after a while or doesn't work at all), which is the major stumbling block right now."
[[GerdHoffmann|Gerd Hoffmann]] confirmed<ref>http://www.redhat.com/archives/fedora-xen/2009-January/msg00056.html</ref> that "...most of the dom0 stuff missed the boat. Some prelimary stuff might be in though..." adding that "The pv_ops/dom0 kernel has some not-yet debugged storage issues (disk controller either fails after a while or doesn't work at all), which is the major stumbling block right now."


[[DanielBerrange|Daniel P. Berrange]], of Red Hat Engineering, detailed the history of <code>Xen</code> on Fedora and explained "while it is definitely unfortunate that we don't have a <code>Xen</code> Dom0 kernel in Fedora 9/10, we are *not* trying to shaft anyone & will re-introduce <code>Xen</code> Dom0 kernels to Fedora when they become available." ... "It [is] still hard to say just when these will be accepted upstream, but there is a semi-reasonable [chance] we'll be able to turn <code>Xen</code> Dom0 back on in Fedora 11 kernels."[11]
[[DanielBerrange|Daniel P. Berrange]], of Red Hat Engineering, detailed the history of <code>Xen</code> on Fedora and explained "while it is definitely unfortunate that we don't have a <code>Xen</code> Dom0 kernel in Fedora 9/10, we are *not* trying to shaft anyone & will re-introduce <code>Xen</code> Dom0 kernels to Fedora when they become available." ... "It [is] still hard to say just when these will be accepted upstream, but there is a semi-reasonable [chance] we'll be able to turn <code>Xen</code> Dom0 back on in Fedora 11 kernels."<ref>http://www.redhat.com/archives/fedora-xen/2009-January/msg00036.html</ref>


[1] http://www.redhat.com/archives/fedora-xen/2009-January/msg00031.html
<references/>
 
[2] http://fedoraproject.org/wiki/FWN/Issue143#Red_Hat_Acquires_Makers_of_KVM.2C_Qumranet_Inc.
 
[3] http://www.redhat.com/archives/fedora-xen/2009-January/msg00033.html
 
[4] http://fedoraproject.org/wiki/Features/XenPvopsDom0
 
[5] http://www.redhat.com/archives/fedora-xen/2009-January/msg00032.html
 
[6] http://www.redhat.com/archives/fedora-xen/2009-January/msg00041.html
 
[7] http://www.redhat.com/archives/et-mgmt-tools/2009-January/msg00063.html
 
[8] http://wiki.xensource.com/xenwiki/XenParavirtOps
 
[9] http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.29-rc2 http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.29-rc1
 
[10] http://www.redhat.com/archives/fedora-xen/2009-January/msg00056.html
 
[11] http://www.redhat.com/archives/fedora-xen/2009-January/msg00036.html


==== Migrating Xen DomU to KVM Guest ====
==== Migrating Xen DomU to KVM Guest ====
Line 433: Line 530:
* "tell<ref>http://www.redhat.com/archives/fedora-xen/2009-January/msg00048.html</ref> the host to give the guest a <code>virtio</code> network card - change the NIC <code><model type='virtio'/></code>"
* "tell<ref>http://www.redhat.com/archives/fedora-xen/2009-January/msg00048.html</ref> the host to give the guest a <code>virtio</code> network card - change the NIC <code><model type='virtio'/></code>"


Richard finally noted<ref>http://www.redhat.com/archives/fedora-xen/2009-January/msg00053.html</ref> "For newly installed guests, recent anaconda just works everything out for you and puts the correct drivers into <code>initrd</code>." [[MarkMcLoughlin|Mark McLoughlin]] provided the <code>mkinitrd</code> command to build the appropriate <code>initrd</code> in existing guests: '<code>mkinitrd --with virtio_pci --with virtio_blk -f /boot/initrd-$(kernelversion) $(kernelversion)</code>' "You only need to do this once. After that, if a new kernel is installed while you're booted off a virtio disk, then mkinitrd will include the modules automatically."
Richard finally noted<ref>http://www.redhat.com/archives/fedora-xen/2009-January/msg00053.html</ref> "For newly installed guests, recent anaconda just works everything out for you and puts the correct drivers into <code>initrd</code>." [[User:Markmc|Mark McLoughlin]] provided the <code>mkinitrd</code> command to build the appropriate <code>initrd</code> in existing guests: '<code>mkinitrd --with virtio_pci --with virtio_blk -f /boot/initrd-$(kernelversion) $(kernelversion)</code>' "You only need to do this once. After that, if a new kernel is installed while you're booted off a virtio disk, then mkinitrd will include the modules automatically."


[[EmreErenoglu|Emre Erenoglu]] noted<ref>http://www.redhat.com/archives/fedora-xen/2009-January/msg00058.html</ref>
[[EmreErenoglu|Emre Erenoglu]] noted<ref>http://www.redhat.com/archives/fedora-xen/2009-January/msg00058.html</ref>
"You will also need to specify <code>/dev/vdX</code> on the <code>kernel root=</code> line and make sure your init script inside your <code>initrd</code> triggers the virtio drivers at boot so that the <code>/dev/vdX</code> are created."
"You will also need to specify <code>/dev/vdX</code> on the <code>kernel root=</code> line and make sure your init script inside your <code>initrd</code> triggers the virtio drivers at boot so that the <code>/dev/vdX</code> are created."


[[MarkMcLoughlin|Mark McLoughlin]] added<ref>http://www.redhat.com/archives/fedora-xen/2009-January/msg00078.html</ref> a caveat.
[[User:Markmc|Mark McLoughlin]] added<ref>http://www.redhat.com/archives/fedora-xen/2009-January/msg00078.html</ref> a caveat.
"the F9 x86_64 xen kernel didn't have support for running 32 bit binaries like grub, so the bootloader would never
"the F9 x86_64 xen kernel didn't have support for running 32 bit binaries like grub, so the bootloader would never
have been installed into the MBR. That works fine for pygrub, but not with KVM's real BIOS."
have been installed into the MBR. That works fine for pygrub, but not with KVM's real BIOS."
Line 491: Line 588:


<references/>
<references/>
[[Category:News]]

Latest revision as of 10:34, 14 April 2009

Fedora Weekly News Issue 161

Welcome to Fedora Weekly News Issue 161 for the week ending February 1, 2009.

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

This week's FWN goodness offers a very special update from the Fonts SIG to bring us up to date on their work leading up to Fedora 11. You may also notice that we are tweaking the wiki formatting to take advantage of the cite module and other features in MediaWiki, and employing User: references for links to named Fedora folk. We'd love to hear your feedback on these changes. Also in this week's intrepid issue details on the upcoming Fedora monthly public meeting, updates on upcoming events with a Fedora presence, and news updates from around the Fedora Planet. In Developments, details on a slight delay to F11 Alpha and Electronic Automation Tools updates. Translation news brings updates from the latest FLP meeting and website translation updates, along with more Fedora 11 plans. A couple brief updates from the Infrastructure Team, including discussion of possible automation of fedora hosted requests. The Artwork beat paints a lovely picture with details on Fedora 11 visual details, and we're brought up to date with the latest security advisories for Fedora 9 and 10. The issue completes with updates from the various virtualization projects, including details on a new libvirt and virt-manager, as well as meaty updates on the Fedora Xen list. Enjoy, everyone!

We are currently looking for a new writer to cover the Fedora Ambassadors for FWN. The work chiefly involves summarizing each's week's traffic on the Fedora Ambassadors' list, and is likely a time committment of perhaps one hour per week.

If you are interested in contributing to Fedora Weekly News, please see our 'join' page[1]. We welcome reader feedback: fedora-news-list@redhat.com

FWN Editorial Team: Pascal Calarco, Oisin Feeley, Huzaifa Sidhpurwala

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

Fedora Board Meeting

Paul Frields wrote[2] that "the Board is holding its monthly public meeting on Tuesday, 3 February 2009, at 1900 UTC on IRC Freenode."

  • Join #fedora-board-meeting to see the Board's conversation. This channel is read-only for non-Board members.
  • Join #fedora-board-public to discuss topics and post questions. This channel is read/write for everyone.

Legal

Tom Callaway announced [1] that "after talking with Red Hat Legal about how we should be handling trademarks in package summaries and descriptions, we came to the conclusion that it would be far easier (and less risky for Red Hat) if we did not use "(TM)" or "(R)" notations at all."

Fedora 11

Fedora 11 Alpha is likely to be delayed for a few days (originally scheduled for February 3) due to a GUI checkbox bug in Anaconda and a problem with nfs-utils that prevented installs over NFS.

See the links [1] [2] [3] below for all the technical details.

Upcoming Events

Fedora will have a presence at several events in the next few weeks. Feel free to join us,

February 6 - 8: Free and Open Source Developers European Meeting (FOSDEM)[1]

February 20 - 22: Southern California Linux Expo (SCALE)[2][3]

Also, people are encouraged to register for Fedora or JBoss.org related speaking slots at LinuxTag 2009.[4]

Contributing Writer: Nicolas Mailhot

Special Report: Fonts SIG

Since Fedora 11 Alpha is quickly approaching, here is a much-delayed edition of the fonts SIG irregular status report. You may recall FWN covered the font surveys in FWN #153[1]. The following special report is largely in addition to that previous report.

I should probably have done one for Fedora 10 release, but (silly me) expected then that the new font packaging guidelines would be adopted quickly. After all, they only reworded existing rules and added material already presented and discussed on the fonts and devel lists.

Of course various instances decided to celebrate F10 by taking a break, then there was some bike-shedding, then we had the Christmas vacations, then FUDCON and more bike-shedding. Live and learn. At least after being hammered to death the result is clear and clean.

Anyway, to the report.

New fonts packaging guidelines

After much anguish and unexpected developments FPC and FESCO approved the complete set of fonts packaging changes that we had submitted.[1]

The end result is:

1) a completed and clarified policy page[2]

2) two new packaging templates[3] [4]

3) a helper package with rpm macros, documentation, plus fontconfig and spec templates[5]

Distribution-wide font auditing and repackaging

Some innocent repoqueries revealed a distressing number of source packages (>130) that made us ship fonts while completely ignoring our previous fonts packaging guidelines and existing licensing rules. So applying new font guidelines twists quickly turned into distribution-wide operation.

1) Its advancement is now tracked[1]

2) A (long) FAQ was published to help packagers with no fonts experience[2]

3) To make sure documentation, QA and other groups are aware and help implement the changes they've been proposed as a Fedora 11 feature[3]

Wishlist status

Our wishlist stood at 56 entries for last report. It has now reached 76 entries [1]. The current fonts packagers are clearly unable to cope with Fedora demands, fresh blood is needed before it moves into 100+ numbers.

At the same time the respected lwn.net is running a front page article[2] listing more indispensable free or open fonts, some of them being neither in Fedora nor in our wishlist yet.

Volunteers to package those or at least add them to our wishlist are welcome. The free and open font landscape is really moving now, and the quality and breadth of its font offerings is now a distribution differentiator.

Review status

At this time there are no un-reviewed font packages in Fedora bugzilla. However, several reviews have been open for quite a long time with their requesters not acting on review comments.

Please do respond to review comments. Reviewing packages is tedious ungrateful work and getting no response after one is demotivating.

New packages

Ignoring renamings ctan-musixtex-fonts, dustin-dustismo-roman-fonts,dustin-dustismo-sans-fonts, hanazono-fonts, google-droid-sans-fonts, google-droid-sans-mono-font, google-droid-serif-fonts, serafettin-cartoon-fonts, and unikurd-web-font are now available in the repository.

The most user-visible of those are probably the Droid fonts, but Dustimo had been waited for a long time.

Several other fonts previously hidden deep inside apps have now been exposed as part of the ongoing F11 auditing and repackaging. The complete set of changes is documented as usual[1]

Several new packagers worked on those and on other packages not pushed yet and I want to thank them publicly for their contribution to a better Fedora.

Web font surveys

Fedora 10 shipped with an openjdk plugin that should be complete enough to run web font surveys. There is no reason left for Fedora users not to participate in them, and help web designers select fonts that work well with Fedora browsers. Please take the time to contribute to these[1]

Better fonts whiteboard

The desktop team has added a whiteboard page[1] to the wiki to help identify the software changes needed to improve Fedora fonts and text handling.

Please contribute comments and complements to this page to help make Fedora better.

Font autoinstallation

Rumors on IRC are that the feature is advancing fast. Hopefully we'll have finished cleaning up our font packages before they need to be rebuild to add auto-install metadata[1]. Automating this operation requires clean packages free of historic cruft.

And that's all for this issue, thank you for reading it to its end.


Planet Fedora

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

http://planet.fedoraproject.org

Contributing Writer: Adam Batkin

General

Chris Ball posted[1] a video and brief description of some patches to the Vino VNC server to support the multiple pointers on X over VNC, so there will be no more fighting over the mouse cursor when connecting into another computer.

Mark J. Wielaard wrote[2] about what he does for a living at Red Hat, including a link to a LWN article that he wrote that provides a high-level overview of Systemtap.

John J. McDonough described[3] some of the upcoming changes to the Fedora Docs project, including its leadership. Karsten Wade chimed in[4] with some more details including some additional history.

Matthew Garrett discussed[5] some of the issues associated with power management under Linux and how "to make it sufficiently useful and inobtrusive that manual configuration is almost never required."

Gary Benson shared[6],[7],[8],[9],[10] a series of articles that he wrote about the internals of Zero and Shark (projects which extend OpenJDK to let it run on new platforms without additional and often cumbersome low-level CPU-specific support).

Martin Sourada developed[11] a set of scripts "which are intended to ease the life of echo-icon artist - they create new icons from template, are able to add icons/symlinks to echo icon theme and add manage their local git repository."

Matthew Daniels mused[12] on the topic of "Social Responsibility" and getting technology out into people's hands everywhere and making all of this social hardware and software accessible.

Jonathan Roberts posted[13],[14] some thoughts about how some of the upcoming major Gnome 3.0 changes might be able to handle things like locating information ("Ubiquitous Search") and saving information automatically.

Richard Hughes created [15] a nice graphical UI front-end for Powertop.

Adam Williamson expressed[16] some frustrations with the fact that the drivers for the Intel GMA 500 (Poulsbo) graphics chip (most notably used in the Dell Mini 12) don't seem to compile cleanly or integrate well with anything, and in fact only work on Ubuntu Netbook Remix.

John Palmier proposed[17] "10 thoughts on what is needed for the Linux Desktop to win".

How-To

Ian Weller offered[1] some tips on moving pages around on the Fedora Project Wiki as part of the new Wiki Tip of the Week[2] series.

Kulbir Saini explained[3] "How to setup gitweb on Fedora/CentOS".

Ding-Yi Chen provided[4] some quick instructions on how to sync between Evolution and a Sony Ericsson K510i phone.

Steven Moix wrote[5] instructions on how to configure a GSynaptics touchpad (which is included with many laptops these days) now that there is no xorg.conf file for the GSynaptics utility to modify.

Developments

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

Contributing Writer: Oisin Feeley

Fedora 11 Alpha May Be Delayed

Jesse Keating reported[1] that the Fedora 11 Alpha release date might slip due to some anaconda bugs which manifested themselves late in his testing on some architectures. A later post suggested[2] that installation using NFS was broken and that "[t]his likely means a slip, perhaps only a two day slip, of Alpha." More info to come either later this weekend or early next week. A bugzilla comment[3] from Warren Togami on a side-effect of trying to fix this problem by reverting to an earlier nfs-utils version warned "People should be aware that NFS as a server in F11 Alpha is broken. That is all." As of going to press on 2009-02-01 there was no further information available.

GCC: Default ISA Flags and Glibc

Jakub Jelinek asked[1] whether the minimum CPU which would run code compiled by Fedora 11's GCC should be re-evaluated. A follow-on question was whether the minimum supported kernel version in glibc could be bumped to 2.6.29. Jakub held out the promise of potentially increased speed and decreased shared library sizes.

A problem raised[2] by Kevin Kofler was that mock builds would no longer be able to run on older Fedora releases and that some VPSs would not be able to upgrade at all. Gerd Hoffman agreed[3]: "We just can't make the huge jump from .9 to .29. We have to do it smaller steps, considering kernel versions at least in supported Fedora versions, maybe also latest RHEL."

Josh Boyer seemed[4] to believe that the required mass rebuild with GCC-4.4 would be difficult but possible. Mike McGrath outlined[5] the amount of work which would be needed.

See this same FWN#161 "Dropping Support for i586 Architecture" for a related discussion.

RPM Packagers: Too Many Unowned Directories

Michael Schwendt raised[1] the problem of unowned directories installed as a result of packagers unfamiliar with "how to include files vs. directories in RPM package %files lists."

Colin Walters remembered[2] discussions which had suggested that if RPM were able to reference count directories there could be a technological fix. Separately Richard W.M. Jones made[3] a similar argument. Panu Matilainen seemed[4] willing to move this task to the top of his queue if it were sufficiently important.

Lack of Update Information

A can of worms was opened[1] by Rahul Sundaram when he noticed that the update information provided by package maintainers was often unhelpful. He cited generic messages of the form "Update foo to upstream x.y.z" as a common problem and wondered if guidelines could improve the situation.

Following some questions Rahul expanded[2] on the problem pointing out that package maintainers had the knowledge to tersely explain what upstream changes implied for ordinary users. He emphasized that he was concerned with the "description that is part of bodhi update and not the changelog which can be very brief."

Chris Weyl put[3] forward the counter-argument that package maintainers had a difficult enough life already.

Richard W.M. Jones wondered[4] if rpm could be altered to allow it to reference upstream changelogs which could be pulled out by other tools. Panu Matilainen averred[5] that while rpm was alterable Richard's proposed change would just dump the information into the rpm payload and it would thus not be available to users until after they had installed it. Further brainstorming seemed[6] to run into various practical dead ends.

Subsequently Rahul published[7] a draft guideline which fanned the flames back to life. Thorsten Leemhuis asked[8] "Don't we have way [too] many guidelines and policies already? [...] Note that I don't disagree with the text that was proposed. My 2 cent: Put it as text into the wiki somewhere, write "best practices" on top of it (avoid the words "rules" and "guidelines") and add a link to the bodhi UI ("best practices for filling this box with information")." Rahul appeared to agree that this was the best course for the present and deferred to FESCo for the ultimate decision.

Electronic Design Automation Content Without Tools ?

Chitlesh Goorah redirected[1] a debate on Electronic Design Automation (EDA)[2] tools from FESCo to @fedora-devel. Chitlesh is the prime mover behind the Fedora Electronic Lab Spin[3]. He was concerned that FESCo had decided that packages in the OVM[4] format were barred from Fedora on the grounds that there was no FLOSS tool which could use them although they were licensed acceptably.

Jef Spaleta explained[5] that there were subtle problems in the discussion as "[OVM] is code of some sort. The problem is we don't have a compiler or interpreter that can process the instructions. In the context of Fedora its code that can't be used." Kevin Kofler supplied[6] the appropriate guideline.

Kevin Fenzi expressed[7] appreciation for Chitlesh's work on the Fedora Electronics Lab and asked if there was any use for OVM besides hooking it up with a non-Free simulator? Manuel Wolfshant argued[8] that OVM "is interesting for a subset of the people interested in EDA" and that it should be provided for them. Horst von Brand disliked[9] the idea of mirrors carrying such a little-used package around and suggested that Manuel could just set up his own repository.

Dropping Support for i586 Architecture ?

Following FESCo discussions[1] Bill Nottingham reported[2] that the supported architecture list was going to change. Important changes include building binaries only for i686 and above. There are concerns that older thin clients based on i586 hardware and the AMD Geode-based XO laptops may then be unsupported or unstable. Bill characterized the discussions as a follow-up to the compiler flag discussions (see this same FWN#161"GCC: Default ISA Flags and Glibc") and summarized the main points as:

- install x86.64 kernel on 32-bit OS where appropriate
- install PAE kernel on other 32-bit OS installs where appropriate
- build only i686 and above for Fedora

Jeremy Katz added[3] anecdotal reassurance that the XO should probably be fine with the i686 kernel and glibc.

Robert Scheck wondered[4] what the definition of "where appropriate" was and what mechanism would be used to make this determination.

Dominik 'Rathann' Mierzejewski predicted[5] "[t]here's going to be some screaming from VIA C3 and AMD K6 users about this." His suggestion was true during an older similar discussion (see FWN#93[6]) in 2007 which concerned plans to drop shipping an i586 kernel. Suggested attempts to compensate by making the i686 kernel bootable on i586 architectures were thwarted as rpm balked at installing a kernel which violated its architecture check. Alan Cox was one of the strongest objectors to the possibility of thus losing support for i586 as he had many thin clients using that architecture. Doubt was cast during that thread as to whether the smolt statistics were believable. However, Alan has recently become an Intel employee (following other ex-Red Hat luminaries David Woodhouse and Arjan van de Ven) and did not contribute to the thread. The smolt statistics listed[7] on the feature page suggest that there are only 130 i586 users.

Josh Boyer clarified[8] that no decision had yet been made by FESCo and that a vote would take place next week.

Blinking Cursor Wastes Power

Matthew Garrett asked[1] for comments on the idea that the cursor should default to not blinking. The rationale was that several less Watts of power would be consumed.

The suggestion seemed generally popular but Dominik `Rathann' Mierzejewski wished to retain the blinking cursor and expressed[2] a desire for more information on the methodology which Matthew had used. Bill Nottingham reminded[3] that it would still be possible to turn the cursor back on from this new default. Matthew provided[4] some of the requested details.

Matthias Clasen suggested[5] changing a GTK setting which disables cursor blinking after a timeout. Josh Boyer worried[6] about other desktop environments and vttys.

Translation

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

http://fedoraproject.org/wiki/L10N

Contributing Writer: Runa Bhattacharjee

FLP Meeting held on 27th January 2009

The first meeting of FLP for the year 2009[1] was held on 2009-01-27 at 18:00 UTC. The discussion centered[2] around the current bugs and issues being faced by the L10n infrastructure.

Website Translation Process Update

Ricky Zhou reminded[1] the list about the requirement of notification to be sent to the fedora-websites team for the inclusion of translations for a new language. It is to be noted, that for new languages the relevant language code is also required to be added to the LINGUAS file. However, the notification sent to the fedora-websites team ensures that the apache configuration is modified to activate the translations for the new language.

System-Config-Printer branch 1.1.x to be used for Fedora 11

Tim Waugh announced[1] that the branch 1.1.x of System-Config-Printer is to be used for submitting translations. This branch has been activated for submission on translate.fedoraproject.org by Dimitris Glezos. Additionally, the obsolete branches for System-Config-Printer have been removed[2] from the submission interface.

Fedora 11 Release Schedule Plans

John Poelstra has drafted[1] the Documentation and Translation Schedules for the upcoming Fedora 11 Release. The Translation Schedule has been based upon the Documentation Schedule. FLSCo member Noriko Mizumoto provided[2] feedback from the FLP about the Translation Schedule. Earlier during the week, Dimitris Glezos attended[3] the Fedora 11 Alpha Readiness Meeting.

Anaconda bug due to UTF characters

Ville Pekka Vainio mentioned the presence of a bug[1] in Anaconda caused[2] by the presence of UTF-8 characters more than 2 bytes wide. As a result the translated interface is damaged.

L10n Infrastructure Roadmap Proposal

In response to the earlier discussions about the problems faced by the L10n infrastructure, Asgeir Frimannsson sent[1] in a proposal for a review roadmap of the current infrastructure[11]. He explained that based upon the outcome of this discussion, further plans can be determined about restructuring the infrastructure.

New Member in FLP

Daniele joined[1] the Italian translation team in the FLP this week.

Infrastructure

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

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: Huzaifa Sidhpurwala

Automating hosted projects?

Paul W. Frields asked[1] on the @fedora-infrastructure-list if it was possible to automate the creation of projects on the fedorahosted.org site. Since some potential contributors may need more immediate results and not wait for an admin to create the project.

To this Seth Vidal replied[2] that a part of the benefit of this being manual is that the admin can do a bit of sanity check before the project is created.

CSI (Security Policy)

Mike McGrath said[1] on the @fedora-infrastructure-list that he had put the security policy CSI docs in the standard place[2]

Artwork

In this section, we cover the Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: Nicu Buculei

Fedora 11 Visual Concepts

With the first milestone[1] for the Fedora 11 visual concept closing on February 1st, Máirí­n Duffy posted[2] on @fedora-art a first mockup "I'm thinking maybe somewhere more mountainous with some mists, and with some vines/plants growing up the columns with some sunbeams on them", which was warmly received by the rest of the team, which opted still for a more lively image, as Luya Tshimbalanga put it[3] "I think of desolation when I see that image with a ruins from old Greek temple (tend to get bored so easily) and a very dry land. That picture would mean Fedora after collapse. Greece is famous with its olive field so the land needs to be green. I see mountain that look like Olympia and the sky appears to be a god/goddess land. That image needs to be live, not dead."

Following this "lively" concept, Konstantinos Antonakoglou came[4] with a photographic collage "I just want to point out the main concept, which is the combination of ancient Greece and nature (water, mountains with a lot of green)" and Bill Nottingham advanced the idea of using photographs[5] "is it possible/should we look for a full photo (appropriately licensed) that can be used?"

At the same time, Samuele Storari tried[6] a different concept in the same Grecian spirit "For this theme I try to work on the Spartan 'Leonidas' idea, I work on the Acient Helm so we don't have discussion on violence or other not connected idea."

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 10 Security Advisories

  • dia-0.96.1-9.fc10[1]
  • kernel-2.6.27.12-170.2.5.fc10[2]
  • vnc-4.1.3-1.fc10[3]
  • glpi-0.71.5-1.fc10[4]
  • gedit-2.24.3-3.fc10[5]

Fedora 9 Security Advisories

  • vnc-4.1.3-1.fc9[1]
  • kernel-2.6.27.12-78.2.8.fc9[2]
  • dia-0.96.1-7.fc9[3]
  • glpi-0.71.5-1.fc9[4]
  • gedit-2.22.3-3.fc9[5]

Virtualization

In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-virt, @fedora-xen-list, and @libvirt-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

New Release virt-manager 0.6.1

Cole Robinson announced[1] a new Package-x-generic-16.pngvirt-manager release, version 0.6.1.

Virtual Machine Manager provides a graphical tool for administering virtual machines for KVM, Xen, and QEmu. Start, stop, add or remove virtual devices, connect to a graphical or serial console, and see resource usage statistics for existing VMs on local or remote machines. Uses libvirt as the backend management API.

New features:

  • VM disk and network stats reporting (Guido Gunther)
  • VM Migration support (Shigeki Sakamoto)
  • Support for adding sound devices to an existing VM
  • Enumerate host devices attached to an existing VM
  • Allow specifying a device model when adding a network device to an existing VM
  • Combine the serial console view with the VM Details window
  • Allow connection to multiple VM serial consoles
  • Bug fixes and many minor improvements.

[1] http://www.redhat.com/archives/et-mgmt-tools/2009-January/msg00067.html

New Release virtinst 0.4.1

Cole Robinson announced[1] a new virtinst release, version 0.4.1.

Package-x-generic-16.pngpython-virtinst is a module that helps build and install libvirt based virtual machines. Currently supports KVM, QEmu and Xen virtual machines. Package includes several command line utilities, including virt-install (build and install new VMs) and virt-clone (clone an existing virtual machine).

New features:

  • Add virt-image -> vmx support to virt-convert, replacing virt-pack (Joey Boggs)
  • Add disk checksum support to virt-image (Joey Boggs)
  • Enhanced URL install support: Debian Xen paravirt, Ubuntu kernel and boot.iso, Mandriva kernel, and Solaris Xen Paravirt (Guido Gunther, John Levon, Cole Robinson)
  • Expanded test suite
  • Numerous bug fixes, cleanups, and minor improvements

[1] http://www.redhat.com/archives/et-mgmt-tools/2009-January/msg00068.html

Fedora Virtualization List

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

Fedora Virt Status Update

True to his word, Mark McLoughlin posted[1] another weekly update on the status of virtualization development in Fedora. Some highlights included:

  • F11 Alpha Blockers - Workaround found for "unsynchronized TSC" issue[2] which caused guests on certain hosts to hang or crash.
  • New release of Package-x-generic-16.pnglibvirt coming very soon. It's out now.
  • The KVM PCI Device Assignment[3] feature for F11 "received a very positive reception from FESCo", and "basic device assignment seems to be working."
  • "Related to PCI device assignment are Intel VT-d issues that have been reported recently. Basically, on some machines ... VT-d support is causing serious [problems] and, in one case, data loss."
  • New F11 feature page created for sVirt.[4] "sVirt integrates SELinux with the Fedora virtualization stack".
  • New patches from Jeremy Fitzhardinge reduce the overhead of enabling paravirt_ops on bare-metal by 75% in testing.
  • Bug count climbed from 186 to 191.

Fedora Xen List

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

Xen Users Future on Fedora

Evan Lavelle might have struck a nerve when wondering[1] if those who have invested years in Package-x-generic-16.pngxen on Fedora have been "shafted". "Xen isn't flavour of the month around here, but I assumed there were good reasons for that. Now, rather belatedly, I've found" that Red Hat acquired Qumranet and Package-x-generic-16.pngKVM. (FWN #143)[2]

Neil Thompson thought[3] not. "Shafted?...I don't think so. We're just in a blip at the moment." Neil pointed out that "RHEL5, which has a number of years left, includes xen - I don't think Red Hat are going to mess their corporate clients around by removing it. The problem with F8 is that the Package-x-generic-16.pngkernel people could no longer drag an obsolete (2.6.21) kernel around just for xen, and decided to concentrate on helping get it into the mainstream kernel. This[4] has taken longer than expected."

Jan ONDREJ was also concerned[5] that, "KVM is still not a replacement for paravirtualized machines and I think fully virtualized KVM will be slower like a paravirtualized XEN."

Richard W.M. Jones countered[6] "KVM is a great replacement for Xen. It's much easier to use for a start -- no more rebooting into a completely separate kernel hypervisor. As long as you have the virtio drivers in the guest, which is the default for all new Linux distros, performance is roughly the same."

Apropos to the topic, but on another list, Mark McLoughlin explained[7] "Para-virtualization isn't always better. KVM uses full virtualization, meaning that it uses the processor's support for virtualization. This means you can run an unmodified guest OS on KVM. If you can modify the guest OS, then KVM does allow you to use paravirtualization for some performance sensitive operations - so e.g. we've got pvclock, pv MMU and virtio devices. Don't get tied up in marketing terminology - try both and decide for yourself which works best for you."

Support for dom0 is targeted[8] for kernel 2.6.29, but the changelogs[9] for the release candidates don't seem to indicate completion yet. Gerd Hoffmann confirmed[10] that "...most of the dom0 stuff missed the boat. Some prelimary stuff might be in though..." adding that "The pv_ops/dom0 kernel has some not-yet debugged storage issues (disk controller either fails after a while or doesn't work at all), which is the major stumbling block right now."

Daniel P. Berrange, of Red Hat Engineering, detailed the history of Xen on Fedora and explained "while it is definitely unfortunate that we don't have a Xen Dom0 kernel in Fedora 9/10, we are *not* trying to shaft anyone & will re-introduce Xen Dom0 kernels to Fedora when they become available." ... "It [is] still hard to say just when these will be accepted upstream, but there is a semi-reasonable [chance] we'll be able to turn Xen Dom0 back on in Fedora 11 kernels."[11]

Migrating Xen DomU to KVM Guest

Talk of the future of Xen on Fedora led to talk of migrating guests to KVM. Fortunately, migrating a virtual machine from Xen to KVM is straight forward. Well, more or less.

Richard W.M. Jones explained[1] "Install a recent Linux kernel in the guest, adjust the [libvirt] configuration file, and reboot." Alternatively, Package-x-generic-16.pngxenner will enable running "the Xen PV guest unchanged (ie. without installing a new guest kernel)."

  • Ensure the guest Package-x-generic-16.pngkernel is new enough to support virtio network drivers (kernel >= 2.6.25)
  • change the domain <type>, <os>, and <emulator> fields[2] - 'virsh edit <domname>'
  • "tell[3] the host to give the guest a virtio network card - change the NIC <model type='virtio'/>"

Richard finally noted[4] "For newly installed guests, recent anaconda just works everything out for you and puts the correct drivers into initrd." Mark McLoughlin provided the mkinitrd command to build the appropriate initrd in existing guests: 'mkinitrd --with virtio_pci --with virtio_blk -f /boot/initrd-$(kernelversion) $(kernelversion)' "You only need to do this once. After that, if a new kernel is installed while you're booted off a virtio disk, then mkinitrd will include the modules automatically."

Emre Erenoglu noted[5] "You will also need to specify /dev/vdX on the kernel root= line and make sure your init script inside your initrd triggers the virtio drivers at boot so that the /dev/vdX are created."

Mark McLoughlin added[6] a caveat. "the F9 x86_64 xen kernel didn't have support for running 32 bit binaries like grub, so the bootloader would never have been installed into the MBR. That works fine for pygrub, but not with KVM's real BIOS."

Also see this[7] guide to converting to virtio drivers.

Libvirt List

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

New Release libvirt 0.6.0

Daniel Veillard announced[1] a new Package-x-generic-16.pnglibvirt release, version 0.6.0.

Libvirt is a C toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes).

New features:

  • thread safety of the API and event handling (Daniel Berrange)
  • allow QEmu domains to survive daemon restart (Guido Gunther)
  • extended logging capabilities
  • support copy-on-write storage volumes (Daniel Berrange)
  • support of storage cache control options for QEmu/KVM (Daniel Berrange)

Improvements:

  • driver infrastructure and locking (Daniel Berrange)
  • Test driver infrastructure (Daniel Berrange)
  • parallelism in the daemon and associated config (Daniel Berrange)
  • virsh help cleanups (Jim Meyering)
  • logrotate daemon logs (Guido Gunther)
  • more regression tests (Jim Meyering)
  • QEmu SDL graphics (Itamar Heim)
  • add --version flag to daemon (Dave Allan)
  • memory consumption cleanup (Dave Allan)
  • QEmu pid file and XML states for daemon restart (Guido Gunther)
  • gnulib updates (Jim Meyering and Dan Berrange)
  • PCI passthrough for KVM (Jason Krieg)
  • generic internal thread API (Daniel Berrange)
  • RHEL-5 specific Xen configure option and code (Markus Armbruster)
  • save domain state as string in status file (Guido Gunther)
  • add locking to all API entry points (Daniel Berrange)
  • new ref counting APIs (Daniel Berrange)
  • IP address for Xen bridges (John Levon)
  • driver format for disk file types (Daniel Berrange)
  • improve QEmu/KVM tun/tap performances (Mark McLoughlin)
  • enable floppies for Xen fully virt (John Levon)
  • support VNC password settings for QEmu/KVM (Daniel Berrange)
  • qemu driver version reporting (Daniel Berrange)

There were also dozens of cleanups, documentation enhancements, portability and bug fixes.