From Fedora Project Wiki

< FWN

Revision as of 01:03, 3 August 2008 by Ush (talk | contribs) (#137 adding all beats complete as of 21:00 Sat)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Fedora Weekly News Issue 137

Welcome to Fedora Weekly News Issue 137 for the week ending August 2, 2008.

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

Fedora Weekly News keeps you updated with the latest issues, events and activities in the Fedora community.

We are pleased to present a new beat on Virtualization issues and developments brought to you by beat writer Dale Bewley. In Developments we report on "How Maintainers Can Help Reduce XULRunner Breakage". In Announcements we reveal the Fedora 10 codename. In Artwork we examine "The Blue Color of Fedora". In Security Advisories, another new beat authored by David Nalley we run through the week's important updates. We are also saddened to announce the departure of Thomas Chung from the editorial chair, but heartened to be working as a new editorial team consisting of Pascal Calarco, Oisin Feeley and Huzaifa Sidhpurwala.

If you are interested in contributing to Fedora Weekly News, please see our 'join' page. Being a Fedora Weekly News beat writer gives you a chance to work on one of our community's most important sources of news. Ideas for new beats are always welcome -- let us know how you'd like to contribute.

We are still looking for a beat writer to summarize the Fedora Events and Meetings that happened during each week.

http://fedoraproject.org/wiki/NewsProject/Join

Announcements

In this section, we cover announcements from the Fedora Project.

http://www.redhat.com/archives/fedora-announce-list/

http://www.redhat.com/archives/fedora-devel-announce/

Contributing Writer: Max Spevack

Fedora 10 (Cambridge)

Josh Boyer informed us[0] that "Cambridge" was the winning name in the Fedora 10 naming election. Jeremy Katz wrote[1] on his blog that "Cambridge" was the original Red Hat Linux 10 codename, which was the release that eventually became Fedora Core 1.

[0] https://www.redhat.com/archives/fedora-announce-list/2008-July/msg00014.html

[1] http://katzj.livejournal.com/434986.html

Developments

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

Contributing Writer: Oisin Feeley

How Maintainers Can Help Reduce XULRunner Breakage

The recent breakage of many packages which depend on xulrunner (see FWN#136 "XULRunner Security Update Breakage Stimulates Bodhi Discussion"[1]) was addressed[2] in a post by Will Woods. Will reported that a QA meeting involving Christopher Aillon (caillon), as Firefox/XULRunner maintainer, had investigated the problem and produced an explanation and some recommendations for other package maintainers. As Christopher was unavailable for a week Will was relaying the information in the hope that some fixes could be made in his absence.

[1] http://fedoraproject.org/wiki/FWN/LatestIssue#XULRunner.Security.Update.Breakage.Stimulates.Bodhi.Discussion

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

The reason that some xulrunner-dependent packages were affected and others not was that xulrunner provides both a stable API gecko-devel and an unstable API gecko-devel-unstable. Will noted that BuildRequires of xulrunner-devel or xulrunner-devel-unstable should no longer be used and instead that gecko equivalents should replace them.

Packages using the stable API were unaffected by the update of xulrunner. Will stated that "[t]he unstable API could change at any time, so if your app is using the unstable API it must be rebuilt *every time* xulrunner is updated." It was recommended that packages that used the stable API should use the following in their specfiles:

Requires: gecko-libs >= 1.9
BuildRequires: gecko-devel >= 1.9

and that those using the unstable API should use:

%define gecko_ver 1.9.0.1
Requires: gecko-libs = %{gecko_ver}
BuildRequires: gecko-devel-unstable = %{gecko_ver}

Lastly an important request was made of package maintainers: "if your package uses the -unstable API, please send caillon redhat com a note, and *please* consider adding him to the ACL (or opening it entirely). He keeps tabs on all packages requiring the unstable API so they can all be rebuilt for each security update."

Braden McDaniel wondered[3] why the same headers, but with different pathnames, were provided by xulrunner-devel-unstable and xulrunner-devel and Ville-PekkaVainio had[4] the same question.

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

In response to the suggested BuildRequires Douglas Warner requested[5] that a Provides: gecko-libs-api = 1.9 be added to xulrunner so that dependent packages would break if xulrunner were bumped to a new version which was not compatible: "For example, I can't do: Requires: gecko-libs < 2.0 Because I'm not guaranteed that the next version will *be* 2.0 (it might be 1.10, for example)." Rex Dieter independently came[6] to the same conclusion. Denis Leroy begged[7] that xulrunner would use "libtool-style soname versions like all other libraries in Fedora? So we don't need to add the version numbers in the spec file in the first place." Denis thought that xulrunner would fail a standard Fedora package review.

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

NEVR Again

Another report detailing broken upgrade paths was posted[1] by Jesse Keating's script (see FWN#136 "Broken Upgrade Paths Due to NEVR"[2]). This time it reported those packages which failed the path "f8-final -> dist-f8-updates -> dist-f8-updates-testing -> dist-f9-updates -> dist-f9-updates-testing -> dist-f10" and seventy-eight packages were listed. Also included as per last week's discussion was an ordering of the list per-builder as opposed to per-owner. Jesse requested[3] feedback from recipients of the automated email warnings if problems are encountered.

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

[2] http://fedoraproject.org/wiki/FWN/LatestIssue#Broken.Upgrade.Paths.Due.to.NEVR

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

Stephen Warren was concerned[4] that the upgrade path did not include the GA release of dist-f9: "Shouldn't dist-f9-final (or whatever the correct name is) be inserted in this path list between dist-f8-updates-testing and dist-f9- updates?" This led to an interesting exchange with Kevin Kofler who argued[5] that the converse should be expected and it was desirable that updates to Fedora 8 would have higher EVRs than the packages which were released for "dist-f9". Stephen argued[6] that it would make it easier to backport fixes if bumping of the release number rather than the version number were preferred and suggested changing what he understood to be Fedora's policies. KevinKofler disagreed[7] both with Stephen's description of current Fedora practices and also with his desire to reduce version bumps. He listed several situations in which these bumps would be useful and suggested that it was such version upgrades which uniquely distinguished Fedora from Debian "stable" or Red Hat EL.

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

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

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

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

The possibility that simultaneous updates would be released to all branches was discussed[8] by Kevin Kofler and Jesse Keating. Although Jesse thought this was a corner case and that it was best to let the maintainer decide Kevin was motivated[9] to write a patch as it was in his experience a common problem. Kevin thought that if Jesse wanted to avoid spamming maintainers with bogus reports then his patch would remove about thirty-nine percent of the volume. Jesse was grateful and excused[10] himself from looking at the patch for a week due to the pressure of releasing the alpha of Fedora 10.

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

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

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

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

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

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

Slimming Down Java by Sub-Packaging AOT

A request to separate out the AOT[1] parts of Java packages into sub-packages was made[2] by Caolan McNamara. He estimated that it would be possible to remove circa 45 Mb (in /usr/lib/gcj) as OpenJDK tended to be installed anyway due to the web plugin.

[1] AOT stands for Ahead-Of-Time. This refers to the static compilation of the program to produce native code which runs without the potential run-time performance hit imposed by JIT. JIT stands for Just-In-Time and refers to dynamic compilation of each method of a Java program immediately before execution. Although there are techniques to speed up JIT, by identifying "hot" frequently called methods and caching them (see http://en.wikipedia.org/wiki/HotSpot), in general it is believed to be sub-optimal for GUI-based programs.

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

Andrew Haley and Andrew Overholt expressed[3] skepticism that users would realize that they needed the gcj AOT-compiled code in order to get good performance. Andrew Overholt stated "one of the reasons we didn't do this to begin with was because RPM has no notion of Suggests or Recommends like dpkg does. Debian went this route, but I've seen reports of people not realizing they needed to install the associated -gcj package."

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

The advantages of maintaining both AOT and JIT compilation were argued[4] by Colin Walters. Among the reasons listed by Colin for keeping a JIT were: "many apps will continue to load code at runtime from sources that are not Fedora. Think unpackaged Eclipse plugins for just a start" and that "[a] JIT also has a lot more interesting information than a normal AOT model. Hotspot does a lot of cool things there." Colin suggested that "profile driven optimizations",based on work done in 2001 by JanHubicka (SuSE), Richard Henderson (Red Hat) and AndreasJaeger (SuSE), might be a way to improve the performance of JITted programs. On the other hand he recognized that AOT compilation was useful "because having Hotspot re-profile and recompile the Eclipse core on everyone's computer is a bit of a waste." Colin followed up[5] with a putative infrastructure plan involving modifying Koji to create a new repository of optimized versions of select applications and a YUM plugin which feeds HotSpot profile data from individuals back to a central server which in turn is used to further optimize the compilations. Jeff Spaleta wanted[6] to know if this new repository would be disabled by default. Toshio Kuratomi was concerned[7] that Koji should maintain its ability to create a precisely audited build.

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

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

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

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

Rawhide Network Breakage Due to Wireless Drivers

A puzzled Richard Jones asked[1] if anyone else had experienced bizarre networking failures apparently due to DNS lookup failures for web browsers but not for command line tools. Several confirmations were posted and Dan Williams warned[2] that "all mac80211-based drivers (b43, b43-legacy, iwl3945, iwl4965, ath5k, rt2x00)" were broken due to upstream patching of multiqueue functionality.

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

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

Ralf Etzinger asked[3] if failure to associate with an Access Point was one of those expected pieces of "random weirdness." In response to a follow-up question from Michael Solberg about a failure to associate using kernel-2.6.25.10-47.fc8 Dan added[4] that only Rawhide kernels should be affected.

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

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

Possible Slippage of Fedora 10 Alpha?

A brief note from Jesse Keating on Friday requested[1] an IRC meeting with spin owners, QA, Kernel and other concerned parties to discuss the problem that "split media"[2] was not working currently. As the Alpha release is scheduled[3] for August 5th it seems as though there is little time to solve this problem.

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

[2] The ability to break a set of RPM packages into media images to be used by anaconda during installation is a difficult one. Currently it is handled by the pungi module https://hosted.fedoraproject.org/pungi/wiki/PungiDocs/PungiDocs

[3] http://fedoraproject.org/wiki/Releases/10/Schedule

In an aside Jesse referred to the problem that the "Alphas" are currently hidden away from the general community and that he would like to address this at a subsequent ReleaseEngineering meeting.

Artwork

In this section, we cover the Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: Nicu Buculei

New Posters Needed for Fedora

Paul Frields asked[1] on @fedora-art-list about a new series of posters: "'Infinity / Freedom / Voice' has been a powerful message and an excellent way to characterize the themes that went into the Fedora logo. The logo has become a completely identifiable brand for us, and the original 'triptych' posters for these themes have allowed our brand to grow throughout the community. Now, it's time for us to build a revitalized message around the more concrete themes that characterize the entire Fedora Project as a whole."

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

Mairín Duffy came up[2] with a concept fitting one of the Fedora 10 theme proposals: "I'm wondering if this could be tied into the F10 artwork theme.... I've been sketching up some steampunky doodles lately. Maybe I'll do some along these lines. Here are some steampunk-inspired ideas" (following with a list of ideas[2]) and after receiving positive feedback even with a graphic sketch [3].

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

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

A T-shirt Design for the Upcoming FUDCon in Brno

Max Spevack asked[1] on @fedora-art-list for a T-shirt design for the Brno FUDCon: "Since you guys did such an awesome job on the FUDCon Boston shirts, I was wondering if you'd be willing to make a few mock-ups of what a FUDCon Brno shirt would look like. I like the idea of trying to have a bit of design consistency for each year's FUDCon shirts... so maybe we could keep the front the same (switching the name of course) and doing something 'similar' on the back?"

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

The request was quickly followed[2] by a design by Nicu Buculei using, as requested, the same template as the recent FUDCon in Boston, a design which is generally liked. The discuss touched[3] on a hunt for usable Brno photos and a number of pieces of technical advice[4] from Mairín Duffy about vectorizing photos.

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

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

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

The Blue Color of Fedora

Paul Frields started an interesting debate[1] about the dominant color used in Fedora graphics: "Does the Artwork team think, overall, that using a blue palette for our desktop theme (background) helps Fedora with its identity and branding? Do you want to continue that for Fedora 10?"

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

A large chorus of contributors to the Art Team expressed their support for using blue, one of the most convincing arguments came from Max Spevack[2]:"Blue = Fedora. Mix in some other stuff as appropriate, but I believe that Blue is now 'our' color. We shouldn't give that up. Ubuntu has brown, OpenSuse has green. Red Hat has red. We have blue. Personally, I like that we maintain that general blue-ish feel. Play with the shades if you like, mix in some spice and variety if you like, but I think Fedora should always be identifiable with the color blue."

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

Of course there are different opinions, like the one voiced[3] by David Nielsen: "As a user I would love to see us break free of the blue prison, it looks dated and should be put down with all manners of mercy possible. I think it hurts us to stick with the blue theme and unlike other competing distros not work towards a unified look over several cycles."

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

Security Advisories

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

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

Contributing Writer: David Nalley

Fedora 9 Security Advisories

Fedora 8 Security Advisories