From FedoraProject

Revision as of 10:25, 14 April 2009 by Fab (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Fedora Weekly News Issue 88

Welcome to Fedora Weekly News Issue 88[1] for the week of May 13th through May 19th, 2007. The latest issue can always be found here[2] and RSS Feed can be found here[3] .

[1] http://fedoraproject.org/wiki/FWN/Issue88

[2] http://fedoraproject.org/wiki/FWN/LatestIssue

[3] http://feeds.feedburner.com/fwn


In this section, we cover announcements from various projects.

Deep Freeze coming for Fedora 7

JesseKeating announces in fedora-maintainers[1] ,

"We're planning on entering "Deep Freeze" this Thursday. From that point on we'll only be accepting build tag requests for builds that are fixing release blockers. See Fedora Release Criteria[2] for current release criteria."

[1] https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00351.html

[2] http://fedoraproject.org/wiki/QA/ReleaseCriteria

Announcing fedora-cs-list for Czech and Slovak Fedora users

MarekMahut announces in fedora-ambassadors-list[1] ,

"Let me introduce you our new mailing list [2] for Czech and Slovak Fedora users. If you are speaking one of those languages, feel free to join."

[1] https://www.redhat.com/archives/fedora-ambassadors-list/2007-May/msg00104.html

[2] http://www.redhat.com/mailman/listinfo/fedora-cs-list

Fedora Rawhide Live Images (20070517)

JeremyKatz announces in fedora-test-list[1] ,

"First set of post-merge rawhide live images. These are based off of yesterday's rawhide (packages tagged f7-final in koji).

You can get the torrent file from Fedora Project Torrent[2] . Available images are i386, x86_64, i386 KDE and also an x86_64 KDE image. Note that the x86_64 images require DVD media, the i386 images will fit on 700 meg CD media. Please file any issues against product Fedora Core, version devel and against the relevant component or LiveCD if you're unsure."

[1] https://www.redhat.com/archives/fedora-test-list/2007-May/msg00558.html

[2] http://torrent.fedoraproject.org.

Planet Fedora

In this section, we cover a highlight of Planet Fedora - an aggregation of blogs from world wide Fedora contributors.


Summary from the Red Hat Summit

ChristopherBlizzard points out in his blog[1] ,

"We announced a pile of things at the Red Hat Summit[2] . Lots of confusing articles have been written. Lots of press releases have been sent out filled with warnings about forward looking statements. Maybe you just want the run down on all the things that happened. This is your simple cheat sheet. Here’s the list:.."

[1] http://www.0xdeadbeef.com/weblog/?p=289

[2] http://www.redhat.com/promo/summit/2007/news/

F7 Firstboot and EULA

MaxSpevack points out in his blog[1] ,

"In an attempt to have some transparency and no surprises, I've sent an email[2] to Fedora Advisory Board that details some of the changes we've made to firstboot and the EULA in Fedora 7. My personal opinion is that the changes are good for Fedora, and also relatively innocuous."

[1] http://spevack.livejournal.com/16260.html

[2] https://www.redhat.com/archives/fedora-advisory-board/2007-May/msg00111.html

'Play Ogg': FSF launches free audio format campaign

ThomasChung points out in his blog[1]

"The Free Software Foundation (FSF)[2] today launched PlayOgg.org[3] , a campaign to encourage use of the patent- and license-free standard Ogg Vorbis as an ethically, legally and technically superior audio alternative to the proprietary MP3 format."

[1] http://fedora-tchung.blogspot.com/2007/05/play-ogg-fsf-launches-free-audio-format.html

[2] http://www.fsf.org/news/playogg.html

[3] http://playogg.org/


In this section, we cover Fedora Marketing Project.


OLPC on CBS 60 Minutes

ThomasChung reports in fedora-marketing-list[1] ,

"CBS 60 Minutes[2] will air OLPC[3] story on Sunday, May 20, 2007 (7PM ET/PT)"

"ONE LAPTOP PER CHILD – MIT Prof. Nicholas Negroponte's dream is to put a laptop computer into the hands of every child as an educational aid. Lesley Stahl reports on his progress in Cambodia and Brazil. Catherine Olian is the producer."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-May/msg00057.html

[2] http://www.cbsnews.com/stories/1998/07/08/60minutes/main13502.shtml

[3] http://fedoraproject.org/wiki/OLPC

UPDATE: The video is now available from CBS News Video archive[1] . You may need to install Real Player[2] .

Here is the transcript for the entire show[3] . You may need to click on 'Print' button from main page.

[1] http://www.cbsnews.com/sections/i_video/main500251.shtml?id=2830221n

[2] http://www.real.com/linux

[3] http://www.cbsnews.com/stories/2007/05/20/60minutes/printable2830058.shtml


In this section, we cover the problems/solutions, people/personalities, and ups/downs of the endless discussions on Fedora Developments.


New Suspend Quirks Functionality of F7 Explained

A "heads up" was announced by RichardHughes with regard to the changes in power management and HAL for Fedora 7, which would probably affect suspension [1] . Richard summarised the implications as "Some machines that suspended in FC6 might not work in F7; Lots of machines that did not suspend in FC6 might work in F7".

[1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01065.html

These changes are as a result of trying to make suspend and resume Just Work by using a modular hal-info DMI whitelist which is being updated regularly.

Explaining this on a separate page [2] Richard noted that the ability to share specific rules for specific hardware allows one user to figure out the "quirks" and then share the appropriate rule with other users that have the exact same hardware.

[2] http://people.freedesktop.org/~hughsient/temp/quirk/quirk-intro.html

This page explains how to see what quirks exist for your laptop, and how to help in creating an fdi file to share with other users.

JefSpaleta wanted to know [3] at what point this had all happened so that he could investigate the actual effect that it had on his machines. PeterJones was able to answer very specifically [4] that the code had entered the tree on March 13, but had some problems until April 25th (pm-utils-0.99.2-1, hal-0.5.9-0.git20070304).

[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01071.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01090.html

In further testing Jef was isolated an unwanted interaction between NetworkManager and gnome-power-manager which RichardHughes and PeterJones agreed could be easily eliminated [5] .

[5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01203.html

ThorstenLeemhuis suggested [6] that Richard's webpage for gathering user data should also ask about the proprietary ATI driver "fglrx" and that it should solicit information as to whether the user selected a plain vga console or a framebuffer, both of which suggestions Richard willingly incorporated.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01123.html

XChat Package Maintenance: First Post-Merge Co-Maintenance?

A discussion was initiated, by an apparently testy [1] KevinKofler, around the apparent radio-silence of XChat-maintainer ChristopherAillon to Kevin's bug reports, which asked for X-Chat to be kept in sync with upstream. Kevin was willing to become co-maintainer, but pointed out [1a] that a lot of good work had already been done by RemiCollet. Kevin wondered if the AWOL-maintainers policy [1b] would be applied post-merge.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01201.html

[1a] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01208.html

[1b] http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers

A few things transpired from this: first, Chrisopher noted that the upstream Xch at developers are apparently unresponsive [3] to patches; second, that Xchat-gnome may have responsive upstream developers [4] .

[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01204.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01210.html

Additionally WarrenTogami noted [5] that there are problems with XChat's ability to use multilinugal input methods such as SCIM or IM [6] .

[5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01206.html

[6] http://www.scim-im.org/

A brief exchange over the respective merits of Xchat-gnome [7] versus Xchat [8] saw both groups of believers unshaken in their faith, although CallumLerwick revealed himself as an apostate heretic user of Irssi.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01222.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01207.html

The upshot of all this was that RemiCollet expressed interest [9] in being a co-maintainer and wondered if this could be a paradigm for The Merge.

[9] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01226.html

PowerTOP Release Opens Up New Directions In Power Saving

Reporting on his work on decreasing power wastage on laptops, ArjanvandeVen (ex-Red Hat, now Intel) suggested that we might want to try [1] his new tool that allows individual analysis of power consumption.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00796.html

JoshBoyer was excited enough to want to package it [2] , but AdamJackson (ajax) had already done that.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00799.html

After DominikMierzejewski (Rathann) and "Dragoran" reported a lack of functional ity on AMD64 and x86_64 (Intel Core 2 Duo) repectively, JesseBarnes pointed out [3] that x86_64 tickless support in the kernel is an essential pre-requisite and this is not yet available in the rawhide kernels, necessitating a manual patch by anyone interested.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00838.html

DavidTimms wanted to know [4] if it would help in finding out what was causing disk-accesses. Arjan replied that this was a frequent request which he was going to attempt to accomodate in the next version, possibly using blktrace. BillNottingham cautioned [5] that blktrace was not currently shipped in Fedora.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00811.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00932.html

ThorstenLeemhuis followed up [6] on DavidTimms' question with some general queries about how Fedora, and more specifically gnome-power-manager, handles spinning down inactive hard-drives. Thorsten remembered RichardHughes' 2005 attempts to get a patch into HAL to allow similar functionality to that which WinXP was alleged to have.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00818.html

Richard answered [7] that Fedora does not currently spin down drives by default and that one had to balance a significantly increased spin-up power drain compared to that saved by spinning down.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00820.html

Thorsten wondered [7a] whether or not the new Robson/TurboMemory and hybrid drives would change that equation.

[7a] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00822.html

JonathanUnderwood shifted the focus [8] to considering drive longevity, worrying that attempts to save power by spinning up-and-down would shorten drive life. Richard agreed, and AndyGreen provided some figures [9] which suggested that laptop drives (2.5") could be power spun 6 times per hour, whereas server (3.5") drives could only do 1 times per hour if one estimated a 5 year lifespan.

[8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00850.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00861.html

TomLondon posted some early observations [10] , in which PowerTOP revealed that if Firefox were displaying GMail there were about 60 wakeups-per-second, but that activating the "Gmail Talk" pushed the rate to 300 wakeups-per-second. NicolasMailhot responded that this was AJAX at work.

[10] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00826.html

MartinSourada was puzzled [11] by what appeared to be an unnaturally low power usage of 1.2W reported by PowerTOP, compared to an expected 16W reported by the /proc subsystem. JonBurgess explained that what was being reported was "present rate" in milliamperes (e.g. current) and showed how to calculate the power in Watts from that. TillMaas thought [12] that some notebooks actually reported the present rate in mW instead of mA.

[11] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00831.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00835.html

In a discussion of the packaging PatriceDumas suggested that the spec file be modified to preserve timestamps. AdamJackson wondered why [13] and ThorstenLeemhuis answered that it was necessary for multilib [14] and would make things easier for presto. MatthiasClasen agreed with DavidWoodhouse that including timestamps in file identity tests was not a good idea [15] . MichaelSchwendt and "nodata" thought that in contrast that it was nice to know when a file was several years old especially for documentation and scripts [16] . AdamJackson (ajax) said [17] that it wasn't a multilib package, but "sure why not".

[13] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01011.html

[14] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01017.html

[15] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01018.html

[16] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01025.html

[17] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01024.html

Massive size increase in some packages

The eagle eyed OrionPoplawski maintains python-numarray, and in the course of rebuilding the package from its Fedora Extras 6 version to Fedora 7 spotted [1] that the size had increased by an order of magnitude. He also noted that a subsequent rebuild now, produced packages of a normal size. Further investigation revealed by Orion suggested that this was due to the shared libraries, and a comparison of FE6 to FE-devel turned up some other candidates which had increased in size by at least a factor of two.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01161.html

The first possible culprit was guessed to be debug symbols by BillNottingham who asked [2] whether debug packages had been turned off for these builds, but Orion reported that he'd just done a straightforward rebuild.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01164.html

Orion posted an objdump [3] which showed that although the shared-object files appeared to have been stripped, the large one was possibly including the whole of the libpython shared-object instead of linking it dynamically at runtime, which might explain the bloat. A diff of the two objdumps appeared to also show different glibc versions [4] .

[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01168.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01170.html

One conclusion drawn from this [5] was that all non-arch python packages built within the timeframe of Dec 8th 2006 to Jan 6th 2007, (or prior to python-2.5.3-8) should be rebuilt. Another conclusion was drawn by AxelThimm, who revisited [6] the mass-rebuild debate (reported in FWN84 [7] ,[8] ) and argued that this backed up his viewpoint that mass rebuilds were useful.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01171.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01174.html

[7] http://fedoraproject.org/wiki/FWN/Issue84

[8] http://fedoraproject.org/wiki/FWN/Issue85

Rawhide Report 17 May 2007:Liberated Fonts, Corrupt Metadata

On Thursday 17th May 2007, the rawhide report [1] listed 5 new packages: gsm, kde-settings, liberation-fonts, mcpp and php-pear-HTML-QuickForm-ElementGrid. The Liberation-fonts package is a result of Red Hat contracting Ascender Corp. to develop replacements for proprietary Microsoft fonts, including but not limited to Times New Roman, Arial and Courier New.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01111.html

[2] http://www.press.redhat.com/2007/05/09/liberation-fonts/

MilesLane was first off the block to report [3] that "yum update" was not picking up an updated version of control-center, but that it could be seen to be present at its URL in the repository. The usual "yum clean all" had been tried first. RoddClarkson reported related problems [4] , which indicated to JeremyKatz [5] that the something was misaligned with the tree.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01114.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01133.html

NicolasMailhot suspected [6] proxies as the problem, but NigelJones refuted this possibility with some data [7] . MattDomsch suggested that the frequently-updated content at mirrors.fedoraproject.org was a better argument to mirrorlist than fedora.redhat.com, but this still didn't help Miles.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01118.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01121.html

The was identified by BillNottingham [8] as a partially synced tree (primary.xml.gz was the only thing missing) and BrendanConoboy added [9] that repomd.xml needed to be regenerated too.

[8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01146.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01150.html

Making Beagle Optional

In response to frequent bugs in Beagle (a desktop search tool) causing CPU and memory stress, AlexanderLarsson made it optional [1] in the default install. While regretting that this was a regression in terms of features he pointed out that Beagle was still available for those who wanted it. There was a mild amount of satisfaction expressed in response to the decision.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00887.html

DavidNielsen thought [2] that Tracker was superior because Beagle consumed 100% CPU without tweaking. KevinKofler mentioned that Strigi would be part of KDE4, which will ship in Fedora 8, and worried about multiple desktop search daemons. David pointed out the Xesam Project [3] from Freedesktop which may mitigate this, and noted that there was a real need for desktop improvements using the technology which weren't simply replacements of the search dialog.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00914.html

[3] http://www.freedesktop.org/wiki/XesamAbout

In response to Alexander's proposal JesseKeating reported [4] that the Release Team agreed with this late regression, with the caveat that Beagle must be in the manifest of the "Fedora" spin of F7 so that upgraders from FC6 to F7 will not suffer.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00942.html

A few people were disappointed. DavidNielsen pointed out [5] that hard testing and stabilization would ensure that Beagle would return in F8, and AlexanderLarsson pointed to some specific bugs that those with an interest in running Beagle on Fedora could help [6] to fix. JefSpaleta expanded on the rationale behind why Beagle had to be removed due to failing QA, but could still be installed from a repository [7] .

RahulSundaram and DejiAkingunola [8] re-emphasized that Beagle was being removed from the default-install, not removed altogether, and that it is still in the official Fedora repositories for those who like it.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00964.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01008.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01053.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01054.html

In response to a suggestion by MatejCepl that Beagle was not greatly admired due to being built on Mono [9] , Alexander hastened to clarify [10] that this was not the reason and that the problems on display were going to be faced by any indexer. In fact, Alexander thought that Mono might have advantages by being (as all managed runtimes are) harder to crash. DavidNielsen was largely in agreement with this and also pointed out that Beagle had excellent documenation [11] .

[9] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00992.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01007.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00992.html

Legality of Fedora In Some Jurisdictions Contd.

Last week's discussion [1] of the need to be able to show a "Certificate of Authenticity" to the IP police in some countries, continued [2] with RalfCorsepius arguing forcefully that it was necessary to have a specific limitation on what language was acceptable for software packaged by Fedora.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00697.html

[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00810.html

JoshBoyer thought that Ralf should make a proposal about this to the Packaging Committee as he is a member, but Ralf thought [3] that responsibility was split between FESCo and GregDeKoenigsberg. Josh pointed out that no rule existed to say that Ralf shouldn't do this, and that he appeared to have a good understanding of the issue [4] , and that something along these lines would need to augment the packaging guidelines in the future anyway.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00908.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00924.html

Rahul also agreed with Ralf that bugs should be filed against packages with non-English licenses [5] , but disagreed that non-English licenses were unreadable. Rahul sought further non-English examples from Ralf. One that had been previously discussed was "mecab", maintained by MamoruTasaka. Mamoru mentioned [6] that he had sent a translation of a Japanese license for another package to TomCallaway who had then queried the FSF and was awaiting a reply from them. Mamoru had unsuccesfully requested the developer to use the GPL and had previously followed the same process [7] of going through TomCallaway and the FSF.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00906.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00910.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00913.html

AndrewHaley thought that license translation wasn't the FSF's job, but Rahul pointed out that they had done so whenever asked in the past [8] .

[8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00912.html

NicolasMailhot took exception [9] to the idea that English was more blessed than other languages and an exchange between Rahul and Nicolas followed which revolved around the US (hence English speaking) nature of Fedora (via Red Hat), the need to define what is an official translation, and the cost burden of producing these translations.

[9] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00915.html

SimoSorce thought [10] that placing the onus on non-English speaking developers to provide English translations of their licenses to Fedora was burdensome. He also argued [11] that mere translation to English was not enough, but rephrasing to take account of the local legal context was essential. At this point the conversation appeared to return to a familiar place, where Rahul argued that non-US contributors would need to accept a US legal framework [12] , or else the Fedora Project would have to regretfully decline their code.

[10] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00926.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00943.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg00947.html

Making Koji A Complete rpmfind Replacement

During the blip with syncing rawhide, NicolasMailhot explored one of Koji's less appreciated abilities. Koji [1] is a package build system developed for the Fedora Project , but Nicolas pointed out that with a little work [2] it could also fill the functional role that rpmfind fills on the web, making it easier for users to find specific RPMs.

[1] http://fedoraproject.org/wiki/Koji

[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01057.html

Agreeing with Nicolas that adding resolution of dependency links and display of rpm metadata, NigelJones added [3] that it would be nice to also see build-requires, so that packagers could contact other affected maintainers. In response MikeBonnet pointed to where this information appeared to be already provided by Koji [4] and asked for some more information. Nicolas advised looking at rpmfind.net to see what he meant.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01058.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01064.html

An offer of help [5] was received from OliverFalk, who had explored similar ideas, and JoshBoyer noted that "patches [were] welcome"!

[5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01059.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01060.html


In this section, we cover Fedora Maintainers, the group of people who maintain the software packages in Fedora


Why Not Build For EPEL Too?

ThorstenLeemhuis sent out a start signal[1] this week to let Fedora contributors know they can also help out with EPEL, or Extra Packages for Enterprise Linux. The invitation was made by Thorsten for Fedora packagers to build their packages for EPEL, which will allow RHEL and CentOS users (and other RHEL-based distributions) access to the vast array of packages found in the Fedora repository.

[1] https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00323.html

Fedora 7 Deep Freeze

This past Thursday, May 17, marked Fedora 7 entering a deep freeze[1] . With this period now in effect, only build tag requests for builds that fix release blockers will be permitted until the May 31st launch of Fedora 7.

[1] https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00351.html

Help Wanted: Package Co-maintainers

JochenSchmitt has put out a request for co-maintainers on a variety of different packages from blender to luma. If you have some time to help out another Fedora contributor, check out his message[1] for a list of packages needing another maintainer.

[1] https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00380.html

Improving Fedora Package Documentation

JonathanUnderwood has also put out a request, but this time it's for improving the Fedora packaging documentation[1] . The packaging documentation is in need of rewriting and then making it known and easy to find, and Underwood is initiating a movement to fix this area in despair.

[1] https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00598.html


In this section, we cover the Fedora Documentation Project.


Fedora Documentation Steering Committee Meeting

The FDSCo meeting was rescheduled last week and took place on Tuesday 15th May[1] . The meetings log was posted to the docs-list[2] .

[1] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00061.html

[2] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00068.html

Welcome Wizard

The idea of creating a Welcome Wizard was submitted to the docs-list[1] . Following discussions it was decided that if such an addition were to be made to Fedora it would be best suited as its own piece of software, separate from the First Run Wizard[2] .

[1] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00066.html

[2] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00081.html

Hardware Solutions Knowledge Base

A long desired addition to the Fedora Project is a community contributed database of hardware compatibility and solutions. It is thought that a knowledge base solution would be most appropriate but the best method for implementation remains undiscovered[1] . Some people believe that integration with Smolt will be possible to an extent, helping to automate the creation of much of the content[2] . Anybody interested in seeing this become a reality should post a message to the docs-list.

[1] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00072.html

[2] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00080.html


In this section, we cover the Fedora Infrastructure Project.


Fedora Mirror System

Thanks to MattDomsch for following news contribution[1] .

[1] https://www.redhat.com/archives/fedora-news-list/2007-May/msg00012.html

Fedora is fortunate to have nearly 200 volunteer mirror sites globally which helps distribute CD and DVD images, OS installs and updated packages to nearly 3 million systems [1] . Managing the list of mirror sites and their content had been a tedious manual process. In late October 2006, the Fedora Infrastructure team recognized the need to automate managing the mirror list. In January 2007, MattDomsch started working on code in earnest with the goal of being in production by the Fedora 7 release. With help from the entire Infrastructure team, especially ToshioKuratomi, MikeMcGrath, SethVidal, and LukeMacken, that system is now in place.

Mirrormanager[2] is licensed under the MIT/X11 license and is written using the TurboGears web application framework. It includes:

  • a database of mirror sites, individual mirror hosts, content carried such as Core, Extras, EPEL, and soon the Fedora Releases. Mirrors may choose to carry whichever subsets of the whole tree they wish.
  • an administration web app for mirror admins to manage detail about their own site.
  • a web crawler that crawls each mirror site several times a day updating the database with what they carry
  • the yum mirrorlist handler which tells yum the list of mirrors to try.

With this system in place, users should begin to see faster yum downloads, from a mirror in your country if possible. You can see the whole list of mirrors by country and content[3] .

We're always looking for additional mirrors. If you would like to provide a public Fedora mirror, please see [4] .

Troubles with new system should be reported to fedora-infrastructure-list redhat com or #fedora-admin on FreeNode.

[1] http://fedoraproject.org/wiki/Statistics

[2] https://hosted.fedoraproject.org/projects/mirrormanager

[3] http://mirrors.fedoraproject.org/publiclist

[4] http://fedoraproject.org/wiki/Infrastructure/Mirroring


Koji[1] (buildsystem software) was upgraded this week to a new version and moved to heavier duty hardware. The upgrade went well, though the outage lasted longer than initially anticipated. MikeMcGrath has more here[2] .

[1] http://fedoraproject.org/wiki/Koji

[2] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg00075.html

Proxy Server

The proxy servers[1] were upgraded[2] this week to RHEL 5. All went well and no outages were reported.

[1] http://fedoraproject.org/wiki/Infrastructure/Architecture

[2] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg00096.html


In this section, we cover Fedora Artwork Project.


Ambassador Program Banner

After a posting to the art-list requesting a new banner for the Ambassador Program's websites[1] , one was quickly forwarded[2] and is now part of the Ambassador's websites.

[1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00010.html

[2] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00011.html

The Ambassadors are still looking for some print banners[1] , however, for LinuxTag Germany, and work is underway[2] but new contributions are always welcome.

[1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00013.html

[2] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00014.html

Shutdown and Logout Icons

A discussion was prompted about the usability of Fedora's current approach to logging out and shutting down, the functions respective icons and menu locations[1] .

[1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00024.html

Security Week

In this section, we highlight the security stories from the week in Fedora.


Last week a round of Samba flaws were fixed[1] :

This update fixed three security flaws, all of which could allow a remote attacker to execute arbitrary code with the same permissions of the Samba server. Some of these flaws are especially dangerous as they allow an anonymous attacker on the network to compromise the Samba server. The anonymous part is what makes the flaws the most scary. If an attacker has to be authenticated against the Samba server, you have a known number of attackers. If anyone attached to the network is able to attack Samba, there can be a near infinite number of attackers depending on the network setup.

The lesson one should take away from this, is that proper network setup is important. Sane firewall rules can go a long way. If you only need one machine to talk to the Samba server, you should only allow that machine access, not the whole network. Spending some time thinking about your network needs can make a big difference when a security flaw is found.

[1] http://news.samba.org/releases/samba_3_0_25_release/

Security Advisories

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


Fedora Core 6 Security Advisories

Fedora Core 5 Security Advisories

Events and Meetings

In this section, we cover event reports and meeting summaries from various projects.

Fedora Release Engineering Meeting 2007-05-14

Fedora French Ambassadors Meeting 2007-05-13

Fedora Engineering Steering Committee 2007-05-10


This document is maintained by the Fedora News Team[1] . Please feel free to contact us to give your feedback. If you'd like to contribute to a future issue of the Fedora Weekly News, please see the Join[2] page to find out how to help.

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

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