Announcements

Announcing Fedora 7 Test 4 (6.93)

The Fedora Project is pleased to announce[1] the release of the fourth and final test release of Fedora 7!

Test 4 is for beta users. This is the time when we MUST have full community participation. Without this participation both hardware and software functionality suffers. We need your help. Join us! This is the final test release before the Fedora 7 release, which is scheduled for May 24, 2007.

Red Hat Summit Compilation

JefSpaleta points out in his blog[1] ,

"So I finally got around to poking at my digital music library and playing with rhythmbox again after almost a year after my move. I noticed the magnatune plugin and started poking at the available content in the catalog. Some of its not bad, but some of it's not to good. So instead of wasting my time hunting and pecking I decided to do a quick search for compilations. And I found this: The Red Hat Summit[2] Compilation[3] ."

0-Day Fedora Kernels

DaveJones points out in his blog[1] ,

"A few days ago I fixed up the script that grabbed the latest kernel I built for Fedora and dumped it onto my people.redhat.com page. F7 users can now install the repo file[2] into /etc/yum.repos.d/ and have it grab those fresh kernels as soon as they're built without having to wait a whole day to get them from rawhide."

Fedora Article in LWN

RahulSundaram points out in his blog[1] ,

"LWN published a article titled Blaming Fedora[2] but really praising it for a strong policy on Free software. The discussions in the comments lead to me having a ongoing offlist very constructive conversations with Brett Smith, licensing compliance engineer from FSF on Fedora Free software analysis[3] . We are having good progress. I will post updates when we reach major milestones."

Marketing

Red Hat's JBoss to Adopt Fedora Model

RahulSundaram points out in fedora-marketing-list[1] ,

"The move would mean that JBoss[2] would deliver a Fedora-like community
edition of its core software that only looks forward. As with the Fedora
Linux project, no backward compatibility is guaranteed—Fedora is focused
on the future and new features."

Developments Mon, April 23 - Sat, April 28 2007

Root Filesystem Encryption Patch

ThomasSwan posted[1] details of how to achieve an encrypted root filesystem on FC6 using LUKS[2] . Thomas was hoping to get his modified mkinitrd script into F7-Test4, but it was pointed out that firstly, F7t4 had already shipped[3] and secondly, that new features like this were not appropriate anyway during a final freeze[4] . All responding to Thomas made it clear that his contribution was not being rejected and that they hoped to see it in F8.

BrunoWolff III was less happy as he'd been hoping that these patches (which had been around for a while) would make it into F7 which would coincide with his need to upgrade some FC5 machines. He wondered[6] who had to be bugged to make the patches actually get incorporated? Thomas answered that he would be happy to assist Bruno patch F7 and intended to set up a yum repository to aid others. FlorianLaRoche pointed Bruno to the wiki, where information about this could be shared but this didn't satisfy Bruno. Finally, BillNottingham was drawn into the discussion and noted some problems[7] with the patches which was why he had not yet rolled them in.

RPM Packaging Feedback Sought and Received

Kelly (lightsolphoenix) looked for advice on some KDE packages that Kelly had produced[1] . TrondDanielsen suggested[2] that, as Kelly was interested in being a maintainer of these packages for Fedora, it would be a good idea to go through the official procedure[3] . RudolfKastl suggested that the SRPM packages would be useful, and Kelly responded with those packages and the spec files.

Wow, Presto Rocks!

Continuing the positive reactions to presto, RexDieter was excited[1] by his experiences with it. Rex wondered how the tools to create presto-enabled repositories were coming along and intoned the mantra "release early, release often." RichardHughes was also interested in these tools[2] . JonathanDieter pleaded end-of-term pressure and pointed to the tools in an unfinished state[3] . MartinSourada noted that he too saw huge savings in bandwidth (90%) for an update on FC6[4] and encouraged the inclusion of presto for F8.

Pidgin Epoch Removed, Rawhide Updates Need Manual Correction

As a result of negotiations between AOL and the developers of Gaim[1] , the program has been renamed to "Pidgin". WarrenTogami noted that the opportunity to remove the epoch had been missed with the original Fedora Extras 7 package[2] , and that this was now corrected and rawhide users should manually fix the problem using:

su -c "yum remove libpurple"
su -c "yum install pidgin"

The issue arose later in a rawhide user error report[3] , manifesting as a missing "libpurple.so". "libpurple" is the renamed "libgaim". Another user reported that he did not have this problem with rawhide, but JoshBoyer was able to explain[4] that this was because he was not using the latest epochless package (which yum would refuse to update). TrondDanielsen also quickly provided a practical fix[5] .

How To Get Your Packages Sponsored And Reviewed

A query from AntonKuznetsov opened up a discussion about the proper way to submit software for review[1] . NigelJones posted links[2] to the specific package that Anton was talking about ("Profugus", a time-dependent automatic migrator of Xen kernels) and counselled patience, noting that the review process was at least two weeks usually and that Anton had only submitted the package ten days ago.

Nigel's informative email clarified an apparent confusion in the original post about the role of volunteer "pre-reviewers", who note problems with packages before they are formally reviewed by someone that can act as a sponsor. ManuelWolfshant who had pre-reviewed the package confirmed that this was the case[3] .

PatriceDumas also suggested patience, and a part of his post that said there are some reviews that are years old surprised RahulSundaram[4] , who felt that packages which had been in review for more than a few months should have their reviews closed as they were clogging up the process. Patrice argued that there was already a "stalled review" policy for dealing with this, and along with NigelJones pointed out several reasons for keeping such a review open. These included maintaining a continuous body of information, ease of contact with external upstream developers. JasonTibbits argued specifically against Rahul's assertion that software older than six months was probably obsoleted[5] . Jason also suggested that people should ping the reviewers more often, then closed with a promise to start reviewing again Real Soon Now (TM).

RalfCorsepius provided an affirmative datapoint to Rahul's original question. JasonTibbitts felt that these were very atypical packages[6] and RexDieter thought that on occasion third-party repositories could be a positive way of getting more feedback, but Ralf didn't see that as true for his particular case[7] which failure he attributed to deficiencies in the rpmbuild system, the guidelines and the competence of "review monkeys"[8] . KevinKofler then proferred some mutual aid to Ralf[8a] as Kevin now owns a package and can thus perform review for those who don't need sponsors.

JoséMatos pointed out that the merge of the Core and Extras repositories might have filled up the queue[9] and that in general things were working as they should be, and Anton posted thanks for all the feedback and information that he'd obtained[10] .

RahulSundaram was not impressed with the move to rename the distribution as simply "Fedora". Following up on his questioning about whether this had been discussed by marketing, JoshBoyer said it had not been discussed on a public list, but on IRC[5a] , and AxelThimm provided[6] an example of how this could lead to confusion centered around what was on the spin (on the DVD or multiple CDs) and what was available on the network in addition to this. There were a couple of suggestions, but no agreement (other than that naming sucks and that there was much confusion)[7] [8] .

Repowars II: Add Some EPEL "repotag" Duct Tape?

ThorstenLeemhuis moved a discussion from @fedora-maintainers in order to reach a wider audience[1] . This discussion concerned the Extra Packages for Enterprise Linux (EPEL) repository[2] that aims to provide a way for high-quality Fedora packages to be provided for RHEL and related spinoffs such as CentOS and Scientific Linux. Repository tags (repotags) are an optional addition to the name of a package, which mainly served the purpose in pre-Extras days of providing brand-recognition between the many excellent, competing repositories.

Thorsten led off with some personal observations, but wished to concentrate on what seemed to him the most important thing: a political problem whereby some would feel that EPEL had been privileged over other "outside the fence" repositories which had to use a repotag, while EPEL did not. Bearing all this in mind, Thorsten was specifically soliciting discussion prior to any of the concerned steering bodies voting[4] on his concrete proposals to solve the problem. FernandoLopez-Lezcano was largely in agreement[5] with Thorsten's scheme to use defines in the EPEL buildsystem to add a repotag, while simultaneously leaving the Fedora buildsystem undisturbed.

AxelThimm was also mainlu in agreement with the proposal[6] , and JefSpaleta provided one of his usual informative and thoughtful takes on the situation[7] , which characterized it as a general usability problem, limited by the design of the current tools. Jef also roughly outlined how package signatures /might/ be used to get around this in the future, a proposal which drew some favourable comment from Fernando.

Standard Naming Scheme For KDE Components

In further naming scheme news, Kelly (lightsolphoenix) wondered whether the names of various KDE components should be patterned after the GTK ones[1] . TomTromey wondered the same thing about emacs dependent pieces and JonathanUnderwood explained that it depended on whether they were solely for emacs, Xemacs, or could be used on both[2] .

RexDieter pointed Kelly to a draft packaging guideline for KDE[3] , and recommended following upstream in the meantime.

kdebase And lftp Cause Rawhide Update Problem

An attempt to update kdebase and lftp on rawhide left DavidHunter seeking help[1] when everything he'd tried failed. Mark and JoshBoyer both suggested a nodeps erasure of the current versions of the packages[2] as an immediate practical workarounds.

JesseKeating acknowledged the workarounds, but wanted to get to the bottom of the problem and asked for bugzilla reports, prompting MichaelSchwendt to explain that these were the result of temporary breakage in rawhide[3] due to known causes.

MamoruTasaka gave a reply specifically on the lftp problem[3a] and RexDieter stepped in to help with the kdebase problem[3b] , which seemed to be to do with the OP mixing in packages from the kde-redhat repository with Fedora's own kde package.

Jesse was still unhappy with this because it would not preserve an upgrade path within rawhide (which is a desideratum according to recent FESCo meetings). To this end he proposed an Obsoletes/Provides, which neither PatriceDumas nor MichaelSchwendt were enthusiastic about[4] . Michael's argument seemed to suggest that there are several ways in which an upgrade path within rawhide are not always be practical.

The Merge Is Upon Us!

Drawing our attention to the imminence of merging, JesseKeating asked for input[1] on the plans to merge. After a query from HansdeGoede about gstreamer plugins, MatthiasClasen posted a tracker bugzilla entry[2] for items that would have to happen post-merge and freeze.

Maintainers

libperl & perl in Fedora 7

Due to build issues, libperl.so was originally going to be moved[1] from the perl package into its own sub-package; however, all has been corrected in the Perl camp for rawhide users. Perl was multilib in Fedora Core 6 due to Gaim, but Jesse Keating has "whitelisted" perl to make it multilib again with Pidgin (Gaim) being in Extras.

Guidelines Update

Clearing up the relationship between the packager and reviewer is an update to the Packaging Guidelines[1] . It is the responsibility of the reviewer to point out problems and it is the responsibility of the packager to correct the problem, while it is a combined responsibility to determine the severity. If the packager or reviewer feels a particular package should be exempt from the Packaging Guidelines[2] , it must be brought to the attention of the Fedora Packaging Committee.

Fedora 7 Development Freeze

With Fedora 7 Test 4 now out the door, there is now a continual development freeze[1] until the May 24 release. During this time, only bug fixes will be accepted. Core packages must also be using the f7-final tag.

The Name For Fedora 7?

With Fedora 7 quickly approaching, Jesse Keating[1] is also seeking Fedora maintainers to fill in the blank: Bordeaux -> Zod -> <blank>? Zod is a <blank>, <blank> is a <blank>. Suggestions are to be run through the legal queue and then voting takes place afterwards.

Documentation

Release Notes Freeze

The release notes wiki[1] is was temporarily frozen with the information being ported over to CVS for translators to begin their work, reports PaulFrields.[2] The wiki was unfrozen so notes can continue to be added up to Fedora 7 release; these additional notes are combined with the ISO-based release notes to be published as a Web-only release[3] .

Media Handling in Pirut

RahulSundaram announced that he is working on updating the Software Management Guide[1] with the goal of releasing a new version for Fedora 7[2] . If you are interested in helping, you can find more details under the guide's working notes.[3]

There was also a request for help with documenting the support for media in the development version of Pirut. Although this feature is present, the required auto-configuration is not yet present in Anaconda and so the documentation is needed before release. If anybody is interested in helping with this send a post to the DocsProject mailing list.[4]

Knowledge Base?

Following the report of a bug with a simple fix, the idea of a knowledge base was briefly discussed. It is hoped that a knowledge base would provide the ideal location for one-off bugs such as this, which in turn might have the effect of making it easier for users to contribute docs.[1]

Sponsored vs Volunteers

A discussion started this week about tracking sponsored versus volunteer contributions to Fedora, with sponsored meaning the contribution was done as part of a for-pay work assignment by the contributor. This thread was started by RahulSundaram, who was interested in having these oft-requested statistics. The thread expanded to discuss the ideal of tracking all contributions made to Fedora, but it appears package maintainers are the first to be tracked[2] . It was emphasized that the tracking is optional; a contributor can opt not to supply this context of their contribution.

Artwork

The Open Pallete

The second part of "The Open Pallete" - a series of articles in Red Hat Magazine[1] about open source graphics tools - has been published. This article is titled "Grungy Brushes", and discusses how to create brushes in Inkscape that can then be used in The Gimp. It's a great article and well worth a read for any budding (or experienced) open artists out there! NicuBuculei has also written some follow up articles which can be found linked from the original post.[2]

Echo SVG Fixed

Following last week's discussions about the problems with the echo-icon-theme's package size, a lot of work has occurred this week and all the icons have now been fixed[1] . The fixed icons can be found on a subpage of the Echo icon's wiki page[2] . It is unlikely that these updated SVGs can be added to the echo-icon-theme package before Fedora 7, however, as Fedora is now frozen for release.[3]

Linuxtag Germany

GeroldKassube has requested help from the Fedora artwork team with a brochure and a banner for Linuxtag Germany[1] - one of the larger open source events in Europe with in excess of 10000 visitors throughout the week. If you feel you could help, read the post and send your reply to the Fedora Art list.

Security Week

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

Firefox 1.5 Support Extended

The biggest security story from last week was the news that the life of Firefox 1.5 is being extended by upstream until mid-May[1] .

The Mozilla project is planning to stop providing official updates for the 1.5 Firefox branch. They of course want to put their development effort into the 2.0 branch. The current plan for Red Hat and Fedora is to roll security patches into the 1.5 branch. Several distributions are going to work together to keep the 1.5 branch maintained with security patches since there is great interest in keeping 1.5 maintained for the immediate future. Chris Aillon explains this in a blog posting, "Mozilla Corp. to work more closely with Linux distributors"[2] .

This action shows a huge strength of open source software and security maintenance. When a closed source application is distributed, you have to run whatever version the author wishes you to run. If an application has the source available, and the will exists, a version that no longer receives formal support can live on.

Event Report: FLISOL 2007 - Salvador, Bahia, Brazil

Errata

From time to time, we issue an Errata to correct Fedora Weekly News[1] published in previous week. We apologize for any confusion it may cause. If you feel a news needs to be corrected, please submit an "Errata Request" to Fedora News Team[2] .

Erratum #1

In FWN Issue #84, in the section entitled "Mass Package Rebuilds - Papering Over Cracks or Shaking the Tree?" we erroneously wrote:

"JohnPoelstra posted details of the Release Engineering Meeting. ThorstenLeemhuis was against one of the decisions made in the meeting: the rebuilding en masse of all packages at Test2 release time."

This should have read:

"JohnPoelstra posted details of the Release Engineering Meeting. These included a note that a mass rebuild of all packages around, but no later than test2 will be considered in the future. ThorstenLeemhuis mentioned in a reply that he was against rebuilding en masse all packages for each cycle."

Erratum #2

In FWN #84, in the section entitled "Packaging Extensions for Mozilla Applications: Security Implications" we misattributed an opinion to VilleSkyttä:

"VilleSkyttä remembered a conversation from the past that suggested there was some interest in packaging the extensions. He was specifically interested in making it easier to obtain a 64-bit version of enigmail."

This was in fact ThorstenLeemhuis, not VilleSkyttä.

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.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, and JBoss are trademarks or registered trademarks of
Red Hat, Inc. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community
maintained site. Red Hat is not responsible for content.