Planet Fedora

Activism Alert

Oron Peled wrote[1] about a proposed new IETF standard for "Transport Layer Security (TLS) Authorization Extensions" which may be patent-encumbered before it is even approved.

Paul W. Frields appealed[2] for prior art against a patent that covers a user interface that has multiple workspaces (filed 1987-03-25).

General

Dave Jones announced[3] some changes to the Fedora kernel packaging "to drop the regular 686 kernels. As of Fedora 11, the only 32-bit kernels built are '586' and '686-PAE' (and their -debug variants)."

Lennart Poettering described[4] some of the new changes in the latest PulseAudio 0.9.15 release, including Flat Volumes, On-the-fly Reconfiguration of Devices (aka "S/PDIF Support"), Native support for 24bit samples and support for Airport Express.

David Nalley wrote[5] about the Fedora Ambassadors giving away free XO laptops! To qualify, either "Package and maintain a sugar-* package for 2 releases or more" or "Build a Sugar activity that helps meet the 'holy list of 4th grade maths[6]'".

Andrew Overholt announced[7] the release of the Linux Tools project for Eclipse. The release has lots of features from profiling and tracing with SystemTap to autoconf and RPM spec file editor (with autocomplete) support.

Jef Spaleta expressed[8] mild excitement at Canonical's "Renewed focus on suspend resume". In a later post, he wrote[9] about comparing Linux (and even OSX) user experiences with respect to functionality regressions after an update.

Seth Vidal mused[10] on the fact that a poster on Planet Gnome[11] had said that "Fedora is held to a higher standard" than certain other distributions.

Harish Pillay reacted[12] to an IDC report claiming "Proprietary software products are much better documented than open source because of the volunteer nature of open source software development".

Ambassadors

FAD SCaLE coming up 2009-02-20

The Fedora Activity Day[1] at the Southern California Linux Expo (SCaLE)[2] will be from 9am - 6pm on 2009-02-20 at the Westin Airport Los Angeles, in Los Angeles, California.

There will be breaks and such, but the FAD will be treated much like a sprint. We're here to get something accomplished -- specifically font packaging and documentation -- so come on by and help us out for an hour or all day. We'd love to have you there!

Also, if you can make SCaLE from the Southern California area, stop by the Fedora booth.

SCaLE takes place on this weekend at the Westin Airport Los Angeles. For more information, visit the Southern California Linux Expo site[3].

Next week's test day[4] will be on the 20 Second Startup[5] feature planned for Fedora 11. It will be held on 2009-02-19 in the #fedora-qa channel on Freenode IRC. Please drop by if you would like to help test and improve boot speed for Fedora 11.

Weekly meetings

The QA group weekly meeting[1] was held on 2009-02-11. The full log is available[2]. Will Woods gave a status report on the progress of the autoqa[3] project, which is working on creating automated test scripts to run whenever certain events happen. He also reported on progress with the Nitrate[4] project, which is for collecting test cases and test plans and compiling results from running them. Jóhann Guðmundsson asked if it will be possible to pull existing test cases from the current Wiki-based system into Nitrate when it is released, and Will Woods said this is likely to be possible.

The Bugzappers group weekly meeting[5] was held on February 10th. The group agreed that the current list of most-important components should be updated, and Edward Kirk will do this. Edward Kirk, Brennan Ashton and Adam Williamson (links) agreed that simple goals should be set for the group, but did not reach final agreement on what these should be. Adam Williamson suggested that Bug Days be revived and made weekly, and this idea was supported by Edward Kirk and Brennan Ashton.

The next QA weekly meeting will be held on 2009-02-18 at 1600 UTC in #fedora-qa, and the next Bugzappers weekly meeting on 2009-02-17 at 1700 UTC in #fedora-bugzappers.

Release-critical bug process

Adam Williamson initiated a discussion[1] regarding the process for handling release-critical bugs. Matej Cepl, James Laska, Jesse Keating, and John Poelstra contributed opinions. In the end it was agreed that the basic shape of the current process is a good one but the groups involved - BugZappers, release engineering, and developers - should communicate and collaborate more in deciding on release-critical bugs.

Xorg/Mesa/DRI testing

François Cami, together with others, proposed a project[1] to conduct organized testing of X.org and DRI functionality with a range of common hardware for Fedora 11. He highlighted four important areas he felt were needed for this: an opt-in system to record what hardware is owned by what testers (possibly utilizing Smolt), a system for producing test plans, a system for recording the results of tests, and regularly scheduled test sessions. Jóhann Guðmundsson supported the idea[2] and suggested that, while some of the features would require help from the infrastructure group, the QA group could at least immediately start writing test cases. James Laska pointed out that extensive information is needed to diagnose and fix X issues remotely. François will work with the X maintainers to define exactly what information needs to be provided.

Developments

FLOSS Multimedia Codec Support

Inspired by previous discussions on whether Fedora should distribute FLOSS content[1]Martin Sourada tried[2] to start a discussion about the poor support of FLOSS multimedia. Martin noted: "Out of the combinations of two FLOSS containers (matroska and ogg) and two FLOSS video codecs (dirac and theora) I know only one (ogg + theora) actually works in xine-lib (used by KDE4) which is pathetic." He asked for help in documenting the situation on a wiki page[3].

When Bastien Nocera suggested that the most important thing was to file bugs Martin responded[4] that this was what he was doing after first performing tests.

An information packed sub-thread started[5] by Gregory Maxwell expanded the scope of the tests and started a discussion with Dominik Mierzejewski about the problem of ffmpeg providing sub-optimal implementations of unencumbered codecs. It seems that for reasons of efficiency ffmpeg re-invents the wheel from scratch instead of using and improving upstream implementations. Kevin Kofler also rose[6] to the implied challenge that GStreamer was preferable to xine-lib.

Multiple Packages from One Source ?

A question about how to handle the situation where a single source could be compiled with alternate databases was posted[1] by Steven Moix. The motion video motion detector software can be compiled to use either MySQL or Postgres. Steven explained that the problem was that "[...]you can't divide it into sub-packages, at the end it generates one big binary file [...]" and wondered should he just choose the database he preferred or propose two packages.

Manuel Wolfshant expressed[2] what appeared to be the common wisdome: "personally I would compile twice, once enabling mysql and another time pgsql, and create 2 packages. each package would install a "motion-dbname" binary, and a symlink would allow access via the well known name "motion". Using alternatives would allow a switch between the two."

Although it was admitted that David Woodhouse's suggestion[3] to make the program use loadable plugins was the ideal Tom Lane thought[4] that was "[...] a bit above and beyond what a packager should do. If he's also an upstream developer, then he should undertake that addition with his developer hat on; but it's *well* beyond the size of patch that a Fedora package should be carrying."

The ability to specify alternate requires (similar to those used in the .deb package format[5]) was discussed[6] by Richard W.M. Jones and Tom Lane and dismissed as impractical in this case anyway due to variations in SQL.

Take a Peek at the Fedora 11 Release Notes

Fresh from his work on the RHEL-5.3 Release Notes Ryan Lerch apprised[1] the list of the latest changes to the Fedora 11 Release Notes. Ryan sought early feedback and changes to documentation beats in order to give the community an early preview of the release notes.

Initial feedback from Thorsten Leemhuis and Kevin Kofler and others indicated that the use of fixed-width instead of liquid layout was disliked by some people and loved[2] by others.

Heads Up: Noarch Subpackages Landing Soon

Florian Festi warned[1] that the ability to produce noarch subpackages will soon be available in Fedora. This brings the benefit of being able to share these packages among different architectures thus reducing disk space and mirror bandwidth.

Although rpm-4.6 supports noarch fully there are still some fixes to make to koji before the Fedora buildsystem can cope with noarch subpackages. Florian suggested that those who wanted to could experiment in mock with rpmdiff to compare the results across different architectures. He assured readers that there were no plans to force packagers to use this feature and invited anyone interested in developing the use of noarch in future release to a discussion.

Florian later warned[2] that one potential negative outcome of using such sub-packages would be a proliferation of packages and consequent bloating of metadata which might affect yum.

VilleSkyttä suggested[3] that it would be wise to make sure that use of BuildRequire: rpm-build >= 4.6.0 was enforced in order to ensure that earlier versions of rpmbuild did not produce noarch versions of the main package and other potential subpackages. Florian's response recognized[4] the problem but deprecated the use of BuildRequires to such an extent. One possible alternative which he proposed was to "[have Panu Matilainen backport a check that will make noarch packages (both regular and noarch) fail to build if they contain binaries [and ensure that this] additional check will be in place before koji will be updated[.]" This latter proposal stimulated a good deal of interest from Ralf Corsepius and Richard W.M. Jones as they were both concerned with cross-architecture issue. The definition of a "binary" seemed to be one unclear point.

In a later thread Florian updated[5] a list of packages which could be easily turned into noarch subpackages.

Mass Rebuild Coming Soon

Jesse Keating drew attention to "[...] a perfect storm brewing for Fedora 11" due to the need to rebuild with GCC-4.4 (see FWN#161[1], the use of i586 as the default supported architecture (see FWN#162[2] and the support of stronger hashes (last paragraph of FWN#107[3]).

Apparently the time-constraints led to a desire to start the rebuild as soon as possible without giving maintainers an explicit window in which to do their own builds. Jesse preferred to give maintainers an ability to opt-out and sought suggestions on how this could be achieved.

Jesse suggested that interested parties should either reply to the thread and/or participate in the 2009-02-16 IRC meeting in #fedora-meeting at 1800UTC.

Translation

Additions to talk.fedoraproject.org

Rafael Gomes has volunteered to update content on talk.fedoraproject.org[1] and would be creating the .pot file to make it available for translators. Additionally, Lucas Do Amaral has volunteered to add content regarding ekiga configuration[2] that would ensure error free display of the translated content, as had been earlier reported by Richard van der Luit [3].

Further discussion on the Infrastructure Roadmap

In continuation to the earlier discussion, Dimitris Glezos mentions that the important issue currently is the inconsistent uptime of the system due to the lack of administration resources [1]. He also mentions that adding Publican support to the Transifex instance would be possible with support from the Fedora Publican group. Additionally, he mentions that Transifex v0.5 to be released in March, would have support for Statistics based display as a start to the future goal of supporting all the features of Damned Lies. It is to be noted that FLP uses Damned Lies and Transifex for its Translation infrastructure.

Domingo Becker added a wishlist[2] for the current system, that includes reservation of files for translation, timeout and notification system to the co-ordinator.
In a separate thread, Francesco Tombolini voiced his opinion about the lack of the file locking feature and the downtime in the statistics page [3].

cgit to replace gitweb?

Seth Vidal said[1]that he has setup cgit as a replacement for gitweb on hosted2 and it is available at hosted2.fedoraproject.org/cgit/
He said that he would like to replace gitweb as a web based git repo browser but that would mean that the urls from gitweb will not work any more. He said that he would like to get some feedback on this.

Artwork

Evolving Fedora 11 Artwork

The development of the Fedora 11 artwork evolved on @fedora-art. Máirí­n Duffy posted[1] a new wallpaper mockup[2]: "It's more really an attempt at a nice backdrop, and maybe we can layer some of the trees and buildings we were talking about on top[.]"

Charles Brej investigated[3] boot animations: "On the plymouth front, I am likely to be a bit busier at work this release than the F10 one, so I would really appreciate some of ideas as to what people would like during the system boot. The possibilities are pretty much limitless but it would be a good thing to conserve the CPU and keep the number and size of images included in the initrd to a minimum".

Security Week

Is Open Source Software Secure?

This week there was a story posted to Slashdot titled How To Argue That Open Source Software Is Secure?[1]. Quoting the post:

... saying that they were warned that they are dangerously insecure because they run open source
operating systems or software, because 'anyone can read the code and hack you with ease.'

This issue seems to keep coming up from time to time. This argument is of course silly and one of those "Prove it ... you can't? So it's true!" There is no way to prove that a piece of closed source software is more or less secure than a given piece of Open Source Software. If you can't see the source, you can't be certain that the vendor did or didn't fix issues. You need to unconditionally trust your vendor. If the source code is wide open for anyone to see, it keeps the vendor honest. You can't sweep issues under a transparent rug. You can try, and maybe hide a few piles of dust, but the really scary piles of dirt will stick out like sore thumbs.

The issue at hand isn't is application A more secure than application B, but do you trust vendor A more than vendor B?