From Fedora Project Wiki

< FWN
Revision as of 13:00, 22 September 2008 by Ush (talk | contribs) (copied over all the proof-read beats. should be good to go for mailshot now)

Fedora Weekly News Issue 144

Welcome to Fedora Weekly News Issue 144 for the week ending September 20, 2008.

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

In this action packed issue Announcements reminds you of important Fedora 10 freeze dates and the latest on the post security scare clean-up. PlanetFedora muses on some "Legal" issues. Our new Marketing beat-writer Svetoslav Chukov unveils the "Beauty found in Fedora". Developments reveals "Fedora not Free Enough for GNU". News of imminent deadlines in Translations is brought to you by another new writer Runa Bhattacharjee. Infrastructure alerts you to "More Puppet Training!". Artwork offers "Freedom for a Game" and SecurityAdvisories brings you the weeks latest in one handy spot. Virtualization shares information on "Migration Support in Virt-manager GUI".

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 10 feature owners--rescue your unfinished feature pages!

John Poelstra reminded[0] everyone that the feature freeze for Fedora 10 is coming soon, and that feature owners need to get their pages updated to ensure that the features that belong in F10 get in, and that the features that need to be deferred to F11 are deferred. "Please complete this as soon as possible so that we can prepare an accurate beta release announcement. FESCo will also be reviewing the complete feature list at its next meeting on Wednesday, September 17, 2008, and determining which incomplete features should remain."

[0] http://www.redhat.com/archives/fedora-devel-announce/2008-September/msg00011.html

Updates to Fedora Packaging Guidelines

Tom Callaway announced[1] the most recent set of revisions to the Packaging Guidelines, including including Haskell, Lisp, and several other areas. For the full announcement, read the link below.

[1] http://www.redhat.com/archives/fedora-devel-announce/2008-September/msg00012.html

Fedora 10 and translations: String freeze and repackaging

Dimitris Glezos reminded[2] us "that shipped packages for which Fedora is upstream for are string frozen since the Beta freeze of September 11: no translatable strings can be added or modified for Fedora 10."

[2] http://www.redhat.com/archives/fedora-devel-announce/2008-September/msg00013.html

Fedora intrustion update

Paul Frields issued[3] his latest updated regarding the Fedora security breach that has been news during the past few weeks. "Work on the Fedora infrastructure has returned to normal at this point. Updates are once again available for Fedora 8 and Fedora 9, our current releases, using the new package signing key we've implemented."

For the full announcement, follow the link.

[3] http://www.redhat.com/archives/fedora-announce-list/2008-September/msg00009.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

Tech Tidbits

Warren Togami announced[1] the creation of a new list for NSPluginWrapper. "NSPluginwrapper Development discussion with the goal of isolating issues and collaboratively working on solutions should go on this list. There was some interest from other Linux distributions and even Adobe to cooperate on the future of nspluginwrapper development[2]."

[1] http://wtogami.livejournal.com/28380.html

[2] https://www.redhat.com/mailman/listinfo/nspluginwrapper-devel-list

Jesus Rodriguez announced[3] the release of Spacewalk 0.2[4], the open-source upstream for Red Hat Satellite. There is a list of features, enhancements, bug fixes, and credits on Jesus' blog.

[3] http://zeusville.wordpress.com/2008/09/16/spacewalk-02/

[4] http://spacewalk.redhat.com/

Greg DeKoenigsberg helped[5] the OLPC folks recruit volunteers to be part of their growing infrastructure team. "OLPC builds a lot of packages. They are looking to set up and maintain an infrastructure that will allow them to meet their own unique packaging needs. They need a volunteer with a strong understanding of the Fedora packaging process -- one who either understands koji now, or can learn to understand it in fairly short order."

[5] http://gregdek.livejournal.com/35595.html

My favorite Planet post this week came[6] from Fedora Board member Matt Domsch, and it is worth people's time to read the entire post, to gain a lot of insight into how Fedora's mass rebuilds work, and what triggers them.

"One challenge to self-hosting a project the size of Fedora (now with about 6200 source packages) is dealing with the interdependencies between packages. When a major component, such as the compiler or an often-used library, upgrades to a new version, you should rebuild all packages that depend upon that major component, to ensure they continue to work. Often, simply re-compiling or re-linking each package using the updated compiler or library is all that is needed. In some cases though, applications which once built, no longer do - bitrot has set in."

[6] http://direct2dell.com/one2one/archive/2008/09/19/use-the-source-luke.aspx

Legal

Tom Callaway wrote[1] a lengthy post about the Mozilla EULA controversy, which reared its head again this week in the context of Ubuntu and Mozilla. However, Fedora dealt with this problem several months ago, at the end of the Fedora 9 release cycle.

Spot's entire post is worth reading, as is the commentary that follows it. Here is one excerpt:

"[The] goal was always to ensure that we could walk away with license terms from Mozilla that:

1. Permitted Fedora to continue using the Firefox trademarks 2. Clearly upheld the MPL as the valid software license terms for the Firefox binaries and source (not just for Fedora, but for everyone) 3. Meet the criteria for Free Software 4. Are presented to the user in a non-obtrusive, non-clickthrough agreement way"

[1] http://spot.livejournal.com/299409.html

Anthony Green wrote[2] a post that referenced SGI's alteration[3] of its Free B license, which has long been a thorn in the side of various distros.

[2] http://spindazzle.org/greenblog/index.php?/archives/121-Thank-you,-SGI..html

[3] http://www.sgi.com/company_info/newsroom/press_releases/2008/september/opengl.html

Events & Ambassadors

The North American Fedora Ambassador Day is coming up at Ohio Linux Fest in October, and there were a few posts about it on Planet this week. Brian Powell gave[1] an update on the organization, saying:

"There have been quite a few discussions and meetings recently in regards to FAD planning. There has been a lot of good progress and great ideas coming out of these. With time getting close, we are looking at finalizing the Agenda and Schedule for FADNA shortly.

If you are a North American Ambassador I would ask that you take a moment to look at what we have come up with so far and a 'tentative' schedule of events located at the FADNA2008 wiki page. If you have anything to add feel free to do so."

[1] http://blog.rhatters.org/2008/09/17/fadna-2008-update/

Additionally, Karsten Wade wrote[2] a post about strategies for handling remote meetings, and making a physical gathering of a small number of people into a larger meeting that remotees can attend and still get value out of, whether that attendance is via IRC, telephone, or something collaborative like gobby.

"Think about your sessions and how it can help to interact with the rest of us. I recommend a minimum of: live video feed, live audio feed, and IRC, Gobby, and wiki editing projected on the wall. We can also keep a VoIP conference room open, but my instinct is to limit the flow on the incoming voices by subject matter. Beyond that recommendation, a live IRC and wiki-based abd/or Gobby note taking with many laptops in the in-person session is the bare bones, with regular usage of talk.fedoraproject.org."

[2] http://iquaid.org/2008/09/16/formula-for-making-distance-work/

David Nalley wrote up[3] a trip report for Linux Demo Day in Charleston, SC. "About 60 people showed up. Charleston’s LUG is relatively new, and this was their first event. They seemed very pleased. I handed about 30 LiveCDs out and talked with a number of Fedora. In addition I spoke to 2-3 people who were intrigued with contributing to Fedora in one way or another. I’ll be following up with these individuals." This is a great example of an event -- low cost, but high touch!

[3] http://www.nalley.sc/david/?p=96

Marketing

In this section, we cover the Fedora Marketing Project.

http://fedoraproject.org/wiki/Marketing

Contributing Writer: Svetoslav Chukov

Video History of Fedora

The history of Fedora as recounted by GregDeKonigsberg is now available[1] in video format

[1] http://www.redhatmagazine.com/2008/09/16/video-the-history-of-fedora/

FUDCon Brno 2008

Max Spevack reported[1] the result of FUDCon Brno 2008.

[1] http://www.redhatmagazine.com/2008/09/09/fudcon-brno-2008/

The Beauty Found in Fedora.

A very interesting point of view[1] of a Fedora user.

[1] http://spreadfedora.org/sf/index.php?option=com_content&task=view&id=52&Itemid=47

Plug and Run Fedora on a TOSHIBA A300D laptop

This post recounted[1] some adventures with Fedora and a very tricky laptop. It is always good to know about such success stories. Some laptops do not even start GNU/Linux at all! But this one seemed to work pretty well with Fedora.

[1] http://spreadfedora.org/sf/index.php?option=com_content&task=view&id=58&Itemid=51

First look at Fedora

The video article "First look at Fedora" showed[1] what one can see for first time use. Very useful for novice users.

[1] http://spreadfedora.org/sf/index.php?option=com_content&task=view&id=55&Itemid=49

Developments

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

Contributing Writer: Oisin Feeley

Removal of non-X Consoles (continued)

The furore over the future removal of text-mode consoles (see FWN#144 "Non-X System Consoles to be Removed"[1]) continued throughout the week. The original thread saw some support for the idea expressed[2] by Nicolas Mailhot on the basis that "[...] non-X-console input is a mess [...] font support has fossilized, and support for modern high resolution screens is severely lacking [...]" Nicholas was especially concerned[3] with the maintenance burden imposed by the text-mode console "[...] as someone who is an upstream maintainer for my language of some of the bits the console use[s]."

[1] https://fedoraproject.org/wiki/FWN/Issue143#Non-X.System.Consoles.to.be.Removed

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

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

Upon being pressed by Dominik Mierzejewski for evidence of a lack of proper maintenance Nicolas listed[4] a series of problems including the stagnation of the console layout database and the console font set. Dmitry Butskoy begged[5] to separate the concepts of "console" and "serial tty" and also for the retention of the text-mode console. Dominik promised to try to find a colleague to shoulder the maintenance burden but Nicolas had already given up[6] in disgust. In response elsewhere to Seth Vidal's argument that the text console did no harm and should be left alone Nicholas expanded[7] on the maintenance costs of "all sorts of packaging rules designed to avoid hitting console limitations and problems" and bugs filed because of the confusion caused by two text stacks.

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

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

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

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

Les Mikesell got to the heart of the problem when he asked[8] "I think I'm confused by the term 'non X consoles'. Is that something different than the native text mode you see before X starts?" He also recommended using FreeNX/NX instead of using the console. Nicolas responded[9] that there were "[...]two different things. A VT to which you can attach an X session, a serial port, a remote SSH, mingetty... and the software stack used to display locally the VT text and collect user input." Nicolas saw the "low-level VT bit" as fundamentally sound but the "current console software stack" as "rotten." Les sought[10] further clarification of this distinction between "[...] the low level part that works in character mode and expects some hardware to supply and render the fonts [...]" and "[...] software other than X that renders custom fonts[.]"

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

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

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

Denis Leroy wondered[11] if there was "[...] an X-based mingetty replacement actually exists ? Something that's proven to be sufficiently fail-safe (will work even with half-broken X configurations and such?)" and although Nicolas did not know of one he speculated[12] "[...] as soon as much of the hardware pocking is moved from xorg to the kernel and X can be run as a normal user "X-based mingetty replacement" will be just running a x term fullscreen in an autoconfigured X instance. Of course one could theoretically write a much lighter solution using only freetype (cairo, pango?) and an xkb-config parser." Denis's concern seemed to be that often a Ctrl+Alt+F1 to mingetty was the only way to kill hanging desktop applications. Colin Walters suggested[13] making "[...] Ctrl-Alt-Backspace just break server grabs instead of killing the server (and of course fix the bugs in the apps that hang while holding a server grab)."

[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01401.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01407.html

[13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01366.html

There were multiple expressions of disapprobation often coupled with use cases. Some of these led Chris Snook to exclaim[14] "Unless I've missed something huge, virtual terminals aren't going away. What may or may not be going away is the x86 video BIOS text mode, to be replaced with a kernel framebuffer, which precludes the use of console fonts, which very few people ever mess with. The console itself will remain. Someone please correct me if I'm wrong." [[DaveAirlie|Dave Airlie] confirmed[15] this understanding and added "[...] vga text mode will not be enabled by default, you will need to pass nomodeset if you want to use vga text mode. Welcome to the 1990s." Alan Cox made[16] the correction that framebuffer console support fonts but that framebuffers did not work on all machines, screen reader technology and remote management cards.

[14] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01417.html

[15] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01445.html

[16] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01484.html

OpenVPN and resolv.conf

Ahmed Kamal asked[1] for help in scratching an itch and started a concise, meaty thread. His particular problem was that he wanted to overwrite /etc/resolv.conf with new DNS servers obtained over a vpn tunnel, this is apparently done automatically in "Windows".

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

The suggestion to use NetworkManager was made by Paul Wouters and Dan Williams agreed[2] and added the explanation that it "[...] mediate[d] between services [including PPP, PPtP, DHCP, openvpn, and vpnc] that need to update your DNS information." The alternative is that each service needs to handle /etc/resolv.conf itself.

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

The idea of a default caching daemon was floated[3] by Simo Sorce. As he envisioned it, the services/tools, such as OpenVPN, would "[...] tell the caching daemon which IP ranges and which domains their provided forwarders should be consulted for. All dynamic so that as soon as one daemon goes away, the caching DNS will notice and revert queries to the default DNS.} Nils Philippsen agreed[4] heartily and added that "[i]deally, it should be something which isn't restricted to class A/B/C like reverse DNS (seems to be), but which would route DNS requests based on arbitrary domain name or IP-range criteria to the desired name servers" and Paul Howarth provided[5] the further reason that changes to /etc/resolv.conf are often not picked up by processes. This latter point spawned a discussion on the demerits of the glibc stub resolver (which is too simplistic) and the consequent use of the deprecated gethostbyname in individual applications. Dan Williams recommended using lwresd (a stripped-down, caching-only nameserver available to clients which use the BIND 9 lightweight resolver library) or for more complex setups a local caching nameserver. Although Simo Sorce disagreed[6] with Dan that many applications were simply using gethostbyname he agreed that "[a] caching nameserver that can be instructed what to do when conditions change is what we really need."

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

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

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

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

Ahmed asked[7] whether dnsmasq or other daemons were able to "[direct] name resolution to specific servers according to IP ranges and/or domain names, with the option of adding/removing servers on the fly?" and Richard W.M. Jones[8] confirmed that this was indeed possible. Adam Tkac suggested[9] that this could be done with view statements in BIND and the gauntlet of how to do this for CIDR and domain names was thrown down[10] by Nils. A detailed sub-thread followed which indicated what while possible it was not pretty.

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

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

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

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

Adam Tkac shared[11] the information that his TODO list includes the addition of NetworkManager support to BIND and Simo Sorce explained [12] that nscd was not a solution for a local caching nameserver "[...] as not all type of queries can be fulfilled by the glibc interface. For example SRV/TXT records ... Also nscd is not smart enough to understand network condition and adapt it's behavior." Simo agreed that it would be nice if "[...] bind could consult different DNSs based 1) on the DNS name to be queried, and B) the reverse IP to be queried" so that on slow links only the necessary queries would be directed through the VPN.

[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01509.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01510.html

Fedora 10 Feature Owner Request

John Poelstra requested[1] all those owning a Feature[2] to take some actions on their feature page so that the beta release notes and announcements are accurate. He provided a list of twenty one feature pages which "have not been updated since the Feature Freeze on 2008-09-11 and/or are not 100% complete."

Kevin Kofler was among those who had been watching the progress of OpenChange (see FWN#133 "Help Wanted: Samba4, Heimdahl, OpenChange"[3]) and noted[4] that due to the decision[5] of Andrew Bartlett to orphan the feature it needed a new owner if Fedora 11 was to offer OpenChange.

Another of the listed pages was that for the Echo icon theme and Luya Tshimbalanga asked if he should add a release note to the effect that echo was now the default. Rahul Sundaram confirmed that this would be helpful.

The Eclipse-3.4 (Ganymede) page was updated[6] by [JeffJohnston|Jeff Johnston]].

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

[2] http://fedoraproject.org/wiki/Features/Policy/Definitions

[3] http://fedoraproject.org/wiki/FWN/Issue133#Help.Wanted:.Samba4.2C.Heimdahl.2C.OpenChange

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

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

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

system-autodeath Becomes Reality

Seth Vidal announced[1] that he had implemented his previously discussed (FWN#140 "System Autodeath"[2]) idea to automatically remove networking capabilities from machines which lacked system updates. The intent is to prevent non-maintained machines from being exploited.

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

[2] https://fedoraproject.org/wiki/FWN/Issue140#System.Autodeath

Seth implemented the concept as a daily cronjob which tests a configured "death date" against the current time. For the week leading up to the "death date" log messages warn that on the specific date the default route will be deleted. He requested feedback and improvements.

Matt Miller was content but suggested[3] beefing up the manpage with details of the consequences of removing the default route. Seth noted that he was happy to accept patches.

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

A fraught note was introduced when Stephen Warren declared[4] that if this were a default then, in combination with the proposed textconsole removal (see this FWN#144 "Removal of non-X Consoles (continued)") and the modesetting changes[5], he was thinking about switching distros. Rahul Sundaram responded[6] that modesetting was going to be a feature of all distros soon and the conversation veered[7] into explaining that the replacement for RHGB, named "Plymouth" had a sane text-mode fallback for unsupported chipsets. As much of Stephen's angst was due to a perceived abandonment of those using non-Free drivers Rahul pointed out that the nouveau drivers might work. Richard Hughes listed[8] 2-D and xrandr as supported with kernel modesetting coming soon due to Maarten Maathuis's work. He warned: "Don't even try 3D yet. It does work, but only if the moon is waxing, and your pet cat is called Oliver."

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

[5] http://fedoraproject.org/wiki/FWN/Issue143#Graphics.Modesetting.Changes

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

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

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

Back on the main topic of the thread Seth stated[9] that system-autodeath was not intended to be part of the default install: "This is just a nicety for sysadmins or local-respin maintainers who would like to put a dropdead date on their releases." In response to Stephen's recollection Seth also stated[10] this point clearly. A general disagreement with the idea of exposing such a feature was expressed[11] by James Hubbard on the basis that the user should be forced to change a config file to prevent against accidental installation errors.

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

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

[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01850.html

Fedora Not "Free" Enough for GNU?

A long-running thread which was started[1] on 07-09-2008 by Michel Salim continues to attracted some heated discussion over the fact that Fedora is not recognized as a 100% Free software distribution by GNU although a derivative named "BLAG" (see also FWN#139[2]) is recognized as FLOSS.

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

[2] http://fedoraproject.org/wiki/FWN/Issue139#Small.Machine.SIG

The central stumbling block seemed[3] to be best stated by Gregory Maxwell as "[...] Fedora doesn't yet strip the binary firmware provided by the Linux kernel (and still provides some re-distributable binary firmware in other packages, the microcode package and alsa-firmware I think)." Gregory described the situation as unfortunate due to both the lack "[...] of acknowledgement it deserves, and the FSF is indirectly promoting Ubuntu, a distribution which is, as far as I can tell, a primary driving factor in new users using and depending on proprietary software." This latter being a reference to the recognition of gNewSense as FLOSS.

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

There had been previous very heated threads on this subject (during one of FWN's holidays) centered around the efforts of Alexandre Oliva to produce a "kernel-libre" and the interaction of this project with other efforts and approaches within the kernel community. David Woodhouse added[4] the excellent news that "We are almost at the point where we can do a spin which remedies [the difficulties of stripping out the non-Free firmware]." He explained that soon a completely separate package instead of a sub-package of the normal kernel build will allow others to produce alternative packages of firmwares for which source code is available. Tom Callaway was worried[5] that there was still firmware entangled in the kernel source code and noted the need for an audit. Rahul Sundaram supplied[6] a link to a Debian inventory of firmwares.

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

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

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

Other interesting points in the discussion touched on the rationales which have been often advanced for refusing to supply source to firmwares. These involve regulatory compliance (often for radio devices). Alan Cox was suspicious of such arguments based[7] on the history of examples such as ISDN code which "[...] was approved. You could change it but then it became unapproved and not permitted in some countries." He described this as a racket run by the phone companies which imploded once the need to ensure robustness became important (due to terrorist threats.) Ignacio Vazquez-Abrams listed[8] some of the other rationales.

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

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

Translation

This section covers the news surrounding the Fedora Translation (L10n) Project.

http://fedoraproject.org/wiki/L10N

Contributing Writer: Runa Bhattacharjee

2008-10-14 Declared Fedora 10 Package Translation Deadline

The last date for submission of translations for Fedora 10 packages was announced[1] as 2008-10-14 (Tuesday). This announcement was made after an unanimous decision by the Fedora L10n Steering Committee (FLSCo) members. The last date for the translation of Documents remains as 2008-10-21 (Tuesday).

[1] https://www.redhat.com/archives/fedora-trans-list/2008-September/msg00050.html

A request for rebuilding of packages post the translation freeze date, was also made[2] to the @fedora-devel-announcement list.

[2] https://www.redhat.com/archives/fedora-devel-announce/2008-September/msg00013.html

"Maintainers of the above packages need to put a reminder to issue a new build *later* than this date and before the Development Freeze of 21/10. The closer to the development freeze the rebuild takes place, the better for our translators. If you have not received any translations since the last build, a rebuild is not necessary."

Renewed Call for Volunteers for the L10n Infrastructure

Another call was made[3] at the FLSCo meeting held[ on 16th September 2008[4] seeking volunteers for the Fedora L10n infrastructure. The earlier call was made[5] in April 2008.

[3] https://www.redhat.com/archives/fedora-trans-list/2008-September/msg00047.html

[4] https://www.redhat.com/archives/fedora-trans-list/2008-September/msg00051.html

[5] https://www.redhat.com/archives/fedora-trans-list/2008-April/msg00020.html

Meanwhile, Asgeir Frimannsson announced[6] a proposed plan for a new L10n infrastructure which is currently being discussed[7] in various relevant mailing lists.

[6] https://www.redhat.com/archives/fedora-infrastructure-list/2008-September/msg00108.html

[7] http://groups.google.com/group/transifex-devel/browse_thread/thread/f9b1e06362386539

Infrastructure

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

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: HuzaifaSidhpurwala

Planning a future L10N infrastructure (including Fedora)

Asgeir Frimannsson wrote on the @fedora-infrastructure-list [1] about his views on the current localisation infrastructure. He summarises the current infrastructure which is used by the localisation team, which includes the version control system and other online tools. He also discusses transifex. He also discusses the requirements for a system where the translation lifecycle would be managed within 'Translation Repositories'

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


Puppet training

Mike McGrath wrote on the @fedora-infrastructure-list [2] that he is going to hold a puppet training next wednesday. He also posted an ogg and the slide deck [3] to which his live training will be identical.

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

[3] http://mmcgrath.fedorapeople.org/puppet/

Fedora 10 Beta Release Planning Meeting

John Poelstra wrote on the @fedora-infrastructure-list [4] about the Fedora 10 Beta Release Planning Meeting. He has also posted the list of participants and the meeting logs.

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

Infrastructure update notice

Paul W. Frields wrote on the @fedora-infrastructure-list [5] about the announcement which went out on the fedora-announce-list [6]. Paul confirmed that all of our services were back online now.

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

[6] http://www.redhat.com/archives/fedora-announce-list/2008-September/msg00009.html

app2 disk space

Mike McGrath wrote on the @fedora-infrastructure-list[7] about the recent disk alerts on app2. It seems that the host was not built with enough disk space similar to app1. It does raise a point about storage for transifex though. Basically each host running transifex or damned lies, keeps a local copy of every scm as part of its usage. For performance reasons that should not change but its something we'll want to figure out long term. So after the freeze the host is going to be rebuilt.

[7] https://www.redhat.com/archives/fedora-infrastructure-list/2008-September/msg00155.html

Artwork

In this section, we cover the Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: Nicu Buculei

Near to the Echo

Pursuing the declared goal of having the new Echo icon theme ready to be used as a default in Fedora 10, Martin Sourada and Luya Tshimbalanga continued[1] the development and posted updates[2], while gathering feed-back and improvement proposals on @fedora-art. Martin even created[3] an animated demo "also prepared animated gif (slideshow) so you can see all the icons in one batch" and blogged about it.

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

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

[3] http://mso.fedorapeople.org/echo/Actions/mail-all.gif

[4] http://mso-chronicles.blogspot.com/2008/09/batch-of-new-mail-echo-icon.html

Freedom for a Game

Nicu Buculei relayed[1] to @fedora-art a request from the Hans deGoede, of Games SIG fame: the Project: Starfighter game[2], which used to be included in Fedora, was discovered to have some non-free graphic files and needed free replacements for them. Erick Henrique offered[3] his help "I go to unpack the archive starfighter.pak and to study a form of I redesign everything in a new style" and Hans promised[4] to code a needed utility "About recreating the .pak file I need to write a little utility for that, hopefully I'll have time for that this weekend."

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

[2] http://www.parallelrealities.co.uk/starfighter.php

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

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

Infrastructure Change for Fedora Art

After an IRC consultation with Mairin Duffy, Martin Sourada proposed[1] using fedorahosted.org services for the Art team "it might be worth setting up a fedorahosted.org instance for the Fedora Art Team. Primary purpose would be to host our release graphics, but it could serve other purposes as well (e.g. using ticket system for design service come to my mind)[.]" This initiative was received with open arms by Luya Tshimbalanga and with some skepticism[3] by Ian Weller "I'm personally all for the idea, but I knew there were some caveats that we should definitely look into before we even think about proceeding. I'd also like to see Mo's input, of course." and Nicu Buculei stated[4] "I am strongly against something which would raise the barrier to entry, so a NO-NO would be to require git to upload sketches (proposals) for the upcoming release."

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

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

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

[4] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00267.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 and Virtinst Closely Related

After upgrading virt-manager to 0.6.0, Maikel Dollé received[1] the error ImportError: cannot import name Storage. Cole Robinson explained[2] virt-manager is tied closely with virtinst and installing virtinst 0.400.0 would likely fix the problem.

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

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

Migration Support in Virt-manager GUI

Shigeki Sakamoto followed[1] up on a previous[2] request for comments on a patch, submitted by same, which works to allow the migration of domains from within the virt-manager GUI. Daniel P. Berrange suggested[3] using a submenu rather than a pop-up window, and commented on the sanity checks[4] in libvirt.

Live Migration Sanity Checks were recently discussed on @libvir list (see FWN #141 Live Migration Sanity Checks[5]).

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

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

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

[4] http://wiki.libvirt.org/page/TodoPreMigrationChecks

[5] http://fedoraproject.org/wiki/FWN/Issue141#Live_Migration_Sanity_Checks

Fedora Xen List

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

DomU Network Interface Problem Leads to Discussion of HVM Requirements

Guillaume[1] asked[1] about a paravirtualized domU which did not show any network interfaces. There was a suggestion made that this could be due to a lack of HVM support in the host hardware, which isn't the case. Paul Wouters cleared[2] up such confusion by describing the main virtualization techniques used in Fedora. Quoting:

  • Xen hypervisor for para_virt guests does not need HVM.
Problem here is that Fedora 8 is the last release to support this setup on x86_64, though work is in progress to add this support to Fedora 9/10. Para_virt guests are booted via kernel= and rootfs images, or via pygrub, which is just a wrapper for grabbing kernel from bootable disk images.
  • Qemu is a software emulator for various architectures including PC hardware.
It requires no HVM instructions, but it can use them if they exist via the kernel "kvm" code. This is how Fedora9 does its VM's via the libvirt and virt-install. This does NOT [sic] use or require a xen hypervisor.
  • Xenner is a software emulation for the Xen hypervisor.
It requires HVM because it uses the kernel "kvm" code. The idea behind Xenner is that you can run VM's based on kernel-xen kernels (eg migration from Fedora8)

Paul went on to mention other[5] virtualization technologies such as VirtualBox/Vmx, lguest, uml, virtuoso, and openvz.

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

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

In another post[3] Paul suggested that Guillaume's domU may have an initrd which lacks xenblk and xennet, and pointed[4] to a debate in the FC6 era concerning the xenblk kernel module.

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

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

[5] http://virt.kernelnewbies.org/TechComparison

Libvirt List

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

Minimal Client-only Libvirt Build

Ben Guthro patched[1] the libvirt spec file to allow for a minimal client-only build.

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

Access to CPU Flags

Ben Guthro needed[1] to access CPU flags to determine if VMX features were available, and suggested src/nodeinfo.c would be the place to parse this. This however raised a concern that adding to the nodeinfo struct breaks the API. Additionally, since this is an x86 specific change, Ben wondered if it would be acceptable.

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

Daniel P. Berrange stated[1] "any struct or API in include/libvirt/libvirt.h is immutable to preserve ABI", and the API shouldn't be specifically x86. Daniel did offer that the most likely place for exposing CPU flags would be in the capabilities[3] XML format. Where PAE, VMX, and SVM flags are already exposed.

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

[3] http://libvirt.org/html/libvirt-libvirt.html#virConnectGetCapabilities

Ben noted[4] that Xen will report those flags, but oVirt running KVM does not, and said "It seems to me that it might be useful for some sort of "node" info driver, where we might be able to share code for hypervisor independent info about the physical machine it is running on." Daniel pointed[5] to src/nodeinfo.c as "a place for this useful reusable node info code".

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

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

OpenVZ Support

Anton Protopopov pointed[1] to a previous thread[2] on xml format for OpenVZ driver, and asked if libvirt supported the xml format for OpenVZ[3] driver.

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

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

[3] http://wiki.openvz.org

Evgeniy Sokolov replied[4] that OpenVZ uses the XML format common for all libvirt drivers.

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

oVirt Devel List

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

Check back next week.

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