FWN#121 Development Beat
Fedora Weekly News #121 Development Beat
Coverage of the development process behind Fedora GNU/Linux by Oisin Feeley based on the @fedora-devel mailing list.
=== Evolution Of Mail Client Preferences ===
A long thread over the selection of ”evolution” as the default MUA in Fedora was started[1] by JensPetersen. After carefully donning a figurative asbestos suit Jens noted that ”evolution” was different enough from the other GNOME applications that it was expensive to maintain and that the release of the Mozilla Foundation’s calendaring application ”lightning” and the stability of their MUA ”thunderbird” suggested they could be chosen instead. MatthewBarnes asked for elaboration of the assertion that “Evolution [is] basically a different platform [to GNOME]”. Jens replied[2], first with a courteous thanks to Matthew for his maintenance work on ”evolution” and then specified that he was referring to its “custom gtk widgets and gtkhtml”.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01750.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01765.html
Matthew, who had dug in for “another round of Evolution bashing”, acknowledged[3] these points and listed the specific steps he was undertaking to “chip away at […] the old cruft [and] technology that fell out of favor years ago.” The list includes a migration from ”GtkHTML” (the rendering library) to ”WebKit/GTK+”, a move from custom gtk widgets to modern GTK+ widgets, replacement of parts of the ”GNOME Applications Library” and rewriting the message composer to not use ”bonobo”. All this work is still in progress and may take some time.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01792.html
JohanGudmundsson and MatejCepl thought[4] that a parallel install of Evolution and Thunderbird along with a mail-migration script for Thunderbird should be installed and then the flame-fest should be concentrated on ”Tomboy” and ”mono”.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01871.html
The issue of actual user preference was floated[5] by NicuBuculei when he referenced Mugshot statistics which show a preference for Thunderbird.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01769.html
MatejCepl did not believe that Jens original mail was not intended as a flame and posted[6] a list of reasons, including poor IMAP support, poor vfolder support, bad reply-to defaults, a lack of regexes, the use of the working folder for message storage, and finally a proven track record of crashing. Matej’s reluctant conclusion was that all email clients sucked but that he would like to find a GUI MUA that sucked as little as ”mutt” did in the non-GUI space. Further discussion with KevinKofler seemed[7] to suggest that ”KMail” was a possible contender. It was even revealed[8] to be gaining HTML support, despite “HTML mail [being] a plague infecting the Internet.” This latter opinion was disputed[9] by “Gene” who pointed out a business use-case where a HTML table can be filled out more easily than ASCII. AlanCox pointed out[10] that “you have no idea what the recipient receives if you do that. HTML isn’t a strict formatting specification.” He went on to provide a demonstration of how large GIFs, which in themselves take up little space, may be turned into enormous RAM-munching bitmaps causing the recipient’s client to die.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01778.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01782.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01899.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01923.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01926.html
The banner of “All MUAs suck, it’s just a question of which sucks less for a given user/task” was raised again by JohnDennis. The most useful attribute of ”Thunderbird” for him was its lack of crashing. TomasMraz agreed[11] and suggested that Evolution’s crashing had stopped after upgrading to Fedora 8. BennyAmorsen thought[12] this was due to the Exchange Connector as did TimothySelivanow.
[11] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01813.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01836.html
[13] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01815.html
PeteZaitcev laid[14] the blame on HavocPennington for Evolution plus Epiphany and explained that its “main merit […] is the integration with calendaring and LDAP”. He cautioned that Thunderbird was subject to competing factions which might turn it into a bloated monster and added that for his own personal use ”sylpheed” was good at not chewing patches. BryanClark wrote[15] an excellent overview of the situation which suggests that Evolution’s integration and Exchange capabilities have entrenched it for now.
[14] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01872.html
[15] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01877.html
As with all good flamebait there was a lot of anecdotal evidence in the thread with some claiming[16] that Thunderbird was better than Evolution for IMAP folders and yet others flatly contradicting[17] this experience. It appears that there is a good deal of ground to be made up to produce a fast, non-archive destroying, IMAP-aware mail client.
[16] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01752.html
[17] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01756.html
==== Incompatible Unison Update ===
The bleeding-edge nature of Fedora came to the fore again when StephenWarren asked[1] whether the decision to update ”unison” in Fedora 8 to a package which was not backwards compatible with older versions was the right thing to do. JonathanUnderwood gave[2] his opinion that it was correct given the “bleeding edge” nature of Fedora and suggested that Stephen ask for a compatibility package or, better still, made one. Stephen was not pleased[3] and argued that while he expected breakage between major versions of the distro he did not expect it within a stable version. He also thought that he might find another distro if such decisions were actually the norm.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01809.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01810.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01820.html
JefSpaleta thought[4] that Jonathan had handled the situation the wrong way. In part this was based on the assumption that Jonathan had closed the bug quickly with “NOTABUG”, as suggested in the comments to the entry. ChristopherAillon also agreed with Stephen that the wrong decision had been made and reminded[5] the list that keeping users of the distribution relatively happy unless there were very good over-riding considerations was important.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01828.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01822.html
Jef requested[6] more information from Stephen as to the nature of the incompatibility asking him to bear in mind the need to limit the existence of compatibility packages. Responses from Stephen detailing the exact systems that he was using led to a list which Jonathan dismissed[7] as mostly irrelevant due to them being EOL’ed. HansdeGoede thought that breaking a network protocol during a stable release was a problem and also expressed[8] concern over Jonathan’s tone. Jonathan apologized[9] for any unintended tone and argued that the bugs fixed by the update were showstoppers for cross-compatibility and thus necessary.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01824.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01834.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01839.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01881.html
A lot of the commentary suggested that such changes were unacceptable. AndrewFarris noted[10] that such changes were not uncommon with upstream ”unison” and ChristopherAillon suggested considering ”rsync” as an alternative. Andrew explained[11] that ”unison” did not simply replicate changes from an authoritative master to a slave, but kept both sides in sync with each other.
[10] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01864.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01866.html
As things stand there appears to be a compatibility package created by Stephen awaiting[12] review, with quite a deal of discussion already attached.
[12] https://bugzilla.redhat.com/show_bug.cgi?id=433915
=== Three Simple Steps To Speed Up Booting / Shutdown ===
The slow booting of Fedora led ArjanvanderVen to undertake some practical steps to speed things up. He confessed[1] to being “a tad annoyed by why the initscript processing is (in my impatient perception) slow” as each actual initscript is actually relatively quick.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01495.html
The practical improvements broke down into six major types of change affecting ”/etc/rc.d/rc”, ”/etc/init.d/functions” and ”/etc/profile.d/lang.sh”. They include rewriting builtin Bourne-shell inclusive-or tests for files ,e.g. {{{[ -f FOO -o -f BAR ]}}}, to two separate statements testing for each file. The point of this is to reduce the un-needed disk-seeking and I/O of searching for BAR in the cases where FOO exists. BehdadEsfahbod suggested[2] that the BASH short-circuit test, later provided[2a] by AdamGoode as {{{ [[ -f FOO || -f BAR ]] }}}, should be used instead. Behdad had undertaken a similar exercise to Arjan’s and agreed that another of the optimizations, namely to not change VGA fonts via initscripts, was important. He extended it to “I’d go as far as saying that unicode_start should only be called from /etc/profile, not other bash invocations.” BillNottingham agreed strongly[3], saying “Heck, it should only be called from a udev rule on console initialization.”
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01501.html
[2a] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01522.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01610.html
Behdad had concentrated on ”rc.sysinit” and was disturbed by a script ”/sbin/start_udev” which it called as it provided its own internal, slower implementation of ”xargs” instead of calling a real xargs when available. Arjan felt[4] that ”udev” was “so incredibly slow that it’s just outrageous” and referenced a comparison to a much quicker boot with a non-Fedora distribution preloaded on his laptop. HaraldHoyer suggested[5] that it would be useful to “add udevinfo or udevdebug to the kernel command line” to check for some of what he found to be the usual causes of a long startup: slow kernel module loading; firmware loading failing; persistent storage labeling bugs. OlaThoresen noted[6] that if LDAP is used for authentication and the network is not up before udev starts then udev waits for a long timeout. LubomirKundrak remembered[7] that there had been a thread about a year ago in which someone recommended that modprobe dependencies should be cached as udev spent most of its time waiting for this information. In fact this work had been done by HaraldHoyer himself as reported in FWN#103 “Udev Performance”[8].
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01520.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01586.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01624.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01615.html
[8] http://fedoraproject.org/wiki/FWN/Issue103#head-4ff62435e0646dccef282c64ec86f3b2c8350ef3
=== When To Introduce Asterisk 1.6 ===
JeffreyOllie asked[1] what the general feeling was about waiting until Fedora 10 to introduce the latest version of the VOIP server ”asterisk”. Right now packages of version 1.4 of ”asterisk” are available for Fedora 7 and Fedora 8 but the 1.6 version was reported by Jeff to be in “late beta”.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01659.html
JefSpaleta wondered[2] why he could not package it after the Fedora 9 ISOs had been released, then drop it into the “updates-testing” repository with appropriate fanfare to alert interested testers, and finally push it into “updates-released” after making any necessary changes. Jeff explained[3] that he wished to “avoid upgrading to a new Asterisk major version in a stable Fedora release” with the reason that Asterisk users tended to be “averse to upgrading” with some still running on 2.4 kernels and Digium still supporting Asterisk-1.2. There seemed to be some support for this position, but BennyAmorsen added[4] the information that the support provided by Digium was for the non-GPL’ed “Business Edition” and extended only to security fixes.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01662.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01668.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01703.html
The other side of the argument was put[5] by RichiPlana who stated his preference, as an employee of an enterprise which ships production systems based on the latest Fedora and Asterisk versions, for a package of the beta to be available for testing “even if it doesn’t go stable before F10 is released”. Richi later argued[6] that as Asterisk itself was moving to a shorter release cycle more synchronized with Fedora’s and that this “beta3” seemed from their list traffic to be implementing very conservative changes. The new management features were something which Richi was especially interested in testing.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01705.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01663.html
The stability of the beta was raised[7] by KevinKofler as an important factor in the decision. He argued that if the official release was scheduled prior to the release of Fedora 9 then “you should definitely upgrade to the beta now and get the release info F9 final.” If, however, it were to be released afterwards then a decision needed to be made based upon the evaluation of the stability of the beta. Kevin noted that the “beta” label itself meant wildly different things for different projects.
[7] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01682.html
On a related issue JohannGudmundsson asked[8] whether the latest ”ISC-DHCP” (ver. 4) and ”freeradius” could be packaged. He also wondered if there were some way to see whether Fedora was shipping the most recent software from a variety of projects. JohnDennis answered[9] that he just needed to find time to get the latest ”freeradius 2” done and that there was nothing blocking it. FlorianlaRoche posted[10] a link to a handy distrowatch table which may be slightly inaccurate but attempts to provide a tabular view of package versions. KevinKofler reminded[11] Johann that DHCP-4 was already in rawhide.
[8] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01670.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01671.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01672.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01683.html
=== SELinux Smolt Statistics ===
Seeking clarification on the figures reported by Smolt for SELinux JamesMorris asked[1] whether the report that approximately half of those surveyed (circa 331,000 registered hosts) had SELinux enabled was accurate. James pointed out that as reports on SELinux had only been collected from Fedora 8 onward the true percentage might be closer to 74%.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01621.html
YaakovNemoy agreed[2] that more detailed reports were necessary, but was off to FOSDEM and had to put it on a “TODO” list for urgent attention. JamesMorris was[3] keener to get a quick correction up on the web page and some clarification as to how the statistics were calculated.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01622.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01634.html
A slightly fraught part of the thread was started[4] by ValentTurkovic when he replied to James’ original query with a partial quote which emphasized the original statistic “If this arguments are true for Fedora 8 than it looks like that more people dislike selinux than like it, right?” and ignored the probable confusion which James had pointed out. James responded[5] “Why did you delete the rest of the email, which queried these numbers and suggested that the real figure for enablement was much higher?” He added that off-list he had obtained the raw figures for Fedora 8 systems (the only ones which actually are set up to report whether SELinux is enabled or not) and “the “Enabled=True” value is currently 94%.” James qualified this with the caution that there were several factors confounding any simple interpretation. JohnDennis answered[6] that Valent had an “anti SELinux agenda” as referenced by previous threads and Valent countered[7] that this was a misunderstanding and that he was helping by contributing bugs for selinux-policy.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01690.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01704.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01962.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01962.html
One of the possible confounding factors was raised by BennyAmorsen, who asked “Does Enabled=True imply enforcing”. JamesMorris answered[8] that it did not and this was one of the extra pieces of information which needed to be collected. He also expressed a wish that information on other security features such as ”iptables” be collected.
[8] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01739.html
=== How To Get Mock To Include Testing Packages In Buildroot ===
NealBecker asked[1] how it was possible to build against a package which was in ”testing”. He was specifically concerned with the situation that his ”python-igraph” package had a BuildRequires on ”igraph-devel” and he wished to build against the latest ”igraph-devel-0.5” which had just been pushed into testing. IgnacioVazquezAbrams told him to “request a buildroot inclusion from releng” and upon further questioning confirmed[2] that this meant “send an email to releng.”
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01633.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01647.html
A webpage listing the commands used by Koji administrators was linked[3] by AlexLancaster and he suggested adding the “email rel-eng” instructions for ordinary users there. JesseKeating seemed[4] to want to keep that particular page as a reference for the Koji administrators but requested “somebody please suggest a place where [instructions on making this request by email] will be found and used [on the wiki].”
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01675.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01676.html
“This is not a particularly intuitive mechanism at the moment. How can we automate this better” asked[5] DenisLeroy. Jesse replied[6] with a request for patches.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01637.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01638.html
=== Auto-rebuild Release Bump Errors ===
A report[1] by OrionPoplawski of an incorrect bump of the version of his pre-release ”gdl” package, as a result of the GCC-4.3 autorebuild (see this same FWN#121 “GCC 4.3 Mass Rebuild”), exposed a problem in its naming. The ”gdl 0.9-0.pre6.fc9” package bad been bumped to ”0.9-1.pre6.fc9” and Orion noted that it should have been ”0.9-0.pre6.fc9.1”. MichaelSchwendt corrected[2] the original numbering to ”0.9-0.1.pre6%{?dist}”.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01657.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01660.html
After JesseKeating agreed with Michael and pointed out that packages which fail to follow the guidelines will be missed by the bumper attention was drawn[3] to the jpp-based java packages by MattWringe. Matt noted that they seemed to have all failed to update properly, yet were following the JPackage naming guidelines. Michael asked[4] whether the original BillNottingham/ElliotLee (sopwith) script in cvs/fedora, used by the old FedoraExtras, was used as “if a different and secret script is used, that’s not helpful.” Jesse responded[5] that it was one from ”cvs/fedora/rebuild-scripts” and asked for details of failed jpp packages because the ones which he had examined seemed fine. KevinKofler reported that they were bumped to ”m+1jpp.something” instead of ”mjpp.n+1” to which Michael replied[6] that this was now a supported scheme in cvs. In discussion with Kevin further details of the bumper were explained by Michael.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01957.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01968.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01969.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01985.html
=== GCC 4.3 Mass Rebuild ===
The announcement that a mass rebuild using ”GCC-4.3” was made[1] on 18 February 2008 by JesseKeating. JoshBoyer sounded[2] happy that blacklist requests (by the owners of packages which were known in advance to fail to rebuild) would no longer be accepted.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01597.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01601.html
JoshBoyer in response to DenisLeroy stated[3] that the algorithm was to “rebuild all except blacklisted AND already rebuilt with gcc 4.3”.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01582.html
PERL packages were thought[4] by PaulHowarth to be a problem as he had been waiting for an update to ”PERL 5.10” in the buildroots before he built his packages. Josh answered[5] that such packages would be rebuilt twice: once now and then another time when the PERL update landed. TomCallaway issued[6] a mea culpa for the lack of a PERL update.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01584.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01590.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01614.html
