FWN/Issue171

From FedoraProject

< FWN(Difference between revisions)
Jump to: navigation, search
(fwn 171 all completed beats)
 
m (added category)
 
(7 intermediate revisions by 3 users not shown)
Line 34: Line 34:
 
Next<ref>http://www.redhat.com/archives/fedora-announce-list/2009-April/msg00004.html</ref>, Fedora 11 Snapshot 1 was released to the torrent site, and it provides "the first and final snapshot before our final devel freeze".  Jesse reminded everyone that "lots of work has gone into the storage code of Anaconda since the Beta release, please do re-test with these images if you had difficulty installing the Beta".
 
Next<ref>http://www.redhat.com/archives/fedora-announce-list/2009-April/msg00004.html</ref>, Fedora 11 Snapshot 1 was released to the torrent site, and it provides "the first and final snapshot before our final devel freeze".  Jesse reminded everyone that "lots of work has gone into the storage code of Anaconda since the Beta release, please do re-test with these images if you had difficulty installing the Beta".
  
'''The final development freeze<ref>http://www.redhat.com/archives/fedora-devel-announce/2009-April/msg00001.html</ref> for Fedora 11 is on Tuesday April 14th.'''  John Poelstra<ref>https://fedoraproject.org/wiki/JohnPoelstra</ref> reminded the community "that all features and their associated feature pages must be at 100% completion by this date", and he listed the features that do not meet this criteria, which includes several of the more prominent features that are scheduled for the release.  '''If you are trying to get a feature in to Fedora 11, please make sure you have completed all necessary steps.'''
+
'''The final development freeze<ref>http://www.redhat.com/archives/fedora-devel-announce/2009-April/msg00001.html</ref> for Fedora 11 is on Tuesday April 14th.'''  [[User:Poelstra|John Poelstra]] reminded<ref>http://www.redhat.com/archives/fedora-devel-announce/2009-April/msg00002.html</ref> the community "that all features and their associated feature pages must be at 100% completion by this date", and he listed the features that do not meet this criteria, which includes several of the more prominent features that are scheduled for the release.  '''If you are trying to get a feature in to Fedora 11, please make sure you have completed all necessary steps.'''
  
 
<references/>
 
<references/>
Line 91: Line 91:
  
 
Any Ambassador news tips from around the Fedora community can be submitted to me by e-mailing lcafiero-AT-fedoraproject-DOT-org and I'd be glad to put it in this weekly report.
 
Any Ambassador news tips from around the Fedora community can be submitted to me by e-mailing lcafiero-AT-fedoraproject-DOT-org and I'd be glad to put it in this weekly report.
 +
 +
{{Anchor|QualityAssurance}}
 +
== QualityAssurance ==
 +
 +
In this section, we cover the activities of the QA team<ref>http://fedoraproject.org/wiki/QA</ref>.
 +
 +
Contributing Writer: [[User:Adamwill|Adam Williamson]]
 +
 +
<references/>
 +
 +
=== Test Days ===
 +
 +
This week's Test Day<ref>https://fedoraproject.org/wiki/Test_Day:Radeon_2009-04-09</ref> was on UEFI<ref>https://fedoraproject.org/wiki/Features/EFI</ref>, the modern BIOS replacement technology which sees increased support in Fedora 11. which has seen substantial changes for Fedora 11. This was mostly an 'internal' test day, as hardware support UEFI is not yet widely available.
 +
 +
Next week is currently planned to have two Test Days. The first will be a follow up to the earlier Anaconda storage rewrite Test Day<ref>https://fedoraproject.org/wiki/QA/Test_Days/2009-03-05</ref>, to check how progress on Anaconda's storage code rewrite is going and whether the significant issues reported at the earlier Test Day have been addressed. The second will be on the Presto plugin for yum<ref>https://fedoraproject.org/wiki/Features/Presto</ref>, which adds support for deltarpms - incrementally diffed packages. This is planned to be a new feature of Fedora 11 if it works well enough, so please come out to help test it. This feature is of particular interest to those with slower internet connections, or bandwidth restrictions.
 +
 +
<references/>
 +
 +
=== Weekly meetings ===
 +
 +
The QA group weekly meeting<ref>http://fedoraproject.org/wiki/QA/Meetings</ref> was held on 2009-04-08. The full log is available<ref>http://www.happyassassin.net/extras/fedora-qa-20090408.log</ref>[[User:jkeating|Jesse Keating]] reported good progress with the autoqa project: a post-tree-compose monitor has been written, meaning autoqa is now run automatically when a new Rawhide tree is created. [[User:Jlaska|James Laska]] mentioned that autoqa results are currently being sent to a mailing list<ref>https://fedorahosted.org/pipermail/autoqa-results/2009-April/thread.html</ref>. [[User:Wwoods|Will Woods]] mapped out some potential future improvements in the reporting of results. Jesse noted that a major next step will be doing automatic tests following the builds of packages through Koji, to give immediate feedback on issues to maintainers.
 +
 +
[[User:Adamwill|Adam Williamson]] reported that, as requested at last week's meeting, he had filed a bug on the issue with creating live USB images for Fedora 11 trees from Fedora 10. It had been closed as a duplicate, and the original bug subsequently marked as closed in Rawhide. The group concurred that it didn't make sense to say an issue that mostly affected Fedora 10 was fixed in Rawhide, so Adam has posted a further comment to the bug asking for clarification.
 +
 +
[[User:Jlaska|James Laska]] said he had checked in with [[User:Wtogami| Warren Togami]] about the new blog<ref>http://rawhidewatch.wordpress.com/</ref> he had created to monitor issues in Rawhide. Warren said that it is intended to be a low traffic blog that includes imformation on non-obvious (potentially high-impact) problems affecting rawhide users. Submissions can be made to Warren for posting on the blog.
 +
 +
[[User:Jlaska|James Laska]] reported that he has not yet been able to discuss the integration of lab-in-a-box and autoqa with [[User:Wwoods|Will Woods]]. He clarified that the idea is to make it possible to do fully automated installation, testing and reporting of test results on Rawhide within a virtualized guest system.
 +
 +
The group discussed the state of play with regards to Fedora 11's final release, particularly whether all appropriate bugs are marked as F11Blocker or F11Target. Members of the group are encouraged to help make sure that all sufficiently important issues are marked as blocking one or the other, and non-serious issues are taken off the F11Blocker list so development resources can be directed appropriately to the most important issues. Everyone agreed that a special meeting should be held soon to work on these lists, and it would be best to involve as many members of the QA and Bugzappers communities as possible.
 +
 +
[[User:Jlaska|James Laska]] committed to working on a simple system for customization of Test Day Live CD images with useful links and information for the particular Test Day for which they are built.
 +
 +
The Bugzappers group weekly meeting<ref>http://fedoraproject.org/wiki/BugZappers/Meetings</ref> was held on 2009-04-07. The full log is available<ref>http://fedoraproject.org/wiki/BugZappers/Meetings/Minutes-2009-Apr-07</ref>. The group thanked [[User:Beland|Christopher Beland]] for his excellent work on the new How to Triage page draft<ref>https://fedoraproject.org/wiki/User:Beland/How_to_Triage</ref>, and discussed further revisions to it. It was agreed that checking for upstream reports when triaging bugs should not be mandatory, but recommended. There was a long discussion on whether triagers should be required to follow up on bugs they set to NEEDINFO state, or whether a separate group of triagers should be responsible for following up NEEDINFO bugs. Eventually it was agreed that front-line triagers should be encouraged to follow up themselves, but a regular sweep could also be made by other Bugzappers to catch bugs in NEEDINFO state that were not being followed up. No agreement was made on whether bugs in NEEDINFO state should be closed after 30 days of inactivity, or 60.
 +
 +
Brennan Ashton (comphappy) reported that his Bugzappers metric reporting system is in the process of moving to the Fedora infrastructure, and a beta site should be available in the next few days. He expects the site to be usable by next week, and requests feedback at that time. The group agreed to aim for a 'production' release by May 6th.
 +
 +
[[User:Adamwill|Adam Williamson]] reported that he is drafting an email to devel-list to solicit developer input on the use of the priority and severity fields in Bugzilla, and he will send this draft to test-list for the group's approval before sending it to devel-list.
 +
 +
The next QA weekly meeting will be held on 2009-04-15 at 1600 UTC in #fedora-meeting, and the next Bugzappers weekly meeting on 2009-04-14 at 1500 UTC in #fedora-meeting.
 +
 +
<references/>
 +
 +
=== Triage Day ===
 +
 +
A successful Triage Day<ref>https://fedoraproject.org/wiki/BugZappers/Triage_days</ref> was held on 2009-04-07 following the weekly Bugzappers meeting. [[User:Adamwill|Adam Williamson]] and [[User:Tk009|Edward Kirk]] helped to train two new triagers, Haase Niels (arxs) and Scott Glaser (Sonar_Guy).
 +
 +
<references/>
 +
 +
=== DeviceKit testing  ===
 +
 +
[[MatthiasClasen|Matthias Clasen]] notified the QA group<ref>http://www.redhat.com/archives/fedora-test-list/2009-April/msg00447.html</ref> that a new version of DeviceKit, which should fix several bugs reported during the previously held Test Day, had landed in Rawhide, and suggested that those who had encountered issues on the Test Day should re-test with the new code.
 +
 +
<references/>
 +
 +
=== Triage Days on the Wiki ===
 +
 +
[[User:Adamwill|Adam Williamson]] apologized for the delay, and announced <ref>https://www.redhat.com/archives/fedora-test-list/2009-March/msg01129.html</ref> that a Triage Day page was now available on the Wiki, explaining the existence and function of the Bugzappers group's weekly Triage Day.
 +
 +
<references/>
 +
 +
=== Fedora 11 Blocker bugs review ===
 +
 +
Further to the discussion in the meeting, [[User:Adamwill|Adam Williamson]] requested<ref>http://www.redhat.com/archives/fedora-test-list/2009-April/msg00544.html</ref> the group's help in reviewing the list of blocker bugs for Fedora 11 release.
 +
 +
<references/>
 +
 +
=== Graphics card Test Day metrics ===
 +
 +
[[User:Adamwill|Adam Williamson]] explained<ref>https://www.redhat.com/archives/fedora-test-list/2009-April/msg00549.html</ref> that he had generated metrics for bug reports from the graphics card Test Days, and posted them to his blog<ref>http://www.happyassassin.net/2009/04/08/test-day-metrics/</ref>.
 +
 +
<references/>
 +
 
{{Anchor|Developments}}
 
{{Anchor|Developments}}
 
== Developments ==
 
== Developments ==
Line 106: Line 178:
  
 
[[TomLane|TomLane]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00572.html</ref> what was going on with <code>glibc</code> reverting to an earlier version in rawhide. [[User:Jkeating|Jesse Keating]] responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00573.html</ref> that <code>glibc</code> for the <code>i586</code> architecture was broken for all versions after beta. After [[PanuMatilainen|Panu Matilainen]] commented that <code>glibc.i586</code> was so broken that <code>rpm</code> could not even read its own configurations [[UlrichDrepper|Ulrich Drepper]] said<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00600.html</ref>: "If you want to complain then to the idiots who made the decision to go with .i586 instead of .i686 for x86 binaries.  This is exactly the kind of problem I've been warning about all along.  Using the i586 target stresses code paths (in this case in gcc) which are hardly ever used since nobody cares for this target in general." Panu disavowed any intent to complain.
 
[[TomLane|TomLane]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00572.html</ref> what was going on with <code>glibc</code> reverting to an earlier version in rawhide. [[User:Jkeating|Jesse Keating]] responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00573.html</ref> that <code>glibc</code> for the <code>i586</code> architecture was broken for all versions after beta. After [[PanuMatilainen|Panu Matilainen]] commented that <code>glibc.i586</code> was so broken that <code>rpm</code> could not even read its own configurations [[UlrichDrepper|Ulrich Drepper]] said<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00600.html</ref>: "If you want to complain then to the idiots who made the decision to go with .i586 instead of .i686 for x86 binaries.  This is exactly the kind of problem I've been warning about all along.  Using the i586 target stresses code paths (in this case in gcc) which are hardly ever used since nobody cares for this target in general." Panu disavowed any intent to complain.
 +
 +
<references/>
  
 
=== Wireless Regulatory Domain Automatically Determined ===
 
=== Wireless Regulatory Domain Automatically Determined ===
  
 
[[User:Linville|John W. Linville]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00566.html</ref> an update to an old(ish) thread. He reported that <code>Fedora 11</code> now has <code>udev</code> rules in place to set wireless regulatory domains based on the configured timezone.
 
[[User:Linville|John W. Linville]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00566.html</ref> an update to an old(ish) thread. He reported that <code>Fedora 11</code> now has <code>udev</code> rules in place to set wireless regulatory domains based on the configured timezone.
 +
 +
<references/>
  
 
=== Moonlight Still Banned in Fedora ===
 
=== Moonlight Still Banned in Fedora ===
  
The 2009-04-08 "Rawhide Report"<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00426.html</ref> caused some excitement when it seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00427.html</ref> that <code>moonlight</code><ref>Moonlight is an implementation<ref>http://mono-project.com/Moonlight</ref> of Microsoft's "Silverlight" which is a virtual machine and framework for creating Rich Internet Applications, roughly competing in the same space as Adobe's Flex<ref>http://www.adobe.com/products/flex/</ref> and Mozilla's Prism<ref>http://labs.mozilla.com/projects/prism/</ref>. It is considered<ref>http://fedoraproject.org/wiki/ForbiddenItems#Moonlight</ref> to risky to include in Fedora due to legal worries raised by the Microsoft-Novell covenant.  </ref> might have been enabled. It turned out<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00500.html</ref> that this was simply due to a confusion between a <code>mono</code> API named "moonlight" and the actual <code>moonlight</code> itself.
+
The 2009-04-08 "Rawhide Report"<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00426.html</ref> caused some excitement when it seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00427.html</ref> that <code>moonlight</code><ref>Moonlight is an implementation of Microsoft's "Silverlight" which is a virtual machine and framework for creating Rich Internet Applications, roughly competing in the same space as Adobe's Flex and Mozilla's Prism. It is considered too risky to include in Fedora due to legal worries raised by the Microsoft-Novell covenant.  </ref><ref>http://mono-project.com/Moonlight</ref><ref>http://www.adobe.com/products/flex/</ref><ref>http://labs.mozilla.com/projects/prism/</ref><ref>http://fedoraproject.org/wiki/ForbiddenItems#Moonlight</ref> might have been enabled. It turned out<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00500.html</ref> that this was simply due to a confusion between a <code>mono</code> API named "moonlight" and the actual <code>moonlight</code> itself.
  
 
All that had actually happened<ref>http://bugzilla.redhat.com/show_bug.cgi?id=492048</ref> was that Fedora Legal okayed the use of the mono compiler switch "moonlight" in order to facilitate RPMFusion's request.
 
All that had actually happened<ref>http://bugzilla.redhat.com/show_bug.cgi?id=492048</ref> was that Fedora Legal okayed the use of the mono compiler switch "moonlight" in order to facilitate RPMFusion's request.
 +
 +
<references/>
  
 
=== Mono Breakage on PPC May Cause Reversion ===
 
=== Mono Breakage on PPC May Cause Reversion ===
Line 127: Line 205:
 
[[User:Mef|Mary Ellen Foster]] requested, as a mono-dependent maintainer, that concrete actions be recommended. [[User:Jkeating|Jesse Keating]] and [[User:Toshio|Toshio Kuratomi]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00568.html</ref> that all such did _not_ set "ExcludeArch: ppc" and rebuild as this would cause massive churn on a large number of packages. Instead a process to track down the failures and fix them with a fallback plan to revert to a mono release-candidate was proposed by Toshio.   
 
[[User:Mef|Mary Ellen Foster]] requested, as a mono-dependent maintainer, that concrete actions be recommended. [[User:Jkeating|Jesse Keating]] and [[User:Toshio|Toshio Kuratomi]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00568.html</ref> that all such did _not_ set "ExcludeArch: ppc" and rebuild as this would cause massive churn on a large number of packages. Instead a process to track down the failures and fix them with a fallback plan to revert to a mono release-candidate was proposed by Toshio.   
  
 +
<references/>
  
 
=== YUM Downgrade Feature Now in Rawhide ===
 
=== YUM Downgrade Feature Now in Rawhide ===
Line 134: Line 213:
  
 
He suggested: "[...]this will be most useful for rawhide users when installing test packages from koji static repos. etc. ... because then an older version will still be available in rawhide. Whereas if you upgrade to what is in rawhide there is nothing older available to downgrade to."  
 
He suggested: "[...]this will be most useful for rawhide users when installing test packages from koji static repos. etc. ... because then an older version will still be available in rawhide. Whereas if you upgrade to what is in rawhide there is nothing older available to downgrade to."  
 +
 +
<references/>
  
 
=== Multiple Package Ownership of Directories ===
 
=== Multiple Package Ownership of Directories ===
Line 140: Line 221:
  
 
[[User:Mschwendt|Michael Schwendt]] and [[User:Cwickert|Christoph Wickert]] were<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00544.html</ref> clear that the packages Rahul mentioned should not own the directory because they were part of a dependency chain which led up to their ancestor package <code>hicolor-icon-theme</code>. Contrary advice led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00546.html</ref> to some sarcasm from [[User:Cwickert|Christoph Wickert]] about Red Hat employees not being familiar with Fedora packaging guidelines and it worried<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00591.html</ref> [[User:Peter|Peter Lemenkov]], who believed that Red Hat employees all had "provenpackager" status (see FWN#170<ref>http://fedoraproject.org/wiki/FWN/Issue170#Provenpackager_Policies</ref>). [[User:Tibbs|Jason L. Tibbitts III]] corrected<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00595.html</ref> this latter assertion.
 
[[User:Mschwendt|Michael Schwendt]] and [[User:Cwickert|Christoph Wickert]] were<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00544.html</ref> clear that the packages Rahul mentioned should not own the directory because they were part of a dependency chain which led up to their ancestor package <code>hicolor-icon-theme</code>. Contrary advice led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00546.html</ref> to some sarcasm from [[User:Cwickert|Christoph Wickert]] about Red Hat employees not being familiar with Fedora packaging guidelines and it worried<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00591.html</ref> [[User:Peter|Peter Lemenkov]], who believed that Red Hat employees all had "provenpackager" status (see FWN#170<ref>http://fedoraproject.org/wiki/FWN/Issue170#Provenpackager_Policies</ref>). [[User:Tibbs|Jason L. Tibbitts III]] corrected<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00595.html</ref> this latter assertion.
 +
 +
<references/>
  
 
=== Zap DontZap ===
 
=== Zap DontZap ===
Line 152: Line 235:
  
 
Dissent and discussion about Fedora's decision to follow the upstream rumbled on. [[User:Kkofler|Kevin Kofler]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00617.html</ref> that "mailing list consensus" was not a good process by which to make such decisions as that taken by Xorg.  [[DaveAirlie|Dave Airlie]] seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00635.html</ref> as though he had had enough of personal attacks on him, but was also able to joke about it.
 
Dissent and discussion about Fedora's decision to follow the upstream rumbled on. [[User:Kkofler|Kevin Kofler]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00617.html</ref> that "mailing list consensus" was not a good process by which to make such decisions as that taken by Xorg.  [[DaveAirlie|Dave Airlie]] seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00635.html</ref> as though he had had enough of personal attacks on him, but was also able to joke about it.
 +
 +
<references/>
 +
 
{{Anchor|Translation}}
 
{{Anchor|Translation}}
 +
 
== Translation ==
 
== Translation ==
  
Line 165: Line 252:
 
After the announcement last week<ref>http://www.redhat.com/archives/fedora-trans-list/2009-April/msg00028.html</ref> about the availability of the Fedora 11 Preview Release Notes for translation, a number of translators have put forward their concerns about the  difficulty in translating these notes due to vast coverage of content and complicated technical text<ref>http://www.redhat.com/archives/fedora-trans-list/2009-April/msg00089.html</ref>.  
 
After the announcement last week<ref>http://www.redhat.com/archives/fedora-trans-list/2009-April/msg00028.html</ref> about the availability of the Fedora 11 Preview Release Notes for translation, a number of translators have put forward their concerns about the  difficulty in translating these notes due to vast coverage of content and complicated technical text<ref>http://www.redhat.com/archives/fedora-trans-list/2009-April/msg00089.html</ref>.  
  
As a solution to this, it has been suggested that the Release Notes be restricted to information that is important to general users and useful to migration from on release to another. The additional information about package improvements etc. may be made part of the SIG pages on the wiki.<ref>http://www.redhat.com/archives/fedora-trans-list/2009-April/msg00090.html</ref>
+
As a solution to this, it has been suggested that the Release Notes be restricted to information that is important to general users and useful to migration from one release to another. The additional information about package improvements etc. may be made part of the SIG pages on the wiki.<ref>http://www.redhat.com/archives/fedora-trans-list/2009-April/msg00090.html</ref>
  
 
One of the writers [[User:Rlandmann | Ruediger Landmann]], has put forward the link to the draft version of Fedora 11 Installation Guide for similar feedback.<ref>http://www.redhat.com/archives/fedora-trans-list/2009-April/msg00091.html</ref>
 
One of the writers [[User:Rlandmann | Ruediger Landmann]], has put forward the link to the draft version of Fedora 11 Installation Guide for similar feedback.<ref>http://www.redhat.com/archives/fedora-trans-list/2009-April/msg00091.html</ref>
Line 349: Line 436:
  
 
<references />
 
<references />
 +
 +
[[Category:News]]

Latest revision as of 10:30, 14 April 2009

Contents

[edit] Fedora Weekly News Issue 171

Welcome to Fedora Weekly News Issue 171 for the week ending April 12th, 2009.

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

Our latest issue includes important Announcements about Fedora 11 and freeze statuses. Ambassadors celebrates the way "Italians Fete Document Freedom Day" and "LinuxFest Northwest Ramps Up". Developments relays some fraught conversations about "Emacs, Glibc, Malloc and i586" and cautions that "Mono Breakage on PPC May Cause Reversion". Translations keys us in to the "Fedora 11 Release Notes Discussion". Artwork provides insight into "Finishing the Artwork for Fedora 11". Virtualization reports on the "Virtualization Technology Preview Repo."

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

  1. http://fedoraproject.org/wiki/NewsProject/Join

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

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

https://fedoraproject.org/wiki/Events

Contributing Writer: Max Spevack

[edit] Fedora 11

Jesse Keating[1] made two announcements regarding Fedora 11.

First[2], the F11-Beta-x86_64-Live-KDE.iso was re-issued on bittorrent as well as to the mirors. The image was "accidentally composed with 32bit packages instead of 64bit packages". Furthermore, the Source ISOs were re-issued on torrent only, where "an older set were first issued there. The CHECKSUM on the mirrors was wrong as well for these isos and has been updated."

Next[3], Fedora 11 Snapshot 1 was released to the torrent site, and it provides "the first and final snapshot before our final devel freeze". Jesse reminded everyone that "lots of work has gone into the storage code of Anaconda since the Beta release, please do re-test with these images if you had difficulty installing the Beta".

The final development freeze[4] for Fedora 11 is on Tuesday April 14th. John Poelstra reminded[5] the community "that all features and their associated feature pages must be at 100% completion by this date", and he listed the features that do not meet this criteria, which includes several of the more prominent features that are scheduled for the release. If you are trying to get a feature in to Fedora 11, please make sure you have completed all necessary steps.

  1. https://fedoraproject.org/wiki/JesseKeating
  2. http://www.redhat.com/archives/fedora-announce-list/2009-April/msg00003.html
  3. http://www.redhat.com/archives/fedora-announce-list/2009-April/msg00004.html
  4. http://www.redhat.com/archives/fedora-devel-announce/2009-April/msg00001.html
  5. http://www.redhat.com/archives/fedora-devel-announce/2009-April/msg00002.html

[edit] FUDCon Berlin 2009

Max Spevack[1] reminded[2] the community about FUDCon Berlin 2009[3], including registration[4], lodging[5], and the speaking schedule[6].

  1. https://fedoraproject.org/wiki/MaxSpevack
  2. http://spevack.livejournal.com/78732.html
  3. https://fedoraproject.org/wiki/FUDCon:Berlin_2009
  4. https://fedoraproject.org/wiki/FUDCon:Berlin_2009_attendees
  5. https://fedoraproject.org/wiki/FUDCon:Berlin_2009_lodging
  6. http://fedoraproject.org/wiki/FUDCon_Berlin_and_LinuxTag_2009_talks

[edit] Upcoming Events

April 15: NYLUG[1] in New York, New York, USA.

April 17-19: Summer Geek Camp 2[2] in Antipolo City, Phillipines.

April 18: BarCamp Rochester[3] in Rochester, New York, USA.

April 19-22: Red Hat EMEA Partner Summit[4] in Malta.

April 24-25: FLISOL, all over the LATAM region.

April 25: Trenton Computer Festival[5] in Trenton, New Jersey, USA.

April 25-26: Linux Fest Northwest[6] in Bellingham, Wasthington, USA.

  1. http://nylug.org/
  2. http://fedora.bluepoint.com.ph/index.php?entry=20090204000843
  3. http://barcamprochester.org/
  4. https://fedoraproject.org/wiki/Red_Hat_EMEA_Partner_Summit_2009
  5. http://tcf-nj.org/
  6. https://fedoraproject.org/wiki/LinuxFest_Northwest_%28LFNW%29_2009

[edit] Ambassadors

In this section, we cover Fedora Ambassadors Project.

http://fedoraproject.org/wiki/Ambassadors

Contributing Writer: Larry Cafiero

[edit] Italians Fete Document Freedom Day

"Document Freedom Day," an event promoted by the Free Software Foundation, was held March 25 and aimed is to spread free documents formats and the Free Software culture. Luca Foppiano reports about his attendance at the event, which was held in Opera (near Milano, where in 2008 was organized "Liberamente") in his blog[1].

Luca spoke at the event about the core values of the Fedora project, whose aim is to spread the meaning of the 4 foundations in general, and Fedora’s policies around codecs and firmwares in particular - thus covering a wider subject matter, not only documents.

[edit] LinuxFest Northwest Ramps Up

A Fedora Activity Day and three Fedora speakers highlight the lineup for the 10th annual LinuxFest Northwest[2] in Bellingham, Wash., USA, on April 25-26. Held on the campus of Bellingham Technical College, the two-day event is free and open to the public.

Clint Savage will be hosting a session on Fedora Remix, Karsten Wade will talk on the topic "Participate or Die," Jesse Keating will give those at LFNW a sneak peek at Fedora 11 and what to expect later next month, and Larry Cafiero will give a Fedora 101 talk prior to the Fedora Activity Day, which takes place all day Saturday.

Prior to LFNW, Karsten Wade and Larry Cafiero are scheduled to address classes at Oregon State University in Corvallis, Ore., on behalf of Fedora on Thursday, April 23. The pair will also meet with the Linux Users Group on campus that evening.

Bellingham is just south of the Canadian border in northwestern Washington, and if you find yourself in the neighborhood, feel free to drop by.

  1. http://blog.foppiano.org/2009/03/30/document-freedom-day/
  2. http://www.lfnw.org

[edit] Got Ambassador News?

Any Ambassador news tips from around the Fedora community can be submitted to me by e-mailing lcafiero-AT-fedoraproject-DOT-org and I'd be glad to put it in this weekly report.

[edit] QualityAssurance

In this section, we cover the activities of the QA team[1].

Contributing Writer: Adam Williamson

  1. http://fedoraproject.org/wiki/QA

[edit] Test Days

This week's Test Day[1] was on UEFI[2], the modern BIOS replacement technology which sees increased support in Fedora 11. which has seen substantial changes for Fedora 11. This was mostly an 'internal' test day, as hardware support UEFI is not yet widely available.

Next week is currently planned to have two Test Days. The first will be a follow up to the earlier Anaconda storage rewrite Test Day[3], to check how progress on Anaconda's storage code rewrite is going and whether the significant issues reported at the earlier Test Day have been addressed. The second will be on the Presto plugin for yum[4], which adds support for deltarpms - incrementally diffed packages. This is planned to be a new feature of Fedora 11 if it works well enough, so please come out to help test it. This feature is of particular interest to those with slower internet connections, or bandwidth restrictions.

  1. https://fedoraproject.org/wiki/Test_Day:Radeon_2009-04-09
  2. https://fedoraproject.org/wiki/Features/EFI
  3. https://fedoraproject.org/wiki/QA/Test_Days/2009-03-05
  4. https://fedoraproject.org/wiki/Features/Presto

[edit] Weekly meetings

The QA group weekly meeting[1] was held on 2009-04-08. The full log is available[2]Jesse Keating reported good progress with the autoqa project: a post-tree-compose monitor has been written, meaning autoqa is now run automatically when a new Rawhide tree is created. James Laska mentioned that autoqa results are currently being sent to a mailing list[3]. Will Woods mapped out some potential future improvements in the reporting of results. Jesse noted that a major next step will be doing automatic tests following the builds of packages through Koji, to give immediate feedback on issues to maintainers.

Adam Williamson reported that, as requested at last week's meeting, he had filed a bug on the issue with creating live USB images for Fedora 11 trees from Fedora 10. It had been closed as a duplicate, and the original bug subsequently marked as closed in Rawhide. The group concurred that it didn't make sense to say an issue that mostly affected Fedora 10 was fixed in Rawhide, so Adam has posted a further comment to the bug asking for clarification.

James Laska said he had checked in with Warren Togami about the new blog[4] he had created to monitor issues in Rawhide. Warren said that it is intended to be a low traffic blog that includes imformation on non-obvious (potentially high-impact) problems affecting rawhide users. Submissions can be made to Warren for posting on the blog.

James Laska reported that he has not yet been able to discuss the integration of lab-in-a-box and autoqa with Will Woods. He clarified that the idea is to make it possible to do fully automated installation, testing and reporting of test results on Rawhide within a virtualized guest system.

The group discussed the state of play with regards to Fedora 11's final release, particularly whether all appropriate bugs are marked as F11Blocker or F11Target. Members of the group are encouraged to help make sure that all sufficiently important issues are marked as blocking one or the other, and non-serious issues are taken off the F11Blocker list so development resources can be directed appropriately to the most important issues. Everyone agreed that a special meeting should be held soon to work on these lists, and it would be best to involve as many members of the QA and Bugzappers communities as possible.

James Laska committed to working on a simple system for customization of Test Day Live CD images with useful links and information for the particular Test Day for which they are built.

The Bugzappers group weekly meeting[5] was held on 2009-04-07. The full log is available[6]. The group thanked Christopher Beland for his excellent work on the new How to Triage page draft[7], and discussed further revisions to it. It was agreed that checking for upstream reports when triaging bugs should not be mandatory, but recommended. There was a long discussion on whether triagers should be required to follow up on bugs they set to NEEDINFO state, or whether a separate group of triagers should be responsible for following up NEEDINFO bugs. Eventually it was agreed that front-line triagers should be encouraged to follow up themselves, but a regular sweep could also be made by other Bugzappers to catch bugs in NEEDINFO state that were not being followed up. No agreement was made on whether bugs in NEEDINFO state should be closed after 30 days of inactivity, or 60.

Brennan Ashton (comphappy) reported that his Bugzappers metric reporting system is in the process of moving to the Fedora infrastructure, and a beta site should be available in the next few days. He expects the site to be usable by next week, and requests feedback at that time. The group agreed to aim for a 'production' release by May 6th.

Adam Williamson reported that he is drafting an email to devel-list to solicit developer input on the use of the priority and severity fields in Bugzilla, and he will send this draft to test-list for the group's approval before sending it to devel-list.

The next QA weekly meeting will be held on 2009-04-15 at 1600 UTC in #fedora-meeting, and the next Bugzappers weekly meeting on 2009-04-14 at 1500 UTC in #fedora-meeting.

  1. http://fedoraproject.org/wiki/QA/Meetings
  2. http://www.happyassassin.net/extras/fedora-qa-20090408.log
  3. https://fedorahosted.org/pipermail/autoqa-results/2009-April/thread.html
  4. http://rawhidewatch.wordpress.com/
  5. http://fedoraproject.org/wiki/BugZappers/Meetings
  6. http://fedoraproject.org/wiki/BugZappers/Meetings/Minutes-2009-Apr-07
  7. https://fedoraproject.org/wiki/User:Beland/How_to_Triage

[edit] Triage Day

A successful Triage Day[1] was held on 2009-04-07 following the weekly Bugzappers meeting. Adam Williamson and Edward Kirk helped to train two new triagers, Haase Niels (arxs) and Scott Glaser (Sonar_Guy).

  1. https://fedoraproject.org/wiki/BugZappers/Triage_days

[edit] DeviceKit testing

Matthias Clasen notified the QA group[1] that a new version of DeviceKit, which should fix several bugs reported during the previously held Test Day, had landed in Rawhide, and suggested that those who had encountered issues on the Test Day should re-test with the new code.

  1. http://www.redhat.com/archives/fedora-test-list/2009-April/msg00447.html

[edit] Triage Days on the Wiki

Adam Williamson apologized for the delay, and announced [1] that a Triage Day page was now available on the Wiki, explaining the existence and function of the Bugzappers group's weekly Triage Day.

  1. https://www.redhat.com/archives/fedora-test-list/2009-March/msg01129.html

[edit] Fedora 11 Blocker bugs review

Further to the discussion in the meeting, Adam Williamson requested[1] the group's help in reviewing the list of blocker bugs for Fedora 11 release.

  1. http://www.redhat.com/archives/fedora-test-list/2009-April/msg00544.html

[edit] Graphics card Test Day metrics

Adam Williamson explained[1] that he had generated metrics for bug reports from the graphics card Test Days, and posted them to his blog[2].

  1. https://www.redhat.com/archives/fedora-test-list/2009-April/msg00549.html
  2. http://www.happyassassin.net/2009/04/08/test-day-metrics/

[edit] Developments

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

Contributing Writer: Oisin Feeley

[edit] Emacs, Glibc, Malloc and i586

As the pressure to stick to the Fedora 11 release schedule built up some glitches arising in part from the decision to support i586 instead of i686 (see FWN#162[1]) led to tense words.

Reports trickled in of problems with emacs in rawhide. Per Bothner reported[2] both that emacs-23.0.91 threw an "Invalid regex: Unmatched ( or \\(" and that emacs-23-0.92 was responding excruciatingly slowly. Ulrich Drepper speculated[3] to that the regexp problem was due to some changes to malloc in glibc. A bugzilla report by Andy Wingo expanded[4] on the problem and drew comments suggesting that rpm and mysql were also failing to due glibc changes. Jakub Jelinek thought they were different problems with the emacs errors being due to malloc_{get|set}_state.

TomLane asked[5] what was going on with glibc reverting to an earlier version in rawhide. Jesse Keating responded[6] that glibc for the i586 architecture was broken for all versions after beta. After Panu Matilainen commented that glibc.i586 was so broken that rpm could not even read its own configurations Ulrich Drepper said[7]: "If you want to complain then to the idiots who made the decision to go with .i586 instead of .i686 for x86 binaries. This is exactly the kind of problem I've been warning about all along. Using the i586 target stresses code paths (in this case in gcc) which are hardly ever used since nobody cares for this target in general." Panu disavowed any intent to complain.

  1. http://fedoraproject.org/wiki/FWN/Issue162#Fedora_11_Will_Support_i586_Instruction_Set
  2. http://www.redhat.com/archives/fedora-test-list/2009-April/msg00221.html
  3. http://www.redhat.com/archives/fedora-test-list/2009-April/msg00225.html
  4. http://bugzilla.redhat.com/show_bug.cgi?id=494631
  5. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00572.html
  6. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00573.html
  7. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00600.html

[edit] Wireless Regulatory Domain Automatically Determined

John W. Linville posted[1] an update to an old(ish) thread. He reported that Fedora 11 now has udev rules in place to set wireless regulatory domains based on the configured timezone.

  1. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00566.html

[edit] Moonlight Still Banned in Fedora

The 2009-04-08 "Rawhide Report"[1] caused some excitement when it seemed[2] that moonlight[3][4][5][6][7] might have been enabled. It turned out[8] that this was simply due to a confusion between a mono API named "moonlight" and the actual moonlight itself.

All that had actually happened[9] was that Fedora Legal okayed the use of the mono compiler switch "moonlight" in order to facilitate RPMFusion's request.

  1. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00426.html
  2. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00427.html
  3. Moonlight is an implementation of Microsoft's "Silverlight" which is a virtual machine and framework for creating Rich Internet Applications, roughly competing in the same space as Adobe's Flex and Mozilla's Prism. It is considered too risky to include in Fedora due to legal worries raised by the Microsoft-Novell covenant.
  4. http://mono-project.com/Moonlight
  5. http://www.adobe.com/products/flex/
  6. http://labs.mozilla.com/projects/prism/
  7. http://fedoraproject.org/wiki/ForbiddenItems#Moonlight
  8. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00500.html
  9. http://bugzilla.redhat.com/show_bug.cgi?id=492048

[edit] Mono Breakage on PPC May Cause Reversion

Another mono issue discussed[1] with reference to the 2009-04-08 Rawhide Report suggests that due to breakage on the ppc architecture it may be necessary to untag the latest mono package.

Objections that the disabling of PPC architecture support on the mono package was happening too close to the Fedora 11 final freeze prompted[2] David Nielsen to make the rejoinder that no help had been given to the Mono SIG despite their reporting a problem. Jesse Keating announced[3] that in the absence of a fix before the final freeze mono would simply be downgraded: "[t]his kind of version change shouldn't really be made after beta anyway."

David Nielsen argued[4] that the changes had been made well before the beta. Bill Nottingham thrust[5] the responsibility back on him. Alex Lancaster made[6] a similar point more diplomatically.

Mary Ellen Foster requested, as a mono-dependent maintainer, that concrete actions be recommended. Jesse Keating and Toshio Kuratomi asked[7] that all such did _not_ set "ExcludeArch: ppc" and rebuild as this would cause massive churn on a large number of packages. Instead a process to track down the failures and fix them with a fallback plan to revert to a mono release-candidate was proposed by Toshio.

  1. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00457.html
  2. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00471.html
  3. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00483.html
  4. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00501.html
  5. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00515.html
  6. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00524.html
  7. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00568.html

[edit] YUM Downgrade Feature Now in Rawhide

James Antill posted[1] that it is now possible to downgrade a package using

yum downgrade <packagename>

He suggested: "[...]this will be most useful for rawhide users when installing test packages from koji static repos. etc. ... because then an older version will still be available in rawhide. Whereas if you upgrade to what is in rawhide there is nothing older available to downgrade to."

  1. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00469.html

[edit] Multiple Package Ownership of Directories

A query posed[1] by Rahul Sundaram concerned whether it was appropriate for multiple packages to claim ownership of a directory.

Michael Schwendt and Christoph Wickert were[2] clear that the packages Rahul mentioned should not own the directory because they were part of a dependency chain which led up to their ancestor package hicolor-icon-theme. Contrary advice led[3] to some sarcasm from Christoph Wickert about Red Hat employees not being familiar with Fedora packaging guidelines and it worried[4] Peter Lemenkov, who believed that Red Hat employees all had "provenpackager" status (see FWN#170[5]). Jason L. Tibbitts III corrected[6] this latter assertion.

  1. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00425.html
  2. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00544.html
  3. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00546.html
  4. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00591.html
  5. http://fedoraproject.org/wiki/FWN/Issue170#Provenpackager_Policies
  6. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00595.html

[edit] Zap DontZap

Paul Wouters reported[1] that he had needed to ssh into his machine to fix an X session problem and would like to revert "[...] to the old behavior of having ctrl-alt-backspace kill the current X session." See FWN#169[2] for earlier discussion.

Anders Rayner-Karlsson explained that dual-head setup in Fedora 10 was as simple as:

xrandr --output LVDS --auto --output VGA --auto --above LVDS

to which Michael Cronenworth responded[3] that this would need to be done in a start-up script as there was also now no xorg.conf by default. Jesse Keating suggested using the system-config-display tool instead as this would obviate the need for an xorg.conf. Adam Jackson cautioned[4] that nVidia's proprietary drivers might not export RANDR-1.2 yet and thus the latter might not work. Further discussions about whether xorg.conf was needed for side-by-side wide virtual desktops suggested[5] that Intel chipsets while currently enforcing a 2048 pixel limit may be[6] capable of supporting up to 4096 pixels on Intel 915 or Intel 945 in the near future.

Dissent and discussion about Fedora's decision to follow the upstream rumbled on. Kevin Kofler suggested[7] that "mailing list consensus" was not a good process by which to make such decisions as that taken by Xorg. Dave Airlie seemed[8] as though he had had enough of personal attacks on him, but was also able to joke about it.

  1. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00363.html
  2. http://fedoraproject.org/wiki/FWN/Issue169#Emacs_Cabal_Disables_Xorg_Ctrl-Alt-Backspace
  3. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00371.html
  4. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00377.html
  5. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00430.html
  6. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00450.html
  7. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00617.html
  8. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00635.html

[edit] Translation

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

http://fedoraproject.org/wiki/L10N

Contributing Writer: Runa Bhattacharjee

[edit] Fedora 11 Release Notes Discussion

After the announcement last week[1] about the availability of the Fedora 11 Preview Release Notes for translation, a number of translators have put forward their concerns about the difficulty in translating these notes due to vast coverage of content and complicated technical text[2].

As a solution to this, it has been suggested that the Release Notes be restricted to information that is important to general users and useful to migration from one release to another. The additional information about package improvements etc. may be made part of the SIG pages on the wiki.[3]

One of the writers Ruediger Landmann, has put forward the link to the draft version of Fedora 11 Installation Guide for similar feedback.[4]

At present, some of the teams have chosen to either translate the core information, divide the translation work amongst multiple translators or to drop translation for this release.

  1. http://www.redhat.com/archives/fedora-trans-list/2009-April/msg00028.html
  2. http://www.redhat.com/archives/fedora-trans-list/2009-April/msg00089.html
  3. http://www.redhat.com/archives/fedora-trans-list/2009-April/msg00090.html
  4. http://www.redhat.com/archives/fedora-trans-list/2009-April/msg00091.html

[edit] New Members/Co-ordinators in FLP

David Leary[1] has joined the French translation team last week.

  1. http://www.redhat.com/archives/fedora-trans-list/2009-April/msg00071.html

[edit] Artwork

In this section, we cover the Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: Nicu Buculei

[edit] Finishing the Artwork for Fedora 11

John Poelstra asked [1] on @fedora-art about the lesson learned and the need for a special feedback period embedded in future release cycles "Maybe we should build a feedback period into the Fedora 12 schedule?" and the status of the remaining work for Fedora 11 "It is also important to note that we are targeting the completion of final artwork and packaging a little less than two weeks from now on 2009-04-16 so that it can all be in the Preview Release and have two weeks to shake out anything that needs final fixing before GA", with Paul W. Frields reinforcing[2] the question "How can we improve the schedule of dates for Artwork deliverables, so that they're more realistic or constructive?"

In reply, Nicu Buculei pleaded[3] for early, on-going feedback "I don't think we need a feedback period, we need to get some graphics (concepts) as soon as possible to get feedback from the early stages. Is not useful if one week before the freeze we learn that everything is not good enough, we have to scrap it and restart."

Appreciating the reminder[4] "Thank you for this reminder and for helping keep us on track", Máirí­n Duffy outlined a list of the remaining tasks: Wallpaper Design, Plymouth Splash, GNOME splash, KDE splash, full screen splash for syslinux, grub splash. gnome screensaver lock dialog, anaconda square splash, firstboot vertical header, kdm, wallpaper extras and she set a deadline[5] on the wallpaper polishing "I'm going to block off Thursday as the day to dive in and polish stuff off".

Nicu Buculei and Martin Sourada took one of the points, the wallpaper extras, further[6][7] and concluded "freeze is irrelevant here. It's highly probable it won't be on any of the official spins, so having the package released at the same day as GA is IMHO fine"

Charles Brej advanced a Plymouth animation proposal[8] "here is a possible progress bar in the style of the theme", followed by another minimalist proposal[9] from Mike Langlie, acclaimed by some[10][11] but also criticised by its use of proprietary tools under proprietary operating systems (Photoshop on OS X)[12]. A third mock-up[13] from Cătălin Feştilă is dismissed by Nicu Buculei for the use of English-only text " Fedora is an operating system for the entire world, we can't go with an English-only text. Due to localization concerns, is wise to avoid any texts rendered as graphics."

Also in preparation for the upcoming Preview Release and the General Release, Paolo Leoni posted[14] a release countdown banner, which evolved quickly with the feedback received into a complete, polished tarball[15], ready to run on the website.

Susmit Shannigrahi advanced a DVD label concept[16], criticised by Luya Tshimbalanga for the use of an obsolete theme[17] "Note that artwork used for Fedora 11 Beta is not final" an Nicu Buculei for excessive use of colors[18] "to keep the printing cost down ideally the label will use only a few colors". Apparently, according to Susmit, in his country the price is not affected by the number of colors used[19] "Well, here in India, they don't charge by color. They charge at a flat rate of 11INR(22 cents) each for bulk production."

  1. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00044.html
  2. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00068.html
  3. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00075.html
  4. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00080.html
  5. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00081.html
  6. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00087.html
  7. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00096.html
  8. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00092.html
  9. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00093.html
  10. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00094.html
  11. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00101.html
  12. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00110.html
  13. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00113.html
  14. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00047.html
  15. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00095.html
  16. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00052.html
  17. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00054.html
  18. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00055.html
  19. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00060.html

[edit] Interview with the Art Team

In the previous edition of the Fedora Weekly News we reported about an interview with the Fedora Art Team being conducted for the Linux Graphics Users forum[1], now Nicu Buculei reported[2] on@fedora-art about the interview going live[3].

  1. http://linuxgraphicsusers.com/
  2. http://www.redhat.com/archives/fedora-art-list/2009-April/msg00111.html
  3. http://linuxgraphicsusers.com/index.php?topic=705.msg5198

[edit] Virtualization

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

Contributing Writer: Dale Bewley


[edit] Fedora Virtualization List

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

[edit] Guest Configuration with augeas and libguestfs

After blogging[1] just last week that "Nothing much is coded at the moment", the prolific Richard Jones announced[2] he has added support to Package-x-generic-16.pngaugeas for his latest project, libguestfs[3]. libguestfs "lets you examine and modify virtual machine disk images, so you can perform sysadmin tasks on virtual machines without needing to bring them up or log into them."

"Augeas is a configuration editing tool. It parses configuration files in their native formats and transforms them into a tree. Configuration changes are made by manipulating this tree and saving it back into native config files."[4] Now libguestfs "supports Augeas, so you can use Augeas to edit configuration files within the virtual machine."

Richard will be working on creating a Fedora RPM of libguestfs this week.

  1. http://rwmj.wordpress.com/2009/04/01/libguestfs-access-and-modify-virtual-machine-disk-images/
  2. http://www.redhat.com/archives/fedora-virt/2009-April/msg00045.html
  3. http://et.redhat.com/~rjones/libguestfs/
  4. http://augeas.net/

[edit] Virtual Machine Backup virt-backup

The discussion of libguestfs led Jan ONDREJ to reveal[1] a tool in development, virt-backup[2].

This script can be used to

  • Make online backups, when virtual server is running.
  • Transfer partitions over the network while the virtual server is off.
  1. http://www.redhat.com/archives/fedora-virt/2009-April/msg00068.html
  2. http://www.salstar.sk/pub/temp/virt-backup

[edit] Virtualization Technology Preview Repo

Daniel Berrange followed up the recent release scheduling conversation (FWN#169 [1]) with a "braindump"[2].

"The obvious problem with what we do for Package-x-generic-16.pnglibvirt at the moment, is that we are introducing major new features into the stable release stream". Adding "I think it would be desirable to get the stable Fedora releases onto a pretty strong bugfix only policy..."

Daniel suggested "a 'virt-preview' YUM repository for the most recent stable stream (ie F10, but not F9)" as a way to achieve this "bugfix only policy", and allow users access development versions of libvirt "without having to include & debug the rest of rawhide". Daniel summaried the "braindump".

"So in summary":

  • All new upstream releases built in rawhide
  • New upstream releases also built in stable preview branch if possible
  • Only bugfixes built in stable updates/updates-testing branch
  • In exceptional circumstances, rebase for preview branch can be built to updates/updates-testing after alot of positive testing

"This would":

  • Ensure users of stable Fedora release have high confidence in quality of the updates/updates-testing stream
  • Allow users to trivially test new upstream rebases while staying on the stable distro stream
  • Improve testing coverage of major new rawhide features without using the stable release stream users as guinea pigs

Mark McLoughlin thought[3] "this would be hugely useful to people interested in the latest virt bits, but without a testing machine for running rawhide." And even proposed a name for the proposed repository, "How about 'virt-hide' ? :)". Mark also reverenced these FESCo approved guidelines[4] relevant to package maintainers who wish to update a package on an already-released branch.

  1. http://fedoraproject.org/wiki/FWN/Issue169#More_Formal_libvirt_Release_Scheduling
  2. http://www.redhat.com/archives/fedora-virt/2009-April/msg00008.html
  3. http://www.redhat.com/archives/fedora-virt/2009-April/msg00010.html
  4. http://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines

[edit] Fedora Virtualization Status Report

Mark McLoughlin reminds[1] us "It's only a matter of days until the F11 tree freezes and the list of bugs isn't getting any shorter!"

Read on for more coverage of virtualization developments in the past week.

  1. http://www.redhat.com/archives/fedora-virt/2009-April/msg00055.html


[edit] Libvirt List

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

[edit] libvirt-TCK Technology Compatibility Kit

In yet another "braindump" this week, Daniel Berrange penned[1] "a very long email" purporting to be a "short guide" to the new Package-x-generic-16.pnglibvirt "Technology Compatibility Kit".

libvirt provides a hypervisor or emulator neutral platform for manipulating virtual machine resources. This model leverages "drivers"[2] for each emulator or backend system. The driver acts as a translator, converting libvirt API calls to the native API. For example, there are drivers for Xen, QEMU KVM, LXC, OpenVZ, User Mode Linux, and storage subsystems.

"The libvirt TCK provides a framework for performing testing of the integration between libvirt drivers, the underlying virt hypervisor technology, related operating system services and system configuration. The idea (and name) is motivated by the Java TCK"

"In particular the libvirt TCK is intended to address the following scenarios

  • Validate that a new libvirt driver is in compliance with the (possibly undocumented!) driver API semantics
  • Validate that an update to an existing driver does not change the API semantics in a non-compliant manner
  • Validate that a new hypervisor release is still providing compatability with the corresponding libvirt driver usage
  • Validate that an OS distro deployment consisting of a hypervisor and libvirt release is configured correctly

Thus the libvirt TCK will allow developers, administrators and users to determine the level of compatability of their platform, and evaluate whether it will meet their needs, and get awareness of any regressions that may have occurred since a previous test run."

The TCK will utilize Perl's testing frameworks and the libvirt Perl binding Package-x-generic-16.pngperl-Sys-Virt (FWN#169[3]).

Daniel created "4 simple proof of concept scripts" which have already "highlighted some horrible problems" in remote, QEMU, and Xen drivers. There are even some results "in pretty HTML format":

Daniel goes on to describe how to try out the test suite, talk about what's still left todo, describe how TCK is expected to be used, and provide an introduction to writing tests.

  1. http://www.redhat.com/archives/libvir-list/2009-April/msg00176.html
  2. http://libvirt.org/drivers.html
  3. http://fedoraproject.org/wiki/FWN/Issue169#New_Release_perl-Sys-Virt_0.2.0