From Fedora Project Wiki

< FWN

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] 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 BastienNocera 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 there would be no problem and adduced the necessity of the producing an audit trail for licensing as a concrete reason for maintaining the current workflow. 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] 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 as another location where "per-user state is kept" but John had investigated[5] both /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

Fedora 8 Security Advisories

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

[1] http://www.redhat.com/about/news/prarchive/2008/qumranet.html

[2] http://www.redhat.com/promo/qumranet/

[3] http://www.qumranet.com/files/white_papers/Solid_IC_Data_Sheet.pdf

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Issue143&oldid=472115"