- 1 Fedora Weekly News Issue 134
- 1.1 Announcements
- 1.2 Planet Fedora
- 1.2.1 Robocup 2008
- 1.2.2 Fedora TV
- 1.2.3 OLPC call to action
- 1.2.4 TurboGears 2 slides & code from FUDCon Boston 2008
- 1.2.5 Featureful
- 1.2.6 Graphical Boot and Live Images
- 1.2.7 Whence world domination?
- 1.2.8 Patented oddness...
- 1.2.9 Bug reporting for Planet Fedora
- 1.2.10 A walking little guy
- 1.2.11 Fedora EMEA Ambassador Meeting Reminder
- 1.2.12 Eth-0 and hacking out in the woods
- 1.2.13 Pushing kernels more aggressively to updates-testing
- 1.3 Marketing
- 1.4 Ambassadors
- 1.5 Development
Fedora Weekly News Issue 134
Welcome to Fedora Weekly News Issue 134 for the week ending July 12, 2008.
Fedora Weekly News keep you updated with the latest issues, events and activities in the fedora community.
If you are interested in contributing to Fedora Weekly News, please see our 'join' page. Being a Fedora Weekly News beat writer gives you a chance to work on one of our community's most important sources of news, and can be done in only about 1 hour per week of your time.
We are still looking for beat writers to cover the highlights of Fedora Marketing each week and to summarize the Fedora Events and Meetings that happened during each week.
In this section, we cover announcements from the Fedora Project.
Contributing Writer: Max Spevack
New RPM version in Rawhide
Panu Matilainen had a very important announcement:
"At long last, we are about to get a brand new RPM version (alpha snapshot at the moment) into rawhide. The list of changes from 4.4.2.x is massive and a full summary needs a separate posting (will follow as time permits), this is just a heads-up of immediate consequences for Fedora packagers and rawhide consumers.
"BACKUP YOUR RPMDB, NOW! We're not aware of any baby-eating bugs in rpm but I'd be shocked if there were no new bugs at all... Better safe than sorry - do something like this before updating to the new rpm:
# cp -avp /var/lib/rpm /var/lib/rpm-`date +%d%m%y`
Bugzilla upgrade coming July 26th
John Poelstra announced on behalf of Dave Lawrence:
"The Red Hat Bugzilla team is happy to announce that the release of the next version of Red Hat Bugzilla will occur on July 26th, 2008. The next version will be based on the upcoming upstream 3.2 code base soon to be released."
Rawhide Orphanarium Purge: June 18th
Warren Togami announced on fedora-devel-announce:
"Please review the following packages. This is roughly the list of current orphans in rawhide. If they are not claimed by June 18th then they may be removed from rawhide by the F10 Alpha freeze."
In this section, we cover the highlights of Planet Fedora - an aggregation of blogs from Fedora contributors worldwide.
Contributing Writer: Max Spevack
Tim Niemuller posted on his blog that he is en-route to China for RoboCup 2008:
"I will place some Fedora stickers on the robots and I hope to foster some questions and spawn some interest for the Fedora Robotics SIG. We have put this SIG on our team description poster as a community contribution! Next year we will have that funky robotics LiveCD!"
Jonathan Roberts discussed the Fedora TV idea, as implemented using Miro.
"What is [Fedora TV]?
A way for our community to easily share video and audio related to Fedora with each other - the mechanism we’ve chosen to do this is an RSS feed that also exists as a channel in Miro.
How do I watch?
You can install Miro and subscribe to the Fedora TV channel. You can also add the RSS feed to any feed reader or suitable podcatching client."
Also, Jef Spaleta talked about the current status of Fedora TV on his blog.
"Fedora TV is up and running a work flow. We have a submission que. We have a delivery channel. So now we need is to start looking at what sort of things make sense as content. We have people looking at doing screencasts, and doing interviews... content of an educational or newsworthy nature. But what we don't have to round out our experimental programming is someone looking into generating artistic or entertainment content."
OLPC call to action
Greg DeKoenigsberg exhorted the Fedora packaging community to pick up some of the items on OLPC's wish list, and gives a general update of the state of OLPC's relationship with Fedora.
"Did you know that the OLPC project is the largest single "customer" of Fedora in the entire world?
The rumours of OLPC's death have been greatly exaggerated. Despite some unfortunate statements by the project's erstwhile CEO, the OLPC project is still *extremely* focused on succeeding in its noble goal -- the education of the world's children -- with the use of free software as the central component of their software strategy. And they are, in fact, succeeding, even though the open source community has largely turned its collective back on that success. Which is, I think, a shame."
TurboGears 2 slides & code from FUDCon Boston 2008
TurboGears ninja Luke Macken has posted his slides and code from FUDCon Boston.
Paul Frields highlighted some of the early Fedora 10 feature work:
"I was just looking at the proposed Fedora 10 features category on the wiki. There are over a dozen cool features being set up for this next release."
Graphical Boot and Live Images
Jeremy Katz wrote in his blog:
"One of the goals for Fedora 10 is to replace the aging rhgb that has been used for graphical boot since Red Hat Linux 8.0. rhgb is implemented using an X server which started in rc.sysinit relatively early during the boot process and then some feedback is provided to the user. With some of the improvements underway for Fedora 10 we should hopefully have kernel modesetting in place at least for some drivers which will let us set a native resolution graphical mode as opposed to requiring either text-mode, an X driver + server or the use of a framebuffer."
Jeremy has also posted a screencast showing this new functionality in action.
Whence world domination?
Colin Walters muses during GUADEC:
"How do we increase use of GNOME and Free Software in general on the desktop? What's our target audience? What kinds of things can we do? Why haven't we taken over the world yet?"
Jef Spaleta opined on his blog about ooxml:
"So looking back over the last few months of all the coverage concerning ooxml and how very bad it is... it seems to me that a lot of people have made it a point to question whether the ooxml specification has patented bits. Even in countries where software patents aren't so very important...yet.. the very issue of patents on bits of the ooxml specification made some sort of press.
Compared to the situation we have for patent encumbered audio/video standards..i find such interest in talking about the ooxml patent issue quite out of proportion. Why does the world, the free world, the world where innovation is yet to be shackled by the constraints of enforced software patents care so very much about the patentability of ooxml, but for audio/video format specifications, its barely on anyone's radar at all as something to be up in arms about?"
Bug reporting for Planet Fedora
Max Spevack wrote on his blog,
"We have received several reports from people who visited parents, relatives, etc. over the 4th of July weekend and saw strange rendering problems with Planet Fedora on various browser/OS combinations.
In response to that, we have set up a test matrix that anyone in our community can use to report either successful or problematic browser/OS combinations.
If you have a Windows box or a Macintosh near you, this is an easy way to do a little bit of testing that will be of benefit to the Fedora community."
A walking little guy
Nicu Buculei made a little animation that your correspondent thought was cute.
Fedora EMEA Ambassador Meeting Reminder
Fabian Affolter wrote on his blog,
"The next monthly EMEA Ambassador Meeting will be next week.
Day : Wednesday, July 16, 2008 (16.07.2008)
Time : 20:00 UTC
Channel : #fedora-meeting"
Eth-0 and hacking out in the woods
"I think it's really important for people to understand a little bit about how open source in Europe works compared to the US. For many people here it isn't just a development model or a way of guaranteeing some level of code security, but just a matter of life and reality. Many people here, at this event, are pretty involved not only in messing around with fun electronic toys, but also administrating some very complex networks and systems deployments. Being able to apply a certain level of code freedom to playing with complex servers scales equally as well to being able to create new tools for Audio and Video production. In other words, all the cool parties use open source here.
When working with Free Media geeks, having libraries of open media for use in productions is equally as important. It's very common to want to use movies out of pop culture or out of alternative culture (cue obvious cut to a scene from Yellow Submarine for 750 milliseconds.) The sooner most common media, even off-Hollywood films are under licenses like the Creative Commons, the closer artists are able to legally and freely use this media for their performances as well. Open Source and Open Media aren't just philosophical discussions but really affect the things that people her do."
Pushing kernels more aggressively to updates-testing
David Nielsen offered his opinions on how we push kernel updates in Fedora:
"We did the correct thing, to a degree naturally, the update was in relation to a security update something Fedora takes very seriously. As such our users should always feel safe knowing that we will push such updates fast, keeping their systems secure through multiple means including proactive security and rapid updates.
However the problem is that we don’t apply the update to the existing stable kernel, the patch is always applied on top of the progressing kernel, meaning we also end up shipping a lot of other things such as bugfixes, updates to the latest upstream STABLE tree and various other things. This however is confronted with one problem, the kernels in between the current stable and next update are not all being pushed to updates-testing - only selected kernel updates are. In cases where we then have to release a security fix we are forced to ship a bunch of stuff additionally which is not likely to have been tested extensively."
In this section, we cover the Fedora Marketing Project.
Contributing Writer: Pascal Calarco
Beat Writers sought for Marketing & Meetings
Pascal Calarco posted  a call for volunteers for the Marketing and Meetings beats for Fedora Weekly News. He added, "If you are interested, take a peek at the last few issues of FWN  to see what this looks like, and then sign up  by joining the fedora-news-list, introduce yourself and claim one of these beats as your own!
Karsten Wade announced  that the Extra Packages for Enterprise Linux (EPEL) project was going to go through a rebranding process and invited interested folk on the fedora-marketing list to participate in a teleconference this past week on this work. Stay tuned for more information on this.
Red Hat Replaces RHGB With Plymouth
Rahul Sundaram shared  a story from Phoronix  about Red Hat's replacement of the Red Hat Graphical Boot loader, which is being discontinued and replaced with a new boot loader called Plymouth, engineered by Red Hat's Ray Strode. More information on Plymouth is available on the Fedora wiki 
Top 4 New Features Proposed for Fedora 10
Rahul Sundaram posted  an article in Linux Loop  where the writer shared his top four suggested enhancements for Fedora 10, including a web-based software portal, Live CD without the CD, improved support for fingerprint readers, and a 'Fedora Lite,' suitable for older computers. The posting generated some discussion on Linux Loop.
Fedora-powered tools on new Phoenix BIOS hypervisor
Paul W. Frields forwarded  a recent article from BetaNews that reported  "that NEC will be among the first PC manufacturers to use its HyperSpace technology...In a meeting with BetaNews on Thursday at this week's Digital Life press preview, the VP said that the HyperSpace platform allows software tools to run on Fedora Linux firmware, even though Windows is installed on the same system."
Concept Art for Fedora 10
Rahul Sundaram contributed  a recent article from OSNews  encouraging readers to check out developments in concept art for Fedora 10 and pointing to a longer posting in Linux Loop . "For many, their first experience with Fedora leaves them in awe of the incredible artwork. This is an important part of Fedora's reputation, so if your a fan of Fedora art, you should definitely check out what the art team has come up with." The poster at Linux Loop briefly looks at six thematic conceptual sketches to be included in Fedora 10, and concludes, "Overall, I cannot wait to see what Fedora 10’s final theme looks like. If the concepts look this good already, I bet they will look simply incredible when they are finalized."
In this section, we cover Fedora Ambassadors Project.
Contributing Writer: JeffreyTadlock
RMLL Event Report
Pierre-Yves posted  an event report for the RMLL at Mont-de-Marsant, France to the ambassador mailing list. The conference had approximately 4000+ visitors and T-shirts, buttons and live media were distributed from the Fedora booth. Be sure to read the event report for the full details.
Fedora 9 Release Party - Rio de Janeiro
Rodrigo Padula posted  pictures from the Firefox 3 and Fedora 9 release party in Rio de Janeiro.
Event Budget Deadlines
Max Spevack reminded  ambassadors that the deadline to have your event on the Fedora Events  page is August 1st if it falls between September 1 and November 30. In order to be considered for the FAmSCo budgeting process the events need to be posted to the wiki. The email to the ambassadors list contains the full details.
Contributing writer Osin Feeley
New RPM Sparks Exploded Source Debate
The announcement of a sparkling new alpha-version of RPM by PanuMatilainen was greeted with congratulations and applause and later some passionate argument. It has been approximately one year since Panu solicited (see FWN#98 "Panu Opens Pandora's Box" and FWN#99 "RPM Roadmap (Cont.)") suggestions from those not intimately involved in RPM development as to which problems should be fixed. This initiative was taken after deciding to move RPM-4.4 to bugfix maintenance due to artistic differences with the current RPM coder (who then led a very public fork named RPM5). Panu's new RPM-4.6.0 implements many of those suggestions as detailed in the release notes and many of those involved in the initial roadmap process (such as RalfCorsepius who cleaned up the autotool stuff also helped to implement the desired changes. By Panu's estimate over 2300 commits were made to the source since the initiative to get RPM development back on schedule began, and although the wiki provides essential details of what has been implemented there is still a good deal of information lacking.
The announcement contained suggestions for users (of Rawhide where the alpha is available) about how to trouble-proof themselves and a more extensive list of notes for packagers. Of note are the changes to the macros to eliminate the old buildroot directory defaults and ignore the BuildRoot in an rpm's spec file, and the addition of support for LZMA compression. Another cool new feature is the addition of a macro to allow iteration over all patches, something which was welcomed by JarodWilson, who noted that RHEL5 needed 1800 lines in the kernel specfile solely to mention each patch.
It seems that a massive amount of work has gone into API changes and internal cleanup of the code in order to set up a framework for the addition of new features in the future.
ThorstenLeemhuis expressed happiness with Panu's contribution but wondered whether the FESCo Feature process had been shown to be unnecessarily bureaucratic by the manner in which this change had occurred. JoshBoyer and JeffSpaleta drew a slightly different lesson and suggested that it ought to be made easier for a developer to determine whether their package upgrade should be filed as a feature. Panu also agreed that Thorsten's points were fair but excused himself on the grounds of concentrating on upstream RPM development and not being sure what the demarcation between feature and non-feature was.
PaulFrields suggested that it might be useful to think of the "Fedora feature process as leveraging what Fedora can provide for an upstream community. Two things that come to mind immediately are QA/testing and widespread publicizing of the feature." JohnPoelstra also drew attention to the synergistic advantages of the Features process resulting from its public communication of what is being worked on currently. CallumLerwick, responding to Thorsten, gave his understanding of the Features process as "a conduit for the Engineering side of Fedora to collaborate with the Marketing side of Fedora, to allow the Marketing people to build up pre-release hype for new features without having to second-guess us notoriously busy, and quiet, engineering types. It allows the Marketing people to keep tabs on engineering activities and have reasonable certainty as to the status of the feature, specifically whether or not it is going to be finished in time for the final release." He emphasized the voluntary participation of developers and software engineers in the process and the benefit resulting from having marketing clued-in to interesting changes. JesseKeating responded that the process was "way more than just marketing fluff. Features have very real schedule impact, just consider this time around, RPM with a bunch of new features, and a new gcc coming at some point soon. Usually we want to rebuild for both of those. Without some high level coordination, how do we schedule so that we rebuild once for all of the right reasons instead of multiple times individually?" The marketing advantages of the Feature process were confirmed by PaulFrields. MatthiasClasen made some concrete suggestions on how to improve the Feature process. They included the addition of definitions or explanations for each section and the perception that the review of his feature pages felt a bit like getting homework graded.  https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00580.html
The point about co-ordination of activities was highlighted when DougLedford confessed that his first reaction had been "Oh hell...what a colossal waste of time" when he realized that he had spent a week studying what was now obsolete RPM source code. Panu's friendly response that Doug "could've just asked" drew out the central problem: "Yeah, I know, I just didn't know a big update like this was in the works." Doug's interest lay in extending rpmdb to add fields to allow interaction with SCMs mostly "to be able to support exploded source repos and usage of exploded source repos as canonical source versions of binary packages." Panu answered that these sorts of changes were probably post-Fedora 10 and that he too was keen to integrate with SCM tools. He pleaded for some more patience to settle this clean, new codebase down before implementing such changes: "I know. People have been waiting SO long for various things to happen in RPM that everybody's out of patience and wants their stuff in NOW. Please try to be patient a little bit longer: once this release stabilizes, RPM can move to a "normal" development-release cycle where folks will not have to wait 5+ years to get their changes in :)" SethVidal and ToshioKuratomi were impatient with Doug's impatience[25,26] with the latter noting that Fedora Policy "to allow using source control repos interchangeably with tarballs would [not] be approved in time for F10 either."
Later Panu requested that packagers "refrain from using the new spec features in Fedora to minimize the fuss in case disaster strikes and we need to go back to rpm 4.4.x. The new rpm is on probation for a while ;) Please do test and use the new things as much as possible in private, just not yet in Fedora CVS. A further notification will be sent when the probation is over."
Doug expended a good deal of effort both trying to get an answer as to whether there was any point in him trying to go ahead and add some of the basic features which he thought were necessary, and also explaining why the ability to interact directly with a distributed SCM/VCS instead of through the middle-man of a tarball was a good idea. Among the advantages Doug described were "since you built the binary packages from this exploded source repo, then in order to give people the exact sources you built from, you need to make the repo available for clone/checkout by people. You need never once build an srpm or tarball from this repo if you don't want to [...] the first advantage to this type of setup is that every SCM worth a pile of dog poo will store the different versions of software in some form of change related format that keeps you from duplicating the same things over and over again like tarball after tarball does. You generally take a hit in size versus a single tarball, but end up saving quite a lot in the long run [...] you get to work on the code in native format, try things out, run build tests, and all the while the pain of repetitive rpm source processing is reduced[...]" Doug went on to explain that in the case where the upstream also uses a distributed SCM then things become even easier. He attached his notes (in tomboy format) with yet more detail.
Doug was obviously brimming with ideas about how this would make Fedora development easier and reacted with a certain amount of frustration to Panu's and Seth's assumption that he was asking them to do something which they could not get around to until Fedora 11. Doug also pointed out that the problem of forcing the creators of spins to distribute their own sources was also possibly solved by using distributed SCMs and that he had discussed this with JesseKeating at the recent FUDCon. His perception was that the Fedora Project was actively blocking Red Hat's needs. JesseKeating later returned to the problem of compliance with the distribution requirements of the GPL: "I either have to offer you a CD/DVD of corresponding sources in <insert vague nonlegal terms here> format, or provide you a written offer to provide the above that is good for the next 3 years, or pass along such written offer that I myself may have gotten. Nobody has confirmed nor denied what that <vague nonlegal terms here> means, nor how long the 3year clock ticks on those formats, and whether or not directions on how to get the source from our public source repo is OK."
This has been an inadequate summary of a complex topic. If you are interested in it you are well advised to read the thread especially Doug's posts and the responses to them. They start here.