Fedora Weekly News Issue 98

Thomas Chung tchung at fedoraproject.org
Mon Jul 30 08:05:34 UTC 2007

= Fedora Weekly News Issue 98 =

Welcome to Fedora Weekly News Issue 98 for the week of July 22nd,
2007. http://fedoraproject.org/wiki/FWN/Issue98

In this week, we have great announcements for Extra Packages for
Enterprise Linux (EPEL), 3000 Fedora 7 Installations as well as FESCo
Election Results. Also we are launching a special section called 'Ask
Fedora' where you can ask questions to Fedora Project.

In Developmets, there are more than enough interesting discussions
including RPM Roadmap, Fedora Sound System, Desktop Menus, Licensing
and more. In Security Week, our Security Response Team reports a
dangerous Firefox Flaw. In Daily Package, you'll find reviews of
Fedora packages including Incron, eSpeak, Syslog, Seamonkey,

To join or give us your feedback, please visit

   1. Announcements
         1. Extra Packages for Enterprise Linux (EPEL) Now Open
         2. 3000 Fedora 7 installations
         3. FESCo Election Results
   2. Planet Fedora
         1. Improving package and system management
         2. First rpm.org-RPM version released
   3. Ask Fedora
   4. Marketing
         1. Fedora 8 To Integrate OpenJDK
         2. A computer in every pot
         3. Fedora stats offer insight into Linux usage
   5. Developments
         1. RPM Roadmap ... Panu Opens Pandora's Box
         2. Package Management Craic[*]
         3. Pulseaudio Improving Fedora Sound
         4. What Should Appear In Desktop Menus
         5. Kmods Deprecated
         6. New Yum-updatesd (Rawhide Report 20070725)
         7. NOTE: Please publicize any license changes to your packages (CONT.)
         8. Extra Packages for Enterprise Linux (EPEL) Now Open
         9. Abuse Of Fedora Trademark
        10. XFS In Anaconda
   6. Translation
         1. F7 Release Notes Update
   7. Infrastructure
         1. Sponsor HowTo's
   8. Artwork
         1. Echo Icons Moved
         2. Nodoka Engine 0.5 Released
         3. Fedora 8 Theme Decisions
   9. Security Week
         1. Dangerous Firefox Flaw
  10. Daily Package
         1. Incron - Execute commands based on filesystem activity
         2. eSpeak - Voice synthesizer
         3. Wednesday Why: Syslog
         4. Seamonkey - Mozilla suite
         5. BSD-Games: Text games
  11. Advisories and Updates
         1. Fedora 7 Security Advisories
         2. Fedora Core 6 Security Advisories
  12. Events and Meetings
         1. Fedora Board Meeting Minutes 2007-MM-DD
         2. Fedora Ambassadors Meeting 2007-07-26
         3. Fedora Documentation Steering Committee 2007-MM-DD
         4. Fedora Engineering Steering Committee Meeting 2007-07-26
         5. Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-07-26
         6. Fedora Infrastructure Meeting (Log) 2007-07-26
         7. Fedora Packaging Committee Meeting 2007-MM-DD
         8. Fedora Release Engineering Meeting 2007-07-23
         9. Fedora Translation Project Meeting (Log) 2007-07-24

== Announcements ==

In this section, we cover announcements from various projects.

Contributing Writer: ThomasChung

=== Extra Packages for Enterprise Linux (EPEL) Now Open ===

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

"If you use enterprise-class Linux (EL) distributions derived from
Fedora, such as Red Hat Enterprise Linux or CentOS, we have something
very exciting for you."

"EPEL[2] is a community of package maintainers working from inside of
Fedora.  Many are the same people who maintain the Fedora version.  Yet,
there room for new packages and contributors.  Currently, around 1000
packages are available, and we've been growing at the rate of several
dozen packages every week."

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

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

=== 3000 Fedora 7 installations ===

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

"After a long discussions and few presentation, i have convinced
Mozambique[2] Ministry of Finance (SISTAFE) to migrate their
workstation around the country from MS Windows to Linux (Fedora 7),
now they have officially approved the migration country wide and i
will supervise this migration, plus will help them in end user
training, its the first time in Mozambique that a Govt. department
have opt for Linux (Fedora) and in my opinion it has been a big
achievement, as after their migration i will be able to speak with
other ministries and private firms."

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

[2] http://en.wikipedia.org/wiki/Mozambique

=== FESCo Election Results ===

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

"The FESCo[2] election is over, and the members for the 2007/2008
FESCo are (in alphabetical order):
ChristopherAillon, JoshBoyer, TomCallaway, KevinFenzi, DennisGilmore,
ChristianIseli, JeremyKatz, JesseKeating, BillNottingham, BrianPepple,
JasonTibbitts, WarrenTogami, DavidWoodhouse"

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

[2] http://fedoraproject.org/wiki/Development/SteeringCommittee

== Planet Fedora ==

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


Contributing Writers: ThomasChung

=== Improving package and system management ===

RahulSundaram points out in his blog[1],

"The most important improvement of course is the ongoing development
of wevisor[2], which as the name indicates is a web interface to
revisor that lets you do custom spins of Fedora. Kickstart
configuration files can be fed into a number of places such as live cd
tools, revisor and wevisor and adds a whole lot of customisability to

[1] http://rahulsundaram.livejournal.com/12108.html

[2] http://hosted.fedoraproject.org/projects/wevisor

=== First rpm.org-RPM version released ===

RolandWolters points out in his blog[1],

"Recently the first version of rpm.org[2]'s RPM tool was released.
While it is only a minor version ( this release is a
milestones because it is a coordinated release between the
participating distributions."

[1] http://liquidat.wordpress.com/2007/07/24/first-rpmorg-rpm-version-released/

[2] http://rpm.org/

== Ask Fedora ==

Beginning this week, we will collect good and useful questions from
users for this special section called 'Ask Fedora'.

Contributing Writers: RahulSundaram, ThomasChung, PaulFrields, ChrisTyler

Questions should exclude topics which are best answered through
existing mechanisms. This shouldn't be for "my soundcard doesn't work"
questions; it should be for big-picture questions of general interest.

Esoteric hardware troubleshooting problems are a deal-killer, but more
general help questions like "How do I edit my menus?" or "How do I
find source code for <FOO>?" are good targets.

To submit your questions, please use askfedora at fedoraproject.org and
our news team will *try* to find the best answers and post in the
following issue.

== Marketing ==

In this section, we cover Fedora Marketing Project.


Contributing Writer: ThomasChung

=== Fedora 8 To Integrate OpenJDK ===

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

""One of the most recently added features to the Fedora 8 feature list
is IcedTea[2], which is the open-source version of Java (OpenJDK). The
plan is to make IcedTea the default JPackage environment and will
replace GCJ. There are Fedora packages for IcedTea already maintained
(at ClassPath.org) and the dependencies needed to build IcedTea can
already be found in Fedora Rawhide."

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

[2] http://fedoraproject.org/wiki/Features/IcedTea

=== A computer in every pot ===

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

"The user interface is called Sugar and not the OS itself but a good
article nevertheless. BBC published a couple of articles with more
technical information and videos featuring Christopher Blizzard, lead
OLPC team in Red Hat."

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

=== Fedora stats offer insight into Linux usage ===

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

Joe 'Zonker' Brockmeier talks with Fedora's Max Spevack about some
recently released statistics. "The Fedora Project offered a peek under
its kimono recently with details about Fedora 7 adoption and other
statistics. Fedora 7 has snagged more than 300,000 users since its
release at the end of May. While that sounds pretty good, Fedora Core
6 managed to attract more than 400,000 in roughly the same amount of
time after its release. We asked Max Spevack, the Fedora project
leader, whether the numbers are telling the full story."

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

== Developments ==

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


Contributing Writer: OisinFeeley

=== RPM Roadmap ... Panu Opens Pandora's Box ===

A "slightly bored" PanuMatilainen solicited[1] suggestions for how rpm
could be improved. Panu was concerned that non-subscribers to
@rpm-maint[2] should get an opportunity to point out deficiencies
which could be corrected now that 4.4.x was branched to maintenance
mode and it was time to plan the next major release. The result was a
thoughtful thread which largely failed to deliver the evil which Panu

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

[2] https://lists.rpm.org/mailman/listinfo/rpm-maint

The issue of multilib support was first raised[3] by "Dragoran", who
thought that "arch requires and provides" should be automatic unless
the packager manually intervened.  TomCallaway (spot) was strongly in
agreement.  DavidWoodhouse followed up later by referencing[4] the
tracker bugzilla entry which shows the extensive thought and
discussion he has put into the issue of multilib support.

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

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

DimiPaun posted[5] an extensive list of suggestions including
version-control of meta-information to allow admins to pinpoint
specific changes due to package updates and the provision of more
fine-grained transaction information to external tools.  The issue of
transactions was also raised separately[6] by MatthiasClasen who
requested "a working %posttrans".  This prompted requests as to what
he found broken, and lead to JeremyKatz explaining that multiple,
small transactions were preferable to fewer, large ones due to their
robustness in the face of power failure and that once this was
achieved there was little advantage of "%posttrans" after "%post".
ColinWalters linked[7] to the Stateless Client approach to avoiding
power failure problems.  Dimi argued that Jeremy might be right about
the power-failure scenario, but that for all others multiple
transactions would diminish the atomicity and integrity of rpm's
workings.  SethVidal didn't precisely disagree[8] but seemed to
consider that Jeremy's scheme would provide more of the granularity of
information that Dimi wanted.

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

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

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

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

Responding[9] to Dimi's point OwenTaylor returned to the
stateless-client model emphasizing that it was important to make
'''system''' transactions as ACID as possible and not necessarily
'''rpm''' transactions. Dimi agreed[10] that this was a non-trivial
problem and suggested that LVM's snapshot capabilities could help out.

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

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

JeffSpaleta wanted[11] some way of marking packages which were
installed explicitly (rather than automatically to satisfy
dependencies). "Topher" suggested reference counting, prompting Jef to
wonder what would be counted and to restate the problem[12] from a
dependency-tree perspective. SethVidal was in agreement with Jef that
avoiding an external database was prudent, but was cautious[13] about
how long it would take to implement labelling such packages.

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

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

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

A sarcastic response from RobertScheck[14] argued that most of what
Panu and others were talking about was either already in the rpm5 fork
or else planned to be in it. Robert asked for clarification on a
couple of points, including MatthiasClasen's wish for smart directory
handling.  Matthias specified[15] that he thought a package should own
all directories it creates or else explicitly require a package which
creates a directory which it uses.

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

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

There many other interesting suggestions and also some great
incidental information about rpm usage.  In this category BrunoWolff
wished[16] that there were some way of extending the length of rpm's
argument list leading JeremyKatz and BillCrawford to point out that
hidden away in the manpage is the info that a manifest list (which can
include globs) can be used instead of a specific package name.

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

Similarly MikeChamber's musing about a way to recover from the
accidental removal of essential rpm libraries led ManuelWolfshant to
point[17] to the "--repackage" option which the manpages say can be
used in conjunction with an erase.  RobertScheck's claim that rpm5 had
a special rollback feature that did this spurred Panu to respond[17]
that the "--repackage" option was ancient.

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

=== Package Management Craic[*] ===

In an independently initiated discussion which overlapped with many of
the issues discussed in another thread covered here (FWN#98 "RPM
Roadmap ... Panu Opens Pandora's Box") RichardHughes asked[1] for
comments on one of his recent blog postings.  Richard argued[2] that
software install and updating tools were prone to information loss,
were user-unfriendly, were hard to maintain, and that Ubuntu was at
the head of an inferior pack.  Richard's main thrust seemed to be to
make package management a D-BUS integrated system service and to make
the various dependency solvers backends, leading to separation out of
the GUI or other interfaces.

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

[2] http://hughsient.livejournal.com/31429.html

An enthusiastic affirmation from "Dragoran" on fixing the problem of
"hung" progress-bars in the US by making the API asynchronous was
initially squashed by JeremyKatz as rpm/sqlite wouldn't play well with
multithreading. DavidZeuthen clarified[3] that multithreading wasn't
necessary for an asynchronous API or proposed by Richard.

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

BillNottingham reminded[4] the list that a similar discussion had been
had before with regard to "yum-updatesd" and the choices roughly
boiled down to making yum-updatesd so simple that it would not even
check the currently installed packages, or extending it to a being a
package-manager which could run unprivileged.  Bill thought that
latter would be a yum/rpm specific version of what Richard was
proposing.  He noted that the goal of making it work with .debs or
other packaging specifications didn't seem interesting to him.
SethVidal was highly skeptical[4a] that working to get a common API
between the different packager formats was possible, noted the huge
amount of coding that would be required and pointed out that
rescue-mode would be complicated.  Richard had specific rebuttals[4b]
of these points and also discussed with Bill the amount of startup
time that would be occasioned by his approach.

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

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

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

In specific response to Bill's lack of interest in a common API
MatthiasClasen thought that escaping the ghettoization of
distro-specific tools to a common upsteam was important and
RichardHughes confirmed[5] that the goal of making it simple for users
to try new software was important.  Bill wondered whether packages as
opposed to "mugshot-style distributed apps" were what Richard really
had in mind.

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

SethVidal was also unhappy with having to use D-BUS on webservers (due
to what he claimed was its impact on RAM and unnecessary extra
complication).  ColinWalters disputed[6] the RAM usage claim and
DavidZeuthen thought[7] that there would be nothing making Seth
install the proposed D-BUS activated simple package management
interface.  He emphasized "simple".

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

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

Offering some mugshot originating code ColinWalters[8] was another enthusiast.

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

[*] Craic is the healthy Hibernian version of "crack", denoting fun,
discussion and general insanity. See

=== Pulseaudio Improving Fedora Sound ===

There was a happy conclusion to a thread on the state of sound and
audio in Fedora which had been opened[1] by a frustrated DimiPaun.
Recounting a series of failures of ALSA since FC6, which were
apparently due to kernel updates Dimi concluded that such flakiness
with very standard hardware was unacceptable.

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

TomBrinkman thought[2] that @fedora-devel wasn't the place for such
support questions and pointed out that Googling indicated that
updating ALSA might work.  In response to this and to JosefBacik's
request for specific details Dimi explained[3] that it wasn't easy to
pin down which kernel caused the problem and that he felt there was a
general,underlying malaise in the development process.  Dimi
expanded on particular flakiness among what he regarded as essential
desktop functionality which had become worse in his opinion.

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

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

A polite response[4] from HansdeGoede asked for Dimi to substitute
high-quality feedback (in the form of filing bugs) instead of
inflammatory emails which no one would look at later. RahulSundaram
similarly asked whether Dimi had filed bug reports and Dimi
answered[5] that he had done so to no effect and that this revealed a
process problem which would result in a deluge of useless bug reports
were Rahul's advice to be followed. A great response[6] from
JosefBacik regretted the problem but suggested that as Fedora merely
packages upstream and could benefit from Dimi filing reports against
the test-release of F8 so that ICH8 (the culpable sound hardware)
would work in F8, Josef also suggested that a more slow-moving distro
(e.g. RHEL, CentOS) might carry fewer frustrations.

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

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

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

"Nodata" wanted to look at the actual bugs, so Dimi provided[7] the
bugzilla entry and expanded on his point that an apparent cycle of
reporting bugs, spending time on them and then being told to report
the bugs upstream was being repeated and that it was too great a
burden on users.

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

To complicate the issue "MarkG"[8] and HenkBreimer[9] reported that
the apparently same hardware worked fine for them with F7.

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

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

A post[10] by "Kelly" recommending the advantages of PulseAudio
appeared to provide hope for the positive resolution of this problem.
Confirmation of this as a solution was provided[11] when Rahul pointed
out that PulseAudio was the default daemon in Fedora8. Kelly helpfully
added[12] that s/he had a package which redirected the Adobe Flash
through PulseAudio.

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

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

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

Finally, Rahul asked[13] Dimi to try some potted commands to update
ALSA and to let him know if it fixed the sound problem.

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

=== What Should Appear In Desktop Menus ===

The debate over whether applications' .desktop files should be setting
ShowOnlyIn (see FWN#97 "ShowOnlyIn Another GNOME Conspiracy
Unmasked"[1]) continued to yield disagreement.  "Nodata" held out
SuSE's "disastrous clutter" as the likely result of bowing to
ChristopherStone's desire to make all applications show up in the
menu.  Chris refused[2] to set foot on this slippery slope and asked
again why shouldn't an application which he chose to install show up
in the menu?

[1] http://fedoraproject.org/wiki/FWN/Issue97#head-dfd181f0727edbc287e9ee6b942c27232649c6a8

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

So far this was a rehash of already covered ground and positions, but
JefSpaleta and MattMiller trod a middle course[3] between complete
menu mayhem and a straightjacketed system which prevent users from
adding icons to their menus as they wished.

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

Chris didn't think much thought was going into the default menu
choices as evidenced by the fact that someone using Xfce (instead of
GNOME or KDE) would not see applications like Kate or Banshee show up
in their menu.  BillNottingham riposted[4] that it also woouldn't make
sense to show kreversi and iagno in both GNOME and KDE and wished for
a DoNotShowIn in addition to OnlyShowIn.  VilleSkyttä drew[5]
everyone's attention to NotShowIn.

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

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

It seemed that Chris was still in high dudgeon and JesseKeating
tried[6] to refocus the discussion on the problem of shared systems
and the need to avoid the application menu becoming contaminated with
applications installed by users who preferred different desktop
environments.  Jesse thought the solution was to teach the Xfce
equivalent of gnome-menu to ignore the ShowOnlyIn entries in .desktop

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

JonathanUnderwood recalled the old days when there was a KDE submenu
in the GNOME menu but "nodata" thought the user experience of having
to know about this and hunt around for applications would be
unpleasant and it would be better to just provide KDE apps for KDE
users and GNOME apps for GNOME users.  Chris thought this was "so dumb
it makes Microsoft engineers look like friggin' geniuses", but
later[8] backed off from the personal element in this remark.

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

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

In closing arguments JesseKeating drew Chris's attention[9] again to
the problem of multiuser systems and developed the point further when

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

The discussion seemed to peter out with Chris and Jesse agreeing[10]
on the previously stated ideal of working toward making gnome-menu and
equivalents able to override ShowOnlyIn.

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

MarkG was shown by ChristopherStone how to remove the problematic
lines from .desktop
 ''# desktop-file-install --remove-only-show-in GNOME
and ChristopherAillon provided a expansion[11] on the idea.

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

=== Kmods Deprecated ===

After an invitation from BrianPepple to add items to the agenda for
the FESCo meeting an interesting thread developed from HansdeGoede's
request[1] for clarity on the "current somewhat grey state of kmods".
His proximate reason for this was that  ParagN's experience suggested
to him[2] that kmods were unlikely to find favour in Fedora because
they were not upstream. FlorianLaRoche felt[3] that kmods were worth
the pain and also was keen on seeing the gspca kmods supported in
Fedora. (See FWN#).

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

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

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

An argument for the  straight-out deprecation of kmods in Fedora was
made[4] by DavidWoodhouse who thought that instead those using them
should be given CVS commit access to maintain patches to the kernel
which could be trivially enabled/disabled. A partial disagreement was
registered[5] by ThorstenLeemhuis who lobbied[5] for deprecation in
the F8 Everything spin and update-proper repository, but the creation
of a replacement test repository which would make kmods available to
those that needed them.  Thorsten argued that there were developers
not as comfortable  with kernel development as David (or HansdeGoede)
who nevertheless produced kmods which were useful to users.  Thorsten
also thought that some code which had a high probablility of not
making it into the upstream (kernel) had a value for select users.

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

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

Adding his voice[6] to David's desire to avoid troublesome kernel code
was JesseKeating who thought that the overhead imposed on yum/rpm was
too high. Thorsten replied[7] to David's statement that "If we don't
want it Fedora's kernel RPM, then we don't want it in Fedora at all"
with a reiteration of the idea that users may want lots of things that
the distro doesn't so a "play" area with clear warning signs should
allow them to shoot themselves in the foot if they so desire.

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

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

Thorsten also conceded[8] that David had a strong position, but linked
the discussion to one happening within the FAB about who comprises
Fedora's target audience and suggested that allowing a safe area for
experimentation would have benefits in terms of stimulating and
retaining interest among people that may later become Fedora
developers or maintainers.

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

HansdeGoede was broadly approving[9] of David's position, not least
because it avoided having to delay kernel security updates while
waiting for kmods to be fixed.  After some discussion JesseKeating's
worries[10] that this would result in more frequent kernel updates
were dispelled[11] after David outlined how he saw the process playing
out in updates and rawhide.

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

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

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

In a related thread RalfCorsepius reported[12] a bizarre result from
updating which resulted in an apparently older kmod being installed.
Posts by SethVidal suggested[2] that this was due to the proper yum
plugin for kmods being absent[13].


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

=== New Yum-updatesd (Rawhide Report 20070725) ===

A heads-up was called[1] by JeremyKatz drawing attention to a
completely re-worked yum-updatesd (see "RPM Roadmap ... Panu Opens
Pandora's Box" in this same FWN issue).  Jeremy noted that it had been
split into a two parts: a small DBUS-enabled daemon and a forked
memory process which is unthreaded.

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

HansdeGoede wanted to know[2] if this fixed his number one reason for
not running yum-updatesd: that yum would fail if yum-updatesd was
checking for updates.  Hans suggested some ways of working around this
problem.  Jeremy responded[3] that this could still be a problem, but
that it was mitigated somewhat by the fact that the process holding a
lock on the database would now die-off quickly as it would not get
"hung up in thread-land".

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

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

In response to Jeremy's rebuttals Hans continued to press some further
suggested changes[4] concerning the detection of a collision between
the two processes and the response to it.

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

=== NOTE: Please publicize any license changes to your packages (CONT.) ===

JefSpaleta agreed[1] with ThorstenLeemhuis that automatic checking of
package licenses with upstream would help ease maintainer load in the
simple cases of entire codebases migrating to GPLv3 from a previous
license. RalfCorsepius reiterated[2] his assertions that it would not
help codebases migrating from license:FOOx to license:BARy, or
packages pointing to websites, and furthermore would require a large
bureaucracy which would drive away contributors.  AndyGreen
responded[3] that these cases would be flagged as problems requiring
human intervention.  Ralf remained unconvinced[4] and invited the
Board and the "dark forces" around it to do so without Ralf's help.
This drew a certain amount of derision and disbelief and led to the
revelation[5] of SethVidal as a self-confessed pusher of the changes
to which Ralf objects.  Seth wondered how exactly the process he was a
part of could be construed as evidence of dark forces and explained
that t Ralf replied with a list of "mushrooming" committees trying to
"push volunteering contributors around".

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

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

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

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

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

While expressing envy of Ralf's imagination NilsPhilippsen drew
attention[6] to the distinction between labour-saving automation (of
license checking) and bureaucracy.

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

Further dispuation saw JesseKeating stating[7] that until the FSF
figured out how to resolve the incompatibility between GPLv2 and GPLv3
the relicensed GNU toolchain couldn't be allowed in the distribution.
Ralf recommended that he check out a discussion on the subject on the
GCC list and Jesse replied[8] that he was aware of it and that it
underscored the need for Fedora to be on top of any and all license

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

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

ArjanvandeVen corrected[9] Jesse's statement of the problem, noting
that co-existence of GPLv2 and GPLv3 packages was no problem, but
rather in making derived works. In turn, JakubJelinek corrected[10]
this statement, saying that LGPLv3 was the problem and not GPLv3.  A
further clarification[11] came from TomasMraz who stated the
constraint as merely '''we just have to ensure that we don't link any
gplv2 only program to such library. Such as we have to ensure that we
don't link any gpl program to openssl library and so on.'''

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

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

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

At this point RalfEtzinger posted a list[12] of packages which
appeared to contravene this principle, again underscoring the need for
this sort of information.  FabioComolli posted[13] a useful link to
MarkMcLoughlin's useful notes on the GPL and OpenSSL exemption.
ChrisAdams provided[14] some package specific information and noted
that these were "good example[s] of why license changes need to be
clearly announced and researched."

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

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

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

JeffSpaleta argued[15] that the absolutely best people to be the "we"
of "we need to ensure that we don't link any gpl program to openssl
library and so on" are the package maintainers as they are the experts
in the libraries they maintain. ArjanVanDeVen suggested that tools
could help parsing the "License" tag for mistakes and JesseKeating
agreed and pointed[16] out that the FPC had been working on a syntax
for the tags to enable this (see also FWN#97 "Allo Allo Wot's This
'Ere License?"[17].)

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

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

[17] http://fedoraproject.org/wiki/FWN/Issue97?action=show&redirect=FWN%2FLatestIssue#head-88f89705c226aecc4869ba68683870b2edebb626

=== Extra Packages for Enterprise Linux (EPEL) Now Open ===

KarstenWade announced[1] that the Extras Packages for Enterprise Linux
(EPEL) repository was now open. This is of particular interest to
anyone currently rebuilding packages from Fedora to use on one of the
RHEL-derivatives such as CentOS, Scientific Linux or even on RHEL

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

Apart from the obvious advantages to those of us maintaing such
systems there is also a unique opportunity for those in academia to
gain experience in curating enterprise applications for a large user

=== Abuse Of Fedora Trademark ===

A sharp-eyed HansdeGoede spotted[1] an announcement in LWN (Linux
Weekly Net) of a piece of software which called itself "EasyFedora"
used a proprietary license.  Hans was pretty sure that this was
abusing the "Fedora" trademark.

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

"Nicolas"(kwizart) noted[2] that a thread in FedoraForum requested the
author to release under a non-proprietary license, but JesseKeating
pointed out that regardless of the license the author had no right to
use Fedora(TM) in the name of his software.

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

A possible further problem was identified by KevinKofler who
suggested[3] that unless the developer had a commercial Qt license
then he was also violating the GPL!

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

A helpful TimLauridsen supplied the information about how to report
trademark violations to the Fedora Project which prompted AlainPortal
to ask[4] whether this was overkill and it would be better to just
write to the developer and ask him to remove the offending wording.
"Dragoran" thought this was a good approach, but RahulSundaram argued
that "legal" would handle it politely and were the appropriate people
to do so.

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

=== XFS In Anaconda ===

A developer at Fermilab (DanYocum) requested[1] the enabling of the
XFS filesystem in anaconda (the installer).  Dan attested to the
succesful inclusion of XFS upstream in the kernel, the realworld
experience of successful installs and circa 1 Petabyte of running
disks at Fermilab.

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

JesseKeating asked how SELinux support was these days and why he
couldn't boot from XFS. EricSandeen confessed[2] that errors in FC6
with regard to SELinux could be blamed on him, but that they seemed to
be fixed now after a trivial error had been corrected.  Eric noted
that booting from XFS in SuSE worked fine and suggested that a since
resolved GRUB error may have been responsible for corruption in both
ext3 and xfs.  Finally Eric admitted that it wasn't possible to
install GRUB to an XFS partition but the MBR worked fine.

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

In response to Eric's questioning Jesse provided the information that
anaconda consistently choked on XFS for him and Eric wondered[3]
whether GRUB was to blame still and how hard it would be to create a
test anaconda.  Jesse thought it wouldn't be too difficult and
pointed[4] to exactly how this could be done.

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

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

== Translation ==

This section, we cover the news surrounding the Fedora Translation
(L10n) Project.


Contributing Writer: JasonMatthewTaylor

=== F7 Release Notes Update ===

PaulFrields mentioned here[1] that an update of the release notes
package is on the horizon. There are a few locales that need fixes, as
of 28-Jul-07 they were el  es  fi  pa  pt_BR  sr  uk  zh_CN.

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

== Infrastructure ==

In this section, we cover the Fedora Infrastructure Project.


Contributing Writer: JasonMatthewTaylor

=== Sponsor HowTo's ===

MikeMcGrath has put some documentation up[1] on how to sponsor, how to
get a sponsor and what the different groups are and what they do.
Additions and clarifications are always welcome.

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

== Artwork ==

In this section, we cover Fedora Artwork Project.


Contributing Writer: JonathanRoberts

=== Echo Icons Moved ===

LuyaTshimbalanga wrote to the list suggesting that it might be a good
idea to move the Echo icons to a host other than the wiki[1]. This
will result in faster upload speeds, making it easier for contributors
to make improvements to existing icons and to create new ones. As well
as improving speeds, this should allow the use of a revision control
system, rather than relying on the current echo-pull script.

A ticket was opened with the Fedora infrastructure team, and work is
underway to move the Echo icon theme to hosted.fedoraproject.org[2],
and will use the Git revision control system. Currently the Echo icons
are hosted at luya.fedorapeople.org/images/echo[3].

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

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

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

=== Nodoka Engine 0.5 Released ===

The Nodoka theme engine has released its 0.5 version, including a
significant number of updates[1].

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

=== Fedora 8 Theme Decisions ===

MairinDuffy has sent a message informing the Art team that they have
been given the authority to determine the final artwork and themes for
Fedora 8. While this is great news, there are now decisions for the
team to make, including which theme engine and icon theme to use as
default in Fedora 8[1].

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

== Security Week ==

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

Contributing Writer: JoshBressers
=== Dangerous Firefox Flaw ===

This week there has been a fair amount of talk regarding a new Firefox
flaw that can allow a web site to execute arbitrary commands as the
user running Firefox.
Window Snyder has more information about this here[1].

[1] http://blog.mozilla.com/security/2007/07/25/launching-local-programs-through-filetype-handler

It turns out that the issue here is how Firefox launches helper
applications.  Specifically, how Firefox launches helper applications
in Windows.  In the Linux version of Firefox, when a helper is
launched Firefox will do a forkexec of the binary.  This basically
means that the way the arguments are passed to the helper are well
understood.  In the windows world, this is not well understood and has
led to confusion and a rather dangerous security flaw.  What's
happening is basically that the URL is handed to a special Windows
function that builds the argument list, then launches the URL handler.
 This is a perfect example of why relying on closed source solutions
are a problem.  Nobody actually understood this problem for several
days, and even now how can it be proven the Firefox fix will be
correct?  Without the ability to view the source, or adhere to
standards, application writers are at a serious disadvantage.  It is
very likely that there are countless other applications that suffer
from this same bug, but since they lack the attention Firefox has, the
bug will never be fixed.  IE even suffers from this flaw, which
Microsoft claims isn't really a security bug.

It's easy to say that open source has significant security advantages,
but situations like this make it hard to believe any argument in favor
of a closed system.

== Daily Package ==

In this section, we recap the packages that have been highlighted as a
Fedora Daily Package. We're looking for suggestions for packages to
feature -- please suggest your favorites using the ''Suggest a
Package'' box on the right-hand side of the Fedora Daily Package home

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

Contributing Writer: ChrisTyler

=== Incron - Execute commands based on filesystem activity ===

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

"Incron is a new tool modeled after cron which executes commands when
a filesystem event occurs. Without polling, Incron can watch a
specific file or an entire directory for new files, file writes,
closures, deletions, or other activity."

[1] http://dailypackage.fedorabook.com/index.php?/archives/102-Productive-Monday-Incron-Execute-commands-based-on-filesystem-activity.html

[2] http://inotify.aiken.cz/

=== eSpeak - Voice synthesizer ===

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

"eSpeak is a speech synthesis package which provides an alternative to
the better-know Festival synthesizer."

[1] http://dailypackage.fedorabook.com/index.php?/archives/103-Artsy-Tuesday-eSpeak-Voice-synthesizer.html

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

=== Wednesday Why: Syslog ===

The ''Wednesday Why'' article[1] took a look at Fedora's syslog configuration:

"The /var/log directory contains a number of different log files. Many
of these logs are generated by syslogd, which accepts log messages
from programs and routes them to log files, the screen, and remote log

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

=== Seamonkey - Mozilla suite ===

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

"If you miss the bundled features of the Mozilla Suite, the Seamonkey
package will give you what you want: web browser, e-mail and newsgroup
client, address book, WYSIWYG page editor, IRC client, DOM inspector,
and JavaScript debugger, all integrated into a single program."

[1] http://dailypackage.fedorabook.com/index.php?/archives/105-GUI-Thursday-Seamonkey-Mozilla-suite.html

[2] http://www.mozilla.org/projects/seamonkey/

=== BSD-Games: Text games ===

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

"In the 70's and 80's, many Unix systems came with several dozen
text-based games and amusements... if you're feeling nostalgic or if
you've never encountered these classic games, it's worth checking out
the bsd-games package."

[1]  http://dailypackage.fedorabook.com/index.php?/archives/106-Friday-Fun-BSD-Games-Text-games.html

[2] ftp://metalab.unc.edu/pub/Linux/games/

== Advisories and Updates ==

In this section, we cover Security Advisories and Package Updates from

Contributing Writer: ThomasChung

=== Fedora 7 Security Advisories ===

 * [SECURITY] bind-9.4.1-7.P1.fc7 -
 * [SECURITY] drupal-5.2-1.fc7 -
 * [SECURITY] lighttpd-1.4.16-1.fc7 -

=== Fedora Core 6 Security Advisories ===

 * [SECURITY] bind-9.3.4-7.P1.fc6 -

== Events and Meetings ==

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

Contributing Writer: ThomasChung

=== Fedora Board Meeting Minutes 2007-MM-DD ===

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

=== Fedora Ambassadors Meeting 2007-07-26 ===

 * https://www.redhat.com/archives/fedora-ambassadors-list/2007-July/msg00090.html

=== Fedora Documentation Steering Committee 2007-MM-DD ===

 * No Report

=== Fedora Engineering Steering Committee Meeting 2007-07-26 ===

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

=== Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-07-26 ===

 * https://www.redhat.com/archives/epel-devel-list/2007-July/msg00225.html

=== Fedora Infrastructure Meeting (Log) 2007-07-26 ===

 * https://www.redhat.com/archives/fedora-infrastructure-list/2007-July/msg00158.html

=== Fedora Packaging Committee Meeting 2007-MM-DD ===

 * No Report

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

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

=== Fedora Translation Project Meeting (Log) 2007-07-24 ===

 * https://www.redhat.com/archives/fedora-trans-list/2007-July/msg00072.html

Thomas Chung

More information about the fedora-announce-list mailing list