Fedora Week News, Issue 143
Huzaifa Sidhpurwala
huzaifas at redhat.com
Mon Sep 15 10:01:18 UTC 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fedora Weekly News Issue 143
============================
Welcome to Fedora Weekly News Issue 143 for the week ending September 7,
2008.
http://fedoraproject.org/wiki/FWN/Issue143
This week Announcements trumpets the arrival of a new version of Bodhi,
the freeze of Rawhide and some essential reading on the new package
keys. In Developments we shock you with "Non-X System Consoles to be
Removed". Virtualization alerts you to "Virt-manager 0.6.0 Released" and
dives into how developers are "Laying the Groundwork for Xen Domain 0
Support". The ever entertaining Artwork beat examines "How to Select a
Winning Theme" and SecurityAdvisories provides a handy list for your
perusal.
If you are interested in contributing to Fedora Weekly News, please see
our 'join' page[1].
[1] http://fedoraproject.org/wiki/NewsProject/Join
=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
Fedora 8 and 9 Updates
Jesse Keating wrote more[0] about the status of updates on Fedora 8 and
Fedora 9. "We're in the final stages of testing a few corner cases, and
preparing the official builds of fedora-release, PackageKit,
gnome-packagekit, and unique (needed as a new dep for gnome-packagekit).
All existing updates in the old update locations will be purged, and
just these updates will be put in their place, signed with our old key.
Once you've updated to these packages, the next update attempt will
point you to our new locations with our new keys and you should be able
to process any further pending updates. You'll be prompted to import the
new key along the way."
Additionally, "these updates are designed to transition users from our
old repo locations to new locations that have all our updates re-signed
with a new set of keys[1]."
I encourage everyone to read both announcements, and also to visit the
information page on the Fedora wiki[2].
[0]
http://www.redhat.com/archives/fedora-announce-list/2008-September/msg00006.html
[1]
http://www.redhat.com/archives/fedora-announce-list/2008-September/msg00007.html
[2] https://fedoraproject.org/w/index.php?title=Enabling_new_signing_key
Bodhi 0.5!
Luke Macken has been very active in Bodhi development lately[3].
"One of the most noticable changes is that bodhi is much more
responsive. Previously, bodhi was a single python process, running on a
single server. This single server was also responsible for composing the
updates repositories, and rawhide, among lots of other bodhi-related
churn. This lead to much pain and suffering for all.
The bodhi deployment has since changed. All bodhi requests are now load
balanced to a bunch of app servers, each running mod_wsgi with multiple
bodhi processes, each with multiple threads. All of the hard work is now
done on an isolated releng server. This separate bodhi "masher" is now
responsible for composing repositories, updating bugs, generating update
notices, sending emails, extended metadata generation, and calculating
metrics. I also added support for inter-bodhi communication, which
allows our bodhi web frontends to kick off push requests to our
bodhi-masher instance."
Plenty more new-feature discussion in the full email.
[3]
http://www.redhat.com/archives/fedora-devel-announce/2008-September/msg00008.html
Frozen for Fedora 10 Beta
Jesse Keating announced[4] that Rawhide is now frozen for Fedora 10
Beta. "Rawhide will compose from the frozen content so that we all are
aware of what Beta is going to be comprised of. Extra scruitiny and
testing of rawhide over the next week is greatly appreciated."
[4]
http://www.redhat.com/archives/fedora-devel-announce/2008-September/msg00009.html
=Developments=
In this section the people, personalities and debates on the
@fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
External Repositories and the New Keys
As a result of the re-signing all the packages with a new key as a
security precaution[1] some problems with packages from third-party
repositories were reported[2] by Callum Lerwick. The specific example
was an update of the non-Free "xine-lib-extras-nonfree". Seth Vidal
suggested[3] a simple fix of yum --skip-broken update.
[1] https://fedoraproject.org/wiki/FWN/Issue142#Getting.Back.on.our.Feet
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01070.html
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01072.html
Jef Spaleta experienced[4] no such error and speculated that it was due
to some mirrors being temporarily out of sync, which Matthew Woehlke
agreed[5] was likely. Kevin Kofler disagreed[6] and diagnosed the
problem as a "chicken and egg" one in which it was impossible to get the
new repository key which in turn would enable the new, matching xine-lib
to be obtained. He suggested that while it was possible to use yum
- --skip-broken or yum --exclude for a selective update it would be better
for new users to "[...] use the PackageKit GUI, click on "Review
updates" and uncheck the xine-lib-extras-nonfree update, then apply."
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01073.html
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01090.html
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01124.html
Thorsten Leemhuis thought[7] that this was a general problem for the
livna repository in which they can only "push [too] early or [too]
late". He had outlined the problem previously (see FWN#138 "Solving the
Unsynchronized Release of Package Dependencies"[8]) but his suggested
solution of adding a brief time period during which yum keeps checking
for missing dependencies had not obtained traction. Thorsten explained
again: "[...] the problem happens each time when Livna/RPM Fusion
packages with deps on a specific Fedora packages get pushed in sync;
that creates a lot of trouble * I'd say once for 24 hours each two
weeks." He conceded[9] that yum --skip-broken was "[...] best answer,
but that's not enabled by default in Fedora. Livna/RPM Fusion could fix
that via its releasepackages, but that's not nice and I want to avoid
going that route."
On the foot of a suggestion made[10] by Harald Hoyer to add "More
Information button in PackageKit dialogs, which explains the situation
and that this might only just take some days to resolve[.]" Richard
Hughes asked[11] for specific suggestions to improve the current
dialogs. He added that "[m]y personal view is that by showing an error
dialog, we've lost, and should avoid doing it at all costs." Thorsten
responded[12] to Harald that he believed that it was best to "[...]
enable skip-broken by default, but show the error to the user if
security updates are involved *or* if the problem doesn't vanish within
72 hours after it had been hit on the client for the first time" and
that for the latter cases PackageKit could show some more information.
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01097.html
[8]
http://fedoraproject.org/wiki/FWN/Issue138#Solving.the.Unsynchronized.Release.of.Package.Dependencies
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01080.html
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01143.html
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01149.html
[12]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01144.html
Non-X System Consoles to be Removed
ArthurPemberton was concerned[1] about the best way to help debug the
many [PulseAudio] issues which he was experiencing on Fedora 9. He asked
"[w]hat information should I gather, how, and where should I present
it?" This innocent enquiry spawned several sub-threads which avoided
answering his question.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00982.html
In the first Bill Crawford recommended[2] disabling PulseAudio and
although Ignacio Vazquez-Abrams listed features unique to it Karel Zak
was[3] skeptical that "ordinary" users would need them. Toshio Kuratomi
responded[4] that the network transport features were very useful for
thinclients.
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01053.html
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01107.html
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01110.html
Janina Sajka chimed in[5] to agree with Arthur that while the idea of
PulseAudio was appealing and "[...] holds great promise for
accessibility [...]" there appeared to be practical problems to sort
out. Janina referenced SpeakupModified.org, which provides repositories
for a Fedora-derived distribution tailored towards users that rely on
audio cues instead of visual ones, and noted that it was currently
necessary to disable PulseAudio because "[...] one gets no audio until
after a user logs in on the GUI. So, how are those who need screen
reader support supposed to use the a11y features of GDM? As it stands,
there seems no way to get console audio without that GUI login. Also a
nonstarter in the screen reader user community." She asked if anyone had
a "working init script for pulseaudio as a system daemon?" None of the
many message that followed appeared to have an answer to this question.
In part this appeared[6] to be because < Orca can handle the audio
rendering of the GDM login screen. Colin provided[7] references that
should make it possible to configure GDM to work this way out of the box
using GConf settings. It seemed[8] that this was a possible solution.
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01179.html
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01189.html
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01213.html
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01240.html
At this point Colin Walters set off a firestorm of complaints and
queries when he announced[9], as an aside, that "[w]e're going to be
removing the legacy non-X system consoles by default in the long run."
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01180.html
Jerry james listed[10] three scenarios in which he felt it would be very
useful to have text consoles. The advantages included faster startup
than with Xorg and independence from a damaged X session. Colin
rebutted[11] most of these with the argument that "login is slow" was a
bug which should be fixed and that the other scenarios also were
constructed on the basis of bugs which should be fixed (in the
applications themselves and in Xorg's ability to handle crashes.)
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01186.html
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01190.html
Matthew Woehlke also wondered what would happen if Xorg itself was
broken and Colin asked[12] rhetorically "What happens when the linux
kernel is broken? What happens when /bin/sh is broken? What happens when
NetworkManager is broken?" He added that a compressed recovery image
should be included by default in a Fedora install. Matthew's response
suggested[13] that although it would be possible to recover it would
mean having to find a rescue disk and to reboot. He expressed a
preference for "[having] X fail to start and dump me at a normal console
from which I can fix the problem *without rebooting*, much less needing
to dig up a rescue disk :P" and compared the alternative to the
fragility of Windows. The issue then became a little clouded when Colin
stated "I believe we already do that today, and am not advocating
removing that functionality if possible. Anyways, I've said what I need
to, so hopefully people won't be surprised later." Further
requests[14][15] for clarification on the previous statement produced no
simple response, although later Colin did appear to confirm[16] the
impression that he saw this as an essential change for the evolution of
Fedora as a Desktop.
[12]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01194.html
[13]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01197.html
[14]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01199.html
[15]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01203.html
[16]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01209.html
make force-tag Gone
The removal of make force-tag was objected to[1] by Bastien Nocerra as
it forced bumping the Release of packages even for trivial changes. A
massive thread resulted with a good deal of agreement expressed with
Bastien.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00675.html
Mike McGrath made[2] the case that if maintainers tested packages before
committing them and adduced the necessity of the current workflow in
producing an audit trail for licensing as a concrete reason. Jon Ciesla
had earlier mentioned using TAG_OPTS=-F make tag as a work around and
now asked[3] if "the Makefile can be modified to prevent it, so that
others who didn't know [that this invalidates the audit trail] stop
doing it?" Doug Ledford responded[4] that this would be unenforceable as
it would still allow the CVS command to be run by hand and "[i]f our
recent 'incident' showed us anything, it's that things like this need to
be enforced on the CVS server if they are going to be enforced at all."
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00725.html
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00736.html
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00904.html
Jesse Keating argued[5] that the issue was more GPL compliance than an
audit trail and outlined why he would personally prefer to move away
from building from CVS tags. Jef Spaleta suggested[6] that Mike McGrath
had misspoken: "You are of course free to make 300 small separate
specfile changes between each build attempt. There is a desire to move
to a point where we can be reasonably sure that a cvs tag corresponds to
a specific build. Since we have no way of making only tags corresponding
to successfully built packages immutable, all tags must be immutable"
and like Mike asked for a way to mark as immutable a subset of CVS tags
corresponding to a successful Koji build.
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00740.html
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00786.html
The thread is recommended reading for package maintainers and the brief
summary above misses many important points.
Graphics Modesetting Changes
A post by Dave Airlie reminded[1] the list that [KernelModesetting][2]
was going to be one of the notable features of Fedora 10 for recent
Radeon "r300 to r500 (and possibly r600/r700)" and Intel "from i830 to
GM45 (though it may end up i915 and up only)" GPUs . Adam Jackson
responded[3] to Bill Crawford that r200 class hardware would probably
not get modesetting in Fedora 10. Among other things this will have
cosmetic advantages such as removing flickers from the startup sequence,
reducing Xorg startup times and practical advantages such as oops/panic
messages while Xorg is running and improved suspend/resume support. Dave
cautioned that only a subset of the GPUs were working for the beta
release "[...] r300 to r500 class of hardware, while we await upstream
changes to the Intel driver" and noted that to disable modesetting one
should append nomodeset to the kernel command line via GRUB.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00991.html
[2] https://fedoraproject.org/wiki/Features/KernelModesetting
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01019.html
In response to Hans de Goede Dave welcomed[4] bug reports of the "output
doesn't light up" type and suggested using an ssh session to reboot to
runlevel 3 with nomodeset and then rmmod radeon drm; modprobe drm
debug=1; modprobe radeon modeset=1 and attach dmesg and an Xorg log to
the bugzilla entry. Following this recipe produced[5] no luck for
"Joshua C." as everything froze once he followed the last step.
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01004.html
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01018.html
Skepticism about inserting the Intel driver code after the beta testing
period was expressed[6] by Jeremy Katz on the foot of such late changes
lacking both the visibility necessary for testing and the time to fix
any bugs revealed. Jeremy was mildly scathing: "Yeah, I've seen intel's
'mature' code before. Excuse me if this is anything but reassuring."
Jesse Keating and Christopher Snook seemed[7] to accept Jeremy's point
and leaned towards the idea of implementing the KernelModesetting
contingency plan[8] of including the modesetting code disabled by
default, but allowing users to enable it on the kernel command line.
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01036.html
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01055.html
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01055.html
Adam Jackson wondered whether Jeremy was advocating removing all the new
code or testing it all and Jeremy suggested[9] the third option of only
enabling the radeon code for now and waiting for Fedora 11 to enable the
Intel code.
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01068.html
When "Joshua C." asked[10] for a list of working radeon cards and
suggested applying the contingency plan because "f10 is just a month
away" he was corrected [11] by Paul Frields that it was approximately
two months away with a development freeze in six weeks. Dave asked[12]
Joshua to "[...] stop scare mongering[,] it's a beta release, if it
still doesn't work at devel freeze I'll blacklist all the broken
machines" which reaction surprised[13] Joshua a little.
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01077.html
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01115.html
[12]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01117.html
[13]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01147.html
Root Login Disallowed on GDM
Surprise was expressed[1] by "Dr. Diesel" when he attempted to log in as
root via GDM[2] to a rawhide install. "Dr. Diesel" reported that it was
possible to log in via the console in runlevel 3. He asked if he should
file a bugzilla entry.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01205.html
[2] http://www.gnome.org/projects/gdm/
Darrell Pfeifer quoted[3] the changelog as evidence that this
restriction was intentional to which "Dr. Diesel" responded that it
would be a good idea to change the prompt to "[...] something like 'Root
login disabled'[.]". Matthew Woehlke was disturbed and wondered "[...]
what exactly are we supposed to do when the user login gets hosed? Reach
for a rescue disk? (Seriously, what's with the sudden trend to make
fixing problems harder by making recovery modes inaccessible in an
apparent bid to hide the "confusing/potentially dangerous" bits of the
system from the user?)" The latter part of this apparently being a
reference to another recent thread (see this FWN#143 "Non-X System
Consoles to be Removed".)
[3]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01206.html
Benjamin Lewis presented[4] a straightforward, obvious way of fixing
such problems: "CTRL+ALT+F1, login as root, fix it, CTRL+ALT+F7 to get
back to GDM" and Martin Sourada added "[or] boot to runlevel 3, login as
root there and startx..."
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01225.html
The discussion was moved on[5] by Nigel Jones with a suggestion that the
default setup should configure sudo to allow the first user configured
during firstboot to have "full access w/ password." Steven Moix
disagreed[6] as this all seemed like the "Ubuntu 'protect us from
ourselves' way" which removed the conscious choice to log in as root.
Martin Sourada was also filled[7] with dismay at the idea, but his
objection was that PolicyKit was a superior solution to sudo. This
preference was confronted[8] by Thorsten Leemhuis with a request to
"[...] please tell me how for example read /var/log/messages or other
log files from /var/log/ using PolicyKit from a -gnome,kde-terminal with
an easy to remember and fast to type command (like 'sudo') [.]" Thorsten
also suggested that firstboot could present a checkbox labeled "User is
the sysadmin for this system" that when checked would configure sudo
and/or PolicyKit or any other desiderata for allowing root privileges
for the user. Matthew Miller largely agreed with this and suggested that
"uncommenting the wheel group in /etc/sudoers, and having said checkbox
add the user to the wheel group" would be the way to do it, but Seth
Vidal raised[9] the problem of "[...] the wheel group, on systems which
are using some other form of nss than local files, can be mucked with
too easily."
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01222.html
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01224.html
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01228.html
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01233.html
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01238.html
All this was strangely reminiscent of previous discussions, e.g. FWN#103
"Root Login And Display Managers In Rawhide"[10] except that PolicyKit
now offers some possible new directions as Martin Sourada outlined[11:]
"What I am mostly against is having full access to sudo without password
by default by any user. I believe PolicyKit is designed to solve this
issue by granting rights (by admin) to user to do this and that and not
do other admin tasks [...] the implementation should IMHO be like
cat/nano/vi/whatever detects that you are trying to access some file you
don't have enough rights to access, then it asks PolicyKit whether to
allow it or not and PolicyKit handles the rest (i.e. checks whether your
admin already allowed that access for you, if not asks for root password
for allowing the access and if succeeded sends back that its OK for you
to access the file). Ideally it wouldn't require any additional command
(like sudo) [...] When I want to view logs (though I don't very much
understand why I cannot read them as normal user) I just log in as root
(in console/gnome-terminal only!). Yeah it's not pleasant to write root
password every time I want to do some admin task - and that's probably
one of the reasons why PolicyKit has been developed - but I think
allowing full access to sudo without password for normal user account is
a big security hole."
[10]
http://fedoraproject.org/wiki/FWN/Issue103#Root.Login.And.Display.Managers.In.Rawhide
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01237.html
Missing Screen Locking Spurs Inquiry Into User-state Maintenance
When John Ellson enquired[1] why "[...] my userid, and only my userid,
has no Lock Screen menu item or applet?" a brief thread revealed the
many places in which user state is kept. The answer, for the impatient,
turned out[2] to be that John had experimented with Pessulus[3], which
allows administrators to enforce mandatory GConf settings on users.
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01027.html
[2]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01108.html
[3] http://live.gnome.org/Pessulus
John's first pass at the problem was to wipe out some dot files rm -rf
.gnome .gnome2 .gconf .gconfd .metacity and this failed to restore the
default. Chris Snook suggested[4] that he consider /tmp</cod> as another
location where "per-user state is kept" but John had investigated[5]
both <code>/tmp and /var/tmp.
[4]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01031.html
[5]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01034.html
Jesse Keating wondered[6] if "[...] it's not a ConsoleKit interaction
making the session think your user isn't at the console?" John replied
that he had gone to the extraordinary lengths of "moving aside my home
directory, deleting my userid, removing everything in /tmp and /var/tmp,
rebooting creating a new userid with the same name (but different user
and group numbers), and it still has no Lock Screen!!!" Jef Spaleta
made[7] the disclaimer that he did not "[...] understand
PolicyKit/ConsoleKit well enough to help you track it down in the
filesystem with 100% confidence[...]" but suggested searching in
/var/lib/PolicyKit and /var/lib/PolicyKit-public for per-user
authorization rules. This was reported[8] as fruitless by John, as was
running polkit-auth. John wondered where the output of polkit-auth came
from as "Removing /var/lib/PolicyKit/user-ellson.auths doesn't change
the output."
[6]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01040.html
[7]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01050.html
[8]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01059.html
MatthiasClasen cut straight to the chase and suggested[9] a good,
old-fashioned backtrace "Why don't we stop all this blind guessing, and
attach a debugger to the panel instead ? It would be so much easier..."
Although John wondered[10] why gnome-panel sprang to Matthias' mind as a
culprit a later suggestion[11] to "[...] break in
panel_lock_screen_action_available [...]" gave him a clue as to the problem.
[9]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01064.html
[10]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01074.html
[11]
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01076.html
Pessulus has been around since Fedora 7 at least and the process above
was a bit of a wild goose chase, but what is interesting is how
difficult it is to solve such a problem due to the many places in which
such information is stored.
=Infrastructure=
This section contains the discussion happening on the
fedora-infrastructure-list
http://fedoraproject.org/wiki/Infrastructure
Contributing Writer: HuzaifaSidhpurwala
More puppet training!
Mike McGrath writes for fedora-infrastructure-list [1]
Mike proposed that he is going to hold a couple of trainings for Puppet
on fedora-infrastructure. And asked if any one had questions etc to be
included in the training.
[1]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-September/msg00001.html
Removal of old projects from fedorahosted.
susmit shannigrahi writes for fedora-infrastructure-list [2]
Susmit reminded the list that, Fedora has a policy to remove _any_
hosted projects that are not altered or updated for last six months. And
provided a list of projects, which falls into this category and they
will soon be removed.
[2]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-September/msg00050.html
Beta Freeze
Mike McGrath writes for fedora-infrastructure-list [3]
Mike reminded everyone that the beta freeze is going to live and it will
end on 2008-09-24. This is the first pre-release freeze type the
infrastructure team has had [4]
[3]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-September/msg00096.html
[4] http://fedoraproject.org/wiki/Infrastructure/SOP/Release#Change_Freeze
=Artwork=
In this section, we cover the Fedora Artwork Project.
http://fedoraproject.org/wiki/Artwork
Contributing Writer: Nicu Buculei
How to Select a "Winning" Theme
MairinDuffy opened[1] a debate on @fedora-art about the best way to
select the final theme in a release: "We have not yet had a case where
more than one theme met this basic requirement. In case we do have
multiple themes that meet this requirement, we need a fair method to
choose which theme is selected as the default" and going further, she
proposed a solution and asked for opinions: "My suggestion is that we
have a vote within the set of active Fedora art team contributors. The
problem is how do we determine who is allowed in this vote - who is
active? "
[1]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00095.html
SamueleStorari opted[2] for a wide vote in the community "I think the
vote will be totally open to the whole community." arguing that "the
graphic it's made for all, think about art, think about expression, it
comes from the inside need of someone to express to other, to
comunicate.", an opinion endorsed by MariaLeandro[3] and IanWeller who
proposed[4] an alternate and complex system "Or, perhaps even better,
take a two-part voting approach; 50% of the vote allocated to current
Art Team members (recent contributions, 6 months, yada yada) and 50% for
the community."
[2]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00099.html
[3]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00105.html
[4]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00114.html
On the other hand, NicuBuculei opposed[5] the community vote invoking
the notion of competence "the trouble is that the large community knows
little about usability and good design", an opinion similar to that
expressed[6] by MatthiasClasen "Taste is not something that can be
decided with simple majority. Voting for the default theme would pretty
much devolve into 'which is the coolest looking background when glancing
at a bunch of screenshots', which is not at all what a good default
theme is about. This forum is the place for qualified and interested
people to work on the art that makes up the default theme. It should
also be the place where the default theme gets put together."
[5]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00101.html
[6]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00116.html
Another argument against a community-wide vote was raised[7] by
MairinDuffy "we don't really have time to plan for a Fedora-wide vote,
and since there's not much time to wait on people to vote and to get the
word out, we won't have a good representation of our base in the vote
results."
[7]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00106.html
- From his position as a Fedora Board member, JeffSpaleta came to the
conclusion "I consider the multiple rounds of discussion over the themes
as a prolonged 'community' decision. The final artwork decision is a
culminating event in a process. Are people encouraged to participate in
the earlier stages of that process as part of the art team? if they
choose not to participate in the previous rounds do they have the
context to make informed decisions at the final stage? Have they earned
the right to be a part of the final decision? I'm not sure they do."
[8]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00111.html
As a solution to get the themes as soon as possible into the hands of
the users and receive early feedback MairinDuffy issued a last-minute
call[9] for packaging the current proposals into Fedora 10 Beta "if we
could get a package put together with the wallpapers that are in the
running so far it could make the Beta." The call answered quickly by
MartinSourada [10], who created the packages.The packages were reviewed
and are already available in Rawhide.
[9]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00123.html
[10]
https://www.redhat.com/archives/fedora-art-list/2008-September/msg00137.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 9 Security Advisories
* amarok-1.4.10-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00057.html
* libtiff-3.8.2-11.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00102.html
* awstats-6.8-2.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00107.html
* openoffice.org-2.4.1-17.6.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00120.html
* Django-0.96.3-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00131.html
* gnome-packagekit-0.2.5-2.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00136.html
* fedora-release-9-5.transition -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00137.html
* PackageKit-0.2.5-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00138.html
* bitlbee-1.2.2-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00160.html
* bluez-libs-3.35-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00233.html
* bluez-utils-3.35-3.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00234.html
* rpy-1.0.3-3.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00253.html
* R-2.7.2-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00254.html
* samba-3.2.3-0.20.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00271.html
* wordpress-2.6.1-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00278.html
* xastir-1.9.2-9.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00307.html
* libxml2-2.6.32-3.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00347.html
* xine-lib-1.1.15-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00385.html
* adminutil-1.1.7-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00449.html
* drupal-6.4-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00508.html
* fedora-ds-base-1.1.2-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00521.html
* wordpress-2.6.2-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00629.html
* bitlbee-1.2.3-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00692.html
* poppler-0.8.1-2.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00697.html
* httrack-3.42.93-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00707.html
* fedora-release-9-5.transition -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00709.html
* tomcat6-6.0.18-1.1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00712.html
* wireshark-1.0.3-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00713.html
* libHX-1.23-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00723.html
* gnome-packagekit-0.2.5-2.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00728.html
* pam_mount-0.47-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00729.html
* PackageKit-0.2.5-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00731.html
* ipa-1.1.0-7.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00743.html
Fedora 8 Security Advisories
* fedora-release-8-6.transition -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00073.html
* Django-0.96.3-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00091.html
* amarok-1.4.10-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00097.html
* libtiff-3.8.2-11.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00121.html
* libxml2-2.6.32-2.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00162.html
* xine-lib-1.1.15-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00174.html
* xastir-1.9.2-8.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00199.html
* adminutil-1.1.7-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00218.html
* rpy-1.0.3-3.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00219.html
* R-2.7.2-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00220.html
* yelp-2.20.0-12.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00222.html
* drupal-5.10-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00259.html
* bitlbee-1.2.2-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00335.html
* awstats-6.8-2.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00355.html
* openoffice.org-2.3.0-6.16.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00494.html
* wordpress-2.6.1-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00502.html
* bitlbee-1.2.3-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00587.html
* wordpress-2.6.2-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00607.html
* fedora-ds-base-1.1.2-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00708.html
* httrack-3.42.93-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00711.html
* wireshark-1.0.3-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00715.html
* libHX-1.23-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00721.html
* pam_mount-0.47-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00730.html
* ipa-1.1.0-4.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00733.html
=Virtualization=
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
Virt-manager 0.6.0 Released
Cole Robinson announced[1] the release of virt-manager[2] 0.6.0.
Features include:
* Remote storage management and provisioning
* Remote VM installation
* Use Avahi to list libvirtd instances
* Virtio and USB options when adding a disk device
and many more.
[1]
https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00026.html
[2] http://www.virt-manager.org
Virtinst 0.400.0 Released
Cole Robinson announced[1] the release of virtinst 0.400.0. Features
include:
* New tool 'virt-convert'
* New tool 'virt-pack'
* Support for remote VM installation
* Use virtio disk/net drivers if chosen os entry supports it
and many more.
[1]
https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00027.html
Fedora Xen List
This section contains the discussion happening on the fedora-xen list.
Laying the Groundwork for Xen Domain 0 Support
There are further developments in the state of Xen in upstream Linux
(see FWN#137[3]). Pasi Kärkkäinen forwarded[1] a patch announcement[2]
from xen-devel list. This set of seven patches begin to lay the
groundwork for Xen domain 0 support.
[1] https://www.redhat.com/archives/fedora-xen/2008-September/msg00001.html
[2]
http://lists.xensource.com/archives/html/xen-devel/2008-09/threads.html#00170
[3]
http://fedoraproject.org/wiki/FWN/Issue137#State_of_Xen_in_Upstream_Linux
Daniel P. Berrange said[4] these patches will make their way into
rawhide when they are merged into the LKML[5] dev tree line used by
rawhide at that time.
[4] https://www.redhat.com/archives/fedora-xen/2008-September/msg00003.html
[5] http://lkml.org
Libvirt List
This section contains the discussion happening on the libvir-list.
Libvirt 0.4.5 Released
Daniel Veillard announced[1] the release of libvirt 0.4.5. In addition
to a long changelog, the "main features are the improvement of OpenVZ
and LXC, the uniform XML handling (and hence format) th[r]ough all
drivers, improvements in devices handling for QEmu/KVM and storage pool
source discovery."
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00186.html
Segfault if no Qemu Emulator Passed
Cole Robinson patched[1] a bug that resulted in a segfault if a Qemu
domain is defined without an emulator value. Daniel Berrange
expressed[2] displeasure at letting this bug slip through and proposed a
"brown paper bag" release. Daniel Veillard advised[3] against rushing
the fix, and offered to push the patch to Fedora's build while other
distributions could pick up the fix in a week or two when libvirt 0.4.6
would presumably be released.
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00199.html
[2] https://www.redhat.com/archives/libvir-list/2008-September/msg00202.html
[3] https://www.redhat.com/archives/libvir-list/2008-September/msg00206.html
Daniel Berrange pointed out code test coverage reports[4] on the build
server, and highlighted the need to create a functional test rig for the
mass of code that is simply not possible to unit test due to
interactions with host OS state / functionality.
[4] http://builder.virt-manager.org/module-libvirt--devel.html
Ability to Nice KVM Processes
Henri Cook expressed[1] a desire to nice KVM processes, and proposed a
means to pass arbitrary command string parameters to the process startup.
As mentioned[2] in FWN #141, Daniel Berrange pointed out[3] the goal of
libvirt is consistent API representation across hypervisors. Fortunately
there is a 'schedular parameters' API in libvirt. All that's needed is
for someone to implement the schedular parameters driver API for KVM.
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00209.html
[2]
http://fedoraproject.org/wiki/FWN/Issue141#Exposing_Unique_Hypervisor_Features
[3] https://www.redhat.com/archives/libvir-list/2008-September/msg00210.html
RFC Thoughts on Open Source Hypervisor Management
Nathan Charles described[1] his ideal clustered VM provisioning system.
Features would include
* cluster administration is done from the command line
* cluster administration can be performed from any node
* a new node can join a cluster on a local subnet with one command
* local storage resources are presented to the cluster so there is
no need to have predefined NAS/SAN/iSCSI
* cluster will load balance vm instances from node to node
* a node shouldn't need more than one nic but adding additional
nic's provides failover and load balancing
Nathan acknowledged oVirt's virtues, but stated it requires a lot of
substantial changes and significant modification to work with an
existing provisioning infrastructure. Nathan requested comments on his
thoughts.
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00195.html
The only reply[2] so far came from Stefan de Konink, who pointed to some
code[3] which seems[4] to be a "handler for libvirt using avahiclient".
[2] https://www.redhat.com/archives/libvir-list/2008-September/msg00196.html
[3] http://repo.or.cz/w/handlervirt.git
[4] http://kinkrsoftware.nl/projecten.html#virt
oVirt Devel List
This section contains the discussion happening on the ovirt-devel list.
oVirt Source Repository Refactored
Perry N. Myers announced[1] the completion of the restructuring of the
oVirt source mentioned in FWN #142[2]. This reorganization resulted in
commits of numerous spec files and other changes making an RPM-based
install more feasible.
[1] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00145.html
[2] https://fedoraproject.org/wiki/FWN/Issue142#Renaming_oVirt_RPMs
oVirt Migration Status
Atsushi SAKAI asked[1] if the following assumptions were true. KVM
supports migration, while Qemu does not. Ovirt release supports
migration, developer version does not. Chris Lalancette clarified[2]
"there is live migration code in upstream kvm userspace, but not in
upstream qemu" and fully emulated guests can be live migrated as long as
the KVM binary is used to do it (which ovirt does).
[1] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00107.html
[2] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00108.html
Atsushi inquired of the fake managed nodes, and Chris Lalancette
explained[3] the fake managed nodes are abstractions to allow
experimenting oVirt with limited hardware. Perry N. Myers added[4] there
is work underway to remove the 'fake node' concept.
[3] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00110.html
[4] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00111.html
Network Interface Bonding and Failover Work Continues
Darryl L. Pierce continued[1] work on NIC bonding and failover (see FWN
#142[2]) laying out the process a node will use to configure interfaces
on bootup and the selection of bonding type which must be selected on
the server. Types include
* Load Balancing
* Failover
* Broadcast
* Link Aggregation
[1] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00243.html
[2]
https://fedoraproject.org/wiki/FWN/Issue142#Network_Interface_Bonding_and_Failover
Daniel P. Berrange inquired[3] if those four options was a limit of the
bonding driver or a design choice, since more complex bonding
configurations are plausible. Darryl L. Pierce affirmed[4] it is a
design choice to keep things simple initially. Chris Lalancette
pointed[5] out there are many combinations of bridges, bonds, and VLANs,
and "we have to figure out which combinations are completely insane,
which are valid and make sense, and then make sure we can handle those."
[3] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00244.html
[4] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00245.html
[5] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00246.html
Related discussion occurred in another[6] thread on how to configure
multiple bondings for a host in the UI.
[6] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00262.html
Other Virtualization News
This section contains virtualization news which may not have been
directly discussed on the above mailing lists.
Red Hat Acquires Makers of KVM, Qumranet Inc.
On September 4, 2008 Red Hat acquired[1][2] Qumranet, Inc., the inventor
and key maintainer of KVM. Qumranet also develops Solid ICE[3] which
runs a user's desktop in a KVM virtual machine in the data center with
users connecting via thin client or other options.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org
iD8DBQFIzjJtzHDc8tpb2uURAt7cAJ4wbxy9uFmQ8YBiE4+4mhWr3ZVewgCdFbzR
EQCCTko6S8KVR4HASblGW+g=
=toBe
-----END PGP SIGNATURE-----
More information about the fedora-announce-list
mailing list