FWN/Beats/Developments

Developments

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

Contributing Writer: Oisin Feeley

Python Bump to 2.6 in Rawhide

The success of Fedora's dogged persistence in pursuing an "upstream all possible patches" methodology was anecdotally highlighted during a thread in which Ignacio Vazquez-Abrams warned that all Python packages in rawhide would soon be affected. An apology was made[1] by Ignacio for a dramatic subject-line ("It's all ASPLODY!), but he explained that "[w]ithin the next few days Python 2.6 will be imported into Rawhide. This means that EVERY single Python-based package in Rawhide will be broken, and that we'll need to slog our way through rebuilding it package by package." Ignacio suggested that the list of approximately seven hundred packages could be examined with a:

repoquery --disablerepo=\* --enablerepo={development,rawhide} \
  --whatrequires "python(abi)" | sort | less

Ignacio expressed[2] willingness to trigger the rebuilds for some of the packages but "[...] there's no way I can get [700] done in a timely fashion."

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

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

Ville Skyttä asked[3] "[i]f a package installs some *.py, *.pyc, *.pyo somewhere else than in versioned python dirs, and the source *.py is python 2.6 compatible, will the *.pyc and *.pyo compiled with 2.5 break with 2.6?" Ignacio confirmed[4] that such packages should not need to be recompiled as the API had not changed beween versions 2.5 and 2.6.

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

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

Tom 'spot' Callaway suggested[5] using a separate Koji tag so that Ignacio could use a process similar to that which Tom had employed for the transition from PERL-5.8 to PERL-5.10. Jeremy Katz remembered[6] that such tagging had been used for past bumping of Python and suggested "It's good to at least get the stack up through yum and friends building and working before thrusting the new python upon everyone as otherwise it's quite difficult for people to even try to fix things on their own." A list of the essential packages was made[7] by Seth Vidal and Konstantin Ryabitsev.

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

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

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

On the foot of some skeptical questions from Les Mikesell Tom reported[8] that the end result of following such a process for PERL was that "[Fedora is] closer to perl upstream than we've ever been, and we have most of the long-standing perl bugs resolved (and we fixed the "RHEL slow perl" bug without even being aware of it as a byproduct of the methodology). The fact that you just noticed it means that we must have done some things properly, you're welcome. :)"

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

On 28-11-2008 Ignacio reported[9] that "[...] we're going to go ahead and commit 2.6 to Rawhide and start the rebuild of all Python packages in Rawhide. So please keep your hands off any packages that require python(abi) until we're done. Or if you like, you can help out by bumping the release and building against the dist-f11-python tag." He later explained[10] that python-2.6 would appear in rawhide "[...] within 10 days if all goes well. Then releng will need to fold the tag back into f11-dist" and confirmed[11] that the version in Fedora 11 will be Python-2.6.

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

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

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

On 30-11-2008 Ignacio posted[12] the results of the "first cycle of rebuilds" and categorized the failures into several convenient classes. On 01-12- 2008 Ignacio posted the results of round two which he explained[13][14] were "a set of packages that a different net caught. I used python(abi)=2.5 for the first set in order to get the low-level packages, and this one uses libpython2.5.so.1.0." The latest follow-up, on 01-12-2008 consisted[15] of the list of packages which "[...] contain compiled Python code but do not have a Requires of python(abi). Please note that this is a packaging bug as the bytecode is specific to the version of the Python it was compiled with. Whether this is a problem with rpm's macros or with the package itself must be dealt with on a case-by-case basis."

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

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

[14] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00028.html

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

Power Management and Filesystem Parameters

A series of three disk-power management proposals were published[1] as an RFC by Matthew Garrett. They were generally well-received and discussion was mostly focused on ways to instrument the kernel to measure any resulting changes and to ensure that disk lifetimes are monitored carefully.

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

The first, least controversial, proposal is to get Ingo Molnar's relatime patch upstream. An extensive discussion in LWN[2] explains that this allows applications to keep track of when files have been read without having to constantly update the last file access time, thus reducing the number of writes to the disk.

[2] http://www.lwn.net/Articles/244829/

Matthew's second proposal was to "[...] increase the value of dirty_writeback_centisecs. This will result in dirty data spending more time in memory before being pushed out to disk. This is probably more controversial. The effect of this is that a power interruption will potentially result in more data being lost." The third proposal was to enable laptop-mode[3] by default in order to mitigate the second change.

[3] cat /usr/share/doc/kernel-doc-2.6.27.5/Documentation/laptops/laptop-mode.txt

EricSandeen was interested[4] in how Matthew would measure the effects on power and performance, whether it was possible to identify individual applications causing disk accesses, and whether disk spin-down should be considered. When Matthew replied[5] that it would be difficult to monitor disk access without causing further disk access David Woodhouse suggested using blktrace and this was eagerly recognized[6] by Matthew as exactly what he needed.

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

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

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

Eric's spin-down suggestion was confirmed: "Yes, the long-term plan involves allowing drive spindown. I'm hoping to do this adaptively to let us avoid the spinup/down tendancies a static timeout provides, but you're right that monitoring SMART information would be a pretty important part of that. I lean towards offering it on desktops and servers, but not enabled by default."

Phil Knirsch posted[7] that he was working on similar ideas currently including "the idea if a combination of a monitoring backend and a tuning engine could provide an automatic adoption of the system to the current use. E.g. during daytime when a user works with his machine we would typically see quite a few reads and write all the time. Drive spindowns or other power saving features could during that time be reduced so that the user will have the best performance. During the night (in case he didn't turn of the machine) only very few read and even fewer write operations should happen, at which time the disk could then be powered down most of the time. And of course this can be extended to not only disk drives but other tunable hardware components."

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

Some of the pitfalls of choosing defaults for all users were exposed when Ralf Ertzinger and Phil disagreed[8] on the ideal behavior of logging mechanisms. Phil drew a distinction between system logging mechanisms and user application logs and argued that losing data from the latter was not as important. Dariusz Garbowski put[9] the point of view of "Joe the User": "He cares a lot that he lost last hour of his xchat (or whatever he uses) logs. He quite likely doesn't care about last hour of syslog messages (he may not even be aware they exist in the first place)..."

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

See FWN#8810,#1001112 for previous discussion of power-management in Fedora.

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

[10] https://fedoraproject.org/wiki/FWN/Issue88#PowerTOP_Release_Opens_Up_New_Directions_In_Power_Saving

[11] http://fedoraproject.org/wiki/FWN/Issue100#Disabling_Atime

[12] http://fedoraproject.org/wiki/FWN/Issue100#Reducing_Power_Usage_Of_Fedora

Strange Resolution Problems

A report of a strange name resolution problem was made[1] by Mark Bidewell. Yum failed to download the Adobe flash-plugin with an error: [Errno 4] IOError: <urlopen error (-2, 'Name or service not known')> Trying other mirror." , yet it was possible to download it directly over HTTP using the browser.

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

Christian Iseli added[2] that he had a similar "[...] issue which seems to be due to some sort of DNS lookup problem. In my case I'd get the 'Name or service not known' for download1.rpmfusion.org." Christian's troubleshooting revealed that specific sites (linuxdownload.adobe.com and download1.rpmfusion.org) were consistently resolved with ping or firefox but failed with wget and ssh. Moreover: "Putting the IP addresses in /etc/hosts "works around" the problem[.]"

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

Following some questions from Seth Vidal nothing seemed[3] obviously wrong and the mystery remains.

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

Cron Confusion

Pavel Alexeev asked[1] for guidance on how to correctly rpm package a cron job. The specific requirement was a cronjob that ran every twenty minutes and might thus use the /etc/cron.d directory provided by cronie ,the SELinux and PAM aware derivative of vixie cron. Pavel wondered how he could make a package which would work for both variants of cron.

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

When Martin Langhoff confirmed that /etc/cron.d was necessary Pavel replied[2]: "[...] /etc/cron.d [is] provided only by cronie [and] now we have several other crons in the repositories[.]" He listed several other implementations of cron found by a

# repoquery '*cron*' | egrep -v '^(yum-cron|PackageKit-cron|cronolog)'

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

Ignacio Vazquez-Abrams corrected[3] him: "The only replacement for cronie in that list is fcron. Feel free to log a bug against it." Till Maas and Pavel noted[4], however, that the /etc/cron.* directories were also provided by the package named crontabs.

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

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

Patrice Dumas posted[5] the welcome news that he was "[...] currently preparing a fcron sub-package that would be completly compatible with cronie and would watch /etc/cron.d (using inotifywait). I'll keep the list informed."

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

Man Pages to be Mandatory and Upstreamed

A vigorous thread flowered from the promising seed planted[1] by Michael Cronenworth in which he advocated getting rid of all current documentation: "Yes, what I'm about to describe should obsolete man, info, and all the other dozen "help" documentation found in all the Fedora packages." Michael proposed that a new, lightweight standard of some sort would solve the problem of missing documentation.

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

During the course of the week there have been requests for "NetworkManager cli docs"[2] and "PulseAudio info needed"[3] in which the desired information has mostly been found on external web pages instead of in documentation supplied with the OS.

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

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

Richard W. M. Jones suggested[4] instead that the Debian model should be followed: "Debian forces all programs to come with a man page. If one is missing, this is considered a bug and packagers have to write one." Patrice Dumas was[5] against compulsion and preferred leaving the choice to the packager.

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

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

The idea of upstreaming the man pages was introduced[6] by Thorsten Leemhuis: "One reason for that: If you add man pages from debian to a fedora package then you have to recheck every now and then if the man pages are still up2date. That afaics often tends to be forgotten (I'm guilty myself here)." Richard agreed[7] and in the course of several clarifications made the strong point that "[...] it's a really useful feature of Debian that _any_ command, any many configuration files and other files, are documented using 'man'. I find it a big negative against Fedora that things aren't so consistently documented."

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

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

There seemed to be little disagreement on the desirability of providing more information but Michael was not impressed[8] with Trond Danielsen's suggestion that yelp would fulfill his requirements: "[...] it lacks in the lightweight department. It eats 40 megs of RAM upon startup and more RAM once searching occurs or pages are opened. Sure, we're all getting gigabytes of RAM these days, but it's a HELP tool with TEXT." Basil Mohamed Gohar was inspired[9] to "[write] or two man pages, because I've run into the missing-man-page problem too often." He suggested a very reasonable sounding action plan for identifying missing man pages and then filling them in with at least stubs in order to form a SIG which would work on providing quality replacements. Gergely Buday also seemed[10] interested.

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

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

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