FWN/Beats/Developments

Planet Fedora

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

Contributing Writer: Oisin Feeley

Erratum: FWN#133 "Shark" is a JIT not a VM

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 named cacao and while it was a promising project it was uncertain how well it would work. The other is a Red Hat initiative to explicitly port HotSpot to more architectures by providing an interpreter named zero. As zero is solely an interpreter it 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".

[1] http://fedoraproject.org/wiki/FWN/Issue133#Java.2C_So_Many_Free_Choices

New libraw1394 Rebuild Exposes Closed ACLs

A simple warning made[1] by 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.

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

[1a] http://lwn.net/Articles/237700/

[1b] http://fedoraproject.org/wiki/FWN/Issue112#Open_By_Default:_New_FAS_Groups_Proposed

[1c] http://fedoraproject.org/wiki/FWN/Issue91#Community_Control_And_Documentation_Of_New_Workflows

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:

[jwilson foo fedora-cvs/pkg11/devel]$ make chain-build CHAIN="libraw1394 pkg1 ... pkg10"

[2] http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Chained.builds

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

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.

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

Early on in the chain of events Kevin Koffler noted[5] the necessity to do this for the KDE packages. "Drago01" wondered why there were closed ACLs to which 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. 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 Rahul Sundaram resulted in Konrad stating[8] that it was necessary to prevent people from making mistakes and that the kernel package was handled similarly. Rahul was unconvinced by this and Jon Stanley agreed[9] it should be possible, as with GNOME, to use open ACLs to allow anyone to help.

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

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

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

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

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

XULRunner Security Update Breakage Stimulates Bodhi Discussion

After Michael Schwendt published[1] a summary of broken dependencies for Fedora 9 it was noticed[2] by 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.

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

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

[3] http://fedoraproject.org/wiki/FWN/Issue110#Gecko-libs.Now.Provided.By.Xulrunnerdevel

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?"

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 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]. 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. 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."

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

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

[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.

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

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

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

Broken Upgrade Paths Due to NEVR

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's revamped version of the old Extras script upgradecheck script (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.

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

[2] http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/check-upgradepaths.py;hb=HEAD

[3] http://fedoraproject.org/wiki/FWN/Issue108#Package.EVR.Problems

[4] http://fedoraproject.org/wiki/Koji

MichaelSchwendt 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 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.

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

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

As the owner can change per branch MichaelSchwendt 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 quickly implemented[7] this after ToshioKuratomi made some changes to pkgdb.

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

Application Installer "Amber" Provides Browser Interface to Packages

A description was posted[1] by OwenTaylor 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?"

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

[2] http://git.o/shsoup.net/cgit/packagekit-plugin/tree/README

Following a suggestion from TomCallaway 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 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.

[3] https://admin.fedoraproject.org/pkgdb

[4] https://fedorahosted.org/packagedb/

[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 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 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 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 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 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 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 was intrigued[8] by the emphasis on community activity. Hans suggested that JeffSpaleta contact DirkHohndel to emphasize the dynamic nature of the FOSS community behind Fedora. Jeff suggested that KarstenWade could meet with Dirk at this week's OSCON[9]. Ex-Red Hat star employee ArjanvandeVen 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'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 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 and JeffSpaleta 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 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 thought it was best to merely demand proof from those spreading FUD. SethVidal 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