From Fedora Project Wiki

< FWN

Fedora Weekly News Issue 137

Welcome to Fedora Weekly News Issue 137 for the week ending August 2, 2008.

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

Fedora Weekly News keeps you updated with the latest issues, events and activities in the Fedora community.

We are pleased to present a new beat on Virtualization issues and developments brought to you by beat writer Dale Bewley. In Developments we report on "How Maintainers Can Help Reduce XULRunner Breakage". In Announcements we reveal the Fedora 10 codename. In Artwork we examine "The Blue Color of Fedora". In Security Advisories, another new beat authored by David Nalley we run through the week's important updates. We are also saddened to announce the departure of Thomas Chung from the editorial chair, but heartened to be working as a new editorial team consisting of Pascal Calarco, Oisin Feeley and Huzaifa Sidhpurwala.

If you are interested in contributing to Fedora Weekly News, please see our 'join' page. Being a Fedora Weekly News beat writer gives you a chance to work on one of our community's most important sources of news. Ideas for new beats are always welcome -- let us know how you'd like to contribute.

We are still looking for a beat writer to summarize the Fedora Events and Meetings that happened during each week.

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 10 (Cambridge)

Josh Boyer informed us[0] that "Cambridge" was the winning name in the Fedora 10 naming election. Jeremy Katz wrote[1] on his blog that "Cambridge" was the original Red Hat Linux 10 codename, which was the release that eventually became Fedora Core 1.

[0] https://www.redhat.com/archives/fedora-announce-list/2008-July/msg00014.html

[1] http://katzj.livejournal.com/434986.html

Ambassadors

In this section, we cover Fedora Ambassadors Project.

http://fedoraproject.org/wiki/Ambassadors

Contributing Writer: JeffreyTadlock


Help Wanted: LinuxWorld San Francisco

Karsten Wade put out a help wanted call [1] for the Fedora booth at LinuxWorld San Francisco. If you are in the area and wnat to help out, please check the mailing list post [1] for details or the wiki page [2].

[1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg00412.html

[2] https://fedoraproject.org/wiki/Events/LinuxWorld_SF_2008


Event Report: Lindependence 2008

Karsten Wade reported [1] on Lindependence 2008 on the ambassador mailing list. THis event was in Felton, California and was an attempt to get an entire town to switch to FOSS alternatives.

[1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg00381.html


Event Report: Palmetto Open Source Software Conference

David Nalley posted [1] his event report covering the Palmetto Open Source Software Conference. This was a first year event and included a talk by Greg DeKoenigsberg and included an imprompt Fedora booth.

[1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg00375.html


Developments

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

Contributing Writer: Oisin Feeley

How Maintainers Can Help Reduce XULRunner Breakage

The recent breakage of many packages which depend on xulrunner (see FWN#136 "XULRunner Security Update Breakage Stimulates Bodhi Discussion"[1]) was addressed[2] in a post by Will Woods. Will reported that a QA meeting involving Christopher Aillon (caillon), as Firefox/XULRunner maintainer, had investigated the problem and produced an explanation and some recommendations for other package maintainers. As Christopher was unavailable for a week Will was relaying the information in the hope that some fixes could be made in his absence.

[1] http://fedoraproject.org/wiki/FWN/Issue136#XULRunner_Security_Update_Breakage_Stimulates_Bodhi_Discussion

[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01682.html

The reason that some xulrunner-dependent packages were affected and others not was that xulrunner provides both a stable API gecko-devel and an unstable API gecko-devel-unstable. Will noted that BuildRequires of xulrunner-devel or xulrunner-devel-unstable should no longer be used and instead that gecko equivalents should replace them.

Packages using the stable API were unaffected by the update of xulrunner. Will stated that "[t]he unstable API could change at any time, so if your app is using the unstable API it must be rebuilt *every time* xulrunner is updated." It was recommended that packages that used the stable API should use the following in their specfiles:

Requires: gecko-libs >= 1.9
BuildRequires: gecko-devel >= 1.9

and that those using the unstable API should use: 

%define gecko_ver 1.9.0.1
Requires: gecko-libs = %{gecko_ver}
BuildRequires: gecko-devel-unstable = %{gecko_ver}

Lastly an important request was made of package maintainers: "if your package uses the -unstable API, please send caillon redhat com a note, and *please* consider adding him to the ACL (or opening it entirely). He keeps tabs on all packages requiring the unstable API so they can all be rebuilt for each security update."

Braden McDaniel wondered[3] why the same headers, but with different pathnames, were provided by xulrunner-devel-unstable and xulrunner-devel and Ville-PekkaVainio had[4] the same question.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01684.html

In response to the suggested BuildRequires Douglas Warner requested[5] that a Provides: gecko-libs-api = 1.9 be added to xulrunner so that dependent packages would break if xulrunner were bumped to a new version which was not compatible: "For example, I can't do: Requires: gecko-libs < 2.0 Because I'm not guaranteed that the next version will *be* 2.0 (it might be 1.10, for example)." Rex Dieter independently came[6] to the same conclusion. Denis Leroy begged[7] that xulrunner would use "libtool-style soname versions like all other libraries in Fedora? So we don't need to add the version numbers in the spec file in the first place." Denis thought that xulrunner would fail a standard Fedora package review.

[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01686.html

NEVR Again

Another report detailing broken upgrade paths was posted[1] by Jesse Keating's script (see FWN#136 "Broken Upgrade Paths Due to NEVR"[2]). This time it reported those packages which failed the path "f8-final -> dist-f8-updates -> dist-f8-updates-testing -> dist-f9-updates -> dist-f9-updates-testing -> dist-f10" and seventy-eight packages were listed. Also included as per last week's discussion was an ordering of the list per-builder as opposed to per-owner. Jesse requested[3] feedback from recipients of the automated email warnings if problems are encountered.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01525.html

[2] NEVR stands for Name, Epoch, Version, Release. http://fedoraproject.org/wiki/FWN/Issue136#Broken_Upgrade_Paths_Due_to_NEVR

[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01526.html

Stephen Warren was concerned[4] that the upgrade path did not include the GA release of dist-f9: "Shouldn't dist-f9-final (or whatever the correct name is) be inserted in this path list between dist-f8-updates-testing and dist-f9- updates?" This led to an interesting exchange with Kevin Kofler who argued[5] that the converse should be expected and it was desirable that updates to Fedora 8 would have higher EVRs than the packages which were released for "dist-f9". Stephen argued[6] that it would make it easier to backport fixes if bumping of the release number rather than the version number were preferred and suggested changing what he understood to be Fedora's policies. KevinKofler disagreed[7] both with Stephen's description of current Fedora practices and also with his desire to reduce version bumps. He listed several situations in which these bumps would be useful and suggested that it was such version upgrades which uniquely distinguished Fedora from Debian "stable" or Red Hat EL.

[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01527.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01529.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01539.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01553.html

The possibility that simultaneous updates would be released to all branches was discussed[8] by Kevin Kofler and Jesse Keating. Although Jesse thought this was a corner case and that it was best to let the maintainer decide Kevin was motivated[9] to write a patch as it was in his experience a common problem. Kevin thought that if Jesse wanted to avoid spamming maintainers with bogus reports then his patch would remove about thirty-nine percent of the volume. Jesse was grateful and excused[10] himself from looking at the patch for a week due to the pressure of releasing the alpha of Fedora 10.

[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01572.html

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

[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01595.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01685.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01728.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01708.html

Slimming Down Java by Sub-Packaging AOT

A request to separate out the AOT[1] parts of Java packages into sub-packages was made[2] by Caolan McNamara. He estimated that it would be possible to remove circa 45 Mb (in /usr/lib/gcj) as OpenJDK tended to be installed anyway due to the web plugin.

[1] AOT stands for Ahead-Of-Time. This refers to the static compilation of the program to produce native code which runs without the potential run-time performance hit imposed by JIT. JIT stands for Just-In-Time and refers to dynamic compilation of each method of a Java program immediately before execution. Although there are techniques to speed up JIT, by identifying "hot" frequently called methods and caching them[2a], in general it is believed to be sub-optimal for GUI-based programs.

[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01763.html

[2a] http://en.wikipedia.org/wiki/HotSpot

Andrew Haley and Andrew Overholt expressed[3] skepticism that users would realize that they needed the gcj AOT-compiled code in order to get good performance. Andrew Overholt stated "one of the reasons we didn't do this to begin with was because RPM has no notion of Suggests or Recommends like dpkg does. Debian went this route, but I've seen reports of people not realizing they needed to install the associated -gcj package."

[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01769.html

The advantages of maintaining both AOT and JIT compilation were argued[4] by Colin Walters. Among the reasons listed by Colin for keeping a JIT were: "many apps will continue to load code at runtime from sources that are not Fedora. Think unpackaged Eclipse plugins for just a start" and that "[a] JIT also has a lot more interesting information than a normal AOT model. Hotspot does a lot of cool things there." Colin suggested that "profile driven optimizations",based on work done in 2001 by JanHubicka (SuSE), Richard Henderson (Red Hat) and AndreasJaeger (SuSE), might be a way to improve the performance of JITted programs. On the other hand he recognized that AOT compilation was useful "because having Hotspot re-profile and recompile the Eclipse core on everyone's computer is a bit of a waste." Colin followed up[5] with a putative infrastructure plan involving modifying Koji to create a new repository of optimized versions of select applications and a YUM plugin which feeds HotSpot profile data from individuals back to a central server which in turn is used to further optimize the compilations. Jeff Spaleta wanted[6] to know if this new repository would be disabled by default. Toshio Kuratomi was concerned[7] that Koji should maintain its ability to create a precisely audited build.

[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01774.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01775.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01792.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01795.html

Rawhide Network Breakage Due to Wireless Drivers

A puzzled Richard Jones asked[1] if anyone else had experienced bizarre networking failures apparently due to DNS lookup failures for web browsers but not for command line tools. Several confirmations were posted and Dan Williams warned[2] that "all mac80211-based drivers (b43, b43-legacy, iwl3945, iwl4965, ath5k, rt2x00)" were broken due to upstream patching of multiqueue functionality.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01788.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01801.html

Ralf Etzinger asked[3] if failure to associate with an Access Point was one of those expected pieces of "random weirdness." In response to a follow-up question from Michael Solberg about a failure to associate using kernel-2.6.25.10-47.fc8 Dan added[4] that only Rawhide kernels should be affected.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00000.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00008.html

Possible Slippage of Fedora 10 Alpha?

A brief note from Jesse Keating on Friday requested[1] an IRC meeting with spin owners, QA, Kernel and other concerned parties to discuss the problem that "split media"[2] was not working currently. As the Alpha release is scheduled[3] for August 5th it seems as though there is little time to solve this problem.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00005.html

[2] The ability to break a set of RPM packages into media images to be used by anaconda during installation is a difficult one. Currently it is handled by the pungi module https://hosted.fedoraproject.org/pungi/wiki/PungiDocs/PungiDocs

[3] http://fedoraproject.org/wiki/Releases/10/Schedule

In an aside Jesse referred to the problem that the "Alphas" are currently hidden away from the general community and that he would like to address this at a subsequent ReleaseEngineering meeting.

Infrastructure

This section contains the discussion happening on the fedora-infrastructure-list

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: HuzaifaSidhpurwala

Email aliases and new cvs requests

Toshio Kuratomi writes for fedora-infrastructure-list [1]

Last week Seth implemented email aliases for the people who should be notified of changes to packages. Toshio used this new functionality to have getnotifylist, which looks up who to notify on cvs commits, stop querying the pkgdb directly (a slow operation with multiple points where it could fail) and instead just construct the alias from the packagename.

[1] https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg00104.html

YUM security issues...

Toshio Kuratomi writes for fedora-infrastructure-list [2]

This is a re-post from Josh Bressers. Justin asked if the ability for mirror admins to select a subnet where they'll serve all of the traffic has been removed? There is a particular concern about this issue in the short term. There is a paper about this also [3]

[2] https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg00082.html

[3] http://www.cs.arizona.edu/people/justin/packagemanagersecurity/

cvsextras renamed to packager

Toshio Kuratomi writes for fedora-infrastructure-list [4]

cvsextras has been renamed to packager. Any scripts that depends on querying the "cvsextras" group will now need to query "packager".

[4] https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg00128.html

Server Monitoring - A replacement for Nagios?

Nigel Jones writes for fedora-infrastructure-list [5]

While this was intended to be a primary discussion point for the Infrastructure meeting there was a little bit of discussion first in #fedora-admin, and then in #fedora-meeting regarding Zabbix, a tool like Nagios that Nigel begun to setup for testing this week.

[5] https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg00143.html

Artwork

In this section, we cover the Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: Nicu Buculei

New Posters Needed for Fedora

Paul Frields asked[1] on @fedora-art-list about a new series of posters: "'Infinity / Freedom / Voice' has been a powerful message and an excellent way to characterize the themes that went into the Fedora logo. The logo has become a completely identifiable brand for us, and the original 'triptych' posters for these themes have allowed our brand to grow throughout the community. Now, it's time for us to build a revitalized message around the more concrete themes that characterize the entire Fedora Project as a whole."

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

Mairín Duffy came up[2] with a concept fitting one of the Fedora 10 theme proposals: "I'm wondering if this could be tied into the F10 artwork theme.... I've been sketching up some steampunky doodles lately. Maybe I'll do some along these lines. Here are some steampunk-inspired ideas" (following with a list of ideas[2]) and after receiving positive feedback even with a graphic sketch [3].

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

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

A T-shirt Design for the Upcoming FUDCon in Brno

Max Spevack asked[1] on @fedora-art-list for a T-shirt design for the Brno FUDCon: "Since you guys did such an awesome job on the FUDCon Boston shirts, I was wondering if you'd be willing to make a few mock-ups of what a FUDCon Brno shirt would look like. I like the idea of trying to have a bit of design consistency for each year's FUDCon shirts... so maybe we could keep the front the same (switching the name of course) and doing something 'similar' on the back?"

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

The request was quickly followed[2] by a design by Nicu Buculei using, as requested, the same template as the recent FUDCon in Boston, a design which is generally liked. The discuss touched[3] on a hunt for usable Brno photos and a number of pieces of technical advice[4] from Mairín Duffy about vectorizing photos.

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

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

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

The Blue Color of Fedora

Paul Frields started an interesting debate[1] about the dominant color used in Fedora graphics: "Does the Artwork team think, overall, that using a blue palette for our desktop theme (background) helps Fedora with its identity and branding? Do you want to continue that for Fedora 10?"

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

A large chorus of contributors to the Art Team expressed their support for using blue, one of the most convincing arguments came from Max Spevack[2]:"Blue = Fedora. Mix in some other stuff as appropriate, but I believe that Blue is now 'our' color. We shouldn't give that up. Ubuntu has brown, OpenSuse has green. Red Hat has red. We have blue. Personally, I like that we maintain that general blue-ish feel. Play with the shades if you like, mix in some spice and variety if you like, but I think Fedora should always be identifiable with the color blue."

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

Of course there are different opinions, like the one voiced[3] by David Nielsen: "As a user I would love to see us break free of the blue prison, it looks dated and should be put down with all manners of mercy possible. I think it hurts us to stick with the blue theme and unlike other competing distros not work towards a unified look over several cycles."

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

Security Week

In this section, we highlight the security stories from the week in Fedora.

Contributing Writer: JoshBressers

Last week wasn't very exciting as far as security issues go. I have nothing of interest to note. Next week should be quite busy though.

Black Hat[1] and DEFCON[2] are going on in Las Vegas. Things are expected to be very busy[3].

[1] http://www.blackhat.com/
[2] https://www.defcon.org/
[3] http://www.networkworld.com/news/2008/073108-black-hat.html?hpg1

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-install Remote Guest Creation

Cole Robinson took[1] a stab at implementing remote guest creation in virt-install. The main unresolved issue was storage. How to detect it and how to allow the user to specify it. Michael DeHaan was interested[2] in teaching koan to install on remote hosts and also focused on the question of storage specification.

[1] https://www.redhat.com/archives/et-mgmt-tools/2008-July/msg00277.html

[2] https://www.redhat.com/archives/et-mgmt-tools/2008-July/msg00278.html

The discussion of storage specification dovetails with the concurrent discussion of Storage Pool Discovery on @libvir-list (covered below) and a previous thread[3] on libvirt storage xml.

[3] https://www.redhat.com/archives/et-mgmt-tools/2008-July/msg00235.html

Fedora Xen List

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

kernel-xen is Dead

Mark McLoughlin wrote[1] to say the kernel-xen package is dead. That is to say the kernel package can now support x86 and x86_64 domU guests and kernel-xen will be dropped from Rawhide. Hiding between those lines is the fact that there is currently no Dom0 kernel in Fedora 9 or Rawhide. Without such a Dom0 kernel a domU must be booted via a paravirt_ops kernel or with the KVM-based xenner.

[1] https://www.redhat.com/archives/fedora-xen/2008-July/msg00044.html

The conversation then turned to the matter of migrating away from Xen and support for systems without hardware virtualization. Paul Wouters asked[2] if there was a howto for migration to KVM. It seemed there is not, but all are encouraged to provide one.

[2] https://www.redhat.com/archives/fedora-xen/2008-July/msg00046.html

Alain Williams realized that Fedora 9 has no Dom0 support after installing it. When he asked why Mark McLoughlin pointed[3] out the problems with kernel-xen being based on a much older kernel than kernel creating a time sink, so the decision was made to re-base to the upstream kernel which supports paravirt_ops. This decision was first announced[4] back in Nov 2007 by Daniel Berrange. Mark McLoughlin also stated[3] that Dom0 support at Fedora 10 launch looks unlikely. Fortunately we have more positive news on that front below.

[3] https://www.redhat.com/archives/fedora-xen/2008-July/msg00048.html

[4] https://www.redhat.com/archives/fedora-xen/2007-November/msg00106.html

Dale Bewley bemoaned[5] the fact that he has no budget to upgrade to HVM capable hardware and will have to stick on Fedora 8 until Fedora 10 has Dom0 support. Stephen Smoogen pointed[6] out that RHEL5 and CentOS5 are options for Dom0 on non-HVM hardware. Daniel Berrange expressed[7] some empathy and the desire for such support, but reiterated it isn't viable until Dom0 is ported to pv_ops.

[5] https://www.redhat.com/archives/fedora-xen/2008-July/msg00049.html

[6] https://www.redhat.com/archives/fedora-xen/2008-July/msg00052.html

[7] https://www.redhat.com/archives/fedora-xen/2008-July/msg00053.html

State of Xen in Upstream Linux

Pasi Kärkkäinen thoughtfully forwarded[1] a long detailed xen kernel status message which was sent to the @xen-devel-list by Jeremy Fitzhardinge. Jeremy pointed out that mainline kernel is at 2.6.27-rc1 and his current patch stack is pretty much empty after being merged into linux-2.6.git.

[1] https://www.redhat.com/archives/fedora-xen/2008-July/msg00058.html

Jeremy stated that Fedora 9's kernel-xen package was based on the mainline kernel even though it's been a separate package. Now that kernel-xen has been dropped from rawhide there will be only one kernel package in Fedora 10. Jeremy said his focus in the next kernel development window will be obvious missing dom0 support with the hope it will be merged into 2.6.28. That work will likely take place in a xen.git on Xen.org. Jeremy then provided his long TODO list with a request for help fullfilling it. In addition he asked what's missing.

Paul Wouters followed up[2] on Jeremy's question of "What's missing?" with the answer of a lack of entropy in the guests. Daniel Berrange mentioned Rusty Russell's VirtIO-RNG patch from this thread. Thorsten Leemhuis provided a link to this LWN article on the subject of entropy sources and showed that this patch is in 2.6.26.

[2] https://www.redhat.com/archives/fedora-xen/2008-July/msg00059.html

[3] https://www.redhat.com/archives/fedora-xen/2008-August/msg00000.html

Creating Multiple Xen Bridges

Andy Burns asked[1] for a clean way to utilize the two NICs in a Dom0 server as multiple bridges. Kanwar Sandhu recommended[2] editing xend-config.sxp to utilize a very small custom network-bridge-wrapper script also provided in the post. Another option pointed[3] out on the list was to short-circuit xend-config.sxp and configure all networking by hand in /etc/sysconfig/network-scripts.

[1] https://www.redhat.com/archives/fedora-xen/2008-August/msg00004.html

[2] https://www.redhat.com/archives/fedora-xen/2008-August/msg00005.html

[3] https://www.redhat.com/archives/fedora-xen/2008-August/msg00008.html

Libvirt List

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

PATCH: Storage Pool Discovery

David Lively refered[1] to a post[2] on "Storage Management APIs" by Daniel Berrange when he posted a patch to implement virConnectDiscoverStoragePools. As the API continues to be solidified, this patch implements discovery for only logical and netfs storage pools.

Daniel Berrange pointed[3] to the Storage Management page on libvirt.org as an appropriate place to document the XML used for srcSpec.

[1] https://www.redhat.com/archives/libvir-list/2008-July/msg00502.html

[2] http://www.redhat.com/archives/libvir-list/2008-February/msg00107.html

[3] https://www.redhat.com/archives/libvir-list/2008-August/msg00013.html

PATCH: Fix Setting of Bridge Forward-delay

Christoph Höger described[1] a problem which caused a bridge to not pass traffic for a number of seconds after activation. Just a few minutes later Daniel Berrange posted[2] a fix for a bug which caused libvirt to ignore the forwarding delay when it was set to 0. The workaround in the meantime is to set fd=1.

[1] https://www.redhat.com/archives/libvir-list/2008-August/msg00017.html

[2] https://www.redhat.com/archives/libvir-list/2008-August/msg00020.html

Daniel Veillard plus-oned[3] that patch and expressed that with the last release having been on June 25th, it may be time for a new release. Daniel Berrange mentioned[4] that the Xen & QEMU refactoring needs more testing, and the LXC and OpenVZ drivers need porting to the new XML routines. Richard W.M. Jones wanted[5] to get virsh edit in. The last word[6] was to delay another week.

[3] https://www.redhat.com/archives/libvir-list/2008-August/msg00025.html

[4] https://www.redhat.com/archives/libvir-list/2008-August/msg00030.html

[5] https://www.redhat.com/archives/libvir-list/2008-August/msg00034.html

[6] https://www.redhat.com/archives/libvir-list/2008-August/msg00036.html

oVirt Devel List

This section contains the discussion happening on the ovirt-devel list.

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