From FedoraProject

Jump to: navigation, search


Fedora Weekly News Issue 110

Welcome to Fedora Weekly News Issue 110 for the week of November 12th. http://fedoraproject.org/wiki/FWN/Issue110

In Announcements, we have "Fedora Unity releases Fedora 8 Everything Spin".

In AskFedora, we have "GIMP 2.4.1 and Fedora 7", "Automatic Security Updates".

In PlanetFedora, we have "Seam running under IcedTea on Fedora 8", "Fedora 8 on a MacBook (intel)", "Custom Kernel documentation updated" and "First Torrent Movie".

To celebrate Thanksgiving Day[1] , Fedora News Team will take the next week off. Have a Safe Holiday!

[1] http://en.wikipedia.org/wiki/Thanksgiving

To join or give us your feedback, please visit http://fedoraproject.org/wiki/NewsProject/Join.


In this section, we cover announcements from Fedora Project.


Contributing Writer: ThomasChung

Fedora Unity releases Fedora 8 Everything Spin

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

"The Fedora Unity Project is proud to announce the release of new spin[2] , the Everything Spin. Included in this spin are all the packages available at the time Fedora 8 was released."

"This spin also includes 3 DVD images for each architecture, as well as 2 DVD Dual Layer images for those who are able to use them."

[1] https://www.redhat.com/archives/fedora-announce-list/2007-November/msg00013.html

[2] http://spins.fedoraunity.org/

Ask Fedora

In this section, we answer general questions from Fedora community. Send your questions to askfedora AT fedoraproject.org and Fedora News Team will bring you answers from the Fedora Developers and Contributors to selected number of questions every week as part of our weekly news report. Please indicate if you do not wish your name and/or email address to be published.


Contributing Writer: NilsPhilippsen, RahulSundaram

GIMP 2.4.1 and Fedora 7

Hasson Ofer <hassonofer AT gmail.com> : Will you make official gimp 2.4.1 package to fedora 7 ?

I've requested the push: https://admin.fedoraproject.org/updates/F7/pending/gimp-2.4.1-1.fc7

These are the update notes as of now:

This update is a major version change. Please test thoroughly. Don't flag it as working unless you have done really extensive testing! I don't want to push this to stable too soon.

For new features and other changes, please read the release notes of GIMP 2.4 on the web: http://www.gimp.org/release-notes/gimp-2.4.html

GIMP 2.4 is supposed to be compatible to older GIMP 2.x versions as far as plug-ins are concerned. It also uses the TinyScheme interpreter now for Script-Fu scripts which is a bit less forgiving about certain programming errors. If you use custom Script-Fu scripts, you might have to fix them to work in GIMP 2.4. Read the Script-Fu Migration Guide on the web for further information: http://www.gimp.org/docs/script-fu-update.html

-- NilsPhilippsen

Automatic Security Updates

Jenni and Adri <jattas AT supernerd.com.au> : I am a new user of Fedora and notice the regular updates. Some of them are huge. I have a 1 Gb monthly down and upload allowance and after that my ISP slows the speed of my internet service down. I used to let the updates download regardless, but I discovered that the size was that large that I nearly lost all capacity in the first 5 or 6 days of the month.

My question is: Is it possible to indicate the size of the automatic down loads so that I know how large the down loads are, so that I can do these down loads when it is the end of the service month?

While the software updater (Pup) does not show the size of the updates, there are two nifty yum plugins that can save you the hassle of keeping track of package sizes. The first is a plugin called yum-security that shows only the security updates and the second is a plugin called yum-presto [1] that downloads only the binary diff's on software updates instead of a full new package and can save you quite a lot of bandwidth and time. Use a combination of both and you don't have to worry about running out of bandwidth.

[1] http://hosted.fedoraproject.org/projects/presto

Planet Fedora

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


Contributing Writers: ThomasChung

Seam running under IcedTea on Fedora 8

KarstenWade points out in his blog[1]

"Best thing about his adventure? Pete ran a “highly unscientific test” and found out that IcedTea outperformed other JDKs"

[1] http://iquaid.org/2007/11/18/seam-running-under-icedtea-on-fedora-8/

Fedora 8 on a MacBook (intel)

KonstantinRyabitsev points out in his blog[1]

"It works quite well, including brightness buttons and the "fn" key. I upgraded from Fedora 7, so I can't comment on whether the installation has improved -- perhaps I'll try it again later."

Custom Kernel documentation updated

SamFolkWilliams points out in his blog[1] ,

"As several people have noticed, there were quite a few changes to the kernel spec file with the release of Fedora 8. The custom kernel document has now been updated to reflect these changes."

[1] http://samfw.blogspot.com/2007/11/custom-kernel-documentation-updated.html

[1] http://mricon.livejournal.com/386456.html

First Torrent Movie

JefSpaleta points out in his blog[1] ,

"As promised, I've started making animations of some of the torrent activity for the Fedora 8 torrents. And instead of using youtube, I'm now uploading the final videos to archive.org so you can get access to the original theora files."

[1] http://jspaleta.livejournal.com/15989.html


In this section, we cover Fedora Marketing Project.


Contributing Writer: ThomasChung

cio.com: The Fedora OS: Free, Stable and Customizable

RahulSundaram reports in fedora-marketing-list[1] ,

"The Fedora Project builds a world-class Linux operating system, consisting of entirely free (meaning both zero-cost and full source code available) software, that is used by companies, organizations and individuals worldwide."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-November/msg00249.html

redhatmagazine.com: Tour of GNOME Online Desktop

RahulSundaram reports in fedora-marketing-list[1] ,

"Here’s a tour of the pre-alpha demo release of GNOME Online Desktop included in Fedora 8. Learn more about what it does and how you can get involved in the project."

[1] http://www.redhatmagazine.com/2007/11/13/tour-of-gnome-online-desktop/

linuxtoday.com: Spinning a New Kind of Distro

RahulSundaram reports in fedora-marketing-list[1] ,

"While talking with Fedora Project Leader MaxSpevack yesterday, I increasingly got the sense that Fedora is positioning itself for something bigger. The key, I believe, is the spin management technology that was implemented in Fedora 7 and has now come to maturity in Fedora 8."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-November/msg00198.html

coffeedaze.com: Fedora/Linux for Noobs

RahulSundaram reports in fedora-marketing-list[1] ,

"While Fedora may not be the best starting point for someone with minimal computer knowledge, it is one of the most cutting edge flavors of Linux and has some amazing support"

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-November/msg00167.html

arstechnica.com: Fedora 8 sees strong adoption in first week

RahulSundaram reports in fedora-marketing-list[1] ,

"The latest version of Fedora—codenamed Werewolf—was released last week. According to statistics released this morning by Red Hat, Fedora 8 has been already been installed over 54,000 times in only four days."

[1] http://arstechnica.com/journals/linux.ars/2007/11/12/fedora-8-sees-strong-adoption-in-first-week

distrowatch.com: Distrowatch reviews Fedora 8

RahulSundaram reports in fedora-marketing-list[1] ,

"Overall, I truly believe that Fedora 8 is by far the best Fedora release to date (and I've tried every one of them). From the look and feel of the system, to the out-of-the-box configuration during installation, I couldn't be happier with a cutting edge release."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-November/msg00134.html

softpedia.com: Installing Fedora 8 Werewolf

RahulSundaram reports in fedora-marketing-list[1] ,

"Fedora 8 (codename Werewolf) was released yesterday and it's the most breathtaking version of the Fedora operating system. Not only does this release bring an installable LiveCD for both i686 and x86_64 architectures, but it also comes with exclusive KDE and GNOME LiveCDs."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-November/msg00132.html


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


Contributing Writer: OisinFeeley

As Review Request Queue Lengthens Tempers Shorten

NealBecker wondered[1] if he had done something wrong resulting in no one responding to his package review request. MamoruTasaka asked[2] for patience as there were about 270 unassigned review requests. JasonTibbitts thought[3] that the number was closer to 830 due to merge reviews and counselled "if the people who are submitting the packages don't do some reviews themselves, or we don't magically acquire several more review nuts then it's just going to be a long wait for every package in the queue." ThorstenLeemhuis topped[4] this with an estimate of 1108 open reviews and re-opened the discussion of how the governance of the Fedora Project is working. He cited an older email he had written which asserted that the levels of disgruntlement due to bureaucracy was rising.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01059.html

[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01063.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01107.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01125.html

ChristopherAillon agreed[5] with Thorsten, thanked him for his well-written email and suggested a webapp which would automate the testing of basic review tasks might ease some of the backlog. Thorsten agreed[6] with Christopher that accumulating guidelines would lead to a bogging down of the review process and suggested[6] that they be split into essential base knowledge "this you must know" and written reference material to provide "guidance in a specific area". Thorsten was unsure if a webapp was necessary and noted packagers (perhaps little-known) ability to do scratch builds in Koji (see also this same FWN#110 "Buildserver Kernel Release (PPC64)" for JesseKeating's suggested commandline to do this.) ToshioKuratomi took up[7] Thorsten's suggestion to organize and split the review guidelines.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01126.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01150.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01158.html

The numbers cited by Thorsten were questioned[8] by PatriceDumas, who suggested that the processing of new packages was a more important metric than the merged packages. Patrice was unhappy with the lagging of wiki documentation and the lack of new sponsors. Thorsten disagreed, suggesting that it would take until Fedora 12 at the current rate to get the merged packages reviewed. He also suggested[9] that experienced packagers should have direct CVS commit access to enable them to quickly fix up obvious specfile errors without having to go through the current process to clear such actions with the package owners.

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

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

HansdeGoede agreed[10] with Thorsten that in the pre-merge days he had felt more control over what FESCo did and added that now "certain groups within Fedora (*cough* release engineering *cough*) are indepent islands, not that these groups are not doing great work, but they don't seem controlled in any democratic way." He announced his intention to join the Fedora Packaging Committee (FPC). JoshBoyer asked whether he could identify and provide solutions to specific problems and Hans replied[11] briefly and finished with a statement of his belief that there was little point in such a discussion. JesseKeating described[12] himself as feeling "blindsided" by this and listed the places where changes had been discussed and required ratification by voting. Hans reiterated some of what he had already said and Thorsten provided[12] some specific links which contrasted feedback received with actual changes in the wiki (and hence policy).

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

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

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

[13] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01165.html

A detailed email from JesseKeating responded[14] to Thorsten specifically with details of which bits of feedback had been incorporated, responded more generally to what Jesse characterized as "the crux of Hans' complaint [being] that there is [a] freeze at all" and explained Jesse's motivation as trying to have a slow-down of changes introduced to the release tree while still also providing places for builds to be tested. Hans disagreed[15] and stated his complaint as the absence of a fast, non-human way of getting packages past the penultimate freeze. MatthiasClasen could not agree[16] with Hans that the process was unwarranted, nor could Jesse, who further argued[17] that a build is supposed to have been tested before it is requested.

[14] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01174.html

[15] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01176.html

[16] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01187.html

[17] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01193.html

A response from RalfCorsepius to Thorsten about the role of the FPC argued[18] that FPC had solved most of the problems apart from exotic corner cases and had thus lost its importance. Ralf also listed the use of ACLs and general policies as contributory causes to robbing FPC of the ability to enforce its decisions on packagers, whom Ralf argued were ignoring them. Thorsten responded[19] with an explanation of his desire to do away with the current committee-bound lethargy and replace it with a meritocracy in which anyone can announce plans and implement them if there are no strenuous objections. He also remembered some problems he had raised earlier on @fedora-packaging. A detailed response from TomCallaway raised[20] the spectre of revert-wars on an open wiki and noted that the documented process was hardly ever followed to propose new guidelines.

[18] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01229.html

[19] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01281.html

[20] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01411.html


NetworkManager Making Fedora 8 Hostile To Sysadmins ?

High blood pressure was experienced[1] by OlivierGalibert when he used the Desktop LiveCD to attempt an install of Fedora 8 to a machine with a static IP address. Olivier traced the problem back to Fedora Core 3 (providing a bugzilla entry to back this up) noting that NetworkManager ignores interface settings entered into anaconda and wipes out /etc/resolv.conf if DHCP is not used. To Olivier the problems had deepened with Fedora 8 as it seemed harder to actually remove NetworkManager.

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

One of the primary complaints raised by Olivier was addressed[2] by BastienNocera when he contradicted Olivier's assertion that chkconfig could not be used to disable NetworkManager. Bastien also thought that using the LiveCD to install servers was not its intended use case. JefSpaleta followed[3] up on the latter point with the information that the DVD image does not suffer from the problem of static routes entered into anaconda ignored. Jef also reminded the list that no one had argued that the use case of the LiveCD should be designed differently during the test cycle. While Jef thought that it was possibly a useful idea to produce an alternate LiveCD using the legacy stack instead of NetworkManager he suggested that due to the expected improvements in NetworkManager this point would be obviated by the time of Fedora 9.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01263.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01318.html

In a slight aside, the issue of the cyclic dependency of ldap and NetworkManager services upon each other dependencies was addressed when KellyMiller described the problem and RalfEtzinger supplied a useful ldap.conf stanza to ignore local users: nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus. ColinWalters agreed[4] that this should become the default option.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01467.html

LesMikesell had heard that it was no longer possible to do an NFS install with the DVD iso image, but ToddZullinger confirmed[5] that it still worked and added that if one wanted to download one single copy and install several machines from the image then there were multiple ways to accomplish the task using kickstart, pxeboot, cobbler and combinations of them.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01300.html

Another part of Olivier's list of problems was sorted out[6] by JefSpaleta when he countered the suggestion that it was impossible to turn NetworkManager off without removing its rpm. Jef described himself as "sort of confused" by these statements and queried whether Olivier could not simply query the status of NetworkManager using /sbin/service NetworkManager status and its default runlevels with /sbin/chkconfig --list NetworkManager. He suggested simply turning off NetworkManager using its initscript and turning on the legacy network and suggested that using mac addressing with dhcp worked well in large laboratory environments. Olivier's blood pressure dropped a little when he realized[7] that he must have been mistaken about it not being possible to turn off NetworkManager using the usual tools. He reiterated the point that options set in the installer should not be ignored and partially destroyed and suggested that at the least a dialog box should inform sysadmin performing the install that this was the case. JeremyKatz agreed[8] that "this sucks" and explained that changes to make NetworkManager better in this regard had not made it into Fedora 8 due to the need to freeze development for translations.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01270.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01291.html

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

Subsidiary interesting discussions during the thread mainly focused on the use of dhcp servers to provide a central point of administration, with contributions from AlexanderBoström[9] , "Jima" and NicolasMailhot[10] in favor and LesMikesell[11] and OlivierGalibert as slight skeptics.

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

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

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

Another of Olivier's objections was explored when JohnPoelstra concurred[12] that removal of NetworkManager should not also remove several other packages as dependencies including pidgin and liferea. JesseKeating responded[13] that this was because those packages used NetworkManager-glib in order to be able to "do the right thing" in response to network changes. ChristopherStone suggested[14] splitting out this functionality into a sub-package and argued that such splitting in general would make Fedora more useful as a base distribution. BillNottingham thought[15] on the contrary that this was a lot of work for a circa 100KB library dependency.

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

[13] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01277.html

[14] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01283.html

[15] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01290.html

RichiPlana, DanWilliams and MatthiasClasen investigated[16] the possibility of splittling libnm-util.so off into a sub-package so that the aforementioned NetworkManager-glib could also be an independent package.

[16] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01348.html

Minimal Requires: Codename "Masochist"

A quest to discover the minimal packages to install for a user using a chroot led PatriceDumas to ask[1] some searching questions about the dependency chains for the mandatory minimal packages. When JesseKeating asked why he did not just use the core comps group with yum --install-root=/path/to/chroot groupinstall 'Core' Patrice clarified[2] that this was possibly too large and he wanted a more fine-grained ability to select the most minimal set of packages.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01076.html

[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01088.html

TomCallaway proposed[3] that Patrice could carry out a test using a chroot to determine the smallest set of packages that could provide a working network, shell and text editor and suggested that this new comps group could be codenamed "masochist". When JeremyKatz thought that this description was exactly what the Core group in comps was intended to be, TomCallaway suggested[4] that perhaps Patrice meant to use "absurd replacements" such as tinylibc, minit and nash, but Patrice disavowed[5] this notion and honed[6] his question down to whether a non-bootable, chrooted minimal install would be a good idea.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01090.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01093.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01095.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01098.html

Later Patrice went[7] ahead with some tests and shared the information that it seemed that a rather long list of packages were installed even when he tried to pair things down.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01182.html

Gecko-libs Now Provided By Xulrunner-devel

An important change for applications which depend on gecko-libs was announced[1] by MartinStransky. The firefox-devel packages will no longer exist and instead are replaced by xulrunner-devel which provides gecko-libs. Martin explained that Firefox would henceforth be shipped as a pure XUL application running on Xulrunner[2] . Martin requested maintainers of packages which built against gecko-libs or firefox-devel to test rebuilds against xulrunner and to contact him or Chris.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01072.html

[2] http://developer.mozilla.org/en/docs/XULRunner

One of the first to respond[3] was AlexLancaster who was trying to rebuild Miro[4] (the excellent internet TV video player) and failing due to gtkmozembed-xulrunner being missing. When Martin provided an updated xulrunner package (1.9-0.alpha9.5.fc9) things appeared[5] to progress a little further.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01074.html

[4] http://www.getmiro.com/

[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01376.html

Attempts to rebuild kazekhase by MamoruTasaka also failed[6] , apparently due to a required header being removed from upstream. ChristopherAillon suggested using one of Mozilla's search tools to find files associated used in their software.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01080.html

The bigger picture was considered[7] by DennisJacobfeuerborn when he asked whether the separation of Firefox from Xulrunner would see the Fedora Project moving in an opposite direction to upstream Mozilla. Dennis wondered whether an eventual fork would be necessary and included a link[8] to a blog entry from BenjaminSmedbergs which discussed the problems of the shared Gecko Runtime Environment[9] on Microsoft Windows(TM). ChristopherAillon pointed out that the very link which Dennis supplied contained a point which confirmed that GNU/Linux distributions would be shipping Firefox3 as a XULRunner application. JefSpaleta added[10] that he was confident that the Fedora Project had a good roadmap for Firefox, but that he was more concerned with all the other applications depending on gecko-lib. He hoped that their maintainers were taking active steps to ensure that the transition to XULRunner had been adequately communicated to their various upstreams so that the maintainers themselves did not have to patch like crazy. ChristopherAillon was sanguine[11] that most would be using gtkmozembed and thus not be affected by the xulrunner changes.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01138.html

[8] http://benjamin.smedbergs.us/blog/2007-05-15/xulrunner-what-we-are-doing/

[9] Benjamin's blog explains that the GRE per se never really shipped on GNU/Linux and that it was essentially a precursor of XULRunner http://benjamin.smedbergs.us/blog/2005-10-31/using-the-gre/

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

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

Autoloading Of Kmods In Udev Area

The splitting out of various I2C[1] tools from the lm_sensors package led HansdeGoede to observe[2] that the OpenSUSE specfile, upon which he was basing his work, was creating character devices on the fly. Hans was also adding an alias into /etc/modprobe.conf.dist which caused the i2c-dev kernel module to be automagically loaded. He wondered if this was the correct approach to the problem and asked if someone could explain how loop.ko worked as it solved the same problem.

[1] http://www.esacademy.com/faq/i2c/

[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01027.html

BillNottingham answered[3] that the udev rule /etc/udev/makedev.d/50-udev.nodes created the loop device and requested further details of the modules behind the i2c device. MattDomsch linked[4] to the kernel list to show that his work on DMI-based module autoloading might make it possible to do something similar to what he had done for the dcdbas module.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01029.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01031.html

After further discussion between Hans and Bill which centered around the question of which approach would be fastest and use less memory Hans decided[5] to go with the approach of using a device node and kmod. He also noted that the loop module seemed to be autoloaded and promised[6] to file a bugzilla entry.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01036.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01041.html

/tftpboot Versus /var/tftp Or Somewhere Else

ChuckAnderson requested[1] that the current location of the TFTP "root" be changed from /tftpboot for a variety of reasons. He requested that at the very least SELinux policy be changed to allow /var/tftp as an alternate location. An especially strong objection made by him was that the root of the filesystem on many servers would be set as read-only.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00937.html

A response from DennisGilmore argued[2] among other things that the majority use case was to net boot machines and that this was read-only and commonly recognizable as a default. Dennis thought that someone smart enough to undertake one of Chuck's other listed use cases involving writing log data or crash dumps was probably competent to change the default location too. JonMasters agreed with Dennis and when Chuck appeared to discount his experience responded[3] by emphasizing that he had built embedded devices for a living.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00938.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01220.html

After PatriceDumas cited the FHS WarrenTogami suggested[4] copying Edubuntu's use of /var/lib/ftp and changing the SELinux policy to allow the use of both the current legacy setting and this new one. MichaelStahnke suggested using /srv but LubomirKundrak remembered[6] an earlier thread (see FWN#103 "RFC: /var Or /srv"[7] ) which he summed up as concluding "to not let anything in distro touch /srv, it's meant to be used only by user for his custom services." RichiPlana also suggested using /srv to which AlanCox responded[8] "/srv is not available to distribution vendors" and advocated sticking to the thirty year old tradition of using /tftpboot.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00945.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01066.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01066.html

[7] http://fedoraproject.org/wiki/FWN/Issue103#head-c1a0d4ef312061b439df55ebebc914e8fdbd0c7b

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

JesseKeating was skeptical about Alan's argument that the tradition was something which should be adhered to and pointed out that to be consistent would have meant keeping executables in /etc, similar to Solaris. Alan defended his position on the grounds that there were advantages to making that change, but none had been advanced for breaking tftpboot. RichiPlana came back[9] with a list of advantages mostly clustered around a simple, logical organization.

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

After StephenSmoogen inquired what the proper RFC procedure would be for making such changes to the FHS there was a brief kerfuffle when JonathanMasters misunderstood[10] Stephen to be announcing his intention to create a /srv/fedora directory to make everything Fedora-specific.

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

Buildserver Kernel Release (PPC64)

A failed attempt to build eclipse-subclipse for ppc64 led RobertMarcano to ask[1] whether the buildservers were running the latest Fedora 8 kernel. ToshioKuratomi responded[2] that they were in fact running Fedora Core 6 and were scheduled to be upgraded to RHEL5 in three weeks time.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00820.html

[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00847.html

DennisGilmore informed Robert that a kernel update had been built by DavidWoodhouse which should fix the bug which Robert had referenced. Unfortunately Robert replied[3] that he now got an error on x86_64. JesseKeating suggested[4] doing a scratch build using koji build --scratch dist-f9 --arch-override ppc64 foo.src.rpm When Robert had to report that while this new trick worked the error was the same on ppc64 Jesse wondered[5] if the problem was that the opening of GUI was being attempted on the builder machine which lacks Xorg. Unfortunately this did not appear[6] to be the problem.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01265.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01267.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01280.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01289.html

Extension Buddy For Fedora 9 ?

"MarkG85" kicked off[1] the discussion of an "Extension Buddy" which would be somewhat analogous to CodecBuddy in that it would sort out whether a file could be played by some application based on its extension, or could suggest a possible application which could do so.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00774.html

RalfErtzinger suggested that a bugzilla entry should be opened for the specific example given of "Audacious" failing to handle files with the .m3u extension. "MarkG85" was not pleased with this, but DavidTimms agreed with Ralf that filing such bugs is the best way to ensure progress and improvement. David also outlined[2] a detailed workflow or use case in order to understand the problem better. An alternate vision was detailed[3] by RichiPlana.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00794.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01023.html

The existing /etc/mime.types and /etc/mailcap were suggested[4] as a useful base by BrunoWolff.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00877.html

BastienNocera liked the idea and redirected[5] attention to an earlier discussion on @fedora-desktop which had considered the same problem.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00983.html

PulseAudio CPU Usage

Although he was enjoying PulseAudio questions about its CPU usage were posed[1] by AhmedKamal. Ahmed was also disturbed that it appeared in the process list with the name "exe"!

[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01442.html

A quick response[2] from LennartPoettering (the main developer of PulseAudio) informed that the "exe" naming issue had been fixed and pointed the finger of blame at Macromedia Flash for not closing playback streams until the browser window is closed. Ahmed's experiments in closing the browser confirmed that CPU usage by PulseAudio dropped[3] to 0%, but that starting up any other sound application saw it climb again due to the sampling issues outlined in Lennart's post. Lennart followed up with the suggestion that Ahmed could use pacmd followed by list-sinks to confirm that his card was fixed to 48KHz and that resampling would have to be done by either PulseAudio or whichever applications he was using, so it may as well be by PulseAudio.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01449.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01452.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01466.html

In response to CallumLerwick some further details about the "Speex" resampler were posted[5] by Lennart.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01480.html

Old Libtool Problems Reported By Check-rpaths

JohnDennis found[1] that one of his packages failed to build on x86_64 because the check-rpaths script complained that there was an RPATH in the .so of a loadable module produced by the package.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01350.html

A suggestion[2] from RayStrode that the package might include a buggy, older version of libtool was confirmed[3] by HansdeGoede.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01356.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01369.html


In this section, we cover Fedora Artwork Project.


Contributing Writer: TimothyRoberts

Naming of Fedora 9?

Now that Fedora 8 "Werewolf" has finally been released into the wild, the gauntlet has been thrown. What shall we name the next Fedora release? JakubRusinek has started this lengthy debate on fedora-arts-list[1] , with numerous people throwing in their two cents. What are you waiting for? Send in your own idea. It could become the next big thing.

[1] https://www.redhat.com/archives/fedora-art-list/2007-November/msg00073.html

Fedora 9 Theming?

MichaelBeckwith has brought to our attention that Fedora 9 theme ideas need to start rolling in[1] . He emphasis ideas that revolve around the idea of "Freedom". So let your creative side come forth and spawn something truly beautiful for the next release.

[1] https://www.redhat.com/archives/fedora-art-list/2007-November/msg00106.html

Rounded Corners Patch for Nodoka

CharlesBrej has released[1] a patch to the Nodoka GTK theme, slightly altering it to change any square corners to rounded ones. A small change, but well appreciated by many people. This patch can be found here[2] .

[1] https://www.redhat.com/archives/fedora-art-list/2007-November/msg00093.html

[2] http://www.mediafire.com/?1nybuai1d5c

Spring and Autumn On Your Desktop

StevenGarrity has proposed a new idea for the Fedora Desktop: Seasonal theming[1] . The beauty of spring and autumn manifested into pixels, wouldn't that be a sight to behold? He states that we could, 'adopt a "spring' visual theme for the odd-numbered releases that fall in the spring, and a 'fall' visual theme for the even-numbered releases that fall in the, well, fall." What are you waiting for? Go outside and get inspired before the fall(Or spring, if you're in the southern hemisphere) ends, and winter(Or summer) sets in.

[1] https://www.redhat.com/archives/fedora-art-list/2007-November/msg00099.html

Infinity 24 for KDE

LaithJuwaidah has released[1] a small script to the community, that changes the wallpaper on a KDE desktop every hour, to different versions of the "Infinity" wallpaper. The script utilizes KDE's advanced desktop options, so all you GNOME users seem to be out of luck for the moment. The script can be found here[2] .

[1] https://www.redhat.com/archives/fedora-art-list/2007-November/msg00122.html

[2] http://ljuwaida.fedorapeople.org/Artwork/Infinity/KDE/Wallpaper

Security Week

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

Contributing Writer: JoshBressers


Last week saw the release of a new version of Samba, with two security fixes:



Both of these issues sound pretty bad, but only CVE-2007-5398 is truly scary. CVE-2007-4572 initially looked rather bad, but after a thorough analysis it was determined that under normal use the flaw shouldn't even crash the Samba server. A detailed analysis of this flaw can be found here:


AppArmor's Security Goals

I'm no fan of AppArmor, but aside from that there is a most interesting read regarding it on Kernel Trap. Those of you interested in such a thing might find it useful:


Hushmail not so hush

It seems that Hushmail is willing to share the PGP keys of its clients with law enforcement:


While this probably isn't terribly surprising (most companies are willing to work with law enforcement). It is an opportunity to point out that unless you have complete control over your encryption key, you should assume that someone else has it. This includes things like storing keys on NFS home directories or using public computers with your private key. Keeping a private key protected properly is very difficult, and everyone has to compromise perfect security for reality at some point. It should be completely obvious though, that trusting someone else, especially a corporation, with your private key is most unwise.

Advisories and Updates

In this section, we cover Security Advisories and Package Updates from fedora-package-announce.


Contributing Writer: ThomasChung

Fedora 8 Security Advisories

Fedora 7 Security Advisories

Fedora Core 6 Security Advisories

Events and Meetings

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

Contributing Writer: ThomasChung

Fedora Board Meeting Minutes 2007-MM-DD

  • No Report

Fedora Ambassadors Meeting 2007-MM-DD

  • No Report

Fedora Documentation Steering Committee (Log) 2007-MM-DD

  • No Report

Fedora Engineering Steering Committee Meeting 2007-11-15

Fedora Infrastructure Meeting (Log) 2007-11-15

Fedora Localization Meeting 2007-MM-DD

  • No Report

Fedora Marketing Meeting 2007-MM-DD

  • No Report

Fedora Packaging Committee Meeting 2007-MM-DD

  • No Report

Fedora Quality Assurance Meeting 2007-11-14

Fedora Release Engineering Meeting 2007-11-12

Fedora SIG EPEL Meeting Week 45

Fedora SIG KDE Meeting Week 46

Fedora SIG Store Meeting 2007-11-14