|
|
Welcome to Fedora Weekly News Issue 90 for the week of May 27th through June 2nd, 2007.
|
|
= Fedora Weekly News Issue 90 =
Welcome to Fedora Weekly News Issue 90[1] for the week of May 27th
through June 2nd, 2007. The latest issue can always be found here[2]
and RSS Feed can be found here[3].
[1] http://fedoraproject.org/wiki/FWN/Issue90
[2] http://fedoraproject.org/wiki/FWN/LatestIssue
[3] http://feeds.feedburner.com/fwn
1. Fedora Weekly News Issue 90
1. Announcements
1. Announcing Fedora 7 (Moonshine)
2. Freshrpms for Fedora 7
3. ATrpms for Fedora 7
4. A Few Words About Fedora 7
5. Discounts on Red Hat training for Fedora folks
2. Planet Fedora
1. Fedora is now an open source project
2. Interview of Max Spevack
3. Interview of Mike McGrath
4. Kernel hacking for laptops
5. fedoraproject.org promos
6. Some comments on Fedora 7
7. Fedora 7 "Moonshine": Freedom vs. Ease-of-Use (Part 1)
3. Developments
1. OCaml Packaging
2. Fedora Secondary Architectures Proposal
3. Five Months To Fedora 8: A Conspiracy Against KDE?
4. What Should X-Chat Be Called In The Menu?
5. FreeTDS Inclusion
6. Simplified Kernel Spec File
7. RPM License Agreement Support
8. Don't Put New Packages Through Updates-testing
9. Fedora Image As A GRUB Entry
4. Maintainers
1. EPEL Report Week 20
2. Bodhi and Fedora 7
5. Documentation
1. Fedora Documentation Steering Committee Meeting
2. Meeting Location
3. ISO and Web-Only Release Notes
4. Documentation for Revisor and Other Spin-Making Tools
6. Infrastructure
1. Infrastructure Server Organization
2. Bodhi
3. New Projects
7. Artwork
1. Fedora 7 Disc Labels
2. Default Desktop Theme?
3. Fedoraproject.org Banners
4. Brazilian Banners
8. Advisories and Updates
1. Fedora 7 Advisories and Updates
2. Fedora Core 6 Advisories and Updates
3. Fedora Core 5 Advisories and Updates
9. Events and Meetings
1. Event Report: IV ESLAM - Amazon, Brazil
2. Fedora Ambassadors Meeting Minutes 2007-MM-DD
3. Fedora Documentation Steering Committee 2007-MM-DD
4. Fedora Engineering Steering Committee Meeting 2007-05-31
5. Fedora Packaging Committee Meeting 2007-05-29
6. Fedora Release Engineering Meeting 2007-MM-DD
10. Feedback
== Announcements ==
In this section, we cover announcements from various projects.
Contributing Writer: ThomasChung
=== Announcing Fedora 7 (Moonshine) ===
The Fedora Project announces in fedora-announce-list[1],
"Fedora 7 is the first release where the development was one hundred
and one per-cent in the community. How? It's simple, cousin -- all
the code was merged into a single external repository. Why? Same
great distribution quality, even more high-quality developers able to
work directly with the code and improve the flavor of over 7500
packages."
* http://fedoraproject.org/get-fedora.html
* http://docs.fedoraproject.org/release-notes
* http://docs.fedoraproject.org/release-notes/f7/en_US/sn-OverView.html
[1] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00009.html
=== Freshrpms for Fedora 7 ===
MatthiasSaou announces in fedora-announce-list[1],
"All freshrpms add-on packages are now available for Fedora 7."
* http://freshrpms.net/
* http://moonshine.freshrpms.net/
[1] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00011.html
=== ATrpms for Fedora 7 ===
AxelThimm announces in fedora-announce-list[1],
"ATrpms is officially launching Fedora 7 support for i386, x86_64 and ppc."
* http://atrpms.net/dist/f7/
* http://dl.atrpms.net/
[1] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00010.html
=== A Few Words About Fedora 7 ===
MaxSpevack announces in fedora-announce-list[1],
"Before I talk about Fedora 7, it's useful to look at recent history.
One of the Fedora Project's mottos is "the rapid progress of free and
open source software." With Fedora Core 5 in March of 2006, Fedora
Core 6 in October of 2006, and Fedora 7 today, that's about 7 months
per release. And with several million Fedora Core 6 installs, everyone
who works on Fedora should feel very proud that not only is the
software being released often, but it's also high quality, and in high
use around the world."
"Fedora 7 represents the culmination of several goals that Fedora has
spent the last few releases (spanning the course of at least 2 years)
working to achieve. I've written previously on this list about the
aspects of Fedora 7 that I think are the most important[2]."
"From my perspective, it is the fundamental infrastructure changes
that Fedora 7 represents that are the biggest achievement. The entire
Fedora toolchain has been freed. Every step in the
distribution-building process is completely open."
"And I speak for everyone at Red Hat when I say that it is an honor to
be a part of something like Fedora. Congratulations to everyone on
today's release."
[1] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00008.html
[2] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00002.html
=== Discounts on Red Hat training for Fedora folks ===
MaxSpevack announces in fedora-announce-list[1],
"The nature of Fedora is such that many of our contributors and users
are very technical, and make Linux their careers as well as their
hobbies. We know that many Fedora contributors and users hold RHCT,
RHCE, or RHCA certifications. Obviously, we are happy that you choose
Red Hat Training and and we appreciate your business. As a way of
saying thank you to our community, we are pleased to offer special
discounts[2] to Fedora contributors who register for upcoming Red Hat
training courses."
[1] https://www.redhat.com/archives/fedora-announce-list/2007-June/msg00000.html
[2] https://www.redhat.com/training/fedora_training_discount.html
== 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, KarstenWade
=== Fedora is now an open source project ===
ChristopherBlizzard points out in his blog[1],
"But of course, these are not the most important qualities of Fedora
7. The qualities that I'm interested in are somewhat intangible. What
this release represents is a first step down a long path. Fedora is no
longer something that just Red Hat produces. Those of us who work for
the company have been long since eclipsed by the sheer number of
people involved in Fedora from outside of the corporate firewall. It's
simple: Fedora is now an open source project. What's interesting to me
is how long we've been able to say this - a few months at best - but
the number of people that have shown up who show a unique passion for
the success of the project is just amazing. For a good view of some of
them check out the Fedora Award Winners for 2007[2]. Every one of
those guys just showed up and started making a difference."
[1] http://www.0xdeadbeef.com/weblog/?p=293
[2] http://www.redhatmagazine.com/2007/05/31/announcing-the-fedora-award-winners-for-2007/
=== Interview of Max Spevack ===
KushalDas points out in his blog[1],
"Yesterday night, I did a video interview of MaxSpevack (Fedora
Project Leader). In this interview, he mostly talked about the
upcoming Fedora-7 release, which will happen tomorrow. The plus points
for the users. He also described the future targets of the Fedora
project. You can see the interview here[2]. In the google video also
at here[3]."
[1] http://kushaldas.in/?p=134
[2] http://www.archive.org/details/InterviewOfMax
[3] http://video.google.com/videoplay?docid=-4461571891690806161&hl=en
UPDATE: Here is another Video Interview[1] of MaxSpevack (Fedora
Project Leader) & Kital
[1] http://kushaldas.in/?p=145
=== Interview of Mike McGrath ===
KushalDas points out in his blog[1],
"As Fedora-7 is out for almost 1 day, I did an interview of
MikeMcGrath (Fedora Infrastructure). He talked about how it went :)"
You can see it here[2].
[1] http://kushaldas.in/?p=136
[2] http://video.google.com/videoplay?docid=7800949146474110046&hl=en
=== Kernel hacking for laptops ===
RichardHughes reflects on his day off hacking the kernel in his blog[1],
"I've just posted a patch to fix the toshiba_acpi kernel driver to
emit INPUT events when the fn hotkeys are pressed. This means that the
hardware works out of the box, and integrates nicely with KDE and
GNOME without using oddball uinput-injecting system daemons such as
FnFX to do the userspace polling. This also obsoletes my hal addon to
do basically the same thing."
[1] http://hughsient.livejournal.com/27324.html
=== fedoraproject.org promos ===
In response to a collaborative idea to do rotating banner promos on
fedoraproject.org[1], MairinDuffy posted a few ideas in her blog,
"So we've had this idea the past few days that now we have a new
fedoraproject.org, we could do cool stuffs like have promos to
highlight events, groups, and other cool stuff around Fedora.
The first promo we're thinking about is to highlight spins - the fact
you can now create your own custom Fedora spins or highlight a
particular spin."
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00001.html
[2] http://mihmo.livejournal.com/41166.html
= Marketing ==
In this section, we cover Fedora Marketing Project.
http://fedoraproject.org/wiki/Marketing
Contributing Writer: ThomasChung
=== Some comments on Fedora 7 ===
RahulSundaram reports in fedora-marketing-list[1],
"Fedora 7, the latest and arguably most ambitious release from the
increasingly community-friendly Fedora Project, will hit the download
mirrors later this week. With its installable live CDs, merged package
repositories and much improved artwork, the new Fedora should prove a
major attraction on the 2nd quarter release calendar[2]."
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-May/msg00082.html
[2] http://distrowatch.com/weekly.php?issue=20070528
=== Fedora 7 "Moonshine": Freedom vs. Ease-of-Use (Part 1) ===
MarcWiriadisastra quoted an article in fedora-marketing-list[1], which
sparked a thread about how well Fedora explains its positions on
IP-encumbered software.
"Fedora 7, a.k.a. "Moonshine," released on May 31, is an odd duck. On
the one hand, it's hugely popular. If you need to be convinced of that,
take a look at the number of people viewing the officially-sanctioned
FedoraForum.org[2] at any given time - as I write this, it's almost 7,000
people. Visit your local Barnes & Noble Booksellers (that's a big
bookstore chain in the U.S.) and you'll see quite a few books about
Fedora on the shelves. (This, by itself, is a big plus for Linux newbies
— Fedora may be the best-documented distro available)."
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00021.html
[2] http://forums.fedoraforum.org/
Editor's Note: As of June 3, 2007, there were over 93,000 members in
FedoraForum.org
== 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
=== OCaml Packaging ===
As previously reported[1], the packaging of the OCaml language has
been initiated. RichardJones wondered[2] whether his OCaml packages
could be discussed at the upcoming FESCo meeting. Richard had
discussed[3] some issues with ToshioKuratomi on @fedora-packaging but
sought wider input.
[1] http://fedoraproject.org/wiki/FWN/Issue86#head-45f52ddea0d1c89a1e166a721b43fc10126dd37f
[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02005.html
[3] https://www.redhat.com/archives/fedora-packaging/2007-May/msg00207.html
TomCallaway (spot) thought[4] that the discussion would be more
appropriate to the packaging committee (which would be meeting within
a week), while BrianPepple noted[5] that FESCo was open to anyone in
the community who was willing to follow the basic etiquette.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02006.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02009.html
=== Fedora Secondary Architectures Proposal ===
A draft proposal on the support of different machine architectures was
submitted[1] by TomCallaway for consideration. It resulted in
prolonged and apparently unresolved disagreements. The proposal
recognised two layers of architecture: Tier 1, consisting of x86 and
x86_64; Tier2 consisting of SPARC, Alpha, PPC{,64}, IA64 (and possibly
s390). Support of Tier1 would be considered the primary
responsibility of the Fedora Project, while responsibility for the
secondary architectures would be devolved onto volunteer teams
(ArchTeams).
The buildsystem would be structured so that the failure of packages to
build on Tier1 would prevent the packages from being pushed to the
repository, but failure on Tier2 would not prevent the packages being
pushed to the repository.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01862.html
The main points of contention seemed to arise from the possibility of
disturbance of a currently well-working system by which package
maintainers provide a certain amount of feedback to the existing Tier2
architectures. Balanced against that is the desire to allow
niche-architecture interest groups to use the Fedora Project
buildsystem, without causing undue potential disturbance to the
majority of users.
An initial objection[2] from DavidWoodhouse (the driving force behind
PPC support in Fedora) was that the proposed system would promote
silent failures, a step backwards from the useful information now
provided by maintainers through the required filing of a tracker bug
each time "ExcludeArch:" is used in a package's specfile.
JefSpaleta[3] and HasdeGoede[4] agreed with David on the advantages of
the documentary nature of the current procedure. Jef proposed that the
current ExcludeArch practice be extended to Tier2.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01863.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01865.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01893.html
Tom cautioned[5] that Jef's suggestion of ignoring failed builds would
necessitate changes to Koji and would also probably result in
frustrated package maintainers overusing ExcludeArch as soon as more
Tier2 were added. David picked up[6] on this point and suggested that
Tom and he were addressing different problems, with Tom considering
the process of introducing a new architecture, while David himself was
talking about the procedure to be followed during the ongoing attempt
to support a Tier2, which had already had low-level stuff like glibc
and gcc bootstrapped. David further suggested the idea[7] of allowing
a maintainer to file a bug after a package failed to build for a
particular architecture, but thought that this resulted in increased
complexity for no gain. BillNottingham pointed out[8] that the gain
was that Tier2 failures wouldn't hold up Tier1 package building and
propagation even if the relevant ArchTeam failed to do a good job.
ChrisBlizzard had separately indicated[9] that he estimated that
inside of Red Hat they were "spending 50% of your time on 3% of your
user base" and that the proposal avoided the delays in development
which Fedora would also surely see if new architectures were added
without this proposal being implemented.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01877.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01896.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01896.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02002.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02020.html
JesseKeating contradicted[10] the idea that Tier2 build failures would
be "silent" and restated the proposal's central advantage in avoiding
development delays due solely to Tier2 architectures. DavidWoodhouse
disputed[11] the idea that progress would be hindered and itemized the
reasons for which a package might cease to build succesfully, arguing
that these were either easily within a package maintainer's abilities,
or else could be passed on to the ArchTeam by filing an ExcludeArch
bug. David further argued that the only downside might be a small
delay resulting from putting a fixed package through the buildsystem
again. Jesse referenced his personal experience in which he had seen
packages sit unbuildable for hours and days due specialists on
particular architectures being unavailable. Jesse also suggested that
package maintainers would be overwhelmed by the additional work
required, a point that was reinforced[12] by ChrisWeyl who was
concerned at the signs of stress already emanating from package
maintainers due to the Core/Extras merge. DaveJones substantiated[13]
Jesse's evaluation of significant delays, citing 6 hours increased
wait time as a result of having to resubmit to the build system. David
thought that the i386 kernel build could be pushed anyway, and
ChristopherAillon explained[14] that currently that couldn't happen
because it would lead to inconsistencies in the primary repositories.
Christopher also thought that there would be advantages for Red Hat in
being able to treat the s390 architecture in this way.
[10] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01922.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01944.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01959.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02155.html
[14] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02173.html
ChrisWeyl argued[15] that David's primary objection was about relaxing
the requirement that maintainers be responsible for all architectures,
but this had to be done in order to allow new architectures into the
build system. TomCallaway thought[16] that Chris had appreciated the
heart of his proposal. David replied[17] that the proposal seemed to
be trying to solve a problem that didn't exist and that the current
system was fine and did exactly what Chris said the new one should do.
JakubJelinek emphasized[18] the problem of slow build times on
particular architectures, providing specific information about the
PPC{,64} builds and wondered whether asynchronous builds should be
considered. OliverFalk was concerned[19] about addressing this problem
for the Alpha architecture.
[15] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01871.html
[16] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01872.html
[17] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01895.html
[18] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01897.html
[19] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01899.html
Responding to Jakub's data, David agreed[20] that slow builds for
particular architectures was the only possible problem solved by the
proposal and wished that TomCallaway had stated the problem more
clearly. ChristopherAillon cited[21] the undesirability of delaying a
critical Firefox security fix in order to add an ExcludeArch and then
rebuild. He also mentioned the undesirability of waiting while exotic
compiler bugs were fixed for Tier2 architectures (something which
Firefox apparently exposes due to its complexity). David
questioned[22] whether it would really take much time. Christopher
responded[23] that it did (worst case of up to 9 hours) and added that
the situation was complicated by the frequent bundling of multiple
fixes in one shot. David dismissed this as an "esoteric" case and
asked if it would be covered by just filing an ExcludeArch
retrospectively, which Christopher assented[24] to, noting that this
was what the proposal addressed. ChrisBlizzard ratified [24a]
ChristopherAillon's experience, to which David responded that he'd
been paid to do it.
[20] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01895.html
[21] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01933.html
[22] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01945.html
[23] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01967.html
[24] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01970.html
[24a] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02029.html
JesseKeating did not agree[25] that retrospective ExcludeArch
bug-filing would solve Christopher's case, because if a build were
allowed to fail for a Tier2 case then it would fail for everything,
necessitating a complete rebuild. This led to David clarifying[26]
what he was proposing, which led Jesse to wonder why David was
objecting to implementing the proposed steps automatically and
TomCallaway expressed concern that it would be difficult to code
correctly and suggested an alternate logical build path. David
reiterated his objection[27] to breaking the current balance of work
shared by package maintainers and others.
[25] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01971.html
[26] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01990.html
[27] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02053.html
Further discussion of Christopher's concrete example was mainly an
exchange between David and Jesse. David argued[28][29] against the
"package monkey" approach of automatically filing ExcludeArch bugs and
Jesse arguing[30] that maintainers couldn't reasonably be expected to
do more than was suggested by the proposal if many new architectures
were added. A lengthy, slightly circular and bad-tempered exchange
developed with David arguing that incompetent Quality Assurance
practices were being pursued and Jesse deciding that he'd had enough
argumentation[31].
[28] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01952.html
[29] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01969.html
[30] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01972.html
[31] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02075.html
OliverFalk tried to salvage[32] something positive from the discussion
by proposing a categorization of the ways in which builds could fail.
David largely agreed with him and pointed out his own earlier similar
attempt. Oliver excused the duplication on the basis of not having
read the lengthy thread.
[32] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02078.html
One repeated question that kept cropping up in these sub-threads was
restated by ChrisBlizzard[33], namely the question of what a package
maintainer could reasonably be expected to do. DavidWoodhouse
clove[34] to his earlier stated position in previous discussions that
package maintainers could and should be expected to reach a high
standard and that the current system worked well. ChristopherAillon
suggested[35] that auto-filing of bugs could have a positive effect.
BillNottingham thought[36] that the issue was more that the community
was being asked to support the CPU fetishes of a minority user base,
and that while the Fedora Project could offer facilities to such
groups it shouldn't allow them to impede Fedora's primary mandate.
[33] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02023.html
[34] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02066.html
[35] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02084.html
[36] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02003.html
BillNottingham[37], DennisGilmore[38], and OliverFalk[39] raised the
logistical issues of where the machines for these builds would be
located. Bill noted that the file space was just not available at the
moment. JesseKeating emphasized[40] that Red Hat shouldn't be looked
to as the source of hardware, which should instead come from any
interested community, even so OliverFalk seemed to have some good
leads on mothballed Alphas!
[37] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01883.html
[38] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01884.html
[39] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01901.html
[40] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01940.html
=== Five Months To Fedora 8: A Conspiracy Against KDE? ===
Discussion of the next release of Fedora was initiated[1] by
KevinKofler on the premise that it was a problem because it would
exclude the final KDE4 by a mere six days. JesseKeating[2] replied
that a stable schedule was more important than any one piece of
software and would allow upstream projects to target Fedora more
easily. Kevin wondered[3] why the relationship should work in that
direction and noted that Fedora 8 would have to ship a release
candidate of a very important KDE and that schedules slipped anyway.
ChristopherAillon responded[4] that this frequently happened with
GNOME, while JefSpaleta described[5] advantages of sticking to
schedules.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02102.html
[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02104.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02106.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02106.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02119.html
Kevin expressed[6] a belief that the release date was being done to
suit GNOME at KDE's expense. ArthurPemberton noted that he'd heard
this but asked for actual evidence, while SethVidal bluntly
contradicted[7] the idea, saying that it was in order to not lose
development staff during the winter holidays.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02111.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02132.html
DavidWoodhouse acknowleged that schedules were good but wondered what
was so special about October/April, leading Kevin to mysteriously
pronounce[8] that he suspected he knew the answer. Disappointingly,
rather than admitting to a counter-KDE conspiracy JesseKeating said[9]
that October allowed some slippage without entering holiday time,
while April was ideal for attention and resources. In a further
demonstration of how carefully the conspirators had synchronized their
stories, JeremyKatz gave nearly exactly the same answer[10].
[8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02127.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02128.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02124.html
The Google Summer of Code deadline was raised[11] by MatthiasClasen as
a possible reason to perhaps slip the draft schedule a bit.
KevinKofler felt relieved[12] that GNOME wasn't being held to the same
standards but argued that it was further reason to change the date.
DavidNielsen reported[13] hearing that KDE was also going to target a
six-month cycle and that the rough schedule could be maintained if
Fedora were to attempt to synchronize with KDE. There was significant
agreement with this, but ThorstenLeemhuis suggested[14] that it would
be best to see if KDE4.0 actually manages to ship on time, and then to
synchronize with KDE.
[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00059.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00069.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00156.html
[14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00200.html
=== What Should X-Chat Be Called In The Menu? ===
A debate over what the IRC client "X-Chat" should be named in menus
raged briefly. X-Chat has been covered before[1], as a possible
example of how the community could help with packages post-merge. The
discussion apparently spilled over from @fedora-extras with a post[2]
from KevinKofler objecting to the manner in which some packages
apparently do not follow the FESCo-approved guidelines about what a
".desktop" file should contain. The original post which Kevin was
responding to is apparently not on @fedora-devel.
[1] http://fedoraproject.org/wiki/FWN/Issue88#head-93d08605503d8a9cb111d3d634105b9f7fc69915
[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02138.html
MatthiasClasen thought that "X-Chat" was much less meaningful than
"IRC", but Kevin and JoshBoyer[3] felt that even regular users coming
from a Windows background would understand intuitively what was meant.
Kevin also wondered why GNOME didn't support GenericNames in .desktop
yet, which Matthias answered[4] by saying no one had got around to it
yet. StuardChildern responded[5] by agreeing that the KDE solution of
"X-Chat IRC" was the best. Even better, Stuart analyzed the problem
as being solvable by adding a gconf dependency to libgnome-menu and
volunteered to do this work himself.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02163.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02153.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00000.html
Matthias thought that the desktop team was getting slammed[6] both for
being too like Windows and for not being similar enough and redirected
his energies to productive use.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02164.html
OwenTaylor zoomed[7] the discussion back out to a bigger picture,
noting that the use of GenericName was a holdover from a previous
"Best of Breed" approach to Fedora. Owen posted links to screenshots
illustrating the new approach which uses "Big Board" to display a lot
more information about applications. Owen thought that it would be
best for now to simply use the name "X-Chat IRC Client" as is done for
Firefox, and ignore the GenericName. ToshioKuratomi agreed, but
thought that the Big Board idea was similar to best-of-breed except
that it depended on usage statistics instead of a best guess of
popularity by the distribution.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00002.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00139.html
After JoshBoyer hastened to make it clear that he wasn't slamming
anyone and Matthias clarified that "regular users" wouldn't be able to
choose applications by name, NilsPhillipsen suggested[9] that the
menuing/application-display utility could do some conditional display
of names and genericnames.
[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00085.html
=== FreeTDS Inclusion ===
The maintainer of FreeTDS[1] (which allows interoperability with
Microsoft SQL and Sybase) posted a request[2] for a reconsideration of
a 2005 decision not to include FreeTDS in Fedora. HansdeGoede noted
that there were already packages in the Livna repository, and asked
TomCallaway if it would be necessary to consult Red Hat legal. Tom
responded that he was satisfied that there was no patent problem, and
while he disliked the only documentation of the standard being marked
"confidential" the package could probably move to Fedora.
[1] http://www.freetds.org/
[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02070.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02088.html
=== Simplified Kernel Spec File ===
ValentTurkovic asked for help[1] in getting suspend and resume to work
properly on his laptop. NicolasMailhot noted the difficulty in
getting a kernel to build from the vanilla source and patches due to
the complication of the specfile. RahulSundaram delivered[2] the good
news that this was being worked on and had been discussed on
@fedora-kernel.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02044.html
[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02148.html
=== RPM License Agreement Support ===
HikaruAmanu wanted[1] RPM to be patched so that it could present an
EULA. ChrisBrown thought[2] that Fedora should do nothing to
facilitate companies wishing to release non-Free software, and that
the issue had been discussed previously.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01924.html
[2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01947.html
JesseKeating stated[3] that RPM installation had to be
non-interactive. Several suggested that if this had to be done it
should be post-install. JefSpaleta referenced[4] the old Macromedia
flash-plugin as an example.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01934.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02013.html
=== Don't Put New Packages Through Updates-testing ===
A thread was moved[1] out of @maintainers by HansdeGoede for wider
consumption. Hans was concerned that the new policy of making new
packages go through updates-testing added an unnecessary extra step
and delayed getting the packages into the hands of users.
JesseKeating responded[2] that this wasn't a sudden change, that it
had always been the idea to have new packages enter the
updates-testing repository, and that the only new thing was using
"bodhi" for them. Jesse also asked for actual statistics on how many
people used the updates-testing repository and pointed out that the
important thing was maintaing a stable release for users and that the
QA process for rawhide was not the same.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00053.html
[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00062.html
RalfCorsepius and HansdeGoede felt that it was unlikely that the
testers using updates-testing would be able to appreciate the issues
involved in many of the huge and technically complex packages that
sometimes also require very specialist architectures. WillWoods
responded with[3] an interesting link to his thoughts on how bodhi
presented a balance between the (old) Fedora Core and Red Hat QA
processes and emphasized that what QA testers did was to make sure
that a baseline of verifying that there were no missed dependencies
and that applications appeared to run without segfaulting. Further
discussion suggested[4] that Hans already went above and beyond this
sort of QA and that he would probably thus not experience the delays
he feared. Hans also suggested some useful QA tests that should be
added to the guidelines.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00077.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00131.html
Summing up[5] JefSpaleta suggested that "bodhi" exposed the updates
process and opened up the possibilty for the time spent in
updates-testing to be used in developing scripted QA tailored to each
package in order to ease the maintenance burden slightly (using
"beaker"[6]).
[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00142.html
[6] http://fedoraproject.org/wiki/QA/Beaker
JoshBoyer estimated[7] that the amount of time packages would spend in
updates-testing was a week. In response to Hans' question as to what
factors besides freedom were important to Fedora, Josh suggested that
end-user stability was important.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00111.html
Hans expressed[8] a general feeling that there were too many rules and
procedures instead of trust, prompting agreement[9] from PatriceDumas
that the merge had seen a lot of control move away from maintainers.
RalfCorsepius agreed[10] and suggested that functionality testing was
upstream's job and that all a packager should be responsible for was
whether the package was suitable for public use. MichaelSchwendt also
felt that things were becoming a bit rule-bound, but thought[11] that
testing against segfaulting was essential.
[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00212.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00214.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00222.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00224.html
RahulSundaram and Michael struggled to come to some agreement over
what it would mean for a reviewer to test base functionality. A
concern over the possible discouragement of reviewers was capped with
Michael pointing out[12] the difficulties that even large upstream
teams had in testing functionality and the closing of quick fixes by
what he termed a new bureaucracy. Rahul admitted that the bar had been
raised for reviewers and worried that users would react negatively to
broken packages. Michael thought[13] that the new updates system was
lacking in specific promised QA resources because FESCo had let the
ball drop on these issues. ThorstenLeemhuis was strongly in
agreement[14], feeling that the transition to Koji had not been
accompanied by the necessary agreements about how it would be used,
resulting in loss of community control. NicolasMailhot disagreed[15],
and was suspicious of the frequent invocation of "community" in
defence of large packagers to do what they wanted. Nicolas also noted
that the transition had gone very smoothly. In response PatriceDumas
drew[16] a distinction between packaging guidelines (which were under
community control) and process and workflow (which were not).
[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00230.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00232.html
[14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00259.html
[15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00285.html
[16] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00287.html
A thoughtful post[17] from ToshioKuratomi responded to Thorsten's
assertions about loss of community control by suggesting that what was
happening was delegation of some jobs to teams (such as
ReleaseEngineering and Infrastructure) and the absorption of the old
core-packagers into the community.
[17] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00299.html
JesseKeating made sure[18] that it was clear that not every update had
to go through updates-testing, and seemed to answer Hans' query about
how to expose users easily to the availability of new updates.
Discussion[19] about the mechanism seemed to end in a workable
resolution.
[18] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00087.html
[19] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00134.html
=== Fedora Image As A GRUB Entry ===
Picking up on a report from ChristopherAillon about how he upgraded,
JefSpaleta suggested[1] that it would be nice to provide an F7 package
that created a GRUB bootmenu entry and an installer for F8. This would
allow users without a DVD writer to do a network upgrade via the
installer instead of a yum upgrade.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00109.html
WillWoods was among the many keen on the idea and suggested[2] the
likely things such an installer would do. ColinWalters and Will were
especially interested[3] in the possibility this opened up for
regression testing of rawhide on a regular basis. SethVidal suggested
caution[4] as many of the more fundamental changes (e.g. transition
ext3->ext4) would not be easy to do on a live system.
AlexanderBostrom wondered[5] if that specific transition could be
handled by having everything downloaded and then using a pivot root
similar to the manner in which anaconda does things.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00112.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00119.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00135.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00208.html
SindrePedersenBjordal reminded[6] the list that he had already posted
about a package he had created that did exactly what was proposed.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00308.html
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00109.html
see also
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00016.html
== 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 Report Week 20 ===
The results of the weekly EPEL meeting were published to the
fedora-maintainers-list[1]. In this meeting, MikeMcGrath discussed the
standing proposal to provide RHEL subscriptions to EPEL packagers, six
new contributors were introduced bringing the total number of EPEL
contributors to eighty, and now in total for EPEL 5 there are over 470
binary packages (EPEL 4 binary package count is currently at 358).
[1] https://www.redhat.com/archives/fedora-maintainers/2007-May/msg01000.html
=== Bodhi and Fedora 7 ===
In time for the release of Fedora 7, BillNottingham announced that
Bodhi is now available[1]. For those out of the loop, Bodhi is a
modular Turbo Gears system for issuing updates. AxelThimm had also
requested a how to for bohdi[2].
[1] https://www.redhat.com/archives/fedora-maintainers/2007-May/msg01025.html
[2] https://www.redhat.com/archives/fedora-maintainers/2007-June/msg00030.html
== Documentation ==
In this section, we cover the Fedora Documentation Project.
http://fedoraproject.org/wiki/DocsProject
Contributing Writer: JonathanRoberts
=== Fedora Documentation Steering Committee Meeting ===
The IRC log[1] and the summary[2] of the FDSCo meeting, from 27 May
were posted to the docs-list.
[1] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00163.html
[2] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00165.html
=== Meeting Location ===
KarstenWade proposed that the FDSCo move their meetings to the
#fedora-meeting channel, as he believes more people are lurking there
from across the whole project, and might encourage them to get
involved with the documentation project meetings[1]. It was well
received but decided that the current meeting time on a Sunday was too
distracted by outside life, so the meeting time has been moved to
1600UTC on Tuesdays[2].
[1] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00177.html
[2] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00182.html
=== ISO and Web-Only Release Notes ===
DimitrisGlezos writes[1] to the docs-list to remind people that the
release notes[2] are published in two locations for the two different
types. The release notes included in the ISO (that is, in F7
itself)[3], and the updated, current ones (also called Web-only
because they are not included in the release)[4].
All translated docs that were included in the release should exist
in[3] and be linked from[2].
[1] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00184.html
[2] http://docs.fedoraproject.org/release-notes/f7/
[3] http://docs.fedoraproject.org/release-notes/f7/iso/
[4] http://docs.fedoraproject.org/release-notes/f7//
=== Documentation for Revisor and Other Spin-Making Tools ===
With the release of Fedora 7 there is one significant new feature that
needs proper documentation: custom spins[1]. Anybody wanting to help
contribute documentation for Revisor, Pungi, or Live CD Tools should
post to the fedora-docs-list[2].
[1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00001.html
[2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00007.html
== Infrastructure ==
In this section, we cover the Fedora Infrastructure Project.
http://fedoraproject.org/wiki/Infrastructure
=== Infrastructure Server Organization ===
MikeMcGrath and others had a discussion this week about Apache
tweaks[1] and general network setup[2].
[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg00198.html
[2] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg00207.html
=== Bodhi ===
LukeMacken and others got Bodhi[1] up and running this week.
[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg00267.html
=== New Projects ===
Following the Fedora 7 release, two of the new initiatives requiring
Infrastructure resources were posted about this week.
DimitrisGlezos is kicking off[1] his Summer of Code effort[2], which
involves a common WebUI for Fedora translators that can be used for
contributing up stream as well.
Another project waiting for Fedora 7 is the click-through CLA for the
Wiki, which replaces the need to have a GPG-signed CLA before
contributing to the Wiki. KarstenWade is requesting[3] an
Infrastructure resource to assist with this effort.
[1] http://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg00041.html
[2] http://fedoraproject.org/wiki/SummerOfCode/2007
[3] http://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg00036.html
== Artwork ==
In this section, we cover Fedora Artwork Project.
http://fedoraproject.org/wiki/Artwork
Contributing Writer: JonathanRoberts
=== Fedora 7 Disc Labels ===
LuyaTshimbalanga posted the final artwork for the Fedora 7 CD
labels[1], with the color stripped out from the original EPS in 8
monochrome colors. The artwork is available as both an SVG and an EPS.
Shortly afterward, an updated SVG was also posted[2].
[1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00053.html
[2] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00054.html
Editor's Note: Official Fedora 7 Labels are available at
http://fedoraproject.org/wiki/Artwork/CDArt
=== Default Desktop Theme? ===
A message was posted to the art-list suggesting that the Fedora theme
needs to be "polished"[1]. The central argument was that although the
artwork sees a lot of attention every release, the theme - including
panels and window borders - looks the same each release[2]. Linux Mint
and Ubuntu Studio were both used as examples of what could be
achieved, but it appears that for any new theme to receive popular
backing, it can't resemble Vista[3].
[1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00060.html
[2] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00064.html
[3] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00067.html
=== Fedoraproject.org Banners ===
Nown that the new home page is in place, the idea has been proposed to
include banners advertising special events and drawing focus to
community created spins of Fedora. Anybody interested in creating
banners for the home page should post to the fedora-art-list[1].
[1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00069.html
=== Brazilian Banners ===
JaymeAyres contributed some banners he created to the list[1]. They
are animated GIFs using the Flying High theme and were very well
received.
[1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00082.html
[2] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00000.html
== Advisories and Updates ==
In this section, we cover Secuirity Advisories and Package Updates
from fedora-package-announce.
Contributing Writer: ThomasChung
=== Fedora 7 Advisories and Updates ===
* 2007-06-02 [SECURITY] seamonkey-1.1.2-1.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0066
* 2007-06-02 agistudio-1.2.3-3.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0015
* 2007-06-02 archivemail-0.7.0-5.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0014
* 2007-06-02 dgae-1.1-3.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0013
* 2007-06-02 liferea-1.2.10c-3.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0041
* 2007-06-02 nagi-2.06-3.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0012
* 2007-06-02 revisor-2.0.3.6-1.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0065
* 2007-06-02 roundcubemail-0.1-0.5.beta2.2.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0016
* 2007-06-02 sergueis-destiny-1.1-4.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0010
* 2007-06-01 [SECURITY] galeon-2.0.3-9.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0050
* 2007-06-01 bugzilla-3.0-3.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0017
* 2007-06-01 jd-1.9.5-0.3.beta070528.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0043
* 2007-05-31 [SECURITY] devhelp-0.13-8.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0006
* 2007-05-31 [SECURITY] epiphany-2.18.1-3.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0008
* 2007-05-31 [SECURITY] firefox-2.0.0.4-1.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0001
* 2007-05-31 [SECURITY] jasper-1.900.1-2.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0005
* 2007-05-31 [SECURITY] libexif-0.6.15-1.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0003
* 2007-05-31 [SECURITY] libpng10-1.0.26-1.fc7.1 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0004
* 2007-05-31 [SECURITY] mutt-1.5.14-4.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0002
* 2007-05-31 [SECURITY] yelp-2.18.1-4.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0009
* 2007-05-31 libwnck-2.18.2-1.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0007
=== Fedora Core 6 Advisories and Updates ===
* 2007-06-02 gnome-python2-extras-2.14.2-10.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-564
* 2007-06-02 gpm-1.20.1-84.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-563
* 2007-06-02 kexec-tools-1.101-56.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-560
* 2007-06-02 selinux-policy-2.4.6-74.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-543
* 2007-05-31 [SECURITY] devhelp-0.12-11.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-549-2
* 2007-05-31 [SECURITY] epiphany-2.16.3-5.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-549-1
* 2007-05-31 [SECURITY] firefox-1.5.0.12-1.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-549
* 2007-05-31 [SECURITY] thunderbird-1.5.0.12-1.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-550
* 2007-05-31 [SECURITY] yelp-2.16.0-13.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-549-3
* 2007-05-31 elinks-0.11.1-5.2 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-556
* 2007-05-31 logrotate-3.7.4-14.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-558
* 2007-05-30 [SECURITY] mutt-1.4.2.3-1.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-539
* 2007-05-30 bind-9.3.4-6.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-531
* 2007-05-30 kernel-2.6.20-1.2952.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-513
* 2007-05-30 lftp-3.5.9-0.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-431
* 2007-05-30 net-tools-1.60-76.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-530
* 2007-05-30 selinux-policy-2.4.6-72.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-521
* 2007-05-30 squid-2.6.STABLE13-1.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-535
* 2007-05-30 system-config-soundcard-2.0.6-6.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-537
* 2007-05-30 vsftpd-2.0.5-10.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-536
=== Fedora Core 5 Advisories and Updates ===
* 2007-06-02 gpm-1.20.1-84.fc5 -
http://fedoraproject.org/wiki/FSA/FC5/FEDORA-2007-562
* 2007-05-31 [SECURITY] devhelp-0.11-7.fc5 -
http://fedoraproject.org/wiki/FSA/FC5/FEDORA
* 2007-05-31 [SECURITY] epiphany-2.14.3-6.fc5 -
http://fedoraproject.org/wiki/FSA/FC5/FEDORA
* 2007-05-31 [SECURITY] firefox-1.5.0.12-1.fc5 -
http://fedoraproject.org/wiki/FSA/FC5/FEDORA
* 2007-05-31 [SECURITY] lha-1.14i-20 -
http://fedoraproject.org/wiki/FSA/FC5/FEDORA
* 2007-05-31 [SECURITY] seamonkey-1.0.9-1.fc5 -
http://fedoraproject.org/wiki/FSA/FC5/FEDORA
* 2007-05-31 [SECURITY] thunderbird-1.5.0.12-1.fc5 -
http://fedoraproject.org/wiki/FSA/FC5/FEDORA
* 2007-05-31 [SECURITY] yelp-2.14.3-5.fc5 -
http://fedoraproject.org/wiki/FSA/FC5/FEDORA
* 2007-05-31 logrotate-3.7.3-3.fc5 -
http://fedoraproject.org/wiki/FSA/FC5/FEDORA
* 2007-05-30 [SECURITY] mutt-1.4.2.1-8.fc5 -
http://fedoraproject.org/wiki/FSA/FC5/FEDORA-2007-540
* 2007-05-30 gd-2.0.33-8.fc5 -
http://fedoraproject.org/wiki/FSA/FC5/FEDORA-2007-542
* 2007-05-30 irqbalance-0.55-4.fc5 -
http://fedoraproject.org/wiki/FSA/FC5/FEDORA-2007-532
== Events and Meetings ==
In this section, we cover event reports and meeting summaries from
various projects.
Contributing Writer: ThomasChung
=== Event Report: IV ESLAM - Amazon, Brazil ===
* https://www.redhat.com/archives/fedora-ambassadors-list/2007-May/msg00162.html
=== Fedora Ambassadors Meeting Minutes 2007-MM-DD ===
* No report in this week
=== Fedora Documentation Steering Committee 2007-MM-DD ===
* No report in this week
=== Fedora Engineering Steering Committee Meeting 2007-05-31 ===
* http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070531
=== Fedora Packaging Committee Meeting 2007-05-29 ===
* https://www.redhat.com/archives/fedora-maintainers/2007-May/msg01015.html
=== Fedora Release Engineering Meeting 2007-MM-DD ===
* No report in this week
== Feedback ==
This document is maintained by the Fedora News Team[1]. Please feel
free to contact us to give your feedback. If you'd like to contribute
to a future issue of the Fedora Weekly News, please see the Join[2]
page to find out how to help.
[1] http://fedoraproject.org/wiki/NewsProject
[2] http://fedoraproject.org/wiki/NewsProject/Join
--
Thomas Chung
http://fedoraproject.org/wiki/ThomasChung
--
fedora-announce-list mailing list
[e-mail:fedora-announce-list@redhat.com]
https://www.redhat.com/mailman/listinfo/fedora-announce-list
|
