- 1 Fedora Weekly News Issue 149
- 1.1 Announcements
- 1.2 Planet Fedora
- 1.3 Developments
- 1.4 Translation
- 1.5 Infrastructure
- 1.6 Artwork
- 1.7 Security Advisories
- 1.8 Virtualization
- 1.8.1 Enterprise Management Tools List
- 1.8.2 Fedora Xen List
- 1.8.3 Libvirt List
- 1.8.4 oVirt Devel List
- 1.9 OLPC Fedora SIG
Fedora Weekly News Issue 149
Welcome to Fedora Weekly News Issue 149 for the week ending October 26, 2008.
We are happy to announce a new beat covering the development of the OLPC XO laptop and the Sugar interface authored by Pascal Calarco. This week samples of beat contents include: OLPC detailing "Merging OLPC with Rawhide"; Announcements alerts us to "Fedora 10 Snapshot 3"; PlanetFedora rounds-up "Events & Trip Reports"; an emotional Developments stares at "Flinging Poo at libtool-2.2"; Translations brings news of "Freeze Breaks"; Infrastructure examines some "FAS Dump Breakage"; Artwork sounds out "Sound Themes" and a new "Four Fs Poster Designs"; SecurityAdvisories faithfully lists this weeks important updates; and Virtualization is again compelling reading with a "New Model for Network Interface Configuration" in its oVirt subsection.
If you are interested in contributing to Fedora Weekly News, please see our 'join' page.
In this section, we cover announcements from the Fedora Project.
Contributing Writer: Max Spevack
Features & Final Development Freeze
John Poelstra announced that "if all goes as planned, the final development freeze will arrive... on October 28, 2008." All features and their associated feature pages must be at 100% completion by this date.
fedora-wiki list for wiki users and contributors
Ian Weller wrote about a new fedora-wiki mailing list. "Among the discussions will be policy, announcements, and editing tips. The list has been created to bring together the wider wiki community split apart between different sub-projects of Fedora."
Fedora 10 Snapshot 3
Jesse Keating announced the availability of another Fedora 10 snapshot. "This is the final snapshot before our final devel freeze and subsequent preview release. On the torrent site you'll find install images and live images for testing."
In this section, we cover the highlights of Planet Fedora - an aggregation of blogs from Fedora contributors worldwide.
Contributing Writer: Max Spevack
Events & Trip Reports
Yaakov Nemoy wrote about his trip to the Central Pennsylvania Open Source Conference.
Greg DeKoenigsberg and Chris Tyler both posted about the first day of FSOSS in Toronto. Of particular interest is the "Teaching Open Source" track, as well as the FSOSS planet and flickr page. Jack Aboutboul posted about his first day at FSOSS, as did Paul Frields.
Sandro Mathys had done a fantastic job preparing for FAD EMEA, and he posted the latest status update about that event to all the Ambassadors.
Fabian Affolter prepared five activities for the XO, and submitted the packages for review.
Jeremy Katz discussed some tips about the best way to make the Fedora 10 Snapshot 2 work on the XO.
Dan Walsh wrote an interesting blog post about "security vs. usability" tradeoffs, based on his experiences at a conference in Washington. The full post is related to both SELinux and Xen.
John Poelstra posted an article that emphasisizes the WHY, as opposed to the HOW, of bug triage. Two of the reasons that he mentions are that triage "saves package maintainers time chasing down missing information in bug reports" and that it "allows maintainers to spend their finite time on bugs that are ready to be worked on".
In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
Splitting Up R
Tom Callaway alerted the list that he intended to merge the
R-devel package with the base
R package. Tom's motivation was that many complaints had been received from users who attempted to install extensions from the external CRAN repository using R's built-in package system. "This doesn't work unless you have R-devel installed. The average R user is a professor or a student, and neither of them are going to necessarily possess the necessary Linux/Fedora knowledge to be able to understand why this doesn't work like the R documentation says it should." Tom recognized that this was a violation of the Fedora Packaging Guidelines and that he was "[...] not entirely sure if I need FESCo or FPC approval to take this action, if so, this is my notice of requesting it. ;)"
 R is an interpreted language based upon S and Scheme intended to be used for statistical computation: http://www.r-project.org/
Enrico Scholz suggested instead: "[...] add it to comps.xml [or] move 'R' to Rcore, and add 'R' which depends on 'R-core' + 'R-devel"' which have the major advantage of not missing all of R-devel's dependencies. Tom accepted these points because "[...] the suggested R/R-core/R-devel split instead [would allow users] to get everything with yum install R, it would meet the guidelines, and minimal installs with R can simply have R-core."
James Antill agreed that the general model of "foo-core + additions" was maintained by such a split but asked "[...] why don't we just package more of the
R modules so
CRAN usage isn't a requirement?" José Matos answered that there were far too many R modules "[...] more than 1500 modules (the have been growing at an exponential rate in the last years). So while we would like to see more R packages in Fedora in are not even near to have a reasonable subset of R packaged." James worried that "[...] you could use that argument a lot (there are probably still more unpackaged libc using things than packaged)." James showed that there were many more unpackaged users of libc than packaged using:
repoquery -whatrequires '*-devel' | \ fgrep -v - '-devel-' | \ fgrep -v - '-static-'
The availability of a tool named
R2spec to convert
R package formats to rpm packages was mentioned by Matthew Salzman. Later threads which appeared in part only on @fedora-r-devel investigated the problem of languages implementing their own packaging systems. José Matos played Devil's Advocate with the remark that "[...] each language is building its own repository and packaging system in a sense we have lots of equivalents of (yum+rpm) for each language (perl, php, python, R, tex, ...) [but] for the system to be really useful it must use the least possible denominator (read the dumbest wins- pun intended ;-) )." José suggested that R2spec could also be tweaked to discover dependencies and include them in its generated spec files. It appeared that Pierre-Yves had a "[...] small script to update the spec file when there is a new release of an already package R-library. This might be something that I should develop maybe a bit more now (especially since Bioconductor[12a] 2.3 has been released with R 2.8.0)"
[12a] Modules primarily for bioinformatics and genomics.
Flinging Poo at libtool-2.2
A discussion on the future of
libtool in Fedora is worth reporting although it is slightly older. Orion Poplawski wondered whether it was the correct time to integrate
libtool-2.2.X into Fedora 11. Benjamin Kosnik wanted it available in Fedora before
GCC was bumped to
gcc-4.4.x as that will depend on
A possible need for FESCo approval was expressed by Karsten Hopp as he was worried that "[...] it breaks up to 300 packages according to my mass rebuilds. I'm going to prepare a Wiki page with details about that." That prompted the first of several queries about the purpose and suitability of
libtool. David Woodhouse asked "[i]sn't the whole point of libtool that it should make things _easier_, not break huge swathes of packages whenever we change it? How about we fix those 300 packages by making them _not_ use libtool, rather than making them use the latest version?" Toshio Kuratomi thought that "If the state of the art has advanced and there's a tool that can replace libtool so a developer can say `I want a shared library' and the tool builds it on all platforms then we could look into getting upstreams to switch but simply getting rid of libtool in favour of handcoding Makefiles to build shared libraries is a step in the wrong direction."
AdamJackson offered that gcc was available on
OSX with the conclusion "[m]st of the complexity in libtool (and autotools in general) is to support systems that simply are not worth supporting and that practically speaking don't exist anymore. I'm being slightly flip in saying 'gcc -shared' but really not by much. Honestly for any fringe platform the correct thing to do is port gcc/binutils/gmake first." There were many disagreements on this point and Sam Varshavchik posted a convincing potted summary of them: "There's much more to libtool then just building shared libraries. If you remove everything from libtool that supports ancient platforms, you'll still have quite a bit left. For example, libtool builds both shared and static libraries in parallel. That, alone, saves you from dealing with a massive hairball in your makefiles. Ask anyone who works on a large, complicated app, that links with its own shared libraries. The option to easily build a statically-linked version is quite invaluable, for debugging purposes."
The practical experience of the MinGW project related by DanielBerrange was also that gcc -shared was insuOEcient i[...] if you're trying to build for windows. The mingw32 work has only been made viable because libtool has basically taken care of the horrible shared library build process required by Windows.j Further details were supplied at Adam's request and KevinKoAEer confirmed that producing a DLL involved several complications.
Discussion of alternatives veered towards
CMake. Braden McDaniel was unconvinced that this was a realistic suggestion for replacing libtool in approximately three hundred upstream projects. Kevin Kofler took a detailed look at the problem and argued that attempting to "[...] convince the automake developers to use something other than libtool is pointless, because automake should also go away, it's at least as obsolete, buggy, unable to maintain backwards compatibility, annoying, a massive time waster at build time and a major PITA for developers to code with as libtool is. The whole autotools stack sucks. It always did, we just didn't have anything better. We now do, so why are people still using autotools?" His critique seemed convincing and he later added that "CMake is used by all of KDE 4 [...]" and in an exchange with Richard W. M. Jones explained that Gnulib was also not a good replacement for autotools: "[...] a "library" which works by copying itself into the source code of the project is a horribly broken concept."
LennartPoettering and RalfCorsepius were suspicious of the attempt to replace autotools with CMake. Ralf argued that "Cmake is imake in new clothes and suffers from the same design flaws as imake did. It's only the limited set of requirements being used by the limited set of use cases it's proponents apply which lets them think 'cmake is better'." StephenSmoogen saw a need to halt the conversation when he examined it from a human neuropsychology viewpoint: "So basically this conversation is a 'dead' conversation. People have their hairs on their necks up, [enough] testosterone pumping to put [out] 3 or 4 beards in a day, and are [on] to the flinging poo part. At this point, there is no way either side is going to say that Cmake is better at this, or Autotools is better than that. Wait a week, and see if one can bridge the gap with some diplomatic discourse[.]"
Later a new thread was started by Braden McDaniel to recommend that
autoreconf should be explicitly forbidden to be run by rpm packages. He explained that he saw the problems caused by running
libtoolize as "[b]y running autoreconf, the RPM build becomes exposed to different versions of autoconf, automake, and libtool than were used by the upstream developer to create the upstream source package. Newer versions of these tools have the potential to introduce incompatibilities, breaking the RPM build. Rather than patching configure.[ac,in] and Makefile.am, a more resilient approach is to patch the configure script and Makefile.in files."TillMaas added a link to a wiki draft on the subject and suggested that "[...] one should run autoreconf locally and create a patch from this, that is then used within the spec." The conversation veered into sharp disagreement as to whether autotool generated files should be treated similarly to "binary JARs (for which the packaging guidelines mandate that they have to be removed and rebuilt from source)" or this should be avoided in order to avoid "potential breakage". This issue seems destined to generate further disagreement.
Livna Migration to RPM Fusion
Several of the third-party repositories external to the Fedora Project agreed some time ago to merge into a single new entity named "RPM Fusion". The current partners include Dribble, Freshrpms and Livna. Thorsten Leemhuis reported that "[...] nearly all of livna's packages have been imported and build for RPM Fusion, but a few are still missing. So you should leave livna repos enabled for now if you want everything [.]" Thorsten explained the migration process in this post with the important details that "[...] all users that installed livna properly (e.g. by installing the livna-release package) and enabled the testing repos will now get RPM Fusion enabled automatically."
A suggestion was made by Nicolas Mailhot to either use the "modern proxyfriendly createrepo" or else "define http.caching=packages" in the yum repo files.
Users who currently have the Livna repository enabled can transition to the new RPM Fusion repository by:
yum install rpmfusion-free-release rpmfusion-nonfree-release
Sbin Sanity Stays
The latest FESCo meeting logs record that the decision to add
/sbin to each users
PATH variable (see FWN#146) will be kept until a working alternative for both non-root and root users is available. The brief deliberations indicate that FESCo members tended to manually add
/sbin to their own paths and distilled the objections to the sole point of "".
Thorsten Leemhuis was dismayed and agreed with Ville Skyttä that the change would4 result in many confused users. Thorsten wished to "[...] help Ville and Matthew making a real solution, where sbin stays "root commands" only, and where package that are right now get into he search path for ordinary users (either with symlinks or by moving the binaries). But it's IMHO best for everyone if we do that for F11. Come on, we had /sbin not in the path for more then how many years, so what is one half year more (especially as everyone that dislikes it is used to enable it already)?"
Jon Masters disagreed on the basis that any script should be using an explicit and absolute binary location anyway: "If you're writing scripts and not explicitly calling out the binary location, then it's not surprising if your scripts break later. I know it's nice to always assume a particular PATH, but it's not good practice any more than including or not including sbin in the PATH to begin with." He also cautioned that most other distributions had made this change a long time ago and that "[...] everyone else is already laughing that Fedora didn't do this, so really it doesn't need to wait for yet another 1.5 years to get done :)"
Packaging Webmin: Should it go in /opt ?
Andy Theuninck asked for some help in "[...] trying to put a package together for webmin. It wants to install to libexec, but if I do that rpmlint (rightly) complains that there are non-executable text files. Perl files & HTML files are intermixed and separating them out would be a patching nightmare [...] as I read FHS /opt would be the most appropriate place [but] if I try to use /opt/webmin [then] rpmlint pitches a fit about using /opt."
Toshio Kuratomi quoted the FHS[3:] "The FHS says: /opt is reserved for the installation of add-on application software packages. Anything packaged by Fedora is part of the system packaging rather than an addon so we stay out of /opt." He also suggested that separating the different files types and getting webmin's upstream to accept patches to do this was a preferred path in the Fedora Project. Failing this it was possible to separate the files and symlink them to the upstream-enforced layout. Another useful link to the Fedora Project's web application packaging guidelines in Toshio's post indicated that non-executable files might best be put into /usr/share. Andy seemed to like the idea of "[m]oving as much as possible over to /usr/share and symlinking against the files that are actually needed[...]" as this would allow upstream to continue to support many OSes by the simple expedient of "sticking everything into a single directory."
Nicolas Mailhot disparaged the use of /opt as "[...] he right place to dump messes and is good enough for ISVs with no ambitions but Fedora does not package messes [.]" Casey Dahlin cautioned Nicolas "Easy, he's here because he wants to do the right thing, and he's not upstream, so there's no reason to clueby4 him just yet" and went on to suggest a similar path to that above: "You might do what apache does and simply place the files where they go, then symlink them to a conf directory in /etc . You'd be doing it on a much larger scale than apache, but until you get upstream to suck less, you at least have a precedent for it (though doing it for apache hasn't particularly encouraged them to change their goofy-as-hell recommended file layout)."
 Filesystem Hierarchy Standard: http://www.pathname.com/fhs/
This section covers the news surrounding the Fedora Translation (L10n) Project.
Contributing Writer: Runa Bhattacharjee
Software Translation Deadline Ends
The software translation deadline for nearly all modules in Fedora ended on 21st October 2008. A few special modules like Anaconda would still be updated until prior to release time. Currently, the Fedora Translation Project members are concentrating their efforts on the documents, especially the Fedora Release Notes. The deadline for translations of the GA version of the F10 Release Notes is 13th November 2008
Bugs Filed for Virt-* Package Submissions
NorikoMizumoto and AnkitPatel announced the bug numbers on Red Hat bugzilla, which would be used to submit the various virt-* modules. These modules are not available for submission via translate.fedoraproject.org interface at the moment. Bugs for submitting translations for System-config-display and desktop-effects modules were also filed.
System-config-firewall, Comps and Packagekit modules underwent string freeze breaks this week due to feature inclusion and typo correction in the main modules. The maintainers have assured that the packages would be rebuilt to ensure the inclusion of the updated translations.
Missing Language Files for F10 Release Notes Added
Files for a few languages were added in the git repository for the F10 Release Notes by KarstenWade. As a result, translators can easily find relevant files in the translate.fedoraproject.org interface and submit the translations too.
SELinux Management and Policy Generation Tool Translations Not Available
IgorSoares reported the non-availability of the translations for the SELinux Management and Policy Generation Tools on the user interface. A bug has been filed as well.
This section contains the discussion happening on the fedora-infrastructure-list
Contributing Writer: Huzaifa Sidhpurwala
Change Freeze Begins Tomorrow
Mike McGrath wrote on the @fedora-infrastructure-list sent out a reminder that another pre-release change freeze will start and last till 11-05-2008.
FAS Dump Breakage
Michael Schwendt wrote on the @fedora-infrastructure-list that there has been an invalid entry returned by the FAS group dump for some time:
bbs,disabled,james francis toy iv,user,0.
To this Nigel Jones added that "The comma is part of the persons name, it needs to be either escaped or the delimiter changed (maybe a | or something)." Mike, however, said that there aren't any comma's in that persons name, its in his email address.
In this section, we cover the Fedora Artwork Project.
Contributing Writer: Nicu Buculei
Fedora Remix Mark
A few weeks ago when the process started, we reported about the request for a secondary trademark design for "Fedora Remix", a process which closed to the decision. On a cross-thread on both @fedora-art and @fedora-advisory-board Greg DeKoenigsberg opined for leaving the ultimate decision to the Art team "I don't suppose we could just defer to the Fedora Art team to make a decision, since we have set them up to be the authoritative voice on precisely these kinds of matters?" This opinion was backed by a number of other members.
Echo Icon Theme Future
In a long mail to @fedora-art Martin Sourada exposed his plans for the future of the Echo icon set "I'd like to focus on (nearly) full coverage of Desktop Live Spin, KDE Live Spin and XFCE Live Spin (others as well, but I don't have them all in memory)". He also pointed to some criticism about the set "we are a lot criticized for inconsistencies in the projection we use in echo" and talked about the various perspectives used "strictly speaking we are using 3 different types of projections and we have rules which is used where and we are pretty much consistent with that", a topic covered also on his blog and proposed a simplification "But on the other side it turns out that having three main types of projections is too much for an icon set and that having two is about the right number."
Hylke Bons, an Ubuntu developer, weighed in against the isometric perspective in Echo "I'm still not a fan of the isometric view of the bigger icons, i think it causes most of the noise in the icons. Also, I do not see a need for that particular viewpoint", while Luya Tshimbalanga proposed a simpler perspective for some image sizes "I remember having a discussion with Máirín about setting perspective for 24x24 and less icons. Perhaps applying that illustrated perspectivs to all categories at those sizes might help. Spherical icons will have much impact."
Nicu Buculei relayed to @fedora-art a blog post where Lennart Pottering raised a call for XDG sound themes and also expressed his concerns about how the team may have not encouraged a contributor "I am afraid we may have driven away Chris with the lack of feedback when he tried to create one" and a possible conflict with with the Desktop Team agenda "Also, with the Echo experience fresh in mind, I wonder if we create a new set only to get it called a 'charade' and 'if you think what you're doing is 'value add' that makes Fedora look better than the 'competition' you are wrong'."
William Jon McCann replied pointing to the lack of quality of the earlier theme proposal "However well intentioned Chris' effort may have been, the results are not suitable for use in a high quality desktop product. Have you actually listened to the theme that you reference here?" and likened it to the work on icons: "This is the same problem that some of us have with the way the icon theme and background art work has been handled in Fedora. I personally love to see lots of energy and experimentation going on. But at the end of the day we have to be concerned about our audience and how everything integrates into a coherent product" and also on wallpapers: "I think that the desktop wallpapers we've used by default are a good example of this".
Máirín Duffy felt patronized "I trust that was meant with the best of intentions, so I'm sad to admit I can't help finding this somewhat patronizing, sorry" and likened the open artwork creation with the open code creation "Just as you can't follow a formula like the GNOME HIG and pop out a beautiful, usable interface, you can't follow a formula like the Fedora theme guidelines and pop out a beautiful theme. The magic in between that makes something good is design. I'm quite saddened by the fact that you don't seem to believe this team has or is capable of having that magic, but I suppose to relate it to coding as you did in your message, perhaps not everyone felt Linus had the magic or capability to develop the magic necessary to start a real, usable operating system."
Paul Frields defended the art team "The Artwork team has always been open, in my experience, to criticism and suggestions about artwork. They exemplify the way Fedora teams work openly and transparently in a cooperative effort. And they've consistently turned out designs that are always solid, and often spectacular, not just for the desktop but for a variety of other uses too" and "At the end of the day, the Fedora Artwork team has been charged with the responsibility of the look and feel of Fedora. They're expected to do -- and have done -- that work in a community-friendly way, and people who want to have input into the process should do the same."
Nicu Buculei showed that open art should be developed in the same way as open software "Yes, I listened to the theme and found it not perfect. But know what? It was NOT supposed to be perfect... the 'release early, release often' mantra in FOSS is exactly that, put your work in the open as soon as possible so other can play with it, comment or contribute. How can the author improve his work without our feedback, knowing which parts are good and which suck?"
Four Fs Poster Designs
Máirín Duffy showed to @fedora-art and @fedora-marketing a number of posters for the new "Four F's" (freedom|friends|features|first) Fedora slogan, posters received with awe by the community,a sentiment probably described best by Ian Weller: "I saw these and my mouth was gaping open. These are very, very, very, very, very, very cool! Now I want to frame them and put them in my room."
In this section, we cover Security Advisories from fedora-package-announce.
Contributing Writer: David Nalley
Fedora 9 Security Advisories
- cman-2.03.08-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00666.html
- jhead-2.84-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00511.html
- php-Smarty-2.6.20-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00522.html
- squirrelmail-1.4.16-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00661.html
- gfs2-utils-2.03.08-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00665.html
- kernel-220.127.116.11-79.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00693.html
- git-18.104.22.168-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00729.html
- ktorrent-3.1.4-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00781.html
- mantis-1.1.4-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00504.html
Fedora 8 Security Advisories
- jhead-2.84-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00531.html
- php-Smarty-2.6.20-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00633.html
- mantis-1.1.4-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00648.html
- rgmanager-2.03.08-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00664.html
- kernel-22.214.171.124-49.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00689.html
- squirrelmail-1.4.16-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00735.html
- drupal-5.12-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00783.html
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
Fedora Xen List
This section contains the discussion happening on the fedora-xen list.
DomU I/O Performance Sanity Check
Ask Bjørn Hansen asked if the disk throughput he experienced matched what others see. The dom0 host achieved 120MB/sec sequential write speed, and a domU only 22MB/sec.
Troels Arvin's experiences with paravirt Xen on raw devices were fine for normal I/O but bad for low-level operations like file system creation. Troel also posted some benchmark results in 2007.
This section contains the discussion happening on the libvir-list.
sVirt Initial Prototype Release
James Morris requested comments on an initial prototype of
sVirt was first mentioned in FWN #138.
"The purpose of this release is to establish a proof of concept of applying security labels to VMs, and for discussion of the underlying technical approach."
"With this release, it is possible to define a security label for a
QEMU domain in its XML configuration ('
virsh edit'), launch the domain
and have it transition to the specified security label ('
then query the security label of the running domain ('
Hot-add SCSI/VirtIO Disks for KVM Guests
Guido Günther supplied a patch to add hot plugging and
unplugging of SCSI/VirtIO disks for
Domain Events Support Completed
After three rounds, Ben Guthro's domain events patches have been committed. This major API addition led Daniel Veillard to speculate that the next release version number may jump to 0.5.0. Domain events are only emitted from
KVM guests. The other hypervisor drivers will require more work to properly emit domain events.
python bindings are forthcoming. 
oVirt Devel List
This section contains the discussion happening on the ovirt-devel list.
New Model for Network Interface Configuration
Daniel P. Berrange offered that "network configuration UI discussions have all focused around the idea of configuring NICs on machines" and this is the wrong model. Adding, "if we can model a network as a global entity in its own right, we can simplify configuration of host interfaces" to "simply a matter of association, and optionally defining an address."
"So this kind of modelling can make our UI for setting up host networking much clearer / simpler, avoiding lots of redundant questions. Also, by having an explicit 'network <-> interface <-> host' assoication, we can trivally determine whether it is possible to migrate between two hosts from a network topology POV - its merely checking one DB relation."
This idea was met with acceptance.
Daniel illustrated the concept with the following entity relationship diagram.
1 n n 1 Network <-----> Interface <----> Node ^ 1 ^ 1 | | V n V n NetAddress Address
Mohammed Morsi created a UML diagram of the model as well.
Interface configuration was recently discussed in this thread as well.
OLPC Fedora SIG
In this section, we cover Fedora developments for the One Laptop Per Child (OLPC) XO laptop, and also Sugar development for Fedora releases. We also pull relevant stories from the OLPC-Community list.
Contributing writer: Pascal Calarco
Merging OLPC with Rawhide
Peter Robinson announced that he is beginning to merge
OLPC package branches into the mainline
Fedora 10 rawhide and
Fedora 9 joyride streams. Jeremy Katz suggested that probably just being concerned with
Fedora 10 is all that is needed, "[g]iven that the idea seems to be to rebase to F10 for the next OLPC release..." "In most cases, they're "something needs to be ported" --eg, some of the Sugar bits for the new NetworkManager dbus api or similar," he added
Pre-orders for Fedora 10 XO cards Open October 28th
Karlie Robinson announced that pre-orders for the Fedora 10 OLPC SD cards will start October 28 at On-Disk.com, and she'll update the list when pricing has been finalized. The cards will also eventually be available at Amazon.com. She added that users may be interested in this, "1) for adults who may not find the Sugar environment practical for daily use, the Fedora 10 option allows the machine to behave in a more familiar way. 2) In this sense, the XO is on-par with an Asus Eee PC, except your purchase during the G1G1 promotion directly effects the lives of children. A social purchase rather than a corporate profit purchase."
Fedora XO Network Test Meeting
The IRC logs from the meeting on 10/24/2008 were posted by James Laska. The team has outlined their test plans, and discussed which applications to test next, including command line tools,
NetworkManager, USB wired and wireless devices, and checking status of mesh networking in Fedora 10.
XO - XFCE Fedora 10 Test Team
James Laska invited interested folk to join a new team to begin testing
XFCE for the Fedora 10 build on the XO. "There's been a lot of buzz around using a more lightweight desktop environment on the XO," he wrote. "While GNOME will continue to be the desktop offered with this years G1G1, I certainly don't want to discourage folks from testing alternatives. I do want to emphasize though that GNOME is the primary focus for Fedora on the XO. The work that Josh Bresser's and the Performance Test team is doing is very important in identifying memory/cpu/"disk" hogs on the XO."
Interested parties can sign up, and more details on the team roles are also available
Sugar Review Activity
Sebastian Dziallas announced that the
Sugar Jukebox was ready for review.
This section covers Fedora/Sugar activity summarized on the OLPC-Community list, sent out weekly by [Jim Gettys]. The 10/20/2008 edition is available, and relevant items are summarized or reproduced below.
The QA team continued performance and capacity testing with a session of 20 laptops connected to a school server, with everyone using chat. A few new tickets were opened as a result of the testing, and "We continue testing with the school server while limiting to 50 - 55 the number of laptops connected to a single access point. We also plan to test other performance-enhancing configurations (including more than one access point connected to the same school server). We also plan to conduct performance testing in the "access point, no school server" setting."
The software development group was busy preparing future feature plans for the upcoming XOCamp, to be held the week of 11/17/2008 which welcomes presentations.
[C. Scott Ananian] continued work on the next version of the Journal (known as Journal2), with new media and screencasts available. [Eben Eliason] also spent time meeting and planning for Journal2, and will "...begin working on revised screenshots and use case scenarios next week so design and implementation can be brought together early in the next release cycle."
[Erik Garrison] spent the week testing various hierarchical file managers which could potentially be used in Sugar and working on UI performance issues. To close the week he published a set of potential modifications to the OLPC software distribution which dramatically improve user interface performance.
Chris Ball worked on power management and an interesting new screencast activity on the XO, "allow[ing] a movie to be created using the content of the display along with narration over the microphone; it could be useful for creating shareable tutorials and walk throughs both for learning how to use the XO and for learning in general."
The 0th issue of The OLPC Journal was put together by [Michael Stone] and [SJ Klien], covering activity on the OLPC devel list, announcements of the G1G1 laptop 2008 program, the upcoming XOCamp2, XO tips and tricks, and the Journal2 work.
An initial implementation of Moodle for the school server was completed by Martin Langhoff.
[Morgan Collett] debugged connections to jabber.laptop.org, and tried to make presence service more reliable in the face of network delays seen in this setup. He worked on API documentation for activity authors, and discussed 9.1.0 goals for collaboration.
Marco Pesenti Gritti wrote a proposal about API stability policy for Glucose and discussed it in the Sugar irc meeting, and wrote a list of work items to make Sugar window management more standard compliant and better host normal desktop applications.
[Tomeu Vizoso] worked on several tasks including adding downloading links and images to the Journal, adding a removable storage icon to Sugar's frame, in preparation of further improvements to handling USB sticks, improved shell loads by 70%, and other work.
Simon Schampijer has been landing the use of
gconf for the profile in
sugar-jhbuild. The profile is now using
gconf to store the preferences. The old API in sugar/profile has been kept around to not break activities using it, for example to request the nickname or the color of the user. You can keep on running multiple instances of the emulator by using the 'SUGAR_PROFILE=username sugar-emulator' command. This keeps on working since we use gconf-dbus in sugar-jhbuild and therefore run one gconf daemon per instance.
[Sayamindu Dasgupta] worked on revising the Khmer keyboard layout so that it adheres to the national NiDA standard as closely as possible. He also worked on adding fallback language support for translations (eg: an Aymara user would like to see Spanish translations as fallback if Aymara ones are not available instead of the default English). In the Sugar department, Sayamindu continued his work on Read and added support for handling external hyperlinks in the underlying evince python bindings.
Guillaume Desmottes implemented the last bits of the new search protocol in Gadget. He released Gadget 0.0.2 which should contain all the requested features. On the Gabble front he finished to implement the new protocol as well and merge the new Gadget API branch. In order to drastically simplify Gadget integration in Sugar, he investigated a new path where buddies in views where advertised as online by Gabble. He implemented it as a proof of concept and was able to very easily request views and making their activities and buddies appear in the mesh view without (almost) any PS change! He also released telepathy-python 0.15.2 which contains new API which are needed to perform Gadget searches.
Javier Cardona worked on driver support for the "wakeup on lan" (WOL) functionality that currently is implemented in the wireless firmware. We can now wake up the XO based on the presence of a number of predefined 4-byte patterns in the received wireless frames, making possible scenarios such as waking up on ARP requests for its IP address.
Ricardo Carrano spent the week in tests with the XO acting as an access point, working with students at UFF to build a wireless sparse mesh test bed and working with Cozybit on the remaining WPA timing issues.