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 !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.
[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 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.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00054.html
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.
[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. PaulFrields--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
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.
[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