Announcements

In this section, we cover announcements from various projects.

Fedora Wiki Accounts

MikeMcGrath announces in fedora-announce-list[1] - In response to our wiki woes, we have decided to delete all wiki accounts that are not watching any pages and are not in the EditGroup[2] .
This will help speed page saves up because of the way moin iterates over users to see who to notify. Those wishing to keep an account should simply sign up again.

Planet Fedora

Fedora's Pidgin Plan

WarrenTogami points out in his blog[1] - The Gaim project[2] signed a trademark settlement with AOL, and will be changing their name to Pidgin.

Upstream is planning on a pidgin-2.0.0-beta7. They are trying to settle a pref migration blocker before cutting this beta release. This beta7 will give Fedora critically important window, where we must move quickly to prepare for the final 2.0.0 release. We must fix all dependencies by fixing up and renaming the numerous gaim-* plugin packages, and be sure the entire collection automatically upgrades cleanly with yum. That should smoothen our upgrade into 2.0.0 that is expected soon thereafter. When we are satisfied with the 2.0.0 final + all plugin packages in F7, we will do the same to FC6.

Spread Open Media

NicuBuculei points out in his blog[1] - We, at the Open Clip Art Library[2] , together with Xiph.org[3] are hosting a contest for creating a logo and maybe a mascot for Spread Open Media. All submissions should be in SVG format and released as Public Domain, so they cam become part of the Open Clip Art Library. The contest started on 10 April 2007 and will end on 05 May 2007. Using those contributions as a base, a lot of materials like banners, buttons, badges, icons, fliers, t-shirts will be created.

Developments

In this section, we cover the problems/solutions, people/personalities, and ups/downs of the endless discussions on fedora-devel-list.

Bad gnome-user-share, Bad!

MattMiller noticed that gnome-user-share was trying out some new tricks [1] and wanted it to stop. Specifically he questioned the wisdom of a Gnome desktop environment needing to include httpd because g-u-s is in the group and works by using WebDAV. JesseKeating pointed him upstream and argued that it was safe because a user had to consciously switch it on, to which JonCiesla agreed [2] "+1. If the nailgun is unplugged, in the box, and the nails are in a
separate box, why not ship them? Provide the functionality, but in a safe
manner. Is this not the current state?". Further discussion led to the idea [3] of breaking out the apache server config from the g-u-s stuff. NicolasMailhot wondered why the gnome-daemon was not able to just drop the right file into /etc/httpd/conf.d and OwenTaylor tried to get to the root [4] of Matt's objections.

Mgetty Still Maintained ? Or, How To Patch And Rebuild From Source RPMs

In a redirected question [1] from fedora-list, Don Russell wondered if mgetty was under active maintenance. Don had opened a Bugzilla report and noted that there were year-old updates available that weren't packaged for FC6. Dragoran and Dexter helped him out with obtaining the source code [2] [3] so that he could build a fixed version himself.

Administrative Tools Emancipated From GTK+ Tyranny

An enquiry [1] from a potential new developer led to suggestions of which projects might profitably be attempted. Noting his C/Qt experience KevinKofler suggested [2] helping with KDE4 packaging. OttoRey was led to wonder [3] whether there were clear mini-RFCs or other specs for dependency checking. Vlad suggested [4] improving KDE integration by writing KDE versions of the administrative tools, which all have GTK+ frontends, but no KDE GUI frontends. RexDieter then drew attention [5] to guidance which does much of Vlad's extensive list. Rex was seeking [6] a co/maintainer for the package, which is already in the review process. MattMiller observed [7] that an important side-effect of rewriting the tools so that there's a GUI-independent back-end will be that root-privileged operations will also be taken out of the GUI front-end.

The issue was further discussed in a separate thread [8] , with DavidZeuthen enlarging [9] on Matt's point about privilege separation and arguing cogently for people to take a look at PolicyKit instead of just Qtifying apps which are currently GTK+ based. JaneDogalt suggested [10] that a scriptable backend would be very welcome. Later NicolasMailhot and RichardHughes discussed the implications [11] for embedded systems and Richard mentioned the OHM project.

Readahead Lists Need an Update For Rawhide?

The prolific MarkG85 noted [1] that readahead was apparently not in use for Firefox-2.x in rawhide and that it was very beneficial for Firefox-1.5.x, also that it might be nice to add the default gnome-panel applets. ZakKarel agreed [12] and said that he'd generate updated readahead lists close to the freeze. Zak also pointed out the useful readahead-collector tool [3] which allows the generation of customized lists for a particular machine.

In today's episode we ask "Can YUM Upgrade noarch to a specific arch?" Acting upon feedback previously received [1] MichaelEBrown (Dell's maintainer of firmware packages) was [2] still seeking a clean, approved way of packaging the firmware. It seemed from his tests that Yum failed (in FC6) to update the firmware-addon-dell packages that he had converted from being noarch. MichaelSchwendt posted a [3] counter-example. Reports from TillMaas led MichaelEBrown to investigate [4] whether this was specifically a problem in updating from noarch -> x86_64 as the noarch -> i386 seemed to work. SethVidal and MattMiller both tried to help, and later MichaelEBrown reported [5] that an IRC conversation with Seth suggested that it was a bug in rpmUtils.updates.py which only reared its head on multilib systems and that there was a temporary work-around. Seth soon posted a patch to the open bugzilla which MichaelEBrown confirmed as a fix [6] .

When Will iwlwifi Work?

A polite [1] enquiry from ThomasBaker noted that iwlwifi had been in the kernel for a bit, didn't work and it would be good to know if users should wait to test fixes, or just go and install the alternate ipw3945 driver. AndyGreen found that it worked on a WPA network, TomLondon found that it didn't [2] (and was testing with each fresh Rawhide kernel and then installing ipw3945). JoshBoyer rebuffed [3] the idea of using JohnLinville's custom kernels because the point was to test rawhide. JohnLinville and others noted that unless people actually try the linville packages then it will be difficult to determine what works and should be propagated into rawhide as a fix. John confirmed to RichardHughes that upstream would be getting an iwlwifi fix from him soon [4] .

After all this there was some confusion about what the "Linville test kernels" were. Dragoran clarified the matter in a response [5] to ThomasBaker, pointing out a bugzilla in which JohnLinville had rolled up some patches written upstream after Dragoran had prodded them with a pointy stick. The Linville page also describes these kernels as Kernels available here are explicitly NOT official Red Hat kernels. These kernels are for testing and/or experimentation. There is absolutely no guarantee that any patches present in these kernels will actually be made available either upstream or as part of any official Red Hat kernel. However testing is of course appreciated and obviously affects what goes into rawhide.

As a sidenote, EricMagaoay and Nicolas (kwizart) noted that the firmware for zd1211rw_mac80211 seemed to work, was under review and needed the wireless-tools package to be updated to stay in sync [6] .

Where are VirtualProvides Documented?

A question [1] about the difference in meaning between "Provides:MTA" and "Provides:smtpdaemon" was posed by VilleSkyttä. The question seemed to have been considered [2] deeply by ManuelWolfshant, as maintainer of ssmtp, who along with PatriceDumas now believes [3] that the problem is to do with mdadm having an incorrect requires.

JonathanUnderwood noted [4] that his proposals for TeX dealt with the issue of virtual provides.

JesseKeating asked whether this in fact concerned the "alternatives" system and Ville argued [5] that it did, but that was a rewording of his original question. Ville and Patrice seemed to cohere on a solution [6] which involved removing mta/MTA from the "Provides" (but not touching the alternatives namespace) and using /bin/mail as a "Requires", and sifting through packages which have a "Provides: smtpdaemon" and fixing them.

RFE: Mirror/server Do Not Remove Old Kernel From Updates

GilboaDavra posted an RFE inspired by a late-night / early-morning tale of woe in which a completely cleaned yum cache and an "rpm -e" left him with a dead machine. His suggestion [1] is that the last five kernels should be left on mirrors so that people could revert if necessary.

LeszekMatok was unsympathetic to what he perceived as a support request for proprietary software (VMware), but Gilboa wasn't having any of it [2] . TonyNelson thought that keeping older versions of the kernel about was a good idea, prompting JesseKeating to ask for recent sightings of the mythical beast Unlimited Storage [3] . Gilboa stuck to his guns and brought specific figures into the picture [4] to show that the last five released kernels for one architecture would only consume 400MB. Interestingly, Jesse responded that post-merge (once Koji is in use) these should be available [5]

1. TomCallaway (spot) posted a [1] that the License tag for non-modifiable firmware should be changed. This led to a query as to whether madwifi-ng could be included in Fedora. ThorstenLeemhuis responded [2] with the conditional information that it would appear not to be the case, as it was more like a static library than a firmware. This interpretation was confirmed by JoshBoyer.

2. A [3] new definition of a "post release" package and specific attention to non-numeric versions was posted. There was no @fedora-devel discussion of this change.

3. An additional subsection now [4] prepping the buildroot properly. TomLane thought it was a bug that each and every specfile had to do this. In response [5] JesseKeating acknowleged that it was a bug but thought there were many more important things upon which rpm developers should work. MichaelSchroeder of SUSE had a helpful suggestion [6] .

Further discussion between TomCallaway, PanuMatilainen and others [7] centered around the benefits of fixing the rpm bug, thus completely breaking older RPM packages.

Bugzilla Policy: Should FC4 Bug Filing Be Banned?

Some thought it was a joke [1] , but MattMiller was deadly serious [2] . The problem is that there is no way to not receive reports still automatically generated for FC4 (which should really be turned into petfood). JesseKeating replied that there was a plan [3] to create a new "product" which only got current (F7 and rawhide) bugs. It would then be possible to only receive bug reports for that product. MikeWiktowy worried [4] that this would only buy a year's grace, leading Jesse to clarify that what he wanted was to see unsupported releases in one product, and only the current release and development in the new Fedora product.

MattMiller was also led to clarify (with tears almost audible in his email) that people were still filing bugs against FC5 [5] . Matt was then invited to join the FedoraQA meeting for further discussion [6] .

Maintainers

"FC6" in Fedora 7

With FWN's inaugural coverage of the fedora-maintainers-list, we begin with the presence of the "fc6" disttag in some Fedora 7 packages. Rahul Sundaram had expressed concern[1] over this occurring and had suggested rebuilding the packages to prevent this.

Packaging Guideline Changes

The Fedora Packaging Committee had also approved a change to the packaging guideline for the license tag and naming firmware packages to <foo>-firmware. Other guidelines changes made over the past week include those for post release naming, prepping buildroot for %install, and UTF-8 filenames.

Fedora 7 Test 4 Freeze

Jesse Keating also reaffirmed that the Fedora 7 Test 4 freeze[1] will start next Tuesday (April 17). The freeze for Test 4 also marks the point at which only bug fixes should enter Fedora 7.

Documentation

Fedora 7 Desktop User Guide

JohnBabich has come forward and volunteered as the lead writer for the Desktop User Guide in the build up to Fedora 7.[1]

Throughout the week there has been a lot of discussion about the Desktop User Guide and the direction it should be taken in: the use of screenshots[2] ; making the document more task orientated and the best layout to achieve this[3] ; providing coverage of alternative desktop environments and the best approach to achieve this[4] .

Common Snippets

As reported last week PaulFrields made a proposal of creating a system that would allow for the quick translation of common snippets of documents to many different languages using XML. KarstenWade replied to this[1] and suggested that it might be nice if some more people with good XML knowledge would get involved with this aspect of the project. If you are interested in XML I'm sure you'll be made very welcome by the documentation team!

Translation

Release Notes Deadlines

PaulFrields sent a note[1] to the list announcing the deadline for translations (2359 UTC 14 April 2007). The next and final POT update is 21 April 2007 and the absolute deadline for translation of PO files is 2359 UTC 2 May 2007.

More on Entities

PaulFrields announced[1] the change back to "xml2po -e" unfortunately this will require some extra translation work. Thanks to all the translators for hanging in there with the recent changes, we do appreciate it!!

Infrastructure

Email Addresses

MikeMcGrath revisited the email address issue[1] in which he pointed out that problems have arisen with the current firstname.lastname email address convention (sendmail and postfix can't handle some of the characters). He proposed that email addresses are setup as the persons account name and also suggested the removal of firstname.lastname addresses. His proposal was agreed upon with the allowal of firstname.lastname addressses in special cases.

The Wiki

Ah, yes, the wiki. This week the wiki provided the team with some challenges and no doubt Fedora users noticed the couple of website outage and yum availability interruption. MikeMcGrath posted this summary[1] of the weeks efforts, which included some Apache and Moin reconfiguration. Thanks to everyone that pitched in and helped throughout the week and to the Fedora users for being patient. (Fedora currently has the largest implementation of Moin/Wiki so we, as always we are on the bleeding edge!)

Artwork

Fedora Underground Pilot

JohnBaer announced that, after previously considering starting a page similar to Google's start page but with the emphasis on Fedora, he now has a pilot design. The page hosts quick links to many Fedora related websites, a customized Google search and links to other sites he considers useful for Fedora users.

He hopes to spread the word and track the number of hits up to the release of Fedora 7 when he will review the situation and consider developing it further.[1]

Echo Icons

LuyaTshimbalanga has submitted some draft icons based on the keyboard icon design discussed last week; these include a character map icon and a keyboard-shortcuts icon[1] . As well as these two keyboard related icons she also submitted new drafts of the Add/Remove Applications icon.[2]

Security Week in Review

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

In This Week

Remarkably little happened this week in the security universe. I wonder if
this is the result of the fabled Microsoft Patch Tuesday, and researchers not
wanting to lose attention to the pending flood of stories about all the
windows patches. The general idea behind this is that rather than release
updates when they're ready, Microsoft will hold them until the second Tuesday
of every month. I'm honestly not sure how I feel about this, but in general
it doesn't work in the open source world. We generally have little control
over when many security updates are released. If an open source project wants
to release an update on a Sunday night, there is nothing stopping them from
doing that. This of course isn't ideal for most people, but it's one of the
many issues with the rather chaotic world of open source security updates.

Schneier on Security

This story from Bruce Schneier's blog made me immediately think of open
source: U.S. Government Contractor Injects Malicious Software into Critical Military Computers [1] .
This sort of thing probably happens more than anybody will ever admit, but
it's likely a lot harder to pull of when your development is conducted in an
open and transparent manner. It's also nearly impossible to prove in a closed
source system. Even if such a flaw is found in a closed source system, it
would not surprise me if many vendors would try to keep such information
hidden. It's certainly not in the best interest of a vendor to let news of a
back door go public.

Apache.org

On this note though, what do projects do to stay secure? Is there anything
preventing a disgruntled project member from causing harm (even if it is found
immediately)? Apache.org had a slightly similar experience with this some
time ago: Apache.Org compromise report, May 30th, 2001 [1]
They handled it about the best any project could.

FreeRADIUS

A memory leak flaw in FreeRADIUS was found[1] . The flaw itself
isn't really noteworthy, but it does give me a good opportunity to note that
there is often a fine line separating old fashioned bugs and security flaws.

Many software applications contain memory leaks and it's usually not a big
deal. I don't suggest one should ignore a memory leak since it is a bug, but
not all memory leaks are security flaws either. However they are serious
problems with long running applications such as daemons. There are a number
of bugs that can be considered a security flaw given the right circumstances.
One of the jobs of the security team is to investigate these bugs and sort the
chaff from the wheat. Another favorite is a user assisted crash. If a remote
attacker can make something like FreeRADIUS crash, it's a security flaw. If a
remote attacker can make Firefox crash, we call it a "don't do that again"
bug.

Mark Cox

Mark Cox had a most interesting blog posting this week: Information
Sources[1] . Most people don't really worry about where security flaws come
from, but it is most interesting when you're on of the lucky people who have
to try to make sense of all this madness. It's nice to know this since we
know that it's worth the effort to maintain a healthy relationship with
upstream projects and various researchers. It is a goal of the Red Hat
Security Response Team to work with anyone who approaches us with a flaw. The
goal is to keep the users as safe as possible, which can occasionally make our
lives a bit painful when dealing with difficult projects and researchers, but
no doubt it's well worth it.

Packaging Committee Meeting 2007-04-10

Ambassadors Meeting Minutes 2007-04-12

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.