From FedoraProject

Revision as of 10:37, 14 April 2009 by Fab (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Fedora Weekly News Issue 154

Welcome to Fedora Weekly News Issue 154 for the week ending November 30th, 2008.


This week some of us enjoyed Thanksgiving turkey, but we all enjoyed a full helping of Fedora 10 and were left stunned and satisfied. In Announcements the availability of third-party repositories and end-of-life of Fedora 8 are detailed. Developments catches up with "Power Management and Filesystem Parameters" and a promising initiative to bring the man pages up-to-date. Artwork passes on some kudos for the "Release Banner for the Website" and the demo of some awesome "Stickers". Don't forget to peruse the SecurityAdvisories!

If you are interested in contributing to Fedora Weekly News, please see our 'join' page[1].

FWN Editorial Team: Pascal Calarco, Oisin Feeley, Huzaifa Sidhpurwala

[0] http://fedoraproject.org/en/get-fedora

[1] http://fedoraproject.org/wiki/NewsProject/Join


In this section, we cover announcements from the Fedora Project.



Contributing Writer: Max Spevack

It was a pretty quiet week in Fedora-land. Nothing really happened, so I guess we can just move ahead to the next section of Fedora Weekly News.

Wait, what? Oh, yeah... how silly of me! I guess there was that one small announcement, like the general availability of Fedora 10 on November 25.

Fedora 10

Keeping with tradition, the Fedora Project Leader Paul Frields wrote[1] a thank you message to the Fedora community on the eve of the release.

Also keeping with tradition, on the morning of the release, a "whimsical" announcement was sent[2] out on the morning of the release.

Naturally, some of the third-party packagers of Fedora (RPM Fusion and ATrpms) made their repositories available for Fedora 10 on the release day also [3,4].

Chitlesh Goorah reminded[5] the community that the Spins SIG has released seven Fedora 10 respins, all of which can be downloaded from spins.fedoraproject.org.

Finally, Red Hat's CEO Jim Whitehurst sent a congratulatory email to the Fedora community [6].

[1] http://www.redhat.com/archives/fedora-announce-list/2008-November/msg00013.html

[2] http://www.redhat.com/archives/fedora-announce-list/2008-November/msg00015.html

[3] http://www.redhat.com/archives/fedora-announce-list/2008-November/msg00014.html

[4] http://www.redhat.com/archives/fedora-announce-list/2008-November/msg00016.html

[5] http://www.redhat.com/archives/fedora-announce-list/2008-November/msg00022.html

[6] http://www.redhat.com/archives/fedora-announce-list/2008-November/msg00019.html


Fedora 8 will reach its end-of-life[7] on January 7th (07-01-2009), according[8] to Jon Stanley.

[7] http://fedoraproject.org/wiki/LifeCycle

[8] http://www.redhat.com/archives/fedora-announce-list/2008-November/msg00021.html


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-

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

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

See FWN#88[10],FWN#100[11][12] for previous discussion of power-management in Fedora.

[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


In this section, we cover the Fedora Artwork Project.


Contributing Writer: Nicu Buculei


In a message posted[1] to both @fedora-art and @fedora-marketing, Máirín Duffy showed the community a demo of a sticker sheet "I've been through a few rounds with the printing company to correct various issues and I just received a digital proof from them that I'm pretty happy with" and asking for feedback "Does this look good? If you see any errors or issues let me know and I'll have them fixed, otherwise I'd like to send to send them my approval ASAP."

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

Gerold Kassube asked[2] about the empty stickers "with some I miss the content to fedora and I ask myself: If somebody sees that freedom boble, does he realize that it's fedora or is it only for insider?!" and proposed an alternate slogan "In my head I have a big idea for a sticker which could also be a good marketing which I want to share with you and your outstanding ideas in the past (and I'm also sure in the future). I like the phrase 'Fedora! Leaders not fellows'". In reply, Paul Frields pointed[3] the possibility to combine the stickers "Well, the nice thing about these stickers is they're *extremely* inexpensive. So we can hand out a sheet or two per person, and people can paste *both* a freedom bubble and the logo together!" and stressed the importance of a single, consistent, marketing message "I think it's important for us not to develop too many 'official' slogans, because it dilutes our message. 'What is Fedora? 4 Foundations? IFV? Leaders?'"

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

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

Release Banner for the Website

In a last check before the release day, Ricky Zhou from the website team asked[1] about the status of the graphics to be used on the website "Just to make sure everything will be ready for Tuesday, will we have a final version ready for adding to the site by some time on Monday?" and quickly Paolo Leoni replied[2] with an upload of the needed images and a minor modification[3] from Nicu Buculei. Jaroslav Reznik added[4] a KDE specific flavour it it (the banner contains screenshots of the desktop).

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

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

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

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

The Download Page

In a post to @fedora-art Seth Kenlon expressed[1] his delight with the design of the download page[2] "I don't know who takes care of this stuff, but I was really really impressed with the new/updated download page for fedora 10. The buttons on the right side of the page are brilliant -- "KDE Fans Click Here" and "Need PowerPC? Click here" -- now sure, I'm biased, because those two versions of Fedora happen to be the two that I use  :^) but......objectively speaking, that is user friendly and attractive. Great job, who ever did that!" The page was designed, as Ricky Zhou pointed[3] by Máirín Duffy "Not surprisingly, this was the work of Máirín - thanks a lot for making that page beautiful and easy to use!"

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

[2] http://fedoraproject.org/en/get-fedora

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

Security Advisories

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


Contributing Writer: David Nalley

Fedora 10 Security Advisories

Fedora 9 Security Advisories

Fedora 8 Security Advisories

Fedora 8 is nearing EOL
Per FESCo support for Fedora 8 will be discontinued on January 7th 2009 https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02014.html