|
|
Welcome to Fedora Weekly News Issue 91 for the week of June 3rd through June 9th, 2007.
|
|
= 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. 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-episode-03/
=== 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-cross-compilation.html
[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-management
[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.html
[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.html
[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.html
[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.html
[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%2FLatestIssue#head-d6f0b8d5bcf1e95e8d776ca23d4d8837c27fdfe5
[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-271f52b8e5603cd40d00d7c44ec8632cae42b1aa
[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/msg00074.html
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/msg00091.html
[10] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg00093.html
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 http://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-4fa2b381c1834f3104cff9fe61bf9e49d1b1e1db
[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/msg00065.html
=== 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/msg00098.html
== 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&articleId=9023538
[2] http://googleonlinesecurity.blogspot.com/2007/06/web-server-software-and-malware.html
=== 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/msg00045.html
[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/msg00035.html
[2] http://www.linuxtag.org/2007/
=== Fedora Ambassadors Meeting Minutes 2007-06-07 ===
* https://www.redhat.com/archives/fedora-ambassadors-list/2007-June/msg00032.html
=== 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
--
fedora-announce-list mailing list
[e-mail:fedora-announce-list@redhat.com]
https://www.redhat.com/mailman/listinfo/fedora-announce-list
|
