< FWN
Fedora Weekly News Issue 142
Welcome to Fedora Weekly News Issue 142 for the week ending September 7, 2008.
http://fedoraproject.org/wiki/FWN/Issue142
This week in Announcements we alert you to the "Fedora 10 Beta Freeze Coming Soon" and the new "FESCo Issue Tracking". In PlanetFedora "Tech Tidbits" contains some juicy morsels on evaluating package sizes and Haskell. In Developments we examine the process of "Getting Back On Our Feet" after the intrusions. SecurityAnnouncements finally has some content. Artwork covers "Working on a Sound Theme" and the acceptance of the "Echo Icon Theme as a Fedora 10 Feature"
Fedora Weekly News keeps you updated with the latest issues, events and activities in the Fedora community. 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
Echo Monthly News, Issue 1
Martin Sourada announced[0] the availability of the premiere issue of "Echo Monthly News[1]." Said Martin, "Since it's our first release it is not perfect and therefore we will appreciate any feedback, suggestions for improvement, etc. at the fedora-art-list and #fedora-art at irc.freenode.net."
[0] http://www.redhat.com/archives/fedora-announce-list/2008-September/msg00001.html
[1] https://fedorahosted.org/echo-icon-theme/wiki/MonthlyNews/Issue1
Fedora 10 Beta Freeze Coming Soon
Jesse Keating discussed[2] the Fedora 10 Beta schedule. "The new freeze date is Sept. 9, which is in 7 days. This is a friendly reminder that the freeze is coming up, and coming up quickly. I realize that rawhide has been less than great lately, and we're working quite hard to fix the issues."
[2] http://www.redhat.com/archives/fedora-devel-announce/2008-September/msg00000.html
Fedora 8 and 9 Updates Status
Jesse Keating wrote[3] about the status of updates on Fedora 8 and Fedora 9. "We have done a successful compose of all the existing and as of yesterday pending updates for Fedora 8 and Fedora 9, all signed with our new keys. These updates will soon hit mirrors in a new set of directory locations. What we don't have quite yet is the updated fedora-release package in the old updates location that will get you the new keys and the new repo locations. The last mile testing of this update requires that new updates be live on the mirrors."
For the full announcement, follow the link below.
[3] http://www.redhat.com/archives/fedora-announce-list/2008-September/msg00002.html
FESCo Issue Tracking
Kevin Fenzi announced[4] the new FESCo issue-tracking tool. "In the past, interested parties could bring matters to the attention of FESCo in several ways: Mailing the chair, following up to the schedule posting on the devel list asking for a new topic to be added, or attending meetings on irc and bringing up the topic at the end of the meeting in the Open Discussion phase.
While these methods work well for issues that simply need a bit of discussion and a decision, longer term issues that should be tracked and discussed further sometimes are forgotten."
[4] http://www.redhat.com/archives/fedora-announce-list/2008-September/msg00003.html
Planet Fedora
In this section, we cover the highlights of Planet Fedora - an aggregation of blogs from Fedora contributors worldwide.
http://planet.fedoraproject.org
Contributing Writer: Max Spevack
Cambridge
John Poelstra wrote[0] about the revised Fedora 10 schedule, which as been moved to account for the infrastructure problems that we faced a few weeks ago. "Last week the Fedora Engineering Steering Committee (FESCo) ratified the updated schedule proposed by the Release Engineering team. This resulted in feature freeze for Fedora moving to 2008-09-09 and GA to 2008-11-18. This three week change to the schedule was to accommodate the recent infrastructure outages."
[0] http://poelcat.wordpress.com/2008/09/02/fedora-10-schedule-update/
Another Fedora Test Day is in the books, and James Laska wrote[1] about it on his blog. "There was a really strong developer turn out for this Test Day. In addition to David Huff, the appliance-tools developer, some of the oVirt team showed up to help walk through oVirt's use of appliance-tools. This was tremendously helpful to see how appliance-tools can be used by other projects. Thanks to Alan Pevec, Bryan Kearney and Darryl Pierce from the oVirt team for joining the event. Having such a tight feedback loop with the developers during Test Days has been very helpful, I hope we can continue with that format."
[1] http://jlaska.livejournal.com/1444.html
Artwork
Nicu Buculei posted[2] the latest iterations of some of the potential Fedora 10 artwork themes. "The second round in the process of creating a visual theme for Fedora 10 ended yesterday, those are the proposals meeting the requirement and which will pass into the third (last) round (listed in chronological order)."
Your beat writer is particularly fond of the Gears/Steampunk theme as well as the Solar theme, but thinks that all four are fantastic pieces of art, and should be carried over into Fedora 11's proposals.
[2] http://nicubunu.blogspot.com/2008/09/fedora-10-themes-round-2.html
Tech Tidbits
Yaakov Nemoy reported[3] on the state of Haskell in Fedora. "After nearly 9 months, I am finally at the point I wanted to be regarding Haskell. Last January i wanted to submit packages for my favourite window manager to Fedora. I got blocked because of a lack of packaging guidelines and familiarity with Haskell or the Glasgow Haskell Compiler."
[3] http://loupgaroublond.blogspot.com/2008/09/finally-done-with-haskell-things.html
Continuing his habit of posting yum-related tutorials, James Antill posted[4] a quick explanation of packages sizes in yum and rpm.
"It's pretty common to think that a specific thing always has a specific size, and people tend to think of an "rpm package" as a single object thus. the it's common to ask what is "the size of an rpm". However if you have a 1MB text file, and gzip compresses it to 50KB which you then upload to a HTTP server you now have at least 3 different sizes: text size; compressed size and upload size (includes HTTP headers etc.) and asking for the size. So it is with rpm packages, and their many sizes."
[4] http://illiterat.livejournal.com/6439.html
FUDCon Brno
FUDCon Brno is happening as Fedora Weekly News freezes, but there are a bunch of photos online[5] and Max Spevack has been providing frequent updates[6] about the event on his blog.
[5] http://flickr.com/groups/fudconbrno/pool/
[6] http://spevack.livejournal.com
Developments
In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
Getting Back on our Feet
On 05-09-2008 Jesse Keating posted[1] the good news that "[...] we have done a successful compose of all the existing[,] and as of yesterday[,] pending updates for Fedora 8 and Fedora 9, all signed with our new keys." He cautioned that the size of this backlog of updates meant that it would take some time to get them out to mirrors. The updates will be in new directory locations and there will be an "[...] updated fedora-release package in the old updates location that will get you the new keys and the new repo locations."
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00329.html
Jesse was keen to point out that there would be a FAQ to which we can all contribute and that its location will be announced shortly.
Sean Darcy, after thanking Jesse for all the work he had put in, asked[2] how he could get the new key for updates right now without having to wait for the fedora-release package to be placed in the old repository location. A variety of answers followed and the canonical one appeared[3] to be that given by Todd Zullinger in which he suggested obtaining fedora-release from CVS and then checking that the fingerprints matched those published[4] on the FedoraProject website. Some minor confusion followed[5] as the example presented on the web page uses the old key signed by "fedora@redhat.com" but the new key is signed by "fedora@fedoraproject.org". Similarly the use of "PUBKEY" as a placeholder variable on the web page caused some difficulties which Todd cleared[6] up again.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00392.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00396.html
[4] https://fedoraproject.org/keys
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00406.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00417.html
Jeffrey Ollie made[7] the good point that using a GPG WoT would make it easier for Fedorans to have confidence that they had obtained the correct key and hoped that those at the Brno FUDCon could "arrange an impromptu keysigning[.]"
[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00411.html
Early in the week on 02-09-2008 Stefan Grosse asked[8] politely when the resigned Fedora 9 updates would be available. Bruno Wolff III suggested[9] "If you are worried about something in particular, you can look at bodhi to see pending updates and updates-testing and get rpms from koji if there is something you want right now." A brief discussion between Till Maas, Jesse Keating and Bruno Wolff explored whether it was possible to download from Koji using SSL if one did not have a FAS account. Bruno testified[10] "I needed certs (two from fedora and mine) to get the bodhi client to work. I used this to grab a list of stable updates last week [...] I didn't bother with ssl when grabbing them from koji." Till was[11] using wget to grab the packages from Koji and found it necessary to use certificates. Jesse showed[12] that it was possible to do a koji download-build to get packages anonymously.
[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00083.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00086.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00089.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00092.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00096.html
In a separate thread Jesse Keating announced[13] that the revised Fedora 10 freeze date would be 09-09-2008 and as part of a friendly reminder that it was coming up quickly observed "I realize that rawhide has been less than great lately, and we're working quite hard to fix the issues. The installer images from the 30th may be of use in getting rawhide installed and then updating to what is in the public repos. See http://kojipkgs.fedoraproject.org/mash/rawhide20080830/development/ (please only grab the installer images from there, not the entire tree)." Matt Miller reported[14] a successful net install from the Fedora 10 alpha images using the rawhide repository.
[13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00091.html
[14] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00107.html
Removing Packages with Long-standing FTBFS Failures
Matt Domsch posted[1] a list of ninety packages which "Fail To Build From Source" (FTBFS)[2]. Matt noted that some of these packages have failed since 02-2008 and that "[...] packages with unresolved FTBFS bugs immediately following the Alpha release will be removed from the distribution" in line with a proposal passed by FESCo. He asked that concerned parties help to resolve the problems and noted that several of them had easy fixes.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00319.html
[2] http://fedoraproject.org/wiki/FTBFS
Response was fairly quick and positive from both those listed as maintainers and concerned parties that needed the packages in Fedora 10.
One interesting ramification of the removal of such packages was mentioned[3] by Daniel Berrange who asserted "[t]his list is far from complete - if you want to remove these 90, the dependency chain ripple, will entail the removal of tonnes of other packages which depend on these." He asked Matt to generate a report which "[...] shows the ripple effect for each proposed package. If something is just a leaf-node, it isn't very important to worry about, but if something triggers removal of 50 dependant packages that's pretty damn important to fix. This info would be useful in prioritizing which builds need fixing most urgently." SethVidal modified[4] a script written by James Antill so that it did exactly that and Matt posted[5] a link to the script and an example run. Till Maas suggested[6] that it would be useful make sure that a src.rpm responsible for several dependent packages is only counted once.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00320.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00363.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00361.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00371.html
The practical consequence of neglecting such dependencies was highlighted[7] by Matthias Clasen when he commented that "djvulibre-devel is a BuildRequires for evince. If you remove djvulibre, evince will become unbuildable." Jesse Keating responded that Daniel, or his team should fix the package as "[i]f we have to do a chained rebuild for various reasons, evince would fail due to this package not building first."
[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00323.html
The inclusion of monodevelop in the list had the side effect of spurring the Mono maintainers including Michel Salim, David Nielsen and Paul Johnson to decide[8] to attempt a co-ordinated push of "Mono-2.0".
[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00385.html
MinGW on Fedora
The availability of a MinGW development repository was announced[1] by Richard Jones. "MinGW" provides a GNU toolchain on Windows allowing the development of Free native Windows binaries. Richard credited Daniel Berrange with a good deal of the work.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00296.html
In response to Farkas Levente's question, as to when it would be available in Fedora, Daniel replied[2] that due to the need for "infrastructure" to create a separate repository and dedicated build root it was impossible to predict. Jef Spaleta seemed[3] to be trying to move the process forward and published a draft which explained that "[t]he initial impetus for this effort has been ovirt developers who desire to more easily use Fedora installations as development environments for the work they are doing to build open source cross-platform virtualization tools." The possible impact on FedoraProject resources appears to have led to the compromise of creating a separate repository which could be strictly confined in size.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00298.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00364.html
Richard Jones encouraged[4] Farkas to try out MinGW without waiting for official inclusion in Fedora "[...] if you want to download and play with it, and send patches :-) It's currently buildable on Rawhide, and possibly on earlier versions of Fedora too." Farkas then revealed that he currently used an older MinGW on RHEL5 and Richard responded[5] that although there were no srpms at this moment it should be possible to use the specfiles and patches (both in the mercurial repository[6]) to rebuild everything.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00300.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00330.html
[6] http://hg.et.redhat.com/misc/fedora-mingw--devel/
Dependency Loops Considered Harmful?
[[MiroslavLichvar|Miroslav Lichvar] raised[1] the issue of a considerable number of packages (354 by his count) which are components of dependency loops in the rawhide repository. Miroslav provided[2] a list. In such loops two or more RPM packages require each other as dependencies in their spec files with the result that it can become confusing for users trying to remove selected packages manually with yum or rpm. Miroslav wondered whether such loops were acceptable and specifically "why games data depend on binaries?"
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00149.html
[2] http://fedorapeople.org/~mlichvar/tmp/rawhide.i386.loops
A substantial conversation resulted which exposed the different needs of packagers and users, some possible limitations due to the design of rpm and varied philosophies concerning the correct way to specify dependencies. One of the central examples chosen were the game packages which tend to be split into a "binary" or "engine" package and a companion "data" package for graphics, sound and levels. The central concerns expressed were that occasionally an install followed by a remove will leave "orphaned" packages behind. Also in contention was the specific case of developers experiencing the problem of maintaining a stable environment when there is no easy way of tracking changes to system libraries. The package manager aptitude was mentioned favorably due to its ability to distinguish between packages installed automatically to satisfy dependencies and those which are installed manually.
On the one hand Chris Snook and Michael Schwendt advocated[3] that instead of using Requires: foo >= X in their spec files packagers should choose Conflicts: foo < X . The possible downside to this would be installing game data yet having no game engine/binary installed. This was seen as a non-serious problem.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00211.html
On the other hand Jon Ciesla argued[4] that the advantage of having games data depend on their binaries from a packagers perspective is that it ensures that attempting to upgrade the binary Version without also upgrading the data will fail. The case of allowing minor fixes without forcing users to download a big bundle of data can be handled by bumping the Release of the package. More concisely he answered[5] that the reason for the dependencies was that "[...] so when you remove the game, you remove the data." Michael responded[6] that Jon's example could be handled by using a Requires: foo-data = X without exposing the increased risk of needing to "bump'n'rebuld" the data package each time the engine package incremented its Version while still working with the same data. He characterized such dependencies as "superfluous [...] try[ing] to enhance 'yum remove'."
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00150.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00151.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00161.html
This was not accepted as accurate by Jon and he described the current situation as "require on name and version" for game data which allows Release to be changed without affecting the match on Name and Version "If new data is required, it will change the version. If not, we only increment the binary rpm's release, so the data rpm matches on version and needs no rebuild." Michael responded[7] by laying out two cases, the first of which illustrated the problem of having to update the data package solely to keep in step with updates to the version so that yum remove would function properly. His alternate case used non-versioned dependencies in the data package and strict dependencies in the engine package. Hans de Goede seemed a bit irritated and asked Michael to "Please take an actual look at game spec files before making up all kinds of BS, it's really easy" and argued that for games there was a one-to-one mapping between the engine and the data. He added that just because other cases resulted in dependencies being sucked in by an install and left behind on a remove there was no reason to change the way things were done for games.
[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00167.html
Stephen Gallagher suggested that the "groups" exposed through yum should be used to bundle together the multiple packages for an application instead of using looped dependencies to which Callum Lerwick replied[8] that it was actually time to "implement the per-package 'explicitly installed/pulled in as a dep' flag that has been discussed several times in the past, and is already implemented (thus proven) in the 'aptitude' apt front end." He followed this with an amusing piece of hyperbole about "the looming dark future of closed DRM-laden content delivery services[.]"
[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00193.html
Toshio Kuratomi raised[9] the problem faced by developers using system libraries that could come and go due to packages being updated or removed. Callum's suggestion was[10] that developers should be "RPM packag[ing] your app. Apps on your system that are not tracked by RPM are a ticking time bomb of dependency breakage whether or not the 'leaf culling' is performed manually or is assisted by a 'pulled in as dep' flag. A package or distribution update could very well break your app too." Needless to say Toshio had[11] several objections to this including the impact on developer workflow imposed by packaging up everything and the inadvisability of forcing developers to become expert administrators. He suggested that "If we implement this, it needs to be at a low enough level that anyone installing packages on the system will be storing the information. That could mean rpm (since rpm is responsible for taking the package and turning it into files on the filesystem) or that could mean yum since yum is the one that actually knows whether a package is being installed due to depsolving or user request. Doing this at a higher level means that information gets lost (for instance, if you do this in PackageKit, there won't be any information about what anaconda chose to install due to checkboxes being clicked and which things were installed due to dependencies). With that said, there needs to be a way for a developer to tell yum not to prune away leaf packages if they want." A very detailed and amusing discussion with (among others) Matthew Woehlke followed in which Matthew argued[12] for a script which essentially produced a parallel iuserj rpm database so that quick and dirty rpms could be produced locally for developers.
[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00195.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00209.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00214.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00278.html
Jef Spaleta wondered[13] what actual examples revealed about the amount of harddrive space being consumed by dependencies and remarked "I hope the packagekit people are watching this discussion. The game data subpackaging issue should be right up their ally in terms of end-user ease of use issues." He discounted the polluting of the packagelist but MichaelSchwendt pointed out[14] that as the packagelist increases then "[because of] the frequent updates common in Fedora land, you need to download and update more[.]"
[13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00162.html
[14] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00170.html
The idea of keeping game data outside of any package management was mentioned[15] by James Antill as an "obvious fix" and he discounted the probability of PackageKit being able to do anything about the issue if yum or rpm could not. Jef responded[16] that "[a]t some point someone is going to have to wade into rpm itself for ease of use of removals to get better" and pointed out that he was "[...] making sure that the people with the right motivation and the right skills find the right way to handle it. That's not going to happen just by telling the current maintainers who are abusing the available requires syntax that they are abusing the syntax and slapping their wrists." Richard Hughes showed[17] that the PackageKit developers were indeed listening to the conversation and mentioned that he had considered "[...] running through a large "get-depends" output into the basename filter, so that the user only sees the 'applications' by default, rather than a huge list[.]"
[15] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00184.html
[16] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00185.html
[17] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00212.html
There is a lot more to this conversation than reported here, but the main thrust is that the limitations of rpm have resulted in package maintainers wrangling spec files to do what they want which in some cases has undesirable effects.
Fedora Security Tools Spin
A suggestion was made[1] by Huzaifa Sidhpurwala to produce a Security Tools spin similar to the "Knoppix Security Tools Distribution"[2] .
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00108.html
[2] http://knoppix-std.org/index.html
Todd Zullinger responded[3] that there was already a spin similar to this being curated by Luke Macken. The SecuritySpin[4] mentioned by Luke seemed to be roughly what Huzaifa was searching for, except that he thought it should have "more tools and [be] more bare bones".
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00110.html
[4] https://fedoraproject.org/wiki/SecuritySpin
Adrian Pilchowiec mentioned[5] a free fork of nessus named OpenVAS[6] as a desirable part of the spin. Luke drew[7] attention to the need for more people to help out with packaging missing tools. Subsequently the wishlist of the project recorded that Huzaifa was packaging up OpenVAS and labrea.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00275.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00183.html
Infrastructure
This section contains the discussion happening on the fedora-infrastructure-list
http://fedoraproject.org/wiki/Infrastructure
Contributing Writer: HuzaifaSidhpurwala
New Key Repo Locations v2
Warren Togami writes for fedora-infrastructure-list [1]
Warren sent out a mail enlisting the new repo locations. Also the repo names have been changed so debuginfo and source are always at the end.
[1] https://www.redhat.com/archives/fedora-infrastructure-list/2008-September/msg00001.html
archives on secondary1
Matt Domsch writes for fedora-infrastructure-list [2]
Matt asked if archives.fp.o is on secondary1.fp.o There are 2 separate rsyncd.conf files in puppet, one for archives,one for secondary. Given they land at the same place on the same machine, only the one for secondary is actually in effect. If they're going to be on the same machine, we need to merge them. On this Mike replied with an affirmative saying that they need to be merged.
[2] https://www.redhat.com/archives/fedora-infrastructure-list/2008-September/msg00030.html
Artwork
In this section, we cover the Fedora Artwork Project.
http://fedoraproject.org/wiki/Artwork
Contributing Writer: Nicu Buculei
Art Schedule for Fedora 10
JohnPoelstra showed[1] on @fedora-art a tentative schedule[2]for the Artwork activities and asked for help with it: "1) Which tasks no longer apply and should be removed 2) New tasks which should be added 3) Existing tasks that are wrong"
[1] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00388.html
[2] http://poelstra.fedorapeople.org/schedules/f-10/f-10-art-tasks.html
He received corrections about dates from MairinDuffy[3] and tasks from NicuBuculei[4]
[3] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00390.html
[4] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00001.html
Working on a Sound Theme
ChrisNorman uploaded[1] a first preview of a new desktop sound theme created for Fedora and he received[2] some feedback about length and content from NicuBuculei: "I am not sure about speaking the English word 'attention' - some people not speaking English may not be that happy. And maybe, just maybe, a few sounds, like 'window-close.wav' are a bit too long".
[1] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00012.html
[2] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00013.html
Echo Icon Theme as a Fedora 10 Feature
LuyaTshimbalanga reported[1] about FESCO acceptance of the new Echo icon set as a default in Fedora 10: "Fesco has accepted echo-icon-theme as default icon theme for Fedora 10.[1] Which means we need to push harder to include as many icons as possible using guideline and echo-artist tool now available on rawhide and is waiting for people to get them on both Fedora 8 and 9"
[1] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00028.html
MatthiasClasen outlined[2] the importance of having Echo as a default in the upcoming beta release "I think we need to act quickly to make Echo the default for the beta, to test the waters before F10" and soon after that he operated the change[3].
[2] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00044.html
[3] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00056.html
MartinSourada noted that the feature depends on the icon coverage "Just a note that Fesco (and many art team members as well) has some concerns about coverage. Simply said if we don't achieve the Mist/gnome icon themes coverage, we'll be rolled back to Mist and wait for another release" and offered to mentor new contributors.
[4] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00031.html
[5] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00069.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
As we recover from the disruptions to the infrastructure Security Advisories are starting to reappear. As of 07-09-2008 the following four advisories are however just the results of testing a push after all packages have been signed with the new GPG keys. Please see the Announcements and Developments sections of FWN for more information.
Fedora 9 Security Advisories
- samba-3.2.3-0.20.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00002.html
- wordpress-2.6.1-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00040.html
- bitlbee-1.2.2-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00045.html
Fedora 8 Security Advisories
- xastir-1.9.2-8.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00046.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
Use Avahi to Discover Local Servers in Virt-manager
Cole Robinson committed[1] a patch[2] to add support for avahi polling in the virt-manager 'Open Connection' dialog.
[1] https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00000.html
[2] https://www.redhat.com/archives/et-mgmt-tools/2008-August/msg00123.html
Virtio Support in Libvirt and Virt-manager
Emre Erenoglu asked[1] if virtio[2] would be supported in virt-manager. Daniel P. Berrange said[3] libvirt supports it as of 0.4.4 and virt-manager will soon automatically enable virtio for disks known to include it.
[1] https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00010.html
[2] http://kvm.qumranet.com/kvmwiki/Virtio
[3] https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00011.html
The design paradigm[4] for virt-manager is to allow selection of OS Type and Variant which informs the features to be enabled, rather than exposing individual features toggles. Cole Robinson agreed[5] exposing the option to enable virtio disks for an unknow virtio-enabled distribution might not be a bad idea.
[4] https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00013.html
[5] https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00015.html
New Virt-manager and Virtinst Releases Pending
Cole Robinson announced[1] that with the pending Fedora 10 beta freeze on Tuesday, September 9th new releases of virt-manager + virtinst are imminent. Daniel P. Berrange concurred[2] that libvirt would roll out a new release around that time as well.
[1] https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00002.html
[2] https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00005.html
Virt-install Patch for Disk Size and Sparse
Cole Robinson patched[1] virt-install's new --disk option to specify size of new storage, and whether it be create it as a sparse file.
[1] https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00004.html
Fedora Xen List
This section contains the discussion happening on the fedora-xen list.
Nothing to report this week.
Libvirt List
This section contains the discussion happening on the libvir-list.
Libvirt vs XenAPI
Atif Bajwa asked[1] about the advantages of using libvirt over XenAPI and what platforms libvirt supports. Atsushi Sakai pointed to a list[2] of which libvirt calls work on which drivers / hypervisors. Daniel P. Berrange replied[3] that libvirt is available for every major Linux distro, and listed several benefits such as:
- avoids locking applications to a particular hypervisor
- provides a guaranteed stable API that can be used both locally and remotely
- remote security options include SSL + x509 certificates, SSH tunnel, Kerberos GSSAPI single sign on, and username + password
- works with every version of Xen 3.0.x or later while XenAPI is only usable in Xen 3.1.0 and later
Richard W.M. Jones mentioned[4] that although there are no binaries yet, libvirt client code can be compiled on windows.
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00002.html
[2] http://libvirt.org/hvsupport.html
[3] https://www.redhat.com/archives/libvir-list/2008-September/msg00008.html
[4] https://www.redhat.com/archives/libvir-list/2008-September/msg00016.html
Latest MinGW Patches
Daniel P. Berrange posted[1] patches to allow building on F10 of libvirt-0.dll and virsh.exe which run successfully under Wine, provided only 'test' and 'remote' drivers are turned on.
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00065.html
Does Libvirtd Need to Always be Running
Yushu Yao asked[1] a basic question which may be helpful to point out. Does libvirtd need to always be running? Richard W.M. Jones answered[2] "yes and no". The local Xen hypervisor can be managed by direct hypervisor calls and/or a connection to xend. Warnings that libvirtd isn't running may be ignored.
Libvirtd must be running to support the following, however.
- remote access
- non-root access
- if you use the network or storage features
- managing QEMU and KVM instances
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00085.html
[2] https://www.redhat.com/archives/libvir-list/2008-September/msg00103.html
oVirt Devel List
This section contains the discussion happening on the ovirt-devel list.
Renaming oVirt RPMs
Alan Pevec proposed[1] renaming the oVirt packages which turned into a discussion with Daniel P. Berrange about how to organize the git repos and how to continue support build-all after such a change.
[1] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00029.html
WUI Management of Underlying Hardware
Chris Lalancette posted[1] a series of patches to allow the Web User Interface to manage the underlying hardware it is running on.
[1] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00081.html
Network Interface Bonding and Failover
Darryl L. Pierce began[1] a discussion on implementing support for ethernet bonding multiple interfaces for load balancing and failover. Special consideration for different hardware scenarios such as blade servers lead Konrad Rzeszutek to ask how these extra parameters would be passed in to the bonding setup. Darryl explained[2] that on boot the node identifies itself to the oVirt server, and downloads a configuration file to be processed by augtool[3]. The managed node then restarts the network service to apply the network configuration that it just retrieved.
[1] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00064.html
[2] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00075.html