Garfield's Opensource News: FWN #154

= Fedora Weekly News Issue 154 =

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

http://fedoraproject.org/wiki/FWN/Issue154

This week many of us enjoyed Thanksgiving turkey and 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

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

CONTENTS #154
1.1 Announcements
1.1.1 Fedora 10
1.1.2 Other
1.2 Developments
1.2.1 Python Bump to 2.6 in Rawhide
1.2.2 Power Management and Filesystem Parameters
1.2.3 Strange Resolution Problems
1.2.4 Cron Confusion
1.2.5 Man Pages to be Mandatory and Upstreamed
1.3 Artwork
1.3.1 Stickers
1.3.2 Release Banner for the Website
1.3.3 The Download Page
1.4 Security Advisories
1.4.1 Fedora 10 Security Advisories
1.4.2 Fedora 9 Security Advisories
1.4.3 Fedora 8 Security Advisories

== Announcements ==

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

http://www.redhat.com/archives/fedora-announce-list/

http://www.redhat.com/archives/fedora-devel-announce/

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

=== Other ===

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

== 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

[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

== Artwork ==

In this section, we cover the Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: Nicu Buculei

=== Stickers ===

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 myapproval 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.

https://www.redhat.com/mailman/listinfo/fedora-package-announce

Contributing Writer: David Nalley

=== Fedora 10 Security Advisories ===

* nagios-3.0.5-1.fc10 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00881.html
* imlib2-1.4.2-2.fc10 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00906.html
* php-Smarty-2.6.20-2.fc10 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00940.html
* net-snmp-5.4.2.1-1.fc10 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg01002.html

=== Fedora 9 Security Advisories ===

* imlib2-1.4.2-2.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00856.html

=== Fedora 8 Security Advisories ===