= Fedora Weekly News Issue 149 =
1.1 Announcements
1.1.1 Features & Final Development Freeze
1.1.2 fedora-wiki list for wiki users and contributors
1.1.3 Fedora 10 Snapshot 3
1.2 Planet Fedora
1.2.1 Events & Trip Reports
1.2.2 Tech Tidbits
1.3 Developments
1.3.1 Splitting Up R
1.3.2 Flinging Poo at libtool-2.2
1.3.3 Livna Migration to RPM Fusion
1.3.4 Sbin Sanity Stays
1.3.5 Packaging Webmin: Should it go in /opt ?
1.4 Translation
1.4.1 Software Translation Deadline Ends
1.4.2 Bugs Filed for Virt-* Package Submissions
1.4.3 Freeze Breaks
1.4.4 Missing Language Files for F10 Release Notes Added
1.4.5 SELinux Tool Translations Not Available
1.5 Infrastructure
1.5.1 Change Freeze Begins Tomorrow
1.5.2 FAS Dump Breakage
1.6 Artwork
1.6.1 Fedora Remix Mark
1.6.2 Echo Icon Theme Future
1.6.3 Sound themes
1.6.4 Four Fs Poster Designs
1.7 Security Advisories
1.7.1 Fedora 9 Security Advisories
1.7.2 Fedora 8 Security Advisories
1.8 Virtualization
1.8.1 Enterprise Management Tools List
1.8.2 Fedora Xen List
1.8.2.1 DomU I/O Performance Sanity Check
1.8.3 Libvirt List
1.8.3.1 sVirt Initial Prototype Release
1.8.3.2 Hot-add SCSI/VirtIO Disks for KVM Guests
1.8.3.3 Domain Events Support Completed
1.8.4 oVirt Devel List
1.8.4.1 New Model for Network Interface
Configuration
1.9 OLPC Fedora SIG
1.9.1 Merging OLPC with Rawhide
1.9.2 Pre-orders for Fedora 10 XO cards Open October
28th
1.9.3 Fedora XO Network Test Meeting
1.9.4 XO - XFCE Fedora 10 Test Team
1.9.5 Sugar Review Activity
1.9.6 OLPC-Community Updates
Welcome to Fedora Weekly News Issue 149 for the week ending October 26,
2008.
http://fedoraproject.org/wiki/FWN/Issue149
We are happy to announce a new beat covering the development of the OLPC
XO laptop and the Sugar interface authored by Pascal Calarco. This week
samples of beat contents include: OLPC detailing "Merging OLPC with
Rawhide"; Announcements alerts us to "Fedora 10 Snapshot 3";
PlanetFedora rounds-up "Events & Trip Reports"; an emotional
Developments stares at "Flinging Poo at libtool-2.2"; Translations
brings news of "Freeze Breaks"; Infrastructure examines some "FAS Dump
Breakage"; Artwork sounds out "Sound Themes" and a new "Four Fs Poster
Designs"; SecurityAdvisories faithfully lists this weeks important
updates; and Virtualization is again compelling reading with a "New
Model for Network Interface Configuration" in its oVirt subsection.
If you are interested in contributing to Fedora Weekly News, please see
our 'join' page[1].
FWN Editorial Team: Pascal Calarco, Oisin Feeley, Huzaifa Sidhpurwala
[1] http://fedoraproject.org/wiki/NewsProject/Join
== Announcements ==
In this section, we cover announcements from the Fedora Project.
http://www.redhat.com/archives/fedora-announce-list/
http://www.redhat.com/archives/fedora-devel-announce/
Contributing Writer: Max Spevack
=== Features & Final Development Freeze ===
John Poelstra announced[0] that "if all goes as planned, the final
development freeze[1] will arrive... on October 28, 2008." All features
and their associated feature pages must be at 100% completion by this
date.
[0]
http://www.redhat.com/archives/fedora-devel-announce/2008-October/msg00013.html
[1] http://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy
fedora-wiki list for wiki users and contributors
Ian Weller wrote[2] about a new fedora-wiki mailing list[3]. "Among the
discussions will be policy, announcements, and editing tips. The list
has been created to bring together the wider wiki community split apart
between different sub-projects of Fedora."
[2]
http://www.redhat.com/archives/fedora-announce-list/2008-October/msg00009.html
[3] https://admin.fedoraproject.org/mailman/listinfo/fedora-wiki
Fedora 10 Snapshot 3
Jesse Keating announced[4] the availability of another Fedora 10
snapshot. "This is the final snapshot before our final devel freeze and
subsequent preview release. On the torrent site you'll find install
images and live images for testing."
[4]
http://www.redhat.com/archives/fedora-announce-list/2008-October/msg00010.html
== Planet Fedora ==
In this section, we cover the highlights of Planet Fedora - an
aggregation of blogs from Fedora contributors worldwide.
http://planet.fedoraproject.org
Contributing Writer: Max Spevack
=== Events & Trip Reports ===
Yaakov Nemoy wrote[0] about his trip to the Central Pennsylvania Open
Source Conference.
[0] http://loupgaroublond.blogspot.com/2008/10/cposc-endnotes.html
Max Spevack posted[1] about his experiences at Athens Digital Week, as
did Diego Zacarao[2].
[1] http://spevack.livejournal.com/67628.html
[2] http://diegobz.net/2008/10/18/athens-digital-week-day-1-and-2/
Greg DeKoenigsberg and Chris Tyler both[3] posted[4] about the first day
of FSOSS in Toronto. Of particular interest is the "Teaching Open
Source" track[5], as well as the FSOSS planet[6] and flickr[7] page.
Jack Aboutboul posted[8] about his first day at FSOSS, as did[9] Paul
Frields.
[3] http://gregdek.livejournal.com/37958.html
[4]
http://blog.chris.tylers.info/index.php?/archives/145-FSOSS-Begins.html
[5] http://fsoss.senecac.on.ca/2008/?q=node/78
[6] http://zenit.senecac.on.ca/~chris.tyler/fsoss-planet/
[7] http://flickr.com/photos/tags/fsoss2008
[8]
http://jaboutboul.blogspot.com/2008/10/id-rather-be-with-animal-part-1.html
[9] http://marilyn.frields.org:8080/~paul/wordpress/?p=1243
Sandro Mathys had done a fantastic job preparing for FAD EMEA, and he
posted the latest status update about that event to all the
Ambassadors[10].
[10] http://blog.sandro-mathys.ch/2008/10/23/fad-emea-2008-3-weeks-to-go
Tech Tidbits
Fabian Affolter prepared[11] five activities for the XO, and submitted
the packages for review.
[11]
http://fabaff.blogspot.com/2008/10/xo-activities-for-fedora-part-ii.html
Jeremy Katz discussed[12] some tips about the best way to make the
Fedora 10 Snapshot 2 work on the XO.
[12] http://katzj.livejournal.com/441143.html
Dan Walsh wrote[13] an interesting blog post about "security vs.
usability" tradeoffs, based on his experiences at a conference in
Washington. The full post is related to both SELinux and Xen.
[13] http://danwalsh.livejournal.com/25265.html
John Poelstra posted[14] an article that emphasisizes the WHY, as
opposed to the HOW, of bug triage. Two of the reasons that he mentions
are that triage "saves package maintainers time chasing down missing
information in bug reports" and that it "allows maintainers to spend
their finite time on bugs that are ready to be worked on".
[14] http://poelcat.wordpress.com/2008/10/20/why-bug-triage/
== Developments ==
In this section the people, personalities and debates on the
@fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
=== Splitting Up R ===
Tom Callaway alerted[1] the list that he intended to merge the R-devel
package with the base R[2] package. Tom's motivation was that many
complaints had been received from users who attempted to install
extensions from the external CRAN[3] repository using R's built-in
package system. "This doesn't work unless you have R-devel installed.
The average R user is a professor or a student, and neither of them are
going to necessarily possess the necessary Linux/Fedora knowledge to be
able to understand why this doesn't work like the R documentation says
it should." Tom recognized that this was a violation of the Fedora
Packaging Guidelines[4] and that he was "[...] not entirely sure if I
need FESCo or FPC approval to take this action, if so, this is my notice
of requesting it. ;)"
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02240.html
[2] R is an interpreted language based upon S and Scheme intended to be
used for statistical computation: http://www.r-project.org/
[3] http://cran.r-project.org/
[4] http://fedoraproject.org/wiki/Packaging/Guidelines
Enrico Scholz suggested[5] instead: "[...] add it to comps.xml [or] move
'R' to Rcore, and add 'R' which depends on 'R-core' + 'R-devel"' which
have the major advantage of not missing all of R-devel's dependencies.
Tom accepted[6] these points because "[...] the suggested
R/R-core/R-devel split instead [would allow users] to get everything
with yum install R, it would meet the guidelines, and minimal installs
with R can simply have R-core."
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02249.html
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02251.html
James Antill agreed that the general model of "foo-core + additions" was
maintained by such a split but asked[7] "[...] why don't we just package
more of the R modules so CRAN usage isn't a requirement?" José Matos
answered[8] that there were far too many R modules "[...] more than 1500
modules (the have been growing at an exponential rate in the last
years). So while we would like to see more R packages in Fedora in are
not even near to have a reasonable subset of R packaged." James
worried[9] that "[...] you could use that argument a lot (there are
probably still more unpackaged libc using things than packaged)." James
showed that there were many more unpackaged users of libc than packaged
using:
repoquery -whatrequires '*-devel' | \
fgrep -v - '-devel-' | \
fgrep -v - '-static-'
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02267.html
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02272.html
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02274.html
The availability of a tool named R2spec to convert R package formats to
rpm packages was mentioned[10] by Matthew Salzman. Later threads which
appeared in part only on @fedora-r-devel investigated the problem of
languages implementing their own packaging systems. José Matos
played[11] Devil's Advocate with the remark that "[...] each language is
building its own repository and packaging system in a sense we have lots
of equivalents of (yum+rpm) for each language (perl, php, python, R,
tex, ...) [but] for the system to be really useful it must use the least
possible denominator (read the dumbest wins- pun intended ;-) )." José
suggested that R2spec could also be tweaked to discover dependencies and
include them in its generated spec files. It appeared[12] that
Pierre-Yves had a "[...] small script to update the spec file when there
is a new release of an already package R-library. This might be
something that I should develop maybe a bit more now (especially since
Bioconductor[12a] 2.3 has been released with R 2.8.0)"
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02288.html
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02301.html
[12]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02306.html
[12a] Modules primarily for bioinformatics and genomics.
=== Flinging Poo at libtool-2.2 ===
A discussion on the future of libtool in Fedora is worth reporting
although it is slightly older. Orion Poplawski wondered[1] whether it
was the correct time to integrate libtool-2.2.X into Fedora 11. Benjamin
Kosnik wanted[2] it available in Fedora before GCC was bumped to
gcc-4.4.x as that will depend on libtool-2.2.6.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00467.html
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00516.html
A possible need for FESCo approval was expressed[3] by Karsten Hopp as
he was worried that "[...] it breaks up to 300 packages according to my
mass rebuilds. I'm going to prepare a Wiki page with details about
that." That prompted the first of several queries about the purpose and
suitability of libtool. David Woodhouse asked[4] "[i]sn't the whole
point of libtool that it should make things _easier_, not break huge
swathes of packages whenever we change it? How about we fix those 300
packages by making them _not_ use libtool, rather than making them use
the latest version?" Toshio Kuratomi thought[5] that "If the state of
the art has advanced and there's a tool that can replace libtool so a
developer can say `I want a shared library' and the tool builds it on
all platforms then we could look into getting upstreams to switch but
simply getting rid of libtool in favour of handcoding Makefiles to build
shared libraries is a step in the wrong direction."
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00479.html
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00730.html
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00737.html
AdamJackson offered[6] that gcc was available on Solaris, Windows, *BSD
and OSX with the conclusion "[m]st of the complexity in libtool (and
autotools in general) is to support systems that simply are not worth
supporting and that practically speaking don't exist anymore. I'm being
slightly flip in saying 'gcc -shared' but really not by much. Honestly
for any fringe platform the correct thing to do is port
gcc/binutils/gmake first." There were many disagreements on this point
and Sam Varshavchik posted[7] a convincing potted summary of them:
"There's much more to libtool then just building shared libraries. If
you remove everything from libtool that supports ancient platforms,
you'll still have quite a bit left. For example, libtool builds both
shared and static libraries in parallel. That, alone, saves you from
dealing with a massive hairball in your makefiles. Ask anyone who works
on a large, complicated app, that links with its own shared libraries.
The option to easily build a statically-linked version is quite
invaluable, for debugging purposes."
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00744.html
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00791.html
The practical experience of the MinGW project related[8] by
DanielBerrange was also that gcc -shared was insuOEcient i[...] if
you're trying to build for windows. The mingw32 work has only been made
viable because libtool has basically taken care of the horrible shared
library build process required by Windows.j Further details were
supplied[9] at Adam's request and KevinKoAEer confirmed[10] that
producing a DLL involved several complications.
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00743.html
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00755.html
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00780.html
Discussion of alternatives veered[11] towards CMake. Braden McDaniel was
unconvinced[12] that this was a realistic suggestion for replacing
libtool in approximately three hundred upstream projects. Kevin Kofler
took[13] a detailed look at the problem and argued that attempting to
"[...] convince the automake developers to use something other than
libtool is pointless, because automake should also go away, it's at
least as obsolete, buggy, unable to maintain backwards compatibility,
annoying, a massive time waster at build time and a major PITA for
developers to code with as libtool is. The whole autotools stack sucks.
It always did, we just didn't have anything better. We now do, so why
are people still using autotools?" His critique seemed convincing and he
later added[14] that "CMake is used by all of KDE 4 [...]" and in an
exchange with Richard W. M. Jones explained[15] that Gnulib was also not
a good replacement for autotools: "[...] a "library" which works by
copying itself into the source code of the project is a horribly broken
concept."
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00780.html
[12]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00775.html
[13]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00799.html
[14]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01017.html
[15]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01142.html
Lennart Poettering and Ralf Corsepius were[16] suspicious of the attempt
to replace autotools with CMake. Ralf argued that "Cmake is imake in new
clothes and suffers from the same design flaws as imake did. It's only
the limited set of requirements being used by the limited set of use
cases it's proponents apply which lets them think 'cmake is better'."
StephenSmoogen saw[17] a need to halt the conversation when he examined
it from a human neuropsychology viewpoint: "So basically this
conversation is a 'dead' conversation. People have their hairs on their
necks up, [enough] testosterone pumping to put [out] 3 or 4 beards in a
day, and are [on] to the flinging poo part. At this point, there is no
way either side is going to say that Cmake is better at this, or
Autotools is better than that. Wait a week, and see if one can bridge
the gap with some diplomatic discourse[.]"
[16]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00954.html
[17]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01023.html
Later a new thread was started[18] by Braden McDaniel to recommend that
autoreconf should be explicitly forbidden to be run by rpm packages. He
explained that he saw the problems caused by running autoreconf or
libtoolize as "[b]y running autoreconf, the RPM build becomes exposed to
different versions of autoconf, automake, and libtool than were used by
the upstream developer to create the upstream source package. Newer
versions of these tools have the potential to introduce
incompatibilities, breaking the RPM build. Rather than patching
configure.[ac,in] and Makefile.am, a more resilient approach is to patch
the configure script and Makefile.in files."TillMaas added[19] a link to
a wiki draft on the subject and suggested that "[...] one should run
autoreconf locally and create a patch from this, that is then used
within the spec." The conversation veered[20] into sharp disagreement as
to whether autotool generated files should be treated similarly to
"binary JARs (for which the packaging guidelines mandate that they have
to be removed and rebuilt from source)" or this should be avoided in
order to avoid "potential breakage". This issue seems destined to
generate further disagreement.
[18]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00866.html
[19]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00869.html
[20]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00970.html
=== Livna Migration to RPM Fusion ===
Several of the third-party repositories external to the Fedora Project
agreed some time ago to merge into a single new entity named "RPM
Fusion"[1]. The current partners include Dribble, Freshrpms and Livna.
Thorsten Leemhuis reported[2] that "[...] nearly all of livna's packages
have been imported and build for RPM Fusion, but a few are still
missing. So you should leave livna repos enabled for now if you want
everything [.]" Thorsten explained the migration process in this post
with the important details that "[...] all users that installed livna
properly (e.g. by installing the livna-release package) and enabled the
testing repos will now get RPM Fusion enabled automatically."
[1] http://rpmfusion.org
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02367.html
A suggestion was made[3] by Nicolas Mailhot to either use the "modern
proxyfriendly createrepo" or else "define http.caching=packages" in the
yum repo files.
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02368.html
Users who currently have the Livna repository enabled can transition to
the new RPM Fusion repository by:
yum install rpmfusion-free-release rpmfusion-nonfree-release
=== Sbin Sanity Stays ===
The latest FESCo meeting[1] logs record that the decision to add /sbin
to each users PATH variable (see FWN#146[2]) will be kept until a
working alternative for both non-root and root users is available. The
brief deliberations indicate that FESCo members tended to manually add
/sbin to their own paths and distilled the objections to the sole point
of "".
Thorsten Leemhuis was dismayed[3] and agreed with Ville Skyttä that the
change would4 result in many confused users. Thorsten wished to "[...]
help Ville and Matthew making a real solution, where sbin stays "root
commands" only, and where package that are right now get into he search
path for ordinary users (either with symlinks or by moving the
binaries). But it's IMHO best for everyone if we do that for F11. Come
on, we had /sbin not in the path for more then how many years, so what
is one half year more (especially as everyone that dislikes it is used
to enable it already)?"
Jon Masters disagreed[5] on the basis that any script should be using an
explicit and absolute binary location anyway: "If you're writing scripts
and not explicitly calling out the binary location, then it's not
surprising if your scripts break later. I know it's nice to always
assume a particular PATH, but it's not good practice any more than
including or not including sbin in the PATH to begin with." He also
cautioned that most other distributions had made this change a long time
ago and that "[...] everyone else is already laughing that Fedora didn't
do this, so really it doesn't need to wait for yet another 1.5 years to
get done :)"
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02273.html
[2]
http://fedoraproject.org/wiki/FWN/Issue146#PATH:.2Fsbin.Tab.Confusion
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02294.html
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02180.html
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02296.html
=== Packaging Webmin: Should It Go In /opt ? ===
Andy Theuninck asked[1] for some help in "[...] trying to put a package
together for webmin. It wants to install to libexec, but if I do that
rpmlint (rightly) complains that there are non-executable text files.
Perl files & HTML files are intermixed and separating them out would be
a patching nightmare [...] as I read FHS /opt would be the most
appropriate place [but] if I try to use /opt/webmin [then] rpmlint
pitches a fit about using /opt."
Toshio Kuratomi quoted[2] the FHS[3:] "The FHS says: /opt is reserved
for the installation of add-on application software packages. Anything
packaged by Fedora is part of the system packaging rather than an addon
so we stay out of /opt." He also suggested that separating the different
files types and getting webmin's upstream[4] to accept patches to do
this was a preferred path in the Fedora Project. Failing this it was
possible to separate the files and symlink them to the upstream-enforced
layout. Another useful link[5] to the Fedora Project's web application
packaging guidelines in Toshio's post indicated that non-executable
files might best be put into /usr/share. Andy seemed[6] to like the idea
of "[m]oving as much as possible over to /usr/share and symlinking
against the files that are actually needed[...]" as this would allow
upstream to continue to support many OSes by the simple expedient of
"sticking everything into a single directory."
Nicolas Mailhot disparaged[7] the use of /opt as "[...] he right place
to dump messes and is good enough for ISVs with no ambitions but Fedora
does not package messes [.]" Casey Dahlin cautioned[8] Nicolas "Easy,
he's here because he wants to do the right thing, and he's not upstream,
so there's no reason to clueby4 him just yet" and went on to suggest a
similar path to that above: "You might do what apache does and simply
place the files where they go, then symlink them to a conf directory in
/etc . You'd be doing it on a much larger scale than apache, but until
you get upstream to suck less, you at least have a precedent for it
(though doing it for apache hasn't particularly encouraged them to
change their goofy-as-hell recommended file layout)."
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02289.html
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02291.html
[3] Filesystem Hierarchy Standard: http://www.pathname.com/fhs/
[4] http://www.webmin.com/
[5] http://fedoraproject.org/wiki/Packaging/Guidelines#Web.Applications
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02327.html
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02297.html
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02300.html
== Translation ==
This section covers the news surrounding the Fedora Translation (L10n)
Project.
http://fedoraproject.org/wiki/L10N
Contributing Writer: Runa Bhattacharjee
=== Software Translation Deadline Ends ===
The software translation deadline for nearly all modules in Fedora ended
on 21st October 2008. A few special modules like Anaconda would still be
updated until prior to release time. Currently, the Fedora Translation
Project members are concentrating their efforts on the documents,
especially the Fedora Release Notes. The deadline for translations of
the GA version of the F10 Release Notes is 13th November 2008[1]
[1]
http://poelstra.fedorapeople.org/schedules/f-10/f-10-trans-tasks.html
=== Bugs Filed for Virt-* Package Submissions ===
NorikoMizumoto[2][3][4][5][6][7][8] and AnkitPatel[9] announced the bug
numbers on Red Hat bugzilla, which would be used to submit the various
virt-* modules. These modules are not available for submission via
translate.fedoraproject.org interface at the moment. Bugs for submitting
translations for System-config-display[11] and desktop-effects[10]
modules were also filed.
[2]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00147.html
[3]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00148.html
[4]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00149.html
[5]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00150.html
[6]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00151.html
[7]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00152.html
[8]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00153.html
[9]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00174.html
[10]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00145.html
[11]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00146.html
=== Freeze Breaks ===
System-config-firewall[12], Comps[13] and Packagekit[14] modules
underwent string freeze breaks this week due to feature inclusion and
typo correction in the main modules. The maintainers have assured that
the packages would be rebuilt to ensure the inclusion of the updated
translations.
[12]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00143.html
[13]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00166.html
[14]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00175.html
=== Missing Language Files for F10 Release Notes Added ===
Files for a few languages were added in the git repository for the F10
Release Notes by KarstenWade[15]. As a result, translators can easily
find relevant files in the translate.fedoraproject.org interface and
submit the translations too.
[15]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00195.html
=== SELinux Management and Policy Generation Tool Translations Not
Available ===
IgorSoares reported[16] the non-availability of the translations for the
SELinux Management and Policy Generation Tools on the user interface. A
bug has been filed[17] as well.
[16]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00199.html
[17] https://bugzilla.redhat.com/show_bug.cgi?id=468383
== Infrastructure ==
This section contains the discussion happening on the
fedora-infrastructure-list
http://fedoraproject.org/wiki/Infrastructure
Contributing Writer: Huzaifa Sidhpurwala
=== Change Freeze Begins Tomorrow ===
Mike McGrath wrote[1] on the @fedora-infrastructure-list sent out a
reminder that another pre-release change freeze will start and last till
11-05-2008.
[1]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-October/msg00070.html
=== FAS Dump Breakage ===
Michael Schwendt wrote[2] on the @fedora-infrastructure-list that there
has been an invalid entry returned by the FAS group dump for some time:
bbs,disabled,james francis toy iv,user,0.
[1]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-October/msg00089.html
To this Nigel Jones added[2] that "The comma is part of the persons
name, it needs to be either escaped or the delimiter changed (maybe a |
or something)." Mike, however, said[3] that there aren't any comma's in
that persons name, its in his email address.
[2]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-October/msg00090.html
[3]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-October/msg00092.html
== Artwork ==
In this section, we cover the Fedora Artwork Project.
http://fedoraproject.org/wiki/Artwork
Contributing Writer: Nicu Buculei
=== Fedora Remix Mark ===
A few weeks ago when the process started, we reported about the request
for a secondary trademark design for "Fedora Remix", a process which
closed to the decision. On a cross-thread on both @fedora-art and
@fedora-advisory-board Greg DeKoenigsberg opined[1] for leaving the
ultimate decision to the Art team "I don't suppose we could just defer
to the Fedora Art team to make a decision, since we have set them up to
be the authoritative voice on precisely these kinds of matters?" This
opinion was backed by a number of other members.
[1]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00152.html
With the decision chain established, the Art team quickly converged[2]
to a final design[3] by Nicu Buculei and its usage guidelines[4] by
Máirín Duffy.
[2]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00199.html
[3]
https://fedoraproject.org/wiki/Image:Fedora_secondary_logo_drafts_nicubunu_color2.png
[4]
https://fedoraproject.org/w/uploads/2/29/Fedora_secondary_logo_draft_guidelines.png
=== Echo Icon Theme Future ===
In a long mail to @fedora-art Martin Sourada exposed[1] his plans for
the future of the Echo icon set "I'd like to focus on (nearly) full
coverage of Desktop Live Spin, KDE Live Spin and XFCE Live Spin (others
as well, but I don't have them all in memory)". He also pointed to some
criticism about the set "we are a lot criticized for inconsistencies in
the projection we use in echo" and talked about the various perspectives
used "strictly speaking we are using 3 different types of projections
and we have rules which is used where and we are pretty much consistent
with that", a topic covered also on his blog[2] and proposed a
simplification "But on the other side it turns out that having three
main types of projections is too much for an icon set and that having
two is about the right number."
[1]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00229.html
[2]
http://mso-chronicles.blogspot.com/2008/10/echo-icon-theme-perspective-part-i.html
Hylke Bons, an Ubuntu developer, weighed in[3] against the isometric
perspective in Echo "I'm still not a fan of the isometric view of the
bigger icons, i think it causes most of the noise in the icons. Also, I
do not see a need for that particular viewpoint", while Luya
Tshimbalanga proposed[4] a simpler perspective for some image sizes "I
remember having a discussion with Máirín about setting perspective for
24x24 and less icons. Perhaps applying that illustrated perspectivs to
all categories at those sizes might help. Spherical icons will have much
impact."
[3]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00230.html
[4]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00231.html
=== Sound Themes ===
Nicu Buculei relayed[1] to @fedora-art a blog post[2] where Lennart
Pottering raised a call for XDG sound themes and also expressed his
concerns about how the team may have not encouraged a contributor "I am
afraid we may have driven away Chris with the lack of feedback when he
tried to create one" and a possible conflict with with the Desktop Team
agenda "Also, with the Echo experience fresh in mind, I wonder if we
create a new set only to get it called a 'charade' and 'if you think
what you're doing is 'value add' that makes Fedora look better than the
'competition' you are wrong'."
[1]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00235.html
[2] http://0pointer.de/blog/projects/free-sound-themes.html
William Jon McCann replied[3] pointing to the lack of quality of the
earlier theme proposal "However well intentioned Chris' effort may have
been, the results are not suitable for use in a high quality desktop
product. Have you actually listened to the theme that you reference
here?" and likened it to the work on icons: "This is the same problem
that some of us have with the way the icon theme and background art work
has been handled in Fedora. I personally love to see lots of energy and
experimentation going on. But at the end of the day we have to be
concerned about our audience and how everything integrates into a
coherent product" and also on wallpapers: "I think that the desktop
wallpapers we've used by default are a good example of this".
[3]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00246.html
Máirín Duffy felt patronized[4] "I trust that was meant with the best of
intentions, so I'm sad to admit I can't help finding this somewhat
patronizing, sorry" and likened the open artwork creation with the open
code creation "Just as you can't follow a formula like the GNOME HIG and
pop out a beautiful, usable interface, you can't follow a formula like
the Fedora theme guidelines and pop out a beautiful theme. The magic in
between that makes something good is design. I'm quite saddened by the
fact that you don't seem to believe this team has or is capable of
having that magic, but I suppose to relate it to coding as you did in
your message, perhaps not everyone felt Linus had the magic or
capability to develop the magic necessary to start a real, usable
operating system."
[4]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00248.html
Paul Frields defended[5] the art team "The Artwork team has always been
open, in my experience, to criticism and suggestions about artwork. They
exemplify the way Fedora teams work openly and transparently in a
cooperative effort. And they've consistently turned out designs that are
always solid, and often spectacular, not just for the desktop but for a
variety of other uses too" and "At the end of the day, the Fedora
Artwork team has been charged with the responsibility of the look and
feel of Fedora. They're expected to do -- and have done -- that work in
a community-friendly way, and people who want to have input into the
process should do the same."
[5]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00250.html
Nicu Buculei showed[6] that open art should be developed in the same way
as open software "Yes, I listened to the theme and found it not perfect.
But know what? It was NOT supposed to be perfect... the 'release early,
release often' mantra in FOSS is exactly that, put your work in the open
as soon as possible so other can play with it, comment or contribute.
How can the author improve his work without our feedback, knowing which
parts are good and which suck?"
[6]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00262.html
=== Four Fs Poster Designs ===
Máirín Duffy showed[1] to @fedora-art and @fedora-marketing a number of
posters[2] for the new "Four F's" (freedom|friends|features|first)
Fedora slogan, posters received with awe by the community,a sentiment
probably described[3] best by Ian Weller: "I saw these and my mouth was
gaping open. These are very, very, very, very, very, very cool! Now I
want to frame them and put them in my room."
[1]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00247.html
[2]
http://duffy.fedorapeople.org/collateral/fourfs/individual%20posters/
[3]
https://www.redhat.com/archives/fedora-marketing-list/2008-October/msg00231.html
== Security Advisories ==
In this section, we cover Security Advisories from
fedora-package-announce.
https://www.redhat.com/mailman/listinfo/fedora-package-announce
Contributing Writer: David Nalley
=== Fedora 9 Security Advisories ===
* cman-2.03.08-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00666.html
* jhead-2.84-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00511.html
* php-Smarty-2.6.20-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00522.html
* squirrelmail-1.4.16-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00661.html
* gfs2-utils-2.03.08-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00665.html
* kernel-2.6.26.6-79.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00693.html
* git-1.5.6.5-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00729.html
* ktorrent-3.1.4-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00781.html
* mantis-1.1.4-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00504.html
=== Fedora 8 Security Advisories ===
* jhead-2.84-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00531.html
* php-Smarty-2.6.20-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00633.html
* mantis-1.1.4-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00648.html
* rgmanager-2.03.08-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00664.html
* kernel-2.6.26.6-49.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00689.html
* squirrelmail-1.4.16-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00735.html
* drupal-5.12-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00783.html
== Virtualization ==
In this section, we cover discussion on the @et-mgmnt-tools-list,
@fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora
virtualization technologies.
Contributing Writer: Dale Bewley
=== Enterprise Management Tools List ===
This section contains the discussion happening on the et-mgmt-tools list
=== Fedora Xen List ===
This section contains the discussion happening on the fedora-xen list.
==== DomU I/O Performance Sanity Check ====
Ask Bjørn Hansen asked[1] if the disk throughput he experienced matched
what others see. The dom0 host achieved 120MB/sec sequential write
speed, and a domU only 22MB/sec.
Troels Arvin's experiences with paravirt Xen on raw devices were fine
for normal I/O but bad for low-level operations like file system
creation. Troel also posted[3] some benchmark results in 2007.
[1]
https://www.redhat.com/archives/fedora-xen/2008-October/msg00012.html
[2]
https://www.redhat.com/archives/fedora-xen/2008-October/msg00013.html
[3] http://article.gmane.org/gmane.comp.emulators.xen.user/29483
=== Libvirt List ===
This section contains the discussion happening on the libvir-list.
==== sVirt Initial Prototype Release ====
James Morris requested[1] comments on an initial prototype of sVirt[2]
v0.10. sVirt was first mentioned in FWN #138[3].
"The purpose of this release is to establish a proof of concept of
applying security labels to VMs, and for discussion of the underlying
technical approach."
"With this release, it is possible to define a security label for a
KVM/QEMU domain in its XML configuration ('virsh edit'), launch the
domain and have it transition to the specified security label ('virsh
start'), then query the security label of the running domain ('virsh
dominfo')."
[1]
https://www.redhat.com/archives/libvir-list/2008-October/msg00478.html
[2] http://www.selinuxproject.org/page/SVirt
[3]
http://fedoraproject.org/wiki/FWN/Issue138#sVirt_project_to_Integrate_SELinux_and_Linux-based_Virtualization
==== Hot-add SCSI/VirtIO Disks for KVM Guests ====
Guido Günther supplied[1] a patch to add hot plugging and unplugging[2]
of SCSI/VirtIO disks for KVM guests.
[1]
https://www.redhat.com/archives/libvir-list/2008-October/msg00391.html
[2]
https://www.redhat.com/archives/libvir-list/2008-October/msg00427.html
==== Domain Events Support Completed ====
After three[1] rounds, Ben Guthro's domain events patches have been
committed. This major API addition led[2] Daniel Veillard to speculate
that the next release version number may jump to 0.5.0. Domain events
are only emitted from KVM guests. The other hypervisor drivers will
require more work to properly emit domain events.
The python bindings[3] are forthcoming.
[1]
https://www.redhat.com/archives/libvir-list/2008-October/msg00537.html
[2]
https://www.redhat.com/archives/libvir-list/2008-October/msg00594.html
[3]
https://www.redhat.com/archives/libvir-list/2008-October/msg00598.html
=== oVirt Devel List ===
This section contains the discussion happening on the ovirt-devel list.
==== New Model for Network Interface Configuration ====
Daniel P. Berrange offered[1] that "network configuration UI discussions
have all focused around the idea of configuring NICs on machines" and
this is the wrong model. Adding, "if we can model a network as a global
entity in its own right, we can simplify configuration of host
interfaces" to "simply a matter of association, and optionally defining
an address."
"So this kind of modelling can make our UI for setting up host
networking much clearer / simpler, avoiding lots of redundant questions.
Also, by having an explicit 'network <-> interface <-> host'
assoication, we can trivally determine whether it is possible to migrate
between two hosts from a network topology POV - its merely checking one
DB relation."
This idea was met with acceptance.
[1]
https://www.redhat.com/archives/ovirt-devel/2008-October/msg00325.html
Daniel illustrated[2] the concept with the following entity relationship
diagram:
1 n n 1
Network <-----> Interface <----> Node
^ 1 ^ 1
| |
V n V n
NetAddress Address
Mohammed Morsi created[3] a UML diagram[4] of the model as well.
[2]
https://www.redhat.com/archives/ovirt-devel/2008-October/msg00330.html
[3]
https://www.redhat.com/archives/ovirt-devel/2008-October/msg00348.html
[4] http://www.ovirt.org/page/Redesigned_Network_Configuration
Interface configuration was recently discussed in this[5] thread as
well.
[5]
https://www.redhat.com/archives/ovirt-devel/2008-October/msg00234.html
== OLPC Fedora SIG ==
In this section, we cover Fedora developments for the One Laptop Per
Child (OLPC) XO laptop, and also Sugar development for Fedora
releases[1]. We also pull relevant stories from the OLPC-Community
list[2].
[1] https://www.redhat.com/archives/fedora-olpc-list
[2] http://lists.laptop.org/pipermail/community-news
Contributing writer: Pascal Calarco
=== Merging OLPC with Rawhide ===
Peter Robinson announced[1] that he is beginning to merge OLPC package
branches into the mainline Fedora 10 rawhide and Fedora 9 joyride
streams[1]. Jeremy Katz suggested[2] that probably just being concerned
with Fedora 10 is all that is needed, "[g]iven that the idea seems to be
to rebase to F10 for the next OLPC release..." "In most cases, they're
"something needs to be ported" --eg, some of the Sugar bits for the new
NetworkManager dbus api or similar," he added[3]
[1]
https://www.redhat.com/archives/fedora-olpc-list/2008-October/msg00068.html
[2]
https://www.redhat.com/archives/fedora-olpc-list/2008-October/msg00069.html
[3]
https://www.redhat.com/archives/fedora-olpc-list/2008-October/msg00071.html
=== Pre-orders for Fedora 10 XO cards Open October 28th ===
Karlie Robinson announced[1] that pre-orders for the Fedora 10 OLPC SD
cards will start October 28 at On-Disk.com, and she'll update the list
when pricing has been finalized. The cards will also eventually be
available at Amazon.com. She added that users may be interested in this,
"1) for adults who may not find the Sugar environment practical for
daily use, the Fedora 10 option allows the machine to behave in a more
familiar way. 2) In this sense, the XO is on-par with an Asus Eee PC,
except your purchase during the G1G1 promotion directly effects the
lives of children. A social purchase rather than a corporate profit
purchase."
[1]
https://www.redhat.com/archives/fedora-olpc-list/2008-October/msg00073.html
=== Fedora XO Network Test Meeting ===
The IRC logs[1] from the meeting on 10/24/2008 were posted by James
Laska. The team has outlined their test plans[2], and discussed which
applications to test next, including command line tools, NetworkManager,
USB wired and wireless devices, and checking status of mesh networking
in Fedora 10.
[1]
https://www.redhat.com/archives/fedora-olpc-list/2008-October/msg00077.html
[2] https://fedoraproject.org/wiki/QA/TestPlans/Networking
=== XO - XFCE Fedora 10 Test Team ===
James Laska invited[1] interested folk to join a new team to begin
testing XFCE for the Fedora 10 build on the XO. "There's been a lot of
buzz around using a more lightweight desktop environment on the XO," he
wrote. "While GNOME will continue to be the desktop offered with this
years G1G1, I certainly don't want to discourage folks from testing
alternatives. I do want to emphasize though that GNOME is the primary
focus for Fedora on the XO. The work that Josh Bresser's and the
Performance Test team is doing is very important in identifying
memory/cpu/"disk" hogs on the XO."
Interested parties can sign up[2], and more details on the team roles
are also available[3]
[1]
https://www.redhat.com/archives/fedora-olpc-list/2008-October/msg00080.html
[2] https://fedoraproject.org/wiki/XO_Test_Roll_Call
[3]
https://fedoraproject.org/wiki/QA/TestPlans/Fedora10_On_XO#Responsibilities
=== Sugar Review Activity ===
Sebastian Dziallas announced[4] that the Sugar Jukebox was ready for
review.
[4]
https://www.redhat.com/archives/fedora-olpc-list/2008-October/msg00081.html
=== OLPC-Community Updates ===
This section covers Fedora/Sugar activity summarized on the
OLPC-Community list[1], sent out weekly by [Jim Gettys]. The 10/20/2008
edition is available[2], and relevant items are summarized or reproduced
below.
[1] http://lists.laptop.org/pipermail/community-news
[2]
http://lists.laptop.org/pipermail/community-news/2008-October/000151.html
The QA team continued performance and capacity testing with a session of
20 laptops connected to a school server, with everyone using chat. A few
new tickets were opened as a result of the testing, and "We continue
testing with the school server while limiting to 50 - 55 the number of
laptops connected to a single access point. We also plan to test other
performance-enhancing configurations (including more than one access
point connected to the same school server). We also plan to conduct
performance testing in the "access point, no school server" setting."
The software development group was busy preparing future feature plans
for the upcoming XOCamp[3], to be held the week of 11/17/2008 which
welcomes presentations.
[3] http://wiki.laptop.org/go/XOcamp
[C. Scott Ananian] continued work on the next version of the Journal
(known as Journal2), with new media and screencasts available[4]. [Eben
Eliason] also spent time meeting and planning for Journal2, and will
"...begin working on revised screenshots and use case scenarios next
week so design and implementation can be brought together early in the
next release cycle."
[4] http://wiki.laptop.org/go/Journal_reloaded
[Erik Garrison] spent the week testing various hierarchical file
managers which could potentially be used in Sugar and working on UI
performance issues. To close the week he published a set of potential
modifications to the OLPC software distribution which dramatically
improve user interface performance.
Chris Ball worked on power management and an interesting new screencast
activity on the XO, "allow[ing] a movie to be created using the content
of the display along with narration over the microphone; it could be
useful for creating shareable tutorials and walk throughs both for
learning how to use the XO and for learning in general."
The 0th issue of The OLPC Journal[5] was put together by [Michael Stone]
and [SJ Klien], covering activity on the OLPC devel list, announcements
of the G1G1 laptop 2008 program, the upcoming XOCamp2, XO tips and
tricks, and the Journal2 work.
[5] http://wiki.laptop.org/go/OLPC:Journal
An initial implementation of Moodle for the school server was completed
by Martin Langhoff.
[Morgan Collett] debugged connections to jabber.laptop.org, and tried to
make presence service more reliable in the face of network delays seen
in this setup. He worked on API documentation for activity authors, and
discussed 9.1.0 goals for collaboration.
Marco Pesenti Gritti wrote a proposal about API stability policy for
Glucose and discussed it in the Sugar irc meeting, and wrote a list of
work items to make Sugar window management more standard compliant and
better host normal desktop applications.
[Tomeu Vizoso] worked on several tasks including adding downloading
links and images to the Journal, adding a removable storage icon to
Sugar's frame, in preparation of further improvements to handling USB
sticks, improved shell loads by 70%, and other work.
Simon Schampijer has been landing the use of gconf for the profile in
sugar-jhbuild. The profile is now using gconf to store the preferences.
The old API in sugar/profile has been kept around to not break
activities using it, for example to request the nickname or the color of
the user. You can keep on running multiple instances of the emulator by
using the 'SUGAR_PROFILE=username sugar-emulator' command. This keeps on
working since we use gconf-dbus in sugar-jhbuild and therefore run one
gconf daemon per instance.
[Sayamindu Dasgupta] worked on revising the Khmer keyboard layout so
that it adheres to the national NiDA standard as closely as possible. He
also worked on adding fallback language support for translations (eg: an
Aymara user would like to see Spanish translations as fallback if Aymara
ones are not available instead of the default English). In the Sugar
department, Sayamindu continued his work on Read and added support for
handling external hyperlinks in the underlying evince python bindings.
Guillaume Desmottes implemented the last bits of the new search protocol
in Gadget. He released Gadget 0.0.2 which should contain all the
requested features. On the Gabble front he finished to implement the new
protocol as well and merge the new Gadget API branch. In order to
drastically simplify Gadget integration in Sugar, he investigated a new
path where buddies in views where advertised as online by Gabble. He
implemented it as a proof of concept and was able to very easily request
views and making their activities and buddies appear in the mesh view
without (almost) any PS change! He also released telepathy-python 0.15.2
which contains new API which are needed to perform Gadget searches.
Javier Cardona worked on driver support for the "wakeup on lan" (WOL)
functionality that currently is implemented in the wireless firmware. We
can now wake up the XO based on the presence of a number of predefined
4-byte patterns in the received wireless frames, making possible
scenarios such as waking up on ARP requests for its IP address.
Ricardo Carrano spent the week in tests with the XO acting as an access
point, working with students at UFF to build a wireless sparse mesh test
bed[6] and working with Cozybit on the remaining WPA timing issues.
[6] http://wiki.laptop.org/go/Wireless_Sparse_Testbed
--
Oisin Feeley
http://fedoraproject.org/wiki/OisinFeeley
--
fedora-announce-list mailing list
fedora-announce-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-announce-list
