From Fedora Project Wiki

< FWN

m (added category)
 
(One intermediate revision by one other user not shown)
Line 5: Line 5:
http://fedoraproject.org/wiki/FWN/Issue144
http://fedoraproject.org/wiki/FWN/Issue144


Selected Contents:
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".
 
In this issue we cover the upcoming plans for North America Fedora Ambassador Day, update the happenings across the Fedora Planet, report on numerous work towards Fedora 10 in artwork, internationalization and reports on FUDCon 2008 in Brno, Czech Republic and Linux Demo Day in Charleston, SC USA.


If you are interested in contributing to Fedora Weekly News, please see our 'join' page[1].
If you are interested in contributing to Fedora Weekly News, please see our 'join' page[1].


[1] http://fedoraproject.org/wiki/NewsProject/Join
[1] http://fedoraproject.org/wiki/NewsProject/Join
{{Anchor|Announcements}}
{{Anchor|Announcements}}
== Announcements ==
== Announcements ==
Line 49: Line 46:


[3] http://www.redhat.com/archives/fedora-announce-list/2008-September/msg00009.html
[3] http://www.redhat.com/archives/fedora-announce-list/2008-September/msg00009.html
{{Anchor|PlanetFedora}}
{{Anchor|PlanetFedora}}
== Planet Fedora ==
== Planet Fedora ==


Line 62: Line 57:
=== Tech Tidbits ===
=== Tech Tidbits ===


Warren Togami announced 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."
[[WarrenTogami|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]."


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


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


Jesus Rodriguez announced the release of Spacewalk 0.2, the open-source upstream for Red Hat Satellite.  There is a list of features, enhancements, bug fixes, and credits on Jesus' blog.
[[JesusRodriguez|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.


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


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


Greg DeKoenigsberg is helping 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."
[[GregDeK|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."


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


My favorite Planet post this week comes 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.
My favorite Planet post this week came[6] from Fedora Board member [[MattDomsch|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."
"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."


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


=== Legal ===
=== Legal ===


Tom Callaway wrote 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.
[[TomCallaway|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:
Spot's entire post is worth reading, as is the commentary that follows it.  Here is one excerpt:
Line 97: Line 92:
4. Are presented to the user in a non-obtrusive, non-clickthrough agreement way"
4. Are presented to the user in a non-obtrusive, non-clickthrough agreement way"


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


Anthony Green wrote a post that referenced SGI altering its Free B license, which has long been a thorn in the side of various distros.   
[[AnthonyGreen|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.   


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


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


=== Events & Ambassadors ===
=== 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 an update on the organization, saying:
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.  [[BrianPowell|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.
"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.
Line 113: Line 108:
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."
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."


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


Additionally, Karsten Wade wrote 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.
Additionally, [[KarstenWade|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."
"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."


'''http://iquaid.org/2008/09/16/formula-for-making-distance-work/'''
[2] http://iquaid.org/2008/09/16/formula-for-making-distance-work/
 
David Nalley wrote up 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!


'''http://www.nalley.sc/david/?p=96'''
[[DavidNalley|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
{{Anchor|Marketing}}
{{Anchor|Marketing}}
== Marketing ==
== Marketing ==


Line 133: Line 126:
http://fedoraproject.org/wiki/Marketing
http://fedoraproject.org/wiki/Marketing


The history of Fedora is now available in video format. [1]
Contributing Writer: [[User:mhydra|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/
[1] http://www.redhatmagazine.com/2008/09/16/video-the-history-of-fedora/
Line 143: Line 140:
[1] http://www.redhatmagazine.com/2008/09/09/fudcon-brno-2008/
[1] http://www.redhatmagazine.com/2008/09/09/fudcon-brno-2008/


=== The beauty found in Fedora. ===
=== The Beauty Found in Fedora. ===


Very interesting point of view of a Fedora user[1]
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
[1] http://spreadfedora.org/sf/index.php?option=com_content&task=view&id=52&Itemid=47
Line 151: Line 148:
=== Plug and Run Fedora on a TOSHIBA A300D laptop ===
=== Plug and Run Fedora on a TOSHIBA A300D laptop ===


Adventures with Fedora and very tricky laptop [1]
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.
 
It is always good to know for such success stories. Some laptops do not even start GNU/Linux at all! But that one seems to work pretty well with Fedora.


[1] http://spreadfedora.org/sf/index.php?option=com_content&task=view&id=58&Itemid=51
[1] http://spreadfedora.org/sf/index.php?option=com_content&task=view&id=58&Itemid=51
Line 159: Line 154:
=== First look at Fedora ===
=== First look at Fedora ===


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


[1] http://spreadfedora.org/sf/index.php?option=com_content&task=view&id=55&Itemid=49
[1] http://spreadfedora.org/sf/index.php?option=com_content&task=view&id=55&Itemid=49
{{Anchor|Developments}}
== Developments ==
In this section the people, personalities and debates on the @fedora-devel
mailing list are summarized.
Contributing Writer: [[OisinFeeley|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 [[NicolasMailhot|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 [[DominikMierzejewski|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. [[DmitryButskoy|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 [[SethVidal|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
[[LesMikesell|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
[[DenisLeroy|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. [[ColinWalters|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 [[ChrisSnook|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." [[AlanCox|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 ===
[[AhmedKamal|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 [[PaulWouters|Paul Wouters]] and [[DanWilliams|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 <code>/etc/resolv.conf</code> 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 [[SimoSorce|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.} [[NilsPhilippsen|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 [[PaulHowarth|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 <code>gethostbyname</code> in individual applications. [[DanWilliams|Dan Williams]] recommended using <code>lwresd</code> (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 [[SimoSorce|Simo Sorce]] disagreed[6] with Dan that many applications were simply using <code>gethostbyname</code> 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 <code>dnsmasq</code> 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 [[RichardJones|Richard W.M. Jones]][8] confirmed that this was indeed possible. [[AdamTkac|Adam Tkac]] suggested[9] that this could be done with <code>view</code> statements in <code>BIND</code> 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
[[AdamTkac|Adam Tkac]] shared[11] the information that his TODO list includes the addition of <code>NetworkManager</code> support to <code>BIND</code> and [[SimoSorce|Simo Sorce]] explained [12] that <code>nscd</code> 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 ===
[[JohnPoelstra|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."
[[KevinKofler|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 [[AndrewBartlett|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 [[LuyaTsimbalanga|Luya Tshimbalanga]] asked if he should add a release note to the effect that <code>echo</code> was now the default. [[RahulSundaram|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 ===
[[SethVidal|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.
[[MattMiller|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 [[StephenWarren|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. [[RahulSundaram|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 <code>RHGB</code>, 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 <code>nouveau</code> drivers might work. [[RichardHughes|Richard Hughes]] listed[8] 2-D and <code>xrandr</code> as supported with kernel modesetting coming soon due to [[Maarten Maathuis|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 <code>system-autodeath</code> 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 [[JamesHubbard|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 [[MichelSalim|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 [[GregoryMaxwell|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 [[AlexandreOliva|Alexandre Oliva]] to produce a "kernel-libre" and the interaction of this project with other efforts and approaches within the kernel community. [[DavidWoodhouse|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. [[TomCallaway|Tom Callaway]] was worried[5] that there was still firmware entangled in the kernel source code and noted the need for an audit. [[RahulSundaram|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). [[AlanCox|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.) [[IgnacioVazquezAbrams|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
{{Anchor|Translation}}
{{Anchor|Translation}}


== Translation ==
== Translation ==


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


http://fedoraproject.org/wiki/L10N
http://fedoraproject.org/wiki/L10N
Line 174: Line 336:
Contributing Writer: [[RunaBhattacharjee|Runa Bhattacharjee]]
Contributing Writer: [[RunaBhattacharjee|Runa Bhattacharjee]]


=== 14th October 2008 declared as the Package Translation deadline for Fedora 10 ===
=== 2008-10-14 Declared Fedora 10 Package Translation Deadline ===


The last date of submission of translations for Fedora 10 packages has been announced as 14th October 2008 (Tuesday).[1] 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 21st October 2008 (Tuesday).
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).


A request for rebuilding of packages post the translation freeze date, was also made to the Fedora-Devel-Announcement List.[2]
[1] https://www.redhat.com/archives/fedora-trans-list/2008-September/msg00050.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."
A request for rebuilding of packages post the translation freeze date, was also made[2] to the @fedora-devel-announcement list.
 
 
[1] https://www.redhat.com/archives/fedora-trans-list/2008-September/msg00050.html


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


=== Renewed call for volunteers for the L10n Infrastructure ===
"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."


Another call was made at the FLSCo meeting held on 16th September 2008[3] seeking volunteers for the Fedora L10n infrastructure.[4] The earlier call was made in April 2008.[5]
=== Renewed Call for Volunteers for the L10n Infrastructure ===
 
Meanwhile, [[AsgeirFrimannsson|Asgeir Frimannsson]] announced a proposed plan for a new L10n infrastructure which is currently being discussed in various relevant mailing lists.[6][7]


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
[3] https://www.redhat.com/archives/fedora-trans-list/2008-September/msg00047.html
Line 199: Line 357:


[5] https://www.redhat.com/archives/fedora-trans-list/2008-April/msg00020.html
[5] https://www.redhat.com/archives/fedora-trans-list/2008-April/msg00020.html
Meanwhile, [[AsgeirFrimannsson|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
[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
[7] http://groups.google.com/group/transifex-devel/browse_thread/thread/f9b1e06362386539
{{Anchor|Infrastructure}}
{{Anchor|Infrastructure}}
== Infrastructure ==
== Infrastructure ==


Line 250: Line 408:


[7] https://www.redhat.com/archives/fedora-infrastructure-list/2008-September/msg00155.html
[7] https://www.redhat.com/archives/fedora-infrastructure-list/2008-September/msg00155.html
{{Anchor|Artwork}}
{{Anchor|Artwork}}


Line 264: Line 420:
=== Near to the Echo ===
=== 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, [[MartinSourada|Martin Sourada]] and [[LuyaTshimbalanga|Luya Tshimbalanga]] continued the development and posting updates[1], [2], gathering feed-back and improvement proposals on @fedora-art. Martin even created an animated demo "also prepared animated gif (slideshow) [3] so you can see all the icons in one batch" and blogged about it.
Pursuing the declared goal of having the new Echo icon theme ready to be used as a default in Fedora 10, [[MartinSourada|Martin Sourada]] and [[LuyaTshimbalanga|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
[1] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00202.html
Line 274: Line 430:
[4] http://mso-chronicles.blogspot.com/2008/09/batch-of-new-mail-echo-icon.html
[4] http://mso-chronicles.blogspot.com/2008/09/batch-of-new-mail-echo-icon.html


=== Freedom for a game ===
=== Freedom for a Game ===


[[NicuBuculei|Nicu Buculei]] relayed[1] to @fedora-art a request from the [[HansdeGoede|Hans deGoede]], of Games SIG fame: the Project: Starfighter game[2], which used to be included in Fedora, was discovered of having some non-free graphic files and need free replacements to be re-included. [[ErickHenrique|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."
[[NicuBuculei|Nicu Buculei]] relayed[1] to @fedora-art a request from the [[HansdeGoede|Hans deGoede]], of Games SIG fame: the <code>Project: Starfighter</code> game[2], which used to be included in Fedora, was discovered to have some non-free graphic files and needed free replacements for them. [[ErickHenrique|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
[1] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00231.html
Line 286: Line 442:
[4] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00291.html
[4] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00291.html


=== Infrastructure change for Fedora Art ===
=== Infrastructure Change for Fedora Art ===


After an IRC consultation with [[MairinDuffy|Mairin Duffy]], [[MartinSourada|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)", an initiative received with open arms by [[LuyaTshimbalanga|Luya Tshimbalanga]] and with some skepticism[3] by [[IanWeller|Ian Weller]] "I'm personally all for the idea, but I knew there were some caveats that
After an IRC consultation with [[MairinDuffy|Mairin Duffy]], [[MartinSourada|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 [[LuyaTshimbalanga|Luya Tshimbalanga]] and with some skepticism[3] by [[IanWeller|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 [[NicuBuculei|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."
we should definitely look into before we even think about proceeding. I'd also like to see Mo's input, of course." and [[NicuBuculei|Nicu Buculei]][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
[1] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00242.html
Line 298: Line 453:


[4] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00267.html
[4] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00267.html
{{Anchor|SecurityAdvisories}}
{{Anchor|SecurityAdvisories}}
== Security Advisories ==
== Security Advisories ==


Line 320: Line 473:
* fedora-package-config-smart-8-12.0.2.transitional  - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00846.html
* fedora-package-config-smart-8-12.0.2.transitional  - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00846.html
* tomcat5-5.5.27-0jpp.2.fc8  - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00889.html
* tomcat5-5.5.27-0jpp.2.fc8  - https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00889.html
{{Anchor|Virtualization}}
== 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: [[DaleBewley | Dale Bewley]]
=== Enterprise Management Tools List ===
This section contains the discussion happening on the [https://www.redhat.com/mailman/listinfo/et-mgmt-tools et-mgmt-tools list]
==== Virt-manager and Virtinst Closely Related ====
After upgrading <code>virt-manager</code> to 0.6.0, [[MaikelDollé|Maikel Dollé]] received[1] the error ''ImportError: cannot import name Storage''.  [[ColeRobinson|Cole Robinson]] explained[2] <code>virt-manager</code> is tied closely with <code>virtinst</code> and installing <code>virtinst</code> 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 ====
[[ShigekiSakamoto|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 <code>virt-manager</code> GUI. [[DanielBerrange|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 <code>@libvir</code>
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 [https://www.redhat.com/mailman/listinfo/fedora-xen 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. [[PaulWouters|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 <code>xenblk</code> and <code>xennet</code>, and pointed[4] to a debate in the FC6 era concerning the <code>xenblk</code> 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 [https://www.redhat.com/mailman/listinfo/libvir-list libvir-list].
==== Minimal Client-only Libvirt Build ====
[[BenGuthro|Ben Guthro]] patched[1] the <code>libvirt</code> 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 ====
[[BenGuthro|Ben Guthro]] needed[1] to access CPU flags to determine if VMX
features were available, and suggested <code>src/nodeinfo.c</code> 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
[[DanielBerrange|Daniel P. Berrange]] stated[1] "any struct or API in <code>include/libvirt/libvirt.h</code> 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 <code>src/nodeinfo.c</code> 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|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
[[EvgeniySokolov|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 [https://www.redhat.com/mailman/listinfo/ovirt-devel ovirt-devel list].
Check back next week.
[[Category:News]]

Latest revision as of 10:54, 14 April 2009

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.