Fedora

We're adding a group of dual-core, 1GHz, 1GB PanadaBoards to the Fedora-ARM build farm.  Paul Whalen and I hacked up the PandaBoard builder filesystem at FUDCon and I tested it with the farm on Thursday -- so far, it appears to build about twice as fast as the older GuruPlug builders. The PandaBoard's randomly-assigned-at-boot MAC addresses did force us to take a new approach to builder identity, though, because our previous approach of serving the identity via DHCP was no longer practical.

We ordered a total of 15 PandaBoards; 12 have arrived, and the others should be shipped shortly.Two are being set aside for testing, and we'll get the other ten building as soon as possible.

Our plan is to stack the boards on threaded rods, powered by an ATX power supply; the stack will be run on its side (with the boards oriented vertically) to aid in convection cooling. More photos to follow as we get this running! (Yes, that is a Powered by Fedora badge on there )

This semester is the fourth time that I've run the Software Build and Release (SBR600) course at Seneca College, and we have record enrollment – a full house! This course is one of a number of open source courses connected with the Centre for Development of Open Technology; it is a professional option in our Computer Systems Technology program, which focuses on network and system administration, and it has two goals:

• Teach software build and release (aka Release Engineering/Build Team) principles, technology, and skills
• Teach how to contribute effectively in an open source community

In this course, I use the Fedora build and release process as a illustration of how large-scale build and release works, something which is only possible because of the transparent nature of open source processes. I also use Fedora as a community which is open to worthwhile contributions from any interested participants. In these first three weeks of the course, we've examined building from source, RPM packaging, the use of mock for build dependency testing, the use of koji for multi-platform testing, signing packages, and creating package repositories. The remainder of the semester is largely project-based.

The students are currently researching and selecting projects from a short list of potential projects which have been screened for manageable size and practical real-world value. This semester, many of these projects are focused on the Fedora ARM secondary architecture, since the ARM buildsystem is physically located at Seneca, but some projects are related to different areas within Fedora (or, in one case, Fedora+Mozilla). In all cases, the students are expected to work with the community, use community communication tools and practices, and ultimately, advance the state of the respective area to which their project contributes. That means that if new software is packaged, it will be put through package review and end up in Fedora; if scripts or programs are written, they will be reviewed and committed upstream; and if documentation is written, it will end up in an appropriate and accessible place such as the wiki.

On Friday, ten SBR600 students will be traveling with Paul Whalen and me to FUDCon Tempe – eight students from the current semester and two from the previous semester. They're looking forward to making connections with other Fedorans, hearing about the latest and greatest technology, hacking, and generally starting down the road to becoming active contributors.

Please join us! -- I invite you to check out what we're doing, either in the usual Fedora places or in the #seneca channel on Freenode, on the Seneca wiki, or on Planet CDOT.

My apologies to anyone experiencing a large volume of build notifications from the fedora-arm koji system. We're attempting to build F13 and are experiencing a lot of build failures (as expected).

I've added some dependency checking to the build script (big thanks to Seth Vidal for the yum code snippets!) which should make it a bit smarter about build order. Build notifications have been turned off until we get the failures down to reasonable levels.

Fedora 13 was release a few weeks ago. We're going to celebrate the release at a release event in Toronto on July 5th. Here are the details:

• Who: Fedora Community -- and anyone interested!
• What: Fedora 13 Release Event
• Where: Seneca@York, TEL Building, room T1009
• When: Monday, July 5, 6 pm
• Why: To celebrate the release of Fedora 13 "Goddard", distribute Fedora 13 discs and discuss its new features, and meet up with other Linux contributors and users
• Wiki URL: http://bit.ly/f13-toronto

Please join us if you're interested. I hope to see you there!

Sugar on a Stick is a project which aims to create a live learning environment on a USB stick. This environment is a Fedora spin hosting the Sugar environment (the learning software original created as part of the OLPC project).

In previous versions of SoaS, the activities were not thoroughly screened before inclusion in the Spin, and so the SoaS Activity Criteria were introduced. I've been working with some other POSSE RIT participants to try and get three activities - Abacus, Maze, and Memorize - to the point of meeting the criteria. It's been a frustrating experience, but we've made some progress:

• Abacus
• Performed a package review (not passed, but close) of Peter Robinson's sugar-abacus package in Fedora
• Created a basic page for recording smoke test results
• Maze
• Filed a bug against the sugar-maze package in Fedora (apparently missing an essential .py file)
• Memorize
• This activity meets most of the criteria, but we weren't able to save to the journal (know issue) and could not confirm that collaboration works (might have been our Sugar configuration or networking)

It's apparent that the Sugar project needs more contributions, including wiki gardening, testing, and documentation -- all of which are areas in which new contributors can become quickly involved.

HTML5 provides <audio> and <video> tags for sound and video content. However, every browser seems to support a different combination of codecs and containers for these tags. Open source projects have of necessity only been able to support open formats, but proprietary vendors have been reluctant to throw their weight behind those open formats.

At GoogleIO today, Google, Mozilla, Opera, and 30+ other partners announced WebM, an open source mashup of the Matroska container format, Vorbis audio codec, and newly-open-sourced VP8 video codec. The intention here is to provide a "safe", open-patent-grant format that both open source and proprietary products can integrate. To that end, the WebM code is licensed under a BSD + patent grant license. And, of course, with Google/YouTube supporting this format, there will be a lot of content available.

So how does this touch Fedora? It looks like current Firefox nightles support WebM, and gstreamer support is in the works; hopefully, this will land in time for Fedora 14. For rpmfusion/ffmpeg users, WebM support is in today's upstream ffmpeg release.