FWN/Beats/Developments

Developments

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

Contributing Writer: Oisin Feeley

Fedora 11 Mass Rebuild

Some complications resulting from the inconsistent application of Fedora Packaging Guidelines were manifested when the mass rebuild discussed last week(FWN#163) gained a more concrete shape. Jesse Keating posted a request that all maintainers would read the wiki page describing what needs to be done, especially the Maintainer Actions section.

The rebuild should kick-off this Monday (2009-02-23). The wiki page describes the relatively narrow timeframe in which maintainers can attempt their own rebuilds and the way in which they can avoid the auto-rebuild.

Concern was expressed by Tom Lane that the rebuilds were non-ordered. Jesse responded that ordered builds were "[...] generally only are necessary when bumping sonames or otherwise bootstrapping items. Given that neither of those apply for this rebuild, effort spent trying to order and chain builds would be effort wasted." Ralf Corsepius challenged this with the observation that pkgconfig BuildRequires are added automatically. Ralf suggested the problem could be solved by "[...] checking which packages in current rawhide contain *.pc's but do not Provide nor Require pkgconfig(foo) and to rebuild them (in manually presorted order) in advance to the mass rebuild."

Jon Masters appreciated Jesse's work and worried that the rebuild might leave some statically built binaries using i386 instead of the promised i586 (see FWN#162). Subsequent rebuilds were suggested as a means to work around the problem but Jesse preferred to identify specific problems and stated: "I think the most I'd be willing to do would be a second build pass across the static packages. IMHO everything else should be left up to testing discovery and fixing the assumptions rather than hiding them."

Another approach was suggested by Conrad Meyer based on using BuildRequires: *-static. When Ralf replied that this would not work because many packagers who had not used static subpackages Conrad pointed to the guidelines. Nicolas Mailhot ruefully responded that his experience with the fonts guidelines suggested that enforcement was necessary. Later discussion with Jakub Jelínek about the presence of libc.a in glibc-devel suggested that it will not be simple to apply this particular guideline to glibc without gcc -static ceasing to behave as expected.

Virtual Provides for Login Managers

Following problems reported with booting to runlevel 5 by default with the slim login-manager [Lumens] sugges:ted that "[...] all packages containing a login manager include a special Provides: that we can query on." This would allow anaconda to determine whether a login-manager is installed without the difficulties of curating a list.

Patrice Dumas, and others, provided a good deal of feedback which seems to have led to a consensus that Provides: service(graphical-login) will be added to all packages which provide a login manager.

An interesting sub-thread developed in which Colin Walters argued that adding display managers (other than gdm and kdm should be strongly discouraged. This was met with a good deal of disagreement from Tom Callaway and Seth Vidal.

Colin explained that the ramifications of changing such an integral part of the OS were complex and that while anyone should be free to add such software it should also be "[...] within the rights of the people working on the desktop to close any bugs filed by people using something else WONTFIX." Jesse Keating and Seth Vidal seemed to agree that it should be possible for the Fedora Project do define specs to which login managers should conform.

The thread blossomed into several discussions. One focused on the technical challenges occasioned by the interaction of GDM, PAM, gnome-keyring, NetworkManager and ConsoleKit. Another saw Toshio Kuratomi and Colin debating the strategic merits of making it more or less easy for interested parties to add their software to the Fedora Project ecosystem.

Reducing the Number of (Dis)Charge Cycles for Laptop Batteries

A certain amount of excitement resulted when Brad Longo asked: "[...] if Fedora's power management tool has something built in so that when the battery reaches full charge, it will then discharge to lets say around 95% before beginning to charge again." The excitement arose from Brad's premise that "[...] leaving your laptop plugged in and charging with a full battery charge is harmful for the battery."

Several responses rejected the premise and pointed out that smart chargers implement trickle-mode charging. Matthew Garrett replied with some specific information about how laptop battery charging happens at a firmware-controlled threshold level. Matthew speculated that Brad wanted "[...] presumably an interface to modify that threshold. This is device specific. The tp_smapi driver (which is not in the kernel for exceedingly dull reasons) allows this to be configured on Thinkpads. I don't believe that we know how to on any other systems." Hans Ulrich Niedermann had an out-of-kernel module for tm_smapi which was configurable via /etc/sysconfig.

Matthew Saltzman reported some experiences with Windows setting the charge-threshold to 85% which is supposed to lengthen the battery life. Callum Lerwick referenced a Wikipedia article which claimes that the "[...] optimal storage charge for a Li-Ion is %40. Also, heat causes Li-Ion batteries to degenerate much faster, so if you're really worried about preserving your battery, don't leave it in the laptop while it's running. Yet another argument for less power usage. Less power, less heat, longer battery service life. Fewer toxic batteries going in to the land fill if you like that angle."

config.guess Reporting Incorrect Configuration Name ?

Panu Matilainen asked if it was a problem that the config.guess script from autotools no longer reported "redhat" as the manufacturer part of the configuration triplet. Panu referenced the documentation which suggests that "[...] the manufacturer part of the configuration name is the manufacturer of the CPU, not OS vendor' so the former redhat' was always incorrect. I don't know the history behind the decision to stomp redhat' in there to begin with nor why it was then dropped later on. But having gotten used to it, people occasionally think the unknown' (or `pc' for that matter) is a bug."

While Jakub Jelínek thought that providing the "redhat" string provided more information than "pc" or "unknown" Stepan Kaspal argued strongly that reverting to maintaining such a patch was wrong. He suggested that either upstream should be convinced to change the use of "manufacturer" or that the %configure macro in the specfile could be used to explicitly avoid calling config.guess. From here on the thread became too technically detailed to summarize although it is relatively brief as of going to press. Those learned in the lore of autotools and cross-compilation will find much to gladden their hearts.

Build-time Trapping of Python Syntax Errors

Tim Waugh initiated verification that Python code can be parsed correctly: "[...] since we are already byte-compiling Python code at build time, it is no extra effort to verify that it can be parsed and fail if not."

Reaction was uniformly positive and when Panu Matilainen explained the simple errors which the byte compile would catch and suggested a simple method of determining affected packages Florian Festi took up the challenge.

YUM Plans for Transition to Fedora 12 i686 Architecture

When Paul Howarth asked: "Now that Fedora 11 x86_32 is going to be based on i586 packages rather than i386 packages, does it follow that yum's $basearch will change from i386 to i586 and hence repository directory layouts changing too, or will it stay at i386?" a brief discussion between Seth Vidal and Josh Boyer started with a discussion over whether repositories should be named after specific architectures.

Seth Vidal differentiated between $arch and $basearch and explained: "The whole reason I liked used $arch was that it meant when fedora stopped producing a 586 compatible tree, we didn't stop any one else from making a 586 compat tree and having it available like secondary arches are." Jesse Keating explained that "i386" was a misnomer for the x86 offering. Josh Boyer was unsure whether i586 would actually "go away" for Fedora 12. Dennis Gilmore was sure that it would and offered: "Anyone who wants to continue i586 support post F11 i look forward to talking to about setting up i586 as a secondary arch."