From Fedora Project Wiki

< FWN

Fedora Weekly News Issue 120

Welcome to Fedora Weekly News Issue 120 for the week of February 11th, 2008. FWN/Issue120

In Announcements, we have "Announcing Fedora 8 Xfce Spin"

In Planet Fedora, we have "KDE 4 Interview", "Announcing Fedora Ambassadors Wall", "Insert favorite Elvis joke here", "Publican - the 'new' Documentation Publisher", and "SCALE 6X Trip Report"

To join or give us your feedback, please visit NewsProject/Join.


Announcements

In this section, we cover announcements from Fedora Project.

https://www.redhat.com/mailman/listinfo/fedora-announce-list

Contributing Writer: ThomasChung

Announcing Fedora 8 Xfce Spin

RahulSundaram announces[1] in fedora-announce-list,

"I am pleased to announce the immediate release of a brand new and sparkling, Fedora 8 Xfce Spin. Fedora Xfce Spin is a bootable Fedora Live CD image available for x86 and x86_64 architecture. It can be optionally installed to hard disk or converted into boot USB images and is ideal for Xfce fans and for users running Fedora on relatively low resource systems."

[1] https://www.redhat.com/archives/fedora-announce-list/2008-February/msg00005.html

Planet Fedora

In this section, we cover a highlight of Planet Fedora - an aggregation of blogs from world wide Fedora contributors.

Planet

Contributing Writers: ThomasChung

KDE 4 Interview

JonRoberts points out in his blog[1] ,

"I’ve just published an interview with Rex, Kevin and Sebastien about KDE 4 and Fedora 9 :) You know the plan here, go, take a look at the interview and if you enjoy it give it a digg - if you do you’ll be forever in my good graces!"

[1] http://blog.questionsplease.org/2008/02/17/kde-4-interview/

Announcing Fedora Ambassadors Wall

FrancescoUgolini pionts out in his blog[1] ,

"Now it's time to create a place where each person can describe with few words what he/she thinks about Ambassadors Project and Fedora Project in general, starting from his/her vision of Ambassadors to his/her opinion about Fedora."

[1] http://ugolini.livejournal.com/1114.html

Insert favorite Elvis joke here

KarstenWade points out in his blog[1] ,

"What is happening is simply that we’re doing a final push to get all modules migrated from elvis to a VCS hosted by the Fedora Project, coming to conclusion this Monday 18 February. Once all modules are within Fedora, we can more easily connect them to Transifex."

[1] http://iquaid.org/2008/02/16/insert-favorite-elvis-joke-here/

Publican - the "new" Documentation Publisher

JohnBabich points out in his blog[1] ,

"Publican -- which has been used by Red Hat's Documentation Group for almost two years -- takes DocBook XML input and outputs HTML, plain Unicode text and PDF. This output can be branded with the following brands: Fedora, Red Hat, and JBoss. A default, generic brand is also included. Further brands can be added, either by request, or by direct customisation."

[1] http://jmbuser.livejournal.com/9322.html

SCALE 6X Trip Report

TomCallaway points out in his blog[1] ,

"SCALE 6X was one of the most fun, most interesting community shows that I have attended in quite some time. Friday was a day of specialized tracks, one for Open Source in Education, one for Open Source in Healthcare, and one for Women in Open Source."

"On Saturday, the expo floor opened, and I got to meet ThomasChung, who helped me man the Fedora booth. Thomas was great, he provided posters, stickers, DVDs and T-Shirts, plus he was willing to talk to all visitors, and encourage them to try Fedora 8."

Editor's Note - SCALE 6X Photo Report[2] is also available.

[1] http://spot.livejournal.com/288447.html

[2] http://tchung.fedorapeople.org/scale6x/

Ambassadors

In this section, we cover Fedora Ambassadors Project.

Ambassadors

Contributing Writer: JeffreyTadlock

Ambassador Wall

FrancescoUgolini announced[1] the creation of an Ambassador Wall [2] in the wiki. The Ambassador Wall offers a place for people to describe in a few words what he or she thinks about the Ambassadors and Fedora Project in general. Future marketing materials may be made based on some of the comments left on the Ambassador Wall. There are already some comments there, so stop by and take a look and tak a few minutes to add your own.

[1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-February/msg00116.html

[2] Ambassadors/Wall

Ambassador Statistics

There has been recent interest in gathering more statistics in regards to various Ambassador activities as a means to measure the impact of Fedora Ambassadors around the world. Initial statistics of the growth of the Fedora Ambassadors group has been started by FabianAffolter with a blog post [1] and the creation of a statistics page [2] in the wiki. JeffreyTadlock has also posted a one sheet overview [3] covering the past six months. FrancescoCrippa has recently started work on generating more of these statistics via automated scripts [4] .

[1] http://fabaff.blogspot.com/2008/02/increase-of-fedora-ambassador-program.html

[2] Ambassadors/Statistics

[3] http://jeffreyt.fedorapeople.org/ambassador-metrics/ambassador_verification_metrics.pdf

[4] http://people.byte-code.com/fcrippa/2008/02/16/fedora-ambassadors-statistics/

Max's Event Report Announcement

MaxSpevack posted[1] a request to the Ambassador's List that any ambassador who has received funds from Fedora for attending or organizing an event is required to produce an event report. Max, GregDeKoenigsberg and JackAboutboul have been working hard to secure a higher budget for community events and ambassadors. As Max stated in the post "... with increased funding comes increased pressure to prove that the money was well spent."

An event report should consist of the following things:

"- one blog post per day with a description of what you did, the atmosphere of the event in general, and pictures if they are available.

- a summary post to fedora-ambassadors-list at the end that provides links to all the blog posts.

- the "leader" of that particular event should encourage all the other Fedora folks who were there to post about it as well, and aggregate their posts into the summary email to Fedora Ambassadors list.

- were any new contributors signed up during the event?

- the blog should be part of the Fedora Planet.

- this should be completed within 1 week from the end of the trip."

[1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-February/msg00074.html

EMEA Meeting Summary

The EMEA Ambassadors held their monthly meeting on February 13th. If you were unable to attend the meeting, FabianAffolter has posted a detailed meeting summary to the Ambassador's mailing list.

[1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-February/msg00118.html

Developments

In this section, we cover the problems/solutions, people/personalities, and ups/downs of the endless discussions on Fedora Developments.

http://www.redhat.com/mailman/listinfo/fedora-devel-list

Contributing Writer: OisinFeeley


Source File Audit

The results of another run of KevinFenzi's sourcecheck script were posted[1] . The tool checks to make sure that source referenced in rpms is downloadable and has matching MD5SUMs and timestamps. Kevin noted that there were a varying number of approximately 700 packages failing one of those three conditions and wondered if he should keep posting the results to the list and/or spam the maintainers.

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

Reaction was uniformly positive with several of the listed maintainers providing brief explanations of problems usually originating in the upstream of the package making changes to location. A suggestion by JonathanUnderwood that automatic opening of a bugzilla would be useful was not welcomed by ColinWalters. Colin explained[2] that issues out of the control of the maintainer (such as transient network outages) would invalidate such bug reports. He suggested instead that integrating such scripts into the Fedora infrastructure and exporting their reports via RSS would be more useful.

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

Kevin was largely in agreement[3] and ToshioKuratomi was excited[4] by the prospect of adding these features into the pre-planning of the notification server which had been discussed several months ago.

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

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

Most respondents were clear that the reports were useful and should be sent to the list. Several problems appeared to be due to the need to log in to get the source.

Multiuser Noise And Fury

As reported in FWN#118 "PulseAudio Crashing Applications"[1] concerns have been expressed about the sparkling new sound management system: PulseAudio. The creator, LennartPoettering, revisited[2] the issue to clear up some misconceptions and in the process stimulated a wider discussion over the setting and enforcement of policy on a multiuser system. Lennart's initial point was that it was expected that sound playback would be temporarily interrupted when there was a new login to a virtual terminal. This is because[3] ConsoleKit and HAL will change the ACL of the audio device in order to follow the active session. Lennart thought that the sound should resume once the initial session was resumed.

[1] FWN/Issue118#head-009f873a04d5ff649747268eb972d8d9325df359

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

[3] Discussion of the device ownership problem in the FastUserSwitching scenario: Desktop/FastUserSwitching

However, AndrewFarris reported[4] that what had actually happened was that Rhythmbox had frozen. Lennart suggested[5] that the problem lay with Gstreamer which is, as yet, unable to make use of the information provided by PulseAudio. He also thought that Rhythmbox's frozen UI was not an issue as it should be frozen while inactive. Andrew corrected Lennart's interpretation with the information that the UI had been frozen both "during AND after the session was inactive, making it permanently frozen (dead, defunct, useless)." This clarification led[6] Lennart to suggest that a process other than PulseAudio had blocked the audio device and he asked Andrew to check this (it can be verified with pactl list sinks | grep SUSPENDED or else by using pacmd to obtain an interactive PulseAudio shell and passing it "list-sinks" as an argument. See man pactl; man pacmd for more information.) Another possibility suggested by Lennart was a known-issue with HAL failing to restore ACLs and he suggested getfacl /dev/snd/* to check this. Andrew later reported[7] that neither of these appeared to be the problem and documented his investigations with a bugzilla entry.

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

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

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

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

Using PulseAudio's ability to re-route "sound to /dev/null (and mic from /dev/null)" was suggested[8] by SimoSorce as a simple fix to stop applications crashing. Lennart argued[9] that any applications crashing were broken and should be fixed to merely freeze. This struck him as preferable to making non-trivial changes to PulseAudio. He added that his version of "expected behavior" is that the music should stop, and then resume on session switch in a manner similar to the suspension of processes achieved with a simple Ctrl-Z. It seems that PulseAudio forwards the information that suspending should happen, but the GStreamer plugin is unable to make use of the information. William "Jon" McCann (a Rhythmbox developer) agreed[10] that this was an issue and pointed to a related discussion on Gnome's bugzilla.

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

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

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

Earlier KevinKofler had suggested that muting, as opposed to blocking, might solve the problem but Lennart rejected[11] this on the basis that it would be impossible to continue streaming as the sound card's clock would be inaccessible. When Kevin further suggested that acceptable alternatives might include using an OS-based timer Lennart argued[12] that it would be "a PITA to do the switching back and forth" and AndrewFarris added[13] that it was pointless to stream to a muted device and that the resolution should be to pause the applications streaming to the device.

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

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

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

Another angle to the problem under discussion was explored when LesMikesell suggested[14] that the current approach was the wrong way to obtain an audio server not tied to a particular login session. Les wondered if it was necessary to now use Xnest, FreeNX, VNC, ssh or other non-VT methods to login to avoid grabbing hardware. JefSpaleta answered[15] that this should be viewed through the lens of ConsoleKit policy: "There's no technical reason that a music server daemon package for example couldn't drop in new policy that changed the behavior here. We just have to understand how to write that policy file and then agree that's the sort of thing we want server packages to do on install." A fairly long thread resulted in which Les robustly defended the viewpoint that it was both impossible to imagine[16] all the behaviors which might be needed in the future and that this specific behavior was incorrect. ChuckAnderson[17] and AlanCox[18] explained that the current default behavior enforced security in that it prevented, for example, audio snooping by users running in other sessions.

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

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

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

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

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

The discussion saw Les argue[19] that traditional UNIX behavior was being broken, that emergency VOIP calls could be disastrously interrupted and that controls based on ownership still allowed snooping by root. Lennart was unimpressed "Yes, and you know what? Unix sucks" and jokingly suggested that frevoke() might be making its way to Linux soon. AlanCox questioned[19a] the accuracy of Les' descriptions of UNIX behavior and how VT switching was handled by X and the kernel. Les stuck to his point that "its wrong to give permissions according to where you are instead of who you are, and its wrong to add default policy changes before documenting the way to manage them locally in unsurprising ways"

[19] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01184.html

[19a] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01377.html

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

There were some other responses, many of which sought a way to manage local policy, or the documentation for how to do so. "Drago01" responded[21] "Is it that hard to cl[i] ck some buttons in the policykit gui?" JefSpaleta's suggestion that it all came down to admins refusing to learn how to write local policy for HAL/ConsoleKit was met by JasonTibbitts' pointing[22] out that it was difficult to find out how to do this. ChristopherAillon helpfully suggested[23] reading the freedesktop.org documentation and/or yum install PolicyKit-docs. "Drago01" referenced[24] a post by DavidZeuthen (possibly this[25] one) and waved towards polkit-gnome-authorization as a way of helping people out.

[21] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01433.html

[22] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01383.html

[23] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01386.html

[24] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01387.html

[25] http://www.redhat.com/archives/rhl-devel-list/2007-November/msg00052.html

Some similar ground had been covered previously in FWN#113 "How Should PulseAudio Work"[26] and WillWoods' post (the third citation in that section) is very useful in explaining how PulseAudio integrates with the rest of the desktop.

Separate /usr An Anachronism?

StepanKasal noticed[1] that dbus-daemon was in /bin and that this was due to being a pre-requisite to bluetooth which in turn must be started before networking. Consequently an increasing number of daemons seemed to need to be started in single-user mode (runlevel 1). Stepan noted that the ability to mount /usr over a network was important to support, but wondered if it would be possible to split networking into a part which could support the necessary functions for "/usr over network" and another part which was only for things like connecting a phone via bluetooth.

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

BillNottingham was keen[2] to stop supporting "/usr over network" with a local "/". MatthiasClasen also asked[3] that Stepan "explain how the separate /usr is not just an anachronism [...] holding us back."

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

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

That challenge was taken up[4] by AlanCox, who explained that it was defined in the LSB and cautioned against dumping long-established abilities: Please don't confuse "I don't use it" with "obsolete" or you'll end up with a distro that's like some of the desktop apps and only usable by exact clones of their authors. Apparently mildly stung by this BillNottingham differentiated[5] "separate /usr" from "local / with network /usr" and gnomically argued "One is fairly useful, one is becoming more and more pointless over time."

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

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

Further battling over this saw Alan make the case[6] , in the face of BillNottingham's skepticism, that a /usr partition shared over the network by NFS or GFS2 allowed the rest of the system to be fitted onto a small local flash drive in a faster, easier manner[7] than a network boot. JeremyKatz responded[8] that initramfs for / on iSCSI or NFS already contained many of the pieces allowing a boot off flash without the "annoyances that dealing with a /usr-not-on-/ entails."

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

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

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

Git Is Not Git, Git Is A Metapackage

A surprised YaakovNemoy asked[1] why a simple yum install git had resulted in 29 dependencies, including emacs, cvs and subversion and totaling 32M. Yaakov wondered should he file a bug. Answers were quickly forthcoming from many to the effect that what Yaakov really wanted was git-core, not git which is actually a metapackage and that he should not file a bug.

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

Yaakov was thankful for the fast answers[2] from DanielBerrange, BillNottingham and others and decided not to file a bug. OlivierGalibert amplified[3] upon the answers a bit with the suggestion "For normal use, you want git-core and probably gitk."

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

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

Others were less thankful. NicolasMailhot welcomed[4] us "to metapackage hell" and AdamJackson's suggestion[5] that "metapackages must be explicitly named as such" garnered a lot of support. HansdeGoede argued[6] that this "actually is a bug, almost no other package has this." Hans' explanation of how his yum commands should be interpreted received[7] a reply from JamesBowes that upstream git had been requested to rename git-core to git and that "As for yum doing what you say and not what you mean, that is a bug. Please bring it up with Seth personally." JoshBoyer and JefSpaleta took pains to make sure that this was understood to be sarcasm. ToddZullinger explained[8] the correct way to make sure that such bugs are dealt with by Seth personally.

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

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

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

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

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

Pleading forgiveness in advance JoshBoyer decided[9] to pick on HansdeGoede, suggesting that he should bugzilla the problem instead of posting a "mailing list rant". Hans agreed[10] with him.

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

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

A discussion over the best naming scheme for metapackages (also known as dummy or virtual packages) led to the suggestion[11] by VilleSkyttä that the metapackage be replaced instead with a git comps group. This seemed to find favor with participants in the discussion including Yaakov on the grounds that comps were a consistent scheme.

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

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

Kernel-2.6.25 Rawhide Booting Problem

A report[1] from MikeChambers asked whether other rawhide users had experienced problems since upgrading to kernel-2.6.25-0.40.rc1.git2.fc9.i686 on 14 February 2008.

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

Although some were able to report no problems JarodWilson relayed[2] that there had been sporadic reports of boot failures, possibly to do with LVM VGs not being found. BillNottingham disputed[3] that it was anything "to do with LVM tools specifically" and instead was "to do with the kernel used to build your initrd. Newer kernels (2.6.25-git) rearrange sysfs - things that were directories are now symlinks, etc. This hurts mkinitrd pretty badly - it can't find the root devices right, to include the right drivers [...] any initrd built on 2.6.25-x will fail." He attached a patch to fix the problem. Discussion with Jarod suggests that the problem may extend back to some 2.6.24 kernels and Bill clarified[4] that it would probably occur if the initrd was "[b] uilt on a kernel where /sys/block/* are all symlinks."

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

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

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

BrunoWolfIII did some testing and reported[5] that falling back from a 2.6.25 kernel to 2.6.24 seemed to fix his problems.

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

Firefox 3 (Minefield) Zoomed Screen Size

DarrellPfeifer was concerned[1] that Firefox seemed "to have an incorrect impression of the screen size" and was displaying massive navigation buttons and displayed content.

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

FelixMiata was able[2] to reassure him that it was a feature not a bug, whereby the latest gecko display engine will carry out pixel scaling automatically for systems with greater than 144 DPI. As Darrell struggled with reconfiguring Xorg using information from xdpyinfo Felix outlined the problems with dealing with DPI resulting from the overhaul of video drivers. He suggested that an old videocard was the easy way out, but suspected that as Darrell was running Rawhide that he was up for helping iron out the bugs!

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

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

An excellent post by NicolasMailhot expanded[4] on the problem and suggested that either Firefox was being passed the wrong information or else Firefox itself was broken. Subsequent to Darrell filing a bugzilla it looked[5] as though the former might be the case.

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

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

LOCALE Vs. LANGUAGE

Some disparities in the stock settings of applications for paper sizes were noticed[1] by JohannGudmundsson. RoddClarkson also wondered[2] how important ISO standards were to Fedora and the thread later developed[3] into a discussion of what anaconda should be assuming about a user's locale based on the language they choose during installation. Rodd was unhappy that the installer's simple logic made some default choices which seemed broken to him: "Because I chose the English (USA) language, anaconda has assumed that everything I do is US. I'm even stunned to note that while I select Melbourne, AUSTRALIA as my time zone, local reports LC_TIME as en_US.UTF-8."

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

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

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

ChristianRose agreed[4] that some fixing of anaconda might be needed based on his experience of administering Swedish machines for work environments which use en_US for official communication but "Swedish sized" paper for printing. Christian thought that the assumption "that just because you want LC_MESSAGES=en_US, everything else should be en_US too" was wrong.

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

The idea that this was a per-user customization was expressed[5] by JefSpaleta. Jef argued that the installer did a good job of choosing a default and that was all that could be reasonably expected: "We set a sane default in the installer based on the locale, and then the installer gets the hell out of the way." MatejCepl provided[6] the simplest way for users to discover the settings they are currently using: locale. There's a lot more to the thread including many individual answers to the specific requirements of people identifying as various nationalities living in far-flung geographic locations who need system-messages in one language, time and date formatting in the convention of yet another and everything else in a third convention. An honorable mention goes to SimoSorce who requested[7] an as-yet unsupported locale "CAN I HAS ENGLISH(IT) ? KTHXBYE ;-)"

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

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

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

Artwork

In this section, we cover Fedora Artwork Project.

Artwork

Contributing Writer: NicuBuculei

Fedora 9 Artwork: Round 2 has ended, Round 3 has started

NicuBuculei announces[1] the end of Round 2 for choosing the default desktop artwork in Fedora 9. Two designs meet the requirements and qualified for Round 3: Waves[2] , proposed by MartinSourada and modified intro Sulfuric Waves by MairinDuffy and Shoowa[3] , proposed by LuyaTshimbalanga. Please send us feedback, either using the project's mailing list, Nicu's blog[4] or FedoraForum.org[5]

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

[2] Artwork/F9Themes/Waves

[3] Artwork/F9Themes/Shoowa

[4] http://nicubunu.blogspot.com/2008/02/fedora-8-artwork-round-2.html

[5] http://forums.fedoraforum.org/forum/showthread.php?t=177882

Echo development status

MartinSourada reports[1] about the status of the development for the Echo icon theme. The Echo icon theme[2] is developed by a group of Fedora Art contributors in an attempt to replace the old Bluecurve. It has a modern look and follow the Tango naming guidelines.

Martin talks about the new website including git web access and a nice status page, a final version of the guidelines, current activities, palns for future and more.

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

[2] https://fedorahosted.org/echo-icon-theme/wiki/IconThemeStatus

A new Inkscape release is coming

RahulSundaram forwards[1] there a call for testing for a development version of Inkscape, which in nearing a stable release. Inkscape is one of the major tools used by the team in their day to day work and the new release brings a lot on new and useful features, so they can be considered experts in the matter. When released, Inkscape 0.46 will be built also for Fedora 8 so is important to have it seriously tested in advance.

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

Daily Package

In this section, we recap the packages that have been highlighted as a Fedora Daily Package.

http://dailypackage.fedorabook.com/

Contributing Writer: ChrisTyler

License Change

The Fedora Daily Package articles are now dual-licensed[1] under the Creative Commons Attribution Share-Alike 2.5 Canada license[2] and the Open Publication License[3] . The OPL was added for compatibility with the Fedora Documentation Project[4] .

[1] http://blog.chris.tylers.info/index.php?/archives/105-Fedora-Daily-Package-License-Change.html

[2] http://creativecommons.org/licenses/by-sa/2.5/ca/

[3] http://opencontent.org/openpub/

[4] DocsProject

Maxima - Computer Algebra System

Productive Mondays highlight a timesaving tool. This Monday[1] we covered Maxima[2] :

"In the late 1960's, a computer algebra system named Macsyma was developed at MIT. ... Fedora includes the maxima package, an open-source descendant of the original Macsyma code (forked in 1982 and placed under the GPL in 1998)."

[1] http://dailypackage.fedorabook.com/index.php?/archives/162-Productive-Monday-Maxima.html

[2] http://maxima.sourceforge.net/

PDFCube - Presentation Viewer

Artsy Tuesdays highlight a graphics, video, or sound application. This Tuesday[1] PDFCube[2] was featured:

"PDFCube is a tiny (35k) player for PDF presentations. It provides double-buffered page switching (PgUp/PgDown or space), zoom to the corners or center of a page (h,j,k,l,z), and a Compiz-style animated cube transition (c)."

[1] http://dailypackage.fedorabook.com/index.php?/archives/163-Artsy-Tuesday-PDFCube-Presentation-Viewer.html

[2] http://code.100allora.it/pdfcube

Customizing the Grub Splash Screen

The Wednesday Why article[1] was on customizing the Fedora boot splash screen:

"A Fedora system usually begins its boot process with a startup screen (or menu) displayed by the bootloader Grub. The background for this screen is provided by the wonderfully talented Fedora artTeam[2] . ... Customizing your boot screen with a favorite photo, your company logo, or even a cartoon is quite straightforward."

[1] http://dailypackage.fedorabook.com/index.php?/archives/164-Wednesday-Why-Customizing-the-Grub-Splash-Screen.html

[2] Artwork

hplip-gui - HP Device Manager

GUI Thursdays highlight software that provides, enhances, or effectively uses a GUI interface. This Thursday[1] , hplip-gui[2] was discussed:

"HP printers and multifunction units are well supported in Fedora, thanks in large measure to HP's decision to open-source its driver software and utilities (hplip) in cooperation with related projects such as sane, ghostscript, and cups. The hplip-gui package provides a simple, convenient GUI front-end to these tools..."

[1] http://dailypackage.fedorabook.com/index.php?/archives/166-GUI-Thursday-hplip-gui-HP-Device-Manager.html

[2] http://hplip.sourceforge.net/

ksudoku - Sudoku Game

Friday Fun highlights fun, interesting, and amusing programs. This Friday[1] , we took a look ksudoku[2] :

"Ksudoku is a Sudoku game included in Fedora. It can generate Sudoku puzzles and many variants, including Roxdoku (3D) and Samurai (5 overlapping grid) versions."

[1] http://dailypackage.fedorabook.com/index.php?/archives/167-Friday-Fun-ksudoku-Sudoku-Game.html

[2] http://ksudoku.sourceforge.net/

Security Week

In this section, we highlight the security stories from the week in Fedora.

Contributing Writer: JoshBressers

Kernel Local Root

The most exciting thing to happen last week was probably all the attention CVE-2008-0600[1] got. This flaw could allow a local user to gain root privileges, and things such as SELinux wouldn't stop it. The significant part isn't the local root in itself, but rather that there were working exploits available in the wild. There are always kernel privilege escalation flaws, but there are not always easy working exploits.

This was of course fixed quite promptly in both Red Hat Enterprise Linux[2] and Fedora[3] .

[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0600

[2] http://rhn.redhat.com/errata/RHSA-2008-0129.html

[3] https://www.redhat.com/archives/fedora-package-announce/2008-February/msg00255.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: ThomasChung

Fedora 8 Security Advisories

Fedora 7 Security Advisories

Events and Meetings

In this section, we cover event reports and meeting summaries from various Projects and SIGs.

Contributing Writer: ThomasChung

Fedora Board Meeting Minutes 2008-02-12

Fedora Community Architecture Meeting 2008-02-11

Fedora Ambassadors Meeting 2008-02-13

Fedora Documentation Steering Committee (Log) 2008-02-14

Fedora Engineering Steering Committee Meeting 2008-02-14

Fedora Infrastructure Meeting (Log) 2008-02-14

Fedora Packaging Committee Meeting 2008-02-12

Fedora Release Engineering Meeting 2008-02-11

Fedora Bug Zappers Meeting 2008-02-13

Fedora SIG KDE Report Week 2008-02-12