<edit role="FWN">
by Karsten Wade
Howdy, I'm starting my edit of FWN tonight, I'll go as quickly as I
can. :)
--
Karsten Wade, 108 Editor ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
quaid.108.redhat.com | gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
16 years, 11 months
- 2
- 3
Fedora Weekly News Issue 91
by Thomas Chung
= Fedora Weekly News Issue 91 =
Welcome to Fedora Weekly News Issue 91[1] for the week of June 3rd
through June 9th, 2007. The latest issue can always be found here[2]
and RSS Feed can be found here[3].
[1] http://fedoraproject.org/wiki/FWN/Issue91
[2] http://fedoraproject.org/wiki/FWN/LatestIssue
[3] http://feeds.feedburner.com/fwn
1. Fedora Weekly News Issue 91
1. Announcements
1. Cooperative Bug Isolation for Fedora 7
2. Planet Fedora
1. OLPC: Mesh Networking Overview in Red Hat Magazine
2. Fedora for ARM and cross compilation
3. Innovation in virtualization management tools
3. Marketing
4. Revisor utility creates custom install images for Fedora
1. Review: Fedora 7 Advances on Rivals (eweek.com)
2. Review: Fedora 7 (linux.com)
3. Review: First look at Fedora 7 (distrowatch.com)
5. Developments
1. Community Control And Documentation Of New Workflows
2. Fedora On ARM Architecture Opens Up
Cross-Compilation Discussion
3. A World Of Hurt: Making F7 Install CD Set From DVD
Using FC6 Pungi
4. Splitting Terminfo Out Of The ncurses RPM
5. Eliminating Unwanted RPM Dependencies And
Statically-linked Binaries
6. F7 Images For Mass Production
7. Exploding Trees and SCM
8. Why Emacs Is Not Installed By Default
9. Metalink: A New Way Of Distributing Fedora ISOs?
10. Quick Notes On Update Image Installer And F8 Desiderata
6. Documentation
1. CVS Walkthrough in IRC
2. RPM Guide
3. Fedora Documentation Steering Committee Meeting
4. Fedora 7 FAQ
7. Translation
1. Bugzilla for Trans Team
8. Infrastructure
1. Backups
2. Fedora 7 Upgrade
9. Artwork
1. Fedora 8 Artwork
2. Echo Icon Theme
10. Security Week
1. Google: Attack code more likely on Microsoft IIS
2. Bruce Schneier: Department of Homeland Security
Research Solicitation
11. Advisories and Updates
1. Fedora 7 Security Advisories
2. Fedora Core 6 Security Advisories
12. Events and Meetings
1. Fedora Event Help Needed: 2007 Libre Software Meeting - France
2. Fedora Event Report: LinuxTag 2007 - Germany
3. Fedora Ambassadors Meeting Minutes 2007-06-07
4. Fedora Documentation Steering Committee 2007-06-05
5. Fedora Engineering Steering Committee Meeting 2007-06-07
6. Fedora Packaging Committee Meeting 2007-06-05
7. Fedora Release Engineering Meeting 2007-06-04
13. Feedback
== Announcements ==
In this section, we cover announcements from various projects.
Contributing Writer: ThomasChung
=== Cooperative Bug Isolation for Fedora 7 ===
BenLiblit announces in fedora-announce-list[1],
"The Cooperative Bug Isolation Project (CBI) is now available for
Fedora 7. CBI[2] is an ongoing research effort to find and fix bugs in
the real world. We distribute specially modified versions of popular
open source software packages. These special versions monitor their
own behavior while they run, and report back how they work (or how
they fail to work) in the hands of real users like you. Even if you've
never written a line of code in your life, you can help make things
better for everyone simply by using our special bug-hunting packages."
[1] https://www.redhat.com/archives/fedora-announce-list/2007-June/msg00001.html
[2] http://www.cs.wisc.edu/cbi/
== 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
=== OLPC: Mesh Networking Overview in Red Hat Magazine ===
ChristopherBlizzard points out in his blog[1],
"Dan Williams, John Palmieri and Miguel Alvarez talk about the mesh
networking in the laptop[2]. They talk about the low level
connectivity bits as well as the higher level set of activities and
architecture that we're building. Great job guys!"
[1] http://www.0xdeadbeef.com/weblog/?p=295
[2] http://www.redhatmagazine.com/2007/06/08/inside-one-laptop-per-child-epis...
=== Fedora for ARM and cross compilation ===
AndyGreen points out in his blog[1],
"It's great to see the more discussion around Fedora on embedded
architectures happening over the last two weeks. To play catch up,
these are the three threads I've found that matter:
* Lennert Buytenhek's "fedora for ARM" thread[2]. Lennert has a
Fedora build for ARM with patches ready to be merged.
* Brendan Conoboy's cross-compilation thread[3]. I've worked with
Brendan for years in the embedded tools and OS arena, and he
definitely knows what he's talking about.
* spot's Secondary Architectures thread[4] discusses proposed
policies for handling secondary architectures in Fedora.
The issues are many, varied and complex, but I hope something comes of this."
[1] http://spindazzle.org/greenblog/index.php?/archives/67-Fedora-for-ARM-and...
[2] http://thread.gmane.org/gmane.linux.redhat.fedora.devel/55880
[3] http://thread.gmane.org/gmane.linux.redhat.fedora.devel/56709
[4 ]http://thread.gmane.org/gmane.linux.redhat.fedora.devel/55377
=== Innovation in virtualization management tools ===
DanielBerrange points out in his blog[1],
"For the last couple of years all the hype wrt open source
virtualization has been about Xen. Unfortunately after several years
Xen is still not upstream in LKML, the main codebase being a huge out
of tree patch persistently stuck on obsoleted kernel versions. The Xen
paravirt_ops implementation is showing promise, but its a long way off
being a full solution since it doesn't provide Dom0 or ia64/ppc/x86_64
yet. Then out of nowhere, 6 months ago, a newer contender arrived in
the form of KVM almost immediately finding itself merged upstream. Now
you can't claim to be offerring state of the art virtualization
without including both KVM and Xen. We had to have KVM in Fedora 7.
With excellant forsight, when working to integrate Xen in Fedora Core
5, Daniel Veillard had the idea to create a technology independant
management library for virtualization platforms. This is libvirt[2]."
[1] http://berrange.com/personal/diary/2007/06/innovation-in-virtualization-m...
[2] http://libvirt.org/
== Marketing ==
In this section, we cover Fedora Marketing Project.
http://fedoraproject.org/wiki/Marketing
Contributing Writer: ThomasChung
== Revisor utility creates custom install images for Fedora ==
PaulFrields reports in fedora-marketing-list1[1],
"Nice to see this is getting even more traction and notice.[2]"
"Imagine a customized GNU/Linux distribution, built to your
specifications with a minimal amount of effort on your part. If you
are running Fedora 7, that dream is now a reality, thanks to Revisor,
a graphical interface for building custom install images for Fedora."
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00106....
[2] http://enterprise.linux.com/article.pl?sid=07/06/06/2017215
=== Review: Fedora 7 Advances on Rivals (eweek.com) ===
RahulSundaram reports in fedora-marketing-list[1],
"This review[2] has focused on virt-manager, revisor and package
management improvements"
"In addition to the structural changes that the Fedora project has
made to its software repository framework, the team has noticeably
sped up the distribution's Red Hat Package Manager/Yum package
management backend. Also, as we mentioned earlier, Fedora's graphical
tool for creating and managing virtual machines is much improved as
well. For one thing, the tool now lists idle VMs alongside running
VMs, which is something that only the system's command-line tool was
capable of in previous releases."
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00096....
[2] http://www.eweek.com/article2/0,1895,2142494,00.asp
=== Review: Fedora 7 (linux.com) ===
RahulSundaram reports in fedora-marketing-list[1],
"Fedora 7 was released last week, a little bit behind schedule, with a
spate of new features, updates, and live CD installable "spins" of
Fedora in KDE and GNOME flavors. I found a lot of good in this
release, but a bug in the FireWire stack that attacked my external
backup drive made this release just a little shy of perfect.[2]"
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00094....
[2] http://www.linux.com/article.pl?sid=07/06/06/1327234
=== Review: First look at Fedora 7 (distrowatch.com) ===
LuyaTshimbalanga reports in fedora-marketing-list[1],
"A very positive review[2] from Distrowatch submitted by Chris Smart,
Kororaa developer
>From the initial boot of the installer the system exuded a sense
of stability which filled me with confidence the more I used it.
The installer is probably the best I have ever used and is very
powerful while remaining simple to use. Top marks for that.
Overall, the default GNOME install of Fedora is very good and
(non-free software idiosyncrasies aside) as a Linux distribution
in itself I thought it was excellent. If what you are after is a
reliable, stable, easy-to-use yet powerful Linux distribution out
of the box, then Fedora fits the bill nicely."
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00040....
[2] http://distrowatch.com/weekly.php?issue=20070604#feature
== 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
=== Community Control And Documentation Of New Workflows ===
The shifting sands of power within the Fedora Project continued to
cause a scramble for surer footing within a thread that started[1]
last week. ThorstenLeemhuis clarified[2] to JasonTibbitts that one of
the problems he perceived. Although the merge of Core/Extras was
widely desired, it had happened in a confusing way that required very
close attention to high-volume mailing lists, or else packagers were
suddenly ignorant of the procedures to build or push. Thorsten
emphasized that he did not blame FESCo, but that lots of people were
unhappy with the addition of ACLs (Access Control Lists) to CVS and
the sudden enabling of Koji, Bodhi, and the freeze. Pulling fewer
punches, RalfCorsepius voiced[3] a suspicion that FESCo was impotent
and the real decisions were made elsewhere.
[1] http://fedoraproject.org/wiki/FWN/Issue90?action=show&redirect=FWN%2FLate...
[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00338.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00340.html
Thorsten suggested[4] that "spare-time packagers" should have some
form of representation as they tend not to get their voices heard. He
also wanted to clarify the roles of the Fedora Project Board and
FESCo, especially in the light of upcoming elections to FESCo.
JoshBoyer responded later[5] that he needed time to respond to
Thorsten's email and that silence shouldn't be taken as acquiescence
on any points made in the discussion so far. JesseKeating also
requested[6] that Ralf hold-off on his darker thoughts until
sufficient reasonable time had elapsed for discussion.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00345.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00373.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00375.html
Responding to NicolasMailhot's earlier points about giving the
Infrastructure team more credit, PatriceDumas replied[7] that it
wasn't about giving or withholding credit, but trying to focus on why
specific processes had been made mandatory despite some packagers'
objections and preference for shortcuts. Nicolas responded[8] that
while Extras had been good at packaging policy and build tools, Core
had been good at release-engineering and leaving those decisions up to
individual packagers would be like herding cats. Patrice thought that
education rather than heavy-handed rules were the answer, but Jesse
invoked[9] the weighty counter-argument of experience.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00347.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00350.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00374.html
Confessing that he felt that the F7 workflow had not been ideal, Jesse
suggested a series of release-engineering meetings for anyone
interested. HansdeGoede thought[10] that discontent was not
necessarily due to the freeze workflow, but more likely to the absence
of an updates policy and the absence of proper documentation for new
tools and workflows. Jesse pleaded[11] for anyone that saw inadequate
wiki pages to help out and make the changes. He also defended[12]
against Hans' charge of information being hidden on
@fedora-maintainers by asserting that he had tried to start a new
thread for each new procedure. Jesse further expressed frustration
that there were no positive suggestions for how to improve
communication.
[10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00379.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00386.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00389.html
KevinKofler attested[13] that he just changed incorrect wiki entries
when he came across them, for which Jesse thanked him and then
HansdeGoede provided[14] links to pages that he believed should be
edited by the people introducing changes. Hans made the argument that
those introducing new tools and workflows were best placed to edit
these pages, preferably before making radical changes to the workflow.
Jesse responded[15] that he had been frankly unaware of the
NewPackageProcess page referred to by Hans and suggested that there be
a FESCo requirement that any workflow changes require a draft that
includes a requirement to update the appropriate wiki pages.
[13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00397.html
[14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00410.html
[15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00413.html
A semi-humorous suggestion[16] from HansdeGoede proposed that only
those who maintained thirty or more packages should be allowed to make
rules. There was general agreement that there was an issue to be
addressed with rule-makers being out of touch with the majority of
packagers and also a general disagreement, best expressed[17] by
NigelJones, that there should be any sort of weighting of votes based
on number of maintained packages.
[16] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00213.html
[17] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00334.html
A fork of the original thread was made by JonathanUnderwood to
encourage[18] people to write documentation so that the community
could re-engage. JesseKeating thought this was a great idea and
sought[19] someone to take on the task of co-ordination.
[18] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00399.html
[19] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00406.html
=== Fedora On ARM Architecture Opens Up Cross-Compilation Discussion ===
A (re)introduction[1] from LennertBuytenhek contained a brief resume
of Lennert's impressive hacking history and a tantalizing glimpse of
what the opening up of Fedora to other architectures could mean. The
opening for architectures was originally discussed last week[2],
FWN#90 "Fedora Secondary Architectures Proposal". Lennert had been
maintaining ports of Fedora Core {2,3,4,6} and wanted to merge his
changes back upstream. DaveJones was happy[3] with what he saw and
made the suggestion that the config file shouldn't be monolithic, but
should be generated out of templates, as is done currently for the
Fedora kernel RPM.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00189.html
[2] http://fedoraproject.org/wiki/FWN/Issue90#head-271f52b8e5603cd40d00d7c44e...
[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00292.html
As an aside TomCallaway(spot) noted[4] that SPARC-32 support was
probably going to be dropped in F8, leading to some jokes about the
devastation of its two users. AlanCox thought[5] that Fedora should
track upstream, meaning that if it was supported in the Linux kernel
trees then it should be in Fedora. However, even the fans of the
architecture were unwilling to defend[6] it and pointed out that
upstream were making noises about dropping it.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00463.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00487.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00594.html
Responding to DaveJones' comments, Lennert provided[7] a wealth of
information about the diversity and non-similarity of ARM CPUs in the
course of explaining why a kernel image RPM wasn't actually built at
this point.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00899.html
Also welcoming[8] Lennert was LinusWalleij, who suggested that Lennert
should open bugzilla reports for each package for which he had diffs.
Linus also asked about Lennert's native build strategy as opposed to
cross-compiling and his target system, something in which PeteZaitcev
was also interested[9]. ManasSaksena provided specific details[10] and
also added the information that, unlike other architectures, it would
not be useful to produce an ISO, but instead to produce a package
repository and tools to create custom root filesystems.
[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00501.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00632.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00761.html
HansdeGoede thought that cross-compiling seemed to be difficult unless
the packages had been designed with that in mind from their
inception[11]. AndyGreen had his own experience with cross-compiling
for arm9 and avr to add[12], and argued that improving common packages
to make cross-compiling easier would be a great advantage for Fedora.
ManasSaksena agreed[13] with this and provided encouragement about the
practicality of dealing with Perl and Python. KrzysztofHalasa and
AndyGreen exchanged details[14] of their build procedures.
[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00505.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00509.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00762.html
[14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00545.html
A detailed exploration of the problems of cross-compiling, with
special reference to rpmbuild, was undertaken[15] by Andy and
RalfCorsepius.
[15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00783.html
AdamJackson(ajax) felt that the Xorg packages looked sane and
thanked[16] Lennert for his good work, while noting that the main
change in migrating the packages to F7 was to change ExcludeArch from
ExclusiveArch.
[16] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00542.html
A sub-thread evolved to investigate the problems of
cross-compilation[17]. This sprouted many intricate offshoots, for
instance one in which BrendanConoboy and RalfCorsepius discussed[18]
whether redhat-rpm-config was fundamentally broken or could be
modified to become cross-compilation friendly. Another scion took root
in a discussion[18] of generic cross-compilation on Fedora.
ManasSaksena tipped a nod[19] to a possibly useful tool from
ChrisTaylor called tsrpm, which would allow the systematic derivation
of customized root filesystems for cross-compilation to specific
devices.
[17] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00837.html
[18] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00895.html
[19] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00960.html
Brendan opened[20] a wider discussion with the Fedora community in
which he recounted the experiences of his Red Hat group (GES) that has
largely abandoned native builds and emulators in favor of
cross-compilation. Brendan was enthused by the discussion about ARM
and identified a need for cross-compilers, modified packages, and
volunteers to avoid extra burdens on packagers.
[20] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01006.html
OliverFalk (Alpha ArchTeam) wanted to know[21] specifically if
cross-compilation was always as reliable as native compilation in
exposing errors, and also thought that if specific ArchTeams chose to
eschew cross-compilation then they should be allowed to do so.
AndyGreen backed up[22] Brendan's recommendations (due to his own
experimentation) and answered that there ought to be no difference
between the object code emitted by a cross-compiler or a
native-compiler.
[21] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01075.html
[22] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01078.html
Hastening to make sure that cross-compilation and new secondary
architectures were not conflated, Brendan replied[23] to Oliver that
there while there were some problems unique to cross-compilation it
was nevertheless reliable. Brendan suggested the idea of a CrossTeam
similar to the ArchTeams.
[23] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01186.html
=== A World Of Hurt: Making F7 Install CD Set From DVD Using FC6 Pungi ===
Several posters have expressed disappointment in the past that the
Fedora 7 images were available only as DVD images and not as a set of
CDs. TonyNelson sought help[1] in filling this need. JesseKeating
made[2] some helpful suggestions about how this splitting could be
achieved using Fedora 7 and drew Tony's attention to the novel use of
a manifest file by Pungi instead of comps.xml. In response[3] Tony
clarified that he was specifically only interested in using Pungi from
(and on) FC6 to try to split the F7 DVD.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00638.html
[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00660.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00680.html
JarodWilson thought[4] that Tony had taken on a tough job because the
.manifest was only in post-FC6 Pungi and it wasn't easy to backport.
Tony argued[5] that Jarod was suggesting that CD-only upgraders would
have to install F7 in order to have a way to install F7! He wondered
what problems might occur besides missing 20 packages from comps.xml.
JesseKeating listed[6] some of the huge changes (to pungi, the yum
API, anaconda-runtime calls etc) that would complicate the task that
Tony was tackling.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00684.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00693.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00697.html
Continue probing from Tony prompted[7] Jesse to explain that the
manifest file is of kickstart syntax, the files listed in it are taken
by Pungi, then anaconda tools are run on them. The version of
anaconda must match the one in the distribution.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00699.html
After Tony seemed ready to give up Jesse wondered why he didn't use
the LiveCD image. Tony responded[8] that it was only useful for a
clean install and put the use case of someone with low-bandwidth and
not enough harddrive space for the DVD iso.
[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00708.html
"Vnpenguin" and JarodWilson had both suggested installing "mock" and
using the resulting chroot to run pungi and Jesse pointed to the docs
explaining how to run pungi in mock[9].
[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00801.html
=== Splitting Terminfo Out Of The ncurses RPM ===
The burst of OLPC inspired activity (see "Eliminating Unwanted RPM
Dependencies And Statically Linked Binaries" elsewhere in this issue)
from BernardoInnocenti had the positive side-effect of slimming the
standard Fedora distro. One piece of bloat identified[1] by Bernardo
was the bundling of 2MB of terminfo data with ncurses, which Bernardo
suggested be split out into a separate sub-package. The discussion
was irritatingly split between @olpc-devel and @fedora-devel, which
made it hard to follow.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00459.html
MiroslavLichvar warned[2] that the terminfo data shouldn't be
eliminate entirely but agreed that it could probably be split out.
Referencing[3] Ubuntu's practice, ArndBergmann agreed and suggested a
shortlist of terminals that could be included in the ncurses package
as a safe minimum. Arnd later described[4] the current split of a
small subset into /lib/terminfo while the exhaustive collection is in
/usr/share/terminfo and brought up the problem of 32 and 64 bit
libraries.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00510.html
[3] http://marc.info/?l=olpc-devel&m=118099052410892&w=2
[4] http://marc.info/?l=olpc-devel&m=118113689230162&w=2
The multilib problem was also addressed[5] by BillNottingham who
argued that in order to make upgrades sane, it would be best to keep
the libraries within a package with the same name as the original.
SimoSorce thought[6] that Bill's approach was improperly constrained
by the brokenness of multilib detection. RexDieter agreed[7] that
multilib detection should be fixed but disagreed that Bill's proposal
resulted in substandard packaging. Bill returned to the problem of
making the upgrade work, which JeremyKatz agreed[8] with but suggested
that a work-in-progress from SethVidal might offer a resolution.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00920.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00930.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00936.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00962.html
=== Eliminating Unwanted RPM Dependencies And Statically-linked Binaries ===
Following from the decision[1] to open up the Fedora Project
infrastructure to the OLPC, BernardoInnocenti queried[2] whether it
would be possible to remove some hard dependencies for particular RPM
packages. The advantage for OLPC would be the ability to use pristine
Fedora packages without pulling in unnecessary bloat. This advantage
would accrue to other projects basing themselves off the Fedora
Project.
[1] http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070607
[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00478.html
DavidTimms posted[3] a lovely dependency tree diagram for GRUB,
showing that there would be advantages in separating out the
fedora-logos into their own package. David also noted that
glibc-common was severely bloated by localization (which slowed
install time and presented problems for small harddrives). David
suggested that similar to OpenOffice, the localisations could be split
into sub-packages and hacked into comps.xml. Finally, David wondered
whether there was a tool that would correlate disk-access to files and
thus to RPM packages, allowing an analysis of unused files in
particular RPMs. "SteveG" (StevenGrubb) suggested[4] using auditctl
and aureport for this purpose.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00519.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00550.html
JeremyKatz cautioned[5] against David's suggested approach as it's
result would be an increase in metadata size, an increased rpmdb size,
and unpredictable side-effects due to comps being a bit hackish.
Jeremy also noted that if one were willing to give up being able to
use DeltaRPMs then setting the %_install_langs rpm macro properly will
exclude non-desired locales.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00560.html
David and Jeremy dug deeper into the size trade-offs, with Jeremy
estimating[6] that the increase in metadata and rpmdb size would be
larger than David expected. David had asked whether the installer
could take note of the %_install_langs setting and Jeremy replied that
it didn't (although it used to) and that setting it via kickstart
would be appropriate for small-footprint installs.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00616.html
A suggestion[7] by Bernardo to provide just one mega-locale package,
which would allow the space-constrained (e.g. embedded developers) or
lovers of the plain "C" locale an advantage, was countered[8] by
JeremyKatz as too Western-centric. Jeremy also argued that a frequent
request in the past had been post-installation addition of language
support and the current setup made this much easier. Jeremy then
provided further details of the workings of DeltaRPMs in response to
Bernardo.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00735.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00745.html
As regards the GRUB dependencies, NicolasMailhot pointed out[9] that
the problem would be obviated once the default display of a themed
GRUB menu is removed. After Jesse suggested that the policy on
directory ownership could be relaxed in the case of the fedora-logos
package, DavidTimms was keen[10] to get things rolling or else hear a
definite "No".
[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00595.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00609.html
Another of Bernardo's suggestions was to remove mkinitrd's dependency
on lvm2 and dmraid, but JeremyKatz[11] pointed out that this would
lead to problems with initrd creation in the kernel's %post and
suggested that this was an area that would benefit from some creative
solutions. DavidZeuthen thought[12] that the OLPC's kernel wouldn't
need mkinitrd because it had all the drivers built-in. Bernardo
thought otherwise[13] due to both the dependency and because of the
need to boot from USB with the ext3 image. The need for any static
binaries at all was also questioned, and Bernardo dismissed the "disk
space is cheap" argument. David replied[14] with the suggestion of
using a dummy RPM package to satisfy the dependency and pointed to
UlrichDrepper's post on @fedora-devel on the subject of static
linking.
[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00559.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00582.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00637.html
An ensuing discussion of static vs. dynamic linking between a
skeptical PatriceDumas and BernardoInnocenti led to ChrisAdams
providing[14] some concrete proof that dynamic-linked binaries are
smaller than statically-linked "in the real world". Later Bernardo
diverged slightly into a discussion[15] of how Linux has become
bloated. NicolasMailhot argued that the solution was optimized,
co-ordinated dynamic libraries (citing Pango and Qt's co-operation on
Harfbuzz), to which Bernardo agreed and noted that OSX had banned
static linking with system libraries.
[14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00805.html
[15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00888.html
[16] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01032.html
A dependency of HAL on crypsetup-luks turned out[17] to not be needed
according to PeterJones, helping Bernardo to eliminate 1.2MB.
[17] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00591.html
=== F7 Images For Mass Production ===
Since the release of Fedora 7 ISO images to the mirrors, there have
been several bugs reported and fixed. The availability of these fixes
led to a dilemma[1] for MaxSpevack who was just about to start
pressing DVDs for the FreeMedia program and FedoraEvents, and wondered
whether the original "GOLD" images should be used for Fedora LiveCDs
and DVDs or if updates should be somehow incorporated.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01119.html
The ensuing discussion saw three main viewpoints emerge. The first
was that the GOLD images should be used exactly as though they'd been
pressed immediately upon release of F7 with the simple addition of an
updates.img to fix simple anaconda problems. ChristopherAillon and
JesseKeating were strongly in favor[2] of doing this and adding a
sleeve-note about known bugs and work-arounds. ThomasChung
(coordinator of the FreeMedia program) was also in favor[3], and Max
deferred[4] to their opinions as Jesse has an overview of the
ReleaseEngineering problems while Thomas has his finger on the pulse
of the users of these DVDs. Jesse gave a good quick rundown[4a] of all
the potential problems with regressions that a respin would involve.
PaulFrields pointed to a serious problem with localization that seemed
like it was a simple updates.img fix, but which Jesse's dissection[4b]
revealed as a slightly more complicated, but fixable problem.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01141.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01130.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01151.html
[4a] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01133.html
[4b] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01155.html
Another approach was advocated[5] by WarrenTogami, who suggested that
all that should change would be to update the both the kernel and
anaconda (using an updates.img) to fix some of the egregious bugs such
as non-booting Dell Core2Duo machines and e1000 NIC problems.
ChrisLumens thought[5a] that the updates.img would avoid getting a
fresh-round of bug-reports on known issues. RahulSundaram tried[6] to
figure out why a public point-release wasn't being considered so that
anyone could benefit from the work which Max thought was worth doing.
Suspend/resume breakage was also suggested as a candidate for this
sort of patching, but Rahul's query[6a] as to whether there was a fix
for this remained unanswered.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01122.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01143.html
[6a] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01137.html
Expanding[7] the previous respin idea a bit, HansdeGoede wanted to add
network security fixes. Jesse extrapolated[8] to the likely outcome
of this approach, which he saw as a series of slow-moving bug-fix
releases similar to Red Hat's approach to RHL. AxelThimm noted[9] the
emerging consensus against a respin this time but suggested that in
future there would always be a post-GA respin. Jesse was against[10]
this being done as an "official" Fedora Project undertaking, due both
to the QA problems and because users would simple ignore the GA and
wait for the respin instead, thus deferring the problem. BrunoWolff
thought[11] it might work because the ability to upgrade would be
guaranteed, making it different from a test-release. FedoraUnity had
been mentioned by several people in the discussion and Axel
wondered[12] if something similar were offered on a weekly basis.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01145.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01150.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01212.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01225.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01246.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01249.html
=== Exploding Trees and SCM ===
JeffOllie got the ball rolling[1] for an @fedora-devel discussion of
possible ways and means of replacing the current CVS system with a
more useful SCM (Source Configuration Management system). The
discussion had been started[2] on @fedora-infrastructure and
JeremyKatz had supplied some helpful discussion points.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00839.html
[2] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg0...
JesseKeating thought[3] that with F8T1 being a mere two months away it
was unrealistic to attempt to make the transition before F9. In
addressing the specific desiderata listed by JeremyKatz, it seemed
that Jesse leaned towards using exploded source trees to make it
easier for package maintainers to adapt their patches to changing
upstream, and the "git" SCM to distribute changesets.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00835.html
Jeffrey agreed[4] with Jesse's post-F8 timeframe, but suggested that
it might be possible to implement a system that didn't disturb
packagers' workflows, yet laid the groundwork for a more radical
change in the future. In response Jesse forwarded an @fedora-infra
post from Jeremy that argued[5] that this would actually require
people retraining twice.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00842.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00845.html
Responding to the original discussion points, AxelThimm thought that
easing packagers tracking of upstream depended on what those upstreams
were using as SCMs. Axel also leaned[6] towards a distributed SCM
such as git or Hg to facilitate Fedora downstream fixes making it back
into the Fedora Project easily, with the choice being left up to the
Koji developers who would have to do the actual implementation.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00844.html
A request from Jesse during the discussion was that participants list
features in which they were interested, rather than particular SCMs.
The discussion seemed to peter out on @fedora-devel with a discussion
between Axel and Jesse as to whether or not Hg supported renames[7].
[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01012.html
A related thread from @fedora-infrastructure was cross-posted[8]
separately by JeremyKatz. ChristopherBlizzard advanced[9] the idea
that because Fedora tries to reflect the upstream of each project it
should possibly do that with regard to SCM choice. Jeremy argued[10]
against this as it made it hard to coral changes of Fedora-specific
interest and also introduced a requirement for knowledge and
inter-operation of multiple, different SCMs. Some parts of the
discussion stayed on @fedora-infrastructure.
[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00855.html
[9] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg0...
[10] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg0...
ToshioKuratomi(abadger) suggested[11] looking at what Ubuntu was doing
(albeit for different reasons) with their "Hypothetical Changeset
Tool". In response JesseKeating drew the distinction[12] that
exploded trees with patch management weren't exclusive to generating
SRPMS, but was a layer that could operate as an input to the
buildsystem which would then produce the SRPMS. BillNottingham was
skeptical[13] about how much this would help the drive to cohere with
upstream.
[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00935.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00969.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00976.html
At this point[14] a discussion between NicolasMailhot and
ToshioKuratomi became far too complex for your humble observer to
follow and those interested should probably look at the thread
themselves. The main arguments seemed to be that Toshio liked[15] the
ability to pull specific subsets of patches to submit upstream, which
is given by DRCS. Nicolas thought Toshio's premises were unrealistic
in assuming that Fedora would fork upstream so heavily and also that
his approach would not separate patches specific to Fedora with
patches for upstream[15]. For a full understanding, refer to the
relevant thread.
[14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00964.html
[15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01010.html
=== Why Emacs Is Not Installed By Default ===
After "Shams" asked[1] why Emacs was not installed by default,
ManuelWolfshant shook the hornets' nest by suggesting that not
everyone wanted a second OS installed. OlivierGalbert was the first
to react[2], pointing out that if Emacs were axed then it wouldn't be
long before vi followed, Olivier surmised that "windows envy" was
determining desktop choices. MatejCepl[3] and LinusWallej[4] drew
attention to the POSIX/IEEE 1003.1 requirement for vi, but not for
Emacs.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00470.html
[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00494.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00615.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00502.html
PatriceDumas suggested that the tools for re-spinning Fedora would
allow userbases that had different visions of the desktop to build a
Fedora that they liked, but NicolasMailhot had apparently been stung
by Olivier's comment and bravely plunged on[5], arguing that Emacs was
"going the way of the dodo because it targets 1995-ish desktops". A
swarm of questioners including AndrewHaley sought clarification from
Nicolas, to which he responded[6] that Emacs didn't use the desktop
font infrastructure, i18n, a11y, one of the main GUI toolkits, or
integrate with the printing infrastructure. TomTromey returned[7] to
the question of what specific maintenance burden was imposed by Emacs,
and reminded everyone that Emacs wasn't being removed, it just wasn't
included in the default install. JeremyKatz agreed[8] and pointed out
that the situation had been like this for a while. Nicolas answered[9]
Tom with the information that Emacs' dependency on the legacy font
system was the main problem.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00500.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00540.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00557.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00558.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00593.html
Taking a stab at answering Shams's question, NigelJones guessed[10]
that popularity was probably the answer. Going one better, JefSpaleta
posted[11] statistics from Mugshot that showed Emacs having marginally
more users. AlexandreOliva explained[12] that Emacs did a lot more
than mere text-editing.
[10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00476.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00583.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00644.html
=== Metalink: A New Way Of Distributing Fedora ISOs? ===
A suggestion[1] from AnthonyBryan about a new way to distribute Fedora
using Metalinker[2] has gained some traction. Metalink is an open
standard that puts an XML wrapper around all the possible available
URIs for common protocols such as HTTP and FTP. It allows segmenting
of the source and hence simultaneous downloading from multiple
mirrors. JesseKeating suggested using MirrorManager to automatically
create the metalinks, to which RahulSundaram replied[3] that he'd
suggested this a while ago. A tool authored[4] by DavidTimms to allow
reconstruction of ISO images from previous versions may be useful for
this problem.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01160.html
[2] http://www.metalinker.org/
[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01164.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01207.html
Responding to the positive reception, Anthony (as the author of
Metalink[5]) wondered whether he should supply[6] a patch to
MirrorManager, and was advised to open a discussion with MattDomsch on
@fedora-infrastructure. Anthony pointed out that no other distribution
was generating dynamic .metalinks on a large scale. Matt responded[7]
briefly on @fedora-devel to indicate that he would be happy to accept
and review patches.
[5] http://www.packtpub.com/article/Downloading-evolved-with-Metalink
[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01200.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01230.html
=== Quick Notes On Update Image Installer And F8 Desiderata ===
Last week's thread[1] on providing a grub-entry for an installer image
to facilitate upgrading kept going. WillWoods posted[2] a modified
plan of attack leading JesseKeating to add[3] that yum/rpm would be
needed for depsolving and a pessimistic BillNottingham to warn[4]
about Python ABI changes, JeremyKatz confirmed[5] this pessimism to
an optimistic[6] ColinWalters
[1] http://fedoraproject.org/wiki/FWN/Issue90#head-4fa2b381c1834f3104cff9fe61...
[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00704.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00705.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00725.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00742.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00744.html
In a completely separate thread initiated[7] by HansdeGoede, a laundry
list of desired features for F8 was under construction. Among Hans'
more controversial proposals were a plugin-buddy, a firmware-buddy,
and a proprietary-software-installer-buddy. BillNottingham
wondered[8] which wireless cards the firmware-buddy would be useful
for and didn't like the bug-chasing that would introduced by the
proprietary-software. Hans listed the ralink, BCM43xx, and SIL cards
and agreed with JeremyKatz who expressed[8] a preference for working
upstream with the vendors so that the firmware could be shipped in
perfect working order. Interested thread participants started[9] a
wiki page[9a] to collect and document missing firmware.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00890.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00927.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00955.html
[9a] http://fedoraproject.org/wiki/SIGs/FirmWare
BernardoInnocenti noted[10] that Firefox's plugin system would, if
applied by many applications, lead to Linux "becoming as maintainable
and robust as Windows". RalfErtzinger liked the RPM-free nature of
Firefox plugin installation and TillMaas showed[11] how difficult it
might be for non-root privileged users to install RPMs.
[10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01022.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01290.html
== Documentation ==
In this section, we cover the Fedora Documentation Project.
http://fedoraproject.org/wiki/DocsProject
Contributing Writer: JonathanRoberts
=== CVS Walkthrough in IRC ===
BartCouvreur held a session in #fedora-docs on freenode, explaining
how to use CVS as part of the Docs Project. This session was also
useful as a general introduction to CVS if you've never used it
before. If you're interested in learning how to use CVS, as part of
the Docs Project or more generally, the log of the session was posted
to the fedora-docs-list[1] and is also available as nicely formated
HTML[2]. You can also find detailed information in the Documentation
Guide[2].
[1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00037.html
[2] http://fedoraproject.org/wiki/JohnBabich/CvsLesson
[3] http://docs.fedoraproject.org/documentation-guide/ch-cvs.html
=== RPM Guide ===
JoseManimala volunteered to maintain the RPM guide[1]. This led to a
discussion about the best place for this guide to be maintained. As
the Fedora Project's software aims to stay as close to upstream as
possible, is there any reason why content should not as well?[2]. It
turned out that upstream had already pointed to the guide, and
suggested that people wanting to work on it should do so through the
Fedora Documentation Project[3].
At this point this guide does not have a team around it. If anybody
has experience with RPM and wants to help Jose Manimala, post to the
fedora-docs-list and co-ordinate from there.
[1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00006.html
[2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00038.html
[3] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00061.html
=== Fedora Documentation Steering Committee Meeting ===
The log for the FDSCo meeting of the 5th June was published to the
fedora-docs-list[1].
[1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00054.html
=== Fedora 7 FAQ ===
RahulSundaram forwarded a message to the fedora-docs-list, requesting
that a link to the Fedora 7 FAQ be added to the docs.fedoraproject.org
front page[1]. The message that was forwarded also included a request
for a link to the FAQ to be included on the new fedoraproject.org home
page, which led to a debate over whether this was appropriate, given
that the home page has just been given a minimalist redesign[2].
[1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00057.html
[2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00058.html
== Translation ==
This section, we cover the news surrounding the Fedora Translation
(L10n) Project.
http://fedoraproject.org/wiki/L10N
Contributing Writer: JasonMatthewTaylor
=== Bugzilla for Trans Team ===
DimitrisGlezos and others have been discussing the idea of adding a
Translation team component[1] to Bugzilla in order to better track
changes, change-requests, suggestions, etc.
[1] https://www.redhat.com/archives/fedora-trans-list/2007-June/msg00014.html
== Infrastructure ==
In this section, we cover the Fedora Infrastructure Project.
http://fedoraproject.org/wiki/Infrastructure
Contributing Writer: JasonMatthewTaylor
=== Backups ===
With recent changes and additions to the project infrastructure,
MikeMcGrath and others have decided to look into new backup][1]
options.
[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg0...
=== Fedora 7 Upgrade ===
Fedora 7 being released prompted some discussion[1] about whether or
not to upgrade infrastructure systems. After some discussion it seemed
to be agreed to review each systems requirement and upgrade
accordingly.
[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg0...
== Artwork ==
In this section, we cover Fedora Artwork Project.
http://fedoraproject.org/wiki/Artwork
Contributing Writer: JonathanRoberts
=== Fedora 8 Artwork ===
MatthiasClasen sent a message to the fedora-art-list, hoping to prompt
discussion on the art work for Fedora 8[1]. The central points of his
message were:
* Diana Fong is no longer employed by Red Hat and so it is probable
there will be no full time artist to work on the F8 release
* He proposes trying a different approach to the art work for F8,
less branded and less image based
* The graphical boot is changing and may result in less art work (and
less restrictive art work) for the boot sequence
* Questioned the state of the Echo icon theme - will it be ready for F8?
NicuBuculei proposed that a similar system to Fedora 7 is followed,
where the art work is decided upon through a 3 round competition[2].
As part of this MarekMahut suggested that we try to get schools
involved. It was suggested a possible problem with this would be that
they use proprietary software; virtual workshops about FOSS art tools
was proposed as a possible solution[3].
RahulSundaram reminded the list that one comment that has appeared
fairly often in early reviews of Fedora 7 is that Clearlooks looks dry
compared to the polished appearance of the rest of the
distribution[4]. Following this two new threads were started, creating
mock-ups of new default themes for Fedora 7[5] [6].
MairinDuffy has proposed a milestone based approach for the Fedora 8
art work, which was received well as a preliminary schedule[7].
Highlights of the proposed schedule include a "promo kit" and the
discussion of tag lines and promo banners for the fedoraproject.org
websites, in co-operation with the fedora-marketing-list.
[1] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00002.html
[2] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00003.html
[3] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00019.html
[4] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00012.html
[5] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00052.html
[6] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00069.html
[7] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00039.html
=== Echo Icon Theme ===
Following the thread about Fedora 8 art work, LuyaTshimbalanga updated
the list on the state of the Echo icon theme[1]. The problems with the
SVG icons encountered before the release of Fedora 7 are now fixed,
although a few will need reworking; the Echo pull script is currently
broken on x86_64; work on Echo icons is now resuming.
[1] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00011.html
== Security Week ==
In this section, we highlight the security stories from the week in Fedora.
Contributing Writer: JoshBressers
=== Google: Attack code more likely on Microsoft IIS ===
"Computer World Security reports[1] Google's malware team
discovered[2] that a server running Microsoft IIS is twice as likely
to be hosting malicious software as are other web servers.
The Google team doesn't draw many conclusions from this data. It is
suspected that it's likely a number of these machines are not
automatically installing security updates for one reason or another.
The most disturbing part of the reports is that there are about 70000
domains hosting malware or browser exploits. This is a huge number of
hosts. No doubt some of those domains are purposely hosting exploits,
but it's also disturbing to consider that there are thousands of
administrators who have no idea their server is being used for dubious
purposes."
[1] http://www.computerworld.com/action/article.do?command=viewArticleBasic&a...
[2] http://googleonlinesecurity.blogspot.com/2007/06/web-server-software-and-...
=== Bruce Schneier: Department of Homeland Security Research Solicitation ===
"Bruce Schneier points[1] out a paper from the DHS. They are looking
for researching into how to deter and prevent malware on the Internet.
As Bruce points out, it's about time someone is investing in this
sort of thing. It is shameful how bad computer security is today. As
more and more computers attach to the Internet, the number of infected
machines will continue to increase. Educating users and
administrators isn't working and probably won't. The best solution is
going to be to stop the malware before it has a chance to cause any
damage. There is no doubt a great deal of money to be made in whoever
solves this rather difficult problem."
[1] http://www.schneier.com/blog/archives/2007/06/department_of_h_1.html
== Advisories and Updates ==
In this section, we cover Secuirity Advisories and Package Updates
from fedora-package-announce.
Contributing Writer: ThomasChung
=== Fedora 7 Security Advisories ===
* 2007-06-09 [SECURITY] mod_perl-2.0.3-9.1.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0316
* 2007-06-08 [SECURITY] bind-9.4.1-4.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0300
* 2007-06-06 [SECURITY] freetype-2.3.4-3.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0033
* 2007-06-06 [SECURITY] php-pear-DB-1.7.11-1.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0249
* 2007-06-06 [SECURITY] postgresql-8.2.4-1.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0174
* 2007-06-06 [SECURITY] zvbi-0.2.25-1.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0175
* 2007-06-04 [SECURITY] Network``Manager-0.6.5-3.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0186
* 2007-06-04 [SECURITY] wpa_supplicant-0.5.7-3.fc7 -
http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0185
=== Fedora Core 6 Security Advisories ===
* 2007-06-06 [SECURITY] postgresql-8.1.9-1.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-565
* 2007-06-06 [SECURITY] quagga-0.99.7-1.fc6 -
http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-525
== Events and Meetings ==
In this section, we cover event reports and meeting summaries from
various projects.
Contributing Writer: ThomasChung
=== Fedora Event Help Needed: 2007 Libre Software Meeting - France ===
MaximeCarron reports in fedora-ambassadors-list[1] and requesting help
on his Fedora Event at Amiens, France[2],
"From July the 10th to 14th will occur the RMLL (Rencontres Mondiales
du Logiciel Libre) ie "Free Software World Meetings" in Amiens,
France.
RMLL is a big and great event in France. Lots of poeple are coming
from all over the world, and both high level and beginner conferences
are
planed during the week."
"Currently we're just 2,5 volunteers for this events
(ChristophePolyte, CharlesVinchon, MaximeCarron [i'm the half]), which
is really not
enough. We need your help."
[1] https://www.redhat.com/archives/fedora-ambassadors-list/2007-June/msg0004...
[2] http://www.rmll.info/?lang=en
Editor's Note: Here are online photo albums[1] from 2006 and 2005 events.
[1] http://photo.rmll.info/main.php
=== Fedora Event Report: LinuxTag 2007 - Germany ===
FabianAffolter reports in fedora-ambassadors-list[1],
"LinuxTag[2] is over...we have had a good time there and the attendance of
the Fedora Project at this event was a success. If you want to know what
was going on there, check out the blogs of the attendees."
[1] https://www.redhat.com/archives/fedora-ambassadors-list/2007-June/msg0003...
[2] http://www.linuxtag.org/2007/
=== Fedora Ambassadors Meeting Minutes 2007-06-07 ===
* https://www.redhat.com/archives/fedora-ambassadors-list/2007-June/msg0003...
=== Fedora Documentation Steering Committee 2007-06-05 ===
* https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00054.html
=== Fedora Engineering Steering Committee Meeting 2007-06-07 ===
* https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01166.html
=== Fedora Packaging Committee Meeting 2007-06-05 ===
* https://www.redhat.com/archives/fedora-maintainers/2007-June/msg00332.html
=== Fedora Release Engineering Meeting 2007-06-04 ===
* https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00640.html
== 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
16 years, 11 months
- 1
- 0
development news beat ready for editing
by Oisin Feeley
Hi all,
The @fedora-devel news beat is ready for editing here:
http://fedoraproject.org/wiki/FWN/Beats/Developments#preview
It's a huge one again, taking up a good 10 hours to prepare.
Which leads me to a request. I'd like to have the names of
reporters appear as "bylines" in each FWN issue, as currently
our contributions are pretty anonymous and although it's
interesting I feel slightly as though I'm wasting effort that
could result in more "egoboo".
Opinions?
Best wishes,
Oisin
--
Oisin Feeley
oisinfeeley(a)imapmail.org
--
http://www.fastmail.fm - And now for something completely different
16 years, 11 months
- 3
- 5
Documentation and Artwork
by Jonathan Roberts
Hi,
After the downtime on the list archives last night, I'm only just
getting the beats done - sorry!
I've just put the Docs beat up and I'm about to do the Art beat now.
Again, sorry!!
Cheers,
Jon
16 years, 11 months
- 2
- 2
@fedora-devel News Beat ready for editing
by Oisin Feeley
OK,
Please take a look at:
https://fedoraproject.org/wiki/FWN/Beats/Developments#preview
All links present and correct!
--
Oisin Feeley
oisinfeeley(a)imapmail.org
--
http://www.fastmail.fm - Choose from over 50 domains or use your own
16 years, 11 months
- 2
- 1
Slight problem with getting links for about 50% of @devel newsbeat
by Oisin Feeley
Hi Thomas and all,
I'm afraid that the maintenance downtime of the RH archives means that I
can't put URLs as references to about 50% of the material in this beat.
I also have to be absent for 4 hours starting about 15 minutes from
sending this email. I'll hang on to the end, hoping that the archives
will come back up and will take another look in 4 hours (which is
actually past the deadline for submission) and fix things if it's still
possible then?
Sorry, should have factored this in in advance, but the notice suggested
30 minutes only of downtime.
O.
--
Oisin Feeley
oisinfeeley(a)imapmail.org
--
http://www.fastmail.fm - Or how I learned to stop worrying and
love email again
16 years, 11 months
- 2
- 2
Fedora Weekly News Issue 90
by Thomas Chung
= 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-winn...
=== 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....
[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....
[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-45f52ddea0d1c89a1e166a721b...
[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-93d08605503d8a9cb111d3d634...
[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/<lang>/
=== 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/msg00...
[2] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg00...
=== Bodhi ===
LukeMacken and others got Bodhi[1] up and running this week.
[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg00...
=== 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/msg00...
[2] http://fedoraproject.org/wiki/SummerOfCode/2007
[3] http://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg00...
== 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...
=== 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
16 years, 11 months
- 1
- 0
FWN Issue 90 publish delay
by Thomas Chung
Due to a technical difficulties with Fedora Project wiki system, FWN
Issue 90 will be delayed until later this afternoon.
Regards.
--
Thomas Chung
http://fedoraproject.org/wiki/ThomasChung
16 years, 11 months
- 2
- 3
editorial pass
by Karsten Wade
In the middle of my editorial pass; might take a bit still, as I'm
working through f-devel-l coverage. :)
--
Karsten Wade, 108 Editor ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
quaid.108.redhat.com | gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
16 years, 11 months
- 2
- 1
translation and infrastructure
by Jason
Nothing for translation this week, infrastructure beat is ready for editor
pass!
-Jason
16 years, 11 months
- 2
- 1