FWN/Beats/Developments

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[2a], 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

[2a] http://en.wikipedia.org/wiki/HotSpot

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.