Fedora Weekly News #150

Mon Nov 3 20:34:10 UTC 2008

-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 

---Fedora 8 Security Advisories---

    * dovecot-1.0.15-14.fc8 - 
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00844.html
    * ed-1.1-1.fc8 - 
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00847.html
    * libgadu-1.8.2-1.fc8 - 
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00865.html
    * openoffice.org-2.3.0-6.17.fc8 - 
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00923.html
    * phpMyAdmin-3.0.1.1-1.fc8 - 
https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00925.html 

-- End FWN 150 --