The 2009-04-08 "Rawhide Report"<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00426.html</ref> caused some excitement when it seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00427.html</ref> that <code>moonlight</code><ref>Moonlight is an implementation of Microsoft's "Silverlight" which is a virtual machine and framework for creating Rich Internet Applications, roughly competing in the same space as Adobe's Flex and Mozilla's Prism. It is considered to risky to include in Fedora due to legal worries raised by the Microsoft-Novell covenant. </ref><ref>http://mono-project.com/Moonlight</ref><ref>http://www.adobe.com/products/flex/</ref><ref>http://labs.mozilla.com/projects/prism/</ref><ref>http://fedoraproject.org/wiki/ForbiddenItems#Moonlight</ref> might have been enabled. It turned out<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00500.html</ref> that this was simply due to a confusion between a <code>mono</code> API named "moonlight" and the actual <code>moonlight</code> itself.

+

The 2009-04-08 "Rawhide Report"<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00426.html</ref> caused some excitement when it seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00427.html</ref> that <code>moonlight</code><ref>Moonlight is an implementation of Microsoft's "Silverlight" which is a virtual machine and framework for creating Rich Internet Applications, roughly competing in the same space as Adobe's Flex and Mozilla's Prism. It is considered too risky to include in Fedora due to legal worries raised by the Microsoft-Novell covenant. </ref><ref>http://mono-project.com/Moonlight</ref><ref>http://www.adobe.com/products/flex/</ref><ref>http://labs.mozilla.com/projects/prism/</ref><ref>http://fedoraproject.org/wiki/ForbiddenItems#Moonlight</ref> might have been enabled. It turned out<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00500.html</ref> that this was simply due to a confusion between a <code>mono</code> API named "moonlight" and the actual <code>moonlight</code> itself.

All that had actually happened<ref>http://bugzilla.redhat.com/show_bug.cgi?id=492048</ref> was that Fedora Legal okayed the use of the mono compiler switch "moonlight" in order to facilitate RPMFusion's request.

All that had actually happened<ref>http://bugzilla.redhat.com/show_bug.cgi?id=492048</ref> was that Fedora Legal okayed the use of the mono compiler switch "moonlight" in order to facilitate RPMFusion's request.

Fedora 11

First[2], the F11-Beta-x86_64-Live-KDE.iso was re-issued on bittorrent as well as to the mirors. The image was "accidentally composed with 32bit packages instead of 64bit packages". Furthermore, the Source ISOs were re-issued on torrent only, where "an older set were
first issued there. The CHECKSUM on the mirrors was wrong as well for these isos and has been updated."

Next[3], Fedora 11 Snapshot 1 was released to the torrent site, and it provides "the first and final snapshot before our final devel freeze". Jesse reminded everyone that "lots of work has gone into the storage code of Anaconda since the Beta release, please do re-test with these images if you had difficulty installing the Beta".

The final development freeze[4] for Fedora 11 is on Tuesday April 14th. John Poelstra[5] reminded the community "that all features and their associated feature pages must be at 100% completion by this date", and he listed the features that do not meet this criteria, which includes several of the more prominent features that are scheduled for the release. If you are trying to get a feature in to Fedora 11, please make sure you have completed all necessary steps.

Ambassadors

Italians Fete Document Freedom Day

"Document Freedom Day," an event promoted by the Free Software Foundation, was held March 25 and aimed is to spread free documents formats and the Free Software culture. Luca Foppiano reports about his attendance at the event, which was held in Opera (near Milano, where in 2008 was organized "Liberamente") in his blog[1].

Luca spoke at the event about the core values of the Fedora project, whose aim is to spread the meaning of the 4 foundations in general, and Fedora’s policies around codecs and firmwares in particular - thus covering a wider subject matter, not only documents.

LinuxFest Northwest Ramps Up

A Fedora Activity Day and three Fedora speakers highlight the lineup for the 10th annual LinuxFest Northwest[2] in Bellingham, Wash., USA, on April 25-26. Held on the campus of Bellingham Technical College, the two-day event is free and open to the public.

Clint Savage will be hosting a session on Fedora Remix, Karsten Wade will talk on the topic "Participate or Die," Jesse Keating will give those at LFNW a sneak peek at Fedora 11 and what to expect later next month, and Larry Cafiero will give a Fedora 101 talk prior to the Fedora Activity Day, which takes place all day Saturday.

Prior to LFNW, Karsten Wade and Larry Cafiero are scheduled to address classes at Oregon State University in Corvallis, Ore., on behalf of Fedora on Thursday, April 23. The pair will also meet with the Linux Users Group on campus that evening.

Bellingham is just south of the Canadian border in northwestern Washington, and if you find yourself in the neighborhood, feel free to drop by.

Developments

Emacs, Glibc, Malloc and i586

As the pressure to stick to the Fedora 11 release schedule built up some glitches arising in part from the decision to support i586 instead of i686 (see FWN#162[1]) led to tense words.

Reports trickled in of problems with emacs in rawhide. Per Bothner reported[2] both that emacs-23.0.91 threw an "Invalid regex: Unmatched ( or \\(" and that emacs-23-0.92 was responding excruciatingly slowly. Ulrich Drepper speculated[3] to that the regexp problem was due to some changes to malloc in glibc. A bugzilla report by Andy Wingo expanded[4] on the problem and drew comments suggesting that rpm and mysql were also failing to due glibc changes. Jakub Jelinek thought they were different problems with the emacs errors being due to malloc_{get|set}_state.

TomLane asked[5] what was going on with glibc reverting to an earlier version in rawhide. Jesse Keating responded[6] that glibc for the i586 architecture was broken for all versions after beta. After Panu Matilainen commented that glibc.i586 was so broken that rpm could not even read its own configurations Ulrich Drepper said[7]: "If you want to complain then to the idiots who made the decision to go with .i586 instead of .i686 for x86 binaries. This is exactly the kind of problem I've been warning about all along. Using the i586 target stresses code paths (in this case in gcc) which are hardly ever used since nobody cares for this target in general." Panu disavowed any intent to complain.

Moonlight Still Banned in Fedora

The 2009-04-08 "Rawhide Report"[1] caused some excitement when it seemed[2] that moonlight[3][4][5][6][7] might have been enabled. It turned out[8] that this was simply due to a confusion between a mono API named "moonlight" and the actual moonlight itself.

All that had actually happened[9] was that Fedora Legal okayed the use of the mono compiler switch "moonlight" in order to facilitate RPMFusion's request.

↑Moonlight is an implementation of Microsoft's "Silverlight" which is a virtual machine and framework for creating Rich Internet Applications, roughly competing in the same space as Adobe's Flex and Mozilla's Prism. It is considered too risky to include in Fedora due to legal worries raised by the Microsoft-Novell covenant.

Mono Breakage on PPC May Cause Reversion

Another mono issue discussed[1] with reference to the 2009-04-08 Rawhide Report suggests that due to breakage on the ppc architecture it may be necessary to untag the latest mono package.

Objections that the disabling of PPC architecture support on the mono package was happening too close to the Fedora 11 final freeze prompted[2]David Nielsen to make the rejoinder that no help had been given to the Mono SIG despite their reporting a problem. Jesse Keating announced[3] that in the absence of a fix before the final freeze mono would simply be downgraded: "[t]his kind of version change shouldn't really be made after beta anyway."

Mary Ellen Foster requested, as a mono-dependent maintainer, that concrete actions be recommended. Jesse Keating and Toshio Kuratomi asked[7] that all such did _not_ set "ExcludeArch: ppc" and rebuild as this would cause massive churn on a large number of packages. Instead a process to track down the failures and fix them with a fallback plan to revert to a mono release-candidate was proposed by Toshio.

YUM Downgrade Feature Now in Rawhide

James Antill posted[1] that it is now possible to downgrade a package using

yum downgrade <packagename>

He suggested: "[...]this will be most useful for rawhide users when installing test packages from koji static repos. etc. ... because then an older version will still be available in rawhide. Whereas if you upgrade to what is in rawhide there is nothing older available to downgrade to."

Multiple Package Ownership of Directories

A query posed[1] by Rahul Sundaram concerned whether it was appropriate for multiple packages to claim ownership of a directory.

Michael Schwendt and Christoph Wickert were[2] clear that the packages Rahul mentioned should not own the directory because they were part of a dependency chain which led up to their ancestor package hicolor-icon-theme. Contrary advice led[3] to some sarcasm from Christoph Wickert about Red Hat employees not being familiar with Fedora packaging guidelines and it worried[4]Peter Lemenkov, who believed that Red Hat employees all had "provenpackager" status (see FWN#170[5]). Jason L. Tibbitts III corrected[6] this latter assertion.

Zap DontZap

Paul Wouters reported[1] that he had needed to ssh into his machine to fix an X session problem and would like to revert "[...] to the old behavior of having ctrl-alt-backspace kill the current X session." See FWN#169[2] for earlier discussion.

to which Michael Cronenworth responded[3] that this would need to be done in a start-up script as there was also now no xorg.conf by default. Jesse Keating suggested using the system-config-display tool instead as this would obviate the need for an xorg.conf. Adam Jackson cautioned[4] that nVidia's proprietary drivers might not export RANDR-1.2 yet and thus the latter might not work. Further discussions about whether xorg.conf was needed for side-by-side wide virtual desktops suggested[5] that Intel chipsets while currently enforcing a 2048 pixel limit may be[6] capable of supporting up to 4096 pixels on Intel 915 or Intel 945 in the near future.

Dissent and discussion about Fedora's decision to follow the upstream rumbled on. Kevin Kofler suggested[7] that "mailing list consensus" was not a good process by which to make such decisions as that taken by Xorg. Dave Airlie seemed[8] as though he had had enough of personal attacks on him, but was also able to joke about it.

Translation

Fedora 11 Release Notes Discussion

After the announcement last week[1] about the availability of the Fedora 11 Preview Release Notes for translation, a number of translators have put forward their concerns about the difficulty in translating these notes due to vast coverage of content and complicated technical text[2].

As a solution to this, it has been suggested that the Release Notes be restricted to information that is important to general users and useful to migration from on release to another. The additional information about package improvements etc. may be made part of the SIG pages on the wiki.[3]

One of the writers Ruediger Landmann, has put forward the link to the draft version of Fedora 11 Installation Guide for similar feedback.[4]

At present, some of the teams have chosen to either translate the core information, divide the translation work amongst multiple translators or to drop translation for this release.

Artwork

Finishing the Artwork for Fedora 11

John Poelstra asked [1] on @fedora-art about the lesson learned and the need for a special feedback period embedded in future release cycles "Maybe we should build a feedback period into the Fedora 12 schedule?" and the status of the remaining work for Fedora 11 "It is also important to note that we are targeting the completion of final artwork and packaging a little less than two weeks from now on 2009-04-16 so that it can all be in the Preview Release and have two weeks to shake out anything that needs final fixing before GA", with Paul W. Frields reinforcing[2] the question "How can we improve the schedule of dates for Artwork deliverables, so that they're more realistic or constructive?"

In reply, Nicu Buculei pleaded[3] for early, on-going feedback "I don't think we need a feedback period, we need to get some graphics (concepts) as soon as possible to get feedback from the early stages. Is not useful if one week before the freeze we learn that everything is not good enough, we have to scrap it and restart."

Appreciating the reminder[4] "Thank you for this reminder and for helping keep us on track", Máirí­n Duffy outlined a list of the remaining tasks: Wallpaper Design, Plymouth Splash, GNOME splash, KDE splash, full screen splash for syslinux, grub splash. gnome screensaver lock dialog, anaconda square splash, firstboot vertical header, kdm, wallpaper extras and she set a deadline[5] on the wallpaper polishing "I'm going to block off Thursday as the day to dive in and polish stuff off".

Nicu Buculei and Martin Sourada took one of the points, the wallpaper extras, further[6][7] and concluded "freeze is irrelevant here. It's highly probable it won't be on any of the official spins, so having the package released at the same day as GA is IMHO fine"

Charles Brej advanced a Plymouth animation proposal[8] "here is a possible progress bar in the style of the theme", followed by another minimalist proposal[9] from Mike Langlie, acclaimed by some[10][11] but also criticised by its use of proprietary tools under proprietary operating systems (Photoshop on OS X)[12]. A third mock-up[13] from Cătălin Feştilă is dismissed by Nicu Buculei for the use of English-only text " Fedora is an operating system for the entire world, we can't go with an English-only text. Due to localization concerns, is wise to avoid any texts rendered as graphics."

Also in preparation for the upcoming Preview Release and the General Release, Paolo Leoni posted[14] a release countdown banner, which evolved quickly with the feedback received into a complete, polished tarball[15], ready to run on the website.

Susmit Shannigrahi advanced a DVD label concept[16], criticised by Luya Tshimbalanga for the use of an obsolete theme[17] "Note that artwork used for Fedora 11 Beta is not final" an Nicu Buculei for excessive use of colors[18] "to keep the printing cost down ideally the label will use only a few colors". Apparently, according to Susmit, in his country the price is not affected by the number of colors used[19] "Well, here in India, they don't charge by color. They charge at a flat rate of 11INR(22 cents) each for bulk production."

Interview with the Art Team

In the previous edition of the Fedora Weekly News we reported about an interview with the Fedora Art Team being conducted for the Linux Graphics Users forum[1], now Nicu Buculei reported[2] on@fedora-art about the interview going live[3].

Fedora Virtualization List

Guest Configuration with augeas and libguestfs

After blogging[1] just last week that "Nothing much is coded at the moment", the prolific Richard Jones
announced[2]
he has added support to augeas for his latest project,
libguestfs[3]. libguestfs "lets you examine and modify
virtual machine disk images, so you can perform sysadmin tasks on
virtual machines without needing to bring them up or log into them."

"Augeas is a configuration editing tool. It parses configuration files in
their native formats and transforms them into a tree. Configuration changes
are made by manipulating this tree and saving it back into native config
files."[4] Now libguestfs "supports Augeas, so you can
use Augeas to edit configuration files within the virtual machine."

Richard will be working on creating a Fedora RPM of libguestfs this week.

Virtualization Technology Preview Repo

Daniel Berrange
followed up the recent release scheduling conversation (FWN#169 [1])
with a "braindump"[2].

"The obvious problem with what we do for libvirt at the moment, is
that we are introducing major new features into the stable release
stream". Adding "I think it would be desirable to get the stable Fedora releases onto a
pretty strong bugfix only policy..."

Daniel suggested "a 'virt-preview' YUM repository for the most recent stable stream (ie F10, but not F9)"
as a way to achieve this "bugfix only policy", and allow users access development versions of libvirt
"without having to include & debug the rest of rawhide". Daniel summaried the "braindump".

"So in summary":

All new upstream releases built in rawhide

New upstream releases also built in stable preview branch if possible

Only bugfixes built in stable updates/updates-testing branch

In exceptional circumstances, rebase for preview branch can be built to updates/updates-testing after alot of positive testing

"This would":

Ensure users of stable Fedora release have high confidence in quality of the updates/updates-testing stream

Allow users to trivially test new upstream rebases while staying on the stable distro stream

Improve testing coverage of major new rawhide features without using the stable release stream users as guinea pigs

Mark McLoughlin
thought[3]
"this would be hugely useful to people interested in the latest
virt bits, but without a testing machine for running rawhide." And even
proposed a name for the proposed repository, "How about 'virt-hide' ? :)".
Mark also reverenced
these FESCo approved guidelines[4]
relevant to package maintainers who wish to update a package on an already-released branch.

Libvirt List

libvirt-TCK Technology Compatibility Kit

In yet another "braindump" this week,
Daniel Berrange
penned[1]
"a very long email" purporting to be a "short guide" to the new libvirt "Technology Compatibility Kit".

libvirt provides a hypervisor or emulator neutral platform for
manipulating virtual machine resources. This model leverages "drivers"[2] for
each emulator or backend system. The driver acts as a translator, converting libvirt API calls to the native API.
For example, there are drivers for
Xen, QEMU KVM, LXC, OpenVZ, User Mode Linux, and storage subsystems.

"The libvirt TCK provides a framework for performing testing
of the integration between libvirt drivers, the underlying virt
hypervisor technology, related operating system services and system
configuration. The idea (and name) is motivated by the Java TCK"

"In particular the libvirt TCK is intended to address the following
scenarios

Validate that a new libvirt driver is in compliance with the (possibly undocumented!) driver API semantics

Validate that an update to an existing driver does not change the API semantics in a non-compliant manner

Validate that a new hypervisor release is still providing compatability with the corresponding libvirt driver usage

Validate that an OS distro deployment consisting of a hypervisor and libvirt release is configured correctly

Thus the libvirt TCK will allow developers, administrators and users
to determine the level of compatability of their platform, and
evaluate whether it will meet their needs, and get awareness of any
regressions that may have occurred since a previous test run."

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, and JBoss are trademarks or registered trademarks of
Red Hat, Inc. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community
maintained site. Red Hat is not responsible for content.