From Fedora Project Wiki

< FWN

Fedora Weekly News Issue 138

Welcome to Fedora Weekly News Issue 138 for the week ending August 11, 2008.

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

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

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

Developments

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

Contributing Writer: Oisin Feeley

Solving the Unsynchronized Release of Package Dependencies

A problem often experienced by users of "add-on" packages[1] is that dependency resolution will fail during a simple yum update when the official Fedora repositories release an update to the base packages on which these add-ons depend. ThorstenLeemhuis explained[2] that as add-on packages have a strict dependency on the base packages for which they were built and updates are not available at exactly the same time on all mirrors there is no ideal point in time for the add-on to be released. Thorsten's RFC was careful to point out that the problem did not only affect kmods, but also plugins for audacious, xine and k3b and that the resulting dependency resolution failures occurred both when the add-on was visible to yum before the base package and vice versa. The two possible solutions envisioned by Thorsten included either yum being modified "to be taught to do a second look at the right place to find what's needed" or the third-party repositories to include the updated base packages along with the updated add-on. Thorsten feared that this latter option of "shipping non-free kernel modules and the GPLed kernels in one repo might [make] some people yell license violation."

[1] Such packages are hosted by "third-party" repositories, which are run independently of the Fedora Project. The packages, while highly useful for many Fedora users, are deemed to be legally non-distributable due to the laws of the U.S.A.

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

A report of daily failures of this type occurring for Rawhide without any complicating third-party repository was posted[3] by John Ellson. He gave two examples from his current machine. The first was a missing dependency error: 

$ yum update phonon*
Error: Missing Dependency: phonon = 4.2.0-1.fc10 is needed by package phonon-backend-gstreamer-4.2.0-1.fc10.x86.64 (installed)

and the second was a file conflict error: 

$ yum update digikam*
Transaction Check Error: file /usr/share/icons/oxygen/128x128/apps/digikam.png from install of digikam-0.10.0-0.1.beta2.fc10.x86.64 conflicts with file from package oxygen-icon-theme-4.1.0-1.fc10.noarch

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

John wished that yum would skip updating all rpms which produce conflicts with currently installed rpms whether or not they are third-party or otherwise, especially as neither of these issues had been flagged in the appropriately dated "Rawhide report". A good deal of the remainder of thread was devoted to replying to this post instead of to Thorsten's RFC. The first response came[4] from MichaelSchwendt and made the point that the first error was probably due to an incorrect "Obsoletes" tag in the phonon-backend-gst that is supposed to replace phonon-backend-gstreamer. The script which checks for broken dependencies in Rawhide cannot detect this as the phonon-backend-gstreamer is not visible to it. Michael addressed the second error with the point that conflicts are entirely different from dependency issues and are not checked. RexDieter, as package maintainer, quickly fixed both of the problems and in doing so demonstrated that users filing bug reports can be an effective part of the current process. Thorsten also emphasized[5] that the two errors posted by JohnEllson were entirely different from each other and that the conflict was a bug best dealt with by user reports. He further argued that it was impossible for the Rawhide dependency checker script to examine the contents of users' hard disks. All that the script can do is examine the current contents of Rawhide and as the phonon-backend-gstreamer was long gone it could not test a theoretical update from it. Michael Schwendt later added[6] that although his own "repoclosure" script developed for the old "Extras" repository had been able to take account of "obsolete binary [packages] from the previous compose [...] because in Extras we've had up to two pkg releases in the repo[sitory ...] the Rawhide report is like a fresh install of only the latest [package] releases, and one can only hope that there are enough testers who find and report the additional update/upgrade problems." Michael claimed[7] that as the FedoraProject policy on file conflicts was "half-hearted" he was uninterested in shouldering the burden of running the script himself. He also noted that Florian La Roche had a script for determining conflicts between files and symlinks.

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

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

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

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

During this discussion JohnEllson was unimpressed[8] with the theoretical reasons as to why he was seeing these problems and requested that even if it were not possible to do such checks on the server "[j]ust have yum on the client recover gracefully from these and skip over them."

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

Similarly David Timms wondered[9] if the original problem stated in the RFC could be solved by using the yum option --skip-broken if it were made to select only those packages which were: available, non-conflicting, non-dependency-breaking and actually downloadable.Thorsten restated[10] his belief that this was effectively hiding the problem instead of fixing it and would result in users being unaware that important updates were blocked solely due to a manually installed problem RPM. Instead he suggested setting a window of time during which updates with broken dependencies would be ignored and then finally reported as errors. Seth Vidal corrected[11] the impression that "skip broken" was a plugin to yum (it is now a core option) and while agreeing that "a tool to detect all these issues is worth discussing, not sure how we catch all possible conflicts, though" seemed to confuse Thorsten's window of time with checking the actual package creation filestamp. JesseKeating also appeared[12] to fall prey to this confusion and like Seth pointed out the problem of queued packages sitting in repositories before being released. To clear this confusion up Thorsten posted[13] a more detailed explanation which emphasized that the times being examined were relative to the client-side's first encountering of the problem and made no reference to the build-date or publication date of the package itself. The advantage of Thorsten's seventy-two hour window scheme is that it gives packagers a grace period in which to correct the problem and at the end of that the same situation prevails as now, namely that the update will fail and users will notice and report the errors.

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

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

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

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

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

Firefox Mouse Woes

MarkG reported[1] that Firefox did not respond to the scroll wheel on GNU/Linux in the same way in which it did on Microsoft Windows. He had intended to file a bugzilla report, but due to the outage (see this same FWN#138 "Bugzilla Overhauled") was merely posting to @fedora-devel. The basic point made in what MarkG chose to frame as an RFC was that he expected the middle mouse button when clicked to allow him to scroll the page but that "[w]hen you press it on linux in firefox you get ... nothing[.]" He suggested that a simple change of thefirefox-fedora-default-prefs.js to pref("general.autoScroll", true); by the Fedora maintainer would achieve this goal and noted that currently it is possible for a user to achieve the same end by navigating to the URI about: config and filtering general.autoScroll and changing its boolean to "true". MarkG also noted in support of his argument that "Ubuntu" had made such a change.

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

A correction was made[2] by Ignacio Vazquez-Abrams to the effect that clicking the middle mouse button brought one to the "URL stored in the clipboard." He also pointed out that the environment in which the middle-click was made was important and that Firefox was doing the correct thing by following the Windows' environment preference of autoscrolling and the *nix environment preference of pasting from the clipboard. At this point the thread should probably have stopped but instead descended into a morass of personal preferences and insults. Nevertheless there were a couple of points worth noting.

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

Naheem Zaffar thought[3] that while pasting was well and good it was not so nice to have the pasted URL automatically replacing the current page. Rui Miguel Silva Seabra provided[4] a fix for this with

about:config -> browser.tabs.opentabfor.middleClick.

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

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

A type of closure to the thread was obtained when Todd Zullinger posted[5] that a likely result of making such changes would merely be to "get the opposite RFC from anyone who is used to the *nix behavior and wonders why Firefox is scrolling instead of pasting the clipboard contents as we'd expect. :)" and he speculated that "Ubuntu" had diverged from upstream.

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

Bugzilla Overhauled

As commented in several threads this week (e.g. this FWN#138 "Firefox Mouse Woes") Bugzilla was down for maintenance. This was due to upgrades of the OS on the servers and a move from the venerable bugzilla-2.18 to bugzilla-3.2. The original announcement[1] was posted on several lists and detailed the planned outage and the changes to bugzilla which included user-interface enhancements, AJAX optimizations for searching and displaying bugs and an XMLRPC API.

[1] http://www.mail-archive.com/fedora-announce-list@redhat.com/msg01372.html

The announcement and the reminder[2] that this would all happen on 2nd August requested that those using the API pointed their scripts to the test server https://partner-bugzilla.redhat.com to ensure that the new system was indeed backwards compatible.

[2] http://www.mail-archive.com/fedora-devel-announce@redhat.com/msg00194.html

A brief thread on @fedora-devel was started[3] when Gilboa Davara noticed that attempting to file a bug resulted in the JavaScript hanging and Firefox offering to retry or stop the script. This experience was confirmed by several other posters who noted that hitting "Continue" and waiting seemed to work. Paul Frields speculated[4] that it was the population of the component list which was slow.

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

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

Feature Proposal: Provers

An interesting proposal to include a bunch of tools for automated theorem proving was mooted[1] by David A. Wheeler. The bundle of tools, listed in David's post, would ease the task of increasing the reliability of software in some specific cases and are often used (see paper by David[2]) to perform assurance for safety and security on other programs. David argued that these tools, which are variously Formal Methods Tools, Key Provers and Solvers should be considered as a "Feature" for Fedora 10 as they needed some integration and had not previously been packaged for Fedora. Some of the methods enabled by these tools are being used by the OpenSuSE distribution to speed up dependency solving of RPM packages.

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

[2] http://www.dwheeler.com/essays/high-assurance-Floss.html

Jarod Wilson was uncertain[3] that the case for calling "just a collection of new packages" a Feature had been made. After further support from Patrice Dumas, Casey Dahlin and Paul Frields an explanation was posted[4] by Toshio Kuratomi that the determination is made in part by the presentation of why and how some packages are useful to a hypothetical end user: "just saying Fedora has a collection of provers isn't a Feature. But saying, in Fedora 10 we've made an effort to include foo, bar, baz important provers for Target Audience so they can find all the tools they need to do X Type of Work. Similarly, `We've done work so that foo and bar can import and export the same file format', or other work to show how we're making the user experience better would make a stronger case for a feature." Similarly Jarod provided[5] links to the Fedora Project wiki to support his case that not enough had been done to explain why the programs were a cohesive collection dedicated to a particular end use case although he admitted "I suppose perhaps this falls under "noteworthy enough to call out in the release notes", depending on who you ask. I'm still not sold yet."

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

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

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

Rahul Sundaram wanted[6] a classification of packaging difficulty added as he had examined several on the package wishlist and found them "a large amount of pain to package." Vasile Gaburici suggested calling the packages "Theorem Proving Tools" in order to broaden the category a bit. He also suggested[7] including gap and twelf. Suggestions to include other packages were forthcoming from Miles Savin for Agda2 and Richard Jones for CIL, a C-parser and static-analysis tool. Richard included a link[8] to a nice analysis of libvirt performed with CIL. Andrew Overholt noted[9] that sat4j was already packaged in Fedora.

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

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

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

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

rpmgrok Announced

Red Hat's David Malcolm announced[1] rpmgrok, a web-based tool to allow users to track program information across an entire distribution, yet without having a complete install tree. The tracked information includes all symbols in binaries, RPM manifests, shared objects, meta-information about rpms and more. He pointed interested parties to his test prototype[2].

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

[2] http://publictest7.fedoraproject.org/rpmgrok

All this information is obtained by analyzing the actually built rpms and storing the results in a database. David requested that anyone interested in coding, sysadmin and UI design get involved and provided a link to the git repository and the information that it was built upon TurboGears and SQLAlchemy.

Enthusiasm for the "Errors and warnings from rpmlint" was expressed[3] by Axel Thimm because he could imagine that someone that's say an expert on "invalid-desktopfile" issues could now dig into this much easier. Very nice!", but upon further feedback[4] from Mamoru Tasaka and Ville Skyttä it appeared that some work needed to be done to ensure that rpmlint was being used correctly. In any case this looks like a very promising and useful tool.

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

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

Infrastructure

This section contains the discussion happening on the fedora-infrastructure-list

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: HuzaifaSidhpurwala

static F10 Alpha relnotes page

Karsten Wade writes for fedora-infrastructure-list [1]

Karsten proposed that we turn [2] static. People should also be able to edit that page. Perhaps as part of making it static we can tell people to post changes to the talk page, then we'll do irregular updates of the static content?


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

[2] Releases/10/Alpha/ReleaseNotes

Photo gallery

Nicu Buculei writes for fedora-infrastructure-list [3]

The Art team decided to start collecting photos which can be used as desktop wallpapers, make a best-of-breed selection and create one or more packages. The easiest way is to add all of them to the wiki. However Nicu proposed that we use a better solution, either a gallery plug-in for trac or a stand alone gallery or something like that.

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

FAS authentication for Red Hat bugzilla

Rahul Sundaram writes for fedora-infrastructure-list [4]

Rahul asked if configuring FAS Auth for Red Hat bugzilla was possible. At which Mike replies saying that it was not our call, and Red Hat will need to decide that.

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

RFC: script to run sqlalchemy migrations on the db

Toshio Kuratomi writes for fedora-infrastructure-list [5]

FAS started using the python-migrate package to update its db. This is a good thing for third-parties that want to install their own FAS server as it lets us ship the database changes in a way that is easy for those users to apply to their own production databases.

However, it doesn't work very well in our particular environment because we're a bit more strict about our permissions than the migrate authors envision. In order to perform migrations, you need to have a user that can modify the schema for the db. This is either the owner of the db or the superuser. In our setup, we create the db with the superuser and then run our web apps with another user. This prevents the normal web app from modifying the db schema. Toshio proposed a couple of solutions to this.

[5] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00059.html

Artwork

In this section, we cover the Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: Nicu Buculei

Web banner for FUDCon Brno

[PaulFrields] asked[1] on the Fedora Art list for a web banner "Red Hat Europe has agreed to put up a banner for Fedora, advertising the upcoming FUDCon Brno", request which is followed by two proposals, one [2] by NicuBuculei and another [3] from VaraPrasadPepakayala. One design is choosen and its quicly featured on the Red Hat Europe website[4].

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

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

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

[4] http://www.europe.redhat.com/

Photographic wallpapers

An interesting question and offer[1] from BobPeterson about using photos as background images: "I like the 'blue' themes that Fedora has traditionally chosen, but I was wondering if Fedora could have a photo for its main background screen. As an amateur photographer, I have several 'scenery' photos I've taken that may be suitable, and I'm willing to donate".

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

As the general opinion converged over the idea that probably abstract images work better as a default but a collection of additional photographic wallpapers is useful, MartinSourada stepped-up[2] and created a preliminary gallery inside the wiki[3], which was quickly populated with a few images[4] by [[NicuBuculei] "to break the ice, start the ball rolling, provide an incentive and show how to use the gallery tag".

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

[3] Artwork/Wallpaper_Extras

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

The discussion covered licensing aspects[5], good practices about preparing wallpaper images[6] and also spawned a follow-up on the infrastructure list[7] about the best way of implementing the gallery, with a Gallery2 instance, proposed by JeffreyOllie looking as the most promising option.

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

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

[7] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00028.html

[8] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00029.html

First Nodoka 0.8 screenshots

MartinSourada posted[1] a status update of the development for the Nodoka theme, including a number of screenshots illustrating its current state.

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

[2] https://fedorahosted.org/nodoka/wiki/Screenshots#a0.7.80.0git9a0f383

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

Virtualization

In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies.

Contributing Writer: Dale Bewley

Enterprise Management Tools List

This section contains the discussion happening on the et-mgmt-tools list

Virt-manager Support for Storage Pool API

Cole Robinson posted[1] three patches (not to mention screen shots) which add support for the storage pool API to the virt-manager GUI.

[1] https://www.redhat.com/archives/et-mgmt-tools/2008-August/msg00066.html

Virt-mem Tools 0.2.8 Released

Richard W.M. Jones announced[1] the release of virt-mem 0.2.8. Virt-mem provides a set of dom0 or host tools which leverage libvirt to facilitate the inspection of domU or guest kernel information. Commands include 'virt-uname', 'virt-ps', and 'virt-dmesg' for example.

This latest version has been reworked to have direct access to basically any kernel structure. This will allow a more rapid fullfillment of outstanding feature requests such as memory usage information, network interface listings, etc.

[1] https://www.redhat.com/archives/et-mgmt-tools/2008-August/msg00033.html

Fedora Xen List

This section contains the discussion happening on the fedora-xen list.

Installing Fedora 9 Guest on Centos 5 Fails

Kenneth Tanzer had trouble[1] installing a Fedora 9 paravirtualized guest on a CentOs 5 host. Eventually the install hung on installing openoffice.org-writer2latex. David Hláčik reported[2] a kernel panic during the same scenario. He stated it was due to the Fedora 9 kernel-xen having newer features which the CentOs dom0 did not support. However, Mark McLoughlin said[3] RHEL5/CentOS Xen is expected to be able to run pv_ops kernels, and a bug should be filed if this isn't the case.

[1] https://www.redhat.com/archives/fedora-xen/2008-August/msg00011.html

[2] https://www.redhat.com/archives/fedora-xen/2008-August/msg00013.html

[3] https://www.redhat.com/archives/fedora-xen/2008-August/msg00018.html

Libvirt List

This section contains the discussion happening on the libvir-list.

sVirt project to Integrate SELinux and Linux-based Virtualization

James Morris announced[1] the formation of the sVirt project with the goal to be able to apply distinct security labels to individual VM instances and their resources, so that they can be isolated from each other via MAC policy.

[1] https://www.redhat.com/archives/libvir-list/2008-August/msg00255.html

Libvirt and Persistent Iptables Rules

Daniel Berrange responded[1] to a networking problem by pointing out that libvirt will automatically setup the correct iptables rules to allow outbound NAT based connectivity for guest VMs and that restarting the iptables service will erase these rules.

[1] https://www.redhat.com/archives/libvir-list/2008-July/msg00508.html

David Lutterkort hoped[2] this was a temporary situation due to the confusion it can cause. Mark McLoughlin confirmed[3] there is a RFE (bug 227011) to enable libvirt to persistently register iptables rules, but was depressed that a resulting fix would be Fedora specific.

[2] https://www.redhat.com/archives/libvir-list/2008-August/msg00098.html

[3] https://www.redhat.com/archives/libvir-list/2008-August/msg00193.html

Network XML Configuration Options

To support a complex virtual network with 3 DMZs, Didier Ayllon asked[1] if it is possible to specify options such as default gateway, static routes, DNS options in the network config.

Daniel Berrange pointed[2] out libvirt networking "is designed specifically to only provide 3 types of networking, an isolated network, a NAT based network, and a routed network" and the format is documented on libvirt.org.

[1] https://www.redhat.com/archives/libvir-list/2008-August/msg00062.html

[2] https://www.redhat.com/archives/libvir-list/2008-August/msg00078.html

oVirt Devel List

This section contains the discussion happening on the ovirt-devel list.

Lighter-weight "Developer" Setup

Chris Lalancette proposed[1] some steps toward lowering the barrier to entry for oVirt users with limited hardware resources and growing the community. The proposal would remove the "fake managed nodes" concept and allow oVirt to manage the hardware on the host machine and enable installation of guests along side the oVirt appliance, and eventually remove the appliance completely and facilitate installing from a set of RPMs.

[1] https://www.redhat.com/archives/ovirt-devel/2008-August/msg00080.html

Beginnings of an oVirt API

David Lutterkort posted[1] an RFC for implementing an oVirt API and 5 patches to begin the discussion. The patches covered handling hosts, storage pools, and hardware pools. The fifth patch provided sample[2] code for using the API. The exercise revealed some changes that could be made to the server code to accomodate such an API.

[1] https://www.redhat.com/archives/ovirt-devel/2008-August/msg00045.html

[2] https://www.redhat.com/archives/ovirt-devel/2008-August/msg00050.html

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Issue138&oldid=472112"