Fedora Weekly News #138

Huzaifa Sidhpurwala huzaifas at redhat.com
Mon Aug 11 10:07:02 UTC 2008

Hash: SHA1

Fedora Weekly News Issue 138

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


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

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


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


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


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 !code?phonon-backend-gst!/code? 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.





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


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.






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


A correction was made[2] by IgnacioVazquezAbrams--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.


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



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.


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


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.


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. PaulFrields--Paul Frields speculated[4] that it
was the population of the component list which was slow.



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


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




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





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


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




This section contains the discussion happening on the


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?


[2] https://fedoraproject.org/wiki/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.


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


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



In this section, we cover the Fedora Artwork Project.


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




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


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


[3] https://fedoraproject.org/wiki/Artwork/Wallpaper_Extras


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.





=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


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

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


Contributing Writer: David Nalley

==Fedora 9 Security Advisories==

    * thunderbird- -
    * libxslt-1.1.24-2.fc9 -
    * pdns- -
    * httpd-2.2.9-1.fc9 -

Fedora 8 Security Advisories

    * poppler-0.6.2-2.fc8 -
    * httpd-2.2.9-1.fc8 -
    * libxslt-1.1.24-2.fc8 -
    * pdns- -
    * thunderbird- -


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

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

Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org


More information about the fedora-announce-list mailing list