From Fedora Project Wiki

< FWN
Revision as of 10:43, 14 April 2009 by Fab (talk | contribs) (added category)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Fedora Weekly News Issue 147

Welcome to Fedora Weekly News Issue 146 for the week ending October 12, 2008.

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

In this Canadian Thanksgiving[0] issue of FWN, Max Spevack announces the Fedora Unity's latest offerings of Fedora 9 re-spins, provides detail on James Laska's Fedora Test Day. and covers the goings on in the Fedora community blogosphere, with coverage of three contributions about the Red Hat Government Users and Developers Conference, and various tech tidbits around Fedora through the week. Svetoslav Chukov covers two stories in our marketing beat, including Intel linux developer work on building a modified Fedora install on an Asus EEE that boots in an amazing five seconds. Oisin Feeley again provides amazing coverage of Fedora development, including discussions of unsigned Rawhide packages as an attack vector, procedures for renaming Fedora packages, a discussion of the trash-cli package and its implications for generic naming issues, and much more. Jason Taylor brings us up to date with the documentation project, covering Fedora 10 release notes, and discussion of a possible fedora-wiki mailing list. Runa Bhattacharjee covers happenings in the translation team for us, discussing release note and documentation translation topics, and translations to the virt-* modules. Huzaifa Sidhpurwala covers the Infrastructure beat again for us, with a story on the infrastructure team's consolidation over the past few months and news of a new bapp class of servers that is under deployment. Nicu Buculei covers all of the great work going on in the Fedora Art team, and details the discussion of Fedora 10 CD/DVD sleeves this week. David Nalley details for us the Fedora 8 and 9 security advisories for the week, and Dale Bewley gets us current with the many happenings on the four virtualization lists he covers -- the Enterprise Management Tools, Fedora Xen, library virtualization and oVirt development lists, including stories on importing appliance raw disk images, support for F10 domU on RHEL5.2 dom0, support for KVM migration, amongst others.

If you are interested in contributing to Fedora Weekly News, please see our 'join' page[1].

FWN Editorial Team:

[0] http://en.wikipedia.org/wiki/Canadian_Thanksgiving

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

Announcements

In this section, we cover announcements from the Fedora Project.

http://www.redhat.com/archives/fedora-announce-list/

http://www.redhat.com/archives/fedora-devel-announce/

Contributing Writer: Max Spevack

New Fedora 9 Re-spins

Ben Williams announced[1] the availability of a new Fedora 9 re-spin. "The Fedora Unity Project is proud to announce the release of new ISO Re-Spins of Fedora 9. These Re-Spin ISOs are based on the officially released Fedora 8 installation media and include all updates released as of October 4th, 2008."

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

Fedora Test Day

James Laska announced[2] the next Fedora Test Day. "I'd like to invite testers and users to join #fedora-qa this Thursday, October 9, 2008. Testing efforts will focus[3] on gathering Fedora 10 Beta feedback and exercising GlitchFreeAudio (aka pulseaudio)."

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

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

Uberpackager Replaces Packager

Toshio Kuratomi explained[4] the changes to packager groups and ACLs. "The transition from a single packager group to an entry level packager group that can only commit to packages that the person owns and a separate uberpackager group that can commit to everything has been made." Additionally, "people in uberpackager should be able to commit to any package which is open to the uberpackager group. As part of the update, all packages which were previously opened to packager/cvsextras are now opened to uberpackager."

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

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: Max Spevack

Events

Several Fedora folks posted about the Red Hat Government Users and Developers Conference. Paul Frields posted[0] a few thoughts, as did[1] Eric Christensen and Dan Walsh[2].

[0] http://marilyn.frields.org:8080/~paul/wordpress/?p=1212

[1] http://fedora-sparks.blogspot.com/2008/10/red-hat-govt-users-and-developers.html

[2] http://danwalsh.livejournal.com/24935.html

Tech Tidbits

James Laska wrote[3] about the Anaconda and NetworkManager Fedora Test Day. "Our focus this round was exercising Anaconda NetworkManager integration in Fedora 10 Beta. In preparation for the day, David Cantrell pulled together several fixes for issues discovered since the beta was released."

[3] http://jlaska.livejournal.com/2257.html

Jeremy Katz posted[4] about updates to the initiative to get Fedora running on the XO. "So, you just got your XO to do some testing of Fedora on OLPC. You update the software that was on there, get a developer key, wait a day, and then get all ready to boot your Fedora image off of the SD card ....

And it boots. But it's slow. Very very slow. Some slowness is to be expected... this isn't a fast machine. But it should probably be a little bit speedier than it is. So want to try out a few experiments to try to help pin down the cause of the slowness? Then read on, pick a case and leave comments about your results."

[4] http://katzj.livejournal.com/440444.html

Karsten Wade wrote[5] about the Fedora 10 release notes. "If you don’t assign someone from your sub-project or SIG to cover that content, that area will be empty for the Fedora 10 Preview and possibly final releases.

Yep, it’s our job to remind you, edit, convert, get translated, package, and deliver. But only you can fill in the content that is missing. One thing we will do for you is hunt through your feature page and pull in any release notes content that you put there. But you have to put it there first, we cannot divine it."

Read the full post for a list of topics within Fedora that are falling behind in the release notes process, and help out if you would like to.

[5] http://iquaid.org/2008/10/06/your-release-notes-are-looking-thin/

Marketing

In this section, we cover the Fedora Marketing Project.

http://fedoraproject.org/wiki/Marketing

Contributing Writer: Svetoslav Chukov

Fedora's Community Attracts Experienced Users

A tale[1] of one user's experience migrating from SUSE 9 to Fedora. "I realized that Fedora is not simply a GNU/Linux distribution with great amount of software but something more than that. I would classify Fedora as combination of strong community, GNU/Linux distribution and great spirit. So, that was the best distro I would switch on. Because of the good support from the community I migrated so easily and avoiding problems."

[1] http://spreadfedora.org/sf/index.php?option=com_content&task=view&id=27&Itemid=40

Five Second Boot of a Modified Version of Fedora

As reported[1] in LWN.net, at the Linux Plumbers Developer Conference, two Linux developers at Intel demonstrated two different modified linux distributions booting in about five seconds on an 'Asus EeePC', one of which was a modified Fedora install. The article includes details on where the time savings were achieved throughout the boot process.

[1] http://lwn.net/Articles/299483/

Developments

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

Contributing Writer: Oisin Feeley

Unsigned Rawhide Packages an Attack Vector ?

Rahul Sundaram noticed[1] that when using PackageKit to obtain updates from the rawhide repository a warning for each package was displayed as they are all unsigned. He asked "[it] is just plain annoying. Can't we do something nice about that?"

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

The planets may have wobbled in their orbits when Ralf Corsepius responded[2] "IMO the 'only correct approach' would be to only have signed packages in rawhide" and Rahul agreed[3] completely "[m]any of us including me run rawhide for a large time of the Fedora development cycle, a security exploit in one of our machines via a bad rawhide mirror can result in malicious packages being pushed to stable repositories or other even worse issues. We should take this attack vector seriously." He asked if the reason was due to the time delay.

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

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

Josh Boyer confirmed[4] that time delay was the central problem and added "[...] the fact that we have a very limited number of people that know the signing key." Till Maas pointed[5] to the need for more developers to help Jesse Keating implement the Sigul[6] signing server that "[...] stores the signing keys within smartcards or something similar."

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

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

[6] https://fedorahosted.org/sigul

Richard Hughes suggested[7] that although PackageKit should simply abort any transaction involving an unsigned package it might be possible to add a configuration setting UnsignedPackages=abort|warn|allow to PackageKit.conf and asked for opinions on whether it was possible for "[u]pstream [to] set this to abort, and patch the package in rawhide to "allow" -- having F10 set to warn or abort[?]" In response to Denis Leroy's suggestion that such properties belonged to the repository rather than the package manager Richard agreed[8] that the policy would be implemented only if the repository declared itself as unsigned.

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

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

Procedure for Re-naming a Package

Two issues were raised[1] by Patrice Dumas in a post which initially asked for information on the formal procedure to rename a package and later explored the apparent lack of an active LaTeX and TeX community within the Fedora Project.

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

Patrice listed all the possible places on the wiki which should contain the information but failed to do so. Debarshi Ray remembered[2] a similar request on @fedora-packaging to which Tom Callaway had suggested: "[...] just open a ticket with Fedora Release Engineering (http://fedorahosted.org/rel-eng) and request the renaming of the package." A slightly different procedure was advanced[3] by Jesse Keating: "Renaming a package is just bringing in the new package, getting it reviewed, particularly for correct Provides/Obsoletes, and then requesting that the old named package be removed." Thorsten Leemhuis concurred[4] with this but pointed out that decisions made by FESCo had not been documented properly on the wiki.

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

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

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

The procedure appeared cumbersome to Patrice although Jesse argued[5] that a new review was useful in order to help diminish "[...] the vast number of improper Provides/Obsoletes I've ran across [.]" Patrice stuck to the idea that time spent "re-reviewing" the package would be better spent elsewhere. Specifically he worried[6] that not enough reviewers knowledgeable about TeX and LaTeX were active and able to keep pace with the "[...] rapid pace of changes linked with switching to texlive 2007 and now 2008 [.]" In response to interest from Matej Cepl he posted[7] a list of pending reviews.

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

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

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

Review of trash-cli Raises Generic Naming Issues

The maintainer of the putative trash-cli package, Jean-François Martin (lokthare), asked[1] whether any package reviewers were interested in examining trash-cli . The package implements the FreeDesktop.org trash specification via the command line. The package had been partially reviewed previously by Patrice Dumas who seemed generally supportive and interested but had expressed[2] unhappiness with the generic nature of one of the command names, trash, provided by the package . The other command names are: list-trash; empty-trash;restore-trash. Patrice had suggested to Jean-Francois that other reviewers might react more favorably but that it would be better to persuade upstream to change the names of the commands.

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

[2] https://bugzilla.redhat.com/show.bug.cgi?id=448122

This objection was re-iterated[3] by Michael Schwendt with the addition of the explanation that such names increased the chances of a namespace collision between current and future packages. Reference was made to existing generic naming of samba commands by Juha Tuomala and player[4] by Yanko Kaneti. Tim Niemuller argued that for the latter case the review had covered the naming problem and decided that adhering to upstream convention in the absence of present conflicts was the best policy as it allowed users to easily reproduce commands found elsewhere on the internet. A longish exchange followed in which Patrice argued[5] that upstreams should consider such issues more carefully and suggested[6] that individual distributions could follow Debian's example and override upstream naming choices when necessary. Tim put[7] the case for respecting upstream choices as long as there were no obvious current conflicts. His suggestion to use /etc/alternatives to resolve the problem was challenged[8] by Toshio Kuratomi as an inappropriate use.

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

[4] Player is part of a robot and sensor research system: http://playerstage.sourceforge.net/

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

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

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

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

Re-naming was considered[9] by Jean-Francois early on in the discussion and Rahul Sundaram recommended[10] alerting one of the FreeDesktop.org email lists to the change. Behdad Esfahbod suggested renaming all the commands to follow the pattern trash-* and was engaged[11] by the primary developer Andrea Francia in a discussion about why this might be preferable. Matt Miller wondered if it was a real problem and Andrea provided[12] a list of all the possible "trash" programs to show that none of them conflicted. Jesse Keating commented[13] that this was because "[...] all of them were smart enough to avoid falling into the generic trap." The bugzilla entry indicated[14] that upstream was going to rename the commands and the trash-cli commands will be available with the next release.

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

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

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

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

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

[14] https://bugzilla.redhat.com/show.bug.cgi?id=448122

PackageKit-gstreamer-plugins Obsoletes Codeina

Richard Hughes wondered[1] what he was doing wrong with the specfile for the PackageKit-gstreamer-plugins package. This package allows individual applications to call PackageKit to install[2] missing codecs.

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

[2] http://blogs.gnome.org/hughsie/2008/10/02/codec-install-in-fedora-10/

The bugzilla error filed[3] against the package reported that it conflicted with the codeina package[4], which was the previous method to install plugins for GStreamer aware applications. Richard wondered if a simple 

Obsoletes: codeina
Provides: codeina

would do the trick, but Paul Howarth cautioned[5] "[u]nversioned obsoletes are bad and should be avoided like the plague." Matej Cepl suggested[6] using the RPM name and version macros: 

Obsoletes: codeina < 0.10.1-10
Provides: codeina = %{version}-%{release}

[3] https://bugzilla.redhat.com/show.bug.cgi?id=465723

[4] http://fedoraproject.org/wiki/Multimedia/Codeina

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

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

Ville Skyttä wondered "[i]s the Provides: above appropriate in the first place, or should only the Obsoletes: be there? The only thing PackageKit-gstreamerplugin and codeina appear to have in common is /usr/libexec/gst-install-pluginshelper." Jesse Keating disputed[7] this but Villä explained[8] that "Dropping the Provides would mean that if something had a depdendency on codeina, that dep would be broken, and that pk-gstreamer-plugin couldn't be installed with "yum install codeina". I don't think it'd have any effect on whether pk-gstreamerplugin would/wouldn't be applied as an upgrade over installed codeina e.g. by yum (assuming the Obsoletes is left there)." He proved[9] his point with a practical example and this combined with James Antill's observation[10] seemed[11] convincing.

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

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

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

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

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

LXDE Feature Removal Disappointment - How to Avoid

Some possible problems with the package review process were raised when Christoph Wickert expressed[1] disappointment over the removal of his Lightweight X11 Desktop Environment (LXDE)[2] Feature from Fedora 10 without any apparent notification coming his way. The discussion was positive and restrained although Christoph was obviously upset. Christoph admitted that his feature was late but pleaded that he had followed the Feature Wrangler's advice and argued that the FESCo deliberations incorrectly assumed that most of his packages were unready. He requested an explanation of the concerns about breaking the string freeze as this was the other main reason for omitting LXDE from Fedora 10. Bill Nottingham explained that "Groups in comps (and their descriptions) are translatable strings; adding or changing them breaks the string freeze [...]" and added that "[t]he feature is supposed to be testable by the feature freeze, which is the same time as the string freeze." Christoph argued[3] that in that case he should have been informed earlier.

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

[2] https://fedoraproject.org/w/index.php?title=Features/LXDE#LXDE

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

Suggestions made[4][5] by Kevin Kofler to hack around the translation problem were rebutted[6] by Bill Nottingham as not following the string freeze policy and he also listed the uncompleted parts of the feature and wondered "[...] exactly what else is there to do when even the basic scope and test plan of the feature isn't ready?" Christoph responded[7] fully and explained that his outrage was because of a lack of communication from anyone and incorrect assumptions made during the FESCo deliberations. He thanked Bill for his feedback. Christoph contended that the necessary packages had in fact passed review contrary to an assumption that none of them had done so. The existence of this assumption was disputed[8] by Brian Pepple. Christoph explained that in addition he had waited fruitlessly for FESCo to give him permission to make changes to comps.

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

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

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

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

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

Toshio Kuratomi tried[9] to calm the discussion by avoiding assigning fault to any party. He suggested trading reviews with other people, explained that any maintainer can make changes to comps without waiting for FESCo and suggested some improvements to the communication process. Apparently MediaWiki handles watches differently to MoinMoin and this might explain some missed information. But Toshio disavowed some of the stronger assertions made by Christoph as "unfair" and reminded him "[t]he Feature Page shows that the feature is not done. Checking bugzilla shows that the page is up-to-date in regards to the package review status. Beta is a deadline for features and that has come and gone. So the Feature is plainly not completed whether you were contacted or not; whether the people who commented knew all the particulars or only some." Finally Toshio interpreted the lack of FESCo commentary to "[...] a bunch of polite people not jumping in to say 'Me too' [.]" This part of the discussion did not seem to go much further, but Nicolas Mailhot added[10] the interesting observation that "Comps is both central and under-regulated. You'll have a hard time finding who is supposed to approve comps policy, and the files themselves are wide open. However out of respect both for the people working on comps translations, and for the people working of comps consumers, I personally wouldn't make any deep restructuring such as new group creation after test1 (to give people time to react)."

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

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

Richard W. M. Jones supported[11] the idea that FESCo members were making decisions without reading the documentation or being interested in the topics and cited MinGW as another example. He suggested that FESCo members should volunteer to produces packages for MinGW. Josh Boyer dismissed[12] the accusations firmly and stated his own interest in MinGW and participation in the debate. The particular example of MinGW seemed ancillary to the central question and ended[13] in irascible disagreement when Richard re-iterated his request and accused FESCo members of lacking sufficient knowledge. The history of MinGW development has included[14] substantial disagreements due to the desire to[15] create a separate repository for it in opposition to Richard's wishes.

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

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

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

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

[15] https://fedoraproject.org/wiki/FWN/Issue142#MinGW.on.Fedora

Josh pointed to the finite amount of time FESCo board members have at their disposal: "If FESCo has to go and be an intimate part of a Feature in order for it to get approved or discussed, then that is what I would consider to be a very large failure. Reality dictates that the 9 people in FESCo do not have infinite time to do explicit things with every single Feature that gets presented. FESCo is a steering committee. We rely on you, the developers, to do your part for Features." Josh noted that other Fedora 10-approved Features had been dropped simply because of their owners failing to follow the process: "They were dropped later for nothing more than lack of following the Feature process. Not out of spite, or lack of interest, or some evil desire to promote only things that some Cabal cares about." Separately Josh explained[16] that although the advertising advantage of declaring LXDE a Fedora 10 Feature had been missed it did not mean Christoph's work was wasted.

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

While sympathetic to Christoph and extremely interested in LXDE Kevin Fenzi was[17] largely in agreement with Bill Nottingham and Josh Boyer that "[LXDE] was not testable by Beta, so it shouldn't be advertised as a feature this time. I'm sorry that that is due to communication problems. ;( I find it very unfortunate." He suggested that although there had been a string freeze it would be possible to make LXDE a Feature for Fedora 11. Christoph appeared[18] unhappy still but keen to move forward with these suggestions.

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

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

David Woodhouse expressed[19] regret at the lack of communication, sought further details to avoid such failures in the future and suggested "[o]ne thing we can do in future to make that situation better is Cc the feature owners when the meeting agenda is sent to fedora-devel-list." As a related matter he urged "[l]et's get the final two packages reviewed -- and that's another area where we could do with some improvement, because failing to approve packages really _is_ verging on the 'deletionism' you spoke of. But that's a separate discussion." He later proposed[20] "[...] that each FESCo member should try to work on at least one package review per week. Each week at the FESCo meeting, we'll ask members which reviews they've worked on in the past week [...] ad anyone else who considers themselves an active member of the Fedora development community should also try to do the same." The size of the review queue was cited by John Poelstra as 1,212 which surprised[21] Hans de Goede into suggesting review swapping as a solution: "[...] what we should be promoting much more is exchange reviews. Just post a mail to fedora-devel-list, saying I've got these and these packages which need review, and I'll gladly review any other package in return." Patrice Dumas analyzed[22] the situation slightly differently and noted that many of the review requests were blocked upon waiting for upstream changes. He thought that "[...] the ratio of review requests that nobody had a look at over the number of fedora contributors" would be a statistic which might indicate if there were a problem with a lack of reviewers.

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

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

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

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

Matters seemed to end amicably enough when Brian Pepple corrected[23] Christoph's assumption that FESCo meeting summaries were not being posted to @fedora-devel and this was accepted[24] with apologies by Christoph.

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

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

The positive note continued to be sounded when Chuck Anderson asked[25] for some practical advice on how he could help out with reviews and Christoph sought[26] information on how to find suitable outstanding reviews.

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

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

Documentation

In this section, we cover the Fedora Documentation Project.

http://fedoraproject.org/wiki/DocsProject

Contributing Writer: Jason Taylor

Fedora 10 Release Notes

This week marked the freeze time for the release notes for the Preview Release of Fedora 10. There was a lot of work done by the team in getting the notes updated, edited, converted to xml and ready for the translation team. It was a little late[1] due to lots of content and tooling changes but with the added time taken less updates will be needed for the final release.

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

Fedora Wiki Mailing List

There was conversation this week about the possibility of making a fedora-wiki mailing list[1]. Some of the reasons for making a wiki-centric list are that groups unrelated to documentation could ask questions but not have the documentation related information that the @fedora-docs-list generates to sort through and a forum for wiki questions that aren't related to documentation but Fedora Project usage of the wiki. After a series of replies supporting the creation of a wiki list, it looks like it will be implemented in the near future.

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

Translation

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

http://fedoraproject.org/wiki/L10N

Contributing Writer: Runa Bhattacharjee

Documentation Repository Updates

PaulFrields (stickster) announced[1] the updated repository information for Fedora Documentation. Submissions to the "master" branch for the documents is currently enabled[2] via https://translate.fedoraproject.org.

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

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

Release Notes .pot File Delayed

KarstenWade (quaid) announced[3] a day's delay in the Fedora 10 Release Notes .pot file, due to content changes and rewriting. The currently projected date and time for its availability is 0700 UTC 12 October '08.

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

Virt-* Modules Cannot Be Submitted Via Transifex

Translations for all the virt-* modules cannot be submitted[4] via https://translate.fedoraproject.org. The backend repository of these modules are currently hosted on hg.et.redhat.com, which is inaccessible[5] from Transifex. With the Fedora 10 translation deadline approaching fast, this issue is still unresolved.

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

[5] https://bugzilla.redhat.com/show_bug.cgi?id=435412

Infrastructure

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

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: Huzaifa Sidhpurwala

Some Architectural Changes

Mike McGrath wrote[1] on the @fedora-infrastructure-list that we have finally completed some consolidation we have been working on for the past couple of months. We have also added a new class of server (bappX servers). The bapp servers (there's only one right now) will be our job control servers.

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

Artwork

In this section, we cover the Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: Nicu Buculei

Fedora 10 CD/DVD Sleeves

Jarod Wen started to work on a set of CD and DVD sleeves for Fedora 10 "The style of the design follows the previous version used in Fedora 9. Most of the sources used in these design are from the source of Solar theme of Fedora 10" publishing a first draft[1] to @fedora-art. As first reactions, Ian Weller stressed[2] the importance of using the MgOpen Modata font "[...] as that's the font that Fedora uses for pretty much everything in their designs"

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

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

A concern about the number of colors was raised by Rahul Sundaram[3] "IIRC, the number of different colors shoots up the printing cost of the material drastically" and Paul Frields[4] "Make sure that the printing of the design is going to be a reasonable cost for the Ambassadors bulk-ordering the discs. If there are any sort of color restrictions, we should get those figured out up-front" but was cleared[5] by MairinDuffy "Actually you don't have to worry about this for the sleeves. It is only the disc designs themselves that are color-limited because of the screen printing process used to print them."

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

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

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

Another concern was raised by Mairin about the use of potentially tainted older version of the Solar theme "That is the old one, so you shouldn't use it. Please don't use any images from round 2, only round 3", a problem quickly corrected by Jarod in a second7] and third[8] drafts.

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

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

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

Also Paul proposed[4] the addition of an informative text "For Live CD, include a small bit of information about how to use the media: `This disc contains a complete bootable Fedora environment. To use it, make sure your computer supports booting from its CD or DVD drive. Then insert the disc, turn the computer's power on, and follow the prompts. If you enjoy this Fedora environment, you can copy it to your computer using the desktop 'Install to Hard Disk' icon. For further assistance, visit help.fedoraproject.org'". The proposal was followed[9] by a comparison between SUSE and Fedora sleeves from John Poelstra: "Here is an interesting comparison I noticed at OSCON this year after stopping by the SuSE booth [...] I realize there are differing philosophies as to how much or little content should be on the cover and what it should say :)" Nicu also offered[10] his opinion regarding this comparison "Maybe *I* am not the target audience[1], but I do not like the SUSE cover, its too busy, with so much text that is simply makes me to not read it. Only the 'Novell' word grab my attention, but not too much. It's boring and a 'corporate' look. I like how from the first look I can understand that the other disc is a DVD and is Fedora. "

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

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

Security Advisories

In this section, we cover Security Advisories from fedora-package-announce.

https://www.redhat.com/mailman/listinfo/fedora-package-announce

Contributing Writer: David Nalley

Fedora 9 Security Advisories

Fedora 8 Security Advisories

Virtualization

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

Contributing Writer: Dale Bewley

Enterprise Management Tools List

This section contains the discussion happening on the et-mgmt-tools list

Importing Appliance Raw Disk Images

Bryan Kearney cross-posted[1] an RFC to the @thincrust-devel[2] list. The goal being the ability to importing "appliance" disk images. Cole Robinson said[3], "the whole problem of taking an existing disk image and turning into something useful is not handled well by any of the virt-* tools", and wondered where best to add it. Daniel P. Berrange said[4], "the live cd installer class in virtinst can basically do 90% of the neccessary stuff already".

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

[2] http://www.thincrust.net/

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

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

Fedora Xen List

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

Support for F10 domU on RHEL5.2 dom0

Jon Stanley noticed[1] that a RHEL 5.2 dom0 was unable to install a current Fedora 10 Rawhide domU. Mark McLoughlin explained[2] that the "older virt-install doesn't know to look in the 'images-xen' stanza in the '.treeinfo' file to determine which images to use". Patches are being backported to RHEL 5.3 for this[3]. A further issue[4] is a lack of bzimage support in the libxc of RHEL.

[1] https://www.redhat.com/archives/fedora-xen/2008-October/msg00002.html

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

[3] https://bugzilla.redhat.com/460585

[4] https://bugzilla.redhat.com/457199

Michael Young asked[5] about a timeline for these patches and expressed concern that there could be "a period of time where there won't be any supported Redhat or Fedora platform to run Xen guests, and of course the lack of current support in RHEL is reducing the testing that Fedora 10 xen is getting."

[5] https://www.redhat.com/archives/fedora-xen/2008-October/msg00006.html

Libvirt List

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

KVM Domain Migration Not Yet Supported

Kenneth Nagin noticed[1] a problem migrating a KVM guest. Daniel P. Berrange said[2] that's because it's not yet supported. "Currently KVM's private fork of QEMU has some migration support, but this is not written in a suitable way for " libvirt "to use - it blocks the QEMU monitor on startup. Upstream QEMU is getting better migration support and once that's done we can support it in libvirt."

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

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

Disable QEMU Drive Cacheing

Daniel P. Berrange posted[1] a patch with the following explaination.

QEMU defaults to allowing the host OS to cache all disk I/O. This has a couple of problems

  • It is a waste of memory because the guest already caches I/O ops
  • It is unsafe on host OS crash - all unflushed guest I/O will be lost, and there's no ordering guarantees, so metadata updates could be flushed to disk, while the journal updates were not. Say goodbye to your filesystem.
  • It makes benchmarking more or less impossible / worthless because what the benchmark things are disk writes just sit around in memory so guest disk performance appears to exceed host diskperformance.

This patch disables caching on all QEMU guests. NB, Xen has long done this for both PV & HVM guests - QEMU only gained this ability when -drive was introduced, and sadly kept the default to unsafe cache=on settings.

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

NSIS Windows Installer in Nightly Builds

Richard W.M. Jones added[1] NSIS[2] support to generate a Windows installer in the nightly build. Richard also recently blogged[3] on the subject on MinGW and NSIS.

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

[2] http://nsis.sourceforge.net/

[3] http://camltastic.blogspot.com/2008/10/mingw-compile-software-for-windows.html

In reply to another thread[4] Daniel P. Berrange explained support is targeted for "client-mode only. ie, allow use of libvirt clients to connect to remote Linux hosts running libvirtd", and that there is no emminent Hyper-V or VMWare support.

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

Domain Events API Progress

Ben Guthro posted[1] patches to implement domain state transition events which were previously discussed[2].

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

[2] http://www.redhat.com/archives/libvir-list/2008-September/msg00321.html

oVirt Devel List

This section contains the discussion happening on the ovirt-devel list.

oVirt Qpid API

Ian Main continues to work[1] on a qpid API for oVirt which leverages the device enumeration[2] and qpid support[3] in libvirt. Ian extended the oVirt API to include network configuration information. Ian also posted[4] a demo script.

[1] https://www.redhat.com/archives/ovirt-devel/2008-October/msg00101.html

[2] https://fedoraproject.org/wiki/FWN/Issue146#Host_Device_Enumeration_API

[3] https://fedoraproject.org/wiki/FWN/Issue146#QPID_Modeling_Framework_and_libvirt-qpid

[4] https://www.redhat.com/archives/ovirt-devel/2008-October/msg00150.html

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