Announcements

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

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

Planet Fedora

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:.."

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

'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."

Marketing

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

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

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

Maintainers

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.

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.

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.

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.

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

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.

Fedora Mirror System

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.

Koji

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

Security Week

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

Samba

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.

Fedora French Ambassadors Meeting 2007-05-13

Fedora Engineering Steering Committee 2007-05-10

Feedback

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.