From Fedora Project Wiki


Revision as of 10:58, 14 April 2009 by Fab (talk | contribs) (added category)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


Fedora Weekly News Issue 107

Welcome to Fedora Weekly News Issue 107 for the week of October 22nd.

In PlanetFedora, we have "Fedora 8 - Blocker bugs status", "Fedora 8 ALSA kernel needs Testing", "Scary Haloween with Werewolves", and "Projeto Fedora?"

To join or give us your feedback, please visit


In this section, we cover announcements from Fedora Project.

Contributing Writer: ThomasChung

No Official Announcement was made for this week.

Planet Fedora

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

Contributing Writers: ThomasChung

Fedora 8 - Blocker bugs status

RahulSundaram points out in his blog[1] ,

"As we get ready for a new release of Fedora, the things we worry about most are the blocker bugs. A couple of QA meetings back, I suggested to Will Woods to post status reports of the blocker bugs every week or alternative week to get some eyes on the important bugs that can block a release and delay it and he has been doing those now and then."


Fedora 8 ALSA kernel needs Testing

WarrenTogami points out in his blog[1] ,

"We are seriously considering using this newer upstream ALSA in F8. But given the tight schedule we need testing to be sure it doesn't horribly break anyone. Reportedly it makes sound behave MUCH better on newer laptops, like ICH8 Intel hardware. Test!"


Scary Haloween with Werewolves

NicuBuculei points out in his blog[1] ,

"I planned to show this cartoon out only next, in time for Halloween, but as it was unveiled already in another place, here is it: halloween."


Projeto Fedora?

MikeMcGrath points out in his blog[1] ,

"Thats right, some of our volunteers have been hard at work (ivazquez and ricky in particular). These guys with the help of some others have gotten our new website in a bit better shape."

"More translations are on the way, if you're a translator, help translate and proof what's there! We had initially scheduled it for Fedora 9 but the work is done already so F8 it is!"



In this section, we cover Fedora Marketing Project.

Contributing Writer: ThomasChung

Fedora, Transifex and upstream L10N

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

"Free software is used all around the world, and as such it needs to be translated to all kinds of different locales. Fedora has a very active translation community, and they decided it was time that some better tools existed for contributing translations and integrating with upstream. To find out more about this, I talked with DimitrisGlezos, discussing the new Transifex project, what it was like to work on a Google Summer of Code Project, and much more..."


Red Hat Magazine | GIMP 2.4 preview

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

"This is a preview of the new GIMP 2.4 which will come with Fedora 8 and is (IMO) important for the general desktop user. Even if it is not a major release feature, I tried to make a tie and talk a bit about F8 too."


Fedora 8 renews tradition of innovations

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

"This release makes it obvious that the Fedora community prides itself on innovation. If nothing else, the public documentation of each change on the project wiki should make the perspective clear. If, despite being marked on the wiki as complete, some of these innovations seem flawed or limited, that seems only inevitable -- with so many efforts at finding a new direction, some are bound to fail, or to be less successful than others, especially in their first release. Fedora deserves appreciation for trying. At the introductory stage, that matters more, perhaps, than complete success."



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

Contributing Writer: OisinFeeley

Crypto Consolidation

(For some bizarre reason we neglected to cover this important issue when it was first announced by SteveGrubb, despite being aware of the thread. Apologies.)

BernardoInnocenti suggested[1] that it would be a worthwhile goal to choose one of the multiple implementations of SSL carried by Fedora as a default. In seeking criteria to make this decision Bernardo mentioned that examination of the dependencies of other packages indicated that OpenSSL, NSS and GNU-TLS were equally popular within Fedora and provided a link to a GNU-TLS benchmark which suggested its superiority. PádraigBrady responded[2] with a link to SteveGrubb's post from August 2007 which introduced[3] the Fedora Crypto Consolidation Project. Steve's post indicated that Red Hat had settled on using NSS[4] as it is a certified (FIPS-140-2[5] ) library performing all the cryptographic functions within itself, meaning that any applications linking to it which also follow system security policies are de facto certified by FIPS-140-2 also. Steve pointed out that a single toolkit would reduce the maintenance burden and make it easier for applications to gain new cryptographic technologies. He asked for help from maintainers in enabling NSS for their applications and feeding their changes back upstream. The wider impact of centralizing cryptographic services in terms of simplifying user interaction is outlined[0] on the wiki.







As Bernardo had compared this effort to the effort made for spellcheckers and had wished as a minimum to make PKI management easier, RichardJones was reminded[6] of his earlier efforts (see FWN#87 "Fedora Standards For Contents Of /etc/pki"[7] ) to standardize the contents of /etc/pki. Richard speculated that there were probably many more implementations as he knew of at least one more in OCaml. He recounted that the choice of GNU-TLS for libvirt[8] had been determined due to its clean, well-documented API and also expressed a preference for GNU-TLS's certtool for certificate management. Richard was skeptical, however, that Bernardo could achieve his goal because "[r] ewriting code to use a different API is a lot of make-work that no one wants to do, and doesn't contribute much benefit to anyone."



[8] Libvirt provides a stable interface layer to KVM, QEMU, Xen etc.

There was agreement on the cleanliness of GNU-TLS's API, the ease-of-use of certtool (both in comparison to OpenSSL) expressed by several developers, including AndrewBartlett[9] (of SAMBA) and DanielBerrange[10] . Daniel also shared Richard's skepticism about the tractability of the problem despite its advantages "Re-writing applications to switch from one impl to another is seriously non-trivial. There is no way in the world you'd want to carry such patches in the Fedora packages because they'd be a huge maintenance time sink whenever a new upstream release came out. So getting any port accepted by the upstream application author has to be the number 1 priority." Dan also introduced the problem of OpenSSL's regular ABI breakage as a likely reason why more packages would choose GNU-TLS over it.



SteveGrubb clarified[11] that the aim of the Fedora Crypto Consolidation Project was not, as RichardJones thought, to get everyone to rewrite their code to use a different API immediately but rather to introduce a "--with-nss" option to packages to make a future transition possible. An openssl compatible API has been developed to that end.


ThomasSteenhold advocated[12] a laissez-faire approach which recognized that projects were free to choose whichever implementation they preferred. He worried that compatibility layers and Fedora-specific patches introduced complexity and bugs, but conceded that perhaps using a preferred implementation when there was choice could be useful. Steve agreed[13] with Thomas that it wasn't the Fedora Project's job to interfere with another project's choice and emphasized that the goal was to add the option of being able to choose to link against NSS as another option. He restated the objectives as "We want to help upstream projects add choice. We want to find out what the rough spots are for NSS and improve its documentation and API so that we can use it everywhere." JeremyKatz still thought[14] that this was going to be tough.




Some ruffled feathers were in evidence when JohnDennis asked[15] why, if SteveGrubb's avowal of not wanting to decide anyone's preference were true, a "slew" of bugs had been opened by PeterVrabec. John noted that he had seen no consensus that maintenance effort should be spent this way. SethVidal added[16] that many of them were also wrong, such as those opened against YUM instead of Python. JesseKeating consequently wondered[17] if it was proposed to remove python's ability to create sha1sum hashes. SimoSorce responded[18] "[j] ust make it easy to compile with NSS or use your own if NSS is not available." DanielBerrange agreed[19] with Seth that many of the bugs were wrong and asked that before bugs were filed that the application in question should be checked to make sure it is actually using the crypto libraries which were being suggested for replacement. Initially TomasMraz argued[20] that he had done this, but later conceded[21] that there were errors in the process.








After ThomasMraz responded to JohnDennis reiteration of a request for information as to whether consensus had been sought on spending developer time on this, ChristopherAillon suggested[22] that FESCo should be consider the issue.


The problem of NSS not providing all desirable algorithms was raised by SimoSorce (SAMBA maintainer) and RobertRelyea responded[23] by asking which were the missing algorithms. He conjectured that MD4 might be one of them, as it was used for Microsoft's NTLM authentication mechanism. He noted that the plan was to provide a library to support NTLM. The SAMBA maintainers weren't overly enthusiastic and AndrewBartlett wondered what was going to be done about rsync.


The importance of being able to add new cryptographic functions quickly and uniformly was highlighted when AlanCox raised[24] the probability that the SHA-1 family of hash functions would not be of use in the near future and BrunoWolff[25] and others provided information confirming this. Although PaulWouters was skeptical[26] the SHA-2 family would be proof against current attacks on SHA-1 (and also pointed out that IPSec was not affected due to using HMACs) EnricoScholz[27] thought that probably there was a safe ten year buffer gained by transitioning to SHA-2 hashes.





Fedora 8 Blocker Bugs

A list of fourteen critical bugs which must be fixed if the release of Fedora 8 is to happen on schedule ("blockers") was posted[1] by WillWoods on October 26th. Will was optimistic that the release would proceed on schedule but highlighted the bugs for which help in testing is requested. The detailed list contains details of the status of the bugs.


There was very focused feedback to this email with some confirmations[2] of fixes, but also several reports[3] [4] that despite huge improvements NetworkManager may still be in need of some changes.




Will noted that the very latest patches can be obtained from Koji before they hit rawhide and said "Most of those bugs already have fixes pending, and none of the rest are hair-on-fire critical bugs, so I think we're in good shape. If you can help test the stuff I mentioned above, or you have found some huge problem that we've missed, please let us know."

Laptop Harddrive Wear And Tear

PádraigBrady drew attention[1] to a bug entry posted on Ubuntu's "Launchpad" (a proprietary bug-tracking/ERM tool) which saw users reporting that their laptop hard-drives were being subjected to unnecessary load cycles due to an ACPI script. A post[2] on PaulLuon's journal identified the issue as being due to the "load/unload" technology introduced in the mid-1990s in order to reduce the effects of stiction between heads and platters. The side-effect of this attempt to reduce damage is that the load/unload mechanism wears out after three hundred thousand cycles.



BillNottingham posted[3] that Fedora took the values set as defaults by the BIOS. On Launchpad MatthewGarrett posted[4] the same information as regards Ubuntu. AlanCox stated[5] that Windows took the same strategy.




Some practical investigations were initiated[6] by WarrenTogami, who suggested power-cycling and then running hdparm -I /dev/sda | grep "Advanced power management. JesseKeating, ThorstenLeemhuis and ChuckEbbert[7] all reported an unhelpful "unknown setting", possibly due to their drives being in AHCI mode. Alan reiterated[8] "[t] he settings we use are those set by the firmware or the preboot environment [and] we don't force them and its not our business to do so as far as I can see."




BIG FAT WARNING: X Breaking In Rawhide

A warning[1] from AdamJackson flagged a month of pain post Fedora 8 release due to serious upstream changes to Xorg.


DarrellPfeifer and RoddClarkson announced[2] that they were happy to test and that this would be made easier if Adam could provide backup/back-out options or hints.


DaveAirlie was drawn out by DavidNielsen to explain[3] that the two main projects were to "composite by default" and to provide a smooth graphical boot transitioning from GRUB to GDM login with only a single mode set.


RichardHally also suggested[4] that a fall back option of the "old stuff" would be useful for rawhide testers.


Fluendo Codecs Violate SELinux Policies

A request[1] from ValentTurkovic for help in installing the "fluendo codec mega pack" (after he had apparently followed the instructions) saw a simple response[2] from JesseKeating in the form of an email which was blank but for Jesse's customary signature: "Fedora -- All my bits are free, are yours?"



A longer, repetitive thread[3] followed in which Valent avowed that he could not localize the problem to the vendor or to "OSS bits" such as CodecBuddy and Jesse repeating that if the proprietary software did not work then Valent needed to follow up with his vendor.


A detailed list of default actions to take was suggested[4] by BastienNocera, including how to check if the codecs are installed gst-inspect-0.10 | grep flu, and where to file a bug with Fluendo.


After Valent posted the output of gst-inspect a problem was noticed[5] by FernandoHerrera who suggested that an SELinux adjustment to allow a relocatable shared library would allow the codecs to work. Fernando suggested chcon -t texrel_shlib_t /home/fedora8test3l/.gstreamer-0.10/plugins/*.so (as an aside DanWalsh's LiveJournal talks[6] about this type of problem and its security implications, borrowing/referencing UlrichDrepper's explanations).



Upon RahulSundaram's suggestion that Fluendo should fix their code, or that Valent could seek special dispensation from the SELinux team by filing a bug report Valent reported back[7] with Fluendo's response which seems to implicate Intel's "IPP".


SUIDs Gone Wild

The issue of suid applications needing some oversight or tracking was raised[1] by ThorstenLeemhuis. Discussion centered on the possibility of adding some functionality into rpmlint.


ALSA 1.0.15 Update Test Kernels

The possibility of the latest audio drivers in Fedora 8 was dangled[1] in front of @fedora-devel subscribers by ChuckEbbert who was fishing for testers. Those replying were happy with the results.


RPM Packages Not Signed?

A perplexed YonasAbraham wondered why his rawhide system was reporting that about sixteen packages were unsigned. WillWoods responded[2] that rawhide packages were never signed, and it turned out that the problem was that Yonas' system had been switched from updating from "development" to "fedora" and "updates".




KDE Compiz Switching Snazziness

The problem of being able to switch between the window managers kwin and compiz was mooted[1] by SebastianVahl. Sebastian had prepared a switching script which used compiz-manager and wondered if it could be included in compiz-kde and compiz-manager for Fedora 8.


Rules On Packaging Vestigial Libraries

A request[1] from HansdeGoede that he be allowed to retire two external library packages and subsume them into the only application which depended on them turned into a substantial thread. The issue seemed to be that the upstream code was using internal versions of these libraries with bugfixes because their upstreams had been dead for years. ToshioKuratomi argued[2] that Hans should only do this once he'd established that upstream for the "Advanced Strategic Command" game (asc) would not take over this responsibility.



Hans was a bit irritated to find himself apparently channeling RalfCorsepius when he said "I'm totally fed up with having discussions like this with the bureaucratic powers that control Fedora (woa I feel like I'm Ralf now) either the powers that be give me permission to use SDLmm and paragui as included and maintained within upstream asc release, or I'll just orphan all 3 of them. I refuse to become upstream for 2 libraries backporting fixes from asc each release just because some people want to follow the rules as if they are something holy. Orphaning asc would be a shame as its a great and quite popular game, but if that is want the powers that be want, then that is what they will get."


A mild response[4] from Toshio robbed the thread of all its drama, and he pointed out that he was responding to a specific request for comments by providing some alternatives and not forcing anyone to do anything.


Advisory Board

In this section, we cover discussion in Fedora Advisory Board.

Contributing Writer: MichaelLarabel

Content On

On the fedora-advisory-board list, JesseKeating asked[1] whether there should be content at the Fedora Project Start page[2] . It turns out that SethVidal is currently working on content for this page along with the fedora-websites-list. More content should be up on this page shortly.



New FUDCon Proposal

GregDeKoenigsberg, the Fedora Community Development Manager, and MaxSpevack have laid out the schedule for future FUDCons[1] . The next proposed FUDCon is from January 11 to the 13th at the Red Hat headquarters. After that, there will be another FUDCon in June during the Red Hat Summit. Greg and Max propose that future FUDCons be held during Red Hat Summits (all over the world) and that there will always be a FUDCon in December and June.



This section, we cover the news surrounding the Fedora Translation (L10n) Project.

Contributing Writer: JasonMatthewTaylor

Release Notes Work (Now and Future)

All the dedicated folks working on the release notes for Fedora 8 will likely have noticed a change in structure in CVS, PaulFrields this week created some new branches.[1] The translators still need to work with the F-8 branch, as a side benefit they can also add their translations to the -devel branch so that the latest translations are available for when the team starts on F9 release notes.


Translation of

The websites team this week enabled translating on the static pages of BartCouvreur mentioned in this post[1] some additional thoughts. There is some workflow details to be worked out but for those looking to go to work on the pages, the POT file can be retrieved from here[2] .




In this section, we cover the Fedora Infrastructure Project.

Contributing Writer: JasonMatthewTaylor

News site CMS

MikeMcGrath started a thread[1] in regards to a new website and how to best implement it. After much discussion it seems to be still up in the air which combination of software the team will use (php and python based). Anyone that has anything to add feel free to comment!


Koji Personal Repos

JesseKeating introduced this piece[1] about adding a personal repository capability to koji for easier experimentation with packages. This is a great idea, there are some infrastructure concerns mainly making sure enough storage space is available but look for this to be implemented in the future, as always comments/suggestions are always welcome.


Security Week

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

Contributing Writer: JoshBressers

Why are so many browser flaws rated as critical?

To many people on the outside world, it's sometimes non obvious why such a big deal is made about the web browser. The story below highlights that an ad server was broken into and used to distribute malware.

People usually think that if they're at a trusted site, such as their bank, a news site, or even some search engines., they are safe and they can let their guard down. The network of webservers have become very pervasive, and the line between sites continues to blur. As various sites start opening up public APIs, this line will eventually vanish completely. The web seems to be evolving into one giant squishy ball of putty, rather than lots of little ones. This in turn is creating an environment more dangerous for its users, with no clear fix in sight.

Virtualization is less secure

I ran across this posting to an OpenBSD mailing list the other day:

Talk of security virtualization reminds me of the old saying about debugging by Brian Kernighan

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

This is hard problem. I doubt the solution lies in writing golden code. It's more likely that technologies like SELinux are going to be far more effective than expecting everyone to write bug free software.

Advisories and Updates

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

Contributing Writer: ThomasChung

Fedora 7 Security Advisories

Fedora Core 6 Security Advisories

  • None reported

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 2007-MM-DD

  • No Report

Fedora Engineering Steering Committee Meeting 2007-10-25

Fedora Extra Packages for Enterprise Linux Report 2007-10-28

Fedora Infrastructure Meeting (Log) 2007-10-25

Fedora KDE-SIG Meeting 2007-10-23

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 Release Engineering Meeting 2007-10-22