From FedoraProject

Revision as of 20:01, 11 January 2009 by Ush (Talk | contribs)

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


Fedora Weekly News Issue 158

Welcome to Fedora Weekly News Issue 158 for the week ending January 11th, 2009.



If you are interested in contributing to Fedora Weekly News, please see our 'join' page[1]. We welcome reader feedback: fedora-news-list@redhat.com

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

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


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



Contributing Writer: Max Spevack

Election Results

Bill Nottingham and Matt Domsch were re-elected to the Fedora Board for two-release terms.

Josh Boyer, Dan Horák, Jarod Wilson, and Jon Stanley were elected to the Fedora Engineering Steering Committee for two-release terms.

Max Spevack, Joerg Simon, Francesco Ugolini, Thomas Canniot, Rodrigo Padula, David Nalley, and Susmit Shannigrahi were elected to the Fedora Ambassadors Steering Committee for two-release terms.

Paul Frields announced that Dimitris Glezos has been appointed to fill the final seat on the Fedora Board.

ref: http://www.redhat.com/archives/fedora-announce-list/2008-December/msg00019.html

ref: http://www.redhat.com/archives/fedora-announce-list/2008-December/msg00017.html

ref: http://www.redhat.com/archives/fedora-announce-list/2008-December/msg00018.html

ref: http://www.redhat.com/archives/fedora-announce-list/2009-January/msg00007.html

FUDCon Boston 2009

Don't forget to attend FUDCon Boston, January 9-11.

ref: https://fedoraproject.org/wiki/FUDCon/FUDConF11

Fedora 8 End of Life

The end-of-life for Fedora 8 is Wednesday, January 7. No further updates will be issued, no new builds will be allowed in the build system, and all open bugs against Fedora 8 will be closed WONTFIX.

ref: http://www.redhat.com/archives/fedora-announce-list/2008-December/msg00018.html

ref: https://fedoraproject.org/wiki/End_of_life


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

Contributing Writer: Oisin Feeley

Default ssh-agent Dialog Pop-up

Confusion abounded when user "nodata" reported[1] that running ssh-add from the command-line popped up a gnome dialog requesting his private SSH key. "nodata" disliked handing out his private key in such a manner. The confusion resulted from the availability of at least two possible ssh-agents[2] and also a change in configuration between Fedora 9 and Fedora 10 which presents the authentication dialog by default.

Ricky Zhou was among those who suggested (with a manpage quote) that the SSH_ASKPASS environment variable determined whether the passphrase was read from a terminal or by an X11 dialog. Separately Jesse Keating[3] and Nalin Dahyabhi explained[4] that the dialog was presented by gnome-keyring and not gnome-ssh-askpass.

"nodata" questioned[5] whether the behavior had changed between Fedora 9 and Fedora 10 and expressed irritation that a "[...] GUI is popping up when I am using a command line app." Jesse Keating responded[6]: "You're using a command line app from a graphical terminal. Also, cli apps aren't the only use for ssh and ssh keys." This did not appeal to many respondents including John Linville who questioned[7] the benefit of changing focus to a new window to type a passphrase. Callum Lerwick rather tartly outlined[8] some benefits including preventing key logging attacks.

Matthias Clasen suggested[9] using

gconftool-2 -s -t bool /apps/gnome-keyring/daemon-components/ssh false

to turn off the behavior for those who dislike it and this led to several requests to make this the default. Andrew Haley put[10] the case that "[t]he key argument against a pop-up dialog box that asks for the passphrase is that we're training people to type secrets into pop-up dialog boxes. Bad psychology, bad security."

][MatthiasClasen|Matthias Clasen]] and Tomas Mraz with Jerry Amundson explored[11] the use of SSH_ASKPASS as an alternate method to disable the GUI dialog.

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00486.html

[2] Private keys are stored by ssh agents so that they may handle all key related operations requested by clients. The passphrase to decrypt the key thus need only be typed into the agent once instead of per-operation.

[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00487.html

[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00536.html

[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00492.html

[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00495.html

[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00523.html

[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00533.html

[9] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00498.html

[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00517.html

[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00540.html

Intel Graphics Installation Woes

"Mike" requested[1] information on when a working xorg-x11-drv-i810 driver for Intel graphics chipsets had a chance of appearing. He was disappointed that it was non-trivial to get two machines with 82945G and 82845G chipsets installed and had needed to fall back to using the vesa driver instead of the intel one.

Others listed outstanding bugzilla entries for a wide range of Intel chipsets. Dan Williams asked[2] if using Option "EXANoComposite" "true" as a workaround for problems with the i830 chipsets was succesfull and received mixed reports. It seemed that he was making some progress with resolving some of the issues.

MAYoung suggested[3] that setting "NoAccel true" in xorg.conf might work for some people but that "[...] intel graphics are highly flaky on Fedora 10."

Robert Arendt laid[4] the blame at the door of upstream merges of GEM/DRM into the kernel and noted that other distributions were suffering identical problems. "Mike" later confirmed[5] this with a list of bugzilla entries from upstream freedesktop.org: "It would be nice if Intel would help to get this fixed, and there are indeed problems with Suse, Ubuntu and Mandriva also with newer drivers and Intel graphics chipsets of various flavors - this is really bad!"

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00435.html

[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00475.html

[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00443.html

[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00445.html

[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00467.html

KPackageKit Auto-update Bug

Michael B Allen reported[1] that his system had performed an update without his permission and asked how to completely disable such behavior.

It appeared[2] that this was due to a bug in KPackageKit which has been unfixable[3] for over a month due in part to the complexity of the code.

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00461.html

[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00504.html

[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00510.html

Disabling Staging Drivers ?

Rahul Sundaram asked[1] if enabling the many new drivers in the staging tree[2] would make sense in rawhide in order to support a wider range of hardware such as the EeePC's ralink wireless chipset.

Opinion was roughly split between those who were completely against the idea and those who suggested avoiding codifying a rigid policy. Matthew Garrett believed[3] that it would be "somewhat user-hostile" to, for example enable the ralink drivers in rawhide but possibly remove them for a general release. He argued that the ralink drivers were a dead-end[4] which would never merge upstream. On the other hand Dave Jones preferred[5] to take a case-by-case approach as long as "[...] we have someone responsible for working on it, with the goal of getting it out of staging, and dealing with bugs etc. Not unlike the same reasoning for us adding various not-yet-upstream drivers to the Fedora kernel really."

While preferring to completely disable the staging drivers Thorsten Leemhuis expressed[6] the intention to provide RPM Fusion kmods in that case. Dan Williams made[7] a strong argument that "-staging" itself was a bad idea as it gave "legitimacy to drivers of questionable quality" and John Linville limned[8] the tortured history of the at76 driver.

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00459.html

[2] "linux-staging" is a kernel tree whose purpose is to test drivers and filesystems for later inclusion in mainline http://lkml.org/lkml/2008/6/10/329

[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00462.html

[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00474.html

[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00472.html

[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00465.html

[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00473.html

[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00476.html

git-* Commands Moved to /usr/libexec/git-core/

Adam Tkac worried[1] that scripts would break due to the latest git branch in rawhide which had moved all the git-* binaries to /usr/libexec/git-core in order to comply with upstream practice. The issue was previously discussed (see FWN#141[2)] with the resolution that updating to git-1.6.0 would be a flag day for this change. Adam suggested that the new location could be added to the PATH environment variable but this received no support.

Karel Zak advocated[3] that such scripts should be fixed as the change had been coming since 2006.

Bryn Reeves wondered[4] if compatibility symlinks and a release note would ease the transition over a couple of releases. Although the symlinks were generally felt to be a non-effective strategy Todd Zulinger was encouraged[5] by Paul W. Frields to open a bugzilla entry against the Release Notes to ensure that the documentation team take care of highlighting the issue for Fedora 11.

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00404.html

[2] http://fedoraproject.org/wiki/FWN/Issue141#Git-1.6.0_Commands_to_be_Moved_Out_of_PATH

[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00408.html

[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00410.html

[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00460.html

Mandatory FHS Adherence

JasonTibbitts posted[1] a summary and links to the 2009-01-06 FPC meeting deliberations. Interest on @fedora-devel was mostly sparked by the item which declared that the FPC would "Make adherence to the FHS a MUST [.]" Jason encouraged reading of the full minutes in order to understand this item.

Doug Ledford discussed[2] the problem his MPI[3] implementations experienced with the FHS and Richard W. M. Jones expressed [4] concern that the FHS was a moribund standard and adhering to it would block projects such as MinGW without any method to evolve the standard. Toshio Kuratomi responded in detail in both threads and pointed out[5] that the MinGW case had been addressed in the meeting and also that there were problems with changing the FHS.

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00362.html

[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00424.html

[3] http://www.open-mpi.org/papers/ipdps-2006/

[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00469.html

[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00483.html


In this section, we cover the Fedora Documentation Project.


Contributing Writer: Jason Taylor

Docs Project and FUDCon

At FUDCon the Documentation Project tasks[0] were discussed and some headway was made. There is still work to be done and the information contained here[0] can be used to pickup where tasks were left off.

[0] https://fedoraproject.org/wiki/Your_Docs_Project_BarCamp_session_FUDConF11

Documentation Team Ownership Deadline

The Docs Project has divided the published documentation into teams[0]. The teams consist of a Lead who manages the overall direction of the document and writers who write and/or edit various pieces of the published document. There are two publications that need a lead, the release notes[1] and the packaging guide[2]. The packaging guide needs a rewrite and the release notes will start the update/publication process for F11. The deadline for claiming a publication is the week of 11-Jan-2009.

[0] https://fedoraproject.org/wiki/Docs_Project_content_tasks_for_experienced_contributors

[1] https://fedorahosted.org/release-notes/

[2] https://fedoraproject.org/wiki/PackagingGuidelines


In this section, we cover the Fedora Artwork Project.


Contributing Writer: Nicu Buculei

Echo News and Development

After a month of absence, Martin Sourada announced[1] on @fedora-art a new issue[2] of Echo Monthly News "We've just published latest Echo Monthly News Issue. Due too lack of enough content, it is joint of November's and December's happenings"

[1] https://www.redhat.com/archives/fedora-art-list/2009-January/msg00021.html

[2] https://fedorahosted.org/echo-icon-theme/wiki/MonthlyNews/Issue4-5

[3] https://fedorahosted.org/echo-icon-theme/wiki/MonthlyNews

In other Echo related news, Martin announced[4] a poll[5] regarding the future development of the theme "I've just posted a poll about Echo Perspective on Fedora Forum to see our user base opinion and I'd like to hear the opinions of the Art Team members as well"

[4] https://www.redhat.com/archives/fedora-art-list/2009-January/msg00030.html

[5] http://forums.fedoraforum.org/showthread.php?t=210159


In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies.

Contributing Writer: Dale Bewley

Enterprise Management Tools List

This section contains the discussion happening on the et-mgmt-tools list

Help Perfect Cobbler SELinux Policy

Dominick Grift posted[1] "instructions on how to install a bare SELinux policy for Package-x-generic-16.pngcobbler. Feedback in the form of AVC denials would be appreciated so that we can perfect this bare policy."

Michael DeHaan asked[2] "Would someone like to take a shot at refining this policy some or at least running Cobbler with that for a while (in permissive mode) to identify what else needs to be allowed?" and added the policy to the cobbler wiki[3].

[1] http://www.redhat.com/archives/et-mgmt-tools/2009-January/msg00003.html

[2] http://www.redhat.com/archives/et-mgmt-tools/2009-January/msg00004.html

[3] http://fedorahosted.org/cobbler/wiki/SeLinuxPolicy

Fedora Virtualization List

This section contains the discussion happening on the fedora-virt list.

New Fedora Virtualization List

On @fedora-xen, Daniel Veillard announced[1] the creation of the new @fedora-virt list.

"As the initiator for [the fedora-xen] list, I must admit I made a mistake 3 years ago, I should have picked a list name agnostic from the hypervisor name. With the current state of Xen in Fedora recent releases it really make sense to try to correct that mistake ... it's never too late ! So http://www.redhat.com/mailman/listinfo/fedora-virt is born, I don't want to mass-subscribe people, especially as I think the current list should survive with its Xen centric focus. You can subscribe directly to the new URL above.

The topic is everything concerning Fedora and virtualization including Xen.

I think the [fedora-xen] list would be a good place for people still using Fedora <= 8 with Xen, but it's just a suggestion :-)"

And on @et-mgt-tools Richard W.M. Jones suggested[2] "we should fold et-mgmt-tools into fedora-virt too."

[1] http://www.redhat.com/archives/fedora-xen/2009-January/msg00014.html

[2] http://www.redhat.com/archives/et-mgmt-tools/2009-January/msg00010.html

Fedora Xen List

This section contains the discussion happening on the fedora-xen list.

Xen 3.3.1 in Rawhide

Pasi Kärkkäinen pointed[1] out the release of Package-x-generic-16.pngxen 3.3.1. A few days later it was made available[2] in Rawhide.

[1] http://www.redhat.com/archives/fedora-xen/2009-January/msg00008.html

[2] http://koji.fedoraproject.org/koji/packageinfo?packageID=7

Manage Shutdowns of KVM Xenner Guests

Felix Schwarz used[1] Package-x-generic-16.pngkvm and Package-x-generic-16.pngxenner to migrate a Fedora 8 Xen dom0 host to Fedora 10.

"So far this was easier than expected. :-) Of course there are some smaller issues (Xenner does not work with SElinux, NetworkManager does not support bridges) but now there is only one real issue left:

How can I automatically shut down all running VMs when my host machine goes down? All VMs do poweroff if I press the 'shutdown' button in virt-manager. So I guess it's just a matter of sending this signal to all running VMs and waiting a bit."

[1] http://www.redhat.com/archives/fedora-xen/2009-January/msg00001.html

Test Dom0 Kernel For Fedora 10

Michael Young has[1] "succeeded in getting a fedora based Package-x-generic-16.pngkernel to build with Dom0 patches added." ... "If anyone wants to inspect it, the source rpm generated is at http://compsoc.dur.ac.uk/~may/xen/kernel-2.6.28-0.106.rc6.fc10.src.rpm It is completely untested beyond the fact that it compiles for me, so I have no idea if a kernel built from it will actually boot."

See also Xen[2] and Fedora[3] wikis.

[1] http://www.redhat.com/archives/fedora-xen/2008-December/msg00028.html

[2] http://wiki.xensource.com/xenwiki/XenParavirtOps

[3] http://fedoraproject.org/wiki/Features/XenPvopsDom0

Libvirt List

This section contains the discussion happening on the libvir-list.

Interface Bandwidth Controls

Max Zhen described[1] a goal of enabling Package-x-generic-16.pnglibvirt to configure bandwidth rate limits for the network interface of virtual machines, and asked for comments on implementation ideas.

[1] http://www.redhat.com/archives/libvir-list/2008-December/msg00644.html

RHEL 5 Support

Markus Armbruster posted[1] a "patch series attempts to make Package-x-generic-16.pnglibvirt just work on RHEL-5. Right now it doesn't, mostly because libvirt relies on version number checks in a couple of places, and RHEL-5's version numbers aren't the whole truth due to various backports of later stuff." Adding "I'm not proposing this for immediate commit, as I'm still testing. But I'd appreciate review: is this the right way to do it?"

[1] http://www.redhat.com/archives/libvir-list/2008-December/msg00629.html

Choice of Private Network Range

Peter Anvin was[1] "kind of wondering why Package-x-generic-16.pnglibvirt defaults to". Refering to RFCs 2544 and 3330. Peter suggested the following alternative ranges:

  • - reserved as "test and example network"
  • - reserved as "benchmark test network"

[1] http://www.redhat.com/archives/libvir-list/2008-December/msg00545.html

Guest-Safe libvirtd Restarts

A restart of libvirtd will necessarily also restart KVM virtual machine guests. Guido Günther sought[1] to rectify this with a submission of several patches.

[1] http://www.redhat.com/archives/libvir-list/2008-December/msg00346.html

[2] http://fedoraproject.org/wiki/FWN/Issue146#Maintaining_VM_State_While_Restarting_libvirtd_Needed