Garfield's Opensource News: Fedora Weekly News #150

-Fedora Weekly News Issue 150-

Welcome to Fedora Weekly News Issue 150 for the week ending November
2nd, 2008.

http://fedoraproject.org/wiki/FWN/Issue150

In this week's issue, featured content includes announcements on a new
Fedora Sugar Spin, and development freeze for Fedora 10. The Translation
beat this week features an interview with Fedora Translation project
member Diego Zacarao (Rasther). In Developments, details on resume from
suspend problems with Intel i945s, details on "[a] gigantic multi-thread
flamewar consum[ing] many list participants" over moving X from VT7 to
VT1 and POSIX file capabilities for Fedora 11. The Artwork beat features
discussion of new wallpaper extras, and final fixes for the Fedora 10
Solar backgrounds. The Security Advisory beat rounds out this issue and
updates us with fixes released in the last week for Fedora 8 and 9.

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

---Blocker Bug Review Meeting---

John Poelstra announced[1] that a "meeting is being held to review the
current blocker bugs[2] in anticipation of the Final Development Freeze
this Tuesday, October 28th."

[1]
http://www.redhat.com/archives/fedora-devel-announce/2008-October/msg00016.html

[2]
https://bugzilla.redhat.com/showdependencytree.cgi?id=438943&hide_resolved=1

---Translation packagers: Rebuild before devel freeze---

Dimitris Glezos wrote[3] to remind "maintainers of Fedora-translatable
packages to issue a build before the Development Freeze of tomorrow,
28/10, in order to have all translations submitted until the translation
deadline of 21/10 included in Fedora 10 (otherwise our translator's hard
work will go to the gutter)."

[3]
http://www.redhat.com/archives/fedora-devel-announce/2008-October/msg00017.html

---Fedora Sugar Spin---

Sebastian Dziallas announced[4] the "availability of our Fedora Sugar
Spin, which incorporates the Sugar Desktop Environment on a Fedora Live
CD." To get the spin, and to contribute to its further development, read
the full announcement below.

[4]
http://www.redhat.com/archives/fedora-announce-list/2008-October/msg00012.html

---Frozen for Fedora 10---

Jesse Keating reminded[5] everyone that we are now frozen for Fedora 10.
"At this point, builds for F10 are not automatically brought into
Rawhide, and won't be in the Fedora 10 release. To request a freeze
override, please use the Final Freeze Policy[6]."

[5]
http://www.redhat.com/archives/fedora-devel-announce/2008-October/msg00018.html

[6] https://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy

--Translation--

This section covers the news surrounding the Fedora Translation (L10n)
Project.

http://fedoraproject.org/wiki/L10N

Contributing Writer: Runa Bhattacharjee

---FTP Meeting to be held on 4th November 2008---

FLSCo member Noriko Mizumoto announced the next meeting of the Fedora
Translation Project to be held on the 4th of November 2008[1]. The time
for the meeting is yet to be determined, with 1900 UTC and 2000 UTC
being the two probable candidates. The meeting and agenda is open for
all[2].

[1]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00215.html

[2] http://fedoraproject.org/wiki/L10N/Meetings

---Package Rebuild requested by FTP---

Dimitris Glezos has requested the maintainers of the Fedora packages
that were translated for Fedora 10 to rebuild them[3]. This would ensure
that the translations submitted by the Fedora Translation Project
members are included for all these packages.

[3]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00209.html
TQSG repository set to be moved

Fabian Affolter has initiated discussions to move the the Translation
Quick Start Guide (TQSG) to fedorahosted[4]. The move has been endorsed
by Paul Frields on behalf of the Fedora Documentation team, subject to
confirmation by FLSCo about the move and the ownership of the
document[5]. The final decision, particularly about the VCS to be used,
is pending at the moment.

[4]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00203.html

[5]
https://www.redhat.com/archives/fedora-trans-list/2008-October/msg00222.html
Dimitris Glezos nominated for the Fedora Board

FLSCo Leader Dimitris Glezos has been nominated[6] by Max Spevack as one
of the candidates for the upcoming Fedora Board elections to be held in
December 2008. These elections would be held to elect two new members
for the Fedora Board.

[6]
http://fedoraproject.org/wiki/Board/Elections/Nominations#Dimitris_Glezos_.28glezos.29

---Diego Zacarao interviewed---

Fedora Translation project member Diego Zacarao (Rasther) was recently
interviewed about his contributions to Transifex and Fedora Translation
Project [7].(The Original version in Brazilian Portuguese[8].)

[7] http://tinyurl.com/6kndvw

[8]
http://vladimirmelo.wordpress.com/2008/10/31/entrevista-com-diego-zacarao-sobre-o-transifex

--Developments--

In this section the people, personalities and debates on the
@fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley

---Resume from Suspend Problems with Intel i945---

Peter Robinson solicited[1] experiences with problems on netbooks in
resuming from suspend from those using the latest Intel-2.5.0drivers.
His problem suddenly manifested itself on a previously working EeePC
901: "It had worked previously and resumes OK but I get a black screen
with a cursor and around that a square of garbled bits." Peter wondered
what had changed recently in order to make suspend-resume stop working.

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02975.html

Apparently similar failures were reported[2] by Jonathon Roberts for a
Dell Mini[3] ,Tim Lauridsen on a ThinkPad T60[4] and Christoph Hoger[5]
on a ThinkPad R61. Tim's problem seemed to be related to compiz.

[2]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02977.html

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02977.html

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03005.html

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03033.html

Jeremy Katz suggested[6] using the suspend quirks[7] , especially
vbepost. Matthew Garret believed[8] this to be unnecessary as "i945 is
perfectly capable of handling resume on its own in-kernel. The problem
is more likely to be an excess of quirks interfering with that (or,
alternatively, someone's broken the kernel)."

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02981.html

[7] http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02992.html

Jesse Barnes (of the Intel Open Source Technology Center[9]) asked
whether suspend worked from the console using:

echo mem > /sys/power/state

as this would indicate that there had been a regression in 2.5.0 as
opposed to a kernel bug. Matthew Garrett thought that Jesse's suggestion
would not test the same suspend pathway and that it would be better to do a:

dbus-send --system --print-reply --dest=org.freedesktop.Hal \
/org/freedesktop/Hal/devices/computer \
org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0

Matthew begged[10] "Please (please, please) don't attempt to add resume
quirks for anything with Intel video hardware now. It's only hiding
kernel bugs."

[9] http://software.intel.com/sites/oss/

[10]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00082.html

---Moving X from VT7 to VT1---

A gigantic multi-thread flamewar consumed many list participants after
Will Woods made sure[1] that everyone knew that in Rawhide "X HAS MOVED
FROM VT7 TO VT1. GDM specifically starts X on tty1, and upstart does not
start a getty on tty1 in runlevel 5." The reason behind this change was
that the boot process no longer uses the old RHGB but instead a
flicker-free and faster replacement named Plymouth (see Fedora
Magazine[2] for a full explanation).

Fuel for the fire was provided by the surprise experienced by many
posters who solely followed @fedora-devel for their information. A
perception that changes made for the purposes of improving the desktop
experience were occurring at the expense of the traditional server
experience also seemed to irritate many. This was despite the fact that,
as Dan Nicholson explained[3]: "Users who do not want a graphical boot
set rc 3 as their default runlevel, and everything is the same as it
always was with getty on tty1-6. If you then run startx, it will start
on tty7. In rc 5, X is started on tty1 and getty is not. That's all
there is to it."

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02422.html

[2]
http://fedoramagazine.wordpress.com/2008/10/21/interview-fedora-10s-better-startup/

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02469.html

In answer to a question from Till Maas it was confirmed[4] by Felix
Miata that if one "[...] rebooted into runlevel 3, logged in on tty1,
did telinit 5, got kdm on vt7, switched to tty1, [then there was] a
normal shell prompt following typical X startup messages, and kdm still
on vt7 [.]"

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02478.html

Dan Nicholson also corrected[5] assumptions that the changes were made
to improve boot speed with the information that it was to prevent the
ugly flicker of VT switching during boot and asked "Why is it
significant what tty any program runs on? Isn't the assumption that
getty will be on tty1 just as faulty as the assumption X will be on
tty7?" Shmuel Siegel gave[6] an answer which was repeated many times in
the threads: "Because you are changing a user interface. What is going
to happen when the user switches to tty1 and nothing happens? The basic
logic of putting X on tty7 is to get it out of the way. Humans will use
the lowest numbered ttys first. Besides breaking existing documentation,
including advice on various forums, is not a good idea." Bill Nottingham
added[7] to Dan's rationale: "1) Reducing the amount of flicker and
useless mode switching on startup is definitely a good thing 2) From a
logical standpoint, the first tty should be for the most important user
interaction. If you're booting in text mode, that's a getty. If you're
booting with a GUI login... that's the GUI." Callum Lerwick and Brian
Wheeler exchanged[8] details of the "vast improvement[s]" including
removal of up to twelve seconds which resulted from the lack of monitor
resync delays.

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02458.html

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02464.html

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02543.html

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02518.html

Gerd Hoffman made[9] an interesting suggestion about how Plymouth could
do a VT switch immediately after KMS[10] had entered graphics mode but
before printing anything to screen. In the course of this he clarified
that "The flicker / resync delay comes from the *mode switch*, not the
*vt switch*. And, no, a vt switch does *not* imply a mode switch. The
reason you'll have flicker today when switching from/to X11 is that X11
does a mode switch when you switch from/to the terminal X11 is running
on." BillNottingham was skeptical but Gerd insisted [11] that his
approach would work.

[9]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02623.html

[10] Kernel Mode Setting: http://kerneltrap.org/node/8242

[11]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02820.html

After Till Maas suggested "[...] the kernel should be patched to start
booting graphically using tty7 and not tty1." Bill Nottingham passed[12]
on the idea as it would involve: "Having the kernel parse its own
commandline for a runlevel (a concept that has nothing to do with the
kernel, and doesn't even exist under some init systems) and then
choosing to rearrange the tty init sequence based on that?" and in
further discussion with Matthew Woehlke reiterated[13] "You're having
the kernel operate on Fedora specific commandline options to start on a
completely different tty, one that could be configured by anyone locally
to do something else entirely. (Unless you do it in userspace, which
means you jump away and then jump back for text mode, which...)" Casey
Dahlin modified[14] the idea to "[...] either offer a getty on tty7 (not
too hard) or we could instead add a small API to the kernel that would
allow remapping which F key went to which tty, so you could have
ctrl+alt+f1 bring up tty7. That way we could remap things so the user
got the correct behavior. We wouldn't have to actually /do/ this, but if
the API were there, we can tell the people who care to go figure it out."

[12]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02544.html

[13]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02594.html

[14]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02553.html

Will Woods explained[15] how to revert the change, but this was
contested[16] by Dan Nicholson on the basis that the latest gdm does not
support FirstVT. Dan provided an untested patch and explained that
"[s]ince plymouth writes the /var/spool/gdm file on boot and then gdm
removes it, any subsequent starts will put X on the first available VT,
which is tty7 in the common configuration. With my patch, prefdm writes
the file every time it's executed. I don't know if that's the correct
behavior for all cases where prefdm would be run. I'm looking at
upstream gdm right now, and FirstVT isn't respected. Looking at the
rawhide patches, I don't see anything that would enable that
functionality again."

[15]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02506.html

[16]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02516.html

Later Dax Kelson reopened[17] the thread with a list of objections which
pointed out the negative impact upon documentation and user habit of the
change. He garnered a good deal of support from many other respected
contributors.

[17]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02601.html

At the end of the thread Bill Nottingham asked[18] the interesting
question of why the change appeared to come as such a surprise given
that it had been telegraphed in advance by a formal feature proposal[19]
and had been implemented in rawhide: "Are people not running rawhide and
the test releases? Are they not looking at features as they are proposed
and being involved in the process? Are they just sitting around waiting
to be outraged?" Dax rejoined[20] that it was not obvious from the
documentation that there would be a side-effect which disturbed an
expected convention.

[18]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02830.html

[19] http://fedoraproject.org/wiki/Features/BetterStartup

[20]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02853.html

---Fedora 11: POSIX File Capabilities---

Panu Matilainen announced[1] that he had added file capability support
to rpm. With kernel support for storing capabilities on filesystem since
2.6.24 and the most recent libcap he asked if now was the time to "[...]
start considering moving away from SUID bits to capabilities, in Fedora
11 maybe?"

SethVidal wondered how this would affect networked file systems and
David Quigley answered[2] that "[...] capabilities are stored in xattrs
they will run into the same problems that SELinux does. Labeled NFS is
working to address this by providing a per file attribute through NFSv4
for extra security information."

Another show-stopper was the erasure of file-based capabilities by
prelink. It appeared[3] that there was a certain amount of desire to
examine whether prelink might cause more trouble than it was worth on
faster hardware. Prelink's problems also included incorrectly stripping
OCaml binaries and preventing rpm -V from working correctly.

Colin Walters noted[4] that the desktop team had "been moving the OS
away from exec-based domain transitions to message passing (e.g.
PolicyKit) for a variety of reasons. I think it might be worth
considering introducing a rule actually in Fedora for "no new SUID/fcap
binaries"[.]" Steve Grubb was worried[5] that this direction resulted in
the introduction of another MAC system and that auditing from userspace
was untrustworthy. Concern was also raised[6] by Michael Stone on the
affects on solid-state memory consumption.

Steve Grubb sought details on how rpm would work with kernels lacking
file capabilities and wanted[7] to "start removing some of the setuid
bits." He suggested[8] to Chris Adams that tar and star should be
capable of storing these new extended attributes and that aide would be
useful in tracking changes to them.

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02637.html

[2]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02849.html

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02923.html

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02729.html

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02809.html

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02818.html

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02777.html

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02823.html

---Purging Unnecessary .la Files---

An apparent contravention of the packaging guidelines was noticed[1] by
Debarshi Ray in the dia package. It contained %{_libdir}/%{name}/*.la
files[2]. Colin Walters was[3][4] enthusiastic about the idea of "not
encourag[ing] the libtool agenda to redefine how shared libraries work
on our platform." Jerry James found[5] that he had quite a number of
them on his x86_64 machine.

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03031.html

[2] .la are libtool archive files:
http://www.gnu.org/software/libtool/manual/html.node/index.html#Top

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03032.html

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03039.html

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03038.html

Dan Nicholson argued[6] that it would be best to convince libtool
upstream to support some way to choose whether or not the library
archives were installed at build time, but Colin was unrelenting and
argued[7]: "Or alternatively convince the automake people that it
shouldn't be in the business of software lifecycle management (make
uninstall) any more than people should be coding/overriding build
systems (make;make install) inside RPM spec files. This seems possible;
probably worth trying to at least have an environment variable
AUTOMAKE.OPTIONS = i-dont-need-uninstall."

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03048.html

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03051.html

David Woodhouse also wanted[8] to see the back of libtool "[...]you can
just throw it away and forget it ever existed? I just write proper
Makefiles, and if I ever _want_ to spend a couple of minutes watch some
bizarre script trying to work out what type of FORTRAN compiler I have
on my system, I can write myself a little bash script for that too[...]"
but Richard W. M. Jones disagreed[9] sharply as he found it useful for
building shared libraries on a wide variety of platforms. In response to
Colin Walters' suggestion to build a hook in RPM to nuke .la files he
stated[10] that they were essential for the MinGW packages.

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00019.html

[9]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00024.html

[10]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00023.html

Toshio Kuratomi and Michael Schwendt discussed[11] how newer versions of
libltld can work without missing libtool archives and that it was
desirable to remove them because a "[...] private copy of a system
library would be a violation of the Packaging Guidelines for security
reasons [.]"

[11]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00064.html

Richard W. M. Jones decided[12] to do some testing to determine whether
MinGW needed "[...] the *.la files for MinGW packages" or "[...] the .la
files in MinGW packages[.]"

[12]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00085.html

--Artwork--

In this section, we cover the Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: Nicu Buculei

---Wallpaper Extras---

Ian Weller asked[1] on #fedora-art about a better way to handle and
package the collection of extra wallpapers gathered from various Fedora
contributors: "The current gallery system for the Wallpaper Extras isn't
working. It doesn't do us good for keeping track of attributions,
especially if we start taking lots of outside contributions from Flickr
or the like (which I plan on doing soon)[.]" Ian also proposed that:
"[t]he entire wallpaper extras framework for submission and tracking
will be on the wiki, through MediaWiki's category system. The main
category will be Category:Wallpaper extras[2], which will contain only
other categories and unsorted wallpapers. Subcategories to that will be
along the lines of Category:Abstract wallpaper extras, which can also
contain other subcategories if we want to categorize further. Categories
have a built-in gallery setup. The image page itself will contain a
template (which we'll need to write) that will contain information such
as the creator, the URL it was taken from (if applicable), and who added
it to the wiki, and what license was originally under."

[1]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00299.html

[2] https://fedoraproject.org/wiki/Artwork/Wallpaper_Extras

Jóhann B. Guðmundsson opted[3] for a contest, possibly held in
cooperation with Fedora Magazine[4] "I personally think we should hold a
wallpaper contest photo artwork etc with a specific subject/theme in
conduction with fedoramagazine each month or so then top 3 picture ( or
top in each category ) would be picked added to the wiki and package".
Nicu Buculei argued for RSS feeds instead of votes "My tendency is to
decouple packaging and contests. Have the images in a proper gallery and
the users can use RSS feeds and see 'best rated', 'most viewed', 'last
uploaded' images with no effort. And they really need the packaging?
They have the photos open in their browser and Firefox has an 'Set As
Desktop Background' command (it appears broken if Firefox/GNOME, but
that is just a bug which needs a patch). And from this large pile of
images, a packager may make a manual selection with the 'most usable'
images (or more packagers can to their own selections and packages)."

[3]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00300.html

[4] http://fedoramagazine.wordpress.com/

[5]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00324.html

Jonathan Roberts, the editor of 'Fedora Magazine', got into the
discussion and opined[6] against a reinvention of the wheel: "Why
reinvent the wheel - why not just take advantage of Gnome look? Or set
up a Flickr pool - I think one already exists possibly?" and for a
manual image selection for the magazine "With respect to the magazine,
I'd be more than happy if someone from the art team would be interested
in doing a monthly post that would share work that members of the art
team were involved with - whether it was Fedora related or just created
using tools exclusively in Fedora"

[6]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00327.html

---Fedora 4 F's buttons---

Following last week's "Four F's" posters made by Máirín Duffy (see our
coverage in FWN#149[0]) Clint Savage posted[1] on @fedora-art a set of
buttons made in the same style, which were received[2] with open arms
"SWEET! I really like the pattern in the background of the logo2 file.
Logo3 is really strong, well done!"

[0] http://fedoraproject.org/wiki/FWN/Issue149#Four_Fs_Poster_Designs

[1]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00304.html

[2]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00305.html

From there the discussion went[2] into printing preparation details.
Clint was asked "Do you know how to scribus-ify these into print-ready,
color-safe PDF artwork?" This was no problem for Clint: "I have done
that before many times. I'll look into doing that on sunday. I assume
you are referring to the fact that I need to make the images CMYK and
making them pdfs so printers won't complain. I'm capable of doing that
:)" Scribus's limitations were raised[4]: "However Scribus SVG support
is rather flaky and most of the time (except for really simple 'kosher'
SVG files) you will get an error stating that some features of the file
were not supported. Also it tends to get the size 'wrong', not the
actual size of the drawing, but rather it kind of adds an additional
'holding box' to the drawing. My personal recommendation when handling
graphics with Scribus would be to export to EPS and then import that
into Scribus, or export to bitmap[.]"

[3]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00308.html

[4]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00310.html

The need to use a recent version of the application was also
expressed[5]: "You're probably using mrdocs' svn build for Fedora then
right? (My head would have gone thru the monitor glass long ago if I was
stuck with 1.3.4) If not, you should give it a try, it makes life so
much easier!"

[5]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00314.html
Final Fixes for the Solar Backgrounds

Charlie Brej spotted[1] an imperfection in the default Fedora 10
wallpaper "In the 3200x1200 dual screen images there is a column at
X=1151 which has a slight transparency. It is in fact very difficult to
see it in gimp but it does become visible on desktop backgrounds with a
contrasting solid colour behind" and also proposed[2] a patch to
decrease the overall size of the backgrounds package "Current solar
background's consume 33Mb. This a bit on the heavy side, especially on
the Live CD which is over its image limit. Currently there are 4
different images (morning, noon, evening, night) sent out in 4 different
sizes (4:3, 16:10, 5:4 and 8:3 for dual screen). What we could do is to
send out just one 3200:1200 image and patch up gnome-desktop background
handling to support cropping to the right aspect."

[1]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00317.html

[2]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00319.html

Martin Sourada announced[3] a split of the backgrounds in 3 packages, to
distribute the file size optimally "I've just built an updated Solar
Backgrounds Package with many fixes provided by Mo, and more
resolutions/ratios [1]. As per request from both gnome and kde folks the
package has been split into solar-backgrounds (for Desktop Live Spin)
solar-backgrounds-common (for KDE) and solar-backgrounds-extras
(containing everything not included in the previous two)" and at the
last minute Kevin Kofler noticed[4] and fixed[5] a bug "the 1280x1024
image is only 1280x1014".

[3]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00364.html

[4]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00373.html

[5]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00379.html

---Fedora 10 Countdown---

Following an earlier request[1] from the website team's Ricky Zhou for a
count down graphic for the Fedora 10 release, Paolo Leoni submitted[2]
to fedora-art for review a couple of proposals and after a couple of
rounds of feedback forwarded the proposals to the @fedora-websites, with
an additional round of improvements[3] incorporating feedback[4] from
Máirín Duffy "I think 'CAMBRIDGE' is a little hard to read because of a
combination of the thin font and the low contrast with the background. I
also think the text doesn't have enough breathing space from the right
and bottom edges of the banner."

[1]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00233.html

[2]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00328.html

[3]
https://www.redhat.com/archives/fedora-websites-list/2008-October/msg00148.html

[4]
https://www.redhat.com/archives/fedora-websites-list/2008-October/msg00147.html

---An OLPC Illustration---

Karlie Robinson, from the OLPC team, used[1] the Design Services
queue[2] to request an OLPC illustration: "I need an image or series of
images illustrating how to insert a SD card into the OLPC XO. This will
be used for instructions on how to load F10 onto the XO" The request was
taken[3] by Mike Langlie "I can render the process of positioning the XO
and inserting an SD card in several steps as technical illustrations.
Dan Williams demonstrated for me and it looks like a drawing may also be
needed for removing the SD card."

[1]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00339.html

[2]
http://fedoraproject.org/wiki/Artwork/DocIllustrationService#Request_list

[3]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00355.html

Karlie followed[4] with a set of photos of the device for visual
reference and Mike created a wonderful diagram[5].

[4]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00357.html

[5]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00365.html

---A Bit of Flame War---

With the huge flame war about X and ttys going strong on the main
development list, @fedora-art couldn't remain behind, and pursued its
own dispute, started with the topic quality of the quality of its works
(we reported about it in our previous issue) and continued with the
relation between the Red Hat Desktop Team and the Fedora Art Team.

Max Spevack stepped in[1], outlined the Fedora objectives, one of the
points in debate: "1) The premiere community development platform in the
OSS world. 2) An open R&D lab for new technologies that Red Hat is
interested in from a RHEL server point of view (witness virtualization's
path through Fedora over the years) 3) An open R&D lab for new ideas and
technologies that Red Hat's desktop team is interested in", raised a set
the question to clarify the team's relations and concluded "I submit to
you all that this isn't a problem that the Fedora Marketing team can
solve. This Artwork v Desktop squabble is a problem about the
fundamental way in which Fedora prioritizes the needs of its different
constituencies. Red Hat has asked that Fedora be many things, as I said
earlier. One of the things Red Hat asks is that Fedora be the best
community development platform in the OSS world, and we strive for that
every day. However, Red Hat has also asked that Fedora be the incubator
for the Red Hat Desktop Team. If those two requests are so incompatible
with each other that only one of those goals can be achieved, that is a
RED HAT problem and not a FEDORA problem, and we should take that
conversation to our managers internally."

[1]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00352.html

The position was reinforced[2] by Paul Frields "For what it's worth,
I've talked about this with the Desktop team's leader in Red Hat,
Jonathan Blandford, on a couple occasions since I came on board. There
are indeed multiple masters to serve, and it's vital that Fedora also
preserve the ability for the people who work on technologies like
virtualization or SELinux to use Fedora for R&D" who proposed the use of
the next FUDCON to discuss and clarify the situation "As am I -- there's
a good opportunity to do this at FUDCon in January, but certainly I
don't want to just let things stew until then. That happens to be a
perfect time to communicate this vision to a sizable portion of the
community that will be gathered for that event."

[2]
https://www.redhat.com/archives/fedora-art-list/2008-October/msg00356.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---

* libgadu-1.8.2-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00893.html
* ed-1.1-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00873.html
* openoffice.org-2.4.2-18.1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00905.html
* phpMyAdmin-3.0.1.1-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00908.html
* dovecot-1.0.15-14.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00816.html
* libtirpc-0.1.7-20.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00819.html
* drupal-6.6-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00826.html