Fedora Weekly News Issue 99

[Thomas Chung]

= Fedora Weekly News Issue 99 =

Welcome to Fedora Weekly News Issue 99 for the week of July 29th,
2007. http://fedoraproject.org/wiki/FWN/Issue99

In this week, we have announcements on Fedora 8 Test 1, Virtual FudCon
and our new column called AskFedora.

Speaking of AskFedora, we received several good questions including
License Issue, Backups and Problem with Pup.

In Developments, we have continuing discussions on CodecBuddy, Yum,
Kmods, RPM Roadmap, KDE4 Status and more.

To join or give us your feedback, please visit
http://fedoraproject.org/wiki/NewsProject/Join.

   1. Announcements
         1. Fedora 8 Test 1 slipping
         2. Interested in holding a session at Virtual FudCon?
         3. Ask Fedora: Fedora Weekly News Column
   2. Planet Fedora
         1. Better Fedora Collaboration
         2. Come Party With Fedora
   3. Ask Fedora
   4. Questions and Answers
         1. License violations
         2. Making Backups
         3. Future of RPM
         4. CD Installations of Fedora 7
         5. Global changes in Fedora
         6. Bugzilla Responses
         7. Problem with Pup
   5. Marketing
         1. Bradley Kuhn and Max Spevack to keynote at Ohio LinuxFest
         2. Video: Meet the Fedora Ambassadors
         3. New extras repository for Red Hat Enteprise Linux
         4. Redirecting Core Dumps
   6. Developments
         1. FESCo Approves CodecBuddy
         2. The Future Of Yum
         3. Kqemu In The Kernel?
         4. Kmods Clarified
         5. LiveCD Wipes Root Partition
         6. RPM Roadmap (Cont.)
         7. KDE4 Status
         8. Package Management: Goats Satisfied With Current Situation
         9. FESCo Ratifies Changes To "License:" Tag In RPM SPECs
   7. Maintainers
         1. EPEL Repository Continues To Expand
   8. Documentation
         1. Virtual Fudcon Ideas?
         2. Documentation Project Steering Committee Meeting
         3. Fedora 8 Test 1 Release Notes
   9. Infrastructure
         1. Operating Procedures
  10. Artwork
         1. Echo Used on translate.fp.org
         2. Virtual Fudcon
         3. Round 2 Deadline
  11. Security Week
         1. Firefox 2.0.0.6
         2. Hacking via IPS Signatures
  12. Daily Package
         1. Gobby - Collaborative editor
         2. Netpbm - Utilities for graphic manipulation
         3. Wednesday Why: Colour ls
         4. Xnest - A nested X server
         5. Kbilliard - Billiard simulator game
  13. Advisories and Updates
         1. Fedora 7 Security Advisories
         2. Fedora Core 6 Security Advisories
  14. Events and Meetings
         1. Fedora Board Meeting Minutes 2007-07-31
         2. Fedora Ambassadors Meeting 2007-MM-DD
         3. Fedora Documentation Steering Committee 2007-07-31
         4. Fedora Engineering Steering Committee Meeting 2007-08-02
         5. Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-08-01
         6. Fedora Infrastructure Meeting (Log) 2007-MM-DD
         7. Fedora Packaging Committee Meeting 2007-07-31
         8. Fedora Release Engineering Meeting 2007-07-30
         9. Fedora Translation Project Meeting (Log) 2007-MM-DD

[[Anchor(Announcements)]]
== Announcements ==

In this section, we cover announcements from various projects.

Contributing Writer: ThomasChung


=== Fedora 8 Test 1 slipping ===

JesseKeating announces in fedora-devel-announce[1],

"Due to an ongoing issue with booting many Dells (and some Toshiba)
systems via CD, we've had to delay the release[2] of Test1.  The good news
is that we've found a solution and a new kernel is building in koji as
I type this.  The bad news is that there is not enough time to get the
output of that build and spin it into a set of trees for release on
Thursday.  As such, we're slipping the release to Tuesday of next
week, August 7."

[1] https://www.redhat.com/archives/fedora-devel-announce/2007-July/msg00012....

[2] http://fedoraproject.org/wiki/Releases/8/Schedule

=== Interested in holding a session at Virtual FudCon? ===

JeffSpaleta announces in fedora-advisory-board[1],

"I am putting a draft together for the Online UnFudcon aka (Virtual
Fudcon)[2]. I've already contacted many  of the F8 Feature drivers
concerning presenting something and the draft includes those items for
which there was interest in holding a presentation. If you are part of
a fedora subproject that would like to hold a session as part of this
virtual conference, please email me and edit the draft page adding
your session topic accordingly."

[1] https://www.redhat.com/archives/fedora-advisory-board/2007-July/msg00218....

[2] http://fedoraproject.org/wiki/JefSpaleta/VirtualFudCon

=== Ask Fedora: Fedora Weekly News Column ===

RahulSundaram announces in fedora-announce-list[1],

"Fedora has a strong community of people helping each other in the
forum and fedora-list but have you always wanted to ask a question to
Fedora developers but weren't sure whom to ask? A new feature for the
next release of Fedora? Any big picture questions of general interest
to Fedora users?"

"If so, we have just the right solution for you. Send your questions
to askfedora(a)fedoraproject.org and Fedora news team will bring you
answers from the right places to selected number of questions every
week as part of our weekly news report."

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

[[Anchor(PlanetFedora)]]
== Planet Fedora ==

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

http://fedoraproject.org/wiki/Planet

Contributing Writers: ThomasChung

=== Better Fedora Collaboration ===

JohnPoelstra points out in his blog[1]

"One of my dreams for Fedora came true today. Free audio conference[2]
service is being tried out in anticipation of the upcoming Virtual
FUDCon[3]."

[1] http://poelcat.wordpress.com/2007/08/02/better-fedora-collaboration/

[2] http://mmcgrath.livejournal.com/6812.html

[3] http://fedoraproject.org/wiki/JefSpaleta/VirtualFudCon

=== Come Party With Fedora ===

JackAboutboul points out in his blog[1],

"Hey all you geeks in the valley or those making your way to
LinuxWorld Expo SF[2]! This is an open invitation to come on down and
experience Fedora like you've never experienced it before. Heck, come
experience open source, open content, free culture and lots of
giveaways the way you never have before."

[1] http://feeds.feedburner.com/~r/MadRhetoric/~3/139819960/come-party-with-f...

[2] http://www.linuxworldexpo.com/dev/12/events/12SFO07A

[[Anchor(AskFedora)]]

== Ask Fedora ==

In this section, we answer general questions from Fedora community.
Send your questions to askfedora(a)fedoraproject.org and Fedora News
Team will bring you answers from the Fedora Developers and
Contributors to selected number of questions every week as part of our
weekly news report. Please indicate
if you do not wish your name and/or email address to be published.

Contributing Writer: RahulSundaram

http://fedoraproject.org/wiki/AskFedora

== Questions and Answers ==

=== License violations ===

''Peter A. Shevtsov <webmaster(a)mera.com.ru&gt; : I know that Fedora is
so-called patents and license clear distro, so neither mp3 nor any
other proprietary technologies don't work in the base installation. As
far as I know, all software included in Fedora is GPLed (v.2 I
suppose). So, my question is the following -- what will happen if
someone violates license condition? For example, there is a company
which provides some open source solutions (like Red Hat Exchange), but
it distributes custom built (patched or something like that) RPMs of
some software -- for example their own built Apache HTTPD Server --
but do not provide sources and charge money. If I'm not mistaken this
is the case of license violation. If so, what can be done in such
situation? Are there any punished precedents of GPL violations?''


Thanks for writing, Peter, and for bringing us our first question.  To
clear up some popular misconceptions about copyright and copyright
licenses, you might want to take a look at the article from Red Hat
Magazine in May 2007[1]. While Fedora News team members are not
lawyers, we've all done enough research on licensing to give you what
we hope is a pretty complete answer to your question.

All software included in Fedora is free and open source software.  The
GPL is but one of the many free and open source licensing[2] options
available to developers.  The example you cite, for instance, is the
Apache web server, which is available under the Apache License 2.0
[3].  This license allows licensees to copy and redistribute without
requiring them to distribute source, and none of the free and open
source licenses can have any restrictions on licensees' rights to
charge money for any original work that they produce or derive.
Therefore, the cited example is not a license violation for a product
built on the Apache web server.  It would, however, be a license
violation for a product built on software licensed under the GPL (or
any of a number of other reciprocative licenses), since the GPL
requires the licensee to make source code available for any derivative
work if the work is distributed to a third party.

To more directly answer your second question, only a copyright holder
has the right to bring an action in case of a violation of a product's
license agreement.  For a program "Foobar" in Fedora, the copyright
holder is the developer of Foobar.  (The Fedora copyright statement
attributes program content to "Red Hat, Inc. and others" to make clear
that Red Hat is the copyright holder for the material it contributes,
while "others" refers collectively to all the other copyright holders
who contribute or originate other work in Fedora.)  The Free Software
Foundation has helped developers deal with enforcing GPL [4] in
multiple instances in the past and has generally been successful.  You
can read more about their licensing compliance work in the FSF site
[5]. If you're interested or want to raise awareness about GPL
violations, the GPL violations website[6] also has several public
cases.

[1] http://www.redhat.com/magazine/007may05/features/ip/

[2] http://fedoraproject.org/wiki/Licensing

[3] http://www.apache.org/licenses/LICENSE-2.0

[4] http://www.gnu.org/philosophy/enforcing-gpl.html

[5] http://www.fsf.org/licensing/compliance

[6] http://gpl-violations.org

=== Making Backups ===

''s sokol <sokolstephen(a)yahoo.com&gt; : I am an enduser and having a hard
time finding out how to backup to an external hard drive in an orderly
and automatic manner.''

Fedora has a number of backup solutions available.  The `cp` or `tar`
commands are usually not the most effective way to maintain backups.
Most advanced users and administrators recommend a system based on the
`rsync` family of utilities, which allow you -- as the name suggests
-- to synchronize two separate storage areas, such as your home
directory and an external device or network share.

Keep in mind that file system differences may affect your choice of
how to back up your data.  Linux file systems such as ext3 have
features that cannot accurately be copied directly to the VFAT file
systems found on many USB disks, or CD/DVD.  However, you can usually
write your data as specially-formatted backup files (such as `star`
format) where this information can be safely retained on such devices.

There are dozens of different solutions available. You might want to
try one or more of these packages:

 * `pybackpack` - A GNOME- and Python-based graphical backup utility;
after installation, look in ''System > Preferences > System > File
Backup Manager''
 * `kbackup` - A KDE-based graphical backup utility; after
installation look in ''Applications > Accessories''
 * `rsync` - reliable command-line program (try {{{rsync -Pavy
<source> <dest>}}} for example)
 * `BackupPC` - A complete web-based backup solution that includes
scheduling and multiple system handling

=== Future of RPM ===

''
Maxime Carron <maxime.carron(a)fedoraproject.org&gt; : can i/we have some
explanations about future of RPM.

> From what i red, 
- redhat, novell and Co start a merge of their
many patches to apply
them to the main stream (dec 2006)
- but it also exists another branch : www.rpm5.org (from an ex RH-employee)
- i heard about openpkg too (which support rpm5.org)

So my questions are : What are the news? What will happen?
Will rpm5.org and rpm.org merge?
What about openpkg?
What about CPM (Community Package Manager)? cf
http://www.redhatmagazine.com/2007/02/08/the-story-of-rpm/

Thank you. ''

After the initial announcement from Fedora Project [1] about renewed focus,
Panu Matilainen announced a new release of RPM 4.4.2.1 [2] that
includes some cleanups of the codebase, consolidation, and
introduction of several bug fixes from Red Hat, Novell and others.

rpm5.org has a different roadmap from rpm.org. Both these branches
have their own community of individuals and vendors with a existing
common codebase. They influence each other and have shared fixes in
various instances. As long as both branches retain compatibility with
the RPM spec format, the higher level tools can explore different
directions. This freedom is a inherent part of free software.

The Red Hat Magazine article to which your question refers is a short
description of some of the history behind RPM.  You can read about the
rpm.org ongoing roadmap discussions in the last week's report [3]. You
can also refer to Max Spevack's thoughts on RPM's and Fedora's future
in Linux Weekly News[4]. RPM is the underlying packaging format and a
base that Fedora builds upon using Yum and friends, and Fedora will
continue to participate in its development for the foreseeable future.

[1] https://www.redhat.com/archives/fedora-announce-list/2006-December/msg000...

[2] https://lists.dulug.duke.edu/pipermail/rpm-announce/2007-July/000001.html

[3]
http://fedoraproject.org/wiki/FWN/Issue98#head-90b3708648e89def933055ad00...

[4] http://lwn.net/Articles/237700/


=== CD Installations of Fedora 7 ===

'' R. Drew Davis <drewclist(a)rdd.name&gt; : My old PC has no DVD drive,
but Fedora 7 appears to only be distributed on DVD's.   Before Fedora
7's release, CheapBytes was accepting pre-orders for Fedora 7 on CD's,
but after Fedora 7's release, they
e-mailed me to say there wasn't going to be a CD version, so they
refunded my money.   I asked them why they couldn't make their own
custom spin of Fedora 7 on CD's and they said the Fedora license
agreement wouldn't let them call the re-spin "Fedora" and that would
make it very hard for them to sell any such version.   So what should
I do?''

Fedora provides GNOME and KDE based live images that can be burned to
a CD and installed to a hard disk or USB flash. Fedora Live images
have a subset of packages from the Fedora repository and some
configuration changes suitable for a desktop user. If you are using
Fedora on the desktop or laptop, this solution is ideal for you.

You can also install Fedora from a network using a boot or rescue
image burned to a CD.  Furthermore, you can copy the DVD image to your
hard disk and install from that.

CheapBytes or anyone else can very well create custom spins of Fedora
7 on CD's. Since they are not changing any packages in the
distribution, they are free to call it Fedora and distribute it. There
are other online and retail vendors doing similar custom spins, and
the ability to create custom spins easily is one of the primary
benefits in Fedora 7. Refer to the Fedora 7 FAQ [1] for more details.

With the merge of Fedora Core and Fedora Extras, the repository has
grown to nearly 8000 packages, which takes around 9 GB of storage
space. This repository is growing rapidly, with more packages
maintained by existing and new contributors. In the next release, the
Fedora Project plans to integrate support for additional
architectures. Fedora is distributed by hundreds of volunteer mirrors,
which would have difficulties mirroring CD variants of all these
packages and architectures. The Fedora Infrastructure team is looking
for volunteers to integrate Jidgo [2] into the release process of
Fedora as a potential solution to this problem. If you are interested
in helping, contact the Fedora Infrastructure team[3] for more
information. Thank you for your support.

[1] http://fedoraproject.org/wiki/Fedora7/FAQ

[2] http://atterer.net/jigdo/

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


=== Global changes in Fedora ===

''Martin Jürgens <martin(a)gamesplace.info&gt; : I have a question to the
Fedora Project, namely where global changes can be discussed.

I know that Bugzilla is the right way to report Feature Requests when
you exactly know how the new feature should look, but I had a more
global idea of making Fedora more end-user friendly without making
system admins unhappy (in the way of changing configuration,
installation and package managing tools, RHBZ #248259). I hoped that
some discussion with ideas would come up in the bug report, but it was
not like this. I did not get a single reply. ''

As you have noticed, Bugzilla is generally very good for reporting
specific bugs, but unsuitable for high level discussions that might
require project management and participation from multiple
contributors. As commented upon in the Bugzilla report, the better
place to discuss any changes like these is in the fedora-devel [1]
mailing list. If you want a informal chat, the #fedora-devel IRC
channel in Freenode is a good place to meet other contributors and
exchange this kind of information.

[1] http://redhat.com/mailman/listinfo/fedora-devel-list/

=== Bugzilla Responses ===

''fred <lazlow(a)charter.net&gt; : After you file a bug with bugzilla, how
do you get a response? I have several bugs filed that have sat there
for a long time and have gotten no response. Are the people that are
supposed to be looking at these bugs no longer with the project? Are
the people who should be working on F7 bugs too busy with F8? The odd
thing about it is the responses that I have received were on the bugs
that were trivial. The important bugs seem to be ignored. No request
for further information or clarification. No anything.''

Fedora as a distribution has several thousand packages being
maintained, and hundreds of packages being updated daily, and the
maintainers involved need to prioritize bug reports.  Severe security
and bug fixes get higher priority compared to other bug reports. If
the problem you reported is not specific to Fedora, you might want to
report this problem directly to the upstream project bug tracker or
mailing list.

If you do not get a response on a bug which you consider important,
you might want to verify that you have assigned the bug to the right
package and try providing more information on the problem. Log files,
hardware information and screenshots are useful depending on the
issue. (Post large sets of data by creating an attachment, not by
pasting the data directly into the comment.)  Your additional comments
or attachments will also act as a gentle reminder to the maintainers.
Contributing patches or being part of the bug triaging team [1] is
also a very good way to participate. Issues concerning security get
special attention [2]

Many of the packages are maintained by volunteers who contribute in
their spare time and other people who might have various commitments.
Fedora Project has been encouraging co-maintainership or multiple
people to work together as a team called special interest groups on
the same or similar packages to share the work. Many of the packages
are maintained in this manner. With the merge of Fedora Core and
Fedora Extras in Fedora 7, the base of contributions and the potential
for more volunteers to work in the packages which were in Fedora Core
and accessible directly only to those in Red Hat, we expect these
problems to be mitigated if not solved to a good extend. If you are
still unsure about the status, or suspect that the package is
currently unmaintained or the maintainer has not responded in a
reasonable timeframe, consider following up in an email to the
fedora-devel mailing list.  Include a reference to the bug report, and
CC the maintainer of the package in question. We understand that this
process can sometimes be frustrating and we appreciate the feedback
and support.

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

[2] http://fedoraproject.org/wiki/Security/Bugs

=== Problem with Pup ===

'' david witbeck <fifi5252(a)yahoo.com&gt; : I am completely new to Linux.
I looked at faq's and I dont see an answer. I installed fedora 6 a few
months ago and didnt use it. I got interested again and logged in . I
got a message i had 252 updates available . When I checked the "apply
updates" box I got the following message "another appliccation is
running which is accessing information".

Also I tried to install the f-stop application through the "add/remove
software " option on the applications drop down menu ,and got the same
message. Also when i do a search for yum with the search
button, there is no  yum. Isnt yum included with version 6 ?

I would really appreciate any help you could give me . Thanks''

We appreciate the detailed descriptions and error messages. To better
understand the issue, we can provide some basic information first.
Fedora package management is based on the RPM format and tool. The
{{{yum}}} application is the automatic dependency resolver that uses
RPM beneath. '''Pirut''' is the graphical frontend to {{{yum}}},
and
'''Pup''' is the  package updater.
'''Puplet''' provides desktop
notification for available package updates. A daemon or background
service called {{{yum-updatesd}}} is leveraged by '''Puplet'''.
The
{{{yum-updatesd}}} process locks {{{yum}}} and the RPM database while
checking for the presence of any updates, to prevent multiple
transactions in the database.

In the earlier versions of {{{yum-updatesd}}}, the daemon had a issue
which caused it to lock the database more often than necessary to
check updates. You can stop the daemon using the
{{{system-config-service}}} graphical utility. From the Main Menu,
choose ''System > Administration > Services'' and enter the
password
for {{{root}}}.  Locate the {{{yum-updatesd}}} service, select it, and
click the '''Stop''' button.  At the command line, you can stop
{{{yum-updatesd}}} for the current session using this command, and the
password for the {{{root}}} account:
 {{{su -c '/sbin/service yum-updatesd stop'
}}}
Then perform an update by selecting ''Applications > System Tools >
Software Updater'' from the graphical menu, or with the following
command:
 {{{su -c 'yum update'
}}}
You can permanently turn the {{{yum-updatesd}}} service off with this command:
 {{{su -c '/sbin/chkconfig yum-updatesd off'
}}}

While this particular issue has been fixed in a update, the threaded
design for performance has caused more problems, and developers have
redesigned and rewritten {{{yum-updatesd}}} to avoid further issues.
This package is currently available in rawhide, the development branch
of Fedora, and will soon be available as an update to the regular
releases.

[[Anchor(Marketing)]]
== Marketing ==

In this section, we cover Fedora Marketing Project.

http://fedoraproject.org/wiki/Marketing

Contributing Writer: ThomasChung

=== Bradley Kuhn and Max Spevack to keynote at Ohio LinuxFest ===

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

"Columbus, Ohio -- 2007 has been an exemplary year for software
freedom, which makes the keynote speakers selected for Ohio
LinuxFest[2] 2007 particularly fitting. The Ohio LinuxFest organizers
are proud to announce that Max Spevack and Bradley Kuhn will be
keynoting this year."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-August/msg0004...

[2] http://www.ohiolinux.org/about.html

=== Video: Meet the Fedora Ambassadors ===

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

"Show case[2] of impressive Brazilian team of Fedora Ambassadors. One
of the very strong regionals teams. With the Free software in Fedora
and in Brazil, this isn't a surprise though. Congrats folks."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-August/msg0004...

[2] http://www.redhatmagazine.com/2007/08/02/video-meet-the-fedora-ambassadors/

=== New extras repository for Red Hat Enteprise Linux ===

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

"If you need a software app that is not included or supported in the
standard Red Hat Enterprise Linux (RHEL) or CentOS distribution, Red
Hat's new Extra Packages for Enterprise Linux (EPEL)[2] repository
might be an excellent place to go fishing."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00096....

[2] http://fedoraproject.org/wiki/EPEL

=== Redirecting Core Dumps ===

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

"Apport[2] is a system wide crash dump handler. Will Woods, QA lead in
Fedora has been working on adopting Apport from Ubuntu and Neil Horman
is pushing some reimplemented patches upstream that is required for
this feature in true Fedora fashion. Originally targeted for the next
release, this has now been moved to Fedora 9. A important feature that
will make it easy for users to report issues. Good to keep an eye on."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00090....

[2] http://fedoraproject.org/wiki/Releases/FeatureApport

[[Anchor(Developments)]]
== Developments ==

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

http://www.redhat.com/mailman/listinfo/fedora-devel-list

Contributing Writer: OisinFeeley

=== FESCo Approves CodecBuddy ===

BrianPepple posted[1] the summary of decisions of the last (2nd Aug
2007) FESCo meeting and the link to the IRC log. Included in this was
the decision to approve the CodecBuddy and RahulSundaram wished[2]
that they'd waited until MaxSpevack had heard answers back from
"legal" about specific questions raised in FAB discussions.

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

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

MatthiasClasen asked[3] Rahul for his alternate code and also claimed
that some points raised by FAB had been addressed. Rahul pointed[4]
out that Matthias was not addressing the issues raised by FAB and that
probably no one could until legal had investigated. From this exchange
and the IRC log[5] it seems that the implementors of "codeina" /
CodecBuddy believe that creating a Fedora Project controlled web-page
will ward off the evil eye of patent lawyers.  There was not an
extensive discussion even given the caution expressed by
DavidWoodhouse (dwmw2) and others. The IRC log records a tentative
approval subject to FESCo input to the content of the webpage.

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

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

[5] http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070802

=== The Future Of Yum ===
An enigmatic opening post from FlorianFesti [1] tantalized by
suggesting that "whois yum4.org" and "whois yum5.org" would be
interesting. The actual pages were the default test-page distributed
with Fedora's httpd package.  Following up on Florian's hint revealed
JeffJohnson ex-Red Hat RPM developer and leader of the rpm5.org fork
(see also FWN#98 "RPM Roadmap...Panu Opens Pandora's Box"[2].)

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

[2]
http://fedoraproject.org/wiki/FWN/Issue98#head-90b3708648e89def933055ad00...

SethVidal, as the originator of "yum", was entertained[3] and wondered
whether he should release successive versions numbered by squaring the
previous version number. Some creative suggestions followed.

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

A good laugh was also being had by RobertScheck[4], who claimed that
yum4/5 will be written in C instead of python and suggested that
PanuMatilainen rip out Python and maybe even PERL support in RPM along
with HTTP and FTP. RahulSundaram wasn't amused[5] by the lack of
courtesy shown in creating a misleadingly similar project name and
also thought that as Robert was involved in a fork he should
concentrate on that instead.

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

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

The thread ended[6] as enigmatically as it had begun with
IgnacioVazquezAbrams asking Robert to let him "know when wnh is
ready".

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

=== Kqemu In The Kernel?  ===

A belated response[1] from "dragoran" to a 16 June 2007 thread on the
absence of kqemu from Fedora argued that it recompiled without much
trouble although it was large. DaveJones responded[2] that kqemu
wasn't merged upstream (the kernel) and that Fedora was trying to stay
close to upstream to make rebasing easier.  Dave was of the opinion
that although Fedora was getting better in this regard it still sucked
(wireless was singled out) and he didn't want to undo the progress.

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

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

PaulWouters seemed to think[3] that this was a duplicitous answer as
many of the concerned upstream people are also Red Hat developers on
this very list.  RahulSundaram asked where the patches had been
submitted upstream and "dragoran" answered that no one had done so.
Rahul disparaged[4] the idea that "politics" or "Red Hat developers"
were relevant to the issue and suggested trying to get the Fedora
kernel maintainers to patch the kernel was futile unless upstream did
it first. AlanCox had empirical evidence[5] that no one was very much
interested in kqemu.

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

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

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

=== Kmods Clarified ===

Following on from the discussion of kqemu above (FWN#99 "Kqemu In The
Kernel?" and last week's slightly misleadingly titled FWN#98 "Kmods
Deprecated"[*]) "Kelly" wondered[1] why DKMS[2] wasn't in the main
repository as s/he found it an invaluable means of managing
non-standard kernel modules.  JefSpaleta corrected[3] Kelly with the
information that DKMS was actually available and Kelly rephrased the
question to ask why couldn't kqemu be included in the main repository
as a DKMS module? The advantage Kelly perceived over including kqemu
in the kernel would be that they could be upgraded separately.

[*] 
http://fedoraproject.org/wiki/FWN/Issue98?action=show&redirect=FWN%2F...

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

[2] http://linux.dell.com/projects.shtml

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

The responses mostly rehashed the older debates on this subject and
ToddZullinger pointed this out[4] along with the need to avoid
packages that require compilation tools which is implicit in the DKMS
approach.  ThorstenLeemhuis followed up[5] with a link to the last
discussion (in Jan 2007) which included a clear argument[6] from
JeremyKatz that the problem of multiple different databases for
tracking installed software and the realistic lack of a stable
upstream kernel interface meant that DKMS was not a preferred
solution.  Thorsten suggested that Kelly review this entire earlier
discussion because if nothing had changed in the interim then there
was no point in replaying it, especially as kmods were on their way
out.

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

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

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

JesseKeating was quick to point out[7] that kmods as separate packages
were deprecated but that kmods in the kernel rpm as out of tree
modules were a preferred solution. Also included in Jesse's list of
advantages was the fact that the kernel maintainers would excercise
the same criteria for kernel modules as for the kernel. In response[8]
Thorsten re-iterated that he was in agreement with parts of the
decision but still saw the advantages of providing an "alphaworks"
space which provided kernel modules.  Thorsten also wondered about the
apparently conflicting messages with some developers within Red Hat
favoring a packaging standard like DKMS developed in Fedora while
"some Red Hat people [were] kick[ing] kernel modules out of Fedora
now."

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

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

LesMikesell argued[9] the advantages of a stable interface to the
kernel for RHEL so that 3rd party modules upon which customers rely
were not broken on updates.  A fairly longish thread followed with
some interesting examples backing up this viewpoint including one from
PaulWouters (who advanced the OpenSWAN case).  The problem with this
argument was pointed out by ToddZullinger who noted that RHEL spends
developer time on constantly backporting to provide this stability and
that Fedora did not have this model.  Todd suggested that the majority
using Fedora preferred a rapidly updated kernel as opposed to a stable
ABI and that CentOS and RHEL existed for people whom this did not
suit.

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

=== LiveCD Wipes Root Partition ===
A remarkably calm MichelSalim reported[1] that an attempt to do a
clean-install of Fedora7 from the LiveCD while retaining his old
"/home" by explicitly requesting anaconda not to reformat "/" had
resulted in anaconda ignoring the request and reformatting "/".

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

There were several indications during the process that anaconda seemed
to be doing the right thing (including a warning that retained files
might interfere with the installed system).  Michel wanted to know his
best strategy for recovering his data and consequently the details
about how the LiveCD worked.

DouglasMcClendon was a mine of information and confirmed[2] that the
absence of a warning dialogue which clarifies that "/" will be
reformatted is a horrible bug and was surprised no one had reported it
before now.  He also confirmed that anaconda copies the whole image
over from the CD using "dd" into a newly reformatted (at least) 4.0GB
"/" partition and subsequently copies "/usr" and "/var" and
other
filesystems  from this into separate partitions (if they exist). Doug
was hopeful that data beyond that 4GB limit would be recoverable to
some extent.

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

Further discussion between Douglas and Michel elucidated[3] the point
that F7 is the first time this LiveCD install option has been
available and the worrying warnings probably steered testers clear.
Douglas discussed his "turbo" version of the installer and the
potential of an alternate file-level copy installation mechanism
(which would also solve the non-ext3 root fs problem).  In response to
Michel's suggestion of a FreeBSD-style default /home partition Douglas
described his strategy of creating a preserved subdirectory within
/home (which also had copies of dotfiles) and this then allowed
"wipegrades".  A default preservable /home partition would aid this
strategy.

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

Michel expanded[4] on this with the idea that the distinction wasn't
so much /home and /, but rather RPM-managed vs non-RPM-managed (and
hence preservation worthy).  Michel wondered how Ubuntu and OpenSUSE
were coping with this in their new LiveCDs.  RahulSundaram thought
that every LiveCD used the "dd" strategy, but Douglas corrected this
with the information[5] that copy-on-write is implemented using
unionfs on Ubuntu whereas devicemapper-snapshot is used on Fedora.

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

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

=== RPM Roadmap (Cont.) ===
The excellent discussion initiated last week by PanuMatilainen (see
FWN#98 "Panu Opens Pandora's Box"[1]) continued apace without a break.
TillMaas wanted[2] rpmbuild to internalize the common part of the
Fedora specs including setting up a sane buildroot, cleaning up and
setting attributes. Till noted the five lines saved in each spec file
as a result of this.  DimiPaun wasn't interested in saving the five
lines, but agreed[3] that Till's proposal would be correct because the
rpmbuild should be telling the specfile where the buildroot is instead
of vice-versa. Dimi also proposed that attempts to set the buildroot
or "rm -rf" by the specfile should be ignored and should issue
warnings.

[1]
http://fedoraproject.org/wiki/FWN/Issue98?action=show&redirect=FWN%2F...

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

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

The problem which this would create for backwards compatability was
explored when JasonTibbitts agreed[4] with Dimi's suggestions with the
exception of ignoring specfile initiated buildroot setting and
clean-up, pointing out EPEL4 as an instance. Panu wearily welcomed[5]
us to the "world of rpm: people want progress but no change" and
wondered about forking the specfile format, but Rahul thought[6] that
would only work with a new parallel-installable version of RPM in
order to be able to deal with the legacy issue.

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

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

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

RobertScheck thought[7] that the macros in /usr/lib/rpm ought to be
used to implement Till's suggestions. Till answered[8] with the
argument that reliance on macros in this way would mean the spec was
not generally useful for non-Fedora distributions.  A minor
sub-discussion about non-sane specfiles creating dangling symlinks
followed.

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

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


Another desired feature was "sandbox" support, requested[9] by ZCMiao
who noted Gentoo's implementation of ebuild, but KevinKofler responded
that "mock" was the appropriate way to test unsafe code builds.

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

"Nodalus" argued[10] against stripping out HTTP/FTP capabilities on
the grounds that bootstrapping would become awkward and wondered if a
solution would be to leave these features but enable RPM to use
superior external methods when/if detected.  JesseKeating, GilboaDavra
and HorstvonBrand argued variously that a rescue environment with
tools to add/remove content via a chroot, a plug-in system for
resource poor systems and security problems were all good reasons not
to implement "nodalus'" proposal.

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

A dream[11] which MatthiasSaou would like to come true is the
automatic cacheing of all %config files which would allow diffs to be
shown against the original state.  This spawned a certain amount of
interest in using a version-control system to manage these files, with
IanBurrell promoting[12] the idea of a hook which could call an
external VCS if needed. TheodorePapadopoulo was inspired[13] to
describe a use-case where it would be advantageous to extend RPM to
deal with rpms which have the sole purpose of over-riding the config
files of some other rpm.  BillCrawford was cautiously encouraging[14]
but also suggested the workaround of replacing redhat-release with a
hand-rolled version and repackaging the software with new config
files.  Similarly, EmmanuelSeyman suggested[15] repackaging with the
addition of using something like "cfengine" to centralize the changes
in a reproducible manner.  JefSpaleta[16] and TonyNelson[17] also
thought that Matthias' suggestion was a good one.

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

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

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

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

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

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

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

AxelThimm requested[18] fixing whatever minor bugs cause rpm to choke
on fakeroot/fakechroot some of the time and advanced the security
benefits as one of the reasons plus the expansion of possible
packagers in the form of students without root accounts.  JesseKeating
was keen on something like this for Koji too, and Panu requested
further reproducible bug details.

[19] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01766.html

There were a hell of a lot of other excellent suggestions, including
RalfCorsepius' concrete suggestions for what should be done to make
the current rpm codebase usable.  Panu was strongly in agreement with
Ralf on these points and requested[20] his autotool expertise.

[20] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01816.html

NilsPhilippsen wanted[21] to get rid of the 2GB limit and hence cpio,
which led to a discussion of compression[21a]. (MichaelSchroeder of
SuSE clarified[22] that the 2GB limit applies to single files not the
entire RPM). AdamJackson (ajax) thought that POSIX 2001 tar might[23]
make a worthy replacement and cast doubt on the sanity of using the
same package manager across multiple systems.  AlanCox defended[24]
ErikTroan's original choice of cpio and argued that a single package
manager across multiple systems had been shown to be both profitable
and useful.  Surprisingly it seemed that there are several [25][26]
possible uses of RPMs containing files greater than 2GB.

[21] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00025.html

[21a] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00100.html

[22] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00064.html

[23] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00037.html

[24] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00069.html

[25] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00074.html

[26] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00106.html

One of the most informative posts came from Panu himself and
explained[27] the problem with adding architecture specific requires
and provides as requested last week by "dragoran" to solve the
multilib problem.

[27] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00056.html

There's a lot more to this thread which is worth reading but can't be
adequately summarized.

=== KDE4 Status ===
A notice[1] from JosPoortvliet (of the KDE Promo group) advised that
the first beta of KDE4 would be released soon and wondered whether it
would be in Fedora 8.  Since then the beta has actually been released
(Aug 2nd 2007)[1a]. Jos wanted to be able to mention Fedora8 in the
release notes.

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

[1a] http://www.kde.org/announcements/announce-4.0-beta1.php

The issue had been discussed earlier (see FWN#89 "KDE4 For Fedora8
Draft Document Discussion"[2]) by KevinKofler and JeremyKatz with
attention paid to the problem with clashing sonames between KDE3 and
KDE4 and the inadvisability of delaying the Fedora8 release-schedule
in the hope that the KDE release-schedule was cast in stone.

[2]
http://fedoraproject.org/wiki/FWN/Issue89#head-51fa717561e1d1e16b73bec573...

This time around there was a top-posted attempt[3] at encouragement
from "MarkG85" to the Fedora-KDE SIG to "make packages" of KDE4.
Responses from the folks producing the KDE desktop for the Fedora
Project were fairly uniform.  ChrisBrown noted[4] his personal
experience with the complexity of the task of maintaining a complete
desktop environment, and also the inadvisability of rushing poorly
constructed packages into the distribution.  "MarkG85" thought that
F8t1 would be a good place to test the packages to which KevinKofler
responded[5] that F8t1 was already frozen.

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

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

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

GilboaDavara shared[6] the concerns of Kevin and RexDieter that
KDE4beta2 would be released a mere 3 days before the Fedora8
feature-freeze which would mean that there would be very little
testing in rawhide.  Gilboa wondered whether KDE4beta2 would be
feature complete and, in a recapitulation of the FWN#89 discussion[2],
whether it was parallel installable.

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

RexDieter invited anyone interested in speeding things up to join the
effort at the Fedora KDE SIG and ArthurPemberton requested an
appraisal of the chances of KDE4 in Fedora8 and suggested a qemu image
for testing if parallel-installation of KDE4 and KDE3 were impossible.
Rex's response[7] was to draw a distinction between the complete KDE4
desktop, which has a 50/50 chance of making it in depending on
release-schedule slippage, and some bits of KDE4 which will without
doubt make it in.  Rex was warmly welcoming of anyone that wanted to
help out with a qemu-image.

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

=== Package Management: Goats Satisfied With Current Situation ===

RichardHughes continued[1] to think hard about the problems of
software installation and wanted other people to join him. Richard
outlined a series of use cases which might form the basis on which to
make decisions about how package management should be implemented.

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

The first substantive comment[2] came from AlanCox who thought that
Richard's security model needed refinement as it made it too easy for
uninformed users to install malware.  Two other important points which
Alan identified were: the absence of install-time distinction of
install types (which limits the automounting of filesystems and Ubuntu
style sudo); and the need for revoke() in the kernel[3] in order to
allow multiple users to install packages after switching desktop user.
 Alan identified three install types: user-managed; centrally-managed;
and physical-access.

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

[3] The revoke() syscalls are not yet in the kernel although they are
in the -mm branch.  They allow a file (or other resource) to be
revoked and all processes which have the file open receive an error.
http://www.uwsg.iu.edu/hypermail/linux/kernel/0701.3/1344.html

Richard thought[4] that most of the problems which Alan identified
with security were ones that could be handled using PolicyKit and
defining the repositories from which authenticated users could install
software. There was also strong agreement that the revoke() system
calls were important "Yes. Take a stapler gun and start firing it into
the air until it's merged" but also optimism that 90% of the
FastUserSwitching could be achieved without it.

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

A short response from ColinWalters disagreed with AlanCox and
suggested that there were only two cases to be considered, namely:
1)that of a user responsible for the machine (who should be able to
install any package from the default CD set); 2)that in which the user
is not responsible, but an admin is and they should be able to set
policy in any way.  RichardHughes requested[5] that Colin add this to
PackageKit[6].

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

[6] http://live.gnome.org/PackageKit

A significant number of the comments expressed concern about the idea
of making it easier for users to install software.  EmmanuelSeyman's
raising of the point with regard to any logged-in user was answered[7]
by Richard invoking the use of PolicyKit to allow the admin to
arbitrarily enforce any desired policy. A very strong version of the
argument was presented[8] by HorstvonBrand who had concerns about the
amount of disk-space and bandwidth that would be consumed if the
laxity of Richard's suggested use-cases were permitted.  Horst thought
that a simple configuration using sudo and yum would solve the problem
without much trouble.  Richard replied that this was true only for
some users and didn't cover the case of the non-technically adept.

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

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

PaulNasrat drew[9] Richard's attention to the Klik package-management
system[10] which attempts to rethink some aspects of
package-management (mainly by assuming the LSB as standard).  Paul
wanted Richard to make his use-cases a little clearer as regards their
administrative role and also was concerned with the need for more
metadata in packages (perhaps obtained using mime/file(1) info) in
order to allow the system to suggest appropriate applications when
users wish to access particular files. Again the issue of bandwidth
and trust was raised with Paul pointing out that automatic updates
over GPRS wouldn't be nice.  NicuBuculei suggested[11] expanding the
information gathered and stored by Mugshot to help with the metadata
problem. (Convergence with other Mugshot features was also discussed
in FWN#98 "Package Management Craic"[12]).

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

[10] http://klik.atekon.de/

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

[12]
http://fedoraproject.org/wiki/FWN/Issue98#head-2e4823600525c6129df7d1944e...

=== FESCo Ratifies Changes To "License:" Tag In RPM SPECs ===

On the foot of recent extensive discussions (see FWN#98 "NOTE:Please
publicize any license changes to your packages (CONT.)"[1]) a friendly
announcement[2] from TomCallaway (spot) communicated the decision of
FESCo (2 Aug 2007) to require every package to have a "License:" tag
formatted in a way which allows some automated checking for
incompatibilities. Spot provided a list of acceptable licenses and
answers to predictable questions.

[1]
http://fedoraproject.org/wiki/FWN/Issue98#head-98f4908dba5aeb4008843b233e...

The positive tone of the posting encouraged specific requests for
information which displayed a few common themes.  One was that
alerting upstream projects of unclear or apparently contradictory
licensing problems .  JakubJelinek pointed out[2] the potential for
one such problem when he thought that Spot's wording concerning the
presence of L/GPL "or any later version" should emphasize that all
files in a program should be examined for consistency in this regard.
Jakub asked for clarification using the example of "glibc" which
contains LGPL2.1 or later libraries certain files of which have
exceptions allowing linking to proprietary code, and also contains
GPL2 or later executables and some erroneous GPL2 only executables.
Spot provided[3] the License-tag "License: LGPLv2+ and LGPL with
exceptions and GPLv2+" under the assumption the package would contain
corrected versions of the executables and thought that Jakub's
description exemplified the sort of breakdown that should be included
in the spec comments. A very similar question was posed by
JasonTibbitts about the "ypbind" package which seems to have
contradictory information in the source and the manpage. Spot's answer
was to get upstream to sort it out, but that source-code trumps all[4]
in the event of this not occurring.

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

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

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

The question of how necessary this all is was floated[5] by TomLane
while he tried to sort out his "mysql" package. Tom echoed
JasonTibbitts suspicion that Fedora will be more organized than most
upstream projects and that things are going to be complicated, perhaps
unnecessarily so.  In support of this Tom noted that many of the
popular graphics libraries (libtiff, libpng and libjpeg) have BDS-ish
licences and that his long involvement with them made clear to him
that their spirit was intended to be BSD.  This made the existence of
a distinctly separate "zlib/libpng" license in Spot's list a little
surprising to Tom.  JesseKeating thought[6] that if those projects had
really intended to use BSD licensing then they would have and it was
best not to assume anything and to try and be specific.  Spot
assured[7] Tom that his intent was not to cause pain, but to make
license-auditing easier for the Fedora Project and offered to try to
pigeonhole any licenses which Tom wished to send him.

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

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

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

The impact on the buildsystem was considered[8] by HansdeGoede who
thought that it would be better to update the CVS devel-branch and
avoid rebuilding until a more convenient time as otherwise this would
effectively be triggering a mass rebuild.  Hans also asked how freely
distributable, non-modifiable content should be tagged (e.g. much
firmware).  JesseKeating listed[9] other outstanding issues that might
trigger a mass rebuild (BuildID, IceTea for Java, all ppc32 due to
SELinux problem) and agreed[10][11] with Hans and Spot that it would
be best to just tag in CVS-devel and add the license tagging as
another item for a synchronized rebuild to minimize churn.

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

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

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

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

Hans had further pertinent[12] points with regard to the zlib/libpng
short-form license tag (which seemed to deviate from rpmlint's
preferences) and also the licensing of non-modifiable game content.
VilleSkyttä[13] reassured Hans that the latest rpmlint (0.80-2) was
consistent with the new packaging guidelines thanks to work by Spot.
The games issue was admitted to be an oversight by Spot who
thanked[14] Hans for pointing it out.

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

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

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

An error in the license table on the wiki was flagged[15] by
GianlucaSforna and later corrected.

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

JefSpaleta wondered what to do when a package contains some "GPLv2 or
later" files and other "GPL2 only" files and was answered[16] by
JoshBoyer that the package should be then tagged as "GPL2" only as the
principle is that the stricter of the licenses should be used.

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

In closing it should be noted that Spot is apparently willing to take
any further license queries and is also seeking help from anyone else
interested in getting involved with helping in this area.
RahulSundaram has stepped forward[17] to assist.

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

[[Anchor(Maintainers)]]
== Maintainers ==

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

https://www.redhat.com/mailman/listinfo/fedora-maintainers

Contributing Writer: MichaelLarabel

=== EPEL Repository Continues To Expand ===

EPEL (or Extras Packages for Enterprise Linux[1]) has been making news
in recent weeks after it officially opened up a while back. In this
week's EPEL report[2] the number of packages for EPEL 5 has risen by
30 to a total of 872 binary packages while the EPEL 4 repository is up
by 31 for a total number of 596 binary packages.

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

[2] https://www.redhat.com/archives/fedora-maintainers/2007-July/msg00441.html

[[Anchor(Documentation)]]
== Documentation ==

In this section, we cover the Fedora Documentation Project.

http://fedoraproject.org/wiki/DocsProject

Contributing Writer: JonathanRoberts

=== Virtual Fudcon Ideas? ===

With the upcoming virtual Fudcon, KarstenWade sent a message to the
list requesting ideas for sessions that the DocsProject might run[1].
Initial suggestions included how to work on docs in the wiki and XML
skills, with practice.

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

=== Documentation Project Steering Committee Meeting ===

The log[1] and the summary[2] of the FDSCo meeting held on 07/31 were
posted to the list.

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

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

=== Fedora 8 Test 1 Release Notes ===

RahulSundaram wrote to the list requesting help with creating the
release notes for Fedora 8 Test 1[1]. This prompted PaulFrields to
suggest that this would be the ideal task for a new contributor, with
help available if they need it[2].

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

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

[[Anchor(Infrastructure)]]
== Infrastructure ==

In this section, we cover the Fedora Infrastructure Project.

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: JasonMatthewTaylor

=== Operating Procedures ===

MikeMcGrath has documented some SOP's[1] for the infrastructure team
and is looking for people to review them.

[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-August/ms...

[[Anchor(Artwork)]]
== Artwork ==

In this section, we cover Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: JonathanRoberts

=== Echo Used on translate.fp.org ===

DimitrisGlezos wrote to the list to announce that, on the new
translate.fedoraproject.org, he has made extensive use of the Echo
icon set[1].

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

=== Virtual Fudcon ===

NicuBuculei, having just read about the virtual Fudcon, writes to the
list to propose that the art team take part[1],  proposing the
possibility of a hackfest on a number of possible projects.

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

=== Round 2 Deadline ===

The deadline for round 2 submissions has been extended to Monday 6th
August, to provide contributors one more week to polish their
submissions[1]. For a submission to be considered for round 2 it must
have at least one wallpaper proposal, and three supporting graphic
proposals. Supporting graphics can include a vertical banner for first
boot, a horizontal banner for Anaconda, banner for fedoraproject.org,
CD label etc.

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

[[Anchor(SecurityWeek)]]
== Security Week ==

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

Contributing Writer: JoshBressers

=== Firefox 2.0.0.6 ===
Firefox 2.0.0.6 was released this week.  Neither Fedora or Red Hat
Enterprise Linux will see this version.  Here is why.

This update fixes these two flaws:

 * MFSA 2007-27: Unescaped URIs passed to external programs[1]
 * MFSA 2007-26: Privilege escalation through chrome-loaded
about:blank windows[2]

[1] http://www.mozilla.org/security/announce/2007/mfsa2007-27.html

[2] http://www.mozilla.org/security/announce/2007/mfsa2007-26.html

The reason the Mozilla Foundation released this update was primarily
to address MFSA 2007-27.  This is a rather serious flaw regarding to
how Firefox hands URIs to external helper programs.  This flaw does
not affect Linux as helper applications are launched in an understood
and controlled manner.  The other flaw, MFSA 2007-26, is a rather
minor flaw that has been rated as being of moderate severity.  It
involves how certain Firefox extensions create new windows.  In
general this flaw is harmless and upstream wanted to fix it since it
was a regression from the 2.0.0.5 update.

A lot happens behind the scenes anytime there is an update of Firefox,
Thunderbird, and Seamonkey.  Apart from a great deal of developer and
QA time, this translates into lost time for users as well.  Vast
quantities of bandwith are consumed to download the updates, then the
various plugins must be updated.  It was decided that it would be a
great disservice to the users to squander the available recourses for
an update they don't need.

Obviously, if you run Firefox on Windows, you best get this update, as
the flaw is rather serious there.

=== Hacking via IPS Signatures ===

An Intrusion Prevention System (IPS) is supposed to stop malicious
attacks from ever happening.  In general most security researchers
worth their salt feel these systems are a waste of time and money.
They fall into the classification of security theater, or something
that doesn't actually make you more secure, it makes you think you are
more secure.

An article on Dark Reading[1] claims something that has been
suspected, but unproved, for a very long time about IPS vendors.
Their 0day vulnerability signatures, aren't very 0day.  One of the
ways IPS vendors try to add value is to include currently unknown
vulnerabilities they discovered.  The way this works is they acquire
information about a security flaw, create an IPS signature for it, add
the signature to their product, then tell the vendor.  The article
from Dark Reading suggests that attackers are using the signatures to
figure out what the vulnerability is, then leveraging the fact that
it's not fixed in the vendors product.

How this will be handled by various vendors is now a vary real
question that needs to be addressed.  We shall see where it goes.

[1] http://www.darkreading.com/document.asp?doc_id=130313&WT.svl=news1_1

[[Anchor(DailyPackage)]]
== Daily Package ==

In this section, we recap the packages that have been highlighted as a
Fedora Daily Package.

[1] http://dailypackage.fedorabook.com/

Contributing Writer: ChrisTyler

=== Gobby - Collaborative editor ===

''Productive Mondays'' highlight a timesaving tool. This Monday[1] we
covered Gobby[2]:

"Gobby is a collaborative editor which enables multiple people to
simultaneously edit a group of documents. ... Gobby also enables
cross-platform collaboration: MS Windows and (limited) Mac OS/X
clients are available from the upstream website."

[1]
http://dailypackage.fedorabook.com/index.php?/archives/107-Productive-Mon...

[2] http://gobby.0x539.de/trac/

=== Netpbm - Utilities for graphic manipulation ===

''Artsy Tuesdays'' highlight a graphics, video, or sound application.
This Tuesday[1] Netpbm[2] was featured:

"Netpbm is a venerable collection of over 300 short programs that
manipulate graphics files."

[1]
http://dailypackage.fedorabook.com/index.php?/archives/108-Artsy-Tuesday-...

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

=== Wednesday Why: Colour ls ===

The ''Wednesday Why'' article[1] took a look at the colour-coding
capabilities of GNU 'ls' and Fedora's default configuration of these
features:

"By default, the Fedora 'ls' command colour-codes file listings when
they are displayed on a virtual terminal or terminal window, but not
when they are piped into another command."

[1]
http://dailypackage.fedorabook.com/index.php?/archives/109-Wednesday-Why-...

=== Xnest - A nested X server ===

''GUI Thursdays'' highlight software that enables, provides, enhances, or
effectively uses a GUI interface. This Thursday[1], Xnest[2] was
discussed:

"Xnest is a nested X server: a display that runs in a window within
another display. It's useful for testing GUI applications as a
different user, trying out several desktop environments at the same
time, or getting screenshots of the login process."

[1]
http://dailypackage.fedorabook.com/index.php?/archives/110-GUI-Thursday-X...

[2] http://x.org/

=== Kbilliard - Billiard simulator game ===

''Friday Fun'' highlights fun, interesting, and amusing programs. This
Friday[1], we took a look at Kbilliards[2]:

"Kbilliards is a billiard game simulator. As the name implies, it's
KDE-based. You can play against yourself, another user, or the
computer. When you start a new game, you can also select 'Training
Mode', which enables you to move any ball to set up complex practice
shots."

[1]
http://dailypackage.fedorabook.com/index.php?/archives/111-Friday-Fun-Kbi...

[2] http://www.hostnotfound.it/kbilliards.php

[[Anchor(AdvisoriesUpdates)]]
== Advisories and Updates ==

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

Contributing Writer: ThomasChung

=== Fedora 7 Security Advisories ===

 * [SECURITY] gdm-2.18.4-1.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1362
 * [SECURITY] GraphicsMagick-1.1.8-2.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1340
 * [SECURITY] tcpdump-3.9.7-1.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1361
 * [SECURITY] xorg-x11-xinit-1.0.2-21.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1409
 * [SECURITY] xpdf-3.02-1.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1383

=== Fedora Core 6 Security Advisories ===

 * [SECURITY] gdm-2.16.5-2.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-653
 * [SECURITY] tcpdump-3.9.4-11.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-654

[[Anchor(EventsMeetings)]]
== Events and Meetings ==

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

Contributing Writer: ThomasChung

=== Fedora Board Meeting Minutes 2007-07-31 ===

 * https://www.redhat.com/archives/fedora-advisory-board/2007-August/msg0000...

=== Fedora Ambassadors Meeting 2007-MM-DD ===

 * No Report

=== Fedora Documentation Steering Committee 2007-07-31 ===

 * https://www.redhat.com/archives/fedora-docs-list/2007-July/msg00093.html

=== Fedora Engineering Steering Committee Meeting 2007-08-02 ===

 * https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00203.html

=== Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-08-01 ===

 * https://www.redhat.com/archives/epel-devel-list/2007-August/msg00014.html

=== Fedora Infrastructure Meeting (Log) 2007-MM-DD ===

 * No Report

=== Fedora Packaging Committee Meeting 2007-07-31 ===

 * https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00010.html

=== Fedora Release Engineering Meeting 2007-07-30 ===

 * https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01784.html

=== Fedora Translation Project Meeting (Log) 2007-MM-DD ===

 * No Report

-- 
Thomas Chung
http://fedoraproject.org/wiki/ThomasChung