From Fedora Project Wiki

< FWN‎ | Beats

(Don't know how the title got changed to Planet Fedora. Revert to my title.)
(fwn137 first pass)
Line 2: Line 2:
== Developments ==
== Developments ==


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


Contributing Writer: [[:User:OisinFeeley|Oisin Feeley]]
Contributing Writer: [[:User:OisinFeeley|Oisin Feeley]]


=== Erratum: FWN#133 "Shark" is a JIT not a VM ===
=== How Maintainers Can Help Reduce XULRunner Breakage ===


Gary Benson kindly corrected an error in FWN#133 "Java, So Many Free Choices"[1] which reported on the work being done by Red Hat engineers to expand the availability of a FOSS Java across more architectures. The gist of the correction is that ''Shark'' is not a Virtual Machine(VM) as stated in the article. Gary explained that ''OpenJDK'' is composed of a VM named ''HotSpot'' and a class library. ''HotSpot'' runs on a limited number of architectures and so there have been two independent attempts to increase VM coverage. One of these is pre-existing project named ''CACAO'' which is a VM whose maintainers are implementing the OpenJDK class interface. The other is a Red Hat initiative named ''zero'' to remove architecture-specific code from ''HotSpot'' in order to make compilation on diverse platforms easier. As ''zero'' is slow and in need of a JIT. This JIT could well end up being ''Shark''. Thanks to Gary for taking the time to clarify this point. We encourage readers to correct important technical issues and misunderstandings and can be contacted via "news@fedoraproject.org".
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 [[WillWoods|Will Woods]]. Will reported that a QA meeting involving [[ChristopherAillon|Christopher Aillon]] (caillon), as <code>Firefox/XULRunner</code> 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/Issue133#Java.2C_So_Many_Free_Choices
[1] http://fedoraproject.org/wiki/FWN/LatestIssue#XULRunner.Security.Update.Breakage.Stimulates.Bodhi.Discussion


=== New libraw1394 Rebuild Exposes Closed ACLs ===
[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01682.html


A simple warning made[1] by [[JarodWilson|Jarod Wilson]] of a soname bump of ''libraw1394'' (which among other things allows easy switching between juju and the older drivers) revealed that Fedora's KDE maintainers are not using open ACLs for their packages. The issue of whether open ACLs should be used to allow any interested community member (e.g. with a FAS account) to start making changes without bureaucracy has been visited several times on @fedora-devel and has been argued[1a] to be one of the exciting "post-merge" aspects of the FedoraProject. Objections have included those based on security (see FWN#112 "Open By Default: New FAS Groups Proposed"[1b]) and the logistics of co-ordinating such open access (see FWN#91 "Community Control And Documentation Of New Workflows"[1c]). At times it has appeared that those who were non-Red Hat employees and contributing to the pre-merge "Extras" repository were the strongest advocates for open ACLs.
The reason that some xulrunner-dependent packages were affected and others not was that ''xulrunner'' provides both a stable API <code>gecko-devel</code> and an unstable API <code>gecko-devel-unstable</code>. Will noted that <code>BuildRequires</code> of ''xulrunner-devel'' or ''xulrunner-devel-unstable'' should no longer be used and instead that gecko equivalents should replace them.


[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01159.html
Packages using the stable API were unaffected by the update of <code>xulrunner</code>. 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* <code>xulrunner</code> is updated." It was recommended that packages that used the stable API should use the following in their specfiles:<pre>
Requires: gecko-libs >= 1.9
BuildRequires: gecko-devel >= 1.9
</pre>
and that those using the unstable API should use:
<pre>
%define gecko_ver 1.9.0.1
Requires: gecko-libs = %{gecko_ver}
BuildRequires: gecko-devel-unstable = %{gecko_ver}
</pre>


[1a] http://lwn.net/Articles/237700/
Lastly an important request was made of package maintainers: "if your package uses the <code>-unstable</code> 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."


[1b] http://fedoraproject.org/wiki/FWN/Issue112#Open_By_Default:_New_FAS_Groups_Proposed
[[BradenMcDaniel|Braden McDaniel]] wondered[3] why the same headers, but with different pathnames, were provided by <code>xulrunner-devel-unstable</code> and <code>xulrunner-devel</code> and Ville-PekkaVainio had[4] the same question.


[1c] http://fedoraproject.org/wiki/FWN/Issue91#Community_Control_And_Documentation_Of_New_Workflows
[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01684.html


Jarod provided a short list of affected packages including ''kdebase'' and ''kdebase3'' and wondered whether he should "do a fancy chainbuild[2], or just let rawhide be busted for a day?" Following advice received[3] offlist he decided that the procedure would be to first bump and tag each of the packages, and then from within the devel-branch of a dependent package issue a: <pre>[jwilson foo fedora-cvs/pkg11/devel]$ make chain-build CHAIN="libraw1394 pkg1 ... pkg10"</pre>
In response to the suggested BuildRequires [[DouglasWarner|Douglas Warner]] requested[5] that a <code>Provides: gecko-libs-api = 1.9</code> be added to <code>xulrunner</code> so that dependent packages would break if <code>xulrunner</code> were bumped to a new version which was not compatible: "For example, I can't do: <code>Requires: gecko-libs < 2.0</code> Because I'm not guaranteed that the next version will *be* 2.0 (it might be 1.10, for example)." [[RexDieter|Rex Dieter]] independently came[6] to the same conclusion. [[DenisLeroy|Denis Leroy]] begged[7] that <code>xulrunner</code> 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 <code>xulrunner</code> would fail a standard Fedora package review.


[2] http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Chained.builds
[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01686.html


[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01161.html
=== NEVR Again ===


This eventually worked[4], but first Jarod had to contact maintainers that disallowed commit access using open ACLs and get them to do the bump and tag in order to use the above method.
Another report detailing broken upgrade paths was posted[1] by [[JesseKeating|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.


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


Early on in the chain of events [[KevinKoffler|Kevin Koffler]] noted[5] the necessity to do this for the KDE packages. "Drago01" wondered why there were closed ACLs to which [[RexDieter|Rex Dieter]] replied[6] that it was not necessary for non-core development platform bits and he would try to change the ACLs for them. [[KonradMeyer|Konrad Meyer]] defended[7] the choice on the basis that "KDE is a major system component and the KDE team (which is something like 6-8 people) does a very good job of fixing things as soon as they need fixing." Further probing for an actual reason by [[RahulSundaram|Rahul Sundaram]] resulted in Konrad stating[8] that it was necessary to prevent people from making mistakes and that the <code>kernel</code> package was handled similarly. Rahul was unconvinced by this and [[JonStanley|Jon Stanley]] agreed[9] it should be possible, as with GNOME, to use open ACLs to allow anyone to help.
[2] http://fedoraproject.org/wiki/FWN/LatestIssue#Broken.Upgrade.Paths.Due.to.NEVR


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


[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01192.html
[[StephenWarren|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 [[KevinKofler|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.


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


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


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


=== XULRunner Security Update Breakage Stimulates Bodhi Discussion ===
[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01553.html


After [[MichaelSchwendt|Michael Schwendt]] published[1] a summary of broken dependencies for Fedora 9 it was noticed[2] by [[MartinSourada|Martin Sourada]] that most of the problems were due to a recent update of ''xulrunner'' which now provides ''gecko-libs'' (see FWN#110[3].) Martin discovered that ''gxine'', which was his particular responsibility, did not depend on a specific version of ''gecko-libs'' and thus removed the versioned dependencies. He suggested that a review by carried out of the other affected packages to determine whether this was also the case for them.
The possibility that simultaneous updates would be released to all branches was discussed[8] by [[KevinKofler|Kevin Kofler]] and [[JesseKeating|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.


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


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


[3] http://fedoraproject.org/wiki/FWN/Issue110#Gecko-libs.Now.Provided.By.Xulrunnerdevel
[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01595.html


Martin was further concerned that the policies for pushing security updates for a stable release be examined in the light of this particular case because it would fail to install due to all the broken dependencies. He suggested that it ought to be possible to use chain builds (the Koji buildsystem allows packages to be grouped into sets during the build process and to only report success if all the packages complete perfectly) to ensure that such breakage does not occur. He also wondered why the security update was not mentioned on the "-devel(-announce) list?"
[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01685.html


[[NicolasMailhot|Nicolas Mailhot]] agreed[4] strongly wondering: "why the hell is this stuff not tested in -devel first? [...] When the update process is not streamlined in -devel, it's no surprise it bombs in -stable when security updates are due." The answers to these questions came from [[AdelGadllah|Adel Gadllah]] (drago01) who replied[5] that as it was a security fix it had to go to updates-stable immediately instead of following the normal procedure[6]. [[DavidNielsen|David Nielsen]] interjected[7] that this method did not deliver a quick security fix because those using, for example, ''epiphany'' failed to get the update because the dependencies had not been properly handled. [[MichaelSchwendt|Michael Schwendt]] also made[8] the same point: "Doesn't matter. It doesn't install at all if it breaks dependencies of *installed* packages. Not even *skip-broken helps in that case." Adel clarified[9] that he was explaining "why it was done, not that it was the right thing to do. As I already said, bodhi should block updates that break deps."
[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01728.html


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


[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01183.html
=== Slimming Down Java by Sub-Packaging AOT ===


[6] Generally bleeding-edge changes for the next version of Fedora are published in the "fedora-rawhide" repository, which is derived from a CVS branch named "-devel". The "fedora-updatestesting" repository contains bleeding edge changes for the current maintained release, the idea being that volunteers will test them and provide feedback before they are pushed to the "fedora-updates" repository for general consumption.
A request to separate out the AOT[1] parts of Java packages into sub-packages was made[2] by [[CaolanMcNamara|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.


[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01184.html
[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.


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


[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01188.html
[[AndrewHaley|Andrew Haley]] and [[AndrewOverholt|Andrew Overholt]] expressed[3] skepticism that users would realize that they needed the ''gcj'' AOT-compiled code in order to get good performance. [[AndrewOverholt|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."


=== Broken Upgrade Paths Due to NEVR ===
[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01769.html


A report listing packages which failed to upgrade smoothly was emailed[1] to the list on Mon 21st. This would appear[2] to be the output of [[JesseKeating|Jesse Keating]]'s revamped version of the old Extras script ''upgradecheck'' (previously discussed in FWN#108 "Package EVR Problems"[3]) which examines Koji tags[4] to determine whether upgrades from one package version to another will work.
The advantages of maintaining both AOT and JIT compilation were argued[4] by [[ColinWalters|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), [[RichardHenderson|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. [[JeffSpaleta|Jeff Spaleta]] wanted[6] to know if this new repository would be disabled by default. [[ToshioKuratomi|Toshio Kuratomi]] was concerned[7] that Koji should maintain its ability to create a precisely audited build.


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


[2] http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/check-upgradepaths.py;hb=HEAD
[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01775.html


[3] http://fedoraproject.org/wiki/FWN/Issue108#Package.EVR.Problems
[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01792.html


[4] http://fedoraproject.org/wiki/Koji
[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01795.html


[[MichaelSchwendt|Michael Schwendt]] noticed[5] that at least one reported failure, of ''audacity'' to upgrade from "dist-f8-updates-testing" to "dist-f9-updates" was a false positive because it omitted to take the possible intermediate tag "dist-f9-updates-testing" into account. [[JesseKeating|Jesse Keating]] pondered[6] the idea and while admitting the possibility that someone might "at one time [have] installed F8 testing updates, and then upgraded to F9 + updates, but without F9 updates-testing. However, it's more plausible that if they were using updates-testing on F8 that they would upgrade to F9 + updates + updates-testing." He suggested that he would break the testing down into two separate paths: "F8, F8-updates, f9-updates" and "F8-updates-testing, F9-updates-testing" and also list the person that built the broken instance instead of listing the owners of the broken packages.
=== Rawhide Network Breakage Due to Wireless Drivers ===


[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01296.html
A puzzled [[RichardJones|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 [[DanWilliams | 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


[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01317.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01801.html
 
[[RalfEtzinger | 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 [[MichaelSolberg|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.


As the owner can change per branch [[MichaelSchwendt|Michael Schwendt]] suggested that the ''pkgdb'' could be queried for branch-specific ownership data, but Jesse thought that it was more interesting to know who built the package rather than who owned it. He hoped that "the <pkg>-contact fedoraproject org or some such gets created soon so that the script can just email that + the person whom built the problematic package" and [[SethVidal|Seth Vidal]] quickly implemented[7] this after [[ToshioKuratomi|Toshio Kuratomi]] made some changes to ''pkgdb''.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00000.html


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


=== Application Installer "Amber" Provides Browser Interface to Packages ===
=== Possible Slippage of Fedora 10 Alpha? ===


A description was posted[1] by [[OwenTaylor|Owen Taylor]] of a visual means to rate, browse and install packaged applications in a repository. The discussion around this revealed some differences over the advisability of providing separate ways for ordinary end-users on the one hand and package maintainers on the other to discover and discuss the software available from the FedoraProject. Owen's post was to announce that he had hacked up a web-browser plugin (a detailed README is available[2] which includes discussion of security and cross-browser support) which used PackageKit to allow the installation of packages selected from this website. He had hopes that this would be "robust against inter-distro differences in package names" and wondered "[w]hat do people think... does this make sense as part of the PackageKit project?"
A brief note from [[JesseKeating|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-July/msg01433.html


[2] http://git.o/shsoup.net/cgit/packagekit-plugin/tree/README
[1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00005.html


Following a suggestion from [[TomCallaway|Tom Callaway]] that it be integrated with PackageDB (this is the central repository of meta-information on packages and is currently targeted to the needs of package maintainers and release-engineering[3] to track ownership and ACLs[4]) there were questions from [[JeffSpaleta|Jeff Spaleta]] about what that meant. Owen replied[5] with more detail, and explained that the web application would take information from PackageDB but that the plugin would use PackageKit (and YUM and hence ''comps.xml'') to display actual installable packages. He listed other possible operations beyond simple installation of packages. It would be possible to offer installation to any anonymous user, but after authentication rating and commenting on packages could be authorized for users in the FAS[6] class. Similarly, the ability to edit package information could be authorized for package owners.
[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] https://admin.fedoraproject.org/pkgdb
[3] http://fedoraproject.org/wiki/Releases/10/Schedule


[4] https://fedorahosted.org/packagedb/
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.
 
[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01440.html
 
[6] https://admin.fedoraproject.org/accounts/
 
Jeff emphasized[7] that he would prefer to see Owen's interface replace, or augment, the existing PackageDB one[8] in order to increase user-maintainer communication by simplifying and reducing the number of interfaces. [[BillNottingham|Bill Nottingham]] wondered[9] "Does anyone actually use packagedb to browse for available software?" and although there were a couple of affirmative replies there was no aggregate data presented to answer this question. [[NicolasMailhot|Nicolas Mailhot]] replied[10] with some possible uses for expanded meta-information based upon the experience of the Fonts SIG.
 
[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01442.html
 
[8] https://admin.fedoraproject.org/pkgdb
 
[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01445.html
 
[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01474.html
 
[[RobinNorwood|Robin Norwood]] explained[11] to Jeff that the PackageDB was for one audience "(mostly) targeted at people interested in the plumbing of Fedora" while the new interface was "targeted at people who are looking for applications to install and 'do stuff' with." He posted[12] a link to the Feature page for this ApplicationInstaller. Work seems to have progressed quite far with both the web-application side, which is tentatively named "Amber" and is available for proof-of-concept testing[13] and also with Owen's plugin.
 
[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01460.html
 
[12] http://fedoraproject.org/wiki/Features/ApplicationInstaller
 
[13] http://publictest10.fedoraproject.org/amber
 
Jeff re-iterated[14] his point that "driving users to a different site than the package maintainers... and allowing them to comment [is] going to cause a communication gap" and characterized this as "driveby commenting and rating." [[MatthiasClasen|Matthias Clasen]] did not accept that the use cases and requirements were the same as those for PackageDB and argued that "[t]his is not an effort to improve package quality or gain new contributors. This is an effort to make life of users better. It is not about packages, but about applications." Robin was[15] against Jeff's idea of a "monolithic app" and emphasized that he was using existing infrastructure to provide a new interface and also planning easy export of the data. He envisioned this data as providing, for example, a feed of comments about each package to PackageDB: "More of a semantic web type idea than an isolated database or a 'one-stop shop'."
 
[14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01472.html
 
[15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01481.html
 
=== RPM Inspires Intel Moblin2 Shift From Ubuntu ===
 
An excited [[PeterRobinson|Peter Robinson]] copied[1] a link to "The Register" to the list. The article claimed that Intel's next version of "Moblin"[2] (cunningly codenamed Moblin2) would be replacing the "Ubuntu-based kernel" with the Fedora kernel and cited Dirk Hohndel. Specifically it attributed a desire to "move to Fedora [as] a technical decision based on the desire to adopt RPM for package management [and also that] having a vibrant community push is the winning factor." The article has since been rebuffed[3] by Hohndel in a comment on one of his blogs as "not only low on detail, it's also high in content that's made up or blown out of proportion" but he does confirm that "we decided to move to an rpm based distribution as that gave us better build tools and most importantly a better way to manage the licenses under which the individual packages are released."
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01381.html
 
[2] Moblin is a GNU/Linux-based software stack for Mobile Internet Devices which includes Xorg,GStreamer,ALSA,the MatchboxWM, GTK, Cairo, Pango, D-Bus, Avahi, Evolution Data Server and more. In order to make life easy for developers a Moblin Image Creator makes it easy to create a small 350-600MB binary image for a particular architecture. Moblin explicitly aims to provide an alternative to GNOME and KDE. http://www.moblin.org/resource.center.php
 
[3] http://www.hohndel.org/communitymatters/moblin/moblin-at-oscon/
 
Commentary on @fedora-devel tended to cautious optimism mixed with a desire for a lot more information. [[JeffSpaleta|Jeff Spaleta]] asked[4] whether the idea was to have Moblin2 be a "part of the larger Fedora project or is it going to be a downstream derived distribution that will include components such that it can not carry the Fedora name?" and broached the idea that Moblin2 might be a candidate for a Secondary Architecture (see FWN#90[5] and FWN#92[6].) [[DavidWoodhouse]] (posting with an Intel.com sig) also liked[7] the idea of a Moblin2 SIG producing a Fedora spin for MIDs (Mobile Internet Devices.)
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01386.html
 
[5] http://fedoraproject.org/wiki/FWN/Issue90#Fedora.Secondary.Architectures.Proposal
 
[6] http://fedoraproject.org/wiki/FWN/Issue92#Secondary.Arch.Proposal.Cont
 
[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01417.html
 
While "yersinia" thought that the emphasis on RPM was interesting [[HansdeGoede|Hansde Goede]] was intrigued[8] by the emphasis on community activity. Hans suggested that [[JeffSpaleta|Jeff Spaleta]] contact Dirk Hohndel to emphasize the dynamic nature of the FOSS community behind Fedora. Jeff suggested that [[KarstenWade|Karsten Wade]] could meet with Dirk at this week's OSCON[9]. Ex-Red Hat star employee Arjanvande Ven volunteered[10] to do what he could to help make contact with Dirk, describing himself as "on the other side of a cube wall" from him. In response to [[RahulSundaram|Rahul Sundaram]]'s request for concrete information from Intel Arjan responded[11] that he would do his best to get the right people to make contact, but that much of the speculation on @fedora-devel concerned topics which have an "eh we don't know yet" answer. He also repeated cautions against believing anything which journalists write.
 
[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01397.html
 
[9] http://en.oreilly.com/oscon2008/public/content/home
 
[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01447.html
 
[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01523.html
 
[[PaulFrields|Paul Frields]] followed up[12] with details of a meeting at OSCON with senior Fedora hackers. It seemed that the ability to use OpenSuSE's Open Build System (which is based on RPM) was one of the main motivations behind Intel's move. Apparently ''Koji'' (the Fedora Project's buildsystem) lacks some specific functionality. Discussion between [[PaulFrields|Paul Frields]] and [[JeffSpaleta|Jeff Spaleta]] centered[13] around whether the apparent Moblin2 plan of acting as a downstream derivative of the Fedora kernel would allow them to garner community contributions and whether this mattered anyway given Intel's vast resources.
 
[12] http://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00198.html
 
[13] http://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00214.html
 
[[ArthurPemberton|Arthur Pemberton]] thought that this was a good opportunity to take on some of the anti-RPM and anti-YUM misinformation which had been spread about. [[DavidNielsen|David Nielsen]] thought it was best to merely demand proof from those spreading FUD. [[SethVidal|Seth Vidal]] conceded[14] that perhaps not enough had been done to publicize the improvements in YUM and RPM over the last few years and cited[15] a particular case-study of a ''smartpm'' user comparing it with ''YUM'' to the advantage of the latter.
 
[14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01503.html
 
[15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01507.html

Revision as of 00:10, 2 August 2008

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.

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Developments&oldid=42875"